This was in response to MinIO/AIStor removing the browser-console UI from the community offering (locking it behind enterprise licensing) a few months back.
Unfortunately, this fork has not developed any traction. It's last commit was 4 months ago basically after the initial fork and instantly became dormant.
The Chandrasekhar limit is the maximum size of a white-dwarf, not a neutron star. It's usually defined as the minimum size of a neutron star (since it has to overcome electron-degeneracy pressure). The TOV limit[0] is the maximum size of a neutron star.
I was thinking of neutron stars all along - which, correct me if I’m wrong, look like they have similar density to an atomic nucleus and for which the upper limit is apparently 3 Sols. [0]
If there's a better URL, we can change it again. I just don't think year-in-review laundry lists make for very good discussion, because inevitably they produce generic referendum-style threads about the company or project.
It's a satirical comment on Tesla's meteoric stock price growth. The traditional quote is "Buy the rumor, sell the news"[0]. But with $TSLA, there's been nearly unbounded investor optimism.
Glad to see `Option::zip` stabilized. I tend to write such a helper in many of my projects to collect optional variables together when they're coupled. Really improves the ergonomics doing more railroad-style programming.
You sometimes have two Options that must both be Some to have any effect, but other reasons prevent you from making an Option of a tuple of those two fields. Eg think of deserializing a JSON that contains optional username and password strings, but you need both if you are to use them to authenticate to some remote.
In that case, you currently have to write code like:
if let (Some(username), Some(password)) = (username, password) {
/* both are set */
}
else {
/* at least one is not set */
}
With zip this can be written as `if let Some((username, password)) = username.zip(password) {` In this case it doesn't look like a big difference, but it does allow you to chain other Option combinators more easily if you were doing that instead of writing if-let / match. Using combinators is the "railroad-style programming" that kevinastone was talking about. For example, you can more easily write:
let (username, password) = username.zip(password).ok_or("one or more required parameters is missing")?;
You could of course still do this without .zip(), but it would be clunkier:
let (username, password) = username.and_then(|username| password.map(|password| (username, password))).ok_or("one or more required parameters is missing")?;
The zip form does lose the information of which of the two original Options was None, so if you do need that information (say the error message needs to specify which parameter is missing) you'd still use the non-zip form with a match.
The zip solution however requires any reviewer to look up on what it actually does, whereas the "if let" is more of a language fundamental and known to most reviewers.
Therefore I would actually prefer the long/verbose form without the zip.
It's just the opposite. zip is a normal function written in normal code, so if the reviewer doesn't know what it does then they can just click through to the definition in their IDE. Whereas "if let" is some kind of special language construct that a reviewer has to look up through some special alternative channel if they don't understand it.
If I'm doing a code review I don't have an idea. I only see text (yeah - limitation of the tooling, but reality). I can search for the functions, but it's a hassle and I want to limit having to do it to as much as possible. It's even not super easy in Rust, since some functions are defined on (extension) traits and you don't exactly know where to search for them if you don't have the IDE support and are not already an expert.
"if let" is certainly a special construct - but it's also one that Rust authors and reviewers will typically encounter rather fast since a lot of error handling and Option unwrapping uses it. Knowing the majority of library functions will imho take longer.
Understanding - or looking up - library functions is something you're always going to have to do during code review (it's well worth getting IDE integration set up). zip is a very standard and well-known function (I used it yesterday, in a non-Rust codebase); it may well end up being better-known than "if let". Learning what a library function does is certainly never harder than learning what a keyword does and it's often easier (apart from anything else, you know that a library function follows the normal rules for functions, so if you can see how its output is used then you can often tell what it does. Whereas you can't rely on that kind of reasoning with language keywords).
Unfortunately, this fork has not developed any traction. It's last commit was 4 months ago basically after the initial fork and instantly became dormant.
You can see the list of 'Still alive?' issues: https://github.com/OpenMaxIO/openmaxio-object-browser/issues...