Question for Zig users:

Can comptime blow up compile times? Does it have arbitrary cutoffs like C++ template depth?

The issues with Go in that article only surfaced at Discord scale.

Under this strict definition you can’t even throw exceptions!

Then allow partial functions too. Maybe even require them to be tagged as such. (Is that within the capabilities of Zig's programmable type system?)

I don't mind escape hatches - as long as they're visible/greppable in the source code. You can always write undefined/error/panic/trace directives while you're coding, then come back and remove them later.

I would love a language that distinguishes functions (pure mathematical constructs) from procedures (imperative constructs that map in a predictable way to the instruction set).

This feels like the direction Algebraic Effects might take us.

Of course you can: you just have to define it in your type. The output set becomes a union type of the normal output and whatever you want as an exception.

If you write this as a monad, your get very similar syntax to procedural code.

I get what you are saying, but…

An exception is different to an Either result type. Exceptions short circuit execution and walk up the call tree to the nearest handler. They also have very different optimization in practice (eg in C++)

(Pure) expression orientation is the true marker of FP

Meta wants the models to be cheap and available because their strength is the context data and platform control.

When allocating engineering spend you need to predict impact. If you know how features of GitHub CLI are used and how you can do this more easily.

There are also atomic references when mutability is the best approach. This is forcing single writer but in the API rather than as a proof.

My understanding is litestream can lose data if a crash occurs before the backup replication to object storage. This makes it an unfair comparison to a Postgres in RDS for example?

Last I checked RDS uploads transaction logs for DB instances to Amazon S3 every five minutes. Litestream by default does it every second (you can go sub second with litestream if you want).

Yes but there is still a (small) window where confirmed writes can be lost

Right and that window is bigger for RDS by the looks of it.

Interesting - I had not looked deep into this before.

Is suppose the difference is RDS has high 9s, whereas in the Litestream case the frequency of crashes is tied to your application code and deployment process. In practice this will take more work to reach the same uptime?

Please can you link to the relevant guarantees? I did read the documentation just today so clearly misunderstood something!

A well designed system shouldn’t drop orders?

If you perform at least once processing then use Stripe idempotency keys you avoid such issues?

It was a fun read but I don’t understand the cult following this book has.