The performance looks outstanding!
The performance looks outstanding!
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.
It’s very much a kitchen sink language.
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.
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-...
- 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.
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.
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.
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 :).
Besides, is writing compilers and linkers, systems programming?
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.