Too bad too many people were too poisoned by Java et al to consider switching to one of the good statically typed languages; happily, their recent popularity (like this blog post :)) has gotten people to consider them.
If anything, I'd argue that Java is the main reason for the rebirth of the popularity of static typing.
Java is a C++ without the compiler getting in the way, so it exposed the power of what you can do with a type system (pretty weak one, but one anyway) when syntax is not tripping you every step of the way.
By making static typing popular, Java kickstarted a whole new generation of improved languages such as C#, Scala and Kotlin which leveraged all the good concepts introduced by Java (such as no more separation between headers and implementation) while adding important missing features, such as type inference and traits.
It's not like Sun took a gun to everyone's head and said "use Java, damn it". I mean, Microsoft might try that :-), but Java succeeded almost despite Sun (e.g. on its own merits as a language), instead of because of them.
And really it was Sun's bungling of the language evolution that led to Java's lack luster reputation today. In constract, Microsoft did a very admirable job with evolving C# to keep up with more modern syntax/semantic expectations.
I suggest that Java mostly caught on for two reasons (from a purely technical perspective):
1. It had automatic garbage collection.
2. It had a batteries-included approach to its standard library.
In practice, both of these had caused much pain for C and C++ programmers for a long time, and a platform where things Just Worked was very appealing for a lot of those programmers. That in turn led to non-technical advantages that drove the widespread adoption of Java for server-side/enterprise programming.
I don’t see that either of those technical advantages has much to do with the type system, though. In fact, of all the programming languages and type systems I’ve used, Java’s is probably still the worst by almost any interesting measure.
I don’t really accept the original premise that static typing is making a comeback; it never went anywhere. However, if it’s gaining renewed interest in certain parts of the industry, I suspect that has more to do with increasing experience of where dynamic typing can have disadvantages as more projects using it grow larger and are maintained for longer, and perhaps to some extent with aspirational statically typed languages like Haskell showing that some of the perceived disadvantages of static type systems are not inherent problems.
It is better these days, but even today Java programs tend to have more distribution issues than other languages.
In the olden days, besides the awful Swing GUI that made it immediately recognizable, gray squares and/or stack dumps when trying to execute Java applications or applets were common.
I would love to have a mainstream development stack with the kind of programming tools and expressive power that plenty of modern languages and libraries now offer, but which ultimately produced compiled and statically linked executables the old-fashioned way at least by default, without necessarily relying on package managers or heavyweight virtual machines or run-time linking or writing code just to describe how to install my code. Unfortunately, I doubt that such a language/tool chain exists today, though I’m optimistic that sooner or later someone’s promising niche language will break through.
The thing about Java is that it is really hard to write clever hard to maintain code in it. Sure, it makes it painful to develop with, but because it leads to maintainable code the code never gets thrown out and rewritten and almost by accident very large multi-million line code bases grow over time in it. These huge code bases lead to a lot of jobs for people doing maintenance on them, not because developers like the language, but because the code still works and never becomes impenetrable, as most large code bases often do.
The Go authors are saying that Go is for "systems programming". What they apparently mean by that is server side infrastructure stuff, the kind that is now frequently written in Java. Things like Hadoop, Tomcat or even database systems.
What they don't mean (I believe) is operating systems, device drivers, embedded systems, real time stuff including many trading and telecoms systems, graphics pipelines, signal processing, libraries that are too complex to rewrite in every language (like browser engines), etc. There's a very long tail of these things and it's growing as we get more intelligent connected devices.
Much of that is now written in C++. The question is, will C come back to replace C++? I don't think that's going to happen. I love C. It was my first language and I admire its simplicity. But there is one thing that C++ has over C: RAII. RAII is an ingenious universal resource management tool that gives us 90% of the productivity gains we get from garbage collection without any of the unpredictability, and it helps with resources other than memory as well.
Forget templates and all that fancy stuff. C++s raison d'etre is RAII. So, I think, Rust may have a chance to replace C++ (purely from a technological perspective) but Go unfortunately does not.
Only future will tell.
I have used in the past desktop operating systems (Native Oberon and AOS) without any single line of C++ code, written in GC aware system programming languages (Native Oberon and Active Oberon).
I do like C++ a lot, but I am quite confident that manual memory management will eventually be a sweet memory of old coders.
I don't mean that Go will be that language per se, but that whatever we might use for doing systems programming in future OSs will be GC enabled, even if it allows for some way to do unsafe/system local memory management.
A lot of "dependency injection" BS can also exceed the tolerance threshold of more experienced programmers.