Holy shit, what an incredible feat of work. 2 years of research and implementation. More than 2 months since they opened the PR and patiently worked through all the concerns raised by reviewers.
And the perf numbers look incredible!
They've designed 2 separate algorithms, one stable (design doc) and one unstable (design doc). The level of detail, care and patience that has gone into this work is next level.
Also, they point out that the community did say runtime performance is a high priority in the 2023 survey. Well, that's exactly what we've got. Sorting heavy programs are about to get much faster by simply compiling with the latest rustc.
hgwxx7_ on Rust's new sort implementations coming in Rust 1.81
The inherent problem is with human beings. The reason other languages are easier to prototype is is specifically because they don’t have guardrails. [...] This is the reality of languages that are easy to prototype in, they make it easy to move about freely with just one’s own naive assumptions about how a system should work, deliberately not being forced to take into account the entire state of the program. Then reality flies in the developer’s face and sod’s law painstakingly shows them every potential state their program can be in that they did not account for. I want to call this “the sin of naivety”. It’s impossible to be skilled enough to avoid this either, even the best programmers on earth make plenty of mistakes in C. It’s a problem well above what the human mind alone can handle, which is why we have these “hard” languages like Rust and Haskell, to act as our own extra hardware so we can think and reason better, better than our little monkey brains can handle.
Making unwraps easier to perform just sounds like someone trying to introduce exceptions or nulls into Rust. [...] even if I’m pretty sure it’s not going to be None/Err, I still properly handle that case by logging it and returning early, not panicking. Yes, it’s more verbose, but that’s not Rust’s fault, it’s the universe’s fault for making reality do things I wish it didn’t, like having flaky network connections or buggy programs. Some might consider that statement to be cope (I’m not wrong, everyone else is wrong!) but genuinely, what are you gonna do if there is an error? Crash? Ignore it? Make up an answer in it’s absence like a hallucinating LLM? You have to do something, and Rust makes you, even if that decision is to crash, at least it’s an explicit decision, unlike exceptions.
Q: How far from completion is the project: A: Hard to say. The codegen is mostly feature complete (besides async), and the only thing preventing it from running more complex code are bugs. If I knew where / how many bugs there are, I would have fixed them already. So, providing any concrete timeline is difficult.
This nomination elided some parts that I think are important context for the "properly", which inspires me to propose an alternative QoTW:
Is it a bug if the program couldn’t build a regular expression from a static string literal? Yup. The programmer typed that regex. It should be correct. So a panic is appropriate.
I have a dream. A dream that Cargo has its own release cadence, so it is free from the strict stability curse and can then ship major version releases.
Properly understood, imperative programming involves code operating over a world of objects, these objects have types, which enumerate the set of possible values the object could have, and these objects exist at places; as a result they also have a notion of identity, in that while two different objects at different places may have the same value, they do not have the same identity. Any programmer knows these facts intuitively but we often elide them when we speak about programming and often cannot clearly explain them, in the same way we successfully use our native languages without being able to explain their grammar.
JavaScript, Python and SQL are all highly-desired and admired programming languages, but Rust continues to be the most-admired programming language with an 83% score this year.
Currently with 37 votes in, the poll shows that 97% think that labeled break should not be used for early exits in closures. I want to point out to the small minority of us who thought that labeled break should be used for that purpose, that it's important that people write code in idiomatic manner because code consistency makes it easier for other people to read. This is why I introduced this as a warn-by-default lint, which would have forced everybody along the ride. Therefore we, the small minority, should not start using labeled break s for early exists in closures, even though we thought that it was a good idea - code consistency is more important than our personal preferences.
Isn't that a quote of, um, 98 weeks ago?