5 ms·

Any specific complaints, or did you just feel like calling us all cavedwellers?

timothycrosley 7y ago
Most of my complaints, I feel like are pretty well documented: No ability to do Generics, no ability to do operator overloading, no ability to make your own for each style loop objects, very manual and repetitive error handling. These are all simplifications to the language spec at the expense of more complicated usage. For the most part, I've been trying to understand myself how to express why I get a pretty bad taste in my mouth when using or looking at Go code, why it feels so much less productive to me than the higher-level languages. Which is what it has been making dents in more than anything else. I especially wanted to understand this since I do see myself as someone who values simplicity. In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. I'd instead rather learn a slightly more complicated language, and be more productive with every task I write using it. I don't see Go users as cavemen. That was admittedly an exaggeration to express my point clearly.
- nemo1618 7y ago
  >In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. That's interesting, because to me, Go accomplishes this fairly well. Generics, operator overloading, and custom 'for' loops make it easier to write "clever" code with surprising behavior. Go's design is not elegant like Lisp or Haskell; there are some warts and special cases that exist for pragmatic reasons. But it manages to be simple and effective, which is sadly a rare thing in the modern language landscape, where the mentality seems to be "more features = better language." 90% of Go's value is in what it takes away, rather than what it adds.
  - outworlder 7y ago
    One could make the same argument for Lua.
- zadokshi 7y ago
  Language designers: Design a language to not use generics. timothycrosley: It doesn't do generics!!! Aaargh!!
  - jeremyjh 7y ago
    Except they didn't. Go has generic maps and slices. It was never their goal to create a language without generics. What happened is they failed to come up with a satisfactory design for user defined generics in time to make Go version 1.
    - zadokshi 7y ago
      Exactly, They didn’t feel it was important. It was not part of the language design. https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- badrequest 7y ago
  Cool, here's my take: people who insist on a language supporting generics are lazy and uncreative.
srparish 7y ago
+ By declaring a field/variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field/variable you need to audit all your code to make sure you haven't broken things. + gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping/unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything. + Scope of element in for-range loop isn't right, so capturing that scope in a lambda does the wrong thing with no warning. + Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map/filter/reduce or comprehensions. + No help from type-system for use of pointer without nil check. + Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man's unique_ptr<> means that I also get optional<> symantics (without the type checking) when I don't want or expect such. Also allows for aliasing when I don't want or expect such. + Difference between '=' and ':=' is silly, especially since ':=' can be used to reassign values. Even more frustrating that ':=' creates shadowing in nested scopes, so doesn't always do what one would expect it would do, such as accidentally creating a shadowed 'err' that doesn't get checked. + if/switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.
- gameswithgo 7y ago
  I actually like Go's simplicity a lot, it was very easy for me to learn and very easy to programming with it because of that. But I agree strongly with some of your points. = vs := specifically feels like a plain mistake, and even against Go philosophy of having just 1 way to do things. I think any new language should be designed around options instead of nils. F#, Rust, Zig show different ways to do this, and often any performance penalty can be compiled away. if/switch being expressions is a simple and helpful idea, languages should allow this. using map/filter/reduce as the idiomatic way to do things I am less sure about. This can come in handy but also would add a lot of complexity to Go, and in most languages these have a performance penalty. its important to remember that not all programmers are interested in languages, they just want to get their project done. So being able to hop into a code base and have low cognitive overhead, because there are no mysterious features they have to learn, having quick compile times, and explicit semantics can be really helpful there. That can save you more time than typing less because of generics and meta programming sometimes.
pyrale 7y ago
Well, I don't subscribe to the deprecating aspect of the grunting stuff, but many of these discussions read very much like transcripts of Plato's cave. I had the same experience as a Java dev back when Java8 came out. To me, it felt great. To people using functional languages which this update ported to Java, it looked poorly. It is hard to understand go's criticism if you have not experienced languages leveraging modern datastructures such as, for instance, union types/pattern matching. But if you have, you really feel like the language lacks something.
- edflsafoiewq 7y ago
  For me, it's not even things like that. It's boring things like push, pop, erase, index_of, etc. that probably everyone has seen but that can't be written in Go.
  - badrequest 7y ago
    You can write them, you just can't write them generically.
  - virmundi 7y ago
    You can write them but to do so generically you need to do code gen. Unfortunately this means learning a code green template library.

Most of my complaints, I feel like are pretty well documented: No ability to do Generics, no ability to do operator overloading, no ability to make your own for each style loop objects, very manual and repetitive error handling. These are all simplifications to the language spec at the expense of more complicated usage. For the most part, I've been trying to understand myself how to express why I get a pretty bad taste in my mouth when using or looking at Go code, why it feels so much less productive to me than the higher-level languages. Which is what it has been making dents in more than anything else. I especially wanted to understand this since I do see myself as someone who values simplicity. In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. I'd instead rather learn a slightly more complicated language, and be more productive with every task I write using it. I don't see Go users as cavemen. That was admittedly an exaggeration to express my point clearly.

nemo1618 7y ago
>In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. That's interesting, because to me, Go accomplishes this fairly well. Generics, operator overloading, and custom 'for' loops make it easier to write "clever" code with surprising behavior. Go's design is not elegant like Lisp or Haskell; there are some warts and special cases that exist for pragmatic reasons. But it manages to be simple and effective, which is sadly a rare thing in the modern language landscape, where the mentality seems to be "more features = better language." 90% of Go's value is in what it takes away, rather than what it adds.
- outworlder 7y ago
  One could make the same argument for Lua.
zadokshi 7y ago
Language designers: Design a language to not use generics. timothycrosley: It doesn't do generics!!! Aaargh!!
- jeremyjh 7y ago
  Except they didn't. Go has generic maps and slices. It was never their goal to create a language without generics. What happened is they failed to come up with a satisfactory design for user defined generics in time to make Go version 1.
  - zadokshi 7y ago
    Exactly, They didn’t feel it was important. It was not part of the language design. https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
badrequest 7y ago
Cool, here's my take: people who insist on a language supporting generics are lazy and uncreative.

srparish 7y ago

+ By declaring a field/variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field/variable you need to audit all your code to make sure you haven't broken things. + gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping/unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything. + Scope of element in for-range loop isn't right, so capturing that scope in a lambda does the wrong thing with no warning. + Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map/filter/reduce or comprehensions. + No help from type-system for use of pointer without nil check. + Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man's unique_ptr<> means that I also get optional<> symantics (without the type checking) when I don't want or expect such. Also allows for aliasing when I don't want or expect such. + Difference between '=' and ':=' is silly, especially since ':=' can be used to reassign values. Even more frustrating that ':=' creates shadowing in nested scopes, so doesn't always do what one would expect it would do, such as accidentally creating a shadowed 'err' that doesn't get checked. + if/switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.

gameswithgo 7y ago
I actually like Go's simplicity a lot, it was very easy for me to learn and very easy to programming with it because of that. But I agree strongly with some of your points. = vs := specifically feels like a plain mistake, and even against Go philosophy of having just 1 way to do things. I think any new language should be designed around options instead of nils. F#, Rust, Zig show different ways to do this, and often any performance penalty can be compiled away. if/switch being expressions is a simple and helpful idea, languages should allow this. using map/filter/reduce as the idiomatic way to do things I am less sure about. This can come in handy but also would add a lot of complexity to Go, and in most languages these have a performance penalty. its important to remember that not all programmers are interested in languages, they just want to get their project done. So being able to hop into a code base and have low cognitive overhead, because there are no mysterious features they have to learn, having quick compile times, and explicit semantics can be really helpful there. That can save you more time than typing less because of generics and meta programming sometimes.

pyrale 7y ago

Well, I don't subscribe to the deprecating aspect of the grunting stuff, but many of these discussions read very much like transcripts of Plato's cave. I had the same experience as a Java dev back when Java8 came out. To me, it felt great. To people using functional languages which this update ported to Java, it looked poorly. It is hard to understand go's criticism if you have not experienced languages leveraging modern datastructures such as, for instance, union types/pattern matching. But if you have, you really feel like the language lacks something.

edflsafoiewq 7y ago
For me, it's not even things like that. It's boring things like push, pop, erase, index_of, etc. that probably everyone has seen but that can't be written in Go.
- badrequest 7y ago
  You can write them, you just can't write them generically.
- virmundi 7y ago
  You can write them but to do so generically you need to do code gen. Unfortunately this means learning a code green template library.