While I mostly agree, the flip side of this statement is, the language then does not automatically take care of things that then you have to keep in your head while you're solving the problem.

I guess this is the underlying trade-off people make when using "higher-level" or "lower-level" languages. More "powerful" languages do more for you automatically, but you need more up-front investment in really understanding the language and applying it to the problem at hand.

And since we are all individuals with individual preferences, whatever choice you make is totally valid for you. It does not make sense to look down on the choices of others. On the other hand, there are some concepts that really are well-understood enough and apply to a large spectrum of languages. These should see widespread adoption, and it does not make sense to deny this either.

Sure, language like Haskell or Rust have a ton of great features and automagical things but I disagree that they are easier to use. One has to keep far more in your head writing Haskell than Go, a clear indicator of this is the difficulty in learning the language. Like c, you can learn Go in a weekend easily.

I am not saying those others types of languages don't have their own strengths, just that I disagree with your assessment that their features provide a lower mental load.

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.

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.

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.

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.

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.

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

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.

This. And the additional effect is that you can keep more of the problem domain in your head as well. I've been in this game a long time, and my experience has been that the simpler the dev tools, the more likely the programmers working on a particular domain will be SME's in that domain.

Whether you write it in Ruby, Java, Go, Assembler really doesn't change this. It just means you may take longer to do it.

And your logic falls apart. If simple dev tools translate to greater productivity then how do you explain the proven benefits of IDEs with all of their "complex" features.

As a fellow Go coder, I'm actually stunned how much I can get done without a debugger nowadays.