Hacker News Reader

Comment by bojo | Hacker News Reader

All these Go applications/talks/whatever coming out of the woodwork make me giggle. YOU CAN'T DO AWESOME STUFF WITHOUT GENERICS, OK?

View on HN

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.

From what I've seen though, most of these projects are executable applications, often with a small code base and written by at most a handful of people. I don't think this is the type of code that really benefits from generics.

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.

Every time I have to write a duplicate XYZServiceResponse instead of ServiceResponse<XYZ>, 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?

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

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?

if you have a standard ServiceResponse wrapper with meta information and a 'response' field that is the actual contents of the response. Leads to FooServiceResponse, BarServiceResponse vs. if you just have a generic ServiceResponse<T>

Yeah, it's like how all those people cutting trees with a manual saw proved that you don't need a power saw!

Or maybe programming languages aren't like saws at all and your analogy is fundamentally compromised by this. They are tools, but they are there own tools. Good at what they are good at and people are apt to use what feels right. More power to them.

>Good at what they are good at and people are apt to use what feels right. More power to them.

That's just wishy washy "let's everyone use what's best for them" etc.

It's not like there's not something called computer SCIENCE, and PL research, that has studied Generics and what they bring to the table...

You're pretty hilarious. There's no SCIENCE here, there's religious fanaticism on both sides driven by anecdotes from thousands of amateurs. Where's the rigorous study that shows if Go or Haskell is better for building quality software?

These tools don't solve some mythical perfect "math" problem. They solve a "social" problem. We write software to help people. Wether a language has generics or not almost certainly not the most important factor that drives the success or failure of a project. But hey, I haven't done a rigorous study to back that up. At least I can admit that.

Generics are like a power saw? ASM doesn't have generics.

ASM doesn't have much in the way of type restrictions either...

Is there something about generics I'm missing? Other than during discovery, when do you have input that you cannot anticipate its type and you are forced to modify it?

I think you're missing something about generics, yes. Firstly, often you don't know the type you're working with because you're writing a generic library, made to be used generically. Secondly, often you want to write some generic data structures or algorithms and parameterize them over multiple known types, and generics help you avoid repeating yourself but maintain strong static typing.

Reply on news.ycombinator.com