The big problem with Go-like concurrency is that it does not cross the ABI boundary well, because we're still effectively stuck with C for ABIs. So if you want to use that one language for everything, that is fine. But if you want to invoke an API written in other language, then "and_then" type futures make more sense, because they can be easily mapped to a C ABI.
To give one specific example, WinRT uses futures, and there you can write async code that flows from C++ through C# to JavaScript and back, with mapping to a common ABI type done transparently at the interop layers (https://docs.microsoft.com/en-us/uwp/api/windows.foundation....).
If and when we standardize on a higher-level ABI that includes fibers or something similar, then the other approach might make more sense. Of course, the problem is that there isn't a single consensus design to standardize on...
Rust used to have a light runtime that managed asynchronous operations using green threads. It was eventually discarded because it caused an unavoidable performance hit even when not using it (because the low-level runtime and I/O methods all needed virtual dispatch) and it wasn't providing any clear benefit over just using OS threads.
Re:Two years of Rust
by carllerche on Tuesday May 16, 2017 @02:08AM
(#14347691)
The futures underpinning of Tokio actually doesn't have much to do with futures. The task system is really what is special about it (though, currently futures are the main way it is exposed) however, there is a lot of potential other routes that can be explorered. If you want green threads, you could build them on top of the task system and it would interopt with futures.
Re:Two years of Rust
by tatterdemalion on Monday May 15, 2017 @05:12PM
(#14345167)
I think we all agree that future chaining isn't great surface API in the long-term, but we have a pretty good idea of how to desugar async/await to the futures we have. That's why we're build the runtime around them; because they're fast and they will (someday) have a relatively convenient API.
>about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`)
How is that more boilerplate than any other way to have concurrency?
Re:Two years of Rust
by steveklabnik on Monday May 15, 2017 @05:14PM
(#14345184)
Async/await is commonly suggested as a lighter-weight syntax.
Well, isn't async/await complementary to futures?
Oh, it is, it just makes them a lot easier to use. The compiler does method restructuring magic behind the scenes to build the necessary state machines. Everything gets a lot easier to understand.
Do notation makes this stuff a whole lot more readable (See Haskell). Or Async-await (See C#)
Re:Two years of Rust
by marcosdumay on Monday May 15, 2017 @05:57PM
(#14345503)
About do notation, can't Rust get something similar with macros? (I still didn't get to making macros in it.)
Re:Two years of Rust
by steveklabnik on Monday May 15, 2017 @06:33PM
(#14345757)
There is a crate that does it in a duck-typed manner. It's not clear that the stronger typed version can work. We'll see.
I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting.
Here are a few that I think about personally and which are probably a little more unusual to see:
* Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it.
* Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct.
[1] https://blog.rust-lang.org/2017/05/05/libz-blitz.html