[hxtk]

It’s surprising to me how much people seem to want async in low level languages. Async is very nice in Go, but the reason I reach for a language like Zig is to explicitly control those things. I’m happily writing a Zig project right now using libxev as my io_uring abstraction.

[pjmlp]

Using async in low level languages goes all the way back to the 1960's, became common in systems languages like Solo Pascal, Modula-2, with Dr.Dobbs and The C/C++ User's Journal having plenty of articles regarding C extensions for similar purposes.

Hardly anything radical.

[hxtk]

When I look at historical cases, it seems different from a case today. If I’m a programmer in the 60s wanting async in my “low level language,” what I actually want is to make some of the highest level languages available at the time even more high level in their IO abstractions. As I understand it, C was a high-level language when it was invented, as opposed to assembly with macros. People wanting to add async were extending the state of the art for high level abstraction.

A language doing it today is doing it in the context of an ecosystem where even higher level languages exist and they have made the choice to target a lower level of abstraction.

[pjmlp]

People are putting C++20 co-routines to good use in embedded systems, in scenarios where the language runtime with some additional glue layers, is the OS for all practical purposes.

And GPGPUs as well, like senders/receivers whose main sponsor is NVidia.

[melodyogonna]

But Zig's async is being designed to enable this low-level control.

[audunw]

There’s two things I think a low level language should have:

1. Standardise on a sync/async agnostic IO interface (or something similar) so you don’t get fragmentation in the ecosystem.

2. Stackless coroutines. Should give the most efficient async io code, and efficient code is one of the reasons I want to use low level language

[xnoreq]

Huh? Golang doesn't have async?!