[ioquatix]

> When designing an API in Rust which performs IO, you have to make a decision whether you want it to be synchronous, asynchronous, or both.

Why must that be true? Why can't you write the interface once, and have concurrency be an implementation detail?

[wahern]

Because the design of async in Rust precludes that. Some of the details are leaky. For example, recursive functions require dynamic allocation in an async context because the async state must be statically sized. See https://rust-lang.github.io/async-book/07_workarounds/04_rec...

There's no easy way to get around the function color problem unless you went the way Go did. But Go's choice made C ABI interoperability more complex. Rust chose simpler C ABI interop, at least for the sync case--no matter which choice you make neither approach makes async interop seamless.

The fun part will be seeing how Rust integrates async and fallible allocation. Both of these issues you could see coming from 10 years away, and also see how they'd interact, but Rust devs decided to punt on some of these hard decisions early on.

This sort of wheel reinvention is what you typically see in every new language, unfortunately, and you typically see them resolved in much the same way because solutions are path dependent on very early design decisions, and almost everybody makes the same early decisions. Except for Go. Go made the decisions it did because the designers had decades of language design experience, including decades of async experience under their belt. Rust designers came with a different set of experiences and goals, and this shows. (Not saying Go is better than Rust--in fact, non-fallible allocations was always a show-stopper for me in some critical niches. But Go made the most difficult decisions up front, and that included putting async first.)

[steveklabnik]

Rust did not punt on concurrency early on. The seventh word used in the first sentence ever describing Rust is "concurrent" http://venge.net/graydon/talks/intro-talk-2.pdf It even comes before "safe"!

What did happen was that the ways in which concurrency was implemented changed as other design constraints on the language changed. But 1.0 wasn't released until we knew what the concurrency story for Rust would be, even if sorting out all of the details took a few years.

"leaky" is in the eye of the beholder. Yes, if you think this should be abstracted, then it's a leak. But not everyone thinks that it should; many things about concurrent vs sequential are different, and Rust likes to expose certain kinds of costs and promises in the type signatures of functions. For its core audience, this is not a leak, this is giving you important information about the context the function should be used in.

[wahern]

> Rust did not punt on concurrency early on.

Rust started with green threading/fibers then quickly rejected that approach. Then it spent years iteratively building an alternative solution, which is still underway.

That's punting in my book; and it's punting for the majority of Rust aficionados who are surprised by the various twists and turns things take as the solution (as inevitable as it is) slowly materializes. By contrast, nothing of substance about Go async has ever changed, except perhaps the change in the default value of GOMAXPROCS. It was complete at conception.

It wasn't a wrong decision that Rust made; it was just a choice. But 10 years out it's not entirely implausible that if Rust had stuck with fibers that it may have driven the required OS improvements (e.g. Google's User Managed Concurrency Groups (UMCG) Linux kernel patches) that would have resolved some of the issues. It's not like Rust has become ubiquitous in the embedded space either, considering that it's held back by LLVM in that regard.

Something similiar happened with fallible allocations. Very early on most Rust devs declared that they believed that attempting recovery from allocation failure was folly (which in the land of GUIs from whence most of them came was the near universal opinion), and so shot down attempts to consider fallibility in the APIs.[1] Cue 10 years of slowly walking that back, with iterative (and still mostly pending) changes that were less than ideal owing to the fact that handling allocation failures is made infinitely more difficult if you don't take it into consideration at day 1.

[1] And, no, it's not enough to say that Rust core is allocation agnostic, because setting aside that only a tiny minority of Rust programmers only stick to core, the decision involved setting idioms and practices surrounding panics.

[steveklabnik]

Okay, we understand the word “punting” extremely differently then. Active work is the opposite of punting.

And yeah, maybe in an alternative universe where everything is different, things would be different. But that zero-cost C interop is one of the only reasons Rust succeeded enough to be making it to the point where it’s conclusion is considered, let alone re-writing all of the primitives of all the current OSes and waiting until those are widely deployed enough to be able to use only them and ignore all those embedded users. I don’t possibly see a universe where that works out. But in theory it could happen I guess.

[kazoomonger]

> But 10 years out it's not entirely implausible that if Rust had stuck with fibers that it may have driven the required OS improvements ...

Rust would've been a language nobody had heard of. It wouldn't have driven anyone to do anything because it wouldn't have had widespread adoption in the first place. As-is I'm using it in embedded programming and loving it. I certainly would never have picked Go for that.

I think you're not really understanding Rust's approach here. Green threads would be much too heavyweight to build into the language itself, and would mostly preclude it from being seriously used in interesting domains like embedded programming.

[kazoomonger]

Since I can't edit the above comment, one additional thought is that your criticism is valid for a language like Python, which has a much higher tolerance for abstractions such as green threads being built into the language itself. It would've been interesting if Python had gone with a solution other than async/await.

I'm also a little confused when you say "Rust started with green threading/fibers". I think the term "fiber" is overloaded here, but Rust did start with green threads (M:N preemptive multitasking). Rust now has support for cooperative multitasking via async/await. From what I can find of UCMG, it kind of misuses the term fiber. Looks like it's just green threads that the kernel is aware of?

[jkarneges]

It is an interesting thought experiment to imagine how things might have played out if Rust had kept green threads.

I don't know if it would have changed the Rust vs Go story much. There'd still be the learning curve of the borrow checker, and many people using Go aren't necessarily doing a ton of concurrency.

The Rust vs C/C++ story on the other hand... If Rust had a bunch of extra runtime stuff and limited interop, I suspect it would not have been perceived as a serious replacement, which may have hindered adoption. At least when I selected a language for my highly concurrent network server, I only considered C, C++, and Rust.

I'll admit it's a fine line. I'm using async Rust, with an executor/reactor and all that jazz, and the end result may not be much different than if Rust had made those decisions for me. Having the power to make my own decisions is very appealing though. It's possible Go could have been a contender for my project if it wasn't such a limited language. And Mozilla's backing of Rust helped it vs other fringe options.

[pjmlp]

Just as an example of how many years this might take, .NET was one of first ecosystems to bring async/await into mainstream, with C# 5 (2016) and the upcoming .NET 6 and related languages are still improving the whole experience.

[Kinrany]

Ideally:

1. The compiler would be able to turn a subset of async code into sync code with no runtime cost

2. Awaiting would be the default, with `.await` deprecated and special syntax for getting a raw future instead

That way most code would look the same regardless of being executed synchronously or asynchronously, with exceptions for evaluating multiple expressions in parallel and such.

But #2 probably implies lazy evaluation semantics for all expressions!

[ibraheemdev]

Because synchronous IO functions block the current thread and return the value directly, while asynchronous function return a `Future`, which will eventually resolve to the value, and can be polled concurrently with other futures as to never block.

    fn sync_read() -> Vec<u8> { ... }
    fn async_read() -> impl Future<Output = Vec<u8>> { ... }
    // the second can be written more succinctly as:
    async fn async_read() -> Vec<u8> { ... }

[dathinab]

It not possible with rust current abstractions you would need:

- higher kind types / type constructors

- some features to handle differences in the auto-traits depending on the result of the type constructor

- some magic to resolves that

---

- OR namespace overloading e.g. read_to_string$sync and read_to_string$async and magic to resolve that

But async has A LOT of implications which change subtle things around handling it, like e.g. the handling of lifetimes/borrows, Send, Sync, etc.

So this probably wouldn't be worth the complexity it introduces.

[vlovich123]

Because async based APIs need to return a promise type of some kind (eg Future). You can kind of auto-generate wrapping code to convert synchronous to asynchronous (with some performance cost that may be undesirable) but you can’t generally do the reverse, unless you try to do funky things like pausing/resuming user space fibers (and then issues of lock inversions and things come into play there in a systems level language).

[monocasa]

Because rust sync versus async colors the functions and how they're called.