3 ms·

We used to have M:N threading in Rust's runtime -- this is one other way to achieve what we wanted. It imposed a cost on all programs, including those which wer

• dboreham 7y ago
  But with other downsides such as making application code less easy to debug and maintain.
  • skybrian 7y ago
    Certainly, but if you're willing to commit to one runtime for your app, there are plenty of other choices: Go, Erlang, Kotlin, Swift, Typescript or Dart might be better bets. Web browsers and mobile phone apps do well with this approach. Rust (along with C or Zig) has an interesting use case for building large libraries that can be reused across different runtimes via foreign function calls. It's paying some usability for the library maintainer for being able to work in more environments. To speculate a bit, I expect we will eventually see some interesting new runtime environments built out of the various libraries in the Rust ecosystem. (Along with C of course, which is how runtimes are built now.) Maybe we will see a trend away from reimplementing all the libraries in whatever the hot new language is, in favor of building on a more persistent set of stable libraries? (Already true today with C, but the Rust ecosystem could evolve into something more cohesive.)