4 ms·

> Rust was originally going to use fiber threading. The reasons they didn't are lost to me Because it was found that you can just put this stuff in user-level

> Rust was originally going to use fiber threading. The reasons they didn't are lost to me Because it was found that you can just put this stuff in user-level libraries, it doesn't need to be part of the core language. This is what Tokio does, it provides a multi-threaded runtime that can be used together with Rust's async facilities. Romio is an experimental project which extends Tokio to work with the new async-await syntax and adds async-IO support, but this work will very likely be folded back into Tokio itself as soon as the underlying features reach stability.

Footpost 7y ago
Is there currently a reasonably mature Erlang-style threading library for Rust? Something that is to Rust what Akka is to Scala?
- steveklabnik 7y ago
  There are people playing with them, but I don’t know how mature they are. Actix is one example.
  - Footpost 7y ago
    Would you be able to venture a guess why they are not more popular? I agree that basing Rust's concurrency on an Erlang-like model would not have been a good idea, for reasons mentioned in this thread. Nevertheless the sheer convenience of Erlang-style concurrency would nevertheless be useful in quite a few scenarios where Rust is used.
    - Footpost 7y ago
      I'm asking because I'm considering developing an Erlang-like approach to message-passing concurrency for Rust.
      - steveklabnik 7y ago
        I dunno, it just seems philosophically divergent. Rust isn't afraid of sharing, that's kinda the whole point. actix was a big one, but actix-web ended up moving off of it, so I'm not sure what the state of it is.
nullwasamistake 7y ago
Building it into the language has the advantage of enabling fiber code in all libraries. I think rust is making a huge mistake here. The reason it's even possible to retrofit fibers into old Java code is because all the threading and async stuff is built into the language. Unless you're using native code enabling fibers will be as easy as switching out thread pools that your threads use.
- 0815test 7y ago
  The basic interfaces are built into the standard library, precisely in order to ensure compatibility across the Rust ecosystem. So if you're writing something that's compatible with the basic futures/async model, you'll be able to use any provided runtime with Rust. It may be possible to do even better in the future (use HKT to enable the exact same code to be compiled as either "sync" or "async"-based) but I'm not sure why you think that the previous model of making Rust into yet another heavy runtime-based language (with a handful of weird, tacked-on functional features that would not even help performance to any real extent given those prereqs, but still making the language even harder to grok than Haskell!) is preferable.
  - pjmlp 7y ago
    The challenge is going to be the same that C++ had until ISO C++ finally understood the way forward was to actually have them in the standard. A bunch of third party libraries with different levels of quality not guaranteed to be available across all target platforms supported by the language.

Footpost 7y ago

Is there currently a reasonably mature Erlang-style threading library for Rust? Something that is to Rust what Akka is to Scala?

steveklabnik 7y ago
There are people playing with them, but I don’t know how mature they are. Actix is one example.
- Footpost 7y ago
  Would you be able to venture a guess why they are not more popular? I agree that basing Rust's concurrency on an Erlang-like model would not have been a good idea, for reasons mentioned in this thread. Nevertheless the sheer convenience of Erlang-style concurrency would nevertheless be useful in quite a few scenarios where Rust is used.
  - Footpost 7y ago
    I'm asking because I'm considering developing an Erlang-like approach to message-passing concurrency for Rust.
    - steveklabnik 7y ago
      I dunno, it just seems philosophically divergent. Rust isn't afraid of sharing, that's kinda the whole point. actix was a big one, but actix-web ended up moving off of it, so I'm not sure what the state of it is.

nullwasamistake 7y ago

Building it into the language has the advantage of enabling fiber code in all libraries. I think rust is making a huge mistake here. The reason it's even possible to retrofit fibers into old Java code is because all the threading and async stuff is built into the language. Unless you're using native code enabling fibers will be as easy as switching out thread pools that your threads use.

0815test 7y ago
The basic interfaces are built into the standard library, precisely in order to ensure compatibility across the Rust ecosystem. So if you're writing something that's compatible with the basic futures/async model, you'll be able to use any provided runtime with Rust. It may be possible to do even better in the future (use HKT to enable the exact same code to be compiled as either "sync" or "async"-based) but I'm not sure why you think that the previous model of making Rust into yet another heavy runtime-based language (with a handful of weird, tacked-on functional features that would not even help performance to any real extent given those prereqs, but still making the language even harder to grok than Haskell!) is preferable.
- pjmlp 7y ago
  The challenge is going to be the same that C++ had until ISO C++ finally understood the way forward was to actually have them in the standard. A bunch of third party libraries with different levels of quality not guaranteed to be available across all target platforms supported by the language.