I learned to program around the peak of object oriented fetishization. Shortly after that came functional programming's moment, and now it seems we are slightly past Rust and other safety focused languages' peak period of hype. All three language families have useful things to offer, but were never the panacea their proponents claimed them to be. "No Silver Bullet" continues to be true.
My negative views on Rust (2023)
101–110 of 308 posts
Re: My negative views on Rust (2023)
#102Earlier quoted context omitted.
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.
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 problems just don't grok Rust well enough. That's a common trope, and it's pretty obviously false, just as it would be false to say that kernels should just supply a GC runtime so we can write device drivers in Java.
Re: My negative views on Rust (2023)
#103I actually used to agree that Rust generally wasn't good for high-level application code, but working with Bevy has made me change that opinion for certain domains. I simply haven't seen a system that makes automatically parallelizing all application logic (game logic, in this case) feasible, other than Bevy and other Rust-based systems. The trick is that the borrow check gives the scheduler enough information to automatically safely determine which systems can run in parallel, and that's very powerful. It's not that you couldn't do this in C# or whatever--it's that you won't without a system that helps express your intent and enforces that those declarations are up to date.
For applications that don't need high performance for the CPU code and aren't systems code, sure, Rust may not be a good choice. I'm not writing the server-side code for low traffic Web sites in Rust either.
Re: My negative views on Rust (2023)
#104Earlier quoted context omitted.
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…
What does "think about your memory layout" mean? Can you provide an example? I've seen this brought up a few times on this thread and have no idea what people are referring to when they say it. As for the rest of your list - I'm not sure why rust is special in regards to "the specific time you grab and release resources" or "inter-thread interactions". Seriously - I have to think about when I acquire and release reso…
Again, the subtext here is GC versus direct control of memory lifecycles, and it is probably not reasonable to argue that there isn't a tradeoff here --- that every application is as gracefully expressible in one as the other, so long as you "git gud" at it. Both sides of this debate are guilty of deploying that trope.
Re: My negative views on Rust (2023)
#105Earlier quoted context omitted.
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…
Yeah I use often Rust where Python would be enough. But unless I really need quick/interactive feedback (for exploratory stuff ie.: Jupyter with plots), Rust suits me well.
I enjoy expressing applications in C. Once a week, a story hits the front page here about someone shipping a web app in C. C suits me well. But I don't pretend that's an objectively reasonable engineering decision. It is not.
Re: My negative views on Rust (2023)
#106Earlier quoted context omitted.
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.
In what way am I "out of luck"? It's trivial to express a tree, including one with backlinks, in Java.
Re: My negative views on Rust (2023)
#107Earlier quoted context omitted.
I feel pretty comfortable with Rc and Arc, read the "too many lists" book, &c. and feel like it is not actually simple to model trees with Rc? What am I missing? I'd love to be convinced I'm wrong about this (I want to like Rust more than I do).
A tree of Rc/Arc is a tree of references, and is really no different than a Java or Python reference value, except that you'll have to do explicit .clone()s Is it mutability that's tripping you up? Because that's the only gotcha I can think of. Yes, you won't get mutability of the content of those references unless you stick a RefCell or a Mutex inside them.
Yes! Mutability is what's tripping me up! That is not a minor detail!
Re: My negative views on Rust (2023)
#108Earlier quoted context omitted.
> 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 th…
>> 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 Hmm.. wasn't memory safety the main selling point for rust? If not the only. Now mix of two languages looks even worst than one complex. Especially taking into account that it can be paired with safe language from long list. Don't know what rust fans…
Memory safety without gc is not the only reason people use rust. It's also nicer to use than C++ for multiple reasons (language features, included package manager, easy to integrate tests...)
Re: My negative views on Rust (2023)
#109Earlier quoted context omitted.
> 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 th…
Non-trivial data structures are often just a bunch of arrays/maps with additional semantics. You may consider implementing/using unchecked versions of basic operations for a little bit of additional performance. If you implement (de)serialization yourself, you may need unsafe code. Sometimes the safety of deserialization may be a convenient lie, if checking the invariants fully would be too expensive. And sometimes y…
> Non-trivial data structures are often just a bunch of arrays/maps with additional semantics
This might be fine for code which consumes data structures implemented by other people. The approach is not good when you actually need to implement data structures in your program.
In modern world this is especially bad for a low-level language (marketed as high performance, BTW) because the gap between memory latency and compute performance is now huge. You do need efficient data structures, which often implies developing custom ones for specific use cases. This is required to saturate CPU cores as opposed to stalling on RAM latency while chasing pointers, or on cache coherency protocol while incrementing/decrementing reference counters from multiple CPU cores.
Interestingly, neither C++ nor C# has that boundary, for different reasons: C++ is completely unsafe, and safe C# supports almost all data structures (except really weird ones like XOR linked lists) because GC.
Re: My negative views on Rust (2023)
#110Earlier quoted context omitted.
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?
The title is inflammatory and yet there are few nuanced takes in the article. It's weird to see it shoot to the top of HN. I think the loglog article is a much better, nuanced, full critique of Rust. https://loglog.games/blog/leaving-rust-gamedev/ The internet is just so full of negativity these days. People upvote titles but don't read articles. Reading about people's views on subjects is useful, but I don't think t…
Inflammatory? "My Negative Views on X" is pretty far from inflammatory. It is exactly what the post was, with some positivity sprinkled in as well.