upvote
You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).
reply
Yes rust async isn’t good imo. You can do basically the same thing with stackfull coroutines.

Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.

reply
> You can do basically the same thing with stackfull coroutines.

...Minus the various tradeoffs that made stackful coroutines a nonstarter for Rust's priorities. For example, Rust wanted:

- Tight control over memory use (no required heap allocation, so segmented stacks are out)

- No runtime (so no stack copying and/or pointer rewriting)

- Transparent/zero-cost interop over C FFI (i.e., no need to copy a coroutine stack to something C-compatible when calling out to FFI)

reply
"Tight control over memory use" sounds wrong considering every single allocation in rust is done through the global allocator. And pretty much everything in rust async is put into an Arc.

I don't understand what kind of use case they were optimizing for when they designed this system. Don't think they were optimizing only for embedded or similar applications where they don't use a runtime at all.

Using stackfull coroutines, having a trait in std for runtimes and passing that trait around into async functions would be much better in my opinion instead of having the compiler transform entire functions and having more and more and more complexity layered on top of it solve the complexities that this decision created.

reply
Generics are incredibly overused in rust like most other features. I’m pretty sure most programs don’t need generics outside of use cases like HashMap
reply