4 ms·

Nailed it. I love Go, but all of the things listed in this article (and more) make me bash my head against the wall more often than I'd like to admit. That said

Nailed it. I love Go, but all of the things listed in this article (and more) make me bash my head against the wall more often than I'd like to admit. That said, there are some fantastic things about Go that aren't listed in the article (I feel like gofmt changed my life). Don't let this article discourage you from investigating Go as a tool to use!

kodablah 11y ago
Same here. Mark me down for loving the runtime/community and having issues with the language. Someone's going to target the Go runtime w/ a better language and zero-overhead and I'll be happy. I can't just switch to Nim or D because I still want the Go ecosystem (e.g. /x/crypto/ssh).
spion 11y ago
I've never understood this, every Go user swears on gofmt for some reason that I just dont get. Can you elaborate how gofmt changed your life? Its a really simple tool and lots of languages have those...
- Jemaclus 11y ago
  You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with customization options. This means your Go program and my Go program are formatted exactly the same. Period. I don't have to choose between spaces or tabs or get annoyed that you chose spaces when tabs are clearly superior. * By being highly opinionated, Gofmt just takes care of those decisions. You focus 100% on coding -- not on stylistic decisions. * It's practically built in and maintained by the core team. The "other tools" out there are usually open-source. You have to go hunting for them. Gofmt ships right with Go. Then you have to figure out how to run them. With go, it's just a simple `gofmt <file>`. Boom. Done. No NPM dependencies, no Ruby gems to install. Just run it and move on. I don't write Go full-time, but I've started adopting similar tools for my primary languages. My editor at my current job runs a similar tool for Node. I don't have to think about style any more. It's just taken care of for me. And all of my team have reached the same conclusion. Peace of mind and focus on what really matters is invaluable.
  - spion 11y ago
    The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no style rules, it doesn't matter - most of those are very superficial and have little to no effect on anything.
    - kyrra 11y ago
      Almost all Go code you find on the web will be formatted the same. It removed some pain points when looking at someone else's code. It also complete removes the discussion about formatting during code reviews with team members. While you may not be opinionated on the matter, many people will learn a certain formatting style and stick with it. They then bring it to their new company and it can cause some minor conflict. Gofmt helps remove that.
      - spion 11y ago
        Any code reformatting tool helps remove that. Gofmt isn't the only code reformatting tool in existence.
    - Jemaclus 11y ago
      You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the next line, or whether... I could go on. All of these are things people tend to have preferences for, so when you work with multiple people, having a consistent style is a huge benefit to reading other people's code. Imagine a simple CSS example: Some people like to do one line per element, while others like one line per style: ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` vs ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` That's a pretty trivial example, and for many people, both are acceptable. But when you get into large projects with hundreds or thousands of styles, or you have to code review that one change that was made off-screen on a really long line of CSS, one of those styles is going to be more conducive to code reviews and readability. Stylistic concerns are very real, and gofmt largely makes those go away. Like kyrra said, you may not be opinionated on the matter, but other people are, and gofmt, et al, completely remove that concern from the table.
- ngrilly 11y ago
  It also opens the door to automatic code modification (like goimports or gorename), and because the code is always formatted the same, you avoid "noise" in your diffs related to trivial changes (spacing, etc.).

kodablah 11y ago

Same here. Mark me down for loving the runtime/community and having issues with the language. Someone's going to target the Go runtime w/ a better language and zero-overhead and I'll be happy. I can't just switch to Nim or D because I still want the Go ecosystem (e.g. /x/crypto/ssh).

spion 11y ago

I've never understood this, every Go user swears on gofmt for some reason that I just dont get. Can you elaborate how gofmt changed your life? Its a really simple tool and lots of languages have those...

Jemaclus 11y ago
You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with customization options. This means your Go program and my Go program are formatted exactly the same. Period. I don't have to choose between spaces or tabs or get annoyed that you chose spaces when tabs are clearly superior. * By being highly opinionated, Gofmt just takes care of those decisions. You focus 100% on coding -- not on stylistic decisions. * It's practically built in and maintained by the core team. The "other tools" out there are usually open-source. You have to go hunting for them. Gofmt ships right with Go. Then you have to figure out how to run them. With go, it's just a simple `gofmt <file>`. Boom. Done. No NPM dependencies, no Ruby gems to install. Just run it and move on. I don't write Go full-time, but I've started adopting similar tools for my primary languages. My editor at my current job runs a similar tool for Node. I don't have to think about style any more. It's just taken care of for me. And all of my team have reached the same conclusion. Peace of mind and focus on what really matters is invaluable.
- spion 11y ago
  The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no style rules, it doesn't matter - most of those are very superficial and have little to no effect on anything.
  - kyrra 11y ago
    Almost all Go code you find on the web will be formatted the same. It removed some pain points when looking at someone else's code. It also complete removes the discussion about formatting during code reviews with team members. While you may not be opinionated on the matter, many people will learn a certain formatting style and stick with it. They then bring it to their new company and it can cause some minor conflict. Gofmt helps remove that.
    - spion 11y ago
      Any code reformatting tool helps remove that. Gofmt isn't the only code reformatting tool in existence.
  - Jemaclus 11y ago
    You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the next line, or whether... I could go on. All of these are things people tend to have preferences for, so when you work with multiple people, having a consistent style is a huge benefit to reading other people's code. Imagine a simple CSS example: Some people like to do one line per element, while others like one line per style: ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` vs ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` That's a pretty trivial example, and for many people, both are acceptable. But when you get into large projects with hundreds or thousands of styles, or you have to code review that one change that was made off-screen on a really long line of CSS, one of those styles is going to be more conducive to code reviews and readability. Stylistic concerns are very real, and gofmt largely makes those go away. Like kyrra said, you may not be opinionated on the matter, but other people are, and gofmt, et al, completely remove that concern from the table.
ngrilly 11y ago
It also opens the door to automatic code modification (like goimports or gorename), and because the code is always formatted the same, you avoid "noise" in your diffs related to trivial changes (spacing, etc.).