[first_amendment]

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.

[didibus]

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?

[first_amendment]

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.

[didibus]

I see, you want a functional language with first class concurrency, which also values high single thread performance and low memory footprint?

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?

[ibotty]

Not every data in Haskell is thunked and boxed. At least with GHC extensions.