4 ms·
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
by baby 6y ago
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
- cies 6y agoYes. 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.
- jasperry 6y agoWait, doesn't Elm have parametric polymorphism like other ML-family languages? That's just as powerful as most languages' generics, and with a lot fewer brackets.
- sdfsfsf3kjdf 6y ago> 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.
- cies 6y agoReally? 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?
- sdfsfsf3kjdf 6y ago> 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.
- floxy 6y agoThere 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 https://en.wikipedia.org/wiki/Parametric_polymorphism https://en.wikipedia.org/wiki/Ad_hoc_polymorphism https://en.wikipedia.org/wiki/Ad_hoc_polymorphism https://wiki.haskell.org/Generics https://wiki.haskell.org/Generics
- shakow 6y agoNo, it fixes that you don't have to chose between ListOfInts, ListOfStrings and ListOfListOfArrayOfInt. BTW, one doesn't have to chose between them in Go either, but only because there are under-the-hood generics for the native types, that are only accessible to the language designers.
- zeugmasyllepsis 6y agoSum 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.
- cies 6y ago> feels so natural Yes. They are as important as records/structs a.k.a. product types. > F#, OCaml, Reason, and Elixir Haskell, Elm, PureScript, Kotlin, Idris, ... > I know they add a significant amount of complexity to the language Really? I dont think it can be so much more than generics :) Elm has 'm and the whole language is 5k lines of code.
- eeperson 6y agoI think you want generics for many useful sum types (e.g. options) so you don't have to repeat your sum type definition everywhere it is used. Also, you can have options and matching without sum types (e.g. scala).
- merb 6y agobtw. scala 3 might change that. there is a language feature which can be turned on to have explicit nulls, which will be in the form of union/sum types: https://dotty.epfl.ch/docs/reference/other-new-features/explicit-nulls.html https://dotty.epfl.ch/docs/reference/other-new-features/expl...
- sdfsfsf3kjdf 6y agoHow 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.
- dragonwriter 6y agoPython has all of those things, including generics, so whatever order they are needed in, “Python got it” doesn't argue for one over the others.