Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation.

So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language, but got another crappy one instead.



> So why do they need Rust then? What advantages does it provide?

That Rust didn't prevent one error in one specific instance does not mean that Rust didn't prevent any errors across any instances. Nor does it mean that Cloudflare didn't benefit from Rust in some way(s) elsewhere.

For example, from one of Cloudflare's previous blogposts [0] (emphasis added):

> Oxy gives us a powerful combination of performance, safety, and flexibility. Built in Rust, it eliminates entire classes of bugs that plagued our Nginx/LuaJIT-based FL1, like memory safety issues and data races, while delivering C-level performance.

[0]: https://blog.cloudflare.com/20-percent-internet-upgrade/


To prevent all the other potential memory safety bugs that didn't crash prior to this one?


If any language would've had this bug, why is Rust being singled out? If the software was written in Go, would the bug get the same attention?

No programming language should get flak for a bug that is not the fault of the programming language. This is Cloudflare's problem.


In Go, if one would ignore the error, it could result in a panic or the program would continue with some unexpected state. Go projects work on an honour system and either return Nils with errors or empty structs.


The same case in Go would’ve probably been a nil panic.


You should familiarize yourself with the prevention paradox.

If you're going to criticize something, at least do it properly.


Before the outage, Cloudflare had Cloudbleed: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

The move to Rust was partly motivated because it prevented that entire class of errors. No more out-of-bound reads, or data races. The compiler audits these missed spots.

Now, you could say a managed memory language would suffice as well. Perhaps it could. But we needed performance, and no memory-managed language met those performance needs then or today.

I get you're making the case that Rust isn't perfect for all use cases, but Cloudflare's scenario is the exact corner case your argument falls apart in: we needed fast and safe in an environment where not being fast or safe had real business consequences, and nothing else except Rust gave both.


That Rust produced a predictable and deterministic way of failing, while in C++ the equivalent code of accessing an uninitialized value without verifying it beforehand would have resulted in entirely unpredictable behavior whose reach is entirely unbounded.


Moreover, now they realize this is an issue for them, they can just do "Ctrl+F unwrap" and fix each instance. Then they can put a hook on their commits that automatically flag any code with "unwrap". In some languages where you're allowed to just ignore errors, you could fix the proximal bug, but you'd never be sure you weren't causing or ignoring more of the same in the future -- how do you search for what isn't there?


Due to the unfortunate naming of unwrap_or and friends it's a little (but only a little) more complicated than ctrl-f.


You can also forbid unwraps as part of clippy.


Not really. It's just "unwrap(" instead.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: