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.

Rust supports arena allocator https://docs.rs/bumpalo/latest/bumpalo/ and the dropping plays well with arena as long as you use bumpalo::boxed::Box

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

Many problems in article are specific to old versions of iOS which is only in old versions of iPhone. Most old iPhone users are not potential paying customers. iOS need to be supported but old versions of iOS don't.

I head that Jane Street use OCaml and said similar thing. Although there are few OCaml developers they are overall better so hiring is easier

Key sentence

Because you weren’t suffering from too much work, you were suffering from too little truly important work.

Not being able to store mutable ref in other type reduces expressiveness. The doc already mentions it cannot allow Iterator that doesn't consume container

https://github.com/rue-language/rue/blob/trunk/docs/designs/...

No silver bullet again

Modern large productivity software (including IDE) are often "fragile".

Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.

Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.

Sometimes the IDE itself has random bugs.

A lot of time is spent workarounding IDE issues

There is nuance distinction between "fundamentally work faster" and "being pushed to work faster".

The first is what to optimize. The second "being pushed to work faster" often produce bad results.

https://x.com/jamonholmgren/status/1994816282781519888

> I’ll add that there’s also a massive habits and culture problem with shipping slop that is very hard to eradicate later.

> It’s like a sports team, losing on purpose so they can get better draft picks for the next year. It rarely works well because that loser mentality infects the whole organization.

> You have to slow down, do it right, and then you can speed up with that foundation in place.

This reminds of me Makimoto’s Wave:

https://semiengineering.com/knowledge_centers/standards-laws...

There is a constant cycle between domain-specific hardware-hardcoded-algorithm design, and programmable flexible design.

I put some article content to Pangram. Pangram says it's AI

https://www.pangram.com/history/282d7e59-ab4b-417c-9862-10d6...

The author's writing style is really similar to AI. AI already somehow passed Turing test. The AI detectors are not that trustworthy (but still useful).

The overuse of emoji make me suspect it's AI. I plugged first paragraph into pangram and result is 100% AI.

https://www.pangram.com/history/30310094-f54b-4e74-8d68-e4c9...

It's probably KPI-driven. Devs are punished by any visible error. So dev hides errors.

It's also possible that OpenAI use many human-generated similar-to-ARC data to train (semi-cheating). OpenAI has enough incentive to fake high score.

Without fully disclosing training data you will never be sure whether good performance comes from memorization or "semi-memorization".

Once a metric becomes optimization target, it ceases to become good metric.

React server component is frontend's attempt of "eating" backend.

On the contrary, HTMX is the attempt of backend "eating" frontend.

HTMX preserves the boundary between client and server so it's more safe in backend, but less safe in frontend (risk of XSS).

Any attempt that blurs boundary between client and server is unsafe.

Egison is a pattern-matching-oriented language https://www.egison.org/