Anyway the hype is surely not the reason why anyone should use go. People should use go because it has good libraries, encourages good interfaces, is fast and space efficient, has good self documentation, is easy to test, etc.
Who's to say that a similar thing isn't happening with the current latest and greatest tools?
There was and continues to remain NOTHING that compares to the Java platform.
Java can do stuff and people use it which is fine. The con was that it was inherently portable and secure and can be used for client software. None of that is true. Today if someone told me that our new client interface was going to be java that person would be reassigned to a role where their awful judgement would not resurface.
Java today is basically the slower edition of C++ which isn't that amazing of a niche.
It is inherently portable, because the bytecode can be run everywhere you have a JVM. You don't need to compile for every platform you wan't to run your software in, or muck around with cross-compilers. True, you can do plattform-spesific things in any language, but the Java standards library is almost entirely cross-plattform. In this way, Java really is as cross-platform as it gets.
The language itself is more secure. Buffer overflow? Forget about it. Undefined behaviour? Forget about it. Wierd stuff happening due to pointer arithmetick. Forget about it. Memory leaks? Forget about it, (well, almost).
Why can't it be used for client software? A JVM language can be used for anything that doesn't require minimal use of memory or short start-up time. Any program you write that will be running for more than 10 seconds and don't run in a memory strained environment, fits Java rather well.
Java is also easier to learn and reason about IMHO than C++.
Java today is the easier, safer, more portable but slower and memory-hungry edition of C++. Which is why there is a hype. Altough that hype is slowly dying, due to Java (the language, not the vm and ecosystem) being outdated compared to it's competitors.
This part I have some issues with: the language is still quite modern (compared to C, for example). There are several other reasons for its slow demise: its licensing issues and initially problematic Linux implementations put it at a disadvantage on the server side and in circles where open source was important. It is quite verbose and not well-suited for web development - not the best proposition at a time where scripting languages and rapid web prototyping were on the rise. Finally, the enterprisey orientation of later developments around Java and heavyweight ecosystem really put off beginners - editing XML (build.xml bigger than the whole program...) sucks.
C is supposed to map very easily to what actually happens under the hood. Thus C will never have closures, type-inference, generators and the like as a part of the language. This is a part of the languages design, which is why you shouldn't compare it to feature rich languages like Java or even C++.
There is nothing wrong with hype if that hype is warranted, and Java certainly has an unmatched track record in terms of delivering solid, portable and easy to maintain code bases that power millions of applications today.
> The con was that it was inherently portable and secure and can be used for client software.
Java hasn't been pitched for client software since the death of applets, circa 1999.
Java is so good in so many domains that it's easier to name the areas where it's not the best: graphical applications and CPU intensive programs (games, numerical calculations). That's about it. For anything else, Java is most likely to be a very solid default choice.
... today. Thrownaway2424 said (my emphasis) "Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker."
This was true. Sun purchased Java's popularity. It did not even come close to living up to the hype in the first few years. I could segfault it without much difficulty using Swing, and I was hardly using it for anything (school assignment!). I was not a sophisticated developer at the time. I should not have been able to do that.
It is also true that through tenacity and dedication, Java eventually did live up to its promises. But that came later.
XML is still the right tool for the job for many use cases. JSON is great for serializing data structures. XML is great for marking up various types of textual data.
Other people have already covered your comment on Java.
We need the structure that JSON can't give us and other data markup languages are too obscure to teach them to everyone we work with.
In the 90s, before Java, you had C/C++ dominating server based code that wasn't COBOL (Smalltalk tried to compete, but it's failure is a whole different story), with BASIC/Delphi/PowerBuilder/OracleForms/arguablyMFC dominating UI based code.
I will grant that Java gained a lot of buzz due to Java Applets in the browser and with deceptive claims regarding how portable AWT and later Swing applications were. But for server side business application coding (NOT systems coding), Java blew C/C++ out of the water.
C++ on large projects, especially with the feeble template compilers at the time, had insanely long compile/link times. It wasn't unusual to kick off a build and have to wait an hour or more to be able to test it. It's true you could break things up into dynamic libraries to try to reduce link times, but that meant more work, especially if you had to run on different platforms. And there were specialized tools like ClearCase's ClearMake that could speed things up, but they were far from commonplace.
Java for server based code compiled quickly and eliminated the link times (well, it moved linking to runtime, but effectively it also made each class into it's own mini shared library). And Java stack dumps were orders of magnitude more useful than C/C++ core dumps. Performance was slower compared to C/C++, but faster than interpreted languages at the time, and generally "fast enough" for most business applications.
Java's JDK also provided a lot more "out of the box" functionality than what you had with the C++. Heck, even just having a standard String class was tremendously more useful than having to deal with char arrays. And the collection library was feeble, but it was there. (The C++ STL wasn't released until 1998, and RogueWave was probably the closest thing to a de facto C++ library, but it was a commercial product).
The rise of internet e-commerce also convened to help Java out. A lot of sites started with cgi-scripts, which had to launch a new process for every CGI request. Even C/C++ CGI programs were slow because of this. Java's servlet spec provided a very convenient way to run multiple requests in a single process, which was typically at least an order of magnitude faster than CGI at the time. And it was much easier to write servlets than to compile a custom Apache C/C++ module into your apache distribution.
And for as many headaches as Java caused for "cross platform" UI code, it actually worked pretty well for cross platform server side code. Gone were the spaghetti pragmas from cross platform C/C++ code.
So what happened with Java is that the applet/UI buzz got in through the enterprise door, but it's server side conveniences are what enabled it to gain tremendous enterprise acceptance. And IBM jumping on board the Java ship was somewhat of a green light for COBOL shops to move to something else that was still blessed by IBM.
>> XML was pretty big back then, too
XML really didn't come about until the late 90s and was really more of a 2000s buzzard. It's being rightfully replaced by JSON for a lot of browser/server interactions, but for better or worse there are still quite a few places that it's sticking around.