Is generics akin to overloading functions?
Golang generics proposal has been accepted
131–140 of 176 posts
Re: Golang generics proposal has been accepted
#132IMO 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…
> Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. OCaml has always been known for having really fast compile times, and could be described as a "higher-typed language" I think. > And as for the topic of clear error messages, the higher-typed languages are all at…
[deleted]
Re: Golang generics proposal has been accepted
#133This 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…
>I bet the original team (in particular, I'm thinking of Rob Pike)
Apparently he's nervous but can think of useful applications of generics: https://old.reddit.com/r/golang/comments/jditu9/what_do_gene...
Robert Griesemer was a coauthor on the Featherweight Go paper so I'm assuming he supports it. I would assume Ken Thompson doesn't care for generics but I think he's retired so he wouldn't vote on it anyway.
Re: Golang generics proposal has been accepted
#134I 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.
When you get used to seeing it, the types mostly disappear from view until you look for it. I got to that level with Java, and Kotlin for the most part--never with Scala it always looked like line noise.
Re: Golang generics proposal has been accepted
#135IMO 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…
I think specific features make compile time very long. Nullable types + ADTs / sum types / 'enums' are not one of them, because they don't add exponentials to the compile time like type inference & operator overloading does for example.
Also adding nullables after the fact isn't very hard, other languages such as dart & objective-c have done it. The migration path isn't that hard either, since it is a completely new syntax that doesn't have to be a breaking change, so migrations can be gradual. Out of all the features that the new higher typed languages give, I think nullables are probably the best one out of them, and one of the cheapest for all the others to adopt. And while your adding nullables, you might as well add sum types because that is how you implement it anyway.
Re: Golang generics proposal has been accepted
#136Earlier 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?
There is a terminology issue here, with "generic" being overloaded to mean different things. Parametric polymorphism is what Go is adding. You'd like to see something like ad hoc polymorphism in Elm, like type-classes in Haskell. But neither of those should be confused with the datatype generic programming.
https://en.wikipedia.org/wiki/Parametric_polymorphism
Re: Golang generics proposal has been accepted
#137Earlier 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.
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.
It could have been built in to the language. Tons of builtin features (slices, maps, channels) are already "generic".
Re: Golang generics proposal has been accepted
#138Is generics akin to overloading functions?
no, overloading functions is called "ad hoc polymorphism", whereas generics is called "parametric polymorphism"
Re: Golang generics proposal has been accepted
#139Earlier 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…
> Just let it be null everywhere, and if it's null somewhere it shouldn't be, the program throws an error--like it should, because there's an error.
Optionals everywhere makes that explicit, vs. something implicit that you can forget.
Re: Golang generics proposal has been accepted
#140I 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…
Golang is google's backup to java if oracle didn't let them have java anymore, with some additional design goals for large companies like fast build times, better memory usage and something jr engineers can pickup without much trouble.
They both have garbage collection, they both perform about 3x slower than static C and they're both mostly used for network services, which is the same as Java at google.