Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Several core problems with Rust

bykozy.me

Post reply on HN
Print view View original

151–160 of 341 posts

Re: Several core problems with Rust

#151

Post by Mauneam »

rddbs wrote: post #144
Mauneam wrote: post #127

Earlier quoted context omitted.

First, he didn't call the "crash()" function, he called the "unwrap()" function. The fact that they decided to call the crash function "unwrap()" is not the OP's fault, it's the language authors' fault. Second, you totally missed the OP's point about reliability. If one has to choose between UB and an immediate halt, those are pretty sucky options. And the OP is 100% right about Rust crashing all the time. Nothing in…

You get to choose between UB, a crash, or handling the error — same as most other languages. It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.

No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent.

The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "chose to double-free".

Re: Several core problems with Rust

#152

Post by byko3y »

lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

>Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile.

What's the largest Rust-based public codebase so far? Rustc with like 1 million lines of code including all the dependencies in all the languages? Zed IDE has 800k lines. Incremental compilation seems to work fine at this scale, but things become messy above it. Most people prefer to not exceed the limit.

>Mutable shared state: make bad designs hard to write. Mutable shared state is another one of these eternal bug sources. Use channels and pass messages.

People think BEAM (Erlang/Elixir) does not have shared mutable state because the programming model says so, but it actually has some mutable shared state transparently under the hood i.e. implementation details and runtime. BEAM processes all run in a single OS address space, they are not even separate threads but async tasks spread out across OS threads — and still per programming model of the language those are "shared nothing". So in the end BEAM is a very good abstraction on the partially shared mutable state.

And no, in BEAM remote messaging is not nearly the same as local messaging. For example, you don't have built-in supervision trees on remote, and ETS is also local-node-only.

I do agree that hardware model of shared mutable state is inherently problematic, but we don't have other commodity CPU-s yet — you have to handle the shared mutable if you wanna be close to hardware.

>It reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Of course everything is cumbersome before you're used to it.

Well, at least you confirm that the complexity is real. Don't get my criticism to close to the heart though — I did exaggerated the problems a bit, because someone needs to counteract the fanboys.

Re: Several core problems with Rust

#153

Post by throwaway81523 »

bccdee wrote: post #80
hekkle wrote: post #64

Earlier quoted context omitted.

> I would love to hear what he thinks a good programming language is Also, not the OP, but I bet it is Python. - No compile time. - Not as complex as C++. - Memory Safety, while they don't care about this apparently, but nice to have. - Plenty of ergonomic GUI style programming, like PySide (Qt for python). Of course, I know there are many downsides to python. Such as interpreted languages, especially ones that are d…

The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better. Unfortunately I don't think their critique is really coherent—this is an absurd standard.

Other languages have some kind of exception mechanism so the crashing unwrap gets caught and handled, preferably sanely. Erlang in fact is written around the idea of expecting stuff to crash, and restarting the crashed thing when it happens.

Re: Several core problems with Rust

#154

Post by [deleted] »

ModernMech wrote: post #145
Maxatar wrote: post #137

Earlier quoted context omitted.

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 the…

[deleted]

Re: Several core problems with Rust

#155

Post by PaulDavisThe1st »

loeg wrote: post #122
PaulDavisThe1st wrote: post #118

Earlier quoted context omitted.

as noted someone else, it is lock contention that doesn't scale, not mutable shared state. lock-free data structures, patterns like RCU ... in many cases these will scale entirely appropriately to the case at hand. A lot of situations that require high-scale mutable shared state have an inherent asymmetry to the data usage (e.g. one consumer, many writers; many consumers; one writer) that nearly always allow a better…

No, it's the mutable shared state that is the problem. Lock contention is just downstream of the same problems as any other mutable shared state. > patterns like RCU RCU isn't mutable shared state! It's sharing immutable state! That's the whole paradigm.

What do you think the "update" part of RCU actually does?

Re: Several core problems with Rust

#156

Post by Capricorn2481 »

lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it

This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB.

Doesn't mean I think it's worth complaining about, there's really no better way for Rust to do this without sandboxing memory.

Re: Several core problems with Rust

#157

Post by jandrewrogers »

loeg wrote: post #62
cogman10 wrote: post #38

Mutable shared state is a feature, not a bug. It's true that it's easier to write correct async code using immutable shared data or unshared data. However, it's very hard if not impossible to do fast and low memory concurrent algorithms without mutable shared state.

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.

At scale, algorithms are commonly limited by memory bandwidth, not concurrency. Most code can be engineered with enough cheap concurrency to efficiently saturate memory bandwidth.

This explains why massively parallel HPC codes are mostly minimal mutable state designs despite seemingly poor theoretical properties for parallelism. Real world performance and scalability is dictated by minimization of memory copies and maximization of cache disjointness.

Re: Several core problems with Rust

#158

Post by riwsky »

tialaramex wrote: post #119
fn-mote wrote: post #41

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.

By coincidence I was talking to one of Cloudflare's engineers this weekend† and they actually argued that the unwrap() isn't the problem per se, that instead it's just wrong to go from "We don't know if this data works" to "Everything is broken" without the step where you check that data works - and that's still true if we're doing this once per minute not once per month. I argued that requiring expect("expectation")…

Screw discipline, it’s a tooling problem. Making canary rollouts with automatic rollback the default would take a lot of investment up front, but then would make discipline at release time a non-factor.

Re: Several core problems with Rust

#159

Post by merb »

fhap wrote: post #117
delifue wrote: post #112

The biggest value of Rust is to avoid heisenbug https://en.wikipedia.org/wiki/Heisenbug Memory safety and thread safety are causes of heisenbugs. However there are other causes. Rust don't catch all heisenbug. But not being perfect doesn't mean it's useless (perfect solution fallacy). The article has some valid points but is full of ragebait exaggeration.

> The article has some valid points but is full of ragebait exaggeration. Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad. People can use C now that LLMs make it easier, so Rust is no longer needed in many ways.

You are joking, right? Writing c with llm‘s… what can go wrong?!

Re: Several core problems with Rust

#160

Post by vacuity »

byko3y wrote: post #104
hypeatei wrote: post #68

> 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,…

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.

Post reply on HN