5 ms·

> Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans

> Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans This claim keeps getting repeated with absolutely nothing to back it up, other than repeating what the golang authors claimed. I work on a large golang code base, and it's quite horrid. The IDE experience is terrible. It's hard to navigate the code base, due to things like types unintentionally implementing interfaces because they happen to match on some of their function declarations. No proper visibility rules (only "public" and "package private"). interface{} everywhere because of no generics (I'm aware that's being worked on). Single character variable names are popular because the golang authors write code that way and it's seen as "smart". No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time. Error handling is terrible, and I've seen many insidious cases of mishandled errors. Null pointers are still a thing. The list goes on. Edit: not to mention things like the language is against quick prototyping (heavy friction due to things like unnused imports or variables, and a very verbose language), as well as the lack of mature libraries such as JDBI or Dapper.

ikiris 6y ago
This sounds like really bad code was allowed to be checked in, not the fault of the language. You can make terrible code in almost any language. The above does not match my experience in maintaining large go codebases because of proper code reviews and expectation of writing maintainable code.
- gher-shyu3i 6y ago
  Nope, we have a very rigorous linting and review process. It's the shortcomings of the language.
  - ikiris 6y ago
    how are your complaints about your bad variable names shortcomings of the language and not the code you accept?
    - gher-shyu3i 6y ago
      Because it's literally in the standard library of golang, and everyone copies its style.
      - majewsky 6y ago
        There is no law that requires the use of the same variable naming style as std. Also, > interface{} everywhere because of no generics It would be good to know the domain here. Looking at my own fair share of Go code in productive systems (probably around 100-200 KLOC, written over the last 6 years), interface{} is really really rare. It appears in some library functions which genuinely accept basically any type, in the same way as json.Marshal(), fmt.Printf() or sql.Stmt.Execute() in std. Other than that, I don't think I've ever had a case where I used interface{} instead of defining a more specific interface (plus adapter types to implement that interface on foreign types if necessary). The only big mess that I've come across in Go land is kubernetes/client-go. I can't wait for generics to replace this metastasizing heap of autogenerated code.
        gher-shyu3i 6y ago
        > There is no law that requires the use of the same variable naming style as std. Also, While that's technically true, it doesn't work out in practice because people look to the standard library as "the way" to write golang. It's basically an implied rule and I haven't seen anyone not folllow it so far. > It would be good to know the domain here Both infrastructure level work as well as CRUD type work. > interface{} is really really rare We have to use them everywhere for things like JSON parsing, config file handling, and pagerduty integration. Not to mention wrappers around SQL handling (e.g. batch inserts, pagination, etc.) Generics will fix some things in the language, but not all. There are too many issues with it like the ones I already mentioned. It's still a very cludgy language to work with.
        ikiris 6y ago
        Having worked with the people doing those standard libraries, you're pulling justifications out of your butt for bad practices. Just as a start: variables names should always be clear by context. You only see the one letter ones if its literally the next line or similar use case. Also, bare interface{} should basically never be the case for a function signature. None of the code you've described thus far would pass a proper review.
dragonwriter 6y ago
> No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time. Python lacks a reserved keyword for this use, and I can count the ones not using “self” in instance methods and “cls” in class methods that I’ve encountered on the fingers of my left foot. But, yeah, weak convention plus no keyword promotes needless chaos.

ikiris 6y ago

This sounds like really bad code was allowed to be checked in, not the fault of the language. You can make terrible code in almost any language. The above does not match my experience in maintaining large go codebases because of proper code reviews and expectation of writing maintainable code.

gher-shyu3i 6y ago
Nope, we have a very rigorous linting and review process. It's the shortcomings of the language.
- ikiris 6y ago
  how are your complaints about your bad variable names shortcomings of the language and not the code you accept?
  - gher-shyu3i 6y ago
    Because it's literally in the standard library of golang, and everyone copies its style.
    - majewsky 6y ago
      There is no law that requires the use of the same variable naming style as std. Also, > interface{} everywhere because of no generics It would be good to know the domain here. Looking at my own fair share of Go code in productive systems (probably around 100-200 KLOC, written over the last 6 years), interface{} is really really rare. It appears in some library functions which genuinely accept basically any type, in the same way as json.Marshal(), fmt.Printf() or sql.Stmt.Execute() in std. Other than that, I don't think I've ever had a case where I used interface{} instead of defining a more specific interface (plus adapter types to implement that interface on foreign types if necessary). The only big mess that I've come across in Go land is kubernetes/client-go. I can't wait for generics to replace this metastasizing heap of autogenerated code.
      - gher-shyu3i 6y ago
        > There is no law that requires the use of the same variable naming style as std. Also, While that's technically true, it doesn't work out in practice because people look to the standard library as "the way" to write golang. It's basically an implied rule and I haven't seen anyone not folllow it so far. > It would be good to know the domain here Both infrastructure level work as well as CRUD type work. > interface{} is really really rare We have to use them everywhere for things like JSON parsing, config file handling, and pagerduty integration. Not to mention wrappers around SQL handling (e.g. batch inserts, pagination, etc.) Generics will fix some things in the language, but not all. There are too many issues with it like the ones I already mentioned. It's still a very cludgy language to work with.
        ikiris 6y ago
        Having worked with the people doing those standard libraries, you're pulling justifications out of your butt for bad practices. Just as a start: variables names should always be clear by context. You only see the one letter ones if its literally the next line or similar use case. Also, bare interface{} should basically never be the case for a function signature. None of the code you've described thus far would pass a proper review.

dragonwriter 6y ago

> No reserved "this" or "self" keyword to declare methods means that every type will have its own single letter self variable which you have to look up every time. Python lacks a reserved keyword for this use, and I can count the ones not using “self” in instance methods and “cls” in class methods that I’ve encountered on the fingers of my left foot. But, yeah, weak convention plus no keyword promotes needless chaos.