> Since when is powerful reflection a drawback or a sign of a broken language?
When it is not balanced by an expressive type system, it becomes a cop-out where anything goes,including creating adhoc types at runtime ( reflect.StructOf() , reflect.SliceOf() , ... ), because it's the only way to get a little bit of expressiveness of out that language.
If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects.
> If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects.
Yet it is there in the language. Why is that? how do you justify adding this to a statically typed language?
Your position is that statically typed languages shouldn't have reflection? I think that's a pretty fringe position to take that not many programmers would agree on. The JVM and .NET static typed languages have reflection, C++ will (hopefully) get reflection one of these days soon as it's been talked about for a while. Even rust has reflection. I think statically typed languages without reflection are the exception rather than the norm.
Go has its quirks, and many design decisions that I find dubious, but so does every language I've used. I'd still much rather tackle a new project in Go than Python or C++ or Java. It's efficient, it's got great tools and a fully-stocked standard library, a fast compiler, static type checking, type inference, and is extremely easy to read other's code because the language is so simple. There aren't a million ways to write cryptic code, unlike say Scala - which appeals to me more on paper but is a disaster to work with in comparison.