Zap – Fast backends in Zig(github.com)
github.com
Zap – Fast backends in Zig
https://github.com/zigzap/zap
68 comments
Thanks, we did a podcast interview this past Sunday on TigerBeetle, also looking at safety as a philosophy (beyond what any language can provide), that I hope you enjoy: https://www.youtube.com/watch?v=0pHHb6ONTbw
In what industries is Zig popular? I'm asking as I saw Zig as being the 'highest' paid language on the 2023 Stack Overflow Dev survey - https://survey.stackoverflow.co/2023/#section-salary-salary-...
The performance looks outstanding!
The performance looks outstanding!
My company uses Zig to write software for small Linux devices, such as set-top boxes.
The biggest benefit isn't exactly performance, but the absurdly tiny binaries it produces (very convenient if you are working with small flash disks!), and how the Zig standard library doesn't depend on anything other than the kernel, which means you can often entirely ignore all library issues; more often than not our software 'just works' when built for some new customer platform even though I've never even targeted that environment (or even CPU architecture) before.
The biggest benefit isn't exactly performance, but the absurdly tiny binaries it produces (very convenient if you are working with small flash disks!), and how the Zig standard library doesn't depend on anything other than the kernel, which means you can often entirely ignore all library issues; more often than not our software 'just works' when built for some new customer platform even though I've never even targeted that environment (or even CPU architecture) before.
If you don’t mind me asking, how long has your company been using Zig in production?
We first finished a Zig application three years ago, but that was a fairly small demo project which we didn't have to support afterwards.
Zig is very popular for WebAssembly: https://wasm4.org/blog/jam-2-results/
It's still pretty early on, but it's aim is to be a C successor I believe. Main example of usage off the top of my head is for bun.sh
how is that different from rust? or is rust a cpp successor?
Rust lives in the smart pointer world. So a good candidate as a c++ succesor. Zig lives in arena alloc and soa world. So it's a better than rust when you need performance beyond the norm.
Just to be clear, you can absolutely do arena allocation and soa in Rust.
In Rust you have convenient escape hatch with a default allocator. It's similar to say "you can do safe applications using C or C++".
Rust is more of a c++ successor, yes.
It’s very much a kitchen sink language.
It’s very much a kitchen sink language.
Zig is still rather new, but it would be a good alternative to C, C++, Rust and Go.
Zig is mostly a good alternative to C.
If Rust or C++ are possible options, Zig probably isn't what you really want. Rust is especially good if you can keep everything in Rust and make the most of the ecosystem.
I like Zig, but it is a much smaller language that C++ or Rust with more than a few very, very sharp edges. That having been said, I reach for Zig in a lot more instances than I thought I would. I write a lot of relatively small programs that I want to work on Linux/Windows/macOS, and Zig is pretty good at that.
Of course, I miss Rust terribly every time I run a Zig program and get a segfault.
If Rust or C++ are possible options, Zig probably isn't what you really want. Rust is especially good if you can keep everything in Rust and make the most of the ecosystem.
I like Zig, but it is a much smaller language that C++ or Rust with more than a few very, very sharp edges. That having been said, I reach for Zig in a lot more instances than I thought I would. I write a lot of relatively small programs that I want to work on Linux/Windows/macOS, and Zig is pretty good at that.
Of course, I miss Rust terribly every time I run a Zig program and get a segfault.
Can Zig also be used to compile static libraries for iOS and Android?
There's no good reason why not. Zig is, after all, a full C compiler so it can certainly create C libraries.
You can create a full Zig program to run on Android: https://archive.fosdem.org/2021/schedule/event/zig_android/
iOS: https://www.jakubkonka.com/2022/04/30/ios-dx-with-zig-milan-...
You can create a full Zig program to run on Android: https://archive.fosdem.org/2021/schedule/event/zig_android/
iOS: https://www.jakubkonka.com/2022/04/30/ios-dx-with-zig-milan-...
The first three, but not Go.
Depends on your use cases. The reason I love Go are:
- Simplicity and readability
- Batteries included: projects don't have to depend on too many 3rd party dependencies
- Same code can be easily compiled to many different architectures
- Fast compile time
- Large ecosystem
With the exception of the large ecosystem, Zig offers a similar experience.
- Simplicity and readability
- Batteries included: projects don't have to depend on too many 3rd party dependencies
- Same code can be easily compiled to many different architectures
- Fast compile time
- Large ecosystem
With the exception of the large ecosystem, Zig offers a similar experience.
Why not Go? Not very comparable due to GC and goroutines?
Right. The others are system languages you could write a kernel or a game engine in.
I'm going to be pedantic here, but this merely means that Go can't fill Zig's niche.
Zig can (in a lot of situations) presumably easily fill Go's role. Both languages have a focus on simplicity and explicit syntax.
In other words, Zig is in fact a decent alternative to Go. Go just isn't a good alternative to Zig.
Zig can (in a lot of situations) presumably easily fill Go's role. Both languages have a focus on simplicity and explicit syntax.
In other words, Zig is in fact a decent alternative to Go. Go just isn't a good alternative to Zig.
Zig isn't memory-safe, and you're not going to pay for the development overhead of manual memory management if you're doing regular back-end stuff.
People did for decades and a lot of that "regular back-end stuff" is in C++ at the moment. If you wanted to move it to a different language, you might currently choose to move it bit-by-bit to Go. But you could also move it bit-by-bit to Zig, and it wouldn't be an unreasonable choice. Zig is in that sense an alternative to Go, IMO.
> People did for decades
Yes, but it was before the invention of mobile phone… Since Java came out, the majority of back-end has been written in memory-safe language, for good reasons.
> you might currently choose to move it bit-by-bit to Go
Not even Google, the home of Go, has been doing a C++ to Go conversion. Backend services that are still in C++ in 2023 are probably so for good reasons, most likely because they either have:
1. really high performance requirements, hence no Go.
2. low budget, and are mostly maintained as it is, hence no rewrite.
In any case, those are only a fraction of the total backend code, which is mostly PHP, Java, and Nodejs.
Yes, but it was before the invention of mobile phone… Since Java came out, the majority of back-end has been written in memory-safe language, for good reasons.
> you might currently choose to move it bit-by-bit to Go
Not even Google, the home of Go, has been doing a C++ to Go conversion. Backend services that are still in C++ in 2023 are probably so for good reasons, most likely because they either have:
1. really high performance requirements, hence no Go.
2. low budget, and are mostly maintained as it is, hence no rewrite.
In any case, those are only a fraction of the total backend code, which is mostly PHP, Java, and Nodejs.
[deleted]
AFAICT you could technically use a GC'd language for either, perhaps just not best suited for it.
On the other hand, Zig can fill the niche Go does, but again, probably not best suited for it.
I guess I'm just being pedantic here :).
On the other hand, Zig can fill the niche Go does, but again, probably not best suited for it.
I guess I'm just being pedantic here :).
If you really want to be pedantic, Zig could maybe be considered a GC’d lang, if you count selecting a GC for as it’s allocator (presumably with some ugly(?) comptime assurances) ;-)
[deleted]
There are production examples of both, written in Go.
Besides, is writing compilers and linkers, systems programming?
Besides, is writing compilers and linkers, systems programming?
> the performance looks outstanding!
Well, given that in their benchmark Go ends up Boeing almost an order of magnitude raster than Rust, I wouldn't trust their benchmarking methodology too much.
Well, given that in their benchmark Go ends up Boeing almost an order of magnitude raster than Rust, I wouldn't trust their benchmarking methodology too much.
Wasn't Uber using Zig? At least for it's cross-compiler features, if I recall properly.
Yes, Uber use Zig: https://www.uber.com/en-FR/blog/bootstrapping-ubers-infrastr...
Wraps the C library https://facil.io/. I hope they port it & go pure Zig at some point.
Are there advantages to this other than, I guess it being convenient? (Zig noob here.)
Eg, are there C to Zig ports that have had a demonstrable performance or memory-safety gain or something like that?
(Specifically, I mean over a C-lib wrapper compiled using Zig, as matching this case.)
Eg, are there C to Zig ports that have had a demonstrable performance or memory-safety gain or something like that?
(Specifically, I mean over a C-lib wrapper compiled using Zig, as matching this case.)
The Zig compiler itself is a good example: https://kristoff.it/blog/zig-self-hosted-now-what/
"The new self-hosted compiler reduces memory usage 3x compared to the old C++ implementation"
"The new self-hosted compiler reduces memory usage 3x compared to the old C++ implementation"
Have to point out that this includes second system optimizations. Just porting C over to Zig won't give you that 3x reduction. For others, I also highly recommend the video linked in that blog post.
Are they also blazingly fast producing CVEs?
Given the current state of use-after-free and similar issues.
Given the current state of use-after-free and similar issues.
Congratulations! This is really great. I am going to try it.
In your benchmarks, consider adding actix which is also in Rust but considerably faster than rust axum according to: https://www.techempower.com/benchmarks/#section=data-r21&tes...
In your benchmarks, consider adding actix which is also in Rust but considerably faster than rust axum according to: https://www.techempower.com/benchmarks/#section=data-r21&tes...
There might also be a chance you can have your webserver included in the techempower benchmarks for their next round. Their code is submitted by experts and open-source: https://github.com/TechEmpower/FrameworkBenchmarks
Techempower benchmarks are not a good measure of real-world performance. Everyone cheats on them, they don't do a great job of matching realistic workloads, and there's plenty of unresolved issues filed about methodology problems.
Actix also used to be the poster child for overly focusing on benchmark performance at the expense of real world concerns.
Actix also used to be the poster child for overly focusing on benchmark performance at the expense of real world concerns.
Does Zap add the datetime in every http response as header because Go does it and those are syscalls so it reduces performance.
That shouldn't reduce performance too much, right? Getting the current time is such a frequently-executed system call that, as far as I understand, its implementation is in a vDSO in Linux that is loaded into every process. This means you shouldn't need the full cost of a system call when you get the current time.
Nice to see someone else thinks about this.
In my personal project webserver I don't. I didn't measure, but just trying not to do unnecessary work.
In my personal project webserver I don't. I didn't measure, but just trying not to do unnecessary work.
What a wasted opportunity to call it zag.
Zap sounds fast and active, which is definitely a goal of the project.
Zag sounds like it's inefficient.
Zag sounds like it's inefficient.
Rust sounds like something old and crusty. No one will ever adopt a language called Ru...
> Rust sounds like something old and crusty.
True
> No one will ever adopt a language called Ru...
I never made this claim.
True
> No one will ever adopt a language called Ru...
I never made this claim.
Very cool - this is a big missing piece in the zig ecosystem. Wish the project all the best.
wow, I had not heard of facil.io (the thing this is based on)—I'll have to give both of these a look, as I'm working on something conceptually similar. neat!
Facebook's Proxygen is also pretty neat: https://github.com/facebook/proxygen
interesting! I was looking for stuff like this awhile back when I started my project and couldn't find anything—I probably was using the wrong search terms.
my goal is to create a simple web framework that produces a single compiled executable, but I don't want to care too much about the HTTP(S) server portion, if possible. I have a functioning prototype, but the wrote-it-myself-and-it-shows HTTP server part sucks, so, hopefully I can find something to replace it with, instead of diving deep and writing something like this on my own.
my goal is to create a simple web framework that produces a single compiled executable, but I don't want to care too much about the HTTP(S) server portion, if possible. I have a functioning prototype, but the wrote-it-myself-and-it-shows HTTP server part sucks, so, hopefully I can find something to replace it with, instead of diving deep and writing something like this on my own.
[deleted]
How does it compete with Node.js? The benchmark (req/s) compares Zap with Rust, Go, etc. But I don't see any mention of Node.js.
Node.js should be way slower, given that JS is an interpreted language and the others aren't.
Not really. All modern JS engines, including V8 that Node uses, include excellent JIT compilers.
Also, HTTP serving in Node uses code written in C, not JS.
That being said, Node is slow compared to Bun: https://bun.sh
Also, HTTP serving in Node uses code written in C, not JS.
That being said, Node is slow compared to Bun: https://bun.sh
At the expense of memory usage, predictibility, and worse P99s.
Faster than axum? Nice!
Keep in mind that microbenchmarks aren't necessarily representative of production performance.
* Some webservers "cheat" and skip a lot of request headers which one may want to use in a production scenario to get better numbers.
* Some web server architectures can do very well on many small uniformly sized requests but poorly on a mixture of request sizes.
* Some web server architectures can get very good average latency but poor p99 latency.
* Some benchmarking tools don't measure correctly: https://medium.com/@siddontang/the-coordinated-omission-prob...
etc.
* Some webservers "cheat" and skip a lot of request headers which one may want to use in a production scenario to get better numbers.
* Some web server architectures can do very well on many small uniformly sized requests but poorly on a mixture of request sizes.
* Some web server architectures can get very good average latency but poor p99 latency.
* Some benchmarking tools don't measure correctly: https://medium.com/@siddontang/the-coordinated-omission-prob...
etc.
The benchmarks only include throughput, not latency (P50, P95, P99), which are quite important.
yakkityyak(4)
I would also be interested to hear the compile time, binary size and memory usage of those example apps.
Looks like the underlying facil.io library hasn't seen any commits since 2021, so that's a bit of a red flag. https://github.com/boazsegev/facil.io