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.

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.

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