> One has to keep far more in your head writing Haskell than Go

I don't think that's really true. I think that's a subjective description of a feeling whose presence or absence depends not how any objective difference in the quantity of things that you need to keep in your head with either language, but with how well each language fits one's (subjective) intuition.

Mental load isn't an objective feature of a language, its a subjective feature of a particular programmer's relationship with a language.

I don't think you can really learn C in a weekend. Not with all the ins and outs of undefined behavior. And if you don't know your way around the undefined behavior in C, you're going to make dangerous mistakes.

For various meanings of 'learn'. My point is that you can be writing useful programs in c in a weekend.

Obviously said person would not be an expert, but I've watched competent programmers try to learn complex languages like Haskell and Scala; there is a far more complex mental model that one needs to build before they can use those languages specifically because of all the automagic that happens in the background.

Having watched both complete beginners and competent programmers try to learn Haskell my observation is that hard part initially for the competent programmer is not building the necessary mental model, but tearing down their existing mental model. People with no mental model going in tend to just look at Haskell, go "I guess that's the way things work", and get on with it. Their real problems first arrive when they then go on to try to learn for example Java which has an entirely different model.

> My point is that you can be writing useful programs in c in a weekend.

We'll need to define criteria for "useful program" but I believe most people could write useful programs in most languages in a weekend.

> I've watched competent programmers try to learn complex languages like Haskell and Scala

> far more complex mental model

I think its more that those languages are different, not that they require a more complex mental model.

Can we at least agree here that complexity implies a larger cognitive burden? I think that's a pretty benign statement to begin from regardless of the domain (programming, cooking, games, etc).

A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail. A simple recipe might not offer the results but it should be easier to produce with a lower chance to mess up.

I think the concept generalizes here.

> Can we at least agree here that complexity implies a larger cognitive burden?

Right, but remember simple doesn't necessarily mean easy. The reason I use functional languages is because in my experience they handle complexity better.

> A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail. A simple recipe might not offer the results but it should be easier to produce with a lower chance to mess up.

> I think the concept generalizes here

I of course mostly agree to both of the above, but I think you are mis-characterizing functional languages such as Haskell which are simple but quite different from languages most are used to.

> A complex recipe rewards a chef with exceptional results if they follow it perfectly, but also presents more opportunities to fail.

Agreed, which is why I prefer to implement complex ideas in Haskell. It catches more potential errors than other languages.

I strongly disagree that features don't lower mental load. For example:

Go's error handling is to put it nicely a joke and requires a lot of effort to manually check every single error condition that may arise. Exception handling makes life exponentially simpler. You can ignore, group and delegate errors at any point which is hard if not impossible to do with Go.