Live data from Hacker News

Gen - a generics library for Go

clipperhouse.github.io

21–30 of 49 posts

Re: Gen - a generics library for Go

#21

These higher-order functions are a very inefficient way to write loops in Go. When you chain them you will end up with multiple sequential iterations instead of only one. Sort should not allocate and return a new slice, it's better to sort in-place, etc.

It’s by design, though I understand the concern. From a design perspective, I like getting a distinct slice out the other end, without having to wonder whether I’ve mutated my original slice. It’s more stateless, so to speak.

Fwiw, slices are inexpensive by design. The elements themselves are not copied. Allocating a new slice is really a small ‘struct’ which serves as a pointer to the underlying array: http://blog.golang.org/go-slices-usage-and-internals

(Gen’ing pointers is supported, which mitigates the potential for allocation.)

It is true that chained operations will be multiple iterations. Whether it will net out to more iterations than otherwise depends on the use.

I’d be interested to see if someone can come up with a pattern where the operations themselves are composed, with a ’.Results()’ method that can intelligently (lazily?) minimize iterations. That’d be impressive.

Re: Gen - a generics library for Go

#22
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'm interested in Go but haven't looked into it yet. The fact that we're even talking about "generics" makes me nervous about further exploring it. Generic collections that have clean, dry implementations seem to be pretty much a requirement for new programming languages, in the way that core support for hashes is.

Re: Gen - a generics library for Go

#23
post #18

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 being said, a systems programming language may not be the right place for FP concepts. It's good enough for Rust.

Note that the Rust compiler doesn't do any stream fusion; rather the functional idioms are designed around iterators, which provide a functional interface that relatively easily and predictably compiles down to code that's as efficient as the corresponding for loop.

Re: Gen - a generics library for Go

#24
I really hope this will get solved in the language itself, I like Go quite a bit, but there are quite ugly places, all related to generics I guess:

- No min/max for integers (and Go doesn't have the ternary operator)

- No IsMember for checking if an object is in a collection

- Directly from the Gen page: Go’s sort package requires the fulfillment of three interface members, two of which are usually boilerplate. If you want to sort by different criteria, you need to implement multiple ‘alias’ types.

Also, unrelated to generics, but no multidimensional arrays.

Re: Gen - a generics library for Go

#26
post #24

I really hope this will get solved in the language itself, I like Go quite a bit, but there are quite ugly places, all related to generics I guess: - No min/max for integers (and Go doesn't have the ternary operator) - No IsMember for checking if an object is in a collection - Directly from the Gen page: Go’s sort package requires the fulfillment of three interface members, two of which are usually boilerplate. If yo…

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

Re: Gen - a generics library for Go

#27

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.

Very cool - I was not aware of this feature. Fwiw, I'm actually something of an FP zealot; I failed to make a stronger case in my comment because I'm tired of arguing, and I'm concerned that I'm being obnoxious.

Re: Gen - a generics library for Go

#28
post #18

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 being said, a systems programming language may not be the right place for FP concepts. It's good enough for Rust.

I wondered about that - Rust looks like the one systems programming language I would actually enjoy using, but I don't know enough about it to have an informed opinion.

Re: Gen - a generics library for Go

#29
post #24

I really hope this will get solved in the language itself, I like Go quite a bit, but there are quite ugly places, all related to generics I guess: - No min/max for integers (and Go doesn't have the ternary operator) - No IsMember for checking if an object is in a collection - Directly from the Gen page: Go’s sort package requires the fulfillment of three interface members, two of which are usually boilerplate. If yo…

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

Re: Gen - a generics library for Go

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

Packages aren't enough of a namespace differentiator for you?
Post reply on HN