Out of curiosity, what changed between now, and when proposals for generics came up in years past?
[deleted]
Golang generics proposal has been accepted
51–60 of 176 posts
Re: Golang generics proposal has been accepted
#52[deleted]
Re: Golang generics proposal has been accepted
#53This 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 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 compile
var x int = nil //this also won't compileRe: Golang generics proposal has been accepted
#54Earlier 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.
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.
Re: Golang generics proposal has been accepted
#55I 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.
Scala uses square brackets. Never liked the look of angle brackets
Re: Golang generics proposal has been accepted
#56This 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…
PHP was also hugely successful, success is not the criterion by which this kind of feature should be decided. The bottom line is that generics allows the production of safer, more robust, more evolvable, more documented, more performant, code. Along with static typing, generics are simply a feature that no language created recently should be without.
A successful language requires less effort to solve your problem. That's why we create them, and it's strange how languages keep becoming popular without nailing this.
Re: Golang generics proposal has been accepted
#57Out 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.
Yea basically they're implementing Java-lite generics. I'm not sure what they have been waiting for exactly...
Re: Golang generics proposal has been accepted
#58Out of curiosity, what changed between now, and when proposals for generics came up in years past?
> Go was released on November 10, 2009. Less than 24 hours later we saw the first comment about generics.
- https://blog.golang.org/why-generics
But it's just taken that long to come up with a good design. Most of the work has been pushed forward by core team member Ian Lance Taylor who put forward the case in https://github.com/golang/proposal/blob/master/design/15292-...
This abstract proposal has been updated to link to a summary of concrete proposals at the footer, ""presented for historic reference. All are flawed in various ways""
Type functions (June 2010) - https://github.com/golang/proposal/blob/master/design/15292/...
Generalized types (March 2011) - https://github.com/golang/proposal/blob/master/design/15292/...
Generalized types (October 2013) - https://github.com/golang/proposal/blob/master/design/15292/...
Type parameters (December 2013) - https://github.com/golang/proposal/blob/master/design/15292/...
But it wasn't updated with implementation proposals after 2013, most notably
Contracts (2019) - https://github.com/golang/proposal/blob/master/design/go2dra...
Re: Golang generics proposal has been accepted
#59I really really hope that this does not end up in people abusing generics in Golang code and making Golang code harder to read. The biggest argument of Golang in my opinion is that it is extremely easy to audit and read and understand at the moment.
Anything that can be abused in a language will be abused.
Re: Golang generics proposal has been accepted
#60Earlier 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.
Sum and intersection types + pattern matching feels so natural in languages like F#, OCaml, Reason, and Elixir. I know they add a significant amount of complexity to the language, but the more I use them, the more I feel that the tradeoff lands in the goldilocks "just right" zone. I find myself missing them often.