4 ms·

I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive cod

by woah 10y ago

I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. It's part of the bargain. Still, if you really feel passionately that Go with generics would be frickin' awesome, generics seem like a pretty easy thing to write a preprocessor for. With the great knowledge of programming language design and implementation that most pro-go-generics internet forum posters have, it should be a piece of cake.

weberc2 10y ago
I don't think it's very easy, particularly the error handling paths. Further, `go build` and friends don't support preprocessors. Much ink has been spilled about the difficulties of implementing generics.
nemo1618 10y ago
>generics seem like a pretty easy thing to write a preprocessor for I am basically doing this: https://github.com/lukechampine/ply https://github.com/lukechampine/ply Ply is like Go except you can write things like []int{1,2,3}.filter(even) and it will Just Werk. It's not quite ready yet, but it feels promising. The idea is that Go doesn't really need full support for generics; most people just want a few more higher-order functions available for manipulating slices, maps, and channels.
- rtegx 10y ago
  Havelang is an attempt to implement full blown generics (among others) for Go, and is getting close to being usable.
  - camus2 10y ago
    http://havelang.org/ http://havelang.org/ It's how C++ started. Unfortunately, that's how it will also end for Go, because of Go designers ignoring the past.
  - nemo1618 10y ago
    Have looks pretty cool, and their project is certainly far more involved than mine (e.g. they have their own lexer/parser). I am excited to see more compile-to-Go languages. The only other one I'm aware of is iGo. That said, I'm curious to know if Have is able to eliminate intermediate structures (deforesting) when chaining together transformations. Haskell performs "stream fusion" to accomplish this, but I'm not aware of how it's done in other languages. Ply does support this optimization, and that's mostly possible because it restricts the generics to a built-in set (rather than allowing the programmer to define their own generic functions). My other goal with Ply is to make it as familiar as possible to Go programmers. It's not so much inventing a new language as it is scratching an itch.
deleted 10y ago
[deleted]
parenthephobia 10y ago
> I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. Your second sentence answers your first. Not everyone likes writing the same code over and over again, even if it's simple code. > generics seem like a pretty easy thing to write a preprocessor for Very funny. But even if it were possible, the bigger problem with using a preprocessor is that everyone ends up using their own incompatible generics preprocessor.
- prodigal_erik 10y ago
  The best possible outcome is that everyone agrees on the same preprocessor/macro-expander and we start treating Go as a compilation target that isn't suited for human beings to read or write. Others have pointed out this is how we got C++ and stopped putting method dispatch and stack unwinding boilerplate at the same level as the code we really care about.
solidsnack9000 10y ago
This is what happened for C, too. It definitely works out. There's just a question of whether it's an end result that we want.
- camus2 10y ago
  C has macros handled by C compilers, no need to hack templates with third party pre-processors like Go gen. You can't even compare C and Go in that case. In fact C is more expressive and type safe than Go.
  - pjmlp 10y ago
    It worked so well that C11 now supports a kind of lite generics. http://en.cppreference.com/w/c/language/generic http://en.cppreference.com/w/c/language/generic
  - solidsnack9000 10y ago
    C macros are not hygienic, which is one motivation for C++ templates. I agree with what you're saying about the pre-processor being part of the standard but it's really hard to write those things in a way that is safe. There were many motivations for C++ -- and many more seemed to get added as it went along -- it's not just generics parametric polymorphism. Of course I would hate to say: Go should have every language feature or else we'll end up with Go++ or Objective-Go or something like that. But simplicity is not just a matter of not providing for something.

by woah 10y ago

weberc2 10y ago

I don't think it's very easy, particularly the error handling paths. Further, `go build` and friends don't support preprocessors. Much ink has been spilled about the difficulties of implementing generics.

nemo1618 10y ago

>generics seem like a pretty easy thing to write a preprocessor for I am basically doing this: https://github.com/lukechampine/ply https://github.com/lukechampine/ply Ply is like Go except you can write things like []int{1,2,3}.filter(even) and it will Just Werk. It's not quite ready yet, but it feels promising. The idea is that Go doesn't really need full support for generics; most people just want a few more higher-order functions available for manipulating slices, maps, and channels.

rtegx 10y ago
Havelang is an attempt to implement full blown generics (among others) for Go, and is getting close to being usable.
- camus2 10y ago
  http://havelang.org/ http://havelang.org/ It's how C++ started. Unfortunately, that's how it will also end for Go, because of Go designers ignoring the past.
- nemo1618 10y ago
  Have looks pretty cool, and their project is certainly far more involved than mine (e.g. they have their own lexer/parser). I am excited to see more compile-to-Go languages. The only other one I'm aware of is iGo. That said, I'm curious to know if Have is able to eliminate intermediate structures (deforesting) when chaining together transformations. Haskell performs "stream fusion" to accomplish this, but I'm not aware of how it's done in other languages. Ply does support this optimization, and that's mostly possible because it restricts the generics to a built-in set (rather than allowing the programmer to define their own generic functions). My other goal with Ply is to make it as familiar as possible to Go programmers. It's not so much inventing a new language as it is scratching an itch.

deleted 10y ago

[deleted]

parenthephobia 10y ago

> I wonder what the point of railing against a lack of generics is. When I sit down to write Go, I know that I will be writing a lot of simple, yet repetitive code. Your second sentence answers your first. Not everyone likes writing the same code over and over again, even if it's simple code. > generics seem like a pretty easy thing to write a preprocessor for Very funny. But even if it were possible, the bigger problem with using a preprocessor is that everyone ends up using their own incompatible generics preprocessor.

prodigal_erik 10y ago
The best possible outcome is that everyone agrees on the same preprocessor/macro-expander and we start treating Go as a compilation target that isn't suited for human beings to read or write. Others have pointed out this is how we got C++ and stopped putting method dispatch and stack unwinding boilerplate at the same level as the code we really care about.

solidsnack9000 10y ago

This is what happened for C, too. It definitely works out. There's just a question of whether it's an end result that we want.

camus2 10y ago
C has macros handled by C compilers, no need to hack templates with third party pre-processors like Go gen. You can't even compare C and Go in that case. In fact C is more expressive and type safe than Go.
- pjmlp 10y ago
  It worked so well that C11 now supports a kind of lite generics. http://en.cppreference.com/w/c/language/generic http://en.cppreference.com/w/c/language/generic
- solidsnack9000 10y ago
  C macros are not hygienic, which is one motivation for C++ templates. I agree with what you're saying about the pre-processor being part of the standard but it's really hard to write those things in a way that is safe. There were many motivations for C++ -- and many more seemed to get added as it went along -- it's not just generics parametric polymorphism. Of course I would hate to say: Go should have every language feature or else we'll end up with Go++ or Objective-Go or something like that. But simplicity is not just a matter of not providing for something.