Wouldn't those trade offs just be picking a different language? I mean Rust is going for no runtime low level systems programming, if you add a runtime, then it brings what more to the table then say Haskell?
I approximately agree with you but there are lots of reasons I'd prefer Rust over Haskell. All data is thunked and boxed in Haskell, it's all heap-allocated and garbage collected, and polymorphism is through indirect pointers. Rust allows for "zero-cost" abstractions with a powerful memory-safe aware type system.
Erlang occupies a similar space.
Go is another option that's less like Haskell/Erlang but its type system is lacking/ inconsistent and it requires garbage collection.
So Rust has a real opportunity here that's not currently occupied by other languages.
Like a runtime only to manage concurrency, but still without a garbage collector and with unboxed types? Is that possible? I mean that's what the RFC looks like it wants to figure out.
Erlang occupies a similar space.
In what sense? I feel Erlang is at the other end of the spectrum from Rust. Can you explain further?
Erlang occupies a similar space compared to Haskell, in terms if it being a functional language with M:N green threads.
It is possible, there are many stack swapping libraries in C that don't use garbage collection/excessive heap allocations as proof (e.g. libpth). The RFC is trying to figure that out with rust, but their approach currently requires manually annotating functions with "async," creating an incompatible calling convention with existing Rust code.
Erlang occupies a similar space.
Go is another option that's less like Haskell/Erlang but its type system is lacking/ inconsistent and it requires garbage collection.
So Rust has a real opportunity here that's not currently occupied by other languages.