import org.apache.hadoop.*;

import org.rapidoid.net.Server;

In case you are wondering people not only using languages for language features but also for the quality/quantity of libraries available in those languages. This is why is very hard to bootstrap a new language. Java has a ton of great libraries that are essential to big data and high performance backend services that you do not have in Go. I could mention tooling as well but we can skip it for now, the aforementioned library situation is enough to not to consider go already. Btw. the new OpenJDK releases are just fine for running Java and many companies use it extensively already (like AWS EMR for example) to run production code.

  import (
  	"net/http"
  	"github.com/labstack/echo"
  )

If you want to compare nifty scripting languages than you can compare Perl with Ruby or Python. In 2008 I was happily using Ruby for most of things we used to do in Perl, a bit slower yes, but who cared and it was much more readable.

Perhaps even compare with Perl 6 :-)

Java also has a multi decade history of remaining backwards compatible across major version upgrades. Barring known exceptions for things explicitly being removed, I don’t see that changing.

And Google has a history of starting and scrapping products without much attention to the remaining userbase. I'm not saying Go is one of these.

But regardless, we're gonna have to give it a few years to get a Swift ecosystem even trying to get on the mic in the same venues as Java/JDK.

Then there is still the regular one, release that get support for a very long time. That LTS releases and Java 11 is the first LTS release since Java 8. Java 8 will still be supported for a while even though Java 11 is out, giving you years to update.

So basically if you like how it worked before, in the days of Java 1.4, 5, 6, ... you just need to only look at LTS releases.

Especially if you use Java for desktop applications rather than server-side. And Generics was not part of Go's plan for a long time.

I enjoy both but would not say Go offers all that Java has or vice versa

Really ? What is the Go equivalent of J2EE ? Do Go appservers exist that offer all the features that something like Payara (Glassfish), JBoss or WebSphere does ?

Kubernetes, Istio, Prometheus, All the Hashicorp stuff, hyperledger, traefik , kong you name it.

EDIT: I see from the docs http://docs.wildfly.org/14/High_Availability_Guide.html that you need to configure an Infinispan cluster, what looks like a non-trivial operation.

I consider not having a suffocating bureaucratic "framework" that can be replaced by simpler and more straightforward constructs most of the time a feature and not a bug

But those that grow up under a bureaucracy tend to miss it

Of course new languages are quickly getting more and more tools but sometimes I feel that they are just reinventing the wheel (sometimes squared). For example: it's easy to host a mirror Maven repository, the file structure is very simple, even with per-project setting. It's not that straightforward with npm or cargo, they push you into centralized model with paid private repositories (npm).

All those 'simpler and more straightforward' constructs cost a lot of extra time and effort, there's a lot of reinventing the wheel going on. Can you do something similar to just adding a field annotated with @PersistenceContext or @Resource and having a database connection injected ? Does it also allow for complete decoupling between the configuration of that datasource and the application itself ? Can it resize the database connection pools live, and then push that config change to an entire cluster, without writing a single line of extra code ?

In theory, the changes should really be minimal but to be sure we would need to have a very strong CI and stress testing platform to be sure about upgrading.

All good projects should have this in place anyways.

Back in college, I created a small desktop app that played a WAV file when any key was pressed, but could be closed silently with the mouse. (Its purpose, along with a recording of me screaming, was to train my cats not to sleep on my laptop.) It would have been written in Java 1.4 or maybe 1.3. The applet library was a pretty standard way to open and play an audio file, because it was simple.

Fast forward a few years, I came across the app again and decided to see if it still worked. It didn't work with the existing JRE on my box. So I rebuilt it with a more recent JDK (1.6, I think). It built, but it still didn't work.

See, Java 1.5 AKA "Java 2" had a new memory model, deprecated a lot of things (like applets), and started modernizing heavily. They attempted to maintain backward compatibility, giving us things like the awful erasure-based generics, but it really wasn't fully BC. They really should have just done what Python did with Python 3 and make Java 2.0 non-BC.

This isn't an isolated incident, either. A major project I worked on updated from Java 1.6 to 1.7 and it broke several things. They were fixed pretty quickly, but it still wasn't truly backwards compatible. It's just like the Java claim that you can write once and run anywhere, which is only half-jokingly referred to by devs as "write once, debug everywhere".

Anyway it's a misconception because it only applies to the Oracle JDK, OpenJDK still follows a different support structure I believe.

Er... Well, I'm with you for a different reason than updating... I'm thinking that Oracle is just shifting the licensing ground too much for my comfort.

Besides, dotnet core would not be a better replacement: it's got a large corporation behind too, so nothing prevents them to do the same in the future.

This is an LTS release. It will be available for more than a few months.

Poor little Oracle & IBM.