[deleted]
Golang generics proposal has been accepted
81–90 of 176 posts
Re: Golang generics proposal has been accepted
#82Earlier quoted context omitted.
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
Yes. But null-safety is absolute on the top (as it is soooo hard, maybe even impossible, to add later). Generics... Well, I just come from a Elm gig (knowing Haskell/C++/Java/Kotlin/Ruby) and I must say I was not too bothered with the lack of generics there.
> 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.
Re: Golang generics proposal has been accepted
#83Earlier 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…
> Actually, javascript is the only language that has it right. Not only can anything be null, anything can be undefined
I think they are very similar in that there are now 2 nully things to guard for.
Option types suck in Java as they were tagged on later. Maybe in Haskell, or even nicer, Maybe in Elm is were the party's at. It is build in at the center of the language. And getting a value (v) from a list by an index should give you a "Maybe v", as you could be out of bounds. That's the strong typing that basically keeps me safe when viciously attacking a code base I have not touched for some time (or is not written by me to begin with).
Re: Golang generics proposal has been accepted
#84Earlier 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…
I don’t see how any of the points you made is a great defense of keeping nulls around.
> 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 is complete jibberish.
Your program and the other program has to agree on some protocol. That can have optionality built into it if you expect them to not send certain fields. If that protocol is violated then either you made a mistake (protocol was not accurate) or they did (sent poorly formatted data); either way, you can handle the error without nulls.
> however this model makes it impossible to treat a value as Optional at an early part of the callstack and Non-optional later in the callstack after it's been checked and verified.
I think what’s being described here could be easily encoded as variants/sum types, or you could have functions that give optional fields default values. Without a specific example it’s hard to discuss what you’re really trying to say.
Re: Golang generics proposal has been accepted
#85Earlier 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…
> 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.
Re: Golang generics proposal has been accepted
#86I 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.
Re: Golang generics proposal has been accepted
#87Earlier 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…
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.
Re: Golang generics proposal has been accepted
#88Earlier 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…
Putting your rhetoric aside, you're mostly right. As someone that maintained an old Java project, a NPE was the most common type of issue that I had to deal with. The code was riddled with them and business logic often broke leaving me to deal with lots of support tickets. That being said, implicit nullability leads to mostly human type of errors and comes from our limitation to fit all the parts of a complex system…
Plenty of the example you request exist. Here two of m:
Well Haskell compiles to binary, or Elm compiles to JS. The resulting binary/JS is basically machine written and does not throw any NPE's.
Re: Golang generics proposal has been accepted
#89This 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…
C11 added _Generic as a way to write generic functions, for data structures people use the preprocessor to code-gen instantiations of generic code.
Rob Pike has nothing against generics and never expressed criticism of them. His concern was always fairly practical; among the numerous forms of generics that exist among different languages, and the significant variation and rapid evolution of them, how can such a feature be safely added to the language?
Re: Golang generics proposal has been accepted
#90Earlier 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.
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.