Hacker News Reader

Comment by CatDevURandom | Hacker News Reader

I agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+).

Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not to say Go is a perfect (e.g. a 'real' debugger option), and it doesn't have to be. If you love Rust, or Ruby, or whatever, great. The programming language landscape is not a zero sum game.

tl;dr Go's a fine tool to get stuff done for a large set of problem domains.

View on HN

>... it's small enough to keep in your head...

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.

The 'magic' that you seem to pine for like is found in lets say Ruby, places a far larger mental burden on the programmer than a language like c or go.

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.

> 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.

>>it's small enough to keep in your head

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.

SME?

Subject Matter Expert.

My experience is that being a domain expert and simplicity of dev tools has absolutely nothing to do with each other. At the end of the day you have to understand the problem in order to implement it.

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.

"That's not to say Go is perfect (e.g. a 'real' debugger option)"

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

You know, I've heard this a few times recently and it strikes me as motivated reasoning. Yes, built in unit testing and tooling is great. Vet and fmt are helpful. Static typing rocks. But... I would definitely welcome a proper debugger.

I'll be candid with you: You're probably right. I would also welcome a debugger in the long run, and I'm sure I'd change my tune pretty quickly if I hit a big snag in production. :-)

Reply on news.ycombinator.com