Hacker News Reader

Comment by owaislone | Hacker News Reader

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.

View on HN

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.

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.

Also gofmt is not configurable.

There is a much better formatting tool. It’s called F#.

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

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

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.

It shouldn't but it does. See Wadler's Law:

https://wiki.haskell.org/Wadler's_Law

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

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.

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.

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

I proposed editorconf to them but I think were still discussions and debates. Not sure if they've settled on anything yet.

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.

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.

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

Reply on news.ycombinator.com