4 ms·

It seems to be a rite of passage that everyone who gets to a certain point of familiarity with Go has to write an article justifying why you don't need generics

It seems to be a rite of passage that everyone who gets to a certain point of familiarity with Go has to write an article justifying why you don't need generics. Austerity can be a tough way to live until you become a bit numb.

coldtea 12y ago
http://en.wikipedia.org/wiki/Stockholm_syndrome http://en.wikipedia.org/wiki/Stockholm_syndrome
marcus_holmes 12y ago
Another rite of passage is the "logger" library, where every Go coder I know (including me) writes a "better" logging library because the standard one is so terse. A few thousand lines of code later, everyone quietly discards their overcomplex library and reverts back to the standard log. The same goes for most of the standard library "improvements" that people make. Http middleware is necessary until you grok the power of Handlers, ORMs are prevalent until you get that it's easier to write specific CRUD routines for your structs using the standard lib. I don't think it's austerity any more. I think it's just putting a high value on simplicity, and I really appreciate that now I understand it better. I'm happy to let the generics argument rage and smarter people than me resolve it. I don't need generics in my coding, happy to work around the occasional time I'd use them, but I understand the "argument from make" - if the Go team needed generics to build the language, then surely they're a Good Thing and we should have them.
weberc2 12y ago
I don't know. I program in C++ all day long--it took a loooong time to figure out the good patterns in the sea of options or to learn to interpret the cryptic and/or vague error messages (I just got an "invalid use of class" error today with GCC that contained nothing more than a line number for data). And that's not counting the sea of build systems, style guidelines, etc. And even with the generics situation, the amount of boilerplate in Go is a tiny fraction of that in C++. I'm quite happy to yield control to sane defaults, widely-accepted conventions, and obvious idioms when I'm at home. If I ever need to write some high performance application, I'll definitely consider switching back to C++ (or perhaps learning Rust), but Go is great for rapid development of decently-fast-executing programs.

coldtea 12y ago

http://en.wikipedia.org/wiki/Stockholm_syndrome http://en.wikipedia.org/wiki/Stockholm_syndrome

marcus_holmes 12y ago

Another rite of passage is the "logger" library, where every Go coder I know (including me) writes a "better" logging library because the standard one is so terse. A few thousand lines of code later, everyone quietly discards their overcomplex library and reverts back to the standard log. The same goes for most of the standard library "improvements" that people make. Http middleware is necessary until you grok the power of Handlers, ORMs are prevalent until you get that it's easier to write specific CRUD routines for your structs using the standard lib. I don't think it's austerity any more. I think it's just putting a high value on simplicity, and I really appreciate that now I understand it better. I'm happy to let the generics argument rage and smarter people than me resolve it. I don't need generics in my coding, happy to work around the occasional time I'd use them, but I understand the "argument from make" - if the Go team needed generics to build the language, then surely they're a Good Thing and we should have them.

weberc2 12y ago

I don't know. I program in C++ all day long--it took a loooong time to figure out the good patterns in the sea of options or to learn to interpret the cryptic and/or vague error messages (I just got an "invalid use of class" error today with GCC that contained nothing more than a line number for data). And that's not counting the sea of build systems, style guidelines, etc. And even with the generics situation, the amount of boilerplate in Go is a tiny fraction of that in C++. I'm quite happy to yield control to sane defaults, widely-accepted conventions, and obvious idioms when I'm at home. If I ever need to write some high performance application, I'll definitely consider switching back to C++ (or perhaps learning Rust), but Go is great for rapid development of decently-fast-executing programs.