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

My negative views on Rust (2023)

chrisdone.com

Post reply on HN
Print view View original

11–20 of 308 posts

Re: My negative views on Rust (2023)

#11

Post by Animats »

My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people seem to use "unsafe" so much.

Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time. Detecting a double borrow is the same problem as detecting a double lock of a mutex by one thread, which is being worked on.

Re: My negative views on Rust (2023)

#13

Post by egnehots »

Some points resonate with me:

> People don't want "to have to play Chess against the compiler"

Things that are easy to express in other languages become very hard in Rust due to the languages constraints on ownership, async...

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.

It's indeed hard to keep up.

> Async is highly problematic.

Yes, more complexity, more fragmentation and feel like another language.

But one point feels unfair:

> the excellent tooling and dev team for Rust [..] pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in.

What? No. The main appeal was the safety. It's still a distinctive feature of Rust. To almost eliminate a whole class of safety issues. It has been proven by several lengthy reports such as https://security.googleblog.com/2024/09/eliminating-memory-s....

They are many projects for which the reliability and efficiency are worth the trouble.

Re: My negative views on Rust (2023)

#14

Post by dvektor »

I agree with a couple points here, specifically I agree that choosing a language based on it's community (and not it's ecosystem) is just silly. And we all know that async ended up being a bit of a thorn in rust's side.

But yeah, rust is very much a systems language: so it will be forcing you to think about memory layout one way or the other. Idk how valid of a complaint that is when you really consider that, and specifically the other alternatives you have.

Re: My negative views on Rust (2023)

#16

Post by tptacek »

hyperbrainer wrote: post #4

Needs (2023) > I predict that tracing garbage collectors will become popular in Rust eventually. The use of Rc is already very widespread in projects when people don't want to deal with the borrow checker and only want to use the ML-like features of Rust (Sum types, Option, Error etc.) > Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.…

Does Rc really resolve the core problem this post is talking about, which is that it's really painful to naturally express tree and graph structures in Rust? It feels like I mostly see people talking about building application-layer pointer systems with integers, which would be surprising if (in a single thread, perhaps) you could just Rc your way around the problem.

Re: My negative views on Rust (2023)

#17

Post by cyberax »

VeejayRampay wrote: post #9
IshKebab wrote: post #7

So much to disagree with.... > In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler. Sure, Rust's strong encouragement of tree-structured ownership may be annoying when you try and make a spaghetti ownership soup, but it's not like it doesn't have upsides. Many people have written about how the ownership & borrowing rules lead to code structure that has…

I'm curious what kind of code gets a 45x speedup by going from python to rust and by that I don't mean the rhetorical or bait-style "i'm curious", no, the literal I'm curious, cause I'm trying to find use cases such as that these days and I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful

> I'm curious what kind of code gets a 45x speedup by going from python to rust

Pretty much any code that is not just tying together external libraries?

Re: My negative views on Rust (2023)

#18

Post by tedk-42 »

DiabloD3 wrote: post #3

I've read this before, it's been passed around the Rust community a few times. The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (H…

Surely someone who writes a lot of C code as he mentions has written it for hardware, no?

Re: My negative views on Rust (2023)

#19

Post by tptacek »

dvektor wrote: post #14

I agree with a couple points here, specifically I agree that choosing a language based on it's community (and not it's ecosystem) is just silly. And we all know that async ended up being a bit of a thorn in rust's side. But yeah, rust is very much a systems language: so it will be forcing you to think about memory layout one way or the other. Idk how valid of a complaint that is when you really consider that, and spe…

A complication of the "Rust is a systems programming language" thing is that people adopt definitions of "systems" of varying expansiveness to suit the situation. There are unquestionable systems programming domains --- the kernel is a great example, and one where it's easy to see why Rust is an exciting proposition; same with browsers, the "second OS" everyone runs --- and then more questionable domains. Is the framework-layer code for a CRUD web application "systems" code? How about a container orchestrator?

This isn't a criticism of Rust, but rather of the framing we often use to compare Rust and (say) Python or Java.

Re: My negative views on Rust (2023)

#20

Post by IgorPartola »

hyperbrainer wrote: post #6
henning wrote: post #2

> People waste time on trivialities that will never make a difference. Depending on the situation, memory layout could be trivial (copying 200 bytes once at startup vs. not in a way that should never be user-perceptible and difficult to even measure) or actually a big deal (chasing down pointers upon pointers in a tight inner loop). It's entirely situational. To dismiss all of that as "trivial" and saying it will "ne…

Criticising a systems programming language for needing to manually manage memory is honestly embarrassing.

I mean to be fair so is using a systems programming language for every use case under the sun. If Rust is a great systems programming language that’s one thing. If it’s a general purpose language that’s another.
Post reply on HN