4 ms·
It has potential to be the new thing, since several details synergize to make this incident more powerful: 1. Previous claims that Rust code often just works a
by blub 11mo ago
It has potential to be the new thing, since several details synergize to make this incident more powerful:
1. Previous claims that Rust code often just works after compiling.
2. Previous claims that low-level error-handling idioms like matching, using Result, etc improve code reliability.
3. Previous claims that using unwrap in example code is ok for brevity. Also, Rust developers would know not to use it in production code.
4. The fact that significant portions of the internet were taken down because a production unwrap from a big, mature player and one of the Rust early adopters.
Sure, Rust is not the problem here, but rather Clownflare being too big and not having their SRE processes fully up to par for their size. Perhaps they are simply too big to operate at the needed level of reliability.
However, Rust anti-fans can easily ignore the above and simply press the issue and debate the minutiae of error handling, human reliability, etc. It’s surprisingly effective and might even catch the ear of management.
However, this article is overall not at the level expected of Rust anti-fans in 2025. I commend the author for trying, but they need to improve in several areas like providing iron-clad real-world examples, proving the required level of experience, focusing more on pain points like dependencies and the potential for supply-chain attacks, addressing reskilling issues and internal corporate politics, etc.
There was a blog by a veteran Rust game developer a while back which single-handedly destroyed the enthusiasm for Rust in gaming. That is the gold standard of Rust criticism for me.
- hananova 11mo ago1. But the code did just work after compiling. The code said "This can never be an Err, and if I'm wrong, you are allowed to panic." And it did just that. 2. They do. If you use them, which they didn't. 3. It is. Let's not discard personal responsibility. 4. The error would've happened in any language, Rust debatably made it easier to find though. I don't write Rust code myself because I simply don't write any code that requires this kind of reliability, and thus I haven't expended the effort learn it properly. But if I were to start such a project, I would still go for Rust and learn it properly. I also don't have a "favorite" language. I just pick whichever seems most appropriate for the project, any decent programmer should be able to pick up any non-esoteric language to the point of adequacy in a few weeks anyway.
- imtringued 11mo ago.unwrap() was a huge mistake. It should be banned from release builds outright. It's the equivalent of dereferencing a null pointer in C or the NullPointerException in Java. All .unwraps() should be replaced by .expect("uniquely identifying message") immediately and preferably the compiler checks that the expect messages are unique within a crate and issues a warning. Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration).
- optionalsquid 11mo agoTo my knowledge, the only difference between `unwrap()` and `expect()` is that the latter takes a custom error message, whereas the former generates a generic error message. In both cases the resulting error message includes the filename and line number of the panic. Both can also generate stack traces if you set `RUST_BACKTRACE=1`, unless this was explicitly disabled at compile time. So if you want to ban `unwrap()`, then you should probably also ban `expect()`, and make sure to handle all possible cases of Err/None instead.
- neonspark 11mo ago> Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration). I'm trying to understand what you're proposing. Are you saying that normal debug builds should have artificial failures in them, or that there should be a special mode that tests these artificial failures? Because some of these failures could cause errors to be shown to the user, that could be really confusing when testing a debug build.
- estebank 11mo agoI guess they are advocating for exhaustive branch testing.