3 ms·

It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callbac

by fooyc 6y ago

It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callback hell, but this doesn't fix everything. The "function color" problem still exists [1], and seems to be more than binary in rust. This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Rust is ground breaking in some areas, but also completely lacks innovation in others. But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? [1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

steveklabnik 6y ago
> This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Already in Rust many libraries can be written completely agnostic of the underyling executor. Some cannot; we have a bit more interface work to do, but there's nothing inherent about this, it's solely a standardization issue that's being worked on. Sounds like they ran into the latter more than the former, which is unfortunate, but should be better in the future. > But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? It is not!
mlindner 6y ago
One of the core facets of Rust is that you don't pay for what you don't use. If everything was async by default then code that wasn't async would pay the cost of it. Async isn't free.
CJefferson 6y ago
I would love to see some quality benchmarking of a non-trivial threaded solver in Rust. As strongly suspect it will perform "well enough" (hopefully much better than async in Python, and hopefull javascript too), which is good enough for me to be able to escape async.
estebank 6y ago
> This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Having to write async versions of the sync APIs doesn't need to be the case: https://docs.rs/smol/0.1.18/smol/ https://docs.rs/smol/0.1.18/smol/ lets you use blocking APIs in async contexts without blocking (by dispatching them to different threads). What the ecosystem is seeing is a few different projects trying things out in different ways to explore the design space. This is not necessarily a bad thing. > Rust is ground breaking in some areas, but also completely lacks innovation in others. Other than the borrow checker Rust is a very boring language for language designers. That is intentional :) > But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? async/await lets the compiler perform some extra inferences on how you're using your data, which makes writing an `async fn foo();` much easier than `fn foo() -> impl Future;` if you are dealing with borrowed data. Of course, the same underlying threading primitives are still available to use.

by fooyc 6y ago

steveklabnik 6y ago

> This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Already in Rust many libraries can be written completely agnostic of the underyling executor. Some cannot; we have a bit more interface work to do, but there's nothing inherent about this, it's solely a standardization issue that's being worked on. Sounds like they ran into the latter more than the former, which is unfortunate, but should be better in the future. > But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? It is not!

mlindner 6y ago

One of the core facets of Rust is that you don't pay for what you don't use. If everything was async by default then code that wasn't async would pay the cost of it. Async isn't free.

CJefferson 6y ago

I would love to see some quality benchmarking of a non-trivial threaded solver in Rust. As strongly suspect it will perform "well enough" (hopefully much better than async in Python, and hopefull javascript too), which is good enough for me to be able to escape async.

estebank 6y ago

> This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Having to write async versions of the sync APIs doesn't need to be the case: https://docs.rs/smol/0.1.18/smol/ https://docs.rs/smol/0.1.18/smol/ lets you use blocking APIs in async contexts without blocking (by dispatching them to different threads). What the ecosystem is seeing is a few different projects trying things out in different ways to explore the design space. This is not necessarily a bad thing. > Rust is ground breaking in some areas, but also completely lacks innovation in others. Other than the borrow checker Rust is a very boring language for language designers. That is intentional :) > But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? async/await lets the compiler perform some extra inferences on how you're using your data, which makes writing an `async fn foo();` much easier than `fn foo() -> impl Future;` if you are dealing with borrowed data. Of course, the same underlying threading primitives are still available to use.