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

101–110 of 176 posts

Re: Golang generics proposal has been accepted

#101

Post by AlphaSite »

Arnavion wrote: post #20
cies wrote: 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.

Considering that go is only really used in a statically compiled context, thats not really necessary.

Re: Golang generics proposal has been accepted

#102

Post by sdfsfsf3kjdf »

cies wrote: post #96
sdfsfsf3kjdf wrote: post #82

Earlier quoted context omitted.

> Well, I just come from a Elm gig and I must say I was not too bothered with the lack of generics there. Elm has generics.

Really? Why then there's List.map, Maybe.map, Array.map, and I have to select one of them? Is that not what generics would fix?

> Is that not what generics would fix?

No. That would be fixed by having something akin to typeclasses, traits or interfaces.

Elm's List, Maybe and Array are all defined using a generic type parameter.

Re: Golang generics proposal has been accepted

#103

Post by creata »

coder543 wrote: post #90
creata wrote: post #85

Earlier quoted context omitted.

I don't like your definition of "implicit nullability". Following that logic, Java integers can't be null either, and C has no implicit nullability! In practice, when we say we don't want implicit nullability, we mean that we want nonnullable everything , including pointers. After all, Tony Hoare called null references his billion dollar mistake.

That's not implicit nullability, in my opinion. I agree that non-nullable references are wonderful, and Go will probably have to grapple with that eventually. I just don't want people to get the wrong idea. Go has value types -- not everything is a reference that is implicitly nullable. C isn't implicitly nullable, you are correct.

I feel like we're just using different definitions of implicit nullability, and by your definition, no language with value types is implicitly nullable, whereas by my definition, every language without nullable references is implicitly nullable. I think your definition is bad and uncommon, but that's not a very fruitful line of discussion.

Re: Golang generics proposal has been accepted

#104

Post by cies »

coder543 wrote: post #70
cies wrote: post #61

Earlier quoted context omitted.

When i read Go code it is riddled with null guards. Any of those null guards may be removed, code compiles without additional warnings but now may blow up at runtime. Sorry, but to me that's a clear symptom of implicit nullability. Edit: clarification, to me it does not show in the type signature that something may return a null, also I do not have to unpack a possible null value (like with Maybe or Option).

You can't check for nil on something that isn't nilable -- it's a compile error to do so in Go. Your definition of "implicit nullability" is suspect here. Go doesn't even implicitly de-reference things, which is what I think you're intending to say that it does. (EDIT: field access does cause a dereference, as was pointed out in a response to this comment. I still think of this as an explicit action when you're speci…

> 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 null guard.

If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit.

That you find as much runtime problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go.

Re: Golang generics proposal has been accepted

#105

Post by coder543 »

cies wrote: post #104
coder543 wrote: post #70

Earlier quoted context omitted.

You can't check for nil on something that isn't nilable -- it's a compile error to do so in Go. Your definition of "implicit nullability" is suspect here. Go doesn't even implicitly de-reference things, which is what I think you're intending to say that it does. (EDIT: field access does cause a dereference, as was pointed out in a response to this comment. I still think of this as an explicit action when you're speci…

> 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 problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go.

It's also a comment on how NPEs are just not a common hazard in Go compared to my past experiences with Java, especially when combined with good editors and linters.

Re: Golang generics proposal has been accepted

#106

Post by hnlmorg »

geodel wrote: post #86
hnlmorg wrote: post #19

I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.

So you know languages which use angle bracket and now wish every other language should follow that. This seems more stuck-up that Go team's alleged opinion on not implementing generics.

Woooah steady in there with the conclusion jumping.

The reason I prefer angle brackets is just because I think it’s a little more readable. For me square brackets and parentheses look too similar in long function declarations. This might be a symptom of my dyslexia but the fact remains it’s a real readability issue for me.

I actually wouldn’t have minded if they used another visually distinct character either. Like the > characters that were also proposed (even though non-ascii characters have usability drawbacks when typing code).

Re: Golang generics proposal has been accepted

#107

Post by cies »

creata wrote: post #85
coder543 wrote: post #53

Earlier quoted context omitted.

> Of course I'm joking, but I think implicit nullability is the worst part of Go. Go doesn't have implicit nullability. You have to declare that something is a pointer for it to be nullable. There are a few kinds of pointers: "normal" pointers, slices, maps, function pointers, and interfaces. Any of those pointer types are nilable. Regular structs and primitives are not nilable. var x someStruct = nil //this will not…

I don't like your definition of "implicit nullability". Following that logic, Java integers can't be null either, and C has no implicit nullability! In practice, when we say we don't want implicit nullability, we mean that we want nonnullable everything , including pointers. After all, Tony Hoare called null references his billion dollar mistake.

If I return a struct pointer in C, I can also return null. The return type does not communicate this to me: this is what I call implicit nullability.

It is just a bad contract, as it is often misunderstood, and it allow for runtime errors that could easily have been caught at compile time.

Re: Golang generics proposal has been accepted

#108

Post by pkulak »

zzbzq wrote: post #68
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…

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…

> and your program code which treats this as impossible is just literally wrong

That's fine though. The program that treats it as possible but fails to handle it in every possible spot is wrong too, but wrong in a completely unpredictable place, way and even number of times.

It's freeing to start out assuming "title" can never be null. If it is, you get a quick failure at the very edge of your application where the data comes in. You make it nullable, and the compiler tells you all the places where you made the wrong assumption and now need a fix. Or even better yet, you give it a default value, even an empty string, and nothing more is required.

Re: Golang generics proposal has been accepted

#109

Post by coder543 »

creata wrote: post #103
coder543 wrote: post #90

Earlier quoted context omitted.

That's not implicit nullability, in my opinion. I agree that non-nullable references are wonderful, and Go will probably have to grapple with that eventually. I just don't want people to get the wrong idea. Go has value types -- not everything is a reference that is implicitly nullable. C isn't implicitly nullable, you are correct.

I feel like we're just using different definitions of implicit nullability, and by your definition, no language with value types is implicitly nullable, whereas by my definition, every language without nullable references is implicitly nullable. I think your definition is bad and uncommon, but that's not a very fruitful line of discussion.

You're referring to how some languages have non-nullable references, which is fine. That's probably a better term to be using, since it is more clearly defined and less contentious in this discussion.

I agree that Go should consider adopting non-nullable references.

Re: Golang generics proposal has been accepted

#110

Post by hnlmorg »

robocat wrote: post #62
kyrra wrote: post #26

Earlier quoted context omitted.

It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/des... a, b = w (z) Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?

Could they not make the space (or no space) part of the syntax after the I detest how syntactically overloaded our few ASCII symbols are, and using square brackets for templates seems wrong. Edit: Even better, use gofmt to convert each ASCII symbol into several unique Unicode symbols depending on usage, to show the semantic meaning. So [] as array is represented differently from [] as the template operator. Edit 2: I…

The > characters (sorry on phone so can’t post the actual Unicode characters) was proposed and, like yourself, the Go team decided it might put people off. But to be honest I actually would have been ok with it.
Post reply on HN