Thank you for the kind words and the thoughtful response.
I'm deeply sympathetic to your viewpoint, and some days I certainly feel like Rust is creaking under its own weight. Why does your typical backend web service need all this complexity with borrows and lifetimes and manual memory management?
But allow me to present the other side of the argument. My background is in systems-level developer tools, and Rust has a combination of things that no other programming environment has:
* & and &mut, which enforce a rigorous separation between mutable and immutable state. I think this is the single most important feature of Rust, and the closest analog to this in other environments is purely functional languages like Haskell
* enums with data + exhaustive pattern matching; the latter is something even Haskell lacks
* high-level idiomatic code that performs like low-level code (e.g. iterators): Rust achieves this through an extraordinary combination of monomorphizing and inlining
* working in memory-constrained environments: tracing GC tends to have significant memory overhead, and I've worked in server environments where a big limiting factor was the amount of DRAM being produced globally
* fast startup times: this is a requirement for command-line tools people use hundreds of times a day—I spent many years working on Mercurial where Python's slow startup time was a very common complaint
* first-class support for using native OS calls directly; many higher-level languages like Java abstract away the details, so things like signal handling are hard to hook into
* first-class Windows support: again, non-negotiable for many developer tools, since the plurality of developers are on Windows
* and last but not least, a great dependency ecosystem, which ties into all of the above points: & and &mut mean that some transitive dependency three levels down won't suddenly alter the list you pass in, idiomatic performance means that perf regressions are rare, first-class Windows support means most dependencies just work on Windows, and so on
Is it possible to have an application-level/GCd/managed language that meets most or all of these requirements? Certainly. Does such an application-level language exist today? No, and there's nothing on the horizon either (Haskell has its heart in the right place, but is missing many of the more practical features here).
Rust isn't a great application-level language, but it's the best application-level language. And given how high the barrier tends to be for a new language to reach adoption, I'll probably be retired long before something like that shows up.
And yeah, async really is quite confusing in so many ways, and it's really unfortunate that this situation has seen no improvements in so many years. And yet, through its characteristics combined with the other things listed here, it enables developers to solve real problems that are completely infeasible in any other language.
I am unfamiliar but I think Go meets most of your requirements. Except of course: "working in memory-constrained environments: tracing GC tends to have significant memory overhead". Go has a garbage collector. The Go fans I know laugh in my face about my concerns with garbage collection resource use (especially GC pauses), very fast they say, very good. Mēh. Whatever, Go has been a success in the "developer tools" sector. AFAICT more successful than Rust
Does the embedded world need or want async/await? Is it worth paying the price of extreme complexity in many not so trivial use cases? Have many embedded developers asked for it? I expect not
My strong feeling is that async/await is making easy things easier and many common things harder. A managed runtime would improve the experience a lot - but it would not be the Rust we know. It would be mostly better.
I would not be interested. My interest in Rust is because I like control. I cannot make a business case for any use of Rust except in the places where C and C++ (my first loves) made sense, and that was (is) a very small sector in application programming.
> I am unfamiliar but I think Go meets most of your requirements.
Go definitely meets many of the requirements here such as fast startup time, but it (like every other imperative language that's not Rust) fails at the & and &mut separation which I've come to regard as the most fundamental requirement of all. Go also doesn't have enums with data and exhaustive pattern matching, and its Windows support is also a bit dodgy -- see things like https://pkg.go.dev/os#Chmod where they try to emulate Unix chmod on Windows. When writing Windows-specific code I want to use Windows idioms, not a Unix emulation layer.
> Does the embedded world need or want async/await?
I'm deeply sympathetic to your viewpoint, and some days I certainly feel like Rust is creaking under its own weight. Why does your typical backend web service need all this complexity with borrows and lifetimes and manual memory management?
But allow me to present the other side of the argument. My background is in systems-level developer tools, and Rust has a combination of things that no other programming environment has:
* & and &mut, which enforce a rigorous separation between mutable and immutable state. I think this is the single most important feature of Rust, and the closest analog to this in other environments is purely functional languages like Haskell
* enums with data + exhaustive pattern matching; the latter is something even Haskell lacks
* high-level idiomatic code that performs like low-level code (e.g. iterators): Rust achieves this through an extraordinary combination of monomorphizing and inlining
* working in memory-constrained environments: tracing GC tends to have significant memory overhead, and I've worked in server environments where a big limiting factor was the amount of DRAM being produced globally
* good polymorphism: I think OOP is a suboptimal paradigm that breaks under day-to-day development stress. I've written about it at https://news.ycombinator.com/item?id=42512629
* fast startup times: this is a requirement for command-line tools people use hundreds of times a day—I spent many years working on Mercurial where Python's slow startup time was a very common complaint
* first-class support for using native OS calls directly; many higher-level languages like Java abstract away the details, so things like signal handling are hard to hook into
* first-class Windows support: again, non-negotiable for many developer tools, since the plurality of developers are on Windows
* and last but not least, a great dependency ecosystem, which ties into all of the above points: & and &mut mean that some transitive dependency three levels down won't suddenly alter the list you pass in, idiomatic performance means that perf regressions are rare, first-class Windows support means most dependencies just work on Windows, and so on
Is it possible to have an application-level/GCd/managed language that meets most or all of these requirements? Certainly. Does such an application-level language exist today? No, and there's nothing on the horizon either (Haskell has its heart in the right place, but is missing many of the more practical features here).
Rust isn't a great application-level language, but it's the best application-level language. And given how high the barrier tends to be for a new language to reach adoption, I'll probably be retired long before something like that shows up.
And yeah, async really is quite confusing in so many ways, and it's really unfortunate that this situation has seen no improvements in so many years. And yet, through its characteristics combined with the other things listed here, it enables developers to solve real problems that are completely infeasible in any other language.
So I keep trying to make Rust better :)