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

61–70 of 308 posts

Re: My negative views on Rust (2023)

#61

Post by CryZe »

s17n wrote: post #43
jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

> Fetishization of Efficient Memory Representation: ... I don't understand what the point is here. Some people care about avoiding heap allocations? They're a tool just like anything else The point is that dealing with the Rust borrow checker is a huge pain in the ass and for most Rust applications you would have been better off just using a garbage collected language.

> huge pain in the ass

Maybe if you structure your code weirdly? I haven't encountered a major borrow checker issue that I couldn't easily resolve in many years.

Re: My negative views on Rust (2023)

#62

Post by CryZe »

hyperbrainer wrote: post #48
jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

> Rust is as complex as C++: ...no, it's not. Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of features in unstable that seem to be stuck there, but I hope will eventually make its way to stable at some point. > Async Rust really is fine I dunno. Always thought it was too complicated, but as another person pointed out avoiding Tokyo::spawn solves many iss…

> Maybe not yet, but it is heading in that direction

About 95% of the unstable features lift limitations that most people expect not to be there in the first place. I'm not aware of all too many that aren't like that.

Re: My negative views on Rust (2023)

#63

Post by rastignack »

brink wrote: post #25
VeejayRampay wrote: post #8

rust is fine, it's a solid mix of performance and expressiveness, it has good constructs and it's gaining traction it's hard to learn so we shall see what kind of niche it can carve for itself, but it's fine

> it's hard to learn And as long as Rust remains popular, this is why we will witness endless complaining about it. Most devs are lazy, and would rather sweep complexity under the rug and pretend it doesn't exist until it becomes a real problem they can't ignore anymore. That's fine. But no need to be so vocal about it. At this point, people whining about Rust is more of a trope than people proselytizing it.

> Most devs are lazy, and would rather sweep complexity under the rug and pretend it doesn't exist until it becomes a real problem they can't ignore anymore

You mean pragmatic. Not all of us are memory absolutists. The time ideally invested in memory management really depends on the problem space, the deadlines, etc.

Re: My negative views on Rust (2023)

#64

Post by lacker »

I like Rust but at the same time I agree with the points here. These things are indeed problems with Rust.

Nevertheless, C++ has even worse problems. When your alternative is using C++, that's the time to consider Rust.

Re: My negative views on Rust (2023)

#65

Post by lovethevoid »

jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

This was an oddly defensive and vapid comment. Mostly just handwaving away any views the article brings up, of which at least the article expands on their thoughts. This comment is just "meh not a bad thing" repeatedly. Why is this comment being upvoted?

Re: My negative views on Rust (2023)

#66

Post by nine_k »

tptacek wrote: post #19
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 fram…

Rust makes you think about your memory layout, memory allocation and avoiding thereof, about the specific time you grab and release other resources, about specifics of your inter-thread interactions, etc.

If such considerations are natural for your problem domain, you likely do "systems programming" and also happen know C, have an.opinion on Zig, etc.

If such considerations are the noise which you wish your language would abstract away, then you likely do "application programming", and you can pick from a wide gamut of languages, from Ruby and Python to Typescript to Elixir and Pony to C#, Java, and Kotlin to OCaml and Haskell. You can be utterly productive with each.

Re: My negative views on Rust (2023)

#67

Post by rich_sasha »

I think to some extent Rust is a victim of its own unreasonable effectiveness. It is great at its narrow niche of memory safe low level programming, but frankly pretty good at lots of other things. But at these other applications some of its design principles get in the way - like the pedantic borrow checker. Languages not used outside their niches don't tend to collect such criticism.

Python is a bit like that. It is a top choice for a few things, and ends up used effectively for other things, simply because it is versatile. But then people run into issues with dynamic typing, zero static safety, start slapping type annotations everywhere... and bemoan Python as a bit of a horror show.

My use case for Rust is complementing Python, where frankly I don't care about half the complex features, still it's nicer than C or C++ to code in. The complexities of the borrow checker are more like a tax to me. I understand people who are frustrated with it thought, as otherwise they see it as a bit of a perfect language.

Re: My negative views on Rust (2023)

#68

Post by ordu »

tptacek wrote: post #16
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.

> 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?

No, but Gc will not resolve the core problem either. The core problem is that rust forbids two mutable pointers into one chunk of memory. If your tree needs backlinks from child nodes to parents, then you are out of luck.

Re: My negative views on Rust (2023)

#69

Post by Const-me »

Animats wrote: post #11

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

> I just do not see why people seem to use "unsafe" so much

Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code in the implementation to allocate heap memory. When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice.

C++ does pretty much the same under the hood, but that’s OK because the entire language is unsafe.

C# has an unsafe subset of the language with more features, just like Rust. However, it runs inside a memory-safe garbage collected runtime. Even List and Dictionary data structures from the standard library are implemented with safe subset of the language. Efficient trees and graphs are also trivial to implement in safe C#, thanks to the GC.

Re: My negative views on Rust (2023)

#70

Post by DiabloD3 »

tptacek wrote: post #44
DiabloD3 wrote: post #36

Earlier quoted context omitted.

"Systems programming language" has almost turned into a weird slur; instead of using it to refer to languages that can actually handle that task, they use it to attempt to pigeonhole a language into only that. As in, people don't realize being a "systems programming language" is extremely difficult to get right, and many languages simply can't handle that (and never will, as per internal design requirements unique to…

See, depending on your definition of "systems programming language", that is just wildly false. A language that nails all the details and ergonomics of expressing a kernel block device driver is almost necessarily going to be suboptimal for exploratory scientific computing or line-of-business app development. Again: this is about the term, not about the language. I don't think it's controversial to suggest that there…

I don't think the people that use it as a slur actually define it. They use it to mean the language they don't like because they think it has some level of enforced complexity that takes away from the language instead of being an important feature of the language.
Post reply on HN