24 comments

[ 4.3 ms ] story [ 66.1 ms ] thread
As usual the HTTP client example is broken again: https://github.com/fwsGonzo/libriscv/blob/master/binaries/zi...
Many examples out there are broken. As a sidenote, I've been benchmarking Zig, Rust and C++ with a fibonacci benchmark and the results basically show that C++ is the fastest, but within a 3% margin of error against Rust and Zig, which are mostly similar (Rust so ever slightly faster).
Can you please share the code? On my tests late last year it was basically Zig, C++, Rust.

Sorry I don’t have the code anymore.

Soon I'll write something and publish it.
What's compiling C++? Having faster compilers available is nice, but comparing same llvm version would be interesting
I'll write something an post it here in HN
I mean it’s a random repo, what do you expect from the Zig authors?
I used the "official" example. It's OK that things break - just that I can't figure out how to update my previously working code. So, I'm wondering - where is the updated official example of using the HTTP client?
Will Github ever fix their Zig syntax highlighting so it's not all brown text by default?
(comment deleted)
I really appreciate the time, effort and detail of the release notes.

That's super rare these days and takes considerable effort and discipline to perform.

It's also indicative of a well run project.

Please consider donating: https://ziglang.org/zsf/

Good news! If all goes well, seems that 0.14.0 will bring async/await https://github.com/ziglang/zig/issues/6025
Here too? Never mind function colouring, async/await itself is a feature that infects entire languages.

Such a terrible abstraction of concurrency for our 1970-style languages. Zig doesn't have strings because they're too high level, but async/await is fine.

From what we know their async/await should be noticeably distinct from the usual, otherwise the previous revert was for nothing.
I still can't find a decent explanation as to why zig, a C replacement needs to have Async built in by default. I actually think this should belong to a higher level abstraction.
Zig doesn't have to have it, but in Zig's specific case it can offer a surprisingly innovative implementation of it. The grandparent post mentioned how async/await infects languages (it does) and Zig is in a unique position where this would be not as true. Note that async/await has to gain a lot by being "built in" as opposed to a pure userland thing, as it basically is used to rewrite function bodies and mess with calling conventions.

As for the correct level of abstraction of async/await I believe that it's actually a very low-level primitive that should only be offered in low-level languages as it's very footgunny to use in high-level languages and generally worse than actors/csp.

Unfortunately I think this is not the case -- it might just be that the async/await issue is getting pushed into the next milestone tag with each release. In the most recent roadmap video[1] Andrew said that the main focus right now is compilation speed, and that async/await specifically was going to take a long time. My memory is that he says something about how it doesn't work well with LLVM and is generally a hard problem that they would prefer to do correctly instead of quickly.

[1]: https://www.youtube.com/watch?v=5eL_LcxwwHg

You are absolutely right, he did indeed share those thoughts. I do remember now! Thanks