Seeing this, and the use of zig for https://github.com/tigerbeetledb/tigerbeetle I wonder if zig might become a good tradeoff vs rust for servers if in long term it's more readable and maintainable and with a different approach to quality.
I would also be interested to hear the compile time, binary size and memory usage of those example apps.
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
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.
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.
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.
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.
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.
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) ;-)
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.
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.
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.
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
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.
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!
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.
I'll just say it: there's always that person who has to come in and tell people how a projects name is named the same as some random thing in the universe, then scours the internets playing the "when was it first created" game. I'd say no one cares, but then there's 'that person' who clearly does! weird.
I don't particularly care, but it's lazy. It's nicer if people try and pick something unique and unambiguous in the domain, so searches don't clash. Obviously, that's not always possible, but in this case, I'm not giving them the benefit of the doubt.
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