Probably best to go to the index and look at part 1 of the saga.

If you build a product on a bad database, you cannot load the blame for the resulting bad product on the bad database. If it was not fit for purpose, then the product designers are the problem as much as anything else.

This applies doubly for a product that relies so heavily on automation enabling speedy responses with heavy consequences.

I understand that this may smack of perfect being the enemy of good, but this domain is akin to medical devices in terms of impact.

> About the role

> "Men wanted for hazardous journey. Low wages, bitter cold, long hours of complete darkness. Safe return doubtful. Honour and recognition in event of success"

> You gotta be in founder mode.

> Next.js web / React Native app. / Supabase, firebase, and Prisma. / Nest.js for WhatsApp / Open AI and Anthropic APIs for agents / Solidity and web3.js for Smart contracts. / A lot of Typescript.

It is a reference, but seemingly also sincere, at least to a non-trivial extent.

Edit: I do not mean this to imply the same company as in the OP

Using this native (written in Zig) C compiler to translate C source into Zig source as a part of the build, would presumably lend itself trivially to all the incremental logic in TFA, as updating C would update the generated Zig, and the incremental logic would detect differences just like it detects differences made by a human in an editor. Maybe there are aspects of the generated Zig that would complicate that somewhat, but I don't know -- just a warning about my ignorance.

This is part of plans to remove the hard LLVM dependency. AFAIK, the LLVM dependency will still be a variant many will use for the convenience of Zig as a much better clang, but removing the hard dependency is part of enabling all these great features like incremental compilation.