alt Hacker News> I want to see the next Blender, the next Postgresql, the next Linux. This is my vision.
Do you think it makes sense to augment these existing (and successful) open source projects with Zig (language and/or toolchain)? Or should something grassroots and written primarily in Zig be their eventual successor?
Replies
Now that you mention it I forgot an important one! I want to see the next VLC. And in fact J-B has mentioned on IRC that he would be interested to see contributions to the project using Zig.
I interpreted it as examples of excellent open source software that Andy wants to see more of. Not that those projects should be replaced.
Specifically, those are applications that are arguably better than their proprietary alternatives.
Perhaps we can se a
* DAW
* Photoshop alternative (no, gimp was never it)
* Video editor
Why contribute to a monopoly when you can lay the foundation for greener grass for more competitors?
There's arguments both ways; what it really boils down to is what you value.
This is one of the shining features of the language: either of these is a viable option. Zig is a great way to build C projects, with native cross-compiling, and the semantics make it straightforward to supply a C API for Zig libraries to add to existing code in C. Depending on the specifics, it can make sense for a C codebase to switch to Zig's build system just for excellent cross compilation, without writing anything in Zig.
I think once Zig stops being a moving target, we'll see an increasing number of C codebases writing some of the new code in Zig, moving over to the build system, and taking it from there. There are a lot of decisions which make this easy. As an example, idiomatic Zig code which allocates memory receives an Allocator, where C uses malloc and free. So there's a C allocator, which provides the Allocator interface to malloc and free, meaning Zig code can create objects and pass the memory to C, which can free it later.
There's a lot of C code out there which is working just fine, and if it ain't broke, no need to fix it. But if it's easy to do new work in a nicer language (to my taste, Zig is definitely that), why not? Then maybe rewrite some preprocessor-heavy C code using comptime.
The main thing holding this back (though it's already happening) is that Zig is pre-1.0. That imposes a maintenance burden which not everyone is willing to take on. But that won't last forever.