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.

Why might I write unsafe Rust? To do something not particularly fancy. A use case covered by normal safe Fil-C. Why might I write unsafe Fil-C (compiler) code? To improve compiler or runtime performance or add new platforms, etc. Analogous to wanting to work on Rust's IR or borrow checker.

Very different use-cases.

"Blocks" are relevant as they are how you express programs, algorithms, etc., that you need in order to get something done. Lots of data structures in Rust have a little unsafe somewhere. Users will typically depend on some "specialist" crate author to write them, but it exists, and is a necessary part of practical Rust programming. The pool of unsafety is open and by necessity growing.

In Fil-C, no such specialists are needed, and the pool of unsafety is closed and fixed, no matter what programs, algorithms, data structures you use.

This is not a trivial distinction I think. I think it's easy to acknowledge, especially given its (current) performance cost.

If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

Have we not seen several examples of older such models exploiting the docker control socket, etc., to escape containers? Even the news isn't new.

I support it being repeatedly publicized, but a bit more of a straightforward description would be an improvement.