[first_amendment]

I wonder if Rust could support pluggable concurrency models (with the accompanying runtime support). That's what Haskell does and it seems to work. At the outset that seems like a better approach than creating an incompatible sub-language. The rust-facing side of the standard library already abstracts away many platform details.

[steveklabnik]

Trying this was in fact one of the reasons that Rust ditched its runtime years ago; it doesn't work. Well, it didn't work for Rust at least.

The RFC that made this change https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

[first_amendment]

Interesting. The problems section isn't really convincing to me though.

Especially, indirect function calls for IO functions seem fine since IO is usually much slower than a function call. Also binary size increase may not be a problem for people writing web-scale servers.

It would be great if the Rust compiler infrastructure provided the necessary hooks for re-implementing std::/using a different concurrency model and independent projects could make those "problems" trade-off decisions on a individual basis. Rust-core could just only support/ship the native threaded model to lower maintenance burden for themselves.

[steveklabnik]

> The problems section isn't really convincing to me though.

It was a big enough problem that the language was almost forked over it.

> It would be great if

Rust is low-level enough that you can do this, and some people have. But then people have to use your package. std is only special in that it can use unstable code but be part of stable Rust; otherwise, it's just regular old Rust code. The community overall abandoned all of those other things and is coalescing around Tokio, which could also be considered this, in a sense. Or Rayon, if you want data parallelism rather than async IO.

[infogulch]

Would it be possible to make functions generic over coroutines/async?

One of the worst parts of async is there's an infectious duplication of pretty much all library code where there are separate sync/async versions of everything. See C# DoXxx() & DoXxxAsync() everywhere, where the only difference between the two implementations are an annotation and some keywords sprinkled throughout. If rust can do the same thing without doubling the code/api surface/documentation across all libraries that would allay the fears of many opponents.

[skyde]

Haskell is doing this already with par and seq function to control parallel and lazy evaluation. I believe we should have something like this for Async

[xfer]

You can do DoXxx() using DoXxxAsync() by calling wait() on the future it returns. No duplicated code necessary.

[infogulch]

It's nice that that'll work but it's... kinda gross. Can it call wait() automatically via some auto type conversion? Ideally in a synchronous context it would call wait(), and in an async context it would automatically annotate await (and you could always override by calling wait() manually).

[didibus]

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?

[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.

[ibotty]

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