I am a fan of Rust for systems programming, but so many people are using Rust for things that are nothing even remotely close to systems programming. So many projects you see being written (or rewritten) in Rust are projects where I just think 'wait, why can't this just have a GC'? And then you look at the code base, and it's all Arc<Mutex<RefCell>>s, and you can't help at marvel at this, since that's just GC, so what's the benefit of Rust here, exactly? (Don't @ me, ARC is GC.)
I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. People will brag about Rust's memory safety, and then you find out that they don't really know how lifetimes work, they just .clone() or Arc<Mutex<RefCell>> everything. Which is totally valid, but Rust is hardly necessary for that.
Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.
I'm just really leery of using languages that don't have a clear separation between immutable and mutable state. Having it in Rust catches so many bugs.
I also want to write code in languages where you don't have to engage in bad software engineering practices to get optimal performance. That usually means aggressive inlining, something that Rust excels at.
edit: the other thing I wanted to mention is that rust's features cause dependencies to be pretty high quality.
If I pass in a slice of something, I'm no longer worried that something ten layers down will change it.
Error handling is explicit and panics are rare, so I'm not worried that dependencies will start throwing exceptions after an update. (This is the reason functions should indicate errors in type signatures—a better ecosystem.)
ADTs mean dependencies represent fewer illegal states internally.
It's just really nice to write code where the bugs are a couple levels up from bullshit like this.
I think this is a legit sort of reasoning, but in an interesting way it's something where OCaml could fill the gap. It has its ergonomics issues, but I think the issues are basically the same/worse in Rust (except I guess Rust's macro system is better).
I say this as a Rust enjoyer, but I take the pain because I _really_ want what I'm working on to be fast.
I like OCaml a lot as a language, but the tooling is very, very poor by modern standards. Poor enough that I think it’s a total blocker on wider adoption.
OCaml is definitely something I'd consider using if I didn't already live and breathe Rust :)
I use Rust often for things that aren't possible in other languages, so I also use it for things that are possible in other languages. (Though I used Python for a production and an art project recently -- with uv it's quite nice.)
> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc.
I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation. Most of the time I bring this up, someone will suggest something like Swift or OCaml, but I think the part people miss is how even despite all of the complexity that comes with being a systems programming language, Rust really goes out of its way to try to be developer friendly despite that.
Yes, it's a meme that Rust programmers are zealous evangelists and want to rewrite the world in it (which is a bit of an exaggeration in terms of lumping all Rust enthusiasts into that group, but there's certainly an element of truth in it), but no one seems to talk about how _weird_ of an idea it is for a language notorious for having a terrible learning curve to be so popular with people perceived to be lacking real-world experience with the domain. How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? You might chalk some of it up to marketing, but I think people undervalue how much effort is put into the little details in Rust to try to make it more approachable, like error messages, standard library documentation, first-class support for all major platforms, and high-quality introductory materials (e.g. both the original and rewritten The Rust Programming Language book, Rust by Example, Rustlings). I don't think the same experience is there if you want to use Swift on Linux (where the support isn't nearly as strong, and a lot of the fancy new things coming out won't be available) or OCaml (from googling right now, a debate on reddit about "which stdlib should I use as a beginner" is on the first page of results when I search "ocaml std" or "ocaml stdlib").
One issue is that with GC, you lose prompt finalization of resources. A lot of code is written with this assumption in mind (e.g., file buffers are flushed if the last reference to the file is dropped—which is arguable incorrect due to the lack of error checking). And the borrow checker is the only thing that keeps everything from being mutable in place in Rust today. Having GC would open the possibility for alternatives to the borrow checker without compromising memory safety, but even Pony-style reference capabilities probably won't lead to a language where abstractions compose much more easily than in Rust today.
Maybe a language with a similar syntax, traits, monomorphization, and macros would still be interesting to many people? Would people prefer traits and macros over ad-hoc polymorphism (in the style of C++, which could subsume the macro use cases, too)?
I don't think constructors are the challenging part. It's about lexically scoped destruction. Certainly there are languages that have that and permit garbage collection, however those constructed values are necessarily second-class citizens and behave somewhat differently than ordinary values. There's probably some reasonable middle-ground, like constructors returning an owned reference that explicitly can be turned into an unowned reference, thus opting out of deterministic destruction.
> but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation
I dream about a Rust subset that's exactly that. What would be even better is if you could just use Rust packages directly with it. Since these libraries already do compile, correctness has been verified.
A web framework doesn't need GC, it just needs some ability to express the idea that per-request code should get its own allocator, with knowledge of said allocator propagating down through function calls.
Jai solves this by having a "context", which includes an "allocator" member by default, whose default value is a standard heap allocator. You can override this allocator member to point to your own allocator, so it's easy and straightforward to have the main server procedure allocate a pool of memory, create a new context with a new allocator that uses this pool of memory, then "push" this context for the duration of the request resolution, then free (or mark for reuse) the memory pool afterward.
I gladly take the whole rust "package" because overall it's just so good, at least for opensource / hobby stuff. I wish there was an equivalent but with GC, to use for work.
> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?
I think Rust is especially popular with a demographic that was not previously exposed to lower level programming. Meaning younger programmers (because modern languages are higher level) and web centric programmers (because we're in a boom of web development).
This demographic had a hard time entering systems programming, because while fascinating, its exposure is lower (less jobs, less projects), and entry cost (learning C, or C++<11) is harder.
Rust made systems programming more accessible, and systems programming, just as anything related to how things work under the hood, is fascinating.
Now Rust is hard, as you noted, but not hard in the same sense than C is hard.
C is hard because low level stuff bites you immediately. You can't quite easily just use a random library in C if you don't understand your build system, linkage, etc. If you mess up in C, the compiler will not tell you either, you will have to debug your way out of it.
Rust is different, in the sense that its difficulty is limited to the compiler saying "nope". If you can get the compiler to say "yep", then you're 99.9% of the time safe. Now getting that compiler to say "yep" may take time, indeed, but all in all you most often can just get away with sprinkling unwraps, clones and Arcs all over the place until it works.
In that sense, I think Rusts popularity essentially lies in the fact that it is a way to do low level stuff with a barrier of entry limited to being stubborn in learning it.
Having learnt C in high school, and doing Z80 Assembly prior as a 12 year old kid, only with a bunch of books from the local library, it is kind of interesting to read about fear and hard regarding C.
Yes it does corrupt memory, there are some crashes, I usually bash C, nonetheless it seems we have too much "safety playground" regarding learning processes nowadays.
> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?
Popular languages don't really have evangelism or fans pushing it aggressively. Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem.
> there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector
What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin? Because those have great web frameworks that address all the features requested in the article and a whole lot more, there's good first class support for all major platforms, lots of documentation etc. These languages are also famously developer friendly with good error messages.
> Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem
> What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin?
I'd argue that Rust has better interop with C, C++, JavaScript, Python, Ruby, and probably almost every other non-JVM language than Java and Kotlin. I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.
Independent of interop (which I'm not really sure is as important to understanding why languages are or aren't popular as you seem to imply it is), I don't think the tooling in Java is nearly as beginner friendly as Rust. It's not just about the code itself; handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.
My point isn't that Java is bad or that doing things in it is hard in the absolute sense, but that "it's possible to do this in language X" is not the same as "it would be easy for a beginner to figure out how to do this in language X". I think there's an inherent lossiness in trying to distill what people like in a programming language into a bullet-pointed list of features, and it's an easy trap to compare those lists and conclude that one language doesn't have anything novel to offer based on that rather than the entire experience of working in a language.
Does Rust really have better interop? At minimum you're going to have to think about the gap between manual lifetimes and GCd allocations, bindings generation, ensuring the target language runtime is installed and so on.
You can call into JS, Python, Ruby and other such languages from Java like this:
It's very easy and requires no build-time bindings generation or Python/JS/Ruby runtimes to be installed. You can add Pip dependencies via the Java build system you use, as if they are regular libraries. It will also JIT compile the different languages together as one so the boundaries are optimized, you get transparent exceptions, callbacks work transparently as the whole heap is GCd as one, you can using a debugger in a unified way across languages and so on.
But this is sort of beside the point. Java once had lots of evangelism, partly to help build out the library ecosystem, but that was done years ago and now there are lots of libraries to meet most needs. So as a consequence you don't hear about it as much. This thread is a case in point. Lots of people suggesting rarely used languages like O'Caml or Zig, nearly nobody suggesting more obvious candidates that are used for this task, every day by nearly every big company in the world.
> I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.
Wouldn't that be expected then? Rust has had lots of evangelism which has successfully yielded lots of libraries?
> handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.
I think this may be based on an outdated idea of how things work nowadays. I have my beefs with Java build tools but if you just want to build and distribute a web app it's easy. Using the stack I'm most familiar with:
1. Starting from a blank computer, install IntelliJ or other IDE of your choice.
2. Go to https://micronaut.io/launch and use the little wizard to pick whatever languages and features you want to start with.
3. Download the generated project, open it in your IDE. All the dependencies are now downloaded automatically including the build system and the Java runtime itself. Likewise if you picked features that use JavaScript.
4. Tweak it, run it. To ship it you have several options, but an easy approach is to add this to your build.gradle file (if you're using Gradle):
and then invoke the dockerPush build target, either from the CLI (./gradlew dockerPush) or the IDE. You can also compile it to a standalone Linux executable with another build target. That's all there is to it. I don't think Rust improves on this situation. Note that the above instructions work on any computer in the same way, including Windows, with no additional work required.
You're behind the times. Write a web app using a framework like Micronaut, Spring Native or Quarkus and you'll get a native Linux EXE out of the build system that starts faster than a C program would (due to pre-initialization).
Not that installing Java is all that hard. apt-get install openjdk is sufficient.
Last I checked there was a significant disadvantage to using rather basic Java JIT code in a cloud environment: slow startup time and poor initial performance in terms of requests per second & latency meant scaling on demand didn't work very well. I suggested we move to GraalVM and AOT compilation on that project but we just ended up over-provisioning by a significant factor to smooth things out.
The problem is friction. To run a rust app you can just run it. To run a java app you need to install java first. This is no problem for backends running on servers, but client apps (like Minecraft) have to include their own JVMs to reach a wider audience, and this solution still introduces a bunch of complexity.
> it is a matter to actually care to learn about their existence
That's kind of the whole point I was trying to make above; if one language makes something super easy to do without having to look for instructions compared, that makes a difference in terms of how people will decide whether to learn it. Individually, lots of small quality of life things add up and can make a language that otherwise would be unapproachable way easier to get started with than languages that don't prioritize that sort of thing.
If someone has two choices that can provide the same output, and one of them makes it more effort to figure out how to do, then people will do the other one more often. There's no inherent virtue is spending effort to do something equivalent. It's not clear to me why you seem to think that pointing this out deserves a sarcastic response.
Yeah, sorry. I was aware of that but was being loose with words. I do think that part of the appeal is rust feels more bare metal and direct to people even if they're using heavy abstractions as compared to Java/kotlin or C# programming.
Scala 3? It has the vast Java ecosystem available and state of the art GCs (plural), with either a focus on throughput or low-latency. Also, it can exclude the null value from the type system, marking it explicitly with a union type.
I think all NVM langs claim interoperability with Java ecosystem. The situation on the ground is never as nice as sold in my XP.
Scala is a great example where I've seen the "best" option being rewrapped libs with scala calls and types rather than a native solution and the dev XP just isn't as good overall.
You can hardly get higher quality code than what is generally available in Java, especially with their stability. Wrapping it to use the language conventions seems like a pretty solid choice to me.
The dev xp, I sorta agree on, but it has improved a lot.
Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless.
It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?
I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.
I used to think that it was more likely that Rust would "expand upward" to provide the higher level syntax that people want in a language like I describe above, but it does seem like the language development has vastly slowed down in terms of big new features. I don't necessarily think this is a bad thing; plenty of people didn't like how much churn there was in the first several years after Rust 1.0 came out. I personally didn't mind since I never ran into any significant breakage in what I worked on, but I definitely noticed a change in how open companies seemed to be to use Rust in any capacity coinciding with Rust's releases growing smaller on average; I think "frequency of major language features" is often used as a proxy for "language maturity".
At this point, I think a new language is more likely to provide this niche than Rust, and I also don't think that has to be a bad thing. Having Rust scoped more to lower-level programming where you're more worried about things like minimizing heap usage and avoiding copying strings or whatever rather than trying to be all things to all users might end up with a better experience in the long run.
> that are nothing even remotely close to systems programming
This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably.
Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult).
* Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, the type system alone is worth dealing with this insistent borrow-checker.
* Its multithreading is stellar. The borrow checker helps a lot in making it such.
* Its mutable/immutable model is highly practical. It's what makes the threading stellar and the type system more useful than in any other language I worked with.
* Its "oop" model is uncomfortable at first (coming from Ruby and Java) but forcing the "composition over inheritance" by not having inheritance is probably the best thing that can happen to "OOP". Every solution where I used inheritance, I shouldn't have.
* Its culture of "making the good way the easy way", being opinionated, and a community that adheres to this, is worth dealing with a thousand borrow-checker WTFs. cargo fmt, clippy, etc.
* Its build system that generates binaries that can just be "plopped" onto a server, "chmod +x" -ed, and ran is unprecedented.
I come from Ruby, Java, Javascript (typescript). I do a lot of Python, maintain some go services, have decades of PHP under the belt and occasionally dabble in some C and even C++. I can find my way around in a C# codebase and Objective-C.
All have their strengths and weaknesses. Their place and use-cases.
But rust, for me, is the only "ecosystem" that ticks all checkboxes in nearly all situations. It has downsides, and I consider the borrow-checker to be one of them in a lot of my use-cases, but it's something I'm willing to deal with gladly, because rust's other benefits.
a few months ago there was an article linked here on HN (iirc about rust game dev) that argued that while rust is great, it's virtue of being mostly correct every time can also be a weakness.
the argument was that in early dev and prototyping phases you don't want to write good, clean, correct code but move fast and break things while not caring about edge cases - and this, the author argued - is relatively hard in rust.
I partially agree. It's not so hard to write software that keeps the borrow checker happy in early stages. But it does restrict the freedom to make terrible decisions a bit. Sometimes in that stage terrible decisions are OK.
But I do like that even in this stage, one is forced to at least make the decision to have terrible things, explicit. Like with 'unwrap()' and 'expect()' littering the code in PoCs and exploratory projects.
For me, a bigger problem in this stage is that I lack the information to make decisions on types. I have this same problem in TS and Java. It's guaranteed that I'll shape types in ways that will prove difficult, or slow me down a lot next week. I'll be spending time refactoring types when I should move on to the next feature.
I guess, but that's just my experience, that statically typed languages are just not well suited for early stage software. When we don't know the shape of the data we'll be pushing around, nor know anything about the shape of the layers, ports, modules and so on. Which is why I'll grab ruby for these kind of quick explorations often. And once the shapes emerge, rewrite it in rust :)
I agree with you on the borrow checker... Part if me wants a simplified(distilled?) Rust ... All of the good stuff, but remove the bad... Not sure how that looks but it is something I know I want
A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone!
My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.
I much prefer rust to go for many reasons, but IME go gets this part much better. Darwin / Linux cross compilation, armv7, FreeBSD, oh sorry you don't have a linker for that toolchain, wait where are those OpenSSL headers... lots of cross-compilation targets I've done in minutes with go that scp and run right away that end up being days / weeks of adventures to cross compile in rust, in spite of me knowing rust much better than go at this point.
I have had the luxury to work in projects that don't have to target many platforms, but rather "one": a server. Which then is often a simple linux variant so setting up a CI or even the local build to target that "one" is relatively simple.
But wasn't Go a lot more limited in the amount of targets it can build for than rust?
Yes and no -- obviously I can build for no_std targets like esp32 and atmega128p in rust but not go (haven't tried tinygo), but the proportion of targets that successfully built and ran IRL has been higher for me with go. On rust, the dynamic linking of libc (by default) and failure to include a linker with the toolchain have repeatedly been stumbling blocks, go "just works."
I didn't mean syntax or core lib to be similar, I just generally meant that both languages impose restrictions on themselves which might seem sensible at first.
Java isn't that restrictive. Rust's type system is much more restrictive and customizable.
That said, a good way to think about programs is a series of restrictions, i.e. invariants. Truth be told, only Ada Spark so far really embraced invariants.
I think RC and clone are the way people begin to use Rust. While lots of criticism are against this usage for not idiomatic, it should be acceptable. Coming from Python, nodejs or Ruby, even RC and clone or stack based variables is still a magnitude faster than those languages. When it's about absolute control for performance you can drop down a notch to the borrow checker behavior.
That's an interesting perspective I'd not considered before. Maybe there are different "registers" of Rust, in the same sense that linguists talk about registers in human languages, where you use your language differently for different purposes.
And thus, maybe if you're writing something that doesn't need to be screamingly fast absolutely all the time there's a register of Rust where putting lots of things in Rc<Box<T>> is completely acceptable, in much the same way that you might use a lot of impolite words around your friends but you don't in front of your employer.
Having written some Rust and a lot of Ruby, I find Kotlin to be a really nice "typed Ruby". Just like Ruby, Kotlin is an OO language in the core that is really friendly to FP. It's terse (not as terse as Ruby, as there are types to specify); but MUCH terser that Java.
> I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story.
F#is not C like and it's tooling and packaging is not as good as rust. Last time I checked it had multiple packaging solutions like paket and nuget. The tooling on vscode can be buggy
Yes F# has come along for the ride with modern .NET and it's as cross-platform as C# is. However, a lot of the really shiny .NET stuff is tooled up mostly for C# users, so it can be a challenge if you wanted to do something like a .NET MAUI (cross-platform GUI library) application in F# because the tooling and the content out there to teach you about it assumes C#.
F# can usually handle C# things - they put a lot of work into ensuring interop with new C# features - but the languages are from different paradigms so it is sometimes a bit awkward despite F#'s comprehensive OO support.
Personally I struggle a bit with F# because it doesn't have typeclasses, and a language that looks that much like Haskell but doesn't have typeclasses just feels weird to me.
Although it might get them... C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed), so F# could presumably piggyback on that if they wanted.
> C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed)
I'm in a startup using .NET. We deploy to a variety of targets including AWS t4g (Arm64) instances in AWS as well as x86/64 targets in GCP. All devs are on M1 Macs. Our build pipeline is GitHub Actions Linux runners. Our DB is either AWS RDS Postgres or GCP Cloud SQL Postgres with a mix of EF Core as ORM and Dapper (for more complex read queries).
C# has, over the years, converged with TypeScript so they are very similar[0] (though no Duck typing in C#). Good mix of OOP and FP paradigms borrowed from F#. F# interoperates with C# so it can tap into the larger C# ecosystem.
It's a good platform; very productive. CLI has a functional hot reload (much more limited than Node on JS as the granularity of module replacement isn't quite as good).
Don’t know if you intended this joke, but some time before Rust 1.0, @ was the sigil for garbage collection types (@T, like &T these days). Which I think was just reference counting, without even a cycle collector, because was shown to be undesirable before it could be improved.
I agree the type system is the best feature of Rust but neither Ruby or Elixir have the level of type safety and type expressiveness of Rust.
I'd recommend Haskell as an alternative, but Rust "fixes" plenty of long term Haskell annoyances (especially around laziness by default, concurrency, unsafe std).
Being able to use Arc<Mutex<T>>, Rc<RefCell<T>> and other smart pointers gives you granularity and control over what happens to your memory. I think it's a nice feature to have to mentally reason about your memory usage (incidentally a weak point in Haskell); even if it were on-par with a GC implementation-wise, why use a GC over this?
I like to have control over my code (and I'm probably one of the few who think monad transformers in haskell were a good feature - despite their clunkiness) and I'd pick explicit code over "magic garbage collection in the background" any day. This is not to say I like verbosity for verbosity's sake (eg. think React Redux in JS vs the implementation of the same idea in Elm) but in some cases I think it's justified and it brings extra value.
> Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.
Who changes their minds about what to do for fun because someone on HN thought it was unnecessary? Doing what some random person wants instead because they want to be “heretical” (because it’s a religion right) sounds like the opposite of fun to me.
But I’ll see you on the next thread about making a Rube Goldberg web server in C++ templates. Or some such very necessary and “approved for prod by HN” thing.
> - Phoenix on Elixir! Yes, it's not quite so blazing fast
As someone running a fairly cpu heavy SAAS application for users who literally dog pile our whatsapp support forums if it goes down for even a second, Phoenix is pretty damn fast in production. I won't claim its as fast as rust but it will run circles around ruby or python and for IO bound tasks, competes perfectly fine with go. Its never been a bottleneck (database is another story)
If Rust had no borrowing at all, just Rc<> everywhere I'd lose maybe 5% interest in it, maybe less. Value orientation and Traits system, close to bare metal speed and stellar stdlib are what's most interesting for me.
I would say it shines when you have systems constraints, for example embedded & robotics work well with Rust. You cannot have a GC (either you don't have a heap or you cannot tolerate a GC pause resp.) but you still have the benefits of a good functional programming language to write your algorithms in.
The benefits are less obvious if you have less of those constraints: go is way way simpler to write large codebases for cloud applications in and still provide an excellent concurrency support. Python is way better for experimenting.
After reading endless insufferable comments on HN a la “this should have been written in Rust” I realized that there is a very strong possibility that the people making those comments do not know another language. We saw this with JavaScript a decade ago. Before that it was Ruby.
You gave a long list of benefits of Rust - which should have answered your own question - and then suggested people use an ecosystem with almost none of those benefits.
I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. People will brag about Rust's memory safety, and then you find out that they don't really know how lifetimes work, they just .clone() or Arc<Mutex<RefCell>> everything. Which is totally valid, but Rust is hardly necessary for that.
Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.