5 ms·

well, here it comes... introducing generics was a mistake. give it a couple of years and golang would be indistinguishable from java

pjmlp 5y ago
That is the thing, Go could have learned from the past and been designed properly fromt the get go instead of accumulating hacks to fix design shortcomings.
akavi 5y ago
Java doesn’t have union types
- _old_dude_ 5y ago
  sealed typed are union types, granted they have been introduced very recently.
  - akavi 5y ago
    Oh, interesting. TIL, thanks!
LambdaComplex 5y ago
Is there an actual issue that you have with sum types?
- mutatio 5y ago
  I think (at least from my perspective) the issue here is that sum types are not first class citizens supported by the compiler, for example non-exhaustive matching in Rust would result in a compile time error. Implementations like this are a mere approximation - and takes a while to grep exactly what is going on (at least for me).
lawrjone 5y ago
Just curious on this, what about this do you think is a mistake? You could do this before without generics, you'd just be unsafely casting types (which can panic at runtime) or assigning to a closured variable, which is quite indirect.
- ngalaiko 5y ago
  sure. but usage of generics in go is heavily discouraged both by best practices and by the api generics however are more available to an average gopher i believe that such availability will eventually produce a go version of spring, or a typescript-like type system, or something even worse
  - lawrjone 5y ago
    Yeah, I think this is personal preference at this point. I find TS to be pretty great, especially in how you can use the type-system to help you build your code. If your goal is not that, then we'll be aiming for different things. > is heavily discouraged both by best practices and by the api On this though, I'm unaware of generics being discouraged? Given they haven't even been released yet, and the amount of effort that's been put into building them, I don't think there's any reason to believe they're discouraged.
    - ratorx 5y ago
      Generics were originally not included because the Go designers felt that it was not necessary, and things could work without them. Even though this opinion has changed, I don’t think it’s been completely reversed, just weakened. So I still think “Idiomatic Go” would be to avoid generics, except in some specific situations. To me, Generics feel like “smart code” in any situation except the most basic and the predominant mindset I’ve come across is that Go code should be dumb and easily understandable (if verbose). I think the situation with TS is different. I also like TS (but haven’t used it as much), but tend to write different code with it than I would with Go. I don’t think there is any one clear winner and I find it more helpful to write code as expected for the language chosen, rather than trying to apply the ideas I loved from every language to every other one (as a user, obviously language implementors should be open to inspiration). Otherwise I would probably spend a significant amount of time poorly reinventing Rust Results in every language I use, which would temporarily confuse everyone else who read my code and not be as robust.
a_humean 5y ago
Except notably sum types and pattern matching are language features that are not assoicated with Java at all. They are more closely assoicated with ML and functional programming languages, and not with Java. Java only got something approaching sum types in Java 17 with sealed classes, which came out in 2021. Standard ML has had this feature since the 1980s! You might want to consider that there are type system linages that exist that are quite different to the one presented by Java.

pjmlp 5y ago

That is the thing, Go could have learned from the past and been designed properly fromt the get go instead of accumulating hacks to fix design shortcomings.

akavi 5y ago

Java doesn’t have union types

_old_dude_ 5y ago
sealed typed are union types, granted they have been introduced very recently.
- akavi 5y ago
  Oh, interesting. TIL, thanks!

LambdaComplex 5y ago

Is there an actual issue that you have with sum types?

mutatio 5y ago
I think (at least from my perspective) the issue here is that sum types are not first class citizens supported by the compiler, for example non-exhaustive matching in Rust would result in a compile time error. Implementations like this are a mere approximation - and takes a while to grep exactly what is going on (at least for me).

lawrjone 5y ago

Just curious on this, what about this do you think is a mistake? You could do this before without generics, you'd just be unsafely casting types (which can panic at runtime) or assigning to a closured variable, which is quite indirect.

ngalaiko 5y ago
sure. but usage of generics in go is heavily discouraged both by best practices and by the api generics however are more available to an average gopher i believe that such availability will eventually produce a go version of spring, or a typescript-like type system, or something even worse
- lawrjone 5y ago
  Yeah, I think this is personal preference at this point. I find TS to be pretty great, especially in how you can use the type-system to help you build your code. If your goal is not that, then we'll be aiming for different things. > is heavily discouraged both by best practices and by the api On this though, I'm unaware of generics being discouraged? Given they haven't even been released yet, and the amount of effort that's been put into building them, I don't think there's any reason to believe they're discouraged.
  - ratorx 5y ago
    Generics were originally not included because the Go designers felt that it was not necessary, and things could work without them. Even though this opinion has changed, I don’t think it’s been completely reversed, just weakened. So I still think “Idiomatic Go” would be to avoid generics, except in some specific situations. To me, Generics feel like “smart code” in any situation except the most basic and the predominant mindset I’ve come across is that Go code should be dumb and easily understandable (if verbose). I think the situation with TS is different. I also like TS (but haven’t used it as much), but tend to write different code with it than I would with Go. I don’t think there is any one clear winner and I find it more helpful to write code as expected for the language chosen, rather than trying to apply the ideas I loved from every language to every other one (as a user, obviously language implementors should be open to inspiration). Otherwise I would probably spend a significant amount of time poorly reinventing Rust Results in every language I use, which would temporarily confuse everyone else who read my code and not be as robust.

a_humean 5y ago

Except notably sum types and pattern matching are language features that are not assoicated with Java at all. They are more closely assoicated with ML and functional programming languages, and not with Java. Java only got something approaching sum types in Java 17 with sealed classes, which came out in 2021. Standard ML has had this feature since the 1980s! You might want to consider that there are type system linages that exist that are quite different to the one presented by Java.