bnolsen

of course the asus rog z13.

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...

C++ and rust make these optionals ugly. Zig does it right. Zig also forbids null pointers and requires use of optionals.

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.

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.

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.

I guess the 'zit' name was already taken by something else.

The radeon 8500 deserves to be on that list. It still has active Linux support under mesa.

HTML is not something to hold up as the standard for documentation.

Why not just use zig for the entire thing?

Not to be confused with zlib.

Except for all the baggage it carries along with it including hacks to address baggage resulting in a very bloated language.

Quaternions are left handed spinors. Please use the correct unified math models (clidfford algebra) rather than these 3d only hacks.

Having worked with c++ strings and also string views I find zigs simple fat pointer to be fairly direct and straightforward, and a bit refreshing. Ownership is being coupled in with the type..

And then zig shows up...

It's christmas and not april fools!

I remember seeing this a long time ago and liking it, I just didn't have a use for it at the time. How does it stack up against luahit for perf and memory, and threading? It also looks like it could be worth looking at porting the compiler to zig which excels at both compiler writing and cross platform tooling.

Work gave me an m1 pro with 32gb on it. A year ago I put together one of those minisforum board+laptop apu with 64gb ram and 2tb nvme for not much money at the time, likely 500usd. For the performance sensitive software I was working on the 7935hs ran with about 50x more throughout using compilers with llvm backend.

There's active work towards that (which could run as part of CI) and it looks very promising: https://github.com/ityonemo/clr

Zig actually does bring some new and innovative ideas to programming. While Zig itself may not become the next big thing a lot of ideas in it most certainly will find their way into languages moving forward.

And they tried to hang him for it. I wasn't particularly pleased with some actions he took after he ran off but the government reaction was truly out of hand and forced him into full survival mode. This part of government is full of weird power crazed spooks.

they are very awkward to use in the current STL, they are part of the template definition. Back in the day EASTL did allocators much better but it never became a thing.

This confuses me. In zig null pointers are illegal, and I have yet to run into any case that should be addressed by using pointer arithmetic, that's all taken care of with slices.

you could fully redesign libc to be modern and toss out the null terminated string concept and use fat pointers and slices. But at that point why not consider moving onto a more modern language with things like explicit type conversions, modern PEG type grammar, etc.

I might buy your argument except that without corporate sponsorship for zig several projects using a very young and unfinished zig exhibit world class performance and utility, apparently without herculean effort.