Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.
I don't think you understood my analogy. Go supposed to be Toki Pona.
I'm saying that once you are used to a language that's more powerful you feel constrained.
I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases.
> I'm saying that once you are used to a language that's more powerful you feel constrained.
I did misunderstand your point, though I don't find this one more compelling. While Java has more features than Go, the only one I would consider to be "more powerful" would be generics.
> The concurrency supposed to be the killer feature, but it is limited to specific cases.
How do you figure? To which specific cases is it limited? How is Java better?
> BTW: The Go is not subset of Java if anything it's very similar to Algol-68
My argument wasn't that Go is most similar to Java; only that Go's featureset is almost a strict subset of Java's. Go gives you tighter control over memory and a better concurrency story, but most of the rest of it looks the same.
