Proposal: Go should have generics • Hacker News Board

Re: Proposal: Go should have generics

#431

Post by aninhumer » Sun, Apr 17, 2016, 3:05 AM UTC

sythe2o0 wrote: post #411

atombender wrote: post #400

Earlier quoted context omitted.

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 imp…

I don't think using nil to represent uninitialized data is a major issue-- if it were possible to catch uninitialized but queried variables at compile-time, that could be an improvement, but we want to give the programmer control to declare and initialize variables separately. I agree the second case is a little silly.

It's perfectly possible to separate declaration and initialisation without using a null value.

Re: Proposal: Go should have generics

#432

Post by pjmlp » Sun, Apr 17, 2016, 6:29 AM UTC

spankalee wrote: post #413

pjmlp wrote: post #388

Earlier quoted context omitted.

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.

That's some odd reasoning. The Angular team does not decide which languages are invested in by Google.

No, but Google decides what their employees are allowed to use.

In this case a company team was allowed to use a competing language instead of the one designed in-house for the same purpose.

Re: Proposal: Go should have generics

#433

Post by sacado2 » Sun, Apr 17, 2016, 11:12 AM UTC

aninhumer wrote: post #430

sacado2 wrote: post #427

Earlier quoted context omitted.

> $1bn over the history of computing is about $2k per hour. I would not be astonished if a class of bugs cost that much across the industry. It's not about knowing whether it's $1bn, or 10bn, or just a few millions. The question is to know whether fighting so hard to make these bugs (the "caught at runtime" version, not the "undefined consequences" version) impossible is worth the cost or not. Can you guarantee that…

>fighting so hard to make these bugs ... impossible is worth the cost or not. In this case the solution is trivial, just don't include null when you design the language. It's so easy in fact, that the only reason I can imagine Go has null, is because its designers weren't aware of the problem.

Not including null has consequences, you can't just keep your language as it is, remove null and say you're done.

What's the default value for a pointer in the absence of null? You can force the developer to assign a value to each and every pointer at the moment they are declared, rather than rely on a default value (and the same thing for every composite type containing a pointer), but then you must include some sort of ternary operator when initialization depends on some condition, but then you cannot be sure your ternary operator won't be abused, etc.

You can also go the Haskell way, and have a `None` value but force the user to be in a branch where you know for sure your pointer is not null/None before dereferencing it (via pattern matching or not). But then again you end up with a very different language, which will not necessarily be a better fit to the problem you are trying to solve (fast compile times, easy to make new programmers productive, etc.).

Re: Proposal: Go should have generics

#434

Post by sacado2 » Sun, Apr 17, 2016, 11:28 AM UTC

tome wrote: post #428

sacado2 wrote: post #427

Earlier quoted context omitted.

> $1bn over the history of computing is about $2k per hour. I would not be astonished if a class of bugs cost that much across the industry. It's not about knowing whether it's $1bn, or 10bn, or just a few millions. The question is to know whether fighting so hard to make these bugs (the "caught at runtime" version, not the "undefined consequences" version) impossible is worth the cost or not. Can you guarantee that…

Why do you think it costs very much to provent null pointer exceptions?

I think it has consequences on the design of the language, making it more complex and more prone to "clever" code, i.e code harder to understand when you haven't written it yourself (or you wrote it a rather long time ago). I've experienced it myself, I spent much more time in my life trying to understand complex code (complex in the way it is written) than to correct trivial NPEs.

That being aside, it is less easy to find developers proficient in a more complex language, and it is more expensive to hire a good developer and let him time to teach himself that language.

I'm not sure it costs "very much", though. I might be wrong. But that's the point: nobody knows for sure. I just think we all lack evidence about those points, although PL theory says avoiding NULL is better, there have been no studies to actually prove it in the "real-world" context. Start-ups using Haskell/OCaml/F#/Rust and the like don't seem to have an undisputable competitive advantage over the ones using "nullable" languages, for instance, or else the latter would simply not exist.

Re: Proposal: Go should have generics

#435

Post by zzzcpan » Sun, Apr 17, 2016, 12:28 PM UTC

sacado2 wrote: post #433

aninhumer wrote: post #430

Earlier quoted context omitted.

>fighting so hard to make these bugs ... impossible is worth the cost or not. In this case the solution is trivial, just don't include null when you design the language. It's so easy in fact, that the only reason I can imagine Go has null, is because its designers weren't aware of the problem.

Not including null has consequences, you can't just keep your language as it is, remove null and say you're done. What's the default value for a pointer in the absence of null? You can force the developer to assign a value to each and every pointer at the moment they are declared, rather than rely on a default value (and the same thing for every composite type containing a pointer), but then you must include some sor…

But null pointers are not really a problem in Go, aren't they? The problem only exists in lower level languages.

Go, as a language, is a pretty good one. It's Go's standard library that's not, especially "net" and other packages involving I/O.

Re: Proposal: Go should have generics

#436

Post by zimbatm » Sun, Apr 17, 2016, 2:54 PM UTC

d4rkph1b3r wrote: post #380

zimbatm wrote: post #364

Earlier quoted context omitted.

Generics introduce more complexity in the type system which in turn makes the compiler slower. Generics introduce more complexity for the reader of the code because it's another abstraction to understand. It's debatable but when your brain is thinking about generics or context-switching because it has to wait on the compiler to finish, it's less time making progress on the actual thing that needs to be done.

The whole point of abstractions is that you don't have to worry about as much. Generics take away complexity, that's the whole point.

I suppose it depends on the level of understanding that you want from your code. Generics introduce another dimension which you have to think about when you want a good level of control on allocations for example. Different data types also have different optimizations available which could be missed when blindly relying on the generic algorithm (think sorting on a fixed set for example)

Re: Proposal: Go should have generics

#437

Post by JanKanis » Mon, Apr 18, 2016, 12:20 PM UTC

atombender wrote: post #400

sythe2o0 wrote: post #302

Earlier quoted context omitted.

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 imp…

I don't think you're right that interfaces are implemented as a pointer to a struct. The struct is inline like any other struct, and it contains a pointer to a type and a pointer to the value, like `([*Baz], nil)` in your example. The problem is that a nil interface in Go is compiled to `(nil, nil)` which is different.

That still makes this inexcusable of course.

Re: Proposal: Go should have generics

#438

Post by lobster_johnson » Mon, Apr 18, 2016, 2:45 PM UTC

JanKanis wrote: post #437

atombender wrote: post #400

Earlier quoted context omitted.

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 imp…

I don't think you're right that interfaces are implemented as a pointer to a struct. The struct is inline like any other struct, and it contains a pointer to a type and a pointer to the value, like `([*Baz], nil)` in your example. The problem is that a nil interface in Go is compiled to `(nil, nil)` which is different. That still makes this inexcusable of course.

You're right, it was lurking in the back of my mind that it must be on the stack entirely.

Re: Proposal: Go should have generics

#439

Post by infogulch » Mon, Apr 18, 2016, 10:11 PM UTC

NateDad wrote: post #361

pklausler wrote: post #354

Earlier quoted context omitted.

Sorting on all three fields in priority order is what I had in mind, and that's trivial in Haskell by adding "deriving(Ord)" to the data type definition and then just using the standard "sort :: Ord a => [a] -> [a]". If you're always going to sort them based on some (other) relation between the fields, make your type a custom instance of Ord, e.g. "instance Ord Machine where compare = compare `on` name". To sort the…

So... you will still need 57 spots in the code where you define how to sort a type. Maybe my reference to sort.Interface is confusing people. When I say we have 57 implementations of sort.Interface, that's 57 different types and/or different ways of sorting one of those types. So, like, sorting Machine by Name would be one implementation, sorting Machine by Name then OS then RAM would be another implementation. You w…

It's possible to make one implementation for a type that supports multiple orderings, at the cost of another indirection [0]. This turns O(N*M) implementations for N types and M sorting orders into just O(N). (I'm not counting an inline anonymous function as a new implementation.)

In practice, it's rare to need to sort a slice more than one way.

[0]: https://gist.github.com/infogulch/5db15e5ae5cf073f1088033ba4...