| ▲ | lispisok 6 hours ago | ||||||||||||||||||||||
Rust is cool but there is way too much dogma around its memory safety and static typing in general being a panacea. Most errors are not type errors. Two days after Cloudfare's little Rust hiccup that took the internet down for a day I saw people posting about Rust "if it compiles it runs". | |||||||||||||||||||||||
| ▲ | JuniperMesos 6 hours ago | parent | next [-] | ||||||||||||||||||||||
I actually don't think this is true. I do think that most programming errors are type errors, in the broader sense of one part of a system making one set of assumptions about the properties of some data, that aren't shared by another part of the system; and that would've been caught automatically by sufficiently sophisticated static correctness checking. I do not think that Rust has a maximally sophisticated type system (nor is it trying to), and while this is reasonable for Rust as a project to decide, I do expect that there will be languages in the future that do more complex things with type systems that might supplant Rust in some domains. The Cloudflare incident was caused by a confluence of factors, of which code written in Rust was only one. I actually think that Rust code worked reasonably well given the other parts of the system that failed - a developer used unwrap() to immediately crash instead of handling an error condition they thought would never happen; when that error condition did happen the Rust program crashed immediately exactly as expected; and if Cloudflare decided that they wanted to ban not handling an error like this in their codebase, it's a pretty easy thing to lint for with automatic tooling. | |||||||||||||||||||||||
| ▲ | pjmlp 5 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
If it helps finally acknowledging basic stuff like bounds checking matters, great, this from a guy that rather use system languages with automatic resource management. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture" From 1980! C++26 will finally have hardening on the standard library, something that I could already enjoy in 1990's with Turbo Vision, OWL, MFC, VCL, but was too much to ask for on the standard library apparently, even if compilers kept having each own their approach. It took governments and companies to start mapping CVEs to money spent fixing them, to finally acknowledge something had to change. Meanwhile on C land, business as usual regarding Hoare's quote. | |||||||||||||||||||||||
| |||||||||||||||||||||||
| ▲ | josephg an hour ago | parent | prev | next [-] | ||||||||||||||||||||||
Rust doesn't eliminate all bugs. But anecdotally, by the time the type checker and borrow checker have humbled me, my programs really do often work the first time I run them. Its quite remarkable. This isn't a special thing about rust. All languages are on a spectrum of "detect all bugs statically" to "detect all bugs dynamically". Rust programs run correctly "first time" more than javascript, more than typescript. But still less than haskell. You can still write bugs in rust, obviously. I've written plenty. As you say, so has cloudflare. But strong typing does find a lot of bugs in practice. | |||||||||||||||||||||||
| ▲ | dcminter 2 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
I don't think your comment deserves the downvotes (upvoted to compensate) but I do think that it's questionable if "Most errors are not type errors" is true. Rust's culture of pushing things into type checking does eliminate a huge swathe of bugs and I wouldn't be surprised if it was the majority. The hurdle of negotiating translation between filesystem strings and unicode strings strikes me as a good example of a place where most languages don't protect you from bugs and a strongly typed one does. The downside, of course, is that you have to handle these cases (even if it's to explicitly say "I don't care"). I still create dumbass bugs in Rust, but they are usually simple logical errors that are pretty obvious when debugging. | |||||||||||||||||||||||
| ▲ | antonvs 6 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
> Most errors are not type errors. If you follow good strong typing principles, you can ensure that most errors are type errors. Yaron Minsky’s phrase, “Make illegal states unrepresentable”, captures this. But it doesn’t happen by accident just because you’re using a strongly typed language. Also, if Cloudflare had run the standard Clippy linter on their Rust code, and taken the results seriously, it would have prevented the issue you referenced. Static checks don’t help if you ignore them. | |||||||||||||||||||||||
| ▲ | IshKebab 3 hours ago | parent | prev [-] | ||||||||||||||||||||||
> Most errors are not type errors. With a sufficiently strong type system all errors are type errors! Rust doesn't have that of course, but it does have quite a strong type system so this is a very bold assertion with no evidence. Rust does have an "if it compiles it works" feel. Nobody means that literally (this should be really obvious). They just mean that once you get it to compile the chance that it works first time is quite high (like 20% maybe?) compared to most other languages where it's more like 1%. | |||||||||||||||||||||||