What functions return interface{}? I rarely see it outside of marshaling/unmarshaling (where I believe it would remain even if the language had real generics) and contexts (which would also use interface{} if there were generics).

Sometimes you want dynamic typing, how else will you pretty print structs? The compiler could generate code but that's a lot of bloat. For context, the point of it is that you don't know what's in it, it's an opaque container for information to be used by middleware. The fact that data might be missing lends itself to easier refactoring later on.

I want generics in go, but I don't find my code using much interface{} at all.

It really depends on the type of application you're building, I suppose. I've seen applications littered with empty interfaces, and others with hardly any.

If you really want good static typing while being fairly python like, there are other great options. Java or c++ both have decent generics, speed comparable to go, great libraries and years of collective experience using them.

I truly hate the social hacks that are causing go to displace much better languages.

It's the learning curve. If you know another imperative language, you can grasp golang in a week. With C++ or Java, you need months.

Java is pretty darned graspable, at least I think it's way closer to Go than C++. What do you think are the biggest things that make it hard? The language? Warts like int/Integer? Library size or organization? (This is a real question, I can't look at this stuff with "fresh eyes.")

For me? The environment/runtime.

I can write a simple program in C/C++/go/rust/etc, and compile and run it.

In Java, a bloated IDE isn't just a recommendation, it's practically a requirement.

Evey time I try to learn Java, I smack my head against the toolchain. I ended up just giving up when I tried to wrap my head around classpath, and haven't tried since. I could probably figure it out pretty easily now, but I just don't see any allure in learning Java anyway.

One of these days, I might start using Clojure, but the JVM just feels so messy that I don't want to start.

There is no requirement to use an ide in Java. I've never written Java in anything other than emacs and never had a problem.

I'm likely overstating the problem, but that is my experience as I remember it.

My main point is that Java just isn't appealing enough in the first place for me to want to deal with the relatively insignificant issues I ran into.

> much better languages.

I disagree. Java has a bloated syntax, and C++ is a mess. Java also depends on a proprietary runtime, with mostly compatible free alternatives.

The biggest advantage C++ offers is speed, through memory management, which is usually a pain to deal with.

Go, on the other hand, has a well thought out syntax, good support for concurrency, garbage collection, and compiles to native executables.

Could you illustrate what you mean by "bloated syntax"?

Everything else you mention (besides native executables) Java also has. From what I can see, Java provides far better concurrency support - more paradigms than simply go routines.

Classes are required. Sometimes I just want a c-style program without a class. Java looks a lot like C++ (just with garbage collection, and some more consistently defined behavior). In comparison, golang (and rust) have some nice syntactical differences: inferred types, postfix type annotations, etc.

Go routines are nice when that is all the complexity you want. Having more paradigms isn't an interesting prospect until it becomes specifically useful.

Java may be more usable in many cases, but it, in my experience, just isn't easy to work with.

Apart from the boilerplate enclosing class (4 lines, vs 2 in C), you can write a C-style program without classes in Java. There is literally nothing stopping you and generics are helping you significantly for this.

That's completely true, but I just don't like the boiler plate. It's not hugely important to the grand scheme of things, but the more barriers I have from writing a function to running code, the less I want to deal with the toolchain/language in the first place.