3 ms·

While I appreciate that this is a work in progress and meant for learning, i just want to caution readers and those new to Go that this is a somewhat dangerous

While I appreciate that this is a work in progress and meant for learning, i just want to caution readers and those new to Go that this is a somewhat dangerous way to approach Go. Simply mapping familiar vocabulary from an traditional OO language into Go implies that the differences are superficial and the underlying concepts are largely the same. The truth is that a lot of the traditional vocabulary was very intentionally left out of Go. For example, mapping embedded stucts to "multiple inheritance" masks the fact that Go is trying to guide you into understanding the power of composition over inheritance. It's not that it's impossible to understand that, but by carrying over the terminology, you burden yourself with some preconceptions. Like I said, I know this is a work in progress, but I encourage you to perhaps map the terms but then write a paragraph or two about how they're _different_, not the same. This was a really nice resource for me when I first came to Go: http://spf13.com/post/is-go-object-oriented/ http://spf13.com/post/is-go-object-oriented/

coldtea 10y ago
>Simply mapping familiar vocabulary from an traditional OO language into Go implies that the differences are superficial and the underlying concepts are largely the same. The truth is that a lot of the traditional vocabulary was very intentionally left out of Go. I find that what has been "intentionally left out of Go" is not necessarily a good choice. I also don't get the obsession with "idiomatic" programming. Idiomatic Java/J2EE circa 1998-2008 was total crap (the programming style, not the language). Even its then adherents admit it. Same holds for many other languages/times. Programmers should be consistent with a style, and teams should work with an agreed upon style. But some languages designers to impose their ideas upon all users of a language is wrong.
- logicchains 10y ago
  >Idiomatic Java/J2EE circa 1998-2008 was total crap (the programming style, not the language) I think part of the aim of Go was to make this style impossible, by e.g. removing inheritance, which plays a key role in most crappy Java code.
  - Zach_the_Lizard 10y ago
    Go's lack of generics however (except for special blessed built ins that are OK) forces some of those bad patterns however. Want to write a linked list that works on all types? Hope you like reflection or annoying code generation or copy and paste.
    - dilap 10y ago
      or casting, which is a selective bit of loss of type safety (& a speed hit), but is what the std library linked list impl actually uses, and is what pre-generics java & objc used forever. it ain't great, but it ain't a disaster, either.
      - Zach_the_Lizard 10y ago
        It's 1990s coding in 2016. We have a better way, and even go implements it for certain special types.
        dilap 10y ago
        i'm not saying it's great, but it's the most practical thing in most cases in go, & it was missing from your list. whether or not go would be better with generics is still an open question imo.

coldtea 10y ago

>Simply mapping familiar vocabulary from an traditional OO language into Go implies that the differences are superficial and the underlying concepts are largely the same. The truth is that a lot of the traditional vocabulary was very intentionally left out of Go. I find that what has been "intentionally left out of Go" is not necessarily a good choice. I also don't get the obsession with "idiomatic" programming. Idiomatic Java/J2EE circa 1998-2008 was total crap (the programming style, not the language). Even its then adherents admit it. Same holds for many other languages/times. Programmers should be consistent with a style, and teams should work with an agreed upon style. But some languages designers to impose their ideas upon all users of a language is wrong.

logicchains 10y ago
>Idiomatic Java/J2EE circa 1998-2008 was total crap (the programming style, not the language) I think part of the aim of Go was to make this style impossible, by e.g. removing inheritance, which plays a key role in most crappy Java code.
- Zach_the_Lizard 10y ago
  Go's lack of generics however (except for special blessed built ins that are OK) forces some of those bad patterns however. Want to write a linked list that works on all types? Hope you like reflection or annoying code generation or copy and paste.
  - dilap 10y ago
    or casting, which is a selective bit of loss of type safety (& a speed hit), but is what the std library linked list impl actually uses, and is what pre-generics java & objc used forever. it ain't great, but it ain't a disaster, either.
    - Zach_the_Lizard 10y ago
      It's 1990s coding in 2016. We have a better way, and even go implements it for certain special types.
      - dilap 10y ago
        i'm not saying it's great, but it's the most practical thing in most cases in go, & it was missing from your list. whether or not go would be better with generics is still an open question imo.