More breaking changes are on the way, until error handling and async/await get properly integrated into std, instead of having a couple of incompatible crates each going its own way.
More breaking changes are on the way, until error handling and async/await get properly integrated into std, instead of having a couple of incompatible crates each going its own way.
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.
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.
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'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.
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.
You're the one claiming it is, it's up to you to demonstrate how.
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.
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."