Go really should have learned 2 lessons from Java 5:
1. People will eventually want generics 2. Retrofitting generics onto an existing language is hard and leads to unusual problems
(edit: I'm glad Go is doing this, but...Java learned this in 2004.)
1. People will eventually want generics 2. Retrofitting generics onto an existing language is hard and leads to unusual problems
(edit: I'm glad Go is doing this, but...Java learned this in 2004.)
If you see "unusual problems" with the design, then tell us what they are.
Otherwise it's just shallow pattern matching "Java added generics late, they had problems, Go added generics late therefore they'll have problems too".
Counterexample: C# added generics late and it's perfectly fine design.
The reason Go team is not rushing to implement generics is precisely so that the design makes sense, in the context of Go.
Over the years Ian Taylor wrote several designs for generics, all of which were found to not be good enough.
They are doing it the right way: not shipping until they have a good design and they didn't have good design when Go launched.
1. https://arxiv.org/abs/2005.11710 2. https://news.ycombinator.com/item?id=23368453
We all called this when Go was created, too.
(Not to disparage WASM, which has some nice ideas both on the technical and ecosystem level.)
I think TypeScript, Scala, Kotlin, C#, and various others I forget now proved that these things weren't a fad and could yield significant gains in productivity and code correctness.
Had Rob Pike been more forward looking (or hired Anders Hejlsberg or Guy Steele to design the language) or dipped further into the PL research, he might have been so bold himself. I don't think anyone can fault him for it, these were niche and minority views in 2010 and may not even be in the majority today.
I think at the same time, we see what happens when a new language has large corporate backing in more recent years. Swift more closely resembles Rust than Go in terms of its type system.
I've had a long career coding in C, C++, Java, Lisp, Python, Ruby... you name it I've done it. Go is my favorite most productive language by far for solving typical backend issues. My least favorite? Java by a HUGE mile.
It's pretty simple -- those of us who use those feature regularly in other languages know how valuable they are, and we miss them when they aren't there.
Is that really a problem? I think proper sum types to allow Result types that can encode many success/error states are so much nicer than an exception hierarchy. Rust and Kotlin did not go with exceptions, and for good reasons.
> C, C++, Java, Lisp, Python, Ruby... you name it I've done it.
Let me name a few: Rust, Kotlin, OCaml/Reason, Haskell, Elm. These languages carefully selected a set of features, the all have: no implicit nulls and sum types. And in your list non of them have those features. I really wonder what you think of these features when you've worked with them.
Kotlin very much did go with exceptions except for the Result type in coroutines which wraps a Throwable anyway and is only used for the border between the coroutine runner and the async functions.