The argument on looking at Go's trend in isolation is a really weak one. Let's also look at Clojure in isolation: https://www.google.com/trends/explore#q=clojur

The argument on looking at Go's trend in isolation is a really weak one. Let's also look at Clojure in isolation: https://www.google.com/trends/explore#q=clojure https://www.google.com/trends/explore#q=clojure - and oh look, Clojure runs on the JVM. > If I were a developer getting started today, I’d make a career bet on Go Advice on picking languages as career bets are especially weak. In my experience, careers are being built on being able to get stuff done and in the long list of things that a developer has to learn to get stuff done, the language itself is very uninteresting considering everything else combined. Personally it takes me 2-3 weeks to become functional in any new programming language, I've worked with half a dozen thus far in production and I played with another dozen in my free time. The language itself is like a drop in an ocean, compared to more fundamental knowledge that makes one productive, like math, algorithms, concurrency and parallelism, hardware, usability, domain specific knowledge, libraries, frameworks, being able to interact with a community, etc... > Go is a simple language by design. You can read the spec and other materials on the Golang website and start being productive in a single day Simplicity in the language doesn't translate to simplicity in the solutions that you're building. This is a fundamental divide, since often people are mistaking simplicity for easy, for being familiar. It's not in the original sense of the word - simplicity is the opposite of complexity, which means interwoven or entangled and in the context of software it means building reusable / modular components, that do one thing well and that can be stacked / connected together to build bigger solutions and to keep complexity manageable. Go is in fact anti-simplicity. Its lack of generics, given its static typing, is a really good example of a design fuck-up, since for building reusable higher-level abstractions, one really, really needs generics and this is an objective fact - note that we aren't talking about dynamic languages here, which don't care about static typing or for being close to the metal. There's no point in denying that and Go will end up like both Java and C++, both of which didn't have generics in the beginning - and so it will end up with a half-baked solution with lots of corner cases and that people will hate, until the next language comes along also lacking generics, because "simplicity", repeating the cycle ad-nauseam. In fact a programming language is supposed to be extensible, because both in natural speech and in our systems, we are extending our language all the time to manage complexity. If this gives birth to features that are harder to learn, that's a freaking drop in the ocean compared to all the shit that we must do when implementing complex business logic. I recommend watching Guy Steele's "Growing a Language" presentation, it's very enlightening: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 But then again, extensible languages and higher-level abstractions are raising the bar to entry, which often goes against the other generally accepted solution for managing complexity, which is to hire more average Joes that can sit in a chair and type. > Simple languages are easier to learn. Familiar languages are easier to learn. There, fixed the typo. And if you're only learning familiar stuff, then you're not learning anything new ;-) I keep going back to Alan Kay's quote which will be relevant for a long, long time: "Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves."