The author uses NixOS.
And that is a reasonable thing for those projects to try to achieve.
Still we've been downloading binaries for decades and the world hasn't ended, this issue never warranted people treating it like nuclear war was imminent and hurling abuse into Dtolnay's github issues like he was a child pornographer. There's a way to have a discussion about this being the wrong direction without doing that.
And I'd encourage everyone to take an honest audit of how many precompiled binaries are in their lives, even if they've switched to NixOS and how much stuff they trust downloading from the internet. Very few people achieve an RMS-level of purity in their technological lives.
There is a very real problem that he was trying to solve, but the right way to do it will require core language support. And his heart is certainly in the right place, since "slow build times" is probably the #1 complaint about Rust.
If you actually polled most Rust users they probably care about their build times more than they care about this issue, particularly if you designed the survey impartially and just asked them to stack rank priorities. They probably all would prefer "both" being the right answer though.
Where the criticism really needs to be leveled is on the core language design (although I appreciate that their job is also extremely tough).
[And the one good thing to come out of this shitshow will probably be getting people focused on solving this issue the right way]
Maybe they could learn a trick or two from each other?
Java’s standard HashMap isn’t thread safe, it has ConcurrentHashMap[0] for this reason. And I’ve never heard somebody refer to Java as an unsafe language. Lemire wrote a blog article arguing Java is unsafe for similar reasons that it seems you’re using here, and I think the comments section has some great discussion about whether this conflation of language safety makes sense or not[1].
And one final point: a lot of the world lives on software segregated across several different machines, operating asynchronously on the same task, usually trying to retrieve some data in some central data store on yet another machine. Rust is great for locking down a single monolithic system, but even Rust can’t catch data races, deadlocks, and corruption that occurs when you’re dealing with a massively distributed system. See this article that talks about how Rust doesn’t prevent all data races, and why it’s probably infeasible to do that[2]. And I doubt anyone here is about to call Rust unsafe :)
This conflation of language often confuses me and I hope as an industry we can disambiguate things like this. Memory safety is distinct from thread safety for a reason, and by all reasonable standards Go is as safe as a modern language is expected to be. (Obviously better thread safety is a goal to be lauded, but as an industry, it seems like we’re still trying stuff out and seeing what sticks in regards to that).
[0]: https://docs.oracle.com/javase/6/docs/api/java/util/concurre...
[1]: https://lemire.me/blog/2019/03/28/java-is-not-a-safe-languag...
From [2] you linked
> a race condition can't violate memory safety in a Rust program on its own.
From golang FAQ on maps not being atomic:
> uncontrolled map access can crash the program
This may be one very narrow case (or a more common theme), but at least in this case the thread safety becomes a memory safety concern in golang.
Otherwise you get into stupid situations like: https://xkcd.com/1172/ (your optimization is killing children!)
In FOSS there is the principle of four Fs:
- Fix it
- Fork it
- Fund it
- Fuck it/off
But we've gone from 0% to 100% overnight and as usual people have adopted it as their new religion and they want to burn all the heretics and there can be no compromise.
I seriously doubt that this one specific issue was all that important in the larger problem of securing the supply chain, and there was a very good reason why it was done (which has now been entirely thrown away, which will certainly harm adoption of rust). I don't think it was remotely comparable to the way all of npm is a security hole.