Live data from Hacker News

Golang generics proposal has been accepted

github.com

11–20 of 176 posts

Re: Golang generics proposal has been accepted

#11
post #5

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

Will it requires a VM to run?

Also, how fast will this language build large projects?

Re: Golang generics proposal has been accepted

#12
post #8

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.

For me the desire to use generics shows up once I've invested some time in making fancy types. When I work in C that point is never reached since problems are solved "the C way".

Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.

Re: Golang generics proposal has been accepted

#13
post #8

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.

The equivalent to a void pointer in Go is interface{}. But very little of the C standard library uses void pointers--basically only those interfaces dealing with untyped blocks of memory, such as malloc and free. IME, you see interface{} far more often in Go code than you see void pointers in C code. And C actually has bone fide generics capabilities with _Generic, it's just very simple and manual.

Re: Golang generics proposal has been accepted

#14
post #5

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

Of course I'm joking, but I think implicit nullability is the worst part of Go. A language designed in a era when this was widely known as the billion dollar mistake (prolly even more expensive).

But this is not easily reversed. Not as easy as tagging generics onto the language. And the parallels with Java's maturing are just lovely. Also, we have seen what Kotlin is now doing for Java: a new language was needed to truly fix that one mistake (implicit nullability), introduced in the grandparent of Java (namely C), and the great old grand uncle of Go.

Re: Golang generics proposal has been accepted

#15

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

> C doesn't have them and is arguably the most successful language in history. I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason. > Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. Conversely, proponents of generics would argue that not having them creates complexity for software de…

Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the benefits of generics are outweighed by the cost of their complexity.

Re: Golang generics proposal has been accepted

#16
post #2

I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next…

> I wonder if over time, Golang will pick up more type features like Java and other languages have.

I hope it doesn't pick them up like Java did.

When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it.

When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java's broken local variable closure semantics]. Sun (Oracle? forget) again picked the worst of the two proposals. Now we're stuck with a real monstrosity.

Java has an amazing history of picking the wrong way to do things and permanently saddling developers with it.

Re: Golang generics proposal has been accepted

#17
post #5

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

Will it requires a VM to run? Also, how fast will this language build large projects?

It will be like Go: no VM. And have great interop with Go!

> Also, how fast will this language build large projects?

Slightly slower.

I wonder what the implementation of generics will do to Go's otherwise stellar compile times. A code base heavily using generics can easily be double the compile time. Not sure how this will be sold, probably "but then simply do not use it!"

Re: Golang generics proposal has been accepted

#20
post #5

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

A more apt comparison is TypeScript to JavaScript, perhaps. Kotlin and Java interop at the bytecode level, but Golang doesn't have that. Gotlin would have to compile to Golang with the same shimming hairiness as TS downleveling to JS.
Post reply on HN