3 ms·

Can you name a few examples?

by eleitl 7y ago

arcticbull 7y ago
Garbage collection, lack of proper generics except for standard library collections, interface{} and the weird way of distinguishing visibility via capitalization, and comments that affect code generation. Oh, and blowing the cobwebs off some archaic plan 9 assembler instead of using LLVM. That’s not to say it’s all bad, far from it, but these were my wtf moments exploring the language.
- dgb23 7y ago
  > Garbage collection This is hardly a weird choice. Garbage collection gives you the highest productivity while being memory safe out of the three options (manual, GC, static). > lack of proper generics They are working on parametric polymorphism, since a while now. It is hard to get right in a language which has readability and simplicity as a main focus. > interface{} I certainly agree on this one. It is a weird feature and often a 'smell' when found in Go code. > the weird way of distinguishing visibility via capitalization It is weird syntax choice in the sense of being unique/uncommon but fits very well into the readability focus of Go. > comments that affect code generation I agree that they should have introduced syntax for this, assuming you mean compiler flags (or w/e they're called). > archaic plan 9 assembler instead of using LLVM One of the goals of the language is to compile really fast, which they certainly succeed at.
  - jerf 7y ago
    "> interface{} I certainly agree on this one. It is a weird feature and often a 'smell' when found in Go code." The feature itself is not a problem. Every major static language has the equivalent. It's often called something that involves the word "dynamic". Having programmed in Go for many years now, I don't find myself using it very often in my own code. I've come to think of this as something said by either people who have never used Go at all, or people who used Go briefly but insisted on programming Javascript-in-Go or something. The latter is definitely a Bad Time... but it's always bad to program X-in-Y. If your code is shot through with interface{}, you either chose Go for something way outside of its domain, or you are not using it correctly. "> comments that affect code generation I agree that they should have introduced syntax for this, assuming you mean compiler flags (or w/e they're called)." This is another criticism that I think mostly comes from people with a checklist criticism set of Go, because in practice, this is of negligible concern. It doesn't come up often, it isn't proliferating (i.e., it's not like with every point release we get another two or three new kinds of comments), it's literally never been an issue of any kind for me in the last six years. It's a complete non-issue. I am far more annoyed by, say, the fact godoc doesn't give me basic markdown than comments affecting compilation has ever annoyed me, and that's just an occasional minor annoyance.
    - _ph_ 7y ago
      I think interface{} is a great feature, when you want to write code that safely handles any type. fmt.Printf is a great example for this. As type information is attached with the value, type safety is fully maintained when casting the contained value back to its right type. Where it is appropriate, it is a very cool thing that you can have fully dynamically typed variables with all safeties in place. Of course, it shouldn't be used in place of better abstractions, like specific interfaces or properly factored code.
    - dgb23 7y ago
      > It's a complete non-issue. It is an issue as someone who doesn't write Go code often but occasionally reads/debugs it. At least for the first couple of times I've come across it made me scratch my head for a couple of hours, because I didn't see what the issue was it being 'hidden' in the comments. Which is fine. It just isn't in line with the general premise of Go's language design, so I wasn't even expecting it. So in a sense you are right!

Can you name a few examples?

by eleitl 7y ago

Can you name a few examples?

Garbage collection, lack of proper generics except for standard library collections, interface{} and the weird way of distinguishing visibility via capitalization, and comments that affect code generation. Oh, and blowing the cobwebs off some archaic plan 9 assembler instead of using LLVM. That’s not to say it’s all bad, far from it, but these were my wtf moments exploring the language.

dgb23 7y ago
> Garbage collection This is hardly a weird choice. Garbage collection gives you the highest productivity while being memory safe out of the three options (manual, GC, static). > lack of proper generics They are working on parametric polymorphism, since a while now. It is hard to get right in a language which has readability and simplicity as a main focus. > interface{} I certainly agree on this one. It is a weird feature and often a 'smell' when found in Go code. > the weird way of distinguishing visibility via capitalization It is weird syntax choice in the sense of being unique/uncommon but fits very well into the readability focus of Go. > comments that affect code generation I agree that they should have introduced syntax for this, assuming you mean compiler flags (or w/e they're called). > archaic plan 9 assembler instead of using LLVM One of the goals of the language is to compile really fast, which they certainly succeed at.
- jerf 7y ago
  "> interface{} I certainly agree on this one. It is a weird feature and often a 'smell' when found in Go code." The feature itself is not a problem. Every major static language has the equivalent. It's often called something that involves the word "dynamic". Having programmed in Go for many years now, I don't find myself using it very often in my own code. I've come to think of this as something said by either people who have never used Go at all, or people who used Go briefly but insisted on programming Javascript-in-Go or something. The latter is definitely a Bad Time... but it's always bad to program X-in-Y. If your code is shot through with interface{}, you either chose Go for something way outside of its domain, or you are not using it correctly. "> comments that affect code generation I agree that they should have introduced syntax for this, assuming you mean compiler flags (or w/e they're called)." This is another criticism that I think mostly comes from people with a checklist criticism set of Go, because in practice, this is of negligible concern. It doesn't come up often, it isn't proliferating (i.e., it's not like with every point release we get another two or three new kinds of comments), it's literally never been an issue of any kind for me in the last six years. It's a complete non-issue. I am far more annoyed by, say, the fact godoc doesn't give me basic markdown than comments affecting compilation has ever annoyed me, and that's just an occasional minor annoyance.
  - _ph_ 7y ago
    I think interface{} is a great feature, when you want to write code that safely handles any type. fmt.Printf is a great example for this. As type information is attached with the value, type safety is fully maintained when casting the contained value back to its right type. Where it is appropriate, it is a very cool thing that you can have fully dynamically typed variables with all safeties in place. Of course, it shouldn't be used in place of better abstractions, like specific interfaces or properly factored code.
  - dgb23 7y ago
    > It's a complete non-issue. It is an issue as someone who doesn't write Go code often but occasionally reads/debugs it. At least for the first couple of times I've come across it made me scratch my head for a couple of hours, because I didn't see what the issue was it being 'hidden' in the comments. Which is fine. It just isn't in line with the general premise of Go's language design, so I wasn't even expecting it. So in a sense you are right!