> We're going to need a few language extensions, so let's get this out of the way first: {-# LANGUAGE RankNTypes, GADTs, MultiParamTypeClasses, KindSignatures, TypeApplications, FunctionalDependencies, FlexibleContexts, FlexibleInstances, UndecidableInstances, IncoherentInstances #-}

Dang, how do you know to use that?

There's a bunch here that are sort of "We need X so we also must enable Y and Z". For instance, FunctionalDependencies requires MultiParamTypeClasses and IncoherentInstances requires UndecideableInstances and FlexibleInstances.

Quite often the error messages will tell you what extension to enable to use that construct.

The same way you know to import a library? It's just importable language features, mostly in existence to not force trade-offs or backwards incompatibility on everyone willy nilly.

I thought it was weird when I moved from Scala to Haskell but now I am unimpeded by it thanks to practice.

This feels absurd indeed. Like half of the GHC extensions introduce only some trivial syntactical convenience whereas the other half each introduce practically a whole new language.

This list aligns more with the latter description.

All of those extensions match the description of "things one thought that Haskell should have been able to do anyway" (some more tenuously than others, granted).

IncoherentInstances?

I wish C++ features had that level of transparency and control.

This is Haskell's equivalent of node.js' dependency hell.

Hardly, Cabal Hell is the Haskell equivalent. You can enable all these extensions module wide by putting them in your project file. This is more a case of having to learn a plethora of advanced Haskell extensions, and when to use them.

And cabal is vastly improved nowadays anyways. I'm not familiar with npm, but does it have anything like cabal's Nix-style builds?

No, it's equivalent to python's "from __future__ import foo"

vmap is by far my favorite feature in JAX. Very cool to see that you can get the same thing straight out of haskell.