6 ms·

"in the land of the blind, the one-eyed man is king" Golang is probably a step up from Python, but it's just that. There are a lot of issues with Golang. From

"in the land of the blind, the one-eyed man is king" Golang is probably a step up from Python, but it's just that. There are a lot of issues with Golang. From the top of my head, lack of decent error handling (if err !=nil { return nil,err} ) or lack of decent polymorphism are the most annoying. There's a github repo dedicated to what's bugging people: https://github.com/ksimka/go-is-not-good

dewey 7y ago
These two issues are usually brought up by people who haven't written a lot of Go. In day to day work it's really not an issue.
- jrimbault 7y ago
  >These two issues are usually brought up by people who haven't written a lot of C. >In day to day work it's really not an issue. Polymorphism and error handling, these are issues, address them. Go's a fine language, but don't dismiss actual real issues that have been addressed in other languages for 40+? years.
  - carteloupe 7y ago
    Status quo is good because it's status quo, sure.
  - cle 7y ago
    I have written a lot of Go (hundreds of thousands of LOC), and appreciate Go's approach to both of these. I disagree that these are major issues. A bigger issue, IMO, is that people coming to Go from other languages expect it to have similar features to what they're used to. Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages.
    - whateveracct 7y ago
      Go necessitates so much handrolling. Loops, concurrency patterns, resource management. You can't abstract over much, so you end up doing these things by hand constantly. Therefore you rely on brainpower, ad hoc linters (if one exists), and tests to not blow things up. Go has its benefits and reasons to use it (especially the network effects around it). But when it comes to the three things I mention, Go is truly pathetic compared to a language like Haskell. It's amazing how much effort is wasted on those activities. I can see why a corporation would not care, but as an engineer I can do better with my time and effort for my personally-owned endeavors.
      - cle 7y ago
        As an individual, many of Go's benefits aren't as useful. It's optimized for team settings, emphasizing consistency, readability, explictness, and low cognitive overhead, which are all major weaknesses of Haskell, and major reasons it's not widely used in industry.
        whateveracct 7y ago
        For many applications, Go has higher cognitive overhead than Haskell. Modulo learning Haskell of course, but still. Go is made to treat people as Resources. Full stop. That explains everything about it's benefits.
      - deleted 7y ago
        [deleted]
    - RandyRanderson 7y ago
      "I have written a lot of Go (hundreds of thousands of LOC)..." Go only appeared about 10 years ago. The industry standard is 50 lines of production code a day. 50/day * 250 working days a year = 12.5k loc/year. So it would take you how many continuous years to write 200k LOC?
      - dewey 7y ago
        There's probably a very big difference between "industry standard" and working with a new language at a startup where a lot of things are written from scratch in a short amount of time. 50 lines of code on average for a year won't get you very far if you work on greenfield project. The industry standard is probably very heavily biased by big corporate code bases where refactoring / architecture takes a lot more time than implementing the actual changes afterwards. Doesn't seem like a very useful calculation you are trying to do there to proof the previous poster wrong.
        RandyRanderson 7y ago
        "There's probably a very big difference between" - that is precisely my point. I have a lot of time playing ms flight sim and so obviously I know how to design airplanes is his argument. Writing "greenfield" applications that no one (comparatively) is using is relatively easy. Creating systems that have four+ 9's availability, integrate with various disparate APIs, don't lose data, and,and etc is where, IMO, the learning is. Once one has this experience, watching this micro services "movement" is, in my mind, related to global warming - like watching someone jump out of a plane with no parachute, smiling.
    - flavio81 7y ago
      >Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages. No, they aren't. They are the same as languages from 40 years ago: We have had channels, coroutines, and good garbage collectors from long, long ago. Plus the syntax is directly borrowed from Algol 68 (from 1968). Go looks nice because it fills a niche (a high performance garbage collected language that is easier to learn than Java and provides faster compilation times than C++), but there's absolutely nothing different here. For "pretty different from mainstream" see Forth, Prolog, Erlang, etc.
  - icandoit 7y ago
    In some circles C has a better reputation than C++. Surely you see that other people value other things than you do? If you value simplicity check out the programming language zig. https://ziglang.org/ https://ziglang.org/
    - jrimbault 7y ago
      I love C, loathe C++, but it is still valid issue that polymorphism in C is hard and error handling rely on convention ? (I know of Zig, Nim et al, I'm more oriented towards Rust this last year)
    - flavio81 7y ago
      >If you value simplicity check out the programming language zig. I value simplicity, that's what i use Brainfuck. Far simpler than Go and Zig. https://fatiherikli.github.io/brainfuck-visualizer/ https://fatiherikli.github.io/brainfuck-visualizer/
- apta 7y ago
  I write a lot of code in golang, and if anything, my views before using the language were even further cemented by even more flaws I found while using it.
  - loicd 7y ago
    Out of curiosity, would you share those flaws you have found?
    - apta 7y ago
      I will hopefully later today, not able to type much now.
    - apta 7y ago
      This is by no means a comprehensive list: * no generics * null pointers * no compile time checked enums or sum types * The golang time package is garbage * golang interfaces are garbage, can't tag types with an interface without implementing a dummy method and hope that no other type implements it. Can't find what interfaces a type implements without an IDE * profiling and debugging tools are nothing in front of JVM and .NET tools * no const/immutablility * no ternary operator, need to write 6 lines instead of a single line if it existed * error handling is error prone and verbose * no default method implementation in interfaces * unit testing frameworks are sucky and rely on code gen, can't mock arbitrary types, but only by defining an interface * that unnused variables and imports are compile time errors, makes it very annoying and time consuming to prototype or when debugging * no private/public/etc modifier. if you want to change the visibility of a type, you need to rename it in all files it's listed in * no incremental compilation (yes Java compiles faster in large projects where I only modify a handful of files, or even more) * pervasive use of single letter identifiers in golang code bases * pervasive use of int, which has a platform dependent size * pervasive instantiation of structs by calling them structFoo { Field1: field1, Field2: field2, ... FieldN: fieldN }, which makes it easy to miss when a new field gets added. Rust and Zig solve this by making it required to specify all fields and values. * defer works on the function scope, not the current scope * defer doesn't handle functions that return errors, meaning many errors are missed * no struct or file private, only package private * the global scope is polluted with special functions like len, copy, delete, make, new, append, for no good reason * golang imports don't support cyclic imports * golang doesn't allow you to import a a specific function or struct from a package. You have you always qualify anything with the package name, which makes things verbose and awkward.
icandoit 7y ago
I like my code to look simple and behave as expected. Stability and "one right way to do it" are great language features. I think this was why Python was able to overtake Perl, for example.
vardump 7y ago
Well... there's also other side of the coin. There's value in visibility and lack of magic. > lack of decent error handling (if err !=nil { return nil,err} ) Errors are in your face, instead of having exceptions performing invisible gotos to somewhere far up in call tree. Implicit error handling is more code, but your error handling is going to be much more robust. > or lack of decent polymorphism... Lack of polymorphism also means you don't have to guess about concrete types when reading code. When troubleshooting, you can see what's going on without going through whole inheritance tree. Go encourages composition instead of inheritance. That's something I wish more C++ codebases would do as well. Composition makes code inherently more maintainable and easier to refactor. Go tends to be easy to read and maintain. It does come with some cost. It's just a matter where your priorities lie. Software projects spend majority of their life as legacy, something that needs to be maintained.
- allovernow 7y ago
  >Composition makes code inherently more maintainable and easier to refactor. My understanding of composition comes from interfaces in C#. In my experience composition is actually more difficult to code and refactor, because it leads to bloat from repeated code as you cannot simply inherit. Refactoring then can become tedious as you may need to manually edit every repeated code block. Whereas with inheritance I define a function once and override it where necessary. Am I misunderstanding something?
  - vardump 7y ago
    Composition tends to lead to more code reuse. And to more code that's still usable in unpredictable future. Over time your whole inheritance model often turns out to be no longer viable, when the basic assumptions made years ago are no longer valid. Worse, because of all of the accumulated cruft, you might not even be able to change the shape of the monster.
  - arwhatever 7y ago
    I don't see that composition should be cause for repeated code blocks.
  - 7y ago

dewey 7y ago

These two issues are usually brought up by people who haven't written a lot of Go. In day to day work it's really not an issue.

jrimbault 7y ago
>These two issues are usually brought up by people who haven't written a lot of C. >In day to day work it's really not an issue. Polymorphism and error handling, these are issues, address them. Go's a fine language, but don't dismiss actual real issues that have been addressed in other languages for 40+? years.
- carteloupe 7y ago
  Status quo is good because it's status quo, sure.
- cle 7y ago
  I have written a lot of Go (hundreds of thousands of LOC), and appreciate Go's approach to both of these. I disagree that these are major issues. A bigger issue, IMO, is that people coming to Go from other languages expect it to have similar features to what they're used to. Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages.
  - whateveracct 7y ago
    Go necessitates so much handrolling. Loops, concurrency patterns, resource management. You can't abstract over much, so you end up doing these things by hand constantly. Therefore you rely on brainpower, ad hoc linters (if one exists), and tests to not blow things up. Go has its benefits and reasons to use it (especially the network effects around it). But when it comes to the three things I mention, Go is truly pathetic compared to a language like Haskell. It's amazing how much effort is wasted on those activities. I can see why a corporation would not care, but as an engineer I can do better with my time and effort for my personally-owned endeavors.
    - cle 7y ago
      As an individual, many of Go's benefits aren't as useful. It's optimized for team settings, emphasizing consistency, readability, explictness, and low cognitive overhead, which are all major weaknesses of Haskell, and major reasons it's not widely used in industry.
      - whateveracct 7y ago
        For many applications, Go has higher cognitive overhead than Haskell. Modulo learning Haskell of course, but still. Go is made to treat people as Resources. Full stop. That explains everything about it's benefits.
    - deleted 7y ago
      [deleted]
  - RandyRanderson 7y ago
    "I have written a lot of Go (hundreds of thousands of LOC)..." Go only appeared about 10 years ago. The industry standard is 50 lines of production code a day. 50/day * 250 working days a year = 12.5k loc/year. So it would take you how many continuous years to write 200k LOC?
    - dewey 7y ago
      There's probably a very big difference between "industry standard" and working with a new language at a startup where a lot of things are written from scratch in a short amount of time. 50 lines of code on average for a year won't get you very far if you work on greenfield project. The industry standard is probably very heavily biased by big corporate code bases where refactoring / architecture takes a lot more time than implementing the actual changes afterwards. Doesn't seem like a very useful calculation you are trying to do there to proof the previous poster wrong.
      - RandyRanderson 7y ago
        "There's probably a very big difference between" - that is precisely my point. I have a lot of time playing ms flight sim and so obviously I know how to design airplanes is his argument. Writing "greenfield" applications that no one (comparatively) is using is relatively easy. Creating systems that have four+ 9's availability, integrate with various disparate APIs, don't lose data, and,and etc is where, IMO, the learning is. Once one has this experience, watching this micro services "movement" is, in my mind, related to global warming - like watching someone jump out of a plane with no parachute, smiling.
  - flavio81 7y ago
    >Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages. No, they aren't. They are the same as languages from 40 years ago: We have had channels, coroutines, and good garbage collectors from long, long ago. Plus the syntax is directly borrowed from Algol 68 (from 1968). Go looks nice because it fills a niche (a high performance garbage collected language that is easier to learn than Java and provides faster compilation times than C++), but there's absolutely nothing different here. For "pretty different from mainstream" see Forth, Prolog, Erlang, etc.
- icandoit 7y ago
  In some circles C has a better reputation than C++. Surely you see that other people value other things than you do? If you value simplicity check out the programming language zig. https://ziglang.org/ https://ziglang.org/
  - jrimbault 7y ago
    I love C, loathe C++, but it is still valid issue that polymorphism in C is hard and error handling rely on convention ? (I know of Zig, Nim et al, I'm more oriented towards Rust this last year)
  - flavio81 7y ago
    >If you value simplicity check out the programming language zig. I value simplicity, that's what i use Brainfuck. Far simpler than Go and Zig. https://fatiherikli.github.io/brainfuck-visualizer/ https://fatiherikli.github.io/brainfuck-visualizer/
apta 7y ago
I write a lot of code in golang, and if anything, my views before using the language were even further cemented by even more flaws I found while using it.
- loicd 7y ago
  Out of curiosity, would you share those flaws you have found?
  - apta 7y ago
    I will hopefully later today, not able to type much now.
  - apta 7y ago
    This is by no means a comprehensive list: * no generics * null pointers * no compile time checked enums or sum types * The golang time package is garbage * golang interfaces are garbage, can't tag types with an interface without implementing a dummy method and hope that no other type implements it. Can't find what interfaces a type implements without an IDE * profiling and debugging tools are nothing in front of JVM and .NET tools * no const/immutablility * no ternary operator, need to write 6 lines instead of a single line if it existed * error handling is error prone and verbose * no default method implementation in interfaces * unit testing frameworks are sucky and rely on code gen, can't mock arbitrary types, but only by defining an interface * that unnused variables and imports are compile time errors, makes it very annoying and time consuming to prototype or when debugging * no private/public/etc modifier. if you want to change the visibility of a type, you need to rename it in all files it's listed in * no incremental compilation (yes Java compiles faster in large projects where I only modify a handful of files, or even more) * pervasive use of single letter identifiers in golang code bases * pervasive use of int, which has a platform dependent size * pervasive instantiation of structs by calling them structFoo { Field1: field1, Field2: field2, ... FieldN: fieldN }, which makes it easy to miss when a new field gets added. Rust and Zig solve this by making it required to specify all fields and values. * defer works on the function scope, not the current scope * defer doesn't handle functions that return errors, meaning many errors are missed * no struct or file private, only package private * the global scope is polluted with special functions like len, copy, delete, make, new, append, for no good reason * golang imports don't support cyclic imports * golang doesn't allow you to import a a specific function or struct from a package. You have you always qualify anything with the package name, which makes things verbose and awkward.

icandoit 7y ago

I like my code to look simple and behave as expected. Stability and "one right way to do it" are great language features. I think this was why Python was able to overtake Perl, for example.

vardump 7y ago

Well... there's also other side of the coin. There's value in visibility and lack of magic. > lack of decent error handling (if err !=nil { return nil,err} ) Errors are in your face, instead of having exceptions performing invisible gotos to somewhere far up in call tree. Implicit error handling is more code, but your error handling is going to be much more robust. > or lack of decent polymorphism... Lack of polymorphism also means you don't have to guess about concrete types when reading code. When troubleshooting, you can see what's going on without going through whole inheritance tree. Go encourages composition instead of inheritance. That's something I wish more C++ codebases would do as well. Composition makes code inherently more maintainable and easier to refactor. Go tends to be easy to read and maintain. It does come with some cost. It's just a matter where your priorities lie. Software projects spend majority of their life as legacy, something that needs to be maintained.

allovernow 7y ago
>Composition makes code inherently more maintainable and easier to refactor. My understanding of composition comes from interfaces in C#. In my experience composition is actually more difficult to code and refactor, because it leads to bloat from repeated code as you cannot simply inherit. Refactoring then can become tedious as you may need to manually edit every repeated code block. Whereas with inheritance I define a function once and override it where necessary. Am I misunderstanding something?
- vardump 7y ago
  Composition tends to lead to more code reuse. And to more code that's still usable in unpredictable future. Over time your whole inheritance model often turns out to be no longer viable, when the basic assumptions made years ago are no longer valid. Worse, because of all of the accumulated cruft, you might not even be able to change the shape of the monster.
- arwhatever 7y ago
  I don't see that composition should be cause for repeated code blocks.
- 7y ago