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

Generics aren't ready for Go

drewdevault.com

Post reply on HN
Print view View original

151–160 of 238 posts

Re: Generics aren't ready for Go

#151

Post by latronic_notron »

weberc2 wrote: post #145
latronic_notron wrote: post #120

Earlier quoted context omitted.

> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. interface{} does feel like a temporary and clunky solution for people used…

> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... > As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. > interface{} does feel like a temporary and clunky solution for people used to generics. It's not a strawman; I run into this tir…

I personally find most implementations of generics to be in the class of "boring and predictable".

I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple.

IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code generation. I mean, the complexity is already there... why wouldn't generics simplify those use cases?

Re: Generics aren't ready for Go

#152

Post by jstimpfle »

latronic_notron wrote: post #138
j16sdiz wrote: post #133

Earlier quoted context omitted.

Go use a duck typing system, many of the generic use case can be solved using interface elegantly.. For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so.... Luckily, go is very simple. Even ugly bit are not hard to understand.

> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.

> Arrays/Maps/Slices

They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.

Re: Generics aren't ready for Go

#153

Post by latronic_notron »

jstimpfle wrote: post #150
latronic_notron wrote: post #136

Earlier quoted context omitted.

> Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety... > Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree for types K and V"?…

> Except when it isn't. Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming). > That's uncalled for, isn't it? There's a lot of non-toy problems...…

> Yes, but by far more important are bounds checks.

Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.

Re: Generics aren't ready for Go

#154

Post by jstimpfle »

latronic_notron wrote: post #153
jstimpfle wrote: post #150

Earlier quoted context omitted.

> Except when it isn't. Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming). > That's uncalled for, isn't it? There's a lot of non-toy problems...…

> Yes, but by far more important are bounds checks. Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.

Many things are important, and most things require making tradeoffs. When a thing that is only a little bit important prevents something else that is more important (albeit more subtle and requiring experience to see), it's probably better not to choose the first thing.

Generics are abstract. They lead to bad error messages. They make the language more complex. They require syntactical support as well as special magic under the hood. Look for various resources by Russ Cox and Rob Pike (and maybe other Go designers). For example https://go.googlesource.com/proposal/+/master/design/go2draf...

Re: Generics aren't ready for Go

#155

Post by nicoburns »

weberc2 wrote: post #114
alexandercrohde wrote: post #64

Earlier quoted context omitted.

I'm not super educated on this, but the example I'm asking is "How would you port the library lodash to your language without generics?"

"Porting lodash" isn't an end unto itself, but you can use `interface{}` everywhere and have the same degree of type safety that lodash enjoys, which is to say zero.

You can also use lodash with TypeScript, and get a great deal more safety than that...

Re: Generics aren't ready for Go

#156

Post by bunderbunder »

overcyn wrote: post #144
bunderbunder wrote: post #134

Earlier quoted context omitted.

So, we would seem to have two key statements being pitted against each other here: 1. Rob Pike doesn't have a strong grasp of type theory. 2. Rob Pike is an accomplished programmer. To me, this conflict of opinions is structurally indistinguishable from 1. That shape over there is a square. 2. That shape over there is blue. IOW, there is no argument to see here.

No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

Yeah, the second statement is also valid, though definitely not what I got from the parent's comment.

Though, in that case, I think the argument is more like:

  1. That shape is equilateral
  2. That shape is equiangular
It turns out it's a square. Rob Pike's public comments on the subject do seem to betray a weak grasp of actual type theory. Or at least one that is about as strong as it could ever get if your knowledge is primarily informed by practical experience with C++ or Java-style deeply broken type systems. But it's also true that Go's found an alternative approach that gets the job done. Or at least, gets the job done if you're writing the types of programs that he's writing.

So, even with the alternative statement, I still see no argument here.

Re: Generics aren't ready for Go

#157

Post by jstimpfle »

apta wrote: post #131
jstimpfle wrote: post #11

Earlier quoted context omitted.

You're implying that there is a better design that has generics and caters to the same programmer folks. But you don't show what that design is. The OP didn't imply there was one.

D, Rust, C#, ML, Delphi, etc.

I haven't used all the other ones, but "Delphi" really made me crack up. I used it for 6 months before I quit my job. It's a mess, junk after junk added on a pile of junk, only surpassing the junk-adding badness of C++ by also having this broken standard library that's somehow required to write any type of software (because the simplest thing, C-like pointers, exist but are really not nice to work with).

The task that lead to my decision to quit was to write a data serialization systems for datastructure that I didn't know in which version of junk they were expressed, by interfacing with the broken standard library. The serialization system was to replace another serialization system that somehow didn't quite work. No wonder, it was broken code, and I couldn't see a way to write non-broken code to solve an unsolveable problem.

What's nice about Delphi is that the compiler is quick and it has a beginner-friendly IDE with a visual GUI creator (no selling point for me). That's about it, AFAICT.

Re: Generics aren't ready for Go

#158

Post by weberc2 »

latronic_notron wrote: post #151
weberc2 wrote: post #145

Earlier quoted context omitted.

> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... > As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. > interface{} does feel like a temporary and clunky solution for people used to generics. It's not a strawman; I run into this tir…

I personally find most implementations of generics to be in the class of "boring and predictable". I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple. IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code gen…

I'm talking about code written in Go, not the implementation of any particular feature. Generics would simplify those cases, but they also remove the rails that keeps Go code pretty consistent relative to Java or C#.

For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experimenting with new patterns and paradigms); however, I also appreciate that there are languages like Go that take a more conservative opinion, and I think this is more practical for software development.

Re: Generics aren't ready for Go

#159

Post by [deleted] »

bunderbunder wrote: post #156
overcyn wrote: post #144

Earlier quoted context omitted.

No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

Yeah, the second statement is also valid, though definitely not what I got from the parent's comment. Though, in that case, I think the argument is more like: 1. That shape is equilateral 2. That shape is equiangular It turns out it's a square. Rob Pike's public comments on the subject do seem to betray a weak grasp of actual type theory. Or at least one that is about as strong as it could ever get if your knowledge…

[deleted]

Re: Generics aren't ready for Go

#160

Post by weberc2 »

nicoburns wrote: post #155
weberc2 wrote: post #114

Earlier quoted context omitted.

"Porting lodash" isn't an end unto itself, but you can use `interface{}` everywhere and have the same degree of type safety that lodash enjoys, which is to say zero.

You can also use lodash with TypeScript, and get a great deal more safety than that...

Granted, but "lodash" is still a means and not an end.
Post reply on HN