Comment by binary132 | Hacker News Reader

Comment by binary132 | Hacker News Reader

I love the idea of Zig, but it really bothers me that they haven’t put 100% total priority on stdlib reliability and asyncrony.

It kinda boggles my mind in particular that they’ve left async unfinished all this time. I can argue myself into tolerating an unfinished stdlib until the 1.0 release, since at least the interface should be pretty stable, but it’s been years, and async is an essential differentiator in this domain that needed to be nailed down early so that an ecology and craft theory could start developing around it. Instead, not only does Zig still lack a production-quality stdlib today, but it’s basically a nonstarter against the main contenders without proper async.

Maybe the thing to do would have been to offer some type of sanitary minimal API for a stack object + state machine + set/longjmp builtin primitives that have well-defined semantics so that at least people could get started defining usable APIs on top of it and experimenting with it.

Instead there was a false start on it with a short stop.

I don’t understand the mindset that led to this (non-)decision, but it erodes my confidence in the project. I understand that it’s not meant to inspire confidence and that it’s still experimental, but at this timescale it is simply frustrating to see and wish for a better status.

I know, I’m not wearing their shoes or whatever. Maybe I’m being uncharitable, but I don’t think I could really be accused of being impatient at this point.

In fairness, I feel this is a major hole in nearly everything but Go, so I guess getting it right is important.

Tbh, I don't understand the fixation on async/await in any language, and the last place where I would want to have that baked in is the stdlib (instead even with async/await available the lowest 'async stdlib layer' should use simple completion callbacks, which can then be wrapped in a higher level async/await compatible API if desired - although the original Zig async/await actually had a solution for the function color problem, which made such an 'async-agnostic' layering less important).

Async/await is a nice-to-have syntax sugar, but not required to write asynchronous code, and considering the substantial under-the-hood complexity I'm not sure if async/await is a good thing overall, especially in a low level systems programming language like Zig (or FWIW, also Rust and C++).

Arguably, promises are an important concept in JS because it's a convenient and composable method to let code complete "in the background" without proper multithreading, but promises work just fine without the async/await code transformation magic (which even in JS is just the cherry on the top, but not a must-have feature).

> sanitary minimal API for a stack object + state machine + set/longjmp builtin primitives

Traditional async/await doesn't use most of that but instead relies on the compiler to transform sequential 'async code' into a switch-case state machine. What you want sounds more like green threads / fibers with stack switching. This isn't portable to some platforms where the call stack isn't accessible (like WASM). But as I wrote above, I think that lowest layer should simply be 'stdlib functions with completion callbacks'. Those low level functions can then be wrapped into all sorts of asynchronous/multithreading runtimes.

FWIW, I think a stack-switching fiber runtime should be possible in Zig without special language primitives, because Zig has inline assembly: https://ziglang.org/documentation/master/#Assembly

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.

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.

> async is an essential differentiator in this domain that needed to be nailed down early

Which domain are we talking about here?

> a major hole in nearly everything but Go

... because Go being mostly used as "the devops tool language" where I honestly don't see much if any point to async code.

If anything I think Go is mostly used to implement client and (perhaps moreso) server apps using HTTP and other RPC protocols.

Go (and erlang) don't really have async, in the same way. In both of these languages, every function has implicit async yield points (this is? was? actually problematic in go since a for loop with no function calls can? could in the past? lock up the CPU), but in any case it's not the same conversation as rust/c/c++/zig which have the form of async where you have to explicitly declare your yield points by nature of the effective lack of runtime, or python/js where the vm is not smart enough to put yield points in for you.

Reply on news.ycombinator.com