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.

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.

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.

Also gofmt is not configurable.

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

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

To add to this, I appreciated that C++ had this, too: http://www.stroustrup.com/dne.html

Was very insightful, in the same way your link was.

If everything looks the same, experts' code looks just as bad as novices' code. If you omit every feature that novices can't figure out how to use, what you're left with is a weaker tool that doesn't give as much leverage as it could have. I want more powerful languages for harder problems, where getting better pays off in clarity and reliability.

Readable... You mean compared to an IAbstractFactoryFactory? ;-)

I'm only half joking as I've seen time and again indirection almost for the sake of indirection. I've seen C# projects where an IRepository is injected into a Controller where IRepository only passes data to another injected IDatabaseHelper... Ripped all the IWhatever out, and injected the DatabaseHelper directly into the BaseController, and voila 80% of the codebase gone, and still just as testable... much simpler to follow too.

In the end, I think that a lot of developers read patterns books, or see them used... then start to apply them everywhere, even when they make no sense. I've had arguments where the counter is, "this is how devs expect it to be." As if that's a valid argument for making things more complicated for no benefit.

It isn't that you cannot write simpler software in the main languages used, it's that developers/architects don't. There's something to be said for only abstracting when it makes using the abstraction simpler.