Citation needed on "well-established". I find myself often benefiting from Haskell's disciplined approach to effects.

" (beyond the well-established Haskell-esque effects bad)"

read that as:

"beyond the well-established idea, from Haskell, that side effects are troublesome and need to be explicitly modelled and thought about."

Ah, I think your clarification makes a lot more sense than your original phrasing, because Haskell's position is indeed that side effects are bad, not that effects are bad. The bad thing is "side", not "effects".

Another possible takeaway is to start from something 'principled' (for whatever definition of principled you like) and then add functionality, rather than starting on shaky ground and trying to patch it up later.

From memory the example in the video was 'pure functions first - then figure out IO'. But it could just as easily apply to memory safety, or nulls.

Why build a new language with state-of-the-art static analysis for detecting nulls, when you could just refrain from putting nulls into your new language?