Live data from Hacker News

Gen - a generics library for Go

clipperhouse.github.io

41–49 of 49 posts

Re: Gen - a generics library for Go

#41
post #2

Here is someone trying to come up with a good solution for generics, rather than simply complaining it don't exist. I am thankful for the effort.

Good? It's an ugly hack with limited functionality (due to Go's design, not the developers' skill and good will). A good solution would be forking the reference compiler and doing a proper implementation.

I think if he gets something good enough that Go devs like, then some form of it might very well be rolled into the compiler itself.

Re: Gen - a generics library for Go

#42
post #29

Earlier quoted context omitted.

> no multidimensional arrays That's not true, e.g. [4][4]byte is a multi-dimensional array. It's a contiguous block of 16 bytes of memory.

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

> The size has to be known at compile time, though.

That's the whole point of an array in Go. So you meant slices, not arrays.

Re: Gen - a generics library for Go

#43
post #9

Thanks for your effort. This is not about the library. Your site's mobile version is kinda broken. The left menu thingy always remain in the site and you can't read the main context. This happened to me on my Android Firefox Browser.

Same here, I couldn't read it at all.

Re: Gen - a generics library for Go

#44

Earlier quoted context omitted.

That's functional programming for you. It's definitely less efficient, but there are other major advantages. For one thing, given the propagation of immutable data, things can be parallelized effortlessly - look at 'pmap' in Clojure for example. Once you're familiar with the style, it's significantly more concise and readable. That being said, a systems programming language may not be the right place for FP concepts.

>That's functional programming for you. Uhm, what? No it's not. Haskell has stream fusion, thereby generating assembler that looks a lot like the optimal imperative version.

This is kind of misleading. Stream fusion isn't baked into Haskell; you need to use a library. [1,2]

    [1] - https://ghc.haskell.org/trac/ghc/ticket/915
    [2] - http://hackage.haskell.org/package/stream-fusion

Re: Gen - a generics library for Go

#45

Earlier quoted context omitted.

That's functional programming for you. It's definitely less efficient, but there are other major advantages. For one thing, given the propagation of immutable data, things can be parallelized effortlessly - look at 'pmap' in Clojure for example. Once you're familiar with the style, it's significantly more concise and readable. That being said, a systems programming language may not be the right place for FP concepts.

D is a systems programming language with FP concepts and they work quite well. Also, it has generics / templates / parametric polymorphism that are more powerful and easier to use than C++.

Right, but it still employs a machine model of computation. This is fundamentally different from FP's language model.

https://existentialtype.wordpress.com/2011/03/16/languages-a...

Re: Gen - a generics library for Go

#46
post #20
post #13

Earlier quoted context omitted.

Historical tidbit: Pizza is the precursor to Java's own generics implementation (introduced in Java 5), both were written by Martin Odersky who then went on to create Scala.

Wow, 12 years old: http://pizzacompiler.sourceforge.net/

- Generics (aka Parametric polymorphism) - Function pointers (aka First-class functions) - Class cases and pattern matching (aka Algebraic types)

13 years, and only it's three features has made it into Java

I wish Sun found a way to transfer the Java trademark to Odersky before dying. Scala has so many nice features that companies prohibit because the language isn't called "Java".

Re: Gen - a generics library for Go

#47

Earlier quoted context omitted.

>That's functional programming for you. Uhm, what? No it's not. Haskell has stream fusion, thereby generating assembler that looks a lot like the optimal imperative version.

This is kind of misleading. Stream fusion isn't baked into Haskell; you need to use a library. [1,2] [1] - https://ghc.haskell.org/trac/ghc/ticket/915 [2] - http://hackage.haskell.org/package/stream-fusion

But, many of the commonly used libraries already use stream fusion, e.g. vector and text.

Re: Gen - a generics library for Go

#48

Earlier quoted context omitted.

>That's functional programming for you. Uhm, what? No it's not. Haskell has stream fusion, thereby generating assembler that looks a lot like the optimal imperative version.

This is kind of misleading. Stream fusion isn't baked into Haskell; you need to use a library. [1,2] [1] - https://ghc.haskell.org/trac/ghc/ticket/915 [2] - http://hackage.haskell.org/package/stream-fusion

http://hackage.haskell.org/package/text-0.1/docs/Data-Text-F...

http://hackage.haskell.org/package/vector-0.9.1/docs/Data-Ve...

Except it's bloody everywhere in the libraries you use and you can design your own libraries around it.

A language powerful enough that things like this can be done in libraries instead of in the compiler is a good thing.

Re: Gen - a generics library for Go

#49
post #2

Here is someone trying to come up with a good solution for generics, rather than simply complaining it don't exist. I am thankful for the effort.

Just because there is no solutions yet, it does not mean you can just throw out any solution. I don't think code generation is a good solution for generics but I like the Linq feature though.
Post reply on HN