20 ms·

My negative views on Rust (2023)

192 points by rc00 2y ago

henning 2y ago
> 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 "never" make a difference is not helpful. There are a lot of shitty apps that are impossible to get running reasonably without a total rewrite and their shitty use of memory is part of that.
- andrepd 2y ago
  Thinking like that is how we get 12MB of javascript to read a news article, or mobile apps that are jankier than Word 97. I don't get how someone can criticise a systems programming language by saying "I have to think about memory layout"....
  - bachmeier 2y ago
    There's a response to your comment in the post: > I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. > This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for. > This post still offends many who have tied Rust to their identity, but that’s their problem, not mine.
    - mwcampbell 2y ago
      I think maybe the GP's point is that we should use systems languages, with their focus on efficiency, for things that the OP defines as out of scope, as an antidote to the creeping software bloat that we all like to complain about from time to time. And let's not forget that Word 97 felt bloated in its day, however fondly we may look back on it now.
- hyperbrainer 2y ago
  Criticising a systems programming language for needing to manually manage memory is honestly embarrassing.
  - IgorPartola 2y ago
    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.
    - hyperbrainer 2y ago
      The two are not mutually exclusive. Also, I don't think I have ever needed to actively think about memory management more than .clone() and static for any hobby project I have undertaken. All the ML-like features like sum types, pattern matching etc. add great value. Cargo too. So, it is a great general purpose programming language. But blaming it as too low-level or similar despite choosing it is obtuse at best.
    - keybored 2y ago
      A lot of git(1) subcommands were originally written in shell or Perl. Now most are written in C. Through many decades people wrote utilities and applications in C. Not hardcore lower-level kernel modules. Just utilities and applications. Because that’s what they wanted to write them in. Over Perl or Java or whatever else the alternatives were. What’s more C than that? Writing everything short of scripts in it? Now people write applications in a modern programming language with modern affordances. They might be working uphill to a degree but they could have chosen much less ergonomic options. The embarrassing part is criticizing people who have put in the work, not on the merits of their work, but on… having put in too much work.
- tptacek 2y ago
  The subtext is that most of the time it won't make a difference, and Rust demands that you consider it every of the time. That squares with my experience. The powerful argument Rust has is that in the hotspots where memory lifecycle and layout make a huge difference to programs, it's much easier to express the fast and predictable memory arrangement than in GC'd languages.
DiabloD3 2y ago
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 (Haskell). It's a weird, yet short, essay that doesn't actually go anywhere. I suspect Chris wrote the essay against their will, or because people asking them about Rust rubbed them the wrong way, because they lash out and say "This post still offends many who have tied Rust to their identity, but that’s their problem, not mine." Its the Internet, man, if you're not offending someone, nobody is reading your shit.
- tedk-42 2y ago
  Surely someone who writes a lot of C code as he mentions has written it for hardware, no?
  - DiabloD3 2y ago
    Take a gander at the rest of that blog, they're a Haskell main.
- Minor49er 2y ago
  Chris is a team of people? I thought he was just one developer
  - mappu 2y ago
    If you re-read the sentence with s/Chris/The Author/ I expect you'll find the pronoun cromulent. "They" was exclusively plural in Middle English in the 1300s, but, we're not speaking Middle English.
  - Narishma 2y ago
    What makes you think they're a team?
hyperbrainer 2y ago
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. I wonder when we will see the rise of Haskell like LanguageExtensions in Rust. AFAIK, pretty much everybody uses things like GADT, PolyKinds, OverloadedStrings etc. The most similar thing I can think of Rust right now for is python-like decorator application of things like builder macros using Bon. > Async is highly problematic Agreed. Tokyo is the only reason, I think, anybody is able to use Rust for this stuff.
- tptacek 2y ago
  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.
  - cmrdporcupine 2y ago
    Sure, Rc/Arc absolutely solves this problem. It's not super idiomatic to go crazy with using it like that, but it's possible/acceptable. Using SlotMap and integer ids, etc. doesn't I think offer any advantage.
    - tptacek 2y ago
      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).
      - cmrdporcupine 2y ago
IshKebab 2y ago
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 fewer bugs. > I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement. Maybe, but I think this is missing the point. The "rewrote it in Rust and it's X times faster" stories are generally when people rewrite from very slow (Python) or medium fast languages (JavaScript or maybe even Go). In those cases you can rewrite in Rust without considering performance and get amazing speedups. I recently did a straight 1:1 port of some Python code with zero extra optimisation effort and got a 45x speedup. Sure I maybe could have got the same in C or C++ but there's no way I would have rewritten it in C++ because fuck segfaults and UB. I don't want to spend any more of my life debugging that. > Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest. I don't really know about Haskell, but I don't think Rust's complexity is anywhere close to as bad as C++'s. Even if it were it doesn't matter because in Rust if you forget some complex rule the compiler will tell you, whereas in C++ it will randomly crash but only in release mode after the program has been running for 2 hours. Totally different. > The “Friendly” Community Gotta agree with this though. The "we're friendly" thing is bullshit. > Async is highly problematic Also agree here. Async is a huge wart on Rust's otherwise relatively unblemished face. Big shame. Oh well. You can mostly avoid it, and there are some cases where it's genuinely good (e.g. Embassy). > I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. > > This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for. I don't see why he's disappointed about this. Rust is great for command line tools and web backends. > I think that the excellent tooling and dev team for Rust, subsidized by Big Tech, pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in. There’s danger in that type of thinking. Ok this guy is not worth listening to.
- VeejayRampay 2y ago
VeejayRampay 2y ago
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
- brink 2y ago
  > 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.
  - rastignack 2y ago
    > 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.
  - timeon 2y ago
    > At this point, people whining about Rust is more of a trope than people proselytizing it. This is common pattern reminds me cross-fit/veganism/i-use-arch/etc. Almost like an echo.
  - mrkeen 2y ago
    > 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. It's the opposite for me. I would put more effort into Rust, but I'm not going to invest in learning how to write safe rust if my libraries are built on unsafe.
lll-o-lll 2y ago
> People waste time on trivialities that will never make a difference. This is an aha moment as I read it. The complexity of your tools must be paid back by the value they give to the business you’re in.
- IgorPartola 2y ago
  [flagged]
- johnnyanmac 2y ago
  Really depends on the "difference". If a male a container crate that is Fer from shippable but gives me knowledge to land a Rust gig, was it a triviality?
- ilrwbwrkhv 2y ago
  This is daft logic. Your business itself has no value in the modern world. Your todo saas app is not needed. Of course this argument is faulty, so going one step back, what is valuable is in the eyes of the hacker. For a lot of people, including mine, the triviality is also part of the value chain.
Animats 2y ago
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.
- deleted 2y ago
  [deleted]
- Ygg2 2y ago
  > My big problem with Rust is too much "unsafe" code. I hear cargo-geiger is useful identifying such crates. > I just do not see why people seem to use "unsafe" so much. Because it's: A) fast (branchless access) B) fast (calling C libs or assembly) C) fast (SIMD) D) people think unsafe Rust is easier Want to write a JSON parser that will gobble up gigabytes per second? Your only way is removing as many branches and use assembly as much as possible. Doubly so on stable! I guess the same goes for making a "blazingly fast"™ graphical stack. People that think unsafe is easier, shouldn't be writing unsafe code. Writing unsafe code correctly is like juggling burning chainsaws. Saying that's easier than using chainsaws is moronic at best. EDIT: Consider following, if each of your unsafe {} blocks doesn't contain a // SAFETY: // Detailed explanation of invariants One of the chainsaws just cut off your leg.
  - johnnyanmac 2y ago
    >people think unsafe Rust is easier If that's their line of thought, I don't know why they simply don't use C/++. Or even C# with unsafe blocks. I know you said the same, but I wanted to reiterate that. But yes, I can see a few very specific cases where unsafe access is needed. Emphasis on "few". I think anything past some fundamentals should be at best a late optimizing step after an MVP is established. I also think, if it's not already there, that crates should be able to identify if it's "safe" or "unsafe". Same mentality where I'd probably want to rely on safe crates until I need to optimize a sector and then look into blazing fast but unsafe crates.
egnehots 2y ago
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-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s.... They are many projects for which the reliability and efficiency are worth the trouble.
dvektor 2y ago
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.
- tptacek 2y ago
  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.
  - DiabloD3 2y ago
    "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 those languages); if a language gets that right, they're going to get everything else right too if people decided to use it for that.
    - tptacek 2y ago
      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 is no one ur-language that is optimal for every problem domain!
dang 2y ago
Related: My negative views on Rust - https://news.ycombinator.com/item?id=29659056 https://news.ycombinator.com/item?id=29659056 - Dec 2021 (89 comments)
School-Cotton 2y ago
> Distinguishing mutability has its advantages I think it's misleading to say that Rust distinguishes mutability. It distinguishes _exclusivity_. If you hold a reference to something, you are guaranteed that nothing else holds an exclusive reference to it (which is spelled &mut). You are _not_ guaranteed that nothing accessible through that reference can change (for example, it might contain a RefCell or other interior-mutable type). Shared references (spelled &) usually imply immutability, but not always. On the other hand, if you hold an exclusive reference to something, you are guaranteed that nothing, anywhere, holds any kind of reference to it. IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with.
- beeflet 2y ago
  >IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with. You couldn't just roll out a change like alias &e to &mut and &s to &, and then have a compiler warning for using the old &mut or &?
  - School-Cotton 2y ago
    That’s technically possible, yes, but I really doubt there is any appetite to change basic syntax like that when it’s already so ingrained in everyone’s mind.
jkelleyrtp 2y ago
"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 Copy, Drop, Deref for you: it would be really annoying to write Rust if you had to call `.copy()` on every bool/int/char. A language like this exists, I'm sure, but this hasn't stopped Rust from taking off - 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 - Rewrite anything and it gets faster: okay sure, but there are limits to how fast I can make a Py/JS algorithm vs a compiled language, and Rust makes writing compiled code a bit easier. People probably aren't rewriting slow Python projects in C these days - Rust is as complex as C++: ...no, it's not. Rust really hasn't changed much in the past 6 years. A few limitations being lifted, but nothing majorly new. - Rust isn't as nice of community as people think: subjective maybe? People are nice to me at conferences and in discussion rooms. There's occasional drama here and there but overall it's been pretty quiet for the past year. - Async is problematic: Async Rust really is fine. There's a huge meme about how bad it is, but really, it's fine. As a framework author, it's great, actually. I can wrap futures in a custom Poll. I can drive executors from a window event loop. Tokio's default choice of making `spawn` take Send/Sync futures is an odd one - occasionally cryptic compile errors - but you don't need to use that default. I'm unsure why this article is so upvoted given how vapid the content is, but it does have a snappy title, I guess.
- s17n 2y ago
  > 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.
  - jkelleyrtp 2y ago
lacker 2y ago
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.
- pjmlp 2y ago
  Still a non starter in many industries, other than for those that enjoy building ecosystems from scratch.
rich_sasha 2y ago
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.
- throwawaymaths 2y ago
  I think in general python gets used because of laziness and vitality. It's just the dumb shit that X person learned first because Y person before then was taught it because it was easy even though it's maybe not even the right choice for example, you can't properly write a working webserver in python without {venv, uvicorn, celery etc.} and if youve ever worked in another language its like why the hell is this shit here? Because it's viral, someone didn't know better, and it stuck. Same goes for machine learning. The ML folks at the start couldn't be bothered to learn something the least bit sophisticated. Some things are getting better. You don't need conda anymore, tensorflow wheels are out, and at least instead of shippong around .pt, checkpoint, or pickle files at least we use safetensors, but there's still python shit around, like jinja2 templates for conversations, etc. Anyways if we want good things we need to get better about getting unstuck from these local minima.
  - rich_sasha 2y ago
    I disagree re Python. It is a brilliant, flexible scripting language. It is easy to build expressive libraries such as pytest or argparse, with deep introspection. It is easy to prototype by subtly changing return types, or even keeping them flexible. It is really easy to eg build a custom data type and build custom expression trees, such as what ML often needs. It has a number of features (often stemming from the above) that make it a PITA for other applications, even when it would be fairly well suited to them otherwise. What I would give for proper static typing for production Python! Alas, that's not coming, and Rust's occasionally mind boggling borrow checker is there to stay.
MuffinFlavored 2y ago
Who uses panic instead of `?` and anyhow / Box<dyn Error> (error propagation?) I think there is even a (gross) way to achieve try/catch around a block of code that panics?
- pshc 2y ago
  Yeah, panic/assert is only for Things That Really Shouldn’t Ever Fail, If They Do Our Base Assumptions Have Broken. whereas Error is for things that are unlikely to fail, like network/filesystem requests and recoverable logic bugs.
jeffreyrogers 2y ago
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.
pcwalton 2y ago
I 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.
- tptacek 2y ago
  Just so we're clear, your reference points for "good for high-level application code" are systems code and game engines? :)
  - pcwalton 2y ago
    Games themselves, not game engines. Systems code, game engines, and games. This isn't meant to be an exhaustive list--it's just the domains I have experience with that Rust was a good fit for. Lest it seem like I'm saying Rust is a good fit for everything I've done, I also worked on Firefox where the UI was JavaScript, and I wouldn't hurry to rewrite that code in Rust. Nor would I want the throwaway stuff I write in Python or Ruby to be Rust.
    - tptacek 2y ago
      I'm just saying, games are exactly one of the things I would assume Rust would be a natural fit for. :)
      - hollerith 2y ago
        >Rust would be a natural fit for Did you leave out a "not" here?
drogus 2y ago
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 new concept?
- senorrib 2y ago
  Generics is hardly a major paradigm shift, and these two languages are worlds apart in amount of features.
  - drogus 2y ago
    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.
- ilrwbwrkhv 2y ago
  Ya the article is a bit fluffy and insubstantial. Surprising it's been voted up so highly on HN. Are people just going off the title?
- kunley 2y ago
  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
  - drogus 2y ago
    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?
indulona 2y ago
i could buy an alphabet soup, add in some cereals, mix it up and throw it on the table, knowing it would end up looking indistinguishable from rust code.
- deleted 2y ago
  [deleted]
sebastos 2y ago
"X is as complex as C++" is a preposterous statement for all values of X. A lot of people seem to assume that "C++ is complex" is referring to how the committee adds new language features every 3 years. The conventional wisdom that C++ is wickedly difficult to learn is NOT about "oh man, now I need to learn about the spaceship operator?" C++ is an almost unfathomably bottomless pit. From the arcane template metaprogramming system to the sprawling byzantine rules that govern what members a compiler auto-generates for you, and on to the insane mapping between "what this keyword was originally introduced for" and "what it actually means here in _this_ context, there is no end to it. Keeping up with new language syntax features is an absolute drop in the bucket compared to the inherent complexity required to understand a C++11 codebase, build it (with a completely separate tool that you must choose) and manage its dependencies (with a yet different completely separate tool that you must choose). You don't have to know anything about Rust to know that saying "Rust has become complex as C++" is objectively incorrect.
- christianqchung 2y ago
  Yeah, but in 12 years when reflection is in the language and is widely used, people will probably have to deal with a significantly increased amount of weirdness as a result of that feature. Though all that's to say the complexity gap between rust and C++ is only going to go up.
- pjmlp 2y ago
  Depends, how much from unstable Rust ends up in Rust during the next 30 years, to match where C++ is today after 40 years of production deployments across the industry.

192 points by rc00 2y ago

> 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 "never" make a difference is not helpful. There are a lot of shitty apps that are impossible to get running reasonably without a total rewrite and their shitty use of memory is part of that.

andrepd 2y ago
Thinking like that is how we get 12MB of javascript to read a news article, or mobile apps that are jankier than Word 97. I don't get how someone can criticise a systems programming language by saying "I have to think about memory layout"....
- bachmeier 2y ago
  There's a response to your comment in the post: > I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. > This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for. > This post still offends many who have tied Rust to their identity, but that’s their problem, not mine.
  - mwcampbell 2y ago
    I think maybe the GP's point is that we should use systems languages, with their focus on efficiency, for things that the OP defines as out of scope, as an antidote to the creeping software bloat that we all like to complain about from time to time. And let's not forget that Word 97 felt bloated in its day, however fondly we may look back on it now.
hyperbrainer 2y ago
Criticising a systems programming language for needing to manually manage memory is honestly embarrassing.
- IgorPartola 2y ago
  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.
  - hyperbrainer 2y ago
    The two are not mutually exclusive. Also, I don't think I have ever needed to actively think about memory management more than .clone() and static for any hobby project I have undertaken. All the ML-like features like sum types, pattern matching etc. add great value. Cargo too. So, it is a great general purpose programming language. But blaming it as too low-level or similar despite choosing it is obtuse at best.
  - keybored 2y ago
    A lot of git(1) subcommands were originally written in shell or Perl. Now most are written in C. Through many decades people wrote utilities and applications in C. Not hardcore lower-level kernel modules. Just utilities and applications. Because that’s what they wanted to write them in. Over Perl or Java or whatever else the alternatives were. What’s more C than that? Writing everything short of scripts in it? Now people write applications in a modern programming language with modern affordances. They might be working uphill to a degree but they could have chosen much less ergonomic options. The embarrassing part is criticizing people who have put in the work, not on the merits of their work, but on… having put in too much work.
tptacek 2y ago
The subtext is that most of the time it won't make a difference, and Rust demands that you consider it every of the time. That squares with my experience. The powerful argument Rust has is that in the hotspots where memory lifecycle and layout make a huge difference to programs, it's much easier to express the fast and predictable memory arrangement than in GC'd languages.

DiabloD3 2y ago

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 (Haskell). It's a weird, yet short, essay that doesn't actually go anywhere. I suspect Chris wrote the essay against their will, or because people asking them about Rust rubbed them the wrong way, because they lash out and say "This post still offends many who have tied Rust to their identity, but that’s their problem, not mine." Its the Internet, man, if you're not offending someone, nobody is reading your shit.

tedk-42 2y ago
Surely someone who writes a lot of C code as he mentions has written it for hardware, no?
- DiabloD3 2y ago
  Take a gander at the rest of that blog, they're a Haskell main.
Minor49er 2y ago
Chris is a team of people? I thought he was just one developer
- mappu 2y ago
  If you re-read the sentence with s/Chris/The Author/ I expect you'll find the pronoun cromulent. "They" was exclusively plural in Middle English in the 1300s, but, we're not speaking Middle English.
- Narishma 2y ago
  What makes you think they're a team?

hyperbrainer 2y ago

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. I wonder when we will see the rise of Haskell like LanguageExtensions in Rust. AFAIK, pretty much everybody uses things like GADT, PolyKinds, OverloadedStrings etc. The most similar thing I can think of Rust right now for is python-like decorator application of things like builder macros using Bon. > Async is highly problematic Agreed. Tokyo is the only reason, I think, anybody is able to use Rust for this stuff.

tptacek 2y ago
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.
- cmrdporcupine 2y ago
  Sure, Rc/Arc absolutely solves this problem. It's not super idiomatic to go crazy with using it like that, but it's possible/acceptable. Using SlotMap and integer ids, etc. doesn't I think offer any advantage.
  - tptacek 2y ago
    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).
    - cmrdporcupine 2y ago

IshKebab 2y ago

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 fewer bugs. > I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement. Maybe, but I think this is missing the point. The "rewrote it in Rust and it's X times faster" stories are generally when people rewrite from very slow (Python) or medium fast languages (JavaScript or maybe even Go). In those cases you can rewrite in Rust without considering performance and get amazing speedups. I recently did a straight 1:1 port of some Python code with zero extra optimisation effort and got a 45x speedup. Sure I maybe could have got the same in C or C++ but there's no way I would have rewritten it in C++ because fuck segfaults and UB. I don't want to spend any more of my life debugging that. > Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest. I don't really know about Haskell, but I don't think Rust's complexity is anywhere close to as bad as C++'s. Even if it were it doesn't matter because in Rust if you forget some complex rule the compiler will tell you, whereas in C++ it will randomly crash but only in release mode after the program has been running for 2 hours. Totally different. > The “Friendly” Community Gotta agree with this though. The "we're friendly" thing is bullshit. > Async is highly problematic Also agree here. Async is a huge wart on Rust's otherwise relatively unblemished face. Big shame. Oh well. You can mostly avoid it, and there are some cases where it's genuinely good (e.g. Embassy). > I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. > > This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for. I don't see why he's disappointed about this. Rust is great for command line tools and web backends. > I think that the excellent tooling and dev team for Rust, subsidized by Big Tech, pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in. There’s danger in that type of thinking. Ok this guy is not worth listening to.

VeejayRampay 2y ago

VeejayRampay 2y ago

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

brink 2y ago
> 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.
- rastignack 2y ago
  > 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.
- timeon 2y ago
  > At this point, people whining about Rust is more of a trope than people proselytizing it. This is common pattern reminds me cross-fit/veganism/i-use-arch/etc. Almost like an echo.
- mrkeen 2y ago
  > 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. It's the opposite for me. I would put more effort into Rust, but I'm not going to invest in learning how to write safe rust if my libraries are built on unsafe.

lll-o-lll 2y ago

> People waste time on trivialities that will never make a difference. This is an aha moment as I read it. The complexity of your tools must be paid back by the value they give to the business you’re in.

IgorPartola 2y ago
[flagged]
johnnyanmac 2y ago
Really depends on the "difference". If a male a container crate that is Fer from shippable but gives me knowledge to land a Rust gig, was it a triviality?
ilrwbwrkhv 2y ago
This is daft logic. Your business itself has no value in the modern world. Your todo saas app is not needed. Of course this argument is faulty, so going one step back, what is valuable is in the eyes of the hacker. For a lot of people, including mine, the triviality is also part of the value chain.

Animats 2y ago

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.

deleted 2y ago
[deleted]
Ygg2 2y ago
> My big problem with Rust is too much "unsafe" code. I hear cargo-geiger is useful identifying such crates. > I just do not see why people seem to use "unsafe" so much. Because it's: A) fast (branchless access) B) fast (calling C libs or assembly) C) fast (SIMD) D) people think unsafe Rust is easier Want to write a JSON parser that will gobble up gigabytes per second? Your only way is removing as many branches and use assembly as much as possible. Doubly so on stable! I guess the same goes for making a "blazingly fast"™ graphical stack. People that think unsafe is easier, shouldn't be writing unsafe code. Writing unsafe code correctly is like juggling burning chainsaws. Saying that's easier than using chainsaws is moronic at best. EDIT: Consider following, if each of your unsafe {} blocks doesn't contain a // SAFETY: // Detailed explanation of invariants One of the chainsaws just cut off your leg.
- johnnyanmac 2y ago
  >people think unsafe Rust is easier If that's their line of thought, I don't know why they simply don't use C/++. Or even C# with unsafe blocks. I know you said the same, but I wanted to reiterate that. But yes, I can see a few very specific cases where unsafe access is needed. Emphasis on "few". I think anything past some fundamentals should be at best a late optimizing step after an MVP is established. I also think, if it's not already there, that crates should be able to identify if it's "safe" or "unsafe". Same mentality where I'd probably want to rely on safe crates until I need to optimize a sector and then look into blazing fast but unsafe crates.

egnehots 2y ago

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-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s.... They are many projects for which the reliability and efficiency are worth the trouble.

dvektor 2y ago

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.

tptacek 2y ago
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.
- DiabloD3 2y ago
  "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 those languages); if a language gets that right, they're going to get everything else right too if people decided to use it for that.
  - tptacek 2y ago
    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 is no one ur-language that is optimal for every problem domain!

dang 2y ago

Related: My negative views on Rust - https://news.ycombinator.com/item?id=29659056 https://news.ycombinator.com/item?id=29659056 - Dec 2021 (89 comments)

School-Cotton 2y ago

> Distinguishing mutability has its advantages I think it's misleading to say that Rust distinguishes mutability. It distinguishes _exclusivity_. If you hold a reference to something, you are guaranteed that nothing else holds an exclusive reference to it (which is spelled &mut). You are _not_ guaranteed that nothing accessible through that reference can change (for example, it might contain a RefCell or other interior-mutable type). Shared references (spelled &) usually imply immutability, but not always. On the other hand, if you hold an exclusive reference to something, you are guaranteed that nothing, anywhere, holds any kind of reference to it. IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with.

beeflet 2y ago
>IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with. You couldn't just roll out a change like alias &e to &mut and &s to &, and then have a compiler warning for using the old &mut or &?
- School-Cotton 2y ago
  That’s technically possible, yes, but I really doubt there is any appetite to change basic syntax like that when it’s already so ingrained in everyone’s mind.

jkelleyrtp 2y ago

"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 Copy, Drop, Deref for you: it would be really annoying to write Rust if you had to call `.copy()` on every bool/int/char. A language like this exists, I'm sure, but this hasn't stopped Rust from taking off - 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 - Rewrite anything and it gets faster: okay sure, but there are limits to how fast I can make a Py/JS algorithm vs a compiled language, and Rust makes writing compiled code a bit easier. People probably aren't rewriting slow Python projects in C these days - Rust is as complex as C++: ...no, it's not. Rust really hasn't changed much in the past 6 years. A few limitations being lifted, but nothing majorly new. - Rust isn't as nice of community as people think: subjective maybe? People are nice to me at conferences and in discussion rooms. There's occasional drama here and there but overall it's been pretty quiet for the past year. - Async is problematic: Async Rust really is fine. There's a huge meme about how bad it is, but really, it's fine. As a framework author, it's great, actually. I can wrap futures in a custom Poll. I can drive executors from a window event loop. Tokio's default choice of making `spawn` take Send/Sync futures is an odd one - occasionally cryptic compile errors - but you don't need to use that default. I'm unsure why this article is so upvoted given how vapid the content is, but it does have a snappy title, I guess.

s17n 2y ago
> 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.
- jkelleyrtp 2y ago

lacker 2y ago

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.

pjmlp 2y ago
Still a non starter in many industries, other than for those that enjoy building ecosystems from scratch.

rich_sasha 2y ago

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.

throwawaymaths 2y ago
I think in general python gets used because of laziness and vitality. It's just the dumb shit that X person learned first because Y person before then was taught it because it was easy even though it's maybe not even the right choice for example, you can't properly write a working webserver in python without {venv, uvicorn, celery etc.} and if youve ever worked in another language its like why the hell is this shit here? Because it's viral, someone didn't know better, and it stuck. Same goes for machine learning. The ML folks at the start couldn't be bothered to learn something the least bit sophisticated. Some things are getting better. You don't need conda anymore, tensorflow wheels are out, and at least instead of shippong around .pt, checkpoint, or pickle files at least we use safetensors, but there's still python shit around, like jinja2 templates for conversations, etc. Anyways if we want good things we need to get better about getting unstuck from these local minima.
- rich_sasha 2y ago
  I disagree re Python. It is a brilliant, flexible scripting language. It is easy to build expressive libraries such as pytest or argparse, with deep introspection. It is easy to prototype by subtly changing return types, or even keeping them flexible. It is really easy to eg build a custom data type and build custom expression trees, such as what ML often needs. It has a number of features (often stemming from the above) that make it a PITA for other applications, even when it would be fairly well suited to them otherwise. What I would give for proper static typing for production Python! Alas, that's not coming, and Rust's occasionally mind boggling borrow checker is there to stay.

MuffinFlavored 2y ago

Who uses panic instead of `?` and anyhow / Box<dyn Error> (error propagation?) I think there is even a (gross) way to achieve try/catch around a block of code that panics?

pshc 2y ago
Yeah, panic/assert is only for Things That Really Shouldn’t Ever Fail, If They Do Our Base Assumptions Have Broken. whereas Error is for things that are unlikely to fail, like network/filesystem requests and recoverable logic bugs.

jeffreyrogers 2y ago

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.

pcwalton 2y ago

I 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.

tptacek 2y ago
Just so we're clear, your reference points for "good for high-level application code" are systems code and game engines? :)
- pcwalton 2y ago
  Games themselves, not game engines. Systems code, game engines, and games. This isn't meant to be an exhaustive list--it's just the domains I have experience with that Rust was a good fit for. Lest it seem like I'm saying Rust is a good fit for everything I've done, I also worked on Firefox where the UI was JavaScript, and I wouldn't hurry to rewrite that code in Rust. Nor would I want the throwaway stuff I write in Python or Ruby to be Rust.
  - tptacek 2y ago
    I'm just saying, games are exactly one of the things I would assume Rust would be a natural fit for. :)
    - hollerith 2y ago
      >Rust would be a natural fit for Did you leave out a "not" here?

drogus 2y ago

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

senorrib 2y ago
Generics is hardly a major paradigm shift, and these two languages are worlds apart in amount of features.
- drogus 2y ago
  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.
ilrwbwrkhv 2y ago
Ya the article is a bit fluffy and insubstantial. Surprising it's been voted up so highly on HN. Are people just going off the title?
kunley 2y ago
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
- drogus 2y ago
  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?

indulona 2y ago

i could buy an alphabet soup, add in some cereals, mix it up and throw it on the table, knowing it would end up looking indistinguishable from rust code.

deleted 2y ago
[deleted]

sebastos 2y ago

"X is as complex as C++" is a preposterous statement for all values of X. A lot of people seem to assume that "C++ is complex" is referring to how the committee adds new language features every 3 years. The conventional wisdom that C++ is wickedly difficult to learn is NOT about "oh man, now I need to learn about the spaceship operator?" C++ is an almost unfathomably bottomless pit. From the arcane template metaprogramming system to the sprawling byzantine rules that govern what members a compiler auto-generates for you, and on to the insane mapping between "what this keyword was originally introduced for" and "what it actually means here in _this_ context, there is no end to it. Keeping up with new language syntax features is an absolute drop in the bucket compared to the inherent complexity required to understand a C++11 codebase, build it (with a completely separate tool that you must choose) and manage its dependencies (with a yet different completely separate tool that you must choose). You don't have to know anything about Rust to know that saying "Rust has become complex as C++" is objectively incorrect.

christianqchung 2y ago
Yeah, but in 12 years when reflection is in the language and is widely used, people will probably have to deal with a significantly increased amount of weirdness as a result of that feature. Though all that's to say the complexity gap between rust and C++ is only going to go up.
pjmlp 2y ago
Depends, how much from unstable Rust ends up in Rust during the next 30 years, to match where C++ is today after 40 years of production deployments across the industry.