|
I wouldn't advocate for the curl project to experiment with rewriting some code in [Zig](http://ziglang.org/) yet, due to lack of maturity, but it is exactly in the target niche of the project. That is, near-seamless integration with a large pre-existing C codebase. So you could, for example, take a 400 line C file, convert it to Zig, and have it import the .h files that the previous C file was including, and export an .h file for the rest of the codebase to look at. The compiler can turn this Zig file a .o file that integrates with the rest of the build. The part of the codebase written in Zig could benefit from the safety features, generics, and error handling features of the language while presenting the same interface to the rest of the codebase. Now of course, if you already have a codebase written in 1 language, it's more complicated to introduce another. This is where the Zig build system comes into play. I'm working on this now, and it's a competitor to autotools, scons, cmake, make, and all those players. It's the Zig programming language with a declarative build system API built into the standard library with some basic tooling around it, and it ships with the compiler. So if the Zig build system gets to the point where it is high quality enough to attract users and ubiquity in package managers, then a project which already uses Zig for its build system can start using it for its actual code without the penalty of adding a dependency. In conclusion, once Zig has reached a stable enough state, I would challenge the libcurl devs to consider, perhaps it could make sense to slowly, carefully, methodically transition to a newer language, if that language was friendly enough to the process. |