You may not have used reflection in Java but we have a very large application in production which is heavily dependent on reflection. It is in use for many years and serves business purpose just fine. Could there be a better way? maybe, but a working solution now is better for our business than promised solution in remote future.
I think the striking point is that you're forced to use a throwaway to have an opinion.
I agree with you about Go's flaws. However, if you have never used a cast or reflection in Java, you have either not done much Java, or you have used libraries and frameworks that do the casts and reflection for you.
Re:My Go Resolutions for 2017
by fauigerzigerk on Wednesday January 18, 2017 @01:11PM
(#13428656)
Absolutely. Many people will decide not to use Go for these reasons.
But others will come to the conclusion that things like complex name lookup rules, or generally too many possible interpretations of individual syntactical expressions, cause hugely greater mental load than any of Go's shortcomings.
That said, I have a lot of complaints about Go too. Especially error handling.
Almost every dependency injection framework in Java uses reflection extensively. And nearly every java project I've ever seen used one of them. Your claim that you didn't have to do reflection may be correct but I'm betting you were consuming code that used a lot of reflection.
How many? how many didn't use Go because it lacked of a sane type system? because Go relies way too much on runtime behavior (AKA type switches and reflection) to be called a modern statically typed language. In all my time using Java I never had to cast something once or use reflection, or to do a type assertion, all these are common practice in Go, especially when the std lib is now getting API like Context.Value(interface{})interface{}.
This isn't PL theory, these are flaws that aren't going anyway and will become more apparent as users will have to maintain all that "productive Go code" written 5/10 years ago. With Go the developers basically do the compiler's job manually. These problems are absolutely not going away, and people will write about how they ditched Go for these reasons.