I think the key is that it's mainstream at the system/platform layer, not so much the application layer (though maybe one day!). Its benefits to the former are clear and undeniable; a paradigm-shift. Its benefits to the latter are pretty mixed by comparison. Anyone who mostly hangs out at the application-layer and doesn't follow this stuff closely could miss the adoption it's getting elsewhere.

I don’t see Rust becoming mainstream in the enterprise layer anytime soon. 90% or enterprise software consists of a REST API getting JSON payloads and saving them in a DB. The most complex part is often managing the “bus factor”, rather than some technical challenge. You often need just a bit more than VB6.

Rust requires a higher cognitive cost than C# or Python, but doesn’t provide massive improvements in the areas most relevant to enterprise developers (ORMs, JSON serialization, SDKs, etc…)

All of the areas you mention as relevant to enterprise developers are things that require libraries written, potentially with APIs that lean less in the "high performance" and more on "easy to use/hard to misuse", not fundamental changes to the existing language or tooling. I personally think that the big surprise with Rust will be how flexible it can be, covering a wider range of use cases than it might look at first.

Any company that does try to work with Rust today in any vertical slightly outside of what is considered "mainstream" will likely end up having to write their own libraries for things that are already available in other languages, but that's a factor of the ecosystem's age.

Though dependency management is quite easy to manage in rust (as with many high level languages) whereas I would argue dependency management isn't as simple in C/C++ which should boost library consumption and creation.

I know depending on boost or qt might be really easy, but the amount of different toolsets you must know to depend on randomlib is too damn high. I wish though that it doesn't end up like npm, I also hope there'll be some kind of "meta standard library" which integrates different mainstream building block libraries into something that's easy to consume coherently.

I consider most web-services - certainly glue code - to be at the "application layer". Of course these definitions are always fuzzy.

Which isn't to say Rust is never the right choice for those, it's just a more complicated question that's highly project-specific. Which is why it isn't mainstream there like it is in other places.

>Rust is mainstream For sure it depends what you mean by mainstream. If a FAANG uses language X, it's language X mainstream?

I'd venture to say that to be considered mainstream a language has to at least pass 1% threshold in Tiobe index (or the equivalent in Redmonk or others).

If Rust is mainstream, then Fortran is über mainstream

I would argue that Fortran _is_ "über mainstream" - if you look at computing as a whole. It may not be used extensively for CRUD applications, but it is part of the bedrock of basically all computing. And there are some niches where it is the main/only language.

Rust will likely end up in a similar place - enormously useful in its niche, foundational for infrastructure outside, and with enough uptake and stability to make a career out of. I don't think anyone expects it to eclipse popular dynamic languages for web development, but it might make inroads on C and C++ in areas where active development is still needed.

The rankings in that index are highly suspect. It has Visual Basic at #6 and Classic Visual Basic as #11. Meanwhile Kotlin is down in position #38 and TypeScript at #46 beneath COBOL, PROLOG, Scratch and Logo!

(And FWIW Rust is #26)

I understand that it is very popular and is increasing adoption. But I was more targeting the embedded systems/hardware. Obviously this blog post is a step in that direction, but I'm still curious if hardware manufacturers will want to spend time adopting it.

> I'm still curious if hardware manufacturers will want to spend time adopting it.

The interesting thing I'm observing[0] is that embedded developers aren't wasting any time waiting for hardware manufacturers to do anything about Rust because they know manufacturers...well, let's express it as: "just don't care about software".

Bluntly, regardless of whether it's perfect or not, Rust is currently pretty much the only hope for devs who are desperate to move on from C for embedded work and if they have reverse engineer every last proprietary bitstream, protocol & application they will.

It's not just about the language itself (which depending on one's perspective has both pluses & minuses) but also the ecosystem/tooling (e.g. libraries with `no_std` support, build/test/doc systems, etc). (And, from my perspective, the community from which this has all grown--and why.)

Maybe it won't succeed but it won't be for lack of trying. :D

Also, one of the interesting aspects of Rust for me is how broad the domains of application are--using the same language from microcontroller level, through UEFI/firmware, OS, applications, & web is pretty appealing and leads to easier migration between domains.

[0] Including in a comment a few comments down from this one (when I first read it): https://news.ycombinator.com/item?id=29001985