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?
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.
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?
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.
I don't know of many, I'm thinking Julia JoCaml or Red maybe a little.
but their approach currently requires manually annotating functions with "async," creating an incompatible calling convention with existing Rust code.
Can this be avoided? How else?