Go has no valid argument about its weak, mostly unsafe type system. Go advocates that pretend it does look silly.
-
-
Replying to @tqbf
How do you propose adding Option<T> without generics? Another special case?
1 reply 0 retweets 0 likes -
Replying to @andygocke
I assume so, yes. I think “no generics” is probably a defensible design decision.
1 reply 0 retweets 1 like -
Replying to @tqbf @andygocke
I think “no generics” is less defensible than “no option types”.
1 reply 0 retweets 2 likes -
I'm in the opposite camp. I'm totally fine with no-generics Go and am productive. I still feel the need for option types/sum types.
2 replies 0 retweets 3 likes -
My biggest concrete issue with no generics in Go is that it’s a concurrent language with no support for concurrent data structures.
1 reply 0 retweets 2 likes -
But you know why it’s like that. I don’t see how they could be clearer about the concept.
1 reply 0 retweets 0 likes -
I believe Go is like that because Pike made a design mistake early on and stuck to his guns.
2 replies 1 retweet 6 likes -
I could believe that, but I don't find that line of thinking super productive
2 replies 0 retweets 0 likes -
FWIW, if you put me in charge of Go, I’d add basic ML generics w/ no functors, some sort of sealed interface ADTs, and try! like error sugar
1 reply 2 retweets 5 likes
Then I’d try to turn all the existing builtin magic into sugar. I think it’d be a *simpler* language at the end TBH, in line with Go goals.
-
-
Replying to @pcwalton @ManishEarth and
Wouldn't that basically make it Rust?
2 replies 0 retweets 0 likes -
Replying to @basus @ManishEarth and
No, it would still have GC, data races, M:N threading, and would have no typeclasses/traits or macros, etc.
2 replies 0 retweets 3 likes - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.