Definitely httpz is the true winner! And this is what I ended up choosing. Zap’s API is not that great and lacks most (path params, etc.) that a framework needs as of now.
Yeah, changes in tech for companies is a risk or investment that doesn’t really provide them any short-term (or even long-term) benefit, choosing different tech, and it totally makes sense for companies to choose the safer route and focus on product instead of choosing technologies.
Ah, but there is a niche in webdev where writing the backend in Zig is an obvious good choice.
If you want to build your own niche SaaS, and all the costs of running it come out of your own pocket, then Zig makes perfect sense.
If you can host the whole of the backend for well under $50 a month, and know that resource consumption remains flat and predictable regardless of load, then you might have a viable business idea.
If you go the traditional corporate webdev route, and budget in worse case scenarios for AWS and other cloud services, it’s a lot harder to break even. You necessarily have to think bigger in every dimension - more customers, more support staff, more features, more marketing, more commitment, more everything.
If you went all in on Zig from day 1, then you can execute on good ideas with very little risk of it getting out of hand.
There is an infinite number of neat project ideas with limited market sizes that never get off the back burner, because the minimum total commitment of doing it right are out of reach for a lot of people. So you end up sucking it up doing the 9-5 corporate stuff whilst your neat project ideas rot away in your neat ideas journal instead.
You can substitute “zig” here with any low level, low dependency, hardcore tooling if you like.
One application I can see is in providing better tooling to the high level move-fast-and-break-things languages.
An example of this is with Frankenphp which provides multithreading support to the php ecosystem and is written in golang.
If php developers just wanted a server with better performance and concurrency while not having to learn a new language, Frankenphp could be a great choice.
I think zig would probably be best utilized for web dev in this way, not requiring users to know all the intricacies of both a new language and a different paradigm (low level development) but instead just giving new efficient features to existing tools.
That’s an interesting one… I’ve used similar tools in the past (Laravel Octane, Swoole), but always felt left out in the cold using them.
On a more Zig note though, you could argue that Zig is already used in web development in the form of Bun.
Having done years of full-time (low performance) web dev and just a touch of Zig, (meaning my opinion is irrelevant, I guess?) I would say that if Zig wanted to compete with Rust as a performance centric webserver language, they would need to add string manipulation to the standard library. So much of web dev involves concatenating strings, filling templates, trimming spaces, and so forth.
My process generally goes like this:
PHP (or js) → go → Zig
And it’s always hard for me to justify the jump to Zig when go is so much faster to develop with.
That being said, if you use ZMQ or similar for your worker queues, you can use any (or all) of these languages, and Zig slots in there perfectly.
I have built full NATS client specifically for this purpose. I wanted to have more and more of the backend in Zig. I was previously doing it using HTTP, but it turned out that having a NATS server is even easier to integrate for me, plus you can use other NATS JetStream features for free.
I opened discussion Foreign (non-PHP) Workers for Laravel Queue
and got clear response
I didn’t ask such questions anymore
I’m not sure Foreign Worrkers even solve the problem really, because Laravel’s Queue (and Symfony’s too) are fully synchronous. IMO, it’s really best suited for sending email, running database maintenance and tasks like that. If you need real-time updates or proper background tasks you’ll have a much nicer time just picking golang from the start.
Incedentily, I think Laravel is the anti-zig if we’re looking for web framework inspiration- everything about it is magical and hidden definitions. When you need to manually run a plugin that generates thousands of lines of helper code just to get basic LSP features, something has gone horribly wrong.
Just a quick clarification - tokamak is supposed to be more about structure/architecture and maintainability (dependency-injection, built-in libs for common use-cases). It is only fast thanks to httpz.
You can use httpz alone, but tokamak is really thin layer on top of it (in the end, it was not planned like this but it fits in really nicely).
