6 ms·

The lack of generics in Go is a non-starter for me. There's polymorphism in built-in types, but these throw out compile time correctness guarantees.

by bhickey 12y ago

PopsiclePete 12y ago
I used to be of the same mindset until I tried it. I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO
- copsarebastards 12y ago
  > I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". If you're trying to solve problems caused by your language, maybe the solution is to switch languages. > I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses. The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.
  - danieldk 12y ago
    `go generate` is a fucking terrible idea. No. `go generate` is great for what it was invented for: Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone. Source: https://blog.golang.org/generate https://blog.golang.org/generate It's not meant as a substitute for generics, it's for running tools such as yacc.
    - copsarebastards 12y ago
      I was responding to `go generate` as a subsitute for generics because that's what PopsiclePete was proposing. But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers. Yet again Go ignores decades of programming language research.
      - ngrilly 12y ago
        > `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to. Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-) > C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. Sounds interesting. Any link to share with us?
        copsarebastards 12y ago
- danieldk 12y ago
  The "go generate" is a small step into the direction this will take, IMO It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite. If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects. 'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.
  - PopsiclePete 12y ago
    Like I said, it's a "small step". It's in the quote you quoted in fact. A small step, that's all. There's go generate now, maybe somebody will write "go super-duper-generate" later. All I'm saying is, if "generics" come to Go, it will be through a tool like "go super-duper-generate-v2.0-apples", not syntax. That's all.
    - Jweb_Guru 12y ago
      I mean, we did this. It was called CFront. Now we have C++ templates that are probably Turing-complete and we use them to create things like Boost. Regardless of howyou feel about compile-time metaprogramming like Boost, Go exists as a direct reaction to its complexity, and that's exactly where go generate will take it.
pnathan 12y ago
I found Go extremely difficult to build abstractions in when I did some work in it last year. I would actually rather write Java (speaking as a Lisper). :-)
- PopsiclePete 12y ago
  Yeah, it does kind of suck to write "generic" data structures/algorithms in. Rob Pike has a funny git commit where he implemented general map/reduce in Go using reflection, immediately followed by the comment "don't do this, ever". For some reason, the core Go team has no need to write general algorithms/data structures. They just...write the code when they need to. It's a strange way to think about programming, but for me, it can work. You focus on the "executable", not the "library" (I know that sounds strange...)
  - dottrap 12y ago
    This is very much in spirit to Casey Muratori's (Handmade Hero) 'Compression Oriented Programming' http://mollyrocket.com/casey/stream_0019.html http://mollyrocket.com/casey/stream_0019.html For all the people complaining about both (the lack of) generics and high performance systems level programming, this and his allies in the video game industry such as Mike Acton (Data Oriented Design in C++) https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc and Jonathan Blow (Ideas about a new programming language for games) https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ argue that performance and the focusing on the problem you are trying to solve are intimately related. Needless levels of abstraction (particularly ones that go against the hardware) and generically trying to solve for cases you will never actually use is a waste of real performance and developer time.
zimbatm 12y ago
In the other hand, it helps prevent people to build needlessly complex abstractions. That's what I like about go: relatively straight-forward code to read in most project that I have seen.
- seanmcdirmid 12y ago
  I think it is worth the time to figure out how to do generic code better than it is currently done with parametric polymorphism and templates. And yes, I think going simple on the type system is a valid direction (vs. Scala which focuses on power and expressiveness). But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.
- 4ydx 12y ago
  Yeah I have to second this, a lot of people are really off the mark about how "useful" their abstract solutions to a problem are. Often something is very over-engineered. Once you have to build anything complex on that type of foundation, well, good luck to you! Besides from what I understand the lack of generics is mostly about compile time speed. I love how fast go compiles and would rather that not change.
  - seanmcdirmid 12y ago
    Templates are slow to compile, most modular parametric polymorphism solutions are pretty fast (C#, Java). Barring Scala...but to be fair they have a lot of other things going on in their type system!
- spotman 12y ago
  agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang without all these abstractions and "elegant" ways to do things. (than some languages like java) yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity. at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.

The lack of generics in Go is a non-starter for me. There's polymorphism in built-in types, but these throw out compile time correctness guarantees.

by bhickey 12y ago

The lack of generics in Go is a non-starter for me. There's polymorphism in built-in types, but these throw out compile time correctness guarantees.

PopsiclePete 12y ago

I used to be of the same mindset until I tried it. I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO

copsarebastards 12y ago
> I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". If you're trying to solve problems caused by your language, maybe the solution is to switch languages. > I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses. The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.
- danieldk 12y ago
  `go generate` is a fucking terrible idea. No. `go generate` is great for what it was invented for: Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone. Source: https://blog.golang.org/generate https://blog.golang.org/generate It's not meant as a substitute for generics, it's for running tools such as yacc.
  - copsarebastards 12y ago
    I was responding to `go generate` as a subsitute for generics because that's what PopsiclePete was proposing. But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers. Yet again Go ignores decades of programming language research.
    - ngrilly 12y ago
      > `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to. Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-) > C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. Sounds interesting. Any link to share with us?
      - copsarebastards 12y ago
danieldk 12y ago
The "go generate" is a small step into the direction this will take, IMO It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite. If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects. 'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.
- PopsiclePete 12y ago
  Like I said, it's a "small step". It's in the quote you quoted in fact. A small step, that's all. There's go generate now, maybe somebody will write "go super-duper-generate" later. All I'm saying is, if "generics" come to Go, it will be through a tool like "go super-duper-generate-v2.0-apples", not syntax. That's all.
  - Jweb_Guru 12y ago
    I mean, we did this. It was called CFront. Now we have C++ templates that are probably Turing-complete and we use them to create things like Boost. Regardless of howyou feel about compile-time metaprogramming like Boost, Go exists as a direct reaction to its complexity, and that's exactly where go generate will take it.

pnathan 12y ago

I found Go extremely difficult to build abstractions in when I did some work in it last year. I would actually rather write Java (speaking as a Lisper). :-)

PopsiclePete 12y ago
Yeah, it does kind of suck to write "generic" data structures/algorithms in. Rob Pike has a funny git commit where he implemented general map/reduce in Go using reflection, immediately followed by the comment "don't do this, ever". For some reason, the core Go team has no need to write general algorithms/data structures. They just...write the code when they need to. It's a strange way to think about programming, but for me, it can work. You focus on the "executable", not the "library" (I know that sounds strange...)
- dottrap 12y ago
  This is very much in spirit to Casey Muratori's (Handmade Hero) 'Compression Oriented Programming' http://mollyrocket.com/casey/stream_0019.html http://mollyrocket.com/casey/stream_0019.html For all the people complaining about both (the lack of) generics and high performance systems level programming, this and his allies in the video game industry such as Mike Acton (Data Oriented Design in C++) https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc and Jonathan Blow (Ideas about a new programming language for games) https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ argue that performance and the focusing on the problem you are trying to solve are intimately related. Needless levels of abstraction (particularly ones that go against the hardware) and generically trying to solve for cases you will never actually use is a waste of real performance and developer time.

zimbatm 12y ago

In the other hand, it helps prevent people to build needlessly complex abstractions. That's what I like about go: relatively straight-forward code to read in most project that I have seen.

seanmcdirmid 12y ago
I think it is worth the time to figure out how to do generic code better than it is currently done with parametric polymorphism and templates. And yes, I think going simple on the type system is a valid direction (vs. Scala which focuses on power and expressiveness). But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.
4ydx 12y ago
Yeah I have to second this, a lot of people are really off the mark about how "useful" their abstract solutions to a problem are. Often something is very over-engineered. Once you have to build anything complex on that type of foundation, well, good luck to you! Besides from what I understand the lack of generics is mostly about compile time speed. I love how fast go compiles and would rather that not change.
- seanmcdirmid 12y ago
  Templates are slow to compile, most modular parametric polymorphism solutions are pretty fast (C#, Java). Barring Scala...but to be fair they have a lot of other things going on in their type system!
spotman 12y ago
agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang without all these abstractions and "elegant" ways to do things. (than some languages like java) yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity. at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.