All the posts on Matt's blog are pretty old. I'd asked him to please add dates to the articles to make this more clear but he was (and always is) very busy so I guess it didn't happen haha. I think the most recent post is at least a couple years old, though he does update the rest of the site (publications, current work, etc.).
In the spirit as written (i.e., not necessarily my personal from-scratch list), drop Perl and Ruby [1], add Javascript (the language itself; not necessarily any specific framework). Possibly add Rust to the list of currently-somewhat-exotic languages... depends on how the author feels, it doesn't 100% fit but it's not completely foreign either. (If you squint hard enough, it as arguably the closest current entrant in the "Haskell, but practical to actually use" contest... note I'm not saying it is the Platonic ideal of such things, but the closest currently existing thing.) Go is debatably getting into the C++/Java/C# set. I'd also add a note that you don't need to deliberately learn all of them; one from a given set is enough, pick up any specific one you may need later on demand. Possible exception for C++ which is so funky that I'm not sure you can just "pick it up", but it's been completely possibly to build careers in the industry without ever using it. I'm 23 years in and still yet to touch it professionally.
[1] Neither may be "dead" but at this point I'd have a hard time recommending either to a young person looking to get started. Python and Javascript are both clearly better choices for that case in 2020; if you do encounter a Perl or Ruby codebase you'll be able to pivot just fine from a strong grounding in Python or JS.
If you've internalized many of the interesting ideas of Haskell, check out Idris: https://www.idris-lang.org/
It builds on the ideas in Haskell (and similar languages) and adds proofs and first class types to the language. With it you can use the type checker to prove almost any invariant about your code that you care about. So the obvious stuff is there, prove that I never access an array out of bounds, sure. But also: prove that this code obeys this network protocol (e.g. never sends header before a successful handshake, never sends body before header has completed, etc).
Ordinarily the best that you can do is expose an API that enforces these constraints, but nothing is checking that the internals of the implementation of that API uphold the constraints. With Idris you can move that into the type system, so that changes that would introduce a protocol violation fail at compile time.
It's wild! And that's really only scratching the surface. It's still firmly in academia land, but the ideas present are fascinating and definitely worth puzzling through.
(The article is undated but was present on the Internet Archive in 2009, https://web.archive.org/web/20090106175608/http://matt.might...)