buz, a fork of bun right before the rust rewrite, claims sub second incremental builds just by using what zig itself provides.

https://micrologics.org/blog/architecting-sub-second-javascr...

That's called a fat pointer. Null terminated c strings is the majority of memory errors out there.

I was doing this for remote sensing orthorectification work back in 2004/2005. It works very well across multiple types of imaging sensors.

I personally think something like the qok format is a better way to go. Make something that performs well and is dirt simple to implement.

No it would not, qoi falls behind even my 2011 WebP lossless design.

Also, it is not a competition for the shortest specification. If it was, still good. Jpeg xl spec is about half the size of the original jpeg spec.

QOI supports a VERY limited set of use cases compared to jpegXL.

QOI is cute as an experiment, but it is not a serious image format unless you work in extremely constrained environments.

It's pretty sad it used to not be so bad in the US. This is what happens when ethics and morals are removed from the culture.

I would think that you might have a better time going from go to zig. You would have to provide a pattern for implementing the interface model go uses.

What are the benefits of moving from Go to Zig?

It seems like you lose a lot (automatic memory safety, simple language, easy concurrency) and gain very little.

Zig fails unit tests if there's a memory leak in those tests.

One of the core design principles of zig is no implied behavior.

Unit tests in zig will fail if the tested code leaks memory.