delifue

The article says some Zig advantages but it's worth noting that all these advantages are tradeoffs.

Zig makes handling error easy but makes retaining error information hard. The result is that Zig developers either write more code than other languages to store diagnostic information, or just simply discard diagnostic information. The second makes it much harder to debug because the useful error information is discarded.

About the TigerStyle, it's worth noting that TigerBeetle doesn't even support variable-sized string type. You can store fixed-sized data, such as a string that's at most 32 bytes. What if the order information contains string longer than 32 bytes? Then you need to store that string in antoher database. TigerBeetle is not a general database. Static memory allocation doesn't fit most applicaitons.

The fallable allocation is useful in embedded system and OS development etc., but useless in common application programming, because OOM results in crash rather than failed allocaiton.

Article likely AI-generated.

AI will be much more powerful than ramanujan. ramanujan is just one person with limited energy, but many instances of AI agent can work in parallel and attack all open problems at once

When people refute the idea that "LLM is the new compiler from natural language to code" the common reason is that LLM is non-deterministic but compiler is deterministic.

But the determinism isn't the real distinction. LLM inference can be made deterministic (temparaute zero, etc.). And multi-threaded compiler can be non-dterministic.

And human developers are also non-deterministic. There is always the nondeterminism even before AI.

I think the real difference is how leaky the abstraction is. If you just need to understand language instead of compiler internal to write correct code, the compiler is non-leaky abstrction. If you rely on compiler to do auto SIMD optimization, and have to do hacks to trigger the optimization, compiler is leaky abstraction.

For AI, if you don't ever need to read the code and AI writes perfectly bug-free program that perfectly follows instruction, then AI is a non-leaky abstraction, but that's not the case for now. To make code maintainable and debuggable you still need to read the code if the project is complex enough.

Overcommit is very common now, including desktop, mobile and server, even in contianers. Checking malloc returning null only prevents OOM in places like embedded.

Yes, same applies to Rust

There is a nuanced mistake in

> If your machine runs out of memory, reversed[i] will cause a segfault upon being accessed. In order to avoid unhelpful segfaults, the program should check for a null pointer and gracefully exit if one is found

If overcommit is enabled (often by default), malloc will not return null when machine runs out of memory. malloc will still return null if input argument is invalid (e.g. too large).

The culling that relies on previous frame has artifact when one object is newly visible (it will be not rendered in the first frame that it becomes visible).

One reason it's easy to leak goroutine is that channel producer blocks waiting on consumer, once channel consumer exits the producer goroutine leaks. Go doesn't allow consumer to close the channel.

In Rust when receivers all drop, the producer will error instead of blocking, so Rust is better in this aspect.

I roughly check it. The array looks like tree in type defintion, where indexing is O(log n), but the real implementation seem to be real array with O(1)

The Type thing is affine type similar to Rust ownership. The array in-place mutation relies on affinity to avoid deep copying. The Data thing is reference-counted if shared, like Rust Arc. The parallel invocation is similar to Rust's rayon::join .

About the proof system, I am not familar with formal verification, but it's obvious that the translation from business requirement to proof target still requires coding and can contain bugs. Even if proof is fully correct, if proof target deviates to business requirement then it still have a bug

It's not like leftpad. It uses segmented array and interally does synchronization, not a simple wrapper to Vec. The append only takes immutable borrow. Its capability cannot be replaced by RefCell because RefCell doesn't allow appending while keeping borrow.

The author says it's "100% accurate and free of hallucinations" but I am sceptical. Although I don't know much about chip production, when I ask LLMs about advanced topics like memory order LLMs tend to hallucinate more than entry-level questions. But the point is that I didn't found that LLM hallucinated before knowing it deeper. It's possible that LLM hallucinates but you don't find out because you are just learning it.

How does static allocation avoid wasting memory?

Static memory allocation requires hardcoding an upper limit of size of everything. For example, if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.

If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.

Unfortunately web API doesn't yet allow drawing multi-line text in canvas. To draw multi-line text in canvas you need a layouting library