In my experience, languages that try to bridge OO and functional ecosystems (F#, Scala, etc) tend to suffer from a lot of split-brain / "worst of both worlds" syndrome. You miss a lot of the advantages of FP unless you go all-in on it like Haskell does.

My experience with F# is that functional programming is the default paradigm while object oriented is used when it is required or easier (or required by a C# library you really want). A striking difference with the little Scala I read in the wild (where object oriented was the clear default).

The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default.

> The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default.

This is also true for Haskell. It's not especially hard to get and use mutable variables, they're just not something that most tutorials cover.

Haskell has confined mutation with the State and ST types, which guarantees that whatever may be going on inside, the external interface to the function is pure. My main problem with F# (and other multi-paradigm / "functional-first" languages) is that they do not provide any such guarantees; purity becomes merely a matter of convention and convenience, not something ensured by the language. This misses the entire point of functional programming, IMHO, which is referential transparency, and greatly increases the complexity since there are things that matter in F#, like evaluation order, which purity renders completely irrelevant in Haskell.

(Yes, Haskell does have unsafePerformIO and the like for special cases, but the expectation is still that the external interface remains pure. If you deliberately circumvent the language's protections and fail to adhere to this rule then you get to keep both pieces when it inevitably breaks. The compiler is still going to operate under the assumptions that the result depends only on the explicit inputs and that evaluating the function has no side effects.)

> You miss a lot of the advantages of FP unless you go all-in on it like Haskell does.

I'm not familiar with F# but Scala at least has a far inferior compiler (compared to GHC). There are a lot of functional techniques that simply don't make sense when you don't have dedicated tooling to support them.

I've done something very similar, albeit with a more bottom-up approach. Pretty much everything he's suggesting is good advice.

This sort of thing makes me very glad I live in a country with legally guaranteed employee entitlements and public healthcare.

California does have some legally guaranteed entitlements if (edit) there is a mass layoff. Apparently like this case if a company just goes under with no money left that doesn't apply. What is the situation in Europe? The healthcare continues, but if a company has no money who pays the entitlements? Do employers have to fund a reserve? Or the govt pays?

In Australia (where I'm from) companies are legally obliged to keep enough cash on hand to cover employee entitlements, which at minimum is pay for the notice period + accrued leave + superannuation (may be more depending on your contract and time served with the company).

Above that, employee entitlements get paid out first in the event of bankruptcy/wind-up (i.e. before any investors or creditors see a cent).

Also, any director of a company that doesn't comply (i.e. keep enough cash on hand) is likely to 1) get banned from being a director of a company, 2) prosecuted, and worst of all 3) get reamed by the tax-office for the amount owing.

Healthcare is almost entirely public here. Employer-provided private health insurance is rare.