Live data from Hacker News

Go generics are not bad

lemire.me

91–100 of 305 posts

Re: Go generics are not bad

#91
post #88

Earlier quoted context omitted.

Generics are great when you need them, but they will cut you badly if you misuse them. Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too. Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that…

This is not the case with traits/type class approach seen in Rust/Haskell.

I'm afraid that it most certainly is, as Rust is the only language I have ever used generics in, and I had this problem.

Lifetimes suffer from the exact same problem as well, since they're really an exotic form of generic.

That said, I will readily admit that it was a lack of skill on my part. From talking to people in the Rust community though, I gather this isn't an uncommon experience.

Re: Go generics are not bad

#92
post #36

The title says Go generics are not bad, and then in less than a page this guy only compared one use case with Java's generics. I'd expect a CS professor to be able to add a little more rigor in a blog post but I guess everyone is losing patience to read and write these days, even for the supposedly erudite.

[deleted]

Re: Go generics are not bad

#93

Earlier quoted context omitted.

Why not use a free function? That is more flexible. Go isn’t Java, it is not a deadly sin to write free functions. You look at something like the Reader and Writer interfaces and there are very few methods. The Go approach is to put more functionality in free functions such as fmt.Fprintf which allows more code reuse across multiple types. In fact I view the heavy Java use of methods as an anti-pattern.

One surely can, and probably that's about the only option they have. But for some `foo.Add(bar)` can be considered nicer than `AddFoo(foo, bar)` or `foopkg.Add(foo, bar)`. The semantic differences are mostly in in an aesthetic/stylistic/personal preferences realm, so it's hard to argue for or against it.

Except that in Java, the former is more common and in Go, the latter is more common. Really, the latter looks more like idiomatic Go, which makes the original complaint somewhat redundant. You might stylistically prefer the former, but then you're probably not going to enjoy using Go anyway.

Re: Go generics are not bad

#95

I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k

Type classes are on the roadmap after Valhalla [1].

[1] https://blogs.oracle.com/javamagazine/post/what-are-they-bui...

Re: Go generics are not bad

#97

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

Does Haskell make it through your filter, with its multi-disciplinary foundation and mix of industrial and academic sponsors?

Re: Go generics are not bad

#98

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

For the working programmer do you really want theoretical soundness? Though I have background in formal mathematics, when it comes to day to day, and what pays the bills, what I might need to operate in anger, I much much more care about legibility, debuggability, inspectability, easy to implement X (without a stdlib if need be), easy to test, no footguns, PL respects programmers (btw go fails most of these)

Re: Go generics are not bad

#99

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

At least in the case of PLT Scheme, I recall a conference where there was open hostility to the notion that their academic language might (horrors!) become widely adopted.

Re: Go generics are not bad

#100
post #14

This is good to hear. There's something like a cognitive bias that makes me leary of genetics (in any language). Once you have some cross cutting feature, generics or object orientation, or in functional programming, those functions of type 'a->'a, or assembly language address modes, people get bogged down by trying to make everything in their work generic or object oriented or "orthogonal". Lemire's example is relev…

> What's this called? The blub paradox https://wiki.c2.com/?BlubParadox

I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.
Post reply on HN