Live data from Hacker News

Proposal: Go should have generics

github.com

161–170 of 439 posts

Re: Proposal: Go should have generics

#161

Earlier quoted context omitted.

> you get the language simplicity I remember the Go language specification to be about as long as the table of contents for the Java language specification. On the other hand, Brainfuck is an extremely simple language, too.

> I remember the Go language specification to be about as long as the table of contents for the Java language specification. I'm not sure where you got that from. On my browser and screen, the JLS8 TOC[0] is 16 pages high which brings me about 20% into the Go language spec[1]. But then again that's a completely inane appeal to emotions: because it's a specification for cross-platform and cross-implementation compatib…

You are absolutely right, it's a silly comparison. The Go language spec is indeed vague.

I did this comparison a while ago. It wasn't very accurate. The Go spec has probably changed. Unfortunately, it seems they don't keep older specs around(!) If I adjust the font size in the ToC of the JLS I get 23 pages and the Go Spec is 84 pages (27%). Not quite "about the same length", still.

I took a compiler course in university where we implemented a compiler for a subset of java 1.3 (I believe), and the next year I was a TA in the compiler course. I got to read the (older) JLS quite a lot. I do find Java to be a more complicated language than Go. This does not mean I find it simpler to write programs in Go (c.f. Brainfuck).

Re: Proposal: Go should have generics

#163
If it was up to me I would break with ASCII for the syntax. It would make parsing easier for the compiler while simultaneously making it slightly annoying to use for the programmer.

Having to reach for a complex key combination would be enough to remind everyone that Generics should be used sparingly.

Re: Proposal: Go should have generics

#164

As long as programmers that are comfortable with (and prefer) 30+/40+ year old PL paradigms are at the helm of Go's design, it's not very likely the language will grow Generics. To paraphrase Max Plank: "A new language-level feature does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."

Only Max Planck was talking about questions of truth.

> To paraphrase Max Plank

Re: Proposal: Go should have generics

#165
post #125

Earlier quoted context omitted.

Rob Pike's repository 'filter'[0] contains implementations of map ("Apply"), filter ("Choose", I believe), and fold/reduce ("Reduce"). The code is an ugly mess, and the implementation shows that he probably hasn't used any of these standard functions in other languages (see the weird permutations of 'filter' in apply.go, or my patch for his fold/reduce implementation[1]). The README is also quite arrogant, IMO. > I w…

This is what people mean when they say that Go has disregarded everything we learned in the programming language community in the last decades. Sure, some people are productive in it and that's fine - but for those of us who have worked in better languages taking the step down is unattractive.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

Re: Proposal: Go should have generics

#166
post #117
post #107

Maybe instead of adding generics to Go it's time to look into alternative programming languages which already implement generics, like for example Nim.

You forgot that most of golangers are ex-php programmers and students with no experience. Just look at what they're talking about: they think generics are the opposite of simplicity and can make performance and compilation time worse. Meanwhile, Nim has generics with other useful features and has faster compilation time along with better optimization. If google would put 'goto' into go golangers would still use it an…

Go does have 'goto'.

https://golang.org/ref/spec#Goto_statements

Re: Proposal: Go should have generics

#168
post #12
post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

I think Go people have a very strange definition for simplicity, much like the population at large actually, but that's a shame really.

Simple means composed of a single element, not compound, unentangled, being the opposite of "complex", which of course means consisting of many different and connected parts. Instead Go people prefer the term to mean the now more popular meaning, which is "easy to understand, familiar".

I think a parallel can be drawn with another word from the English language: "free". You see, English doesn't have a word for the latin "liber" (libre, at liberty), like other romance languages have and I can name at least Italian, Spanish, French and Romanian (my own tongue). In these romance languages there's a firm distinction between libre and gratis, whereas in English there's no adjective signifying liberty without also meaning "at no monetary cost". I find that to be interesting and I bet it happened most probably because at some point in time these 2 issues were correlated.

Back to simplicity, while you can often correlate simplicity with easiness, mixing the terms is unjust because sometimes simple things aren't easy at all and sometimes easy things aren't simple at all (much like how sometimes gratis things are restricted and liberties aren't gratis). Speaking of which in my own native tongue the word for "easy" is also used to signify weightlessness (light, soft). Makes sense in a way, but you can see how language works.

And it would be a shame to lose the true meaning of "simple", just because its usage is at hand when trying to describe things that are or are not desirable. As in the end, this is how the meaning of words gets diluted and lost: because of our constant desire to make other people believe our ideas and buy our shit. So we exaggerate. Just a little, after all, we are only going to end up with a language that's ambiguous. What does it matter if "open source" has had a clear definition since OSI and that it wasn't in use before that, it's marketable dammit, so lets use it for all shit that has source-code available. Etc, etc.

And I get it, saying that generics aren't easy isn't so appealing, because that would be an acknowledgement of one's own capabilities and knowledge, being a metric relative to the one who's speaking. Whereas simple is an objective metric, with things being simple or complex irregardless of the person that's passing judgement. Still, generics are only as complex as static type systems. When you have a statically typed language, generics are a natural consequence. And if you don't add generics, then you need to add an "Object", "Any", "dynamic" or whatever you want to call it, which would be a whole in that static type system, not to mention introducing special cases (like the builtin arrays and maps) and that's complex by definition. Java did as well, introducing generics at version 5, when it was too late to do it cleanly and the result isn't nice at all ;-)

Re: Proposal: Go should have generics

#169
post #126

Earlier quoted context omitted.

What things? Care to elaborate?

interfaces

Look at Nim's concept(http://nim-lang.org/docs/manual.html#generics-concepts), it can do more than a regular interface.

Edit: here is how they look like, concept vs interface:

1. Nim: http://ideone.com/wn3Kzf 2. Go: http://ideone.com/fRrB05

Re: Proposal: Go should have generics

#170
post #149

Earlier quoted context omitted.

Or just use a language that supports generics instead?

The first company to make a fork of Go that runs on the JVM and has compiler-specific extensions will make a ton of money, IMO.

This will only target a very small group of developers, who are comfortable with JVM, but not with Java or Scala. I don't see any money there.

JVM is a major drawback for any language. Many people don't even look at JVM languages.

Post reply on HN