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?

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