4 ms·

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 5y 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.
    - gher-shyu3i 5y ago
      Code bases in reality still do what I'm describing, and they pass code reviews. Kubernetes is one example of the atrocities caused by the language.
  - majewsky 5y ago
    > JSON parsing, config file handling I assume you're not referring to things like json.Marshal(), where the function argument is legitimately of type interface{} since it really accepts any value. Hence I'm going to assume that you're referring to situations where a value can have one of multiple types (e.g. a float value that sometimes gets provided as a string). It's true that people sometimes unmarshal into interface{} and then type-assert in those scenarios, but that use of interface{} is a code smell that should be flagged in review. The proper way is to unmarshal into a custom type with a json.Unmarshaler implementation that accepts all possible input formats (and vice versa for json.Marshaler if encoding is required). This is a real-world example from one of my codebases: https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b9577922824b045e7fab16/pkg/plugins/client_ironic.go#L126-L151 https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b95779...
    - gher-shyu3i 5y ago
      Algebraic types would solve the issue in the example you're giving. However, those don't exist in golang either.

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 5y 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.
  - gher-shyu3i 5y ago
    Code bases in reality still do what I'm describing, and they pass code reviews. Kubernetes is one example of the atrocities caused by the language.
- majewsky 5y ago
  > JSON parsing, config file handling I assume you're not referring to things like json.Marshal(), where the function argument is legitimately of type interface{} since it really accepts any value. Hence I'm going to assume that you're referring to situations where a value can have one of multiple types (e.g. a float value that sometimes gets provided as a string). It's true that people sometimes unmarshal into interface{} and then type-assert in those scenarios, but that use of interface{} is a code smell that should be flagged in review. The proper way is to unmarshal into a custom type with a json.Unmarshaler implementation that accepts all possible input formats (and vice versa for json.Marshaler if encoding is required). This is a real-world example from one of my codebases: https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b9577922824b045e7fab16/pkg/plugins/client_ironic.go#L126-L151 https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b95779...
  - gher-shyu3i 5y ago
    Algebraic types would solve the issue in the example you're giving. However, those don't exist in golang either.