Hacker News new | ask | show | jobs
by gabrielgio 261 days ago
As a developer interested in zig it is nice to see books being release, but I'd be a bit resitant to buy anything before zig reaches 1.0 or at least when they settle on a stable api. Both the builder and the std keep changing. Just 0.15 is a huge breakage. Does anyone knows how those changes would affect this book?
5 comments

People are doing real companies with Zig (e.g. Tiger Beetle) and important projects (e.g. Ghostty) without the 1.0 backward compatibility guarantee. Zig must be doing something right. Maybe this also keeps opinionated 9-5er, enterprise type devs out of it as well which might be a good thing :).
Are there other notable commercial companies/projects than Tiger Beetle relying on Zig? According to public information, Tiger Beetle are about eight employees with a single customer, isn't it?
I'm not sure how many customers that Tiger Beetle have but I really hope they are successful. It would be great to see such a quality focused engineering org make it. They are basically doing what many devs really want to do - make the highest quality and fastest stuff possible - instead of banging out random features that usually no one actually cares about. I don't have a use case for their tech right now, but the moment I have a need for anything in the vicinity I'll be checking it out..
Thanks! Joran, CEO from TigerBeetle here!

We’re doing pretty well as a business already, contrary to Rochus’ comment, which is not accurate.

Our team is 16, we have $30M in investment, and already some of the largest brokerages, exchanges, and wealth managements, in their respective jurisdictions are customers of TigerBeetle.

We have a saying:

“Good engineering is good business, and good business is good engineering.”

At least in TigerBeetle’s experience, the saying is proving true. We really appreciate your support and kind words!

Thanks for the clarifications.

May I ask what made you use Zig instead of e.g. Rust or C++ (or even Ada/SPARK)? I assume Go would be too undeterministic for real-time applications?

Go doesn't belong in this discussion.its a better java, c#, python and not much more. It doesn't work for 24/7 or for performance sensitive applications.
Bun.sh uses zig for large portions of native code.
Thanks for the hint. According to public sources, Bun's runtime infrastructure and bindings are written in Zig, but it uses Apple's JavaScriptCore engine written in C++ (i.e. Zig is essentially used in a thin wrapper layer around a large C++ engine). Bun itself apparently struggles with stability and production readiness. Oven (Bun's company) has around 2-10 employees according to LinkedIn.
Been using bun from years, it's as stable as alternatives from a long time.
Who is that single customer? I'd have thought by now there would be more.
lightpanda and bun
Lightpanda looks interesting, thanks for the hint. According to public sources, behind the development is a company of 2-10 employees (like Bun). The engine uses parts of the Netsurf browser (written in C) and the V8 engine (written in C++), and - as far a I can tell - is in an early development stage.
> The main idea is to avoid any graphical rendering and just work with data manipulation

Which makes the engine much smaller and less complex than a "normal" browser.

I guess almost every single language out there have at least one "real" company using it, so yeah, Zig is still mostly hype and blog post praising its awesomeness.
I disagree, since there's Bun also to exemplify real, popular, tools are being created.

https://bun.com

As a Zig adopter I was rooting for this because even though there is the official documentation and some great community content, it's nice to just kick back and read a well written book. I'm also very happy with other Manning titles; they have built a high level of trust with me.

To answer your question is it too early. My expectation is that the core language, being quite small by design, will not change that much before 1.0. Some things will, especially async support.

What I think we will see is something like a comprehensive book on C++14 . The language is not much changed between now and then, but there will be new sections to add and some sections to rework with changes to the interface. The book would still be useful today.

Not a perfect analogy because C++ maintains backwards compatibility but I think it is close.

Is this really the first Zig book since the development startet in 2016? Maybe the language and library is just too volatile for a book.
Or it evolves smoothly at another pace.
Author links to 0.15.1 Zig docs in several places, at least for now.

Outstanding issue on Zig side for 1.0 release: https://github.com/ziglang/zig/issues/16270

With how its going I feel Zig 1.0 wont be a thing until my retirement in 37 years
I’m willing to bet $5 it happens in 4 years or fewer.
That’s a pretty low confidence if we measure confidence in dollars willing to risk
It’s 100% of my annual betting budget though!
Do you have a history we can look at to see how good you are at predicting this for programming languages? Like say, some 2020 predictions you had for languages which would or would not ship 1.0 by 2025 ?
I made a set of predictions for Rust in 2022, nearly all of which turned out to be correct. And I was publicly confident Go and Rust would be massive when they reached 1.0. I was right on both counts.

But I will also admit I don’t follow developments in zig as closely as Rust. I’ve never written any Zig. And in any case, past performance isn’t indicative of future performance.

I could be wrong about this prediction, but I don’t think I will be. From what I’ve seen Andy Kelley is a perfectionist who could work on point releases forever. But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0. They’ll nudge him towards 1.0. They can wait a few years, but not forever. That’s why I guessed 4 years.

> But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0.

TB is only 5 years old but already migrating some of the largest brokerages, exchanges and wealth managements in their respective jurisdictions.

Zig’s quality for us here holds up under some pretty extreme fuzzing (a fleet of 1000 dedicated CPU cores), Deterministic Simulation Testing and Jepsen auditing (TB did 4x the typical audit engagement duration), and is orthogonal to 1.0 backwards compatibility.

Zig version upgrades for our team are no big deal, compared to the difficulty of the consensus and local storage engine challenges we work on, and we vendor most of our std lib usage in stdx.

> They’ll nudge him towards 1.0.

On the contrary, we want Andrew to take his time and get it right on the big decisions, because the half life of these projects can be decades.

We’re in no rush. For example, TigerBeetle is designed to power the next 30 years of transaction processing and Zig’s trajectory here is what’s important.

That said, Zig and Zig’s toolchain today, is already better, at least for our purposes, than anything else we considered using.

I stand corrected. I fear I may lose my $5 now.

If you don’t mind my asking, did TB add support for transaction metadata? I’ve seen this anti-pattern of map<string, string> associated with each transaction. Far from ideal, but useful. Last I checked TB didn’t support that because it would need dynamic memory allocation. Does it support it now or will it in future?

Both go and rust had substantial dedicated corp support and dollars behind them. Zig not so much. With that in view its advancement is pretty remarkable.
Wouldn’t you think AI advances in 4 years would make this a safe bet?
No, unless you're riding the hype train so hard that you are excited to go to colonize Mars thanks to AI advances.
The language itself won't change much. The standard library is what is still in flux.