It's still bizarre though that Rust is capturing such ridiculous mindshare. I suspect it has a lot to do with web developers being plugged into Mozilla, and Mozilla spending quite a lot on Rust development and marketing. And Zig may be being roped into it. It seems to be a temporary low-level programming zeitgeist driven by YouTube and Reddit recommendation algorithms to an audience that has never done it and probably never will.
> It's still bizarre though that Rust is capturing such ridiculous mindshare.
I don't think it's that bizarre. The two big headline features that bring Rust such popularity are: #1 "70% of bugs are memory-safety bugs" [1] and Rust can help solve those, and #2 C/C++ have a couple of package manager solutions - none of which have critical mass and Rust "comes with" cargo.
Those two make me really eager to continue experimenting with Rust.
> It seems to be a temporary low-level programming zeitgeist driven by YouTube and Reddit recommendation algorithms to an audience that has never done it and probably never will.
This is some weird gatekeep-y kinda thing. Most of us didn't start out with low-level programming. Wouldn't it have been odd and frustrating for someone to tell your younger self that you have "never written C and probably never will"?
> This is some weird gatekeep-y kinda thing. Most of us didn't start out with low-level programming. Wouldn't it have been odd and frustrating for someone to tell your younger self that you have "never written C and probably never will"?
I'm not making any sorts of demands about who should be able to program at a low level, but I'm being realistic about who will. I have an intuition that I do not think is unreasonable that the vast majority of the 20- to 30-something crowd that recently learned JavaScript in a boot camp would bounce off of systems programming hard, while a handful might discover it's what they should've been doing all along.
The young are not who I'm thinking of at all. Someone with time and neuroplasticity can and should be spending that time toying around with C, Haskell, and Lisp to expand their understanding as much as possible.
People bounce off of systems programming because C/C++ is hard. Rust's focus on ergonomics, error management, tooling and learning resources actually makes people want to try again.
Rust is the first low-level language that actually solves a fundamental problem of low-level programming. I don’t see why is it surprising that it gains weight.
Zig, while I appreciate many of its design goals and definitely has some novel ideas, is “just” a better C.
I think your comment can actually help me clarify what I meant. My perception is that there is a rift between what domains Rust is targeting versus what audience is actually hyped about Rust.
When I look to the C++ world and the embedded/realtime systems industry, what I see is lots of discussion about Carbon and herb Sutter's CppFront. I don't see as much Rust discussion.
When I look to the JavaScript/webdev/fullstack world, that is who I see discussing Rust; these are domains where GC languages, even those with lots of GC churn like Clojure, have already proven their utility. In the creator sphere, the same folks talking about JS frameworks are the ones covering Rust and, to a lesser extent, Zig.
As usual, the C world seems completely disinterested towards what is outside of it.
There is definitely a hype among programmers who are familiar only with higher level languages, but I think the actual core audience is the (ex-)C/C++ community. I am definitely not some integral part of the Rust community, so my experience there is limited, but based on discussions in for example their subreddit, it is definitely not made up of beginners who are just learning what a pointer is.
There are beginners, but I see mostly veteran embedded/systems programmers with very good understanding of both low-level systems and the advantages/disadvantages of C++ for example, making up for very technical and interesting comments.
Rust solves a problem for people who only know GC languages - performance. They see their developer tools rewritten in Rust to great success. Examples include ruff for Python, turborepo and turbo build for JS. These tools are worth adopting because they're much faster than what came before them. Therefore Rust is worth learning to build things where performance matters.
For C and C++ developers, the value prop isn't so clearly defined. Sure it's possible that Rust code they write might have fewer bugs. But if they think they're the sort of developer that doesn't write bugs, then what does Rust do for them? Just slows them down. I won't get into whether they're right or wrong to feel the way they do.
There's also an element of the former group being more open to learning and adopting new tools. The latter group is more likely to say "if it ain't broke, I don't need to learn a new thing".
Part of my purpose with my OP was pointing out that the limiting factor for performance is not GC. When developers are coming from JavaScript and Python, the dominating performance factors are interpreting and dynamic typing. For native-compiled GC languages like Nim, Go, and D, GC only becomes an issue when it interferes with deterministic runtime constraints (RC, bounded GC, and arena allocation fix this), or when the GC is subject to lots of allocations and enormous pressure (which Nim minimizes).
Which is why I find it weird that webdevs are hyped about Rust: They're using it in an enormous number of publicly distributed applications where a native-compiled GC language would be a clearly better long-term choice.
> Part of my purpose with my OP was pointing out that the limiting factor for performance is not GC.
Agree. Also agree that it’s possible to write performant software in the languages you mentioned.
> where a native-compiled GC language would be a clearly better long-term choice.
I don’t think this is the case, and I don’t think you’ve made the case for it. I think there’s some implicit assumption that the GC gives a better developer experience and that’s why it’s a better choice? In a vacuum maybe, but the dev ex in Rust is better than Nim for a number of reasons.
It’s easy to see if you’re right or they are. In 5 years I’m willing to bet that the tooling for the JS ecosystem is all written in Rust, Zig or Go. Nothing in Nim or D.
You might see that and think “oh, it’s because they made suboptimal choices”. I see it differently though.
If not having to clutter code with memory semantics isn’t enough of a case, I could gush about UFCS abrogating the need for interfaces, or Nimble and the dead-simple module and export system (and not needing to scatter ‘pub mod’ files all over the project), or the choice of any number of useful GCs or to forego GC, or the very quick compiler presenting very powerful, sensible options and making things like static linking trivially easy. This all blew my Rust experience out of the water.
But it’s ultimately an uphill battle. Nim has no marketing budget. It’s comparable to any language introduced in the 90s going up against Java. There is a zeitgeist of “cool” around Rust that means many tools will be written in it regardless of how much grassroots rooftop shouting anyone does about Nim. I think too many people assume we all live in a world of perfect information and rational decisions, but that just isn’t the case.
Yeah it’s entirely possible that some people pick what’s popular instead of what we think is theoretically optimal.
I would only caution you about assuming that people are following the zeitgeist instead of making sound technical decisions. For example there’s only one language that prevents race conditions at compile time. Maybe they write more multithreaded code than you did and really prize this feature.
Maybe they like the libraries that make the ecosystem rich. Does nim have anything as polished and performant as clap and serde? Maybe they like the generally high quality of documentation in the Rust ecosystem? I could point out several other legitimate axes on which Rust is a superior alternative.
It doesn’t matter, because you’re aware of most or all of these. What’s important is for you to avoid falling into the fallacy of “what’s popular must be bad, because the average person isn’t as smart as me”. Lots of smart people fall into this trap. It’s especially bad to fall into this when you’re thinking about platforms because the utility of a platform is directly proportional to its popularity.
Language X might have so many flaws, but if it’s popular then the community around it could find myriad ways to mitigate the flaws. They’ll release a million useful libraries that make our lives easier. And if the language gets 50% more popular, it gets 50% more useful to us because the ecosystem gets richer. Better ecosystem means more companies adopt it => more jobs available => it’s a sound choice to learn this language in your free time => more devs available with this skill => it's a good idea for more companies to adopt it. It’s a fly wheel of adoption. Java benefited from this, even if it wasn’t a perfect language. Rust benefits, but to a lesser extent because there’s so many good alternatives now (including Java!)
Even if Rust doesn’t do it for you in 2023, I’d counsel taking a look again in 2026. The growth around the language (80% per year in crate downloads, 30% per year in crate authors) means that it’s possible that you might find most of your pet peeves might have been addressed by then. Either in the main language or in a library.
>Does nim have anything as polished and performant as clap and serde?
"Polished" and "high quality" are more subjective/implicitly about adoption, IMO. "Performant" has many dimensions. That said, I just tested the Nim https://github.com/c-blake/cligen vs clap: cligen used 5X less object file space (with all size optimization tweaks enabled in both), 20% less run-time memory for large argument lists, and the same run-time per argument (with march=native equivalents on both, within statistical noise). cligen has many features - "did you mean?/suggestions", color generated help and all that - I do not see obvious feature in clap docs missing in cligen. The Nim binary serde showing is unlikely as good but there are like 10 JSON packages and that seems maybe your primary concern.
More to add color your point than disagree (and follow up on my "adoption") - your ideas about polish, quality, docs, etc. are part of feedback loop(s) you mentioned. More users => Users complain (What is confusing? What is missing? etc.) => things get fixed/cleaned up/improved => More users. Besides "performant" being multi-dimensional, the feedback loop is more of a "cyclic graph". :-) Or maybe this is just a sub-graph of "ecosystem richness". While I probably prefer Nim as much or more as @netbioserror, I am not too shocked by the mindshare capture. It seems to happen every 5..10 years or so in prog.langs.
While many of your points are not invalid, tech is also a highly hype-driven & fad-driven realm. In my experience, the more experience with this meta-feature that someone has, the more skeptical they are of the latest thing (more rounds of regret, etc.). Also, that feedback graph is not a pure good. Things can get too popular too quickly with near permanent consequences. ipv4 got popular so quickly that we are still mostly stuck on it 40 years later as ipv6 struggles for penetration. Whatever your favorite PL is, it may also grow features too fast.
I think the beauty of serde is its flexibility. I can change the format from JSON to one of the other 21 supported formats with ease.
We're both agreed - popularity benefits platforms in many ways. I'm not a fan of hype-driven things, unless the hype ends up making the thing more valuable.
Rust is a good example - there was undoubtedly something useful there with its concept of compile time checks and memory safety with performance. It also had nice tools like cargo. But that wasn't enough. Quality alone isn't enough.
Look at the adoption curve (https://lib.rs/stats). If it had remained as popular as it was in 2018 then it would not be something I could recommend for general purpose programming. The main criticism of Rust in 2018 was that there weren't enough libraries to do basic things. You had to write and maintain a lot of that yourself. Fortunately for Rust, the hype based around its feature set and early successes snowballed into more adoption. In 2023, hardly anyone complains about missing libraries. At most they're missing one or two, and they can write those themselves.
Joining a hype train of a platform is a rational thing to do, because of the technical benefits of using a popular platform.
I'm far more critical of fads in our industry where we blindly copy practices from large tech companies, like algorithmic interviews. Copying interview practices doesn't lead to shared benefits, unlike a platform.
> Whatever your favorite PL is, it may also grow features too fast.
For what it's worth, Rust is really conservative about adding new features. Only big features I can remember in the last 3 years is GATs, and that's a pretty nice feature. Most of the feature work is making things more consistent. For example, we can write async functions but not async trait methods. They're fixing this inconsistency now.
While I love Nim, another reason for Rust's success (aside from its type system, general good language design, and zero-cost memory safety) is that the tooling is ridiculously good, probably the best of any language I've used, sans maybe Java. Nim's tooling is improving but still has a ways to go - I still occasionally get orphaned langserver processes, and while the langserver itself is pretty good, it's nowhere near the level of what rust-analyzer can do. Especially with error messages and (automatic) refactoring.
I have worked in HPC, Cryptography and Genetics, and Rust is sailing full speed in all these domains -- which are as remote as may be from WebDev & Mozilla.
