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

281–290 of 308 posts

Re: My negative views on Rust (2023)

#281

Post by almostgotcaught »

pjmlp wrote: post #264
almostgotcaught wrote: post #254

Earlier quoted context omitted.

> Not completely but they are interchangeable ... I'll just ask you this extremely simple question: does C# compile/run/whatever-magic-you-think-it-does on targets that aren't in {x32, x86, ARM64}? Does it target RISC-V? Does it target PTX? Does it target AMDGPU? Are you getting the picture? Pre-empting the most low-brow dismissal: these are only niche targets if you've never heard of a company called NVIDIA.

Yes, NVidia has support for .NET on the CUDA ecosystem via partners, the only one that matters on GPGPU. Yes, Linaro is doing work for managed runtimes on RISC-V, although it remains questionable how much RISC-V matters outside nerd circles.

> Yes, NVidia has support for .NET on the CUDA ecosystem via partners, the only one that matters on GPGPU.

Ironic because "via partners" is equivalent to "doesn't matter".

Re: My negative views on Rust (2023)

#282

Post by tptacek »

pjmlp wrote: post #267
tptacek wrote: post #102

Earlier quoted context omitted.

Yes: it's about the distinction between global GC and programmer-defined memory management. GC is about as straightforward a tradeoff as you can make: remove a very large class of programmer concerns in exchange for a different performance envelope. It is not reasonable to argue that Rust's memory management doesn't represent a point on a tradeoff space --- that people suggesting GC languages are better fits for some…

Meanwhile there are companies doing just that, better let their management know how fool they are selling bare metal real time Java runtimes, Oberon, Go and C# based microkernels. Even more so the fools that given them money for such products. /s

Look, I know there are bare metal Java runtimes (I've done assessment projects for some of them), I just don't want to litigate the point. I'm fine with a definition of "kernel programming" that fits Linux and the NT kernel and nothing else.

Re: My negative views on Rust (2023)

#283

Post by tptacek »

School-Cotton wrote: post #271
tptacek wrote: post #180

Earlier quoted context omitted.

When we talk about Rust being a reasonable choice for things like (say) a CRUD app, memory safety is already table stakes; every mainstream high-level language is memory-safe. Why would you ever pick Rust over Java? The answer to that question will be an even better answer to why you'd write a game in Rust.

Java may be memory safe but it is not data race safe (unlike Rust, the compiler does not enforce cross-thread synchronization). So there is still a safety-related reason to use Rust over Java. That said, I don't really think Rust is a good choice for CRUD apps, because development velocity is more important than performance and they probably don't need to be multithreaded anyway. But Rust would have been great for a…

I feel like I've had this debate many, many times, and it always ends in the same place: I'm willing to concede that there are a subset of correctness/reliability bugs that Rust's error handling and type system mitigate, but not that any of those bugs are material to security, which is what most people are talking about when the discussion turns to memory safety. And, of course, Rust admits concurrency bugs too! We just ran into a huge one.

Re: My negative views on Rust (2023)

#284

Post by drogus »

senorrib wrote: post #122
drogus wrote: post #114

It's funny when people mention Go as the gold standard of not adding features to the language and Rust as ever-changing when Rust hasn't introduced any major changes in at least 3-4 years and Go introduced a major paradigm shift in how people structure their code (generics). Before you start replying with "Rust introduced X" - ask yourself - is X extending an existing feature slightly or does it introduce an entirely…

Generics is hardly a major paradigm shift, and these two languages are worlds apart in amount of features.

That's not the point, though. The author says:

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest. Go was designed as the antidote to this kind of endlessly increasing language surface area.

Yes, Rust learning curve is much steeper and the "language surface area" is big, but it's not changing much in recent years. Go getting generics is much bigger change than anything that Rust got in a long while.

Re: My negative views on Rust (2023)

#285

Post by drogus »

kunley wrote: post #205
drogus wrote: post #114

It's funny when people mention Go as the gold standard of not adding features to the language and Rust as ever-changing when Rust hasn't introduced any major changes in at least 3-4 years and Go introduced a major paradigm shift in how people structure their code (generics). Before you start replying with "Rust introduced X" - ask yourself - is X extending an existing feature slightly or does it introduce an entirely…

I think the author rather refers to "tamagotchi tooling" and constant adapting libraries to new trends. It was not that much about language changes per se

I guess it depends on what libraries you're using, but honestly a lot of very popular libraries are at 1.x and hardly change. Honestly I'm not sure where people are getting these experiences from. I feel like either they make it up or they talk about experiences from 2017 or sth. Or maybe they are very unlucky when choosing dependencies?

Re: My negative views on Rust (2023)

#286

Post by steveklabnik »

School-Cotton wrote: post #272
steveklabnik wrote: post #216

Earlier quoted context omitted.

> the degree to which you have to ask yourself if you want to use String or if you want to use &str In practice, there isn’t a ton of thinking to do about this: if it’s a struct, you want String. If it’s a function parameter, you want &str, and if it’s a function’s return type, you want String. Doing that until you have a reason not to is the right call 95% of the time, and 4% of that last 5% is “if the return type i…

If you write Rust like this (insisting that structs always fulfill 'static) you will end up unnecessarily cloning memory way more than you would in a GC'ed language. In GCed languages strings get allocated once when you need them, get referred to wherever you want, however many times you want (with no new calls to the allocation subsystem), and are freed once when you don't need them anymore, with minimal thought or…

That’s why it’s “until proven otherwise.” As you gain experience you can be more subtle about it, and you gain more intuition, but it’s just not that big a deal until you demonstrate it’s a big deal.

I rarely type clone(). Even with this advice, you won’t clone super often. And when you do, it’s a signal sometimes that maybe you can do better, but it’s just not a big cognative burden.

Re: My negative views on Rust (2023)

#287

Post by tinrab »

RandomThoughts3 wrote: post #270
tinrab wrote: post #191

Earlier quoted context omitted.

I hear this constantly but never see any examples of what they actually mean, or it's coming from misunderstandings of what the language is. I've seen people say how well the async code could be if Rust got a garbage collector. For the borrow checker specifically, I think it's important to understand smart pointers, Cell/RefCells, other primitives, and the fact that you don't have to solve everything with references.

> it's coming from misunderstandings of what the language is “You are just not holding it right.” Rust borrow checker indeed does force you to make contorsion to keep it happy and will bite you if you fail to take its particularity into account. It’s all fine and proper if you think the trade-off regarding safety is worth it (and I think it is in some case) but pretending that’s not the case is just intentionally del…

Can you give me an example of what the borrow checker prevents you from doing without calling Rust developers delusional? The hardships are way overstated, in my opinion. One issue I can think of newcomers might have is immutable and mutable references. You can't borrow as mutable something already borrowed. Let's say you have a reference to a Vec element, then you add an item to Vec. The realloc could invalidate that reference, which Rust prevents. Using Cell/RefCell also helps if you don't want to deeply nest &mut. Rust is definitely hard, but after a while it's fine and you kind of get how even if using another language you still have to think about memory.

Re: My negative views on Rust (2023)

#288

Post by School-Cotton »

tptacek wrote: post #283
School-Cotton wrote: post #271

Earlier quoted context omitted.

Java may be memory safe but it is not data race safe (unlike Rust, the compiler does not enforce cross-thread synchronization). So there is still a safety-related reason to use Rust over Java. That said, I don't really think Rust is a good choice for CRUD apps, because development velocity is more important than performance and they probably don't need to be multithreaded anyway. But Rust would have been great for a…

I feel like I've had this debate many, many times, and it always ends in the same place: I'm willing to concede that there are a subset of correctness/reliability bugs that Rust's error handling and type system mitigate, but not that any of those bugs are material to security, which is what most people are talking about when the discussion turns to memory safety. And, of course, Rust admits concurrency bugs too! We j…

I didn’t think we were having a debate. You insinuated that Rust isn’t ideal for CRUD apps, and I agreed with you.

Re: My negative views on Rust (2023)

#289

Post by tptacek »

School-Cotton wrote: post #288
tptacek wrote: post #283

Earlier quoted context omitted.

I feel like I've had this debate many, many times, and it always ends in the same place: I'm willing to concede that there are a subset of correctness/reliability bugs that Rust's error handling and type system mitigate, but not that any of those bugs are material to security, which is what most people are talking about when the discussion turns to memory safety. And, of course, Rust admits concurrency bugs too! We j…

I didn’t think we were having a debate. You insinuated that Rust isn’t ideal for CRUD apps, and I agreed with you.

"Debate" was too confrontational a word, sorry about that.

Re: My negative views on Rust (2023)

#290

Post by pjmlp »

dartos wrote: post #279
pjmlp wrote: post #265

Earlier quoted context omitted.

ISO Rationales and papers.

Yeah I’m sure they exist, but googling “C++ ISO Rationales” doesn’t give me them. Searching for “Rust RFCs” reveals a git repo with thousands of markdown files describing features and their motivations with links to discussions.

Because ISO processes are only open to those in the know.

Same applies to Ada, C, Modula-2, Pascal, Fortran, Algol, Cobol,.....

Post reply on HN