Hacker News Reader

Comment by binary132 | Hacker News Reader

Do you think it’s good or bad for Rust that they got builtin async semantics this late in their lifecycle, after multiple people have already contributed competing and incompatible asynchrony APIs? Have you paid any attention to the state of industrial asynchronous programming in C++?

I can see arguing to omit it entirely from a language, and to never introduce it, but clearly the Zig authors intend to include it.

View on HN

I'm not closely following the state of async/await in Rust and C++, but from my outside perspective it looks like it resulted in a hot mess in both cases.

Zig's initial async/await solution looked like it would avoid a lot of that mess, but IMHO it's better to not have a feature at all instead of a half-assed feature. So I actually appreciate Zig to focus on other things first if they don't currently have a good plan on how to provide a good async/await implementation that fits the "Zig vision". Personally, it's definitely not anywhere close to the top of my "must have" list for a low level language like Zig.

In Rust, C, and C++, people have come up with their own solutions to it, which are incompatible with one another, hard to debug, and have caused ecosystem fragmentation. The reality is that evented IO is a system feature that needs to be supported in the standard library first and foremost, if not in the compiler, to avoid competing “async std” implementations, and then a blessed API should be provided to support it so that the ecosystem doesn’t diverge. Go knocked it out of the park on this.

Yes. I think I don't understand something, because without a cohesive concurrency story, it isn't clear how you're supposed to glue different components together effectively.

For example, an http server is using nonblocking calls and dispatches to its own threadpool. The lack of cohesiveness means that the blocking call made by the PostgreSQL library can't feedback into the http server's concurrency model. The http server could expose or pass some control mechanism into the application, but for that to work, all the libraries would need to support it.

A lot of people don't seem to think this is necessary, and I've generally assumed that they're right and there's stuff I just don't understand.

It's kinda true if you're just using the system primitives directly (kqueue, epoll, whatever) but people tend to build abstractions over those and then offer callback scheduling libraries for their users, and away we go.

IMO, we haven't really seen a natively compiled and manually memory-managed language "get it right" yet. There are pretty good third-party abstractions for it though.

Reply on news.ycombinator.com