4 ms·

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, althou

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.

NateDad 12y ago
Go has a very nice standard library. The whole thing is reusable code.
- falcolas 12y ago
  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.
  - NateDad 12y ago
    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.
    - theseoafs 12y ago
      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.
      - NateDad 12y ago
        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.
sentiental 12y ago
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 http://blog.golang.org/generate
- irq-1 12y ago
  > 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.
vardump 12y ago
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...
- falcolas 12y ago
  Like c's 'libc', or C++ boost, or pythons 'requests', or... Lots of code reuse there that depends on generics.
  - vardump 12y ago
    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.
    - falcolas 12y ago
      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).
    - codygman 12y ago
      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.
- coldtea 12y ago
  >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.

NateDad 12y ago

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

falcolas 12y ago
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.
- NateDad 12y ago
  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.
  - theseoafs 12y ago
    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.
    - NateDad 12y ago
      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.

sentiental 12y ago

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 http://blog.golang.org/generate

irq-1 12y ago
> 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.

vardump 12y ago

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...

falcolas 12y ago
Like c's 'libc', or C++ boost, or pythons 'requests', or... Lots of code reuse there that depends on generics.
- vardump 12y ago
  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.
  - falcolas 12y ago
    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).
  - codygman 12y ago
    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.
coldtea 12y ago
>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.