Remember that Google Trends just measures search traffic. Also, handy tip, select "Programming Language" instead of "Term", the graph changes slightly with that: https://trends.google.com/trends/explore?cat=5&date=all&geo=...

Another tip, by default Google Trends just show data from the US, which is not very interesting, select Wordwide to get a better picture: https://trends.google.com/trends/explore?cat=5&date=all&q=%2...

Competitors are hard to say as there would different categories. Some workplaces would only choose a JVM language, then Scala's competitors are Java itself, Clojure and alike.

Go and Rust have mainly been described as "system" languages but they take vastly different approaches from each other.

If you be a bit more specific on what you're compared them on, it'll be easier to know if they are competitors or not.

I was interested in Scala and used various tools/hacks to build Android apps with it. Very neat language but the pain for building on Android was too much for me - I stopped using Scala around 2016/2017 as Kotlin became viable (and is now extremely well supported) on Android.

Depends who Scala was a competitor to.

If you viewed Scala as a competitor to Java, then Go is a competitor to Scala and not Rust; because Go is a competitor to Java in my opinion.

Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries.

If Go 2.0 ever happens, it will be a competitor to Java 5.

So, it depends on what you’re talking about; language or organizational need.

Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you’re talking about how teams use Java and Go, they’re a good match now.

Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and moving them around. From an organizational perspective there are a ton of Java shops that use Java for similar reasons, plus the ability to cheaply and quickly acquire contractors who know Java.

Both, people comparing Go to Java apparently lack a complete understanding of the Java universe.

If you are talking about doing REST APIs, talking to Postgres in Java 1.0 servlets style code, yeah Go is a replacement for Java.

Except that is like 1% of everything that is currently being done in Java.

Go is a competitor to Java in that most of the things people do with one, they could do with the other.

As a Java guy, i would agree that Go is not actually competitive with Java. But then, a Go guy would probably say the opposite.

Really? Where are the Go versions of Spring, JEE, Android, Solr, Liferay, Kafka, Gemalto, microEJ, PTC, Aicas, Ricoh, Kyocera, Java Card, VisualVM, JFR, JMX and plenty of other stuff I haven't bothered to type?

You really should not have started with spring and jee

Not understanding why they exist is the first error trying to sell to enterprise.

Seeing how .Net is being sold to enterprises without such libraries I would say that they exist because business happily buys into any promise that something increases productivity even if that is just salesmen's lies. But it requires good salesmen not good engineers.

Actually it does have many of those libraries, they just come with a different name, or in commercial only form, without the FOSS variants from Java.

Avoiding the necessity for libraries like many of these would be a key success criteria for a new language were I judging.

Then don't expect to actually take over Java on the domains it owns.

Why Java devs automatically assume that every new language is made to overthrow Java/C#? They might still to provide better development in a particular domain. Go or Python or JacaScript are good at rivaling Java at mainstream language, and so what?

Because that is what the "every new language" crowd keeps selling, without understanding how they got there.

I know people who would be sold on NO JEE, NO Spring, NO Hibernate. I am one of them. :)

I have to say if they add generics without type erasure to go then Java is likely in trouble.

A language feature alone doesn't replace an ecosystem with 25 years of production experience across platforms that aren't even supported by Go.

After getting generics, Go still needs to offer JFR/JMX/VisualVM like monitoring and dynamic code loading capabilities (Go plugins are very limited), JEE/Spring like Web tooling, Liferay/AEM/Magnolia like CMSs, an OS of its own and real time GC, card chips, M2M hardware gateways, printer enterprise configuration appps, and plenty of other use cases that many on HN seem unaware of its existence in enterprise scenarios.

Isn't Kyocera, like, a printer company?

Yes it is, and those printers support Java for customised enterprise solutions.

Good. Here I was thinking Java 17 to be released in 2021 will be competitor to Go 1.0 when it finally have value types.

Yeah, meanwhile Gonuts will still be discussing what is the best way to add generics, while it's users on Hacker News keep telling us that it isn't political and there is a working prototype at Google.

So where is the EA for generics like the value types EA I can download today from OpenJDK repository?

To be fair, apparently this appears to be the current internal prototype, https://go-review.googlesource.com/c/go/+/187317

It still appears quite far from being done in 2021, though.