Go is supposed to be a better C, not a better C++.
Why couldn't a better C have generics?
Proposal: Go should have generics
421–430 of 439 posts
Re: Proposal: Go should have generics
#422Earlier quoted context omitted.
What's wrong with nil? Just legitimately curious, and I've never used Go at all.
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…
Beside the fact you're wrong (structs, arrays, bools, numeric values, strings and functions can't be nil, for instance), I'm always a little puzzled when I read the argument that "nil costs billions of $".
First, most of the expensive bugs in C/C++ programs are caused by undefined behaviors, making your program run innocently (or not, it's just a question of luck) when you dereference NULL or try to access a freed object or the nth+1 element of an array. "Crashing" and "running erratically" are far from being the same. If those bugs were caught up-front (just like Java or Go do), the cost would be much less. The Morris worm wouldn't have existed with bound-checking, for instance.
Second point, since we're about bound checking. Why is nil such an abomination but trying to access the first element of an empty list is not? Why does Haskell let me write `head []` (and fail at runtime) ? How is that different from a nil dereference exception ? People never complain about this, although in practice I'm pretty sure off-by-one errors are much more frequent than nil derefs (well, at least, in my code, they are).
Re: Proposal: Go should have generics
#423Earlier quoted context omitted.
> On the other hand, when you study PL theory, you learn very quickly about Hindley-Milner type inference and System-F. Apparently they haven't. Again you assume that, since they didn't include it, they must not have known about it. You keep claiming that. Given the breadth of these guys' knowledge (it's not just Java, C#, and C++, not by a long shot), I really struggle to see any justification for you assuming that.…
> Again you assume that, since they didn't include it, they must not have known about it. That's not why I assumed ignorance. I assumed ignorance because their stated reasons for doing so are false. Generics can be simple. They skipped them "for simplicity's sake". Therefore they didn't know generics could be simple. Besides, generics could have probably helped them simplify other parts of the language. (But I'm gett…
> Therefore they didn't know generics could be simple.
I wouldn't call Hindley-Milner type inference simple, though. I think you underestimate what has to be available in the language for a ML-like parametric polymorphism to be implemented in the language. For instance, can an interface be generic? Can a non-generic type implement a generic interface? How do you say your type is generic, but "only numeric types allowed" ? Does it mean the language must implement a type hierarchy of some kind ? How well does it play with pointers? Is `*int` a numeric type?
Once you introduce generics, you have no choice but to make a more complex language overall. You say generics would have simplified the language, I find it hard to believe. Care to mention a language that is easier to grasp than go (i.e I can be productive in less than a week) and that also offers efficient generics?
Re: Proposal: Go should have generics
#424Earlier quoted context omitted.
It's like you assume that, since they didn't do it your way, they're either stupid, ignorant, or malicious - which I also find to be pretty inexcusable.
I'd like to give them the benefit of the doubt, but even within their stated goal of "simplicity", some of their design choices still seem ignorant of PL theory. The obvious one being including a null value, which is widely recognised to be a terrible idea with pretty much no redeeming qualities. Another subtler example is the use of multiple return values for error handling, rather than some kind of sum type. It jus…
Sum types don't fit well with zero values. What is the zero value of an `(int|string)` union type ?
Re: Proposal: Go should have generics
#425Let me give a concrete example of how I've been personally impacted by the lack of generics. My project makes liberal use of pointers to represent "optional" fields, since they need to be distinguished from the zero-type. Alternatives would be to have a boolean associated with every field, but that clutters the API and still faces a lot of the problems with using pointrs, such as: - Easy to forget to check that point…
type Optional struct {
stuff interface{}
present bool
}
func (o Optional) Get() (interface{}, bool) {
return o.stuff, o.present
}
func NewOptional(stuff interface{}) {
return Optional(stuff, true)
}Re: Proposal: Go should have generics
#426Earlier 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…
Beside the fact you're wrong (structs, arrays, bools, numeric values, strings and functions can't be nil, for instance), I'm always a little puzzled when I read the argument that "nil costs billions of $". First, most of the expensive bugs in C/C++ programs are caused by undefined behaviors, making your program run innocently (or not, it's just a question of luck) when you dereference NULL or try to access a freed ob…
> I'm always a little puzzled when I read the argument that "nil costs billions of $".
$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.
> most of the expensive bugs in C/C++ programs are caused by undefined behaviors
Sure, there are worse bugs. Why, then, waste our time tracking down trivial ones?
> Why does Haskell let me write `head []` (and fail at runtime) ?
Because the Prelude is poorly designed.
> How is that different from a nil dereference exception ?
It's not different, really. It's a very bad idea.
> People never complain about this
Yes we do. We complain about it all the time. It is, however, mitigateable by a library[1] (at least partially), whereas nil is not.
[1] http://haddock.stackage.org/lts-5.4/safe-0.3.9/Safe.html#v:h...
Re: Proposal: Go should have generics
#427Earlier quoted context omitted.
Beside the fact you're wrong (structs, arrays, bools, numeric values, strings and functions can't be nil, for instance), I'm always a little puzzled when I read the argument that "nil costs billions of $". First, most of the expensive bugs in C/C++ programs are caused by undefined behaviors, making your program run innocently (or not, it's just a question of luck) when you dereference NULL or try to access a freed ob…
> I'm always a little puzzled when I read the argument that "nil costs billions of $". $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. > most of the expensive bugs in C/C++ programs are caused by undefined behaviors Sure, there are worse bugs. Why, then, waste our time tracking down trivial ones? > Why does Haskell let me write…
> $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 hiring a team of experienced Haskell developers (or pick any strongly-typed language of your choice) will cost me less than hiring a team of experienced Go developers (all costs included, i.e from development and maintenance cost to loss of business after a catastrophic bug)? Can you even give me an exemple of a business that lost tons of money because of some kind of NullPointerException ?
Re: Proposal: Go should have generics
#428Earlier quoted context omitted.
> I'm always a little puzzled when I read the argument that "nil costs billions of $". $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. > most of the expensive bugs in C/C++ programs are caused by undefined behaviors Sure, there are worse bugs. Why, then, waste our time tracking down trivial ones? > Why does Haskell let me write…
> $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?
Re: Proposal: Go should have generics
#429Earlier quoted context omitted.
I'd like to give them the benefit of the doubt, but even within their stated goal of "simplicity", some of their design choices still seem ignorant of PL theory. The obvious one being including a null value, which is widely recognised to be a terrible idea with pretty much no redeeming qualities. Another subtler example is the use of multiple return values for error handling, rather than some kind of sum type. It jus…
Sum types don't fit well with zero values. What is the zero value of an `(int|string)` union type ?
Well I don't think zero values are a very good idea to start with (if you want a default value, make it explicit), but if one insists on having them, they can just use the first case. So for your example it would be int 0.
Re: Proposal: Go should have generics
#430Earlier quoted context omitted.
> I'm always a little puzzled when I read the argument that "nil costs billions of $". $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. > most of the expensive bugs in C/C++ programs are caused by undefined behaviors Sure, there are worse bugs. Why, then, waste our time tracking down trivial ones? > Why does Haskell let me write…
> $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.