Hacker News new | ask | show | jobs
by m0th87 3310 days ago
This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics without the impedance mismatch?
3 comments

It's harder for us, but I think we can get to an ergonomic solution with async/await.

It's not as easy as threads (M:N vs 1:1 is a red herring as far as this is concerned), but there's no free lunch.

I hope the Rust team takes a look at Kotlins coroutines (and all the stuff they managed to build on top of them). I think Kotlin is a good example because it is built ontop of a 1:1 runtime and uses very elegant primitives.

I was pretty disappointed Rust didn't ship with async/await and some form of lightweight thread but it's understandable.

async/await still has the fundamental problem of composability that all the other attempts at sugaring around an event loop have (aka the "functions have colors" problem [1]). It sucks for collaboration, which is one of the most important things for modern software development.

1. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

I don't like that article, because (1) it claims Go is doing something new, while Go is really just threads with a particularly idiosyncratic implementation; (2) it ignores the fact that you can convert async to sync by just blocking and sync to async by proxying out to a thread pool. The "what color is your function" problem really isn't a big deal.
A thread pool is far from "ergonomic", it's accidental complexity with numerous gotchas.
You can see for yourself [1]. Seems many users are not following the patterns of Async IO in Rust.

1. https://www.reddit.com/r/rust/comments/6enj5d/what_does_rust...

1:1 can be made compatible with async I/O with a thread pool, though.
There's a prototype of async/await that can help a lot with that.