Hacker News Reader

Comment by m0th87 | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com