Item — HN Reader

Please allow me to share my view of the conversation up to this point:

Boats: Here is an approach I use in my personal projects that has proven to be ergonomic, consistent with other language features, and could possibly even unlock future optimization opportunities long down the road.

OP: That's it, I'm DONE. The language moves too quickly and I can't keep up.

You: More breaking changes are on the way. They never learn.

-----

Would you agree that this escalated way, way too quickly?

Boats didn't "move" the language with a blog post, it's not even a pre-RFC. As pointed out elsewhere in this thread, the language hasn't been moving at all since 1.0 - you could say the frontier has been inching forward, but that's what frontiers do; nobody's forced to fight on the front lines all the time. And then the cherry on top - "more breaking changes on the way", when 1) prior changes weren't breaking; 2) it's not clear there will be any new ones; 3) if there will, those won't be breaking either.

1 comments

Please let us know how async/await is not going to be a breaking change, when even Fuchsia just decided to create their own async runtime, because surely we still don't have enough of them.

So I wonder how std will incorporate a runtime implementation that happens to be compatible with all ongoing runtime flavours, so that those breaking changes don't happen.

Well, either the language will leave async runtimes in the domain of third-party libraries, which is the current approach. Or, the potential blessed one in std will be an alternative that you may or may not want to use in your code.

When I think of breaking changes, I think removing sun.misc.Unsafe. Which, yes yes, was never supposed to be used, but still was. Evolution of best practices and introduction of alternative implementations doesn't break anything.

It does break, because those libraries need to interoperate and async/await doesn't work without linking to one of them.

I might be misunderstanding, but the third party libraries won’t be going anywhere, right? No one will be forced to use the runtime in std, if it’s added.

That is correct. It's not clear that we'll add one to libstd, but even if we do, it will have zero impact on folks using external runtimes. If we do add one to libstd, it will probably be a very simple one, mostly for convenience and prototyping, rather than something that tries to compete with the bigger runtimes.

And what is the interoperability story across libraries that dependent on different runtimes?

It depends. The major pain point right now is that there's no common API for spawning new tasks. Not every library does that though.

It's still not clear what this has to do with being a "breaking change" though. Like, if I were to use the serde-json crate in my project, the fact that the json crate exists, but has a slightly different API, does not mean that somehow this is a "breaking change." Moving between two or three different libraries is not the same thing.

Well it all depends on how interoperability will work across runtimes, otherwise you get silos depending on which runtime each library decides to use for their async/await code.

Right now Rust is looking to have as many async/await variants as there are C++ string libraries, with the same amount of interoperability headaches.

> Please let us know how async/await is not going to be a breaking change,

You're the one claiming it is, it's up to you to demonstrate how.

Because currently I cannot switch Rust libraries without rewriting my code to depend on another probably incompatible async implementation.

Even C++ has learnt the pain of not having basic language libraries as standard library type in what concerns interoperability across libraries.

Async runtimes not being part of std was a surprise to me.

That is a very idiosyncratic definition of "breaking change."

Interoperability is good! We have more work to do to make async more interoperable, absolutely. That doesn't mean that "async/await is a breaking change."