101–110 of 341 posts
You really have to compare articles like this, which are just a bunch of hand waving around the author's biases, against articles with more concrete statements like the Android team finding a 1000x reduction in memory vulnerabilities compared to C/C++. Thanks for your opinion but I'm going to weigh the people who actually use the language more than you.
Rust has its issues and there are plenty of things to not like about Rust, but this article is giving me the impression that this person has not written much Rust. Unfortunately, many such cases with Rust criticism. > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliabi…
Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source of bugs in applications — as developers of Zed found out.
>Doing this the "correct" way in other languages has similar impact? So I'm not sure why Rust forcing you to do the correct thing which causes perf issues is uniquely a Rust issue. Doing this the "just get it done" way in other languages will likely come back to bite you eventually even if it does unblock you temporarily.
It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient. I mean you just spawn lots of objects with random references in between and then eventually GC untangles the mess — it's zero overhead until the GC cycle. Escape analysis and semantic-reach containers can reduce GC work a lot (so you don't have the classical JVM GC problems). More specialized things like RCU and general quescence-state reclamation can be totally pause-less.
Earlier quoted context omitted.
Idk, it's a general rule of thumb that the more mutable shared state an algorithm has, the worse it scales. So if you're trying to scale something to be concurrent, mutable shared state is an antipattern.
It's lock contention that slows things down more than anything. But it's really an 'it depends' situation. The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
It's all flavors of the same thing. Lock contention is slow because sharing mutable state between cores is slow. It's all ~MOESI.
> The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
Yes. Aka shared nothing, or read-only shared state.
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…
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.
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…
>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,…
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/
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…
>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,…
The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.
Yes, but in C++ we would simply not have asserted the result has_value instead of has_error and instead returned some implicit memory corruption. Or, I think that is the author's argument. (I don't subscribe to that point of view.)
D language smiling in the corner [1].
"D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." [2]
[1] Kevin James meme creator tries to guess why the photo went so viral:
https://www.yahoo.com/lifestyle/kevin-james-became-internets...
[2] Ask HN: Why do you use Rust, when D is available?
Earlier quoted context omitted.
The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword. The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind. Unsafe in a language like Go is very rare, mostly because people do not program at such low system le…
It's got really not much at all to do with `unsafe`.
> telling a victim “but the memory was not corrupted in the crash” is a weak consolation. We actually had a recent Cloudflare outage caused by a crash on unwrap() function. It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability This is incorrect in a way that honestly feels insulting. It's not the language's fault that you called the `crash()` f…