4 ms·

I am not a Go programmer, but every time there is a discussion about Go I want to link to the article on “Language Design in the Service of Software Engineering

by svat 7y ago

I am not a Go programmer, but every time there is a discussion about Go I want to link to the article on “Language Design in the Service of Software Engineering”: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article It explains so many of Go's design decisions and why it is the way it is (e.g. why something like gofmt/gofix is among the best things about the language); I wish there were similar articles on the design decisions behind more languages. The first point in this (OP) post is also explained by the same philosophy: as far as Readability / “I can pop open almost any .go file and [can] understand it pretty quick” goes, it is a powerful thing to be able to navigate to pretty much any team's code and not only understand their code but also be able to focus on what's specific to that code rather than on idiosyncratic stylistic differences. In other languages this is done with a lot of adherence to the style guide; if Go tries to make it even easier, this would make sense.

batty_alex 7y ago
To add to this, I appreciated that C++ had this, too: http://www.stroustrup.com/dne.html http://www.stroustrup.com/dne.html Was very insightful, in the same way your link was.
owaislone 7y ago
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.
        7y ago
- 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.
tracker1 7y ago
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.
erik_seaberg 7y ago
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.

by svat 7y ago

batty_alex 7y ago

To add to this, I appreciated that C++ had this, too: http://www.stroustrup.com/dne.html http://www.stroustrup.com/dne.html Was very insightful, in the same way your link was.

owaislone 7y ago

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

tracker1 7y ago

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.

erik_seaberg 7y ago

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.