I’m torn on this kind of thing. To be honest, I personally hate writing Go; it takes far more typing and far more boilerplate to get anything done than in literally any other language I use, and for dubious at best benefits. But when it comes to quickly grabbing and modifying someone else’s code, I frequently look for Go versions, because I know I’ll be able to dive in and start making changes extremely quickly.
I think that’s the real split brained reaction to Go in a nutshell: the restrictions that make me more productive diving into a random codebase slow me way down when I’m working on writing meaningful new code myself. This article is really hitting on that divide. I’m still torn on whether the trade-off is worth it.
For any nontrivial project, where there are multiple people working on the same codebase over several years, virtually every developer will spend much more time reading other people’s code than writing their own. That’s where Go shines; in that respect it’s the opposite of languages like Python, Perl or Ruby, which are pretty easy to write but much harder to read when working on a large codebase.
I find Go harder to read. Every for loop must be inspected to know if it’s a map, filter or reduce. Error handling obscuring the real work everywhere. It’s tedious.
I actually disagree with that, at least in part. On a single codebase, or even a single framework, achieving Go’s level of readability by simply enforcing coding standards is not difficult. Rails is largely in this bucket: give me a random Rails app, and I can usually get oriented in just a minute or two. And Mercurial is good example of project in this bucket: I know exactly where to go to add or change functionality, and I know exactly how to write it to match the surrounding well-enforced coding style. These are high-level languages with rich abstractions.
Where Go is different is that the style and code layout is generally standard for the entire ecosystem. But I’m not usually jumping between random parts of an ecosystem; I spend the overwhelming majority of my time in just a project or two. So I’m not convinced that giving up so much flexibility for being able to navigate around a language ecosystem is necessarily worth it, compared to just tight linting and consistency within a framework or project.
[Edit: or a short, better way I could it: I am 100% on board with optimizing for readability to a point, but optimizing for readability at the expense of writability when your target is just one project, or even just one kind of project, will result in a much richer language than when you optimize for any project. I strongly support the first, but am not sure about the second.]
To me it’s an extraordinarily nice language to get paid to use in a very large codebase with a very large team and substantial delivery pressure. Reviewing pull requests is easy, reading the code is easy, testing it is easy, the artifacts you produce tend to have good performance characteristics especially for a language with GC, there are hardly ever any surprises. There is the boilerplate (although I don’t think it’s any worse than idiomatic corporate Java), and the lack of features, and that is the tradeoff. Whether it’s worth the tradeoff will depend on where you work, imo. I am extremely happy writing it for work where I work now. If I were working for a 5 person startup trying to crank out an MVP for a mostly-CRUD app, it would be a ridiculously inappropriate choice. I don’t think I’ll ever use it for any personal projects (I’d rather use a language I find interesting as a language, something like Rust, or Python, or Haskell, etc), and that is fine also.
This matches my experience, and I’m conflicted myself. I think I lean towards the Go philosophy, because I’ve historically spent a lot more time doing maintenance than new development. But I also get frustrated whenever I sit down to write something new in Go because it feels just a bit tedious…
I think there is nothing wrong with the philosophy itself, it’s just that Go is a terrible execution of it – a fact many people are unable to see, because Go just doesn’t have many competitors in the not-super-complex section of programming languages.
I think we can get some of those benefits in more powerful languages if we restrict coding style to something straightforward for all cases except those where power helps. Tricky to get people to do, though.
easier if you also mandate that no code can be checked in without review, and that a reviewer citing the style guide always has the last word. that way if you want a style guide exception you have to convince the reviewer, and in my experience the “convincing” usually takes the form of extensive comments explaining your non-straightforward code.
… it takes far more typing and far more boilerplate to get anything done than in literally any other language I use,…
I do not know what languages you usually use but this is exactly the opposite from what I experience when writing Go.
The web services and command line tools I wrote in Go are vastly smaller than a comparable Java service and almost as dense as one written in Python.
I’ve just got started with Go about 9 months ago and I find a lot of what is said in this article to be true. I’ve spent the majority of my career writing Scala and while I love the expressiveness, it’s hard for beginners to become productive in.
I’m torn on this kind of thing. To be honest, I personally hate writing Go; it takes far more typing and far more boilerplate to get anything done than in literally any other language I use, and for dubious at best benefits. But when it comes to quickly grabbing and modifying someone else’s code, I frequently look for Go versions, because I know I’ll be able to dive in and start making changes extremely quickly.
I think that’s the real split brained reaction to Go in a nutshell: the restrictions that make me more productive diving into a random codebase slow me way down when I’m working on writing meaningful new code myself. This article is really hitting on that divide. I’m still torn on whether the trade-off is worth it.
For any nontrivial project, where there are multiple people working on the same codebase over several years, virtually every developer will spend much more time reading other people’s code than writing their own. That’s where Go shines; in that respect it’s the opposite of languages like Python, Perl or Ruby, which are pretty easy to write but much harder to read when working on a large codebase.
I find Go harder to read. Every for loop must be inspected to know if it’s a map, filter or reduce. Error handling obscuring the real work everywhere. It’s tedious.
I actually disagree with that, at least in part. On a single codebase, or even a single framework, achieving Go’s level of readability by simply enforcing coding standards is not difficult. Rails is largely in this bucket: give me a random Rails app, and I can usually get oriented in just a minute or two. And Mercurial is good example of project in this bucket: I know exactly where to go to add or change functionality, and I know exactly how to write it to match the surrounding well-enforced coding style. These are high-level languages with rich abstractions.
Where Go is different is that the style and code layout is generally standard for the entire ecosystem. But I’m not usually jumping between random parts of an ecosystem; I spend the overwhelming majority of my time in just a project or two. So I’m not convinced that giving up so much flexibility for being able to navigate around a language ecosystem is necessarily worth it, compared to just tight linting and consistency within a framework or project.
[Edit: or a short, better way I could it: I am 100% on board with optimizing for readability to a point, but optimizing for readability at the expense of writability when your target is just one project, or even just one kind of project, will result in a much richer language than when you optimize for any project. I strongly support the first, but am not sure about the second.]
I mostly agree with the legibility of Go code others write, though I have to say that error handling stuff in particular looks like line noise to me.
It reminds me of reading C code, where your business logic ends up being intermingled with memory management of all things.
But at least you know what’s going on on each line in Go (no chance for that in C, esp with fancier macros)
To me it’s an extraordinarily nice language to get paid to use in a very large codebase with a very large team and substantial delivery pressure. Reviewing pull requests is easy, reading the code is easy, testing it is easy, the artifacts you produce tend to have good performance characteristics especially for a language with GC, there are hardly ever any surprises. There is the boilerplate (although I don’t think it’s any worse than idiomatic corporate Java), and the lack of features, and that is the tradeoff. Whether it’s worth the tradeoff will depend on where you work, imo. I am extremely happy writing it for work where I work now. If I were working for a 5 person startup trying to crank out an MVP for a mostly-CRUD app, it would be a ridiculously inappropriate choice. I don’t think I’ll ever use it for any personal projects (I’d rather use a language I find interesting as a language, something like Rust, or Python, or Haskell, etc), and that is fine also.
This matches my experience, and I’m conflicted myself. I think I lean towards the Go philosophy, because I’ve historically spent a lot more time doing maintenance than new development. But I also get frustrated whenever I sit down to write something new in Go because it feels just a bit tedious…
I think there is nothing wrong with the philosophy itself, it’s just that Go is a terrible execution of it – a fact many people are unable to see, because Go just doesn’t have many competitors in the not-super-complex section of programming languages.
I think we can get some of those benefits in more powerful languages if we restrict coding style to something straightforward for all cases except those where power helps. Tricky to get people to do, though.
easier if you also mandate that no code can be checked in without review, and that a reviewer citing the style guide always has the last word. that way if you want a style guide exception you have to convince the reviewer, and in my experience the “convincing” usually takes the form of extensive comments explaining your non-straightforward code.
I definitely like code review. Using it to reduce non-straightforward code sounds good to me! :)
I do not know what languages you usually use but this is exactly the opposite from what I experience when writing Go. The web services and command line tools I wrote in Go are vastly smaller than a comparable Java service and almost as dense as one written in Python.
[Comment removed by author]
Your comment has literally nothing to do with the post.
I’ve just got started with Go about 9 months ago and I find a lot of what is said in this article to be true. I’ve spent the majority of my career writing Scala and while I love the expressiveness, it’s hard for beginners to become productive in.