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

Golang generics proposal has been accepted

github.com

Post reply on HN
Print view View original

111–120 of 176 posts

Re: Golang generics proposal has been accepted

#111

Post by rurban »

dcolkitt wrote: post #66

IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…

> high performance

I would not call 2x slower than C high performance. Decent performance, yes. But certainly not high.

It has easy to use concurrency, so it waits less than typical C code. This might lead to some high perf claims. But it is not

Re: Golang generics proposal has been accepted

#112

Post by wtetzner »

pjungwir wrote: post #87
zzbzq wrote: post #68

Earlier quoted context omitted.

Now that I've worked professionally in a whole bunch of languages that attempt to delete implicit nullability out of existence, I long for it's return. Option monads are a two billion dollar mistake. The fact is when you're working with any data coming from any other system, the data is or will become null, somehow, some way, and your program code which treats this as impossible is just literally wrong in a way that…

I've been experimenting with Rust's Rocket webapp framework, and as much as I like it, I agree it's very annoying how a struct can't permit nulls in one context but not another. I wish there were an easy solution that didn't require near-identical struct definitions and excess copying memory from one place to another.

Seems like a good opportunity for a custom derive.

Re: Golang generics proposal has been accepted

#113

Post by cies »

mssundaram wrote: post #77
cies wrote: post #30

Earlier quoted context omitted.

Well spotted. Though typescript does not fix some of the biggest horrors of JS. Interop is really good as one would expect.

I'd say it depends on how you tune your tsconfig and linting. You can really crank all the knobs avoid nearly all of the JS pitfalls

Agreed. But this is not very beginner friendly (sadly JS is more and more the first lang being taught), and is not an example of great design.

Re: Golang generics proposal has been accepted

#114

Post by sdfsfsf3kjdf »

baby wrote: post #41
cies wrote: post #14

Earlier quoted context omitted.

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

Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.

How exactly are you going to implement a type safe option type without generics? You either have to use interface{}, which is obviously not type safe, or write/generate an option type for every type contained within it. Sum types are a lot less useful if you don't have generics.

Re: Golang generics proposal has been accepted

#115

Post by cies »

erik_seaberg wrote: post #65
cies wrote: post #17

Earlier quoted context omitted.

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!"

I'm made out of meat, the compiler is always going to be millions of times faster than that. Are generics actually slower than codegen plus parsing the same method body over and over with different types?

> meat

Flesh to me. (vegan) :)

Re: Golang generics proposal has been accepted

#116

Post by mseepgood »

meddlepal wrote: post #57
hnlmorg wrote: post #28

Earlier quoted context omitted.

This isn’t a new proposal. Go’s maintainers have always been clear that they weren’t against generics per se but we’re against rushing into implementing something without giving sufficient time to consider the options. Personally I don’t think their time spent considering has resulting in anything better than if they had rushed into a solution (I’m not a fan of this proposal). But that’s just my personal opinion.

Yea basically they're implementing Java-lite generics. I'm not sure what they have been waiting for exactly...

Java generics do type erasure, this proposal does not. Java generics do not work on primitive types or with operators, this proposal does. Java generics require unbounded parser look-ahead by using , this proposal avoids it by using []. These are just from the top of my head, I'm pretty sure there are more differences.

Re: Golang generics proposal has been accepted

#117

Post by wtetzner »

coder543 wrote: post #105
cies wrote: post #104

Earlier quoted context omitted.

> I wish that Go would adopt Sum Types And then make a Maybe sum type? But then it is too late as the std lib communicates with nils instead of Maybes > The best way to know something won't be null is to use value types where possible. Don't return nilable values unless you have a good reason. I'm not doing this, I'm using an API that does! I cannot choose what some code returns, all I can do is --sigh-- add another…

> If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. But they're still explicit nulls. You seem to be saying that only implicit nulls require null guards, but that's just not what that means (as far as I have learned). You seem to hate nullability as a concept, which is fine, but that's different from hating implicit nullability. > That you find as much runtime p…

> But they're still explicit nulls.

Except that there may be other reasons to use pointers than just nullability. And in that case, there's no mechanism to specify whether or not the thing being pointed to is nullable.

I think that's where the implicitness in question comes in.

Re: Golang generics proposal has been accepted

#118

Post by sdfsfsf3kjdf »

pjungwir wrote: post #87
zzbzq wrote: post #68

Earlier quoted context omitted.

Now that I've worked professionally in a whole bunch of languages that attempt to delete implicit nullability out of existence, I long for it's return. Option monads are a two billion dollar mistake. The fact is when you're working with any data coming from any other system, the data is or will become null, somehow, some way, and your program code which treats this as impossible is just literally wrong in a way that…

I've been experimenting with Rust's Rocket webapp framework, and as much as I like it, I agree it's very annoying how a struct can't permit nulls in one context but not another. I wish there were an easy solution that didn't require near-identical struct definitions and excess copying memory from one place to another.

In Rust you can solve this via derive or a macro. Typescript's conditional types and the associated utility types are a nice solution to this problem as well. You can do a ton with Partial, Required, Pick, Omit, Exclude etc.

Re: Golang generics proposal has been accepted

#119

Post by skybrian »

hnlmorg wrote: post #28
lastofus wrote: post #18

Out of curiosity, what changed between now, and when proposals for generics came up in years past?

This isn’t a new proposal. Go’s maintainers have always been clear that they weren’t against generics per se but we’re against rushing into implementing something without giving sufficient time to consider the options. Personally I don’t think their time spent considering has resulting in anything better than if they had rushed into a solution (I’m not a fan of this proposal). But that’s just my personal opinion.

I'm not sure what you're comparing to, but there were previous proposals that were pretty different (and worse in my opinion), and there were changes along the way in the drafts that eventually turned into the accepted proposal.

Re: Golang generics proposal has been accepted

#120

Post by matheusmoreira »

CarelessExpert wrote: post #10
gautamcgoel wrote: post #4

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…

> I'm not sure "C didn't have it" is a good litmus test for determining the value of features

It can be a good test.

One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces.

Adding features to languages almost always increases the complexity of these binary interfaces. Eventually they become so complicated that nothing will ever interoperate with software written in these languages. The increased language complexity reduces the reusability of software produced in that language.

C++ had this problem and Rust is following in its footsteps. Rust libraries are really only reused within the Rust ecosystem. Those that are meant to be universally reusable will no doubt offer a simple ABI that lacks all the benefits of the Rust language.

Post reply on HN