Hacker News Reader

Comment by brianolson | Hacker News Reader

The first point "no generics, no code reuse" is the best one. Go really needs generics/templates/macros or _something_. It doesn't even have subclassing, although you can kinda extend a type if you only use its public interface. I've been tempted to see if I could reasonably use the "text/template" package and feed that back into the Go compiler to achieve this.

The rest is mostly a Haskell fanboy whining that Go isn't Haskell.

View on HN

I am starting to think they'll be recommending we use `go generate` to do handwritten templates before too long. It saves them the hassle of building generics into the type system and they clearly want it to be part of the build cycle.

http://blog.golang.org/generate

> Just keep in mind that it is for package authors, not clients...

Generics by author-template sounds exactly like what the Go authors would want: source code is still shared (rather than binaries), no Make/Include/Macros for the build, and no hassle for the _user_ of a package.

> Also, if the containing package is intended for import by go get, once the file is generated (and tested!) it must be checked into the source code repository to be available to clients.

Moving external processes into the source code is characteristic of how they've developed Go.

A GCO/SWIG style generator built-in to `go` would be a great next step. It wouldn't have to be perfect, just deal with includes and defines separate from Go build. Even if the output needed to be hand edited it would be a great starting point.

Go has a very nice standard library. The whole thing is reusable code.

Not every problem can be solved with the standard library. At some point you need a 3rd party library, which may require your modification to work with your data types.

The point is that everyone assumes you need generics to reuse code. And that's simply not true. For some very specific problems that can be true, but in many many cases it's not. My point is not that you never need anything outside the standard library, just that the standard library does a hell of a lot and it is by definition reusable.

Go's standard library uses generics a lot. In fact, Go's built-in datatypes are the only parts of the language that are allowed to use generics.

Built ins are not the same as the standard library. The standard library consists of packages written in normal go for things like networking, web servers, JSON, regular expressions, etc.

Best joke in the industry:

"Code reuse!"

Cracks me up every time. ;-)

We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...

>We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...

I don't know in what industry you work for. In the IT industry code reuse very much happens every time.

It might not be using code from your previous project to build the next one (through people do that ALL the TIME), that it's very much using common libs for thousands of projects.

The kind of code reuse he talks about has been working perfectly fine for ages. E.g a generic sort, filter etc function, instead of having to handle the basics every time.

Like c's 'libc', or C++ boost, or pythons 'requests', or...

Lots of code reuse there that depends on generics.

Yes, libraries get used. That's their point. My point was, that very little of application code ever gets reused, although we somehow always think it will.

And most people are asking for generics to write libraries which don't rely on unblocking interfaces.

Even in the process of writing a single program, there are a number of times where you reuse certain bits of logic, and having generics makes it easier to refactor those into a single function, instead of duplicate code with multiple types (or overly generic types).

That's why you write or update libraries before writing an application, so it can be reused and your application specific code is minimized as much as possible.

Reply on news.ycombinator.com