4 ms·

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 programmi

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.

jksmith 12y ago
>>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.
- jimbokun 12y ago
  SME?
  - bmelton 12y ago
    Subject Matter Expert.
- threeseed 12y ago
  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.
throwawaykf05 12y ago
>... 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.
- sctechie 12y ago
  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.
  - pcwalton 12y ago
    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.
    - sctechie 12y ago
      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.
danesparza 12y ago
"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.
- CatDevURandom 12y ago
  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.
  - danesparza 12y ago
    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. :-)

jksmith 12y ago

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

jimbokun 12y ago
SME?
- bmelton 12y ago
  Subject Matter Expert.
threeseed 12y ago
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.

throwawaykf05 12y ago

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

sctechie 12y ago
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.
- pcwalton 12y ago
  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.
  - sctechie 12y ago
    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.

danesparza 12y ago

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

CatDevURandom 12y ago
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.
- danesparza 12y ago
  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. :-)