6 ms·

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in tea

by TeeWEE 6y ago

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is build for readability, not for writing code fast and elegantly... Often short dense code with complex types is just really hard to read for your overage joe programmer. We're not all computer scientists here. Go is designed to write maintainable server side programs that can utilize concurrency in computer these days. Therefore they left out generics... I hope its coming. I do wish error handling and generics where part of the language... And a tuple type indeed.

cies 6y ago
> I do wish error handling and generics where part of the language... And a tuple type indeed. On top of that I wish `null` wasn't and sum types + pattern matching were (and were used for error handling).
lmm 6y ago
> Often short dense code with complex types is just really hard to read for your overage joe programmer. I think people make the mistake of measuring how long it takes you to read x lines, when really you need to measure how long it takes to read x functionality. There've been times when I replaced a 200 line class with 4 lines of Scala. Those lines were very much the kind of complexly-typed code that people attack Scala for. It took time and effort to understand what they did. But they were still a lot more maintainable than a 200 line class.
- mrmonkeyman 6y ago
  There is a middle way here. 4 terse lines still sucks. Make it 10-15 readable lines please.
greyman 6y ago
I agree with the first sentence, and that I found is one of the strongest points of Go. That you can look at your colleague code and be almost sure what it does, there just aren't hidden traps or clever hacks. It's always the same "dull" code, telling you in plain language what is happening.
- ardfard 6y ago
  I had an opposite experience. Go code is just like other code in any other languages. It still can be abused to be unholy mess. I see a Go code that have channels all over the place that it's hard to follow the program flow, a function that can panic deep down the stack when feed with certain input.
  - ghayes 6y ago
    Channels for me make Go harder to read than most languages. Once you encounter a channel when reading Go code, good luck understanding the flow from then on.
thesz 6y ago
I disagree with only 1 way to write programs in Go. Go is not an old Fortran (see [1] about "the only real structure is an array") so there is always choice between array-of-structures and structure-of-arrays. [1] https://www.ee.ryerson.ca/~elf/hack/realmen.html https://www.ee.ryerson.ca/~elf/hack/realmen.html Haskell (and C++ for that matter) can hide the difference with associated types (and templates). PS Speaking about arrays - I once read Go's specification for some obscure fun and realized that I read a third of it and still am reading about arrays and stuff and not about programming.
- deleted 6y ago
  [deleted]
eru 6y ago
Go impedes its own readability by encourage or even requiring such huge volumes of code. (And Go ain't very good at concurrency. At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.) Yes, tuples are a really weird thing with Go. If they had completely left them, that would be bad but sort of defendable. But instead they give you a half-baked implementation of some of what tuples do with their 'multiple return types'. (And multiple return types aren't even a good fit for signaling errors. For error-handling you want to return _either_ the result _or_ the error, in a way that the compiler can check that you handled the error. Instead as far as the types are concerned they are always returning both the result and an error, and human reviewers have to make sure that they are checked properly.)
- Philip-J-Fry 6y ago
  Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective. And Go let's you communicate by copying. That's what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn't copied for glaringly obvious reasons. And what would you suggest is a good alternative for returning multiple parameters. Currently this basically forces you to handle any possible errors and results in software you can very easily reason about. Not sure what you mean about human reviewers needing to check errors.
  - LandR 6y ago
    > Go is incredibly readable I find. I'm the opposite, I don't find it readable at all. I find Go too verbose to be readable.
    - kevincox 6y ago
      Exactly this. I find that each line of go is readable. However actually trying to figure out what the code is trying to accomplish becomes a chore because I can't keep all of the lines in my head. Maybe it is because what I am used to but I find I am often "pattern matching" loops into `map`s `filter`s and similar in my head. Of course doing this, and making sure that I didn't miss a side effect or condition that makes it not-quite-a-map takes a lot more brainpower than just seeing `slice.map(|path| path.basename())`.
higerordermap 6y ago
This is told so often told that people believe it is true The lack of any type of abstraction is not great for teams. The need to write boilerplate code harms readability more than writeability. Understanding what a single statement does is not important. Understanding intent is more important. And Go provides very few tools on it. The reason for Go's popularity is mostly tooling. I like structural typing too. But other than that it is a very tedious language.
- jiofih 6y ago
  > other than that it is a very tedious language And that, is precisely why it is a good language for teams.
  - Philip-J-Fry 6y ago
    Yeah it's hard to write weirdly complicated code in Go. Stick Java or C# in the hands of a team and before you know it you've got typed factory service factories and every abstraction known to man.
    - shaan7 6y ago
      What higerorderma said above applies to this ^ comment as well. It is another of those nonsensical things that keeps getting repeated all the time by some Go programmers. That line of thinking promotes workarounds over long-term solutions. If your team has people who are abusing tools (like types, abstractions etc), the solution is to teach them how to not do that. The solution is NOT to remove the tool itself! That is like saying that a drilling machine is easier to misuse so "only the hammer is a tool for teams". Ugh. Go is awesome because of things it _can_ do (it has the speed of C and enough libraries to write full-blown webservices with it). Please don't encourage the whole marketing agenda of touting its shortcomings as advantages. It doesn't work. All it does is it turns people away from the language.
      - Philip-J-Fry 6y ago
        Why do you think it gets repeated by Go developers? I was a C# developer writing all these abstractions like every other C# developer does. It's idiomatic C#. OOP exists, you're encouraged to use it to abstract and decouple code. Even if you try and strip all that away, you'll never escape it because every library you depend on is written this way. For example, try understanding https://github.com/protobuf-net/protobuf-net https://github.com/protobuf-net/protobuf-net like I once did. The cognitive load is huge. This is C#, this is what having a huge toolset results in. A simple language with simple code isn't a shortcoming. It's an advantage. Overly complex code is a shortcoming. I liked writing heavily abstracted code in C#, that's what I used to do every day. But I never liked reading other people's code because without the intimate knowledge of the code it is a huge mental load. Onboarding new developers into a code base they are unfamiliar with is also very time consuming. In Go I realised that the only abstraction you need is an interface. There's no "abstraction first" mentality like there is in C#. You can define interfaces at any point in time, whereas in C# you must define an interface first, and if you don't then you end up going the OOP route with more abstraction. And because of this small toolset, reading other people's code is easy. It all looks the same.
clon 6y ago
The argument for Go being a simple language that naturally produces code everyone can easily grok comes up time and time again. I have never gotten it. I find Go code somewhat easy to write, just just give up on trying to be concise or elegant, but not at all easy to read. The excessive boilerplate just makes me feel like my brain does not have the working memory to piece it all together. The constructs are simple, true, but if you are trying to write anything non-trivial, then simple syntax will not make your problem simpler. It is just expressed in tens of times more lines than in Elixir, Haskell or even PHP. This takes a toll on the reader. As an example - you can accomplish interesting projects with Lego. And it is easy to get going for sure. But at some point, when you are trying to do something non-trivial, it becomes a hindrance, despite it's simplicity. Hence "I built a life-size XYZ in Lego" becomes impressive in it's own right. Oh, and Go modules is a story of a train wreck.
- kevincox 6y ago
  I agree! If people believe that Go is easy to read because it is simple they must love reading brainfuck as there are only a handful of simple operations!
- tored 6y ago
  In what way are Go modules a train wreck?
  - clon 6y ago
    Here is a good start: https://donatstudios.com/Go-v2-Modules https://donatstudios.com/Go-v2-Modules With the relevant HN discussion: https://news.ycombinator.com/item?id=24429045 https://news.ycombinator.com/item?id=24429045

by TeeWEE 6y ago

cies 6y ago

> I do wish error handling and generics where part of the language... And a tuple type indeed. On top of that I wish `null` wasn't and sum types + pattern matching were (and were used for error handling).

lmm 6y ago

> Often short dense code with complex types is just really hard to read for your overage joe programmer. I think people make the mistake of measuring how long it takes you to read x lines, when really you need to measure how long it takes to read x functionality. There've been times when I replaced a 200 line class with 4 lines of Scala. Those lines were very much the kind of complexly-typed code that people attack Scala for. It took time and effort to understand what they did. But they were still a lot more maintainable than a 200 line class.

mrmonkeyman 6y ago
There is a middle way here. 4 terse lines still sucks. Make it 10-15 readable lines please.

greyman 6y ago

I agree with the first sentence, and that I found is one of the strongest points of Go. That you can look at your colleague code and be almost sure what it does, there just aren't hidden traps or clever hacks. It's always the same "dull" code, telling you in plain language what is happening.

ardfard 6y ago
I had an opposite experience. Go code is just like other code in any other languages. It still can be abused to be unholy mess. I see a Go code that have channels all over the place that it's hard to follow the program flow, a function that can panic deep down the stack when feed with certain input.
- ghayes 6y ago
  Channels for me make Go harder to read than most languages. Once you encounter a channel when reading Go code, good luck understanding the flow from then on.

thesz 6y ago

I disagree with only 1 way to write programs in Go. Go is not an old Fortran (see [1] about "the only real structure is an array") so there is always choice between array-of-structures and structure-of-arrays. [1] https://www.ee.ryerson.ca/~elf/hack/realmen.html https://www.ee.ryerson.ca/~elf/hack/realmen.html Haskell (and C++ for that matter) can hide the difference with associated types (and templates). PS Speaking about arrays - I once read Go's specification for some obscure fun and realized that I read a third of it and still am reading about arrays and stuff and not about programming.

deleted 6y ago
[deleted]

eru 6y ago

Go impedes its own readability by encourage or even requiring such huge volumes of code. (And Go ain't very good at concurrency. At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.) Yes, tuples are a really weird thing with Go. If they had completely left them, that would be bad but sort of defendable. But instead they give you a half-baked implementation of some of what tuples do with their 'multiple return types'. (And multiple return types aren't even a good fit for signaling errors. For error-handling you want to return _either_ the result _or_ the error, in a way that the compiler can check that you handled the error. Instead as far as the types are concerned they are always returning both the result and an error, and human reviewers have to make sure that they are checked properly.)

Philip-J-Fry 6y ago
Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective. And Go let's you communicate by copying. That's what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn't copied for glaringly obvious reasons. And what would you suggest is a good alternative for returning multiple parameters. Currently this basically forces you to handle any possible errors and results in software you can very easily reason about. Not sure what you mean about human reviewers needing to check errors.
- LandR 6y ago
  > Go is incredibly readable I find. I'm the opposite, I don't find it readable at all. I find Go too verbose to be readable.
  - kevincox 6y ago
    Exactly this. I find that each line of go is readable. However actually trying to figure out what the code is trying to accomplish becomes a chore because I can't keep all of the lines in my head. Maybe it is because what I am used to but I find I am often "pattern matching" loops into `map`s `filter`s and similar in my head. Of course doing this, and making sure that I didn't miss a side effect or condition that makes it not-quite-a-map takes a lot more brainpower than just seeing `slice.map(|path| path.basename())`.

higerordermap 6y ago

This is told so often told that people believe it is true The lack of any type of abstraction is not great for teams. The need to write boilerplate code harms readability more than writeability. Understanding what a single statement does is not important. Understanding intent is more important. And Go provides very few tools on it. The reason for Go's popularity is mostly tooling. I like structural typing too. But other than that it is a very tedious language.

jiofih 6y ago
> other than that it is a very tedious language And that, is precisely why it is a good language for teams.
- Philip-J-Fry 6y ago
  Yeah it's hard to write weirdly complicated code in Go. Stick Java or C# in the hands of a team and before you know it you've got typed factory service factories and every abstraction known to man.
  - shaan7 6y ago
    What higerorderma said above applies to this ^ comment as well. It is another of those nonsensical things that keeps getting repeated all the time by some Go programmers. That line of thinking promotes workarounds over long-term solutions. If your team has people who are abusing tools (like types, abstractions etc), the solution is to teach them how to not do that. The solution is NOT to remove the tool itself! That is like saying that a drilling machine is easier to misuse so "only the hammer is a tool for teams". Ugh. Go is awesome because of things it _can_ do (it has the speed of C and enough libraries to write full-blown webservices with it). Please don't encourage the whole marketing agenda of touting its shortcomings as advantages. It doesn't work. All it does is it turns people away from the language.
    - Philip-J-Fry 6y ago
      Why do you think it gets repeated by Go developers? I was a C# developer writing all these abstractions like every other C# developer does. It's idiomatic C#. OOP exists, you're encouraged to use it to abstract and decouple code. Even if you try and strip all that away, you'll never escape it because every library you depend on is written this way. For example, try understanding https://github.com/protobuf-net/protobuf-net https://github.com/protobuf-net/protobuf-net like I once did. The cognitive load is huge. This is C#, this is what having a huge toolset results in. A simple language with simple code isn't a shortcoming. It's an advantage. Overly complex code is a shortcoming. I liked writing heavily abstracted code in C#, that's what I used to do every day. But I never liked reading other people's code because without the intimate knowledge of the code it is a huge mental load. Onboarding new developers into a code base they are unfamiliar with is also very time consuming. In Go I realised that the only abstraction you need is an interface. There's no "abstraction first" mentality like there is in C#. You can define interfaces at any point in time, whereas in C# you must define an interface first, and if you don't then you end up going the OOP route with more abstraction. And because of this small toolset, reading other people's code is easy. It all looks the same.

clon 6y ago

The argument for Go being a simple language that naturally produces code everyone can easily grok comes up time and time again. I have never gotten it. I find Go code somewhat easy to write, just just give up on trying to be concise or elegant, but not at all easy to read. The excessive boilerplate just makes me feel like my brain does not have the working memory to piece it all together. The constructs are simple, true, but if you are trying to write anything non-trivial, then simple syntax will not make your problem simpler. It is just expressed in tens of times more lines than in Elixir, Haskell or even PHP. This takes a toll on the reader. As an example - you can accomplish interesting projects with Lego. And it is easy to get going for sure. But at some point, when you are trying to do something non-trivial, it becomes a hindrance, despite it's simplicity. Hence "I built a life-size XYZ in Lego" becomes impressive in it's own right. Oh, and Go modules is a story of a train wreck.

kevincox 6y ago
I agree! If people believe that Go is easy to read because it is simple they must love reading brainfuck as there are only a handful of simple operations!
tored 6y ago
In what way are Go modules a train wreck?
- clon 6y ago
  Here is a good start: https://donatstudios.com/Go-v2-Modules https://donatstudios.com/Go-v2-Modules With the relevant HN discussion: https://news.ycombinator.com/item?id=24429045 https://news.ycombinator.com/item?id=24429045