Translating library usage from C# to F# is pretty mechanical so not sure if specific docs are needed.

The larger issue is the C# community loves OOP so you often have to wrap these libraries into something more “FP” if that’s how you want to work.

Overall it’s far better than having nothing (looking at Haskell, OCaml as much as I enjoy them!)

It’s really hard to please everyone all of the time on this front.

This kind of thing is why Roc compiles to WASM but not JS.

C++ could use some do-notation

Abstracting any part of code structure in C++ is a wasps nest that will attack you back.

Did you mean "abstract you back"?

Being abstracted by code you just wrote is quite a painful experience, yes.

Question for Zig users:

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

You can think of comptime (as of zig 0.16) as an interpreter that evaluates code with very limited optimization. So yes, naive use of comptime can definitely grind compilation to a halt.

Zig tackles the halting problem a bit differently by putting the evaluation cutoff in userspace through the compiler builtin function `@setEvalBranchQuota`. You bump up the quota as you see fit.

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

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

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++)

I'm what way is that different? You return early and the call Cascades up the call chain until you handle it (otherwise it's always an "either" results)

In practice you use something like an exception monad, which makes this a lot more ergonomic since you don't need to carry a case distinction around for every unwrap: an exception monad essentially has an implicit passthrough that says "if it's a value, apply the function, if it's an exception just keep that". You only need to "catch" the exception if you actually need the value. I'm this case the exception monad is not that different from annotating a function with "throws": your calling function either needs it's own throws (=error monad wrapper) in which case exceptions just roll through, or you remove the throws, but now need to handle the exception explicitly (=unwrap the monad).

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.

(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.