51–60 of 74 posts
All these Go applications/talks/whatever coming out of the woodwork make me giggle. YOU CAN'T DO AWESOME STUFF WITHOUT GENERICS, OK?
Every time I have to write a duplicate XYZServiceResponse instead of ServiceResponse , I don't think "Hey I can't do stuff", I think "I have to copy and paste the same code AGAIN."
Earlier quoted context omitted.
Every time I have to write a duplicate XYZServiceResponse instead of ServiceResponse , I don't think "Hey I can't do stuff", I think "I have to copy and paste the same code AGAIN."
Perhaps you should instead be composing an XYZServiceResponse that implements the ServiceResponse interface?
Earlier quoted context omitted.
I don't think anybody's said anything like that. You can build awesome software projects using almost any toolset. C, or C++, or Ruby, or Go, or Java, or… The question is – is the trade-off worth it? Lack of generics makes things more awkward – but it's also simpler, so maybe it's a net gain? Some people think it is, and some people think it's not. But it's a useful conversation to have.
Considering how many cool projects are being written in Go lately, it seems that a lot of people either don't mind the lack of generics or like the rest of Go enough to power through. I'm personally in the latter camp, though I can't say I've written anything remotely as cool as this.
As a Scala developer I heavily use generics, but generally only when writing libraries. Application code, code that becomes the final executable and isn't mean to be reused, is usually very light on generics and many other fancier aspects of the type system. Perhaps it goes without saying, but it's only when writing generic code do generics really become important.
To me, Go seems good for one-off projects like this. The code is straightforward and it's small enough that it's not a big deal to hand-write functions that could have been generic. But for large projects or for writing highly reusable code, Go seems really unfit for the job, and I think it's those kinds of projects people have in mind when they criticize Go for not having more powerful features like generics.
All these Go applications/talks/whatever coming out of the woodwork make me giggle. YOU CAN'T DO AWESOME STUFF WITHOUT GENERICS, OK?
Yeah, it's like how all those people cutting trees with a manual saw proved that you don't need a power saw!
Earlier quoted context omitted.
Perhaps you should instead be composing an XYZServiceResponse that implements the ServiceResponse interface?
Can't json deserialize things to interface{} and then use members.
All these Go applications/talks/whatever coming out of the woodwork make me giggle. YOU CAN'T DO AWESOME STUFF WITHOUT GENERICS, OK?
Earlier quoted context omitted.
Can't json deserialize things to interface{} and then use members.
Good point - throw in a parent struct type. http://play.golang.org/p/oASRdqN0eQ
The author likes terminals a lot: http://gizak.github.io/ Projects like this make me want to have an excuse to use them.
Earlier quoted context omitted.
Good point - throw in a parent struct type. http://play.golang.org/p/oASRdqN0eQ
Good pull, but are there really that many use cases in production code where you need to consume JSON that you don't have an expectation of what types of data are coming your way?