4 ms·

As someone without a ton of experience with Go, a good amount the Go code I have encountered "in the wild", has actually been more difficult to read and underst

by thayne 6y ago

As someone without a ton of experience with Go, a good amount the Go code I have encountered "in the wild", has actually been more difficult to read and understand than code in more complicated languages because I have to read through and understand all of these patterns. Hopefully the addition of generics will help with that. But IMO the simplicity of go actually hinders readability.

philosopher1234 6y ago
Could you share an example?
- gher-shyu3i 6y ago
  Not the poster you're responding to, but practically every time someone wants to write code that mimics `map` or `filter` and gang is a 5-7 line function (at least). Something that would have been a 1 liner in languages like Java or C#. It gets tiring and distracting very quickly to jump around verbose implementations which amount to nothing more than standard streaming functions. Another example is the lack of annotations for validations. In Java or C#, you'd annotate the function argument with something like `@Validated`, and it's taken care of. In golang, calling the validation code would have to be done manually each time that's another 3-4 lines (including error handling). Yet another example is that golang lacks a construct similar to C#'s `Task`. You can't execute a function that returns a value asynchronously (if you care about that value) without creating a channel and passing it. golang also lacks pattern matching and discriminated unions (aka algebraic data types). Java and C# are getting both (both have pattern matching, and ADTs are in the works as far as I'm aware).
  - fileeditview 6y ago
    Have to agree with you. I wished for sum types & pattern matching more than for generics.. but who knows what the future brings.
    - cy_hauser 6y ago
      RemindMe! 10 Years "Are we there yet?"
    - hderms 6y ago
      this is why I have moved to Rust. I worked in Go a number of years ago, but after becoming proficient in Scala, I've decided sum types and pattern matching are where the sweet spot is. The JVM has its own issues though and I'd like to have a performance-conscious language in my toolbelt that doesn't sacrifice expressivity. Hence: Rust.
  - dullcrisp 6y ago
    You got me excited about Java having pattern matching, but all I could find was a proposal.
    - gher-shyu3i 6y ago
      It's partially there since Java 14: https://docs.oracle.com/en/java/javase/14/language/pattern-matching-instanceof-operator.html https://docs.oracle.com/en/java/javase/14/language/pattern-m...
      - vips7L 6y ago
        Thats just for instanceof they're working on growing the capabilities in another JEP. Switch expressions are EXTREMELY powerful though.
    - deleted 6y ago
      [deleted]
fileeditview 6y ago
My personal experience is very different. Of course I have seen bad Go code in the ~5 years I do Go development professionally. But when compared to previous monstrosities in C++ or Java with exceptions cluttered everywhere, deep inheritance trees that are absolutely useless.. then Go code is an absolute breeze to read and work with. The one thing I see frequently and dislike a lot in Go code bases is the frequent usage of interfaces for single structs just for the sake of mocking for unit tests. Often I see cases where you could just strip the whole layer of crap and unit test the real functions themselves. But nobody seems to think about that. It seems that this "write interfaces for everything and then mock/test this" pattern is dominating currently.
- thayne 6y ago
  > But when compared to previous monstrosities in C++ or Java Perhaps part of it is the languages we are comparing to? I'm comparing to languages such as rust and scala, and to some extent python and ruby. > with exceptions cluttered everywhere I prefer errors to be part of the return value to exceptions, but I also find repeating if err != nil { return nil, err } for almost every line of significant code in go functions pretty distracting. I much prefer rust's `?` operator. Or haskell's do notation (or scala's roughly equivalent for/yield). > deep inheritance trees that are absolutely useless. uh, you can have deep inheritance trees in Go, and not have them in Java or C++, I'm not sure what your point is.
  - fileeditview 6y ago
    > Perhaps part of it is the languages we are comparing to? I'm comparing to languages such as rust and scala, and to some extent python and ruby. I think you should compare to languages that have a similar purpose / area of usage. In my experience that is C++ and mostly Java. I wouldn't dare compare dynamically typed and interpreted languages with Go.. what's the point? I don't have much experience with Rust so I cannot compare it and additionally it's rarely used in companies. Scala I just don't like personally. For my taste it just "is too much of everything". > ... err != nil ... In the beginning I was thinking the same. Over time I got used to it. When I write it I use a snippet. And clearly reading the flow of the error has been beneficial to me a lot of times. Yes it is verbose. > uh, you can have deep inheritance trees in Go, and not have them in Java or C++, I'm not sure what your point is. I am sure you know that there is no inheritance in Go so I am not totally sure what you are getting at. My point is that I think OOP by composition is a lot clearer than by inheritance. Also composition is not overused in Go as say inheritance is overused in Java.

by thayne 6y ago

philosopher1234 6y ago

Could you share an example?

gher-shyu3i 6y ago
Not the poster you're responding to, but practically every time someone wants to write code that mimics `map` or `filter` and gang is a 5-7 line function (at least). Something that would have been a 1 liner in languages like Java or C#. It gets tiring and distracting very quickly to jump around verbose implementations which amount to nothing more than standard streaming functions. Another example is the lack of annotations for validations. In Java or C#, you'd annotate the function argument with something like `@Validated`, and it's taken care of. In golang, calling the validation code would have to be done manually each time that's another 3-4 lines (including error handling). Yet another example is that golang lacks a construct similar to C#'s `Task`. You can't execute a function that returns a value asynchronously (if you care about that value) without creating a channel and passing it. golang also lacks pattern matching and discriminated unions (aka algebraic data types). Java and C# are getting both (both have pattern matching, and ADTs are in the works as far as I'm aware).
- fileeditview 6y ago
  Have to agree with you. I wished for sum types & pattern matching more than for generics.. but who knows what the future brings.
  - cy_hauser 6y ago
    RemindMe! 10 Years "Are we there yet?"
  - hderms 6y ago
    this is why I have moved to Rust. I worked in Go a number of years ago, but after becoming proficient in Scala, I've decided sum types and pattern matching are where the sweet spot is. The JVM has its own issues though and I'd like to have a performance-conscious language in my toolbelt that doesn't sacrifice expressivity. Hence: Rust.
- dullcrisp 6y ago
  You got me excited about Java having pattern matching, but all I could find was a proposal.
  - gher-shyu3i 6y ago
    It's partially there since Java 14: https://docs.oracle.com/en/java/javase/14/language/pattern-matching-instanceof-operator.html https://docs.oracle.com/en/java/javase/14/language/pattern-m...
    - vips7L 6y ago
      Thats just for instanceof they're working on growing the capabilities in another JEP. Switch expressions are EXTREMELY powerful though.
  - deleted 6y ago
    [deleted]

fileeditview 6y ago

My personal experience is very different. Of course I have seen bad Go code in the ~5 years I do Go development professionally. But when compared to previous monstrosities in C++ or Java with exceptions cluttered everywhere, deep inheritance trees that are absolutely useless.. then Go code is an absolute breeze to read and work with. The one thing I see frequently and dislike a lot in Go code bases is the frequent usage of interfaces for single structs just for the sake of mocking for unit tests. Often I see cases where you could just strip the whole layer of crap and unit test the real functions themselves. But nobody seems to think about that. It seems that this "write interfaces for everything and then mock/test this" pattern is dominating currently.

thayne 6y ago
> But when compared to previous monstrosities in C++ or Java Perhaps part of it is the languages we are comparing to? I'm comparing to languages such as rust and scala, and to some extent python and ruby. > with exceptions cluttered everywhere I prefer errors to be part of the return value to exceptions, but I also find repeating if err != nil { return nil, err } for almost every line of significant code in go functions pretty distracting. I much prefer rust's `?` operator. Or haskell's do notation (or scala's roughly equivalent for/yield). > deep inheritance trees that are absolutely useless. uh, you can have deep inheritance trees in Go, and not have them in Java or C++, I'm not sure what your point is.
- fileeditview 6y ago
  > Perhaps part of it is the languages we are comparing to? I'm comparing to languages such as rust and scala, and to some extent python and ruby. I think you should compare to languages that have a similar purpose / area of usage. In my experience that is C++ and mostly Java. I wouldn't dare compare dynamically typed and interpreted languages with Go.. what's the point? I don't have much experience with Rust so I cannot compare it and additionally it's rarely used in companies. Scala I just don't like personally. For my taste it just "is too much of everything". > ... err != nil ... In the beginning I was thinking the same. Over time I got used to it. When I write it I use a snippet. And clearly reading the flow of the error has been beneficial to me a lot of times. Yes it is verbose. > uh, you can have deep inheritance trees in Go, and not have them in Java or C++, I'm not sure what your point is. I am sure you know that there is no inheritance in Go so I am not totally sure what you are getting at. My point is that I think OOP by composition is a lot clearer than by inheritance. Also composition is not overused in Go as say inheritance is overused in Java.