5 ms·

At my current job, most of the backend code is divided in two separate groups. One uses Java while another is built with Go. Both have teams have very good reas

At my current job, most of the backend code is divided in two separate groups. One uses Java while another is built with Go. Both have teams have very good reasons to choose what they did and both languages are serving their purpose pretty well but one of the major issues with the Java team I've seen is how discussion there is around styling the code. Most PRs have some comments about some styling and it gets a bit worse every time a new engineer joins the team. I think what you pointed about Go is one of it's best features if not the best.

aphexairlines 7y ago
The Java team could use EditorConfig, CheckStyle, FindBugs, ErrorProne, or other tools to enforce team rules similar to how the Go team uses tools like gofmt.
- elithrar 7y ago
  I think the part here is that there aren’t tools “like” gofmt - there is only gofmt. Other tools wrap it, but there’s no choice (and bikeshedding) to make.
  - icholy 7y ago
    Also gofmt is not configurable.
    - tigershark 7y ago
      There is a much better formatting tool. It’s called F#.
  - aphexairlines 7y ago
    If the team puts in place a code formatter/linter tool there won't be bikeshedding for them either. If they're happy to let google format their Go code they can let google format their Java code too: https://github.com/google/google-java-format https://github.com/google/google-java-format
    - themoat 7y ago
      We had a "discussion" on which formatter/linter to use for a different language. There were 2 choices and I bet we spend 300 man hours on nonsense. Everyone had to have their say. You can decide TO use a linter, but then you just get to argue about which linter...
      - aphexairlines 7y ago
        The fact that there are multiple linter tools shouldn't paralyze a group of people for 300 man hours. The Go ecosystem will eventually have choices too. For instance, I think there are a couple of different protobuf implementations for Go already.
        malandrew 7y ago
        It shouldn't but it does. See Wadler's Law: https://wiki.haskell.org/Wadler's_Law https://wiki.haskell.org/Wadler's_Law
      - tigershark 7y ago
        Seriously? If something like this happened where I work probably everyone would be let go. Sometimes I kind of envy the freedom of wasting your work time just for nothing... But honestly I still prefer to do something that helps the users rather than measure each other “manhood” in this nonsense...
  - tigershark 7y ago
    I think that a proper IDE had this features for more than 10 years. Honestly to me it seems a huge disadvantage to have to run a command line tool outside your work environment to get the same.
- Strom 7y ago
  There's a big difference between standard styling and optional styling. Yes a single team could decide on a custom style, however when you need to cooperate with other teams, it takes a lot of wasted time in politics to agree upon a style. It's also harder to read random code written by others, e.g. open source libraries. You can't just glimpse at it in the browser, you have to download the code and run it through your custom style applier.
  - katabatic 7y ago
    > There's a big difference between standard styling and optional styling. THIS. This is not stated enough in the value of gofmt - it's the standard formatting style for everything. I've worked in Java and C++ for a couple of decades, and while every team has had its own style guidelines, and occasionally tools to enforce them, even different teams in the same organization would have difficulty understanding each other's code. The value of gofmt is that it's the only formatting standard, thus I never have to learn a new formatting style when reading the code for an open-source library, or coming in to a new job. It's exactly the same as what I've been reading for the last 3 1/2 years of working in Go.
- owaislone 7y ago
  I proposed editorconf to them but I think were still discussions and debates. Not sure if they've settled on anything yet.
JamesBarney 7y ago
I'm not a huge fan of go for the type of work I usually do, (Line of business/enterprise apps with really strict timelines) but this is definitely one of the best things Go did right, and I hope other languages learn from them. I think the styling issue is even more important than on first glance because the way a lot of people do code reviews is they look at code until they find a few issues to comment on and then mark it approve. If they find 3 styling issues they might just make those comments and not search for the deeper issues that actually affect the client like bugs, ways the code could be made more defensive, or performance issues.
tigershark 7y ago
The java team can just switch to Kotlin and improve immediately their readability and expressive power. I don’t think that the go team would switch to another language to do the same...
sacado2 7y ago
Even in a team of a single person, go's opinionated approach to styling is great. I can still maintain code I wrote when I was a go noob and no cringe when I read it. It's gofmt that made me fall in love with go.

aphexairlines 7y ago

The Java team could use EditorConfig, CheckStyle, FindBugs, ErrorProne, or other tools to enforce team rules similar to how the Go team uses tools like gofmt.

elithrar 7y ago
I think the part here is that there aren’t tools “like” gofmt - there is only gofmt. Other tools wrap it, but there’s no choice (and bikeshedding) to make.
- icholy 7y ago
  Also gofmt is not configurable.
  - tigershark 7y ago
    There is a much better formatting tool. It’s called F#.
- aphexairlines 7y ago
  If the team puts in place a code formatter/linter tool there won't be bikeshedding for them either. If they're happy to let google format their Go code they can let google format their Java code too: https://github.com/google/google-java-format https://github.com/google/google-java-format
  - themoat 7y ago
    We had a "discussion" on which formatter/linter to use for a different language. There were 2 choices and I bet we spend 300 man hours on nonsense. Everyone had to have their say. You can decide TO use a linter, but then you just get to argue about which linter...
    - aphexairlines 7y ago
      The fact that there are multiple linter tools shouldn't paralyze a group of people for 300 man hours. The Go ecosystem will eventually have choices too. For instance, I think there are a couple of different protobuf implementations for Go already.
      - malandrew 7y ago
        It shouldn't but it does. See Wadler's Law: https://wiki.haskell.org/Wadler's_Law https://wiki.haskell.org/Wadler's_Law
    - tigershark 7y ago
      Seriously? If something like this happened where I work probably everyone would be let go. Sometimes I kind of envy the freedom of wasting your work time just for nothing... But honestly I still prefer to do something that helps the users rather than measure each other “manhood” in this nonsense...
- tigershark 7y ago
  I think that a proper IDE had this features for more than 10 years. Honestly to me it seems a huge disadvantage to have to run a command line tool outside your work environment to get the same.
Strom 7y ago
There's a big difference between standard styling and optional styling. Yes a single team could decide on a custom style, however when you need to cooperate with other teams, it takes a lot of wasted time in politics to agree upon a style. It's also harder to read random code written by others, e.g. open source libraries. You can't just glimpse at it in the browser, you have to download the code and run it through your custom style applier.
- katabatic 7y ago
  > There's a big difference between standard styling and optional styling. THIS. This is not stated enough in the value of gofmt - it's the standard formatting style for everything. I've worked in Java and C++ for a couple of decades, and while every team has had its own style guidelines, and occasionally tools to enforce them, even different teams in the same organization would have difficulty understanding each other's code. The value of gofmt is that it's the only formatting standard, thus I never have to learn a new formatting style when reading the code for an open-source library, or coming in to a new job. It's exactly the same as what I've been reading for the last 3 1/2 years of working in Go.
owaislone 7y ago
I proposed editorconf to them but I think were still discussions and debates. Not sure if they've settled on anything yet.

JamesBarney 7y ago

I'm not a huge fan of go for the type of work I usually do, (Line of business/enterprise apps with really strict timelines) but this is definitely one of the best things Go did right, and I hope other languages learn from them. I think the styling issue is even more important than on first glance because the way a lot of people do code reviews is they look at code until they find a few issues to comment on and then mark it approve. If they find 3 styling issues they might just make those comments and not search for the deeper issues that actually affect the client like bugs, ways the code could be made more defensive, or performance issues.

tigershark 7y ago

The java team can just switch to Kotlin and improve immediately their readability and expressive power. I don’t think that the go team would switch to another language to do the same...

sacado2 7y ago

Even in a team of a single person, go's opinionated approach to styling is great. I can still maintain code I wrote when I was a go noob and no cringe when I read it. It's gofmt that made me fall in love with go.