Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

391–400 of 439 posts

Re: Proposal: Go should have generics

#391

Post by eva1984 »

twic wrote: post #369
eva1984 wrote: post #89

Earlier quoted context omitted.

Java itself is, IMHO, quite straightforward. But setup a java toolchain, building, deploying, and a lot of other configuration if some heavy framework is involved, is non-trivial. Gradle is like a must for modern Java application, and mastering itself takes some efforts. Go, when coming to toolchain, it is pretty much battery-included, best-practice-builtin, sometimes even a little forced. Language wise, Java recentl…

> Java [...] is still more LOC comparing to Go My experience is the exact opposite: Go takes more lines to do something than Java. I would say that in large part, this is because the error handling restricts expressions to a rather small size, and then because without streams, collection manipulation has to be written out longhand.

I agree with you on the error handling part, although it is not a big pain for me yet.

But in terms of parallel programming, when doing in Java, I constantly find myself basically building a lot of stuff where Go has as a part of its own semantic. Queues -> Channel, Executors -> M in Go, and Runnables -> Go functions. Java8's Lambada and ForkJoinPool is an advance in the right direction but still not quite there.

Re: Proposal: Go should have generics

#392

Post by kzhahou »

Came for a Proposal. This article only provides motivation for generics.

Are there any concrete proposals on the table? I don't recall seeing any, and it would be great to work from that and pick it apart. Otherwise, we're just arguing the opinion that they're useful, against the opinion that they'd soil the language.

Re: Proposal: Go should have generics

#393

Post by enneff »

kzhahou wrote: post #392

Came for a Proposal. This article only provides motivation for generics. Are there any concrete proposals on the table? I don't recall seeing any, and it would be great to work from that and pick it apart. Otherwise, we're just arguing the opinion that they're useful, against the opinion that they'd soil the language.

Yes, there are four at the bottom of the doc.

Re: Proposal: Go should have generics

#394

Post by enneff »

lucozade wrote: post #209
reycharles wrote: post #92

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…

I quite like the logical progression though: + People keep telling me we should be able to implement a map function in go. + I implemented a map function in go. + The map function was ugly, slow, unsafe and generally an abomination. Conclusion? You don't need a map function in go. You may not agree but you have to admire his dedication to the One True Way whatever is put in his way. Even if it's him that's erecting p…

> Conclusion? You don't need a map function in go.

I don't see Rob making that conclusion anywhere.

Re: Proposal: Go should have generics

#395

Post by kzhahou »

enneff wrote: post #393
kzhahou wrote: post #392

Came for a Proposal. This article only provides motivation for generics. Are there any concrete proposals on the table? I don't recall seeing any, and it would be great to work from that and pick it apart. Otherwise, we're just arguing the opinion that they're useful, against the opinion that they'd soil the language.

Yes, there are four at the bottom of the doc.

Wow, major props to him for having written four proposals!! Still, he says they're all flawed so far...

Re: Proposal: Go should have generics

#396

Post by eru »

loup-vaillant wrote: post #207
eru wrote: post #65

Earlier quoted context omitted.

Generics become complicated when you have other subtype relationships, don't they? (That's why SML, OCaml and Haskell don't really do inheritance, isn't it?)

If I have generics, first class functions, and garbage collection, frankly I don't care about sub-typing. http://loup-vaillant.fr/articles/classes-as-syntactic-sugar

I like Haskell, too. But we are talking about adding generics to Go as it is. Not about designing a good language from scratch.

Re: Proposal: Go should have generics

#397

Post by Ericson2314 »

ngrilly wrote: post #122
Ericson2314 wrote: post #95

Earlier quoted context omitted.

My point is that if Go was properly formalized as it should have been all along, this would be a lot easier. These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.

Does you critic applies to Rust as well which, as far as I know, is not formalized either? Are OCaml or Haskell propery formalized?

Unfortunately they aren't. But those are all worked on by people with academic (or equivalent) PL backgrounds whose hand-waving I trust much more. Also don't forget the existence of GHC's core, and Rust's Mir (OCaml I'd hope have a good well-defined core language). Basically, for human purposes, there is a spectrum of "quasi-formality" and Go is not winning.

Finally, get very excited for http://plv.mpi-sws.org/rustbelt/ .

Re: Proposal: Go should have generics

#398

Post by tacos »

Arzh wrote: post #373
nanny wrote: post #319

Earlier quoted context omitted.

>I will often use code generation since you only need to run that once and templating bloats the compile time for ever. Don't you need to compile the generated code?

Yes of course, but compiling the code is faster than generating the code and then compiling it. Templates are much slower than just compiling code straight.

With the exception of pathological metaprogramming examples -- and even those have largely been fixed -- there's no way you could even measure this, let alone justify such a strong, broad opinion. You're using incomplete information to justify sloppy engineering and promoting it to others.

Re: Proposal: Go should have generics

#399

Post by narrowrail »

pjmlp wrote: post #388
narrowrail wrote: post #268

Earlier quoted context omitted.

Your theory fails to account for the lack of success with respect to Dart; so, it seems more like something you have an urge to believe (despite a lack of evidence).

Dart has been abandoned by Google the day that Angular team has chosen Typescript instead of believing in Dart, thus sending to the world the message that the company doesn't believe in it. Whereas there are a few production examples of Go at Google.

My understanding is that Dart is used by Google Fiber for their routers, so I wouldn't call that abandoned yet. But, the point is that Google supporting a language does not seem to imply its eventual success.

Re: Proposal: Go should have generics

#400

Post by atombender »

sythe2o0 wrote: post #302
nostrademons wrote: post #264

Earlier quoted context omitted.

It means that every single type in the language has one extra value it may contain, 'nil', and your code will crash or behave erratically if it contains this value and you haven't written code to handle it. This has caused billions of dollars in software errors (null dereferences in C/C++, NullPointerExceptions in Java, etc.). See "Null References: The Billion Dollar Mistake" by Tony Hoare, the guy who invented it: h…

nil in Go doesn't work that way. Most types cannot be nil.

But a bunch types you do expect to work can: Slices, maps and channels.

  var m map[string]bool
  m["foo"] = 1  // Nil, panic

  var a []string
  a[0] = "x"  // Nil, panic

  var c chan int
This violates the principle of least surprise. Go has a nicely defined concept of "zero value" (for example, ints are 0 and strings are empty) until you get to these.

The most surprising nil wart, however, is this ugly monster:

    package main

    import "log"

    type Foo interface {
    	Bar()
    }
    type Baz struct{}

    func (b Baz) Bar() {}

    func main() {
    	var a *Baz = nil
    	var b Foo = a
    	fmt.Print(b == nil)  // Prints false!
    }
This happens is because interfaces are indirections. They are implemented as a pointer to a struct containing a type and a pointer to the real value. The interface value can be nil, but so can the internal pointer. They are different things.

I think supporting nils today is unforgivable, but the last one is just mind-boggling. There's no excuse.

Post reply on HN