Excerpt of email reply from Nathan Myhrvold is mostly correct:
>The new Java applications are NOT credible threats to traditional PC software any time soon. [...] Cool new technology always expands rapidly into NEW ares (where there is a vacuum).
Java's hype of Write-Once-Run-Anywhere to kill Microsoft Windows didn't happen on client desktop apps like many expected. Desktop apps are still C++ and some newer apps are Javascript(Electron). Yes, there are a few niche desktop apps using Java like JetBrains IDEs but history has shown that Java made more market penetration on server-side code. The 1990s dot coms like Ebay and Amazon were early users of Java on their servers. I read that Google uses Java on the web servers to generate the results page. (To be clear, I think Google uses C++ for the crawlers to build the index and the algorithms for search engine ranking.)
Java didn't kill the desktop. The web - Javascript - has put a huge dent in it, especially via the medium of smartphones which were never going to run Windows desktop software. (+). The desktop limps on but it's not quite as dominant as it once was. You can run an entirely successful multibillion dollar software business without a single Windows machine being involved at either the client or the server or developer ends.
(+ don't mention Continuum or UWP or Windows Phone)
>Java didn't kill the desktop. The web - Javascript - has put a huge dent in it
Nah, I disagree. Mobile killed the desktop, 85% of that is Android, and most Android apps are written in Java. So yeah, Java did eventually "kill" the desktop. But I would point out it was mostly low cost, battery powered, untethered mobile, not the Java language or runtime. What Java solved was a chicken/egg problem where there are no developers because there's no market because there's no developers...
The web never killed the desktop. There are no high end games on the web. There are no native features on the web. The web provided forms and ssl; an e-commerce platform. That's it. Everything outside of e-commerce on the web is ad supported which leads back to e-commerce. All roads lead to Rome. That sums up the total contribution of the web on humanity as a whole IMO. Yes, you can list off small exceptions, but most people using the web are participating in e-commerce at some level.
You mean the native app stores on smartphones? Because that's what competes with desktop software now that people user their phones for computing. But you can still get the app version of windows desktop software.
> you can still get the app version of windows desktop software.
Not really - you get app versions of portable software, which may be entirely rewritten from a similarly-named desktop app, but they're not the desktop app. It is as you say a separate version that requires separate maintenance.
What you can't do is take a 1996-era Windows app and run it on a smartphone without a complete rewrite. Surprisingly, you could do this with Windows CE for handhelds, like the Compaq Pocket PC which ran ordinary MFC apps with minor tweaks and a recompile.
Microsoft had one last go at desktop/phone unification with UWP, and that lost in the market.
IMHO this was because the JVM at the time had bad performance compared to native apps. I certainly avoided Java apps on my machine as much as possible if there was a native alternative, the extra load on consumer machine resources at the time just wasn't worth it.
HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.
I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself.
For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit.
I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path.
Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.
> I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path
That's a slightly confusing comment because while it does integrate it in some components, very little of LibreOffice is written in Java. From what I understand, the core of it is all written in C++ and it's often held up as a canonical example of what happens when a giant C++ codebase gets out of control and doesn't manage complexity well.
Well, the stack overflows through the years seem to resolve similar issues by pinning the JRE version, so I assumed it had something to do with it. Sounds like that might have been a bad assumption. Either way, I never tracked it down. Plenty of options for spreadsheets these days.
In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.
Later, but HotSpot to this day means “less slow” - it’s a lot better than it used to be but you still need considerably more RAM and CPU than native apps.
Just because someone managed to come up with a worse alternative doesn't make Java good. The main problems, initial JIT time and fixed heap size still remain.
Java has always been tunable to be more aggressive at returning memory to the OS if you are worried about the resident memory size. Newer versions of Java with the more advanced GCs are even better at it.
Ultimately Java's runtime performance wasn't really to blame for it's lack of success but rather the awkwardness of JRE distribution, garbage applet sidetrack and lack of high quality GUI toolkits that actually felt native rather than attempting to do "platform independent look and feel".
How does the tuning work? To me it still seems that JVM (or at least the version bundled with JetBrains IDEs) keeps allocating memory until it's near max heap size and it's up to the user to find the value that's large enough stop the app getting stuck doing full GC but leaves memory for other apps.
JVM can be tuned via the command line during startup. Eclipse comes with 512MB as the heap size, and you can enable a small gauge to see how it's doing. I've never seen "This heap is small, please give me more space" error from Eclipse. Also, latest versions of Java (starting with 16 IIRC) doesn't grind to halt during large GC passes.
I've developed enough applications in Eclipse during past 20 years, and it has become from being an absolute lead ball to something agile for its size, both in macOS and Linux. I've found an infinite loop bug in CDT, and only with that I was able to make JVM throw the towel, and call it quits.
JVM is very smart and resilient in memory management, I've seen some stuff during my life.
Defaults are important. The world runs on defaults. Bad defaults cause real problems and take real work to fix, so it's fair to blame software for poor out-of-the-box behavior, even if it can be configured away.
Well, a message saying "This heap is small, please give me more space" would be all too helpful. I haven't touched Eclipse in years, but Clion and Rider have this failure mode where they just use all the CPU all the time and it's up to user to figure out that it's GC and how to increase the heap size. I was hoping for an option that would mean "use all the memory you need but don't keep the maximum allocated just in case". The current -Xmx seems to be more like "postpone full GC until the maximum has been reached".
I'm not sure if it's significant that Jetbrains IDEs and Eclipse are separate products. Google can't distinguish between different Jetbrains products in search results, maybe Eclipse can be lumped into same group by some logic.
Atom, yes, VSCode, no. The latter is noticeably faster and uses less RAM — and the JetBrains suite is even worse.
A large part of this is cultural. The Java world has been prone to high complexity styles which are hard to optimize and there doesn’t appear to be much social expectation that you profile or improve code until you max out what you can easily fit on a single system.
Latest Eclipse (esp. after they switched to 4 releases/year schedule) is very lightweight and nimble for what it does.
It's being optimized for being faster and lighter every release, and it really shows. I mostly develop C++ and Python in Eclipse, and CDT's indexer is really good, and it's not using gigabytes of RAM, or doesn't require LSPs to be productive. OTOH, Eclipse supports new things like LSPs, direct builds to containers, etc.
So, it's getting faster, doesn't getting heavier resource wise, and keeping its edge tech-wise. I'm a happy camper.
Oh, and the plugins doesn't need official binaries, if you're inclined to build your own.
Personally I find Jetbrains IDE, Phpstorm specifically, very snappy. Much better than VSCode in performance.
I few years ago I managed to run Phpstorm on a ASUS Eeebook with an Intel Atom 32 bit 1.3 GHz CPU & 2GB RAM. Not optimal but doable.
I’m impressed what Jetbrains has managed to squeeze out of Java. However I’m not aware of any other Java desktop app that that works as well.
Only thing you can’t do is to manually run every inspection there is on the entire project, takes forever and will eat your CPU even on a fast machine.
JetBrains IMO is about the same performance as VSCode for waaaaay more ease and functionality.
It doesn't give me that deliciously snappy feel compared to something like terminal NeoVim, but my productivity is ultimately much higher on a JetBrains IDE
Far less than an order of magnitude — and it shouldn’t be the case that every advanced feature slows down core functionality like how long it takes for a key press to render when you’re not even using that feature. They have lots of functionality but proponents have always noted the … stately … speed and these days the ones I know have moved to VSC because it’s competitive for the features they use and they benefit from better performance all of the time.
You still can’t really conclude that it is due to Java somehow.
Also, if jetbrains would finally use a non-deprecated GC and a slightly more GC-friendly max heap setting, intellij would have much better latency. (You can try this out yourselves, just go with G1GC and increase heap size for a good improvement. But the best experience would come from ZGC but it is only available in a newer runtime than the bundled 11)
Definitely, but when almost every Java program I use has issues with performance and memory it suggests that the culture doesn’t value those things highly enough. The same is often true in the JavaScript world, which makes VSC interesting because it’s famously an outlier in the Electron world.
> The same is often true in the JavaScript world, which makes VSC interesting because it’s famously an outlier in the Electron world.
That's because it's not a JS problem so much as it is a problem with the culture of NodeJS/NPM. It happens to be that NodeJS has pretty much cannibalized JS development, however.
Two large pieces of software that make heavy use of JS that most people don't even realize—because they don't feel like the kinds of apps that NPM programmers produce—are Firefox and the Gnome desktop. They're by no means examples of the top end of world's snappiest software, but they are solidly middle-of-the-road in a way that most Electron apps, for example, are not.
Dominant platforms that capture lots of developer attention (like NPM today, and Java starting 15–20 years ago) end up capturing the attention of the sort of programmers who are going to be causing trouble no matter what ecosystem they're working in.
I mean, both programs hardly use JS for anything other than scripting the behavior of a very optimized C/C++ codebase. So I don’t think it is fair to call them JS apps — I have never heard Firefox referred to as such.
Your remarks here, esp. re "hardly use JS", make for a wildly misinformed comment. (You realize that every Electron app also has at the core a "very optimized[...] C++ codebase"? Aside from that, Gecko makes very little use of C and by now makes extensive use of Rust.) XUL-based apps were doing the Electron application architecture before Electron (or NPM, for that matter) even existed—and on average they've done it better.
> I have never heard Firefox referred to as such.
... so?
The fact that you aren't aware how heavily reliant that Firefox (and Thunderbird, and Zotero[1]) is on JS for its UI and other application logic doesn't exactly change anything. In fact, that most people aren't aware of it is rather the point of the comment that you're responding to...
While Firefox's JS usage is more ingrained and near to its core, GNOME's and KDE's JS usage is nowhere as deep. They both use JS (and QML in KDE's case) as strict scripting engines, which directly bind to C++ codebase underneath.
GNOME's JS introspection libraries are even "autogenerated" from the source and header files.
I played with both, and the weight the JS parts are lifting are pretty minimal. All the stuff is done by the C++ parts underneath.
It's like using TensorFlow, SciPy or a similar C backed library and telling that you use Python for computation. Same thing.
At the end of the day, any Electron app I use (I use TiddlyDesktop for example) is using more RAM and CPU, and bogging down both considerably more w.r.t. Firefox, KDE or Eclipse. When a simple application which has a very optimized C++ core is using more resources to show a simple web page and manipulate it is using comparable resources to my IDE or primary browser, there's something very wrong.
I've done more than play with Firefox and Mozilla toolkit code. "All the stuff is done by the C++ parts underneath" is an overstatement. (Not least of all because a bunch of stuff is now done by Rust parts and not C++ parts.) Plenty of the behind the scenes stuff is JS.
> At the end of the day, any Electron app I use (I use TiddlyDesktop for example) is using more RAM and CPU, and bogging down both considerably more w.r.t. Firefox, KDE or Eclipse. When a simple application which has a very optimized C++ core is using more resources to show a simple web page and manipulate it is using comparable resources to my IDE or primary browser, there's something very wrong.
These remarks doesn't really make any sense here. I didn't show up to the party defending Electron apps and their authors. My comment was an explicit indictment of typical NPM and Electron development practices.
> I've done more than play with Firefox and Mozilla toolkit code. "All the stuff is done by the C++ parts underneath" is an overstatement.
By both, I meant KDE & GNOME. I didn't dive into Mozilla/Firefox stuff, but as far as I understand, since setting enterprise stuff and locking features, etc. (I forgot the name of the enterprise stuff, it's long time ago) is done in JS, JS is more than skin deep in Mozilla/Firefox codebases.
This is understandable though. Firefox is just Netscape, and they just invented JS. Not much involved otherwise.
> These remarks doesn't really make any sense here.
They're not direct counter-arguments to you. Just I've wanted to say that, even though the Electron is built on a C++ core, it's extremely inefficient and wastes a lot resources for what it does, that's it.
Still, it’s like claiming that OpenJDK is written in java — yeah, the SDK has many parts in Java, but it is still a C++ executable that has bootstrapped another language.
Is the CSS layouting engine, the network stack, the goddamn JS interpreter or the myriad other literal millions of lines of code of firefox is in JS?
Of course electron apps bundle a.. browser, but you are just pedantic. An electron app’s core functionality is not the bundled browser.
They don't. You are conflating Web browsers and the engines that power them.
Web browsers are applications unto themselves. They require lots of application
code separate from the underlying engine. You don't get a Web browser by
compiling a browser engine and calling it a day.
> Is the CSS layouting engine, the network stack, the goddamn JS interpreter
or the myriad other literal millions of lines of code of firefox is in JS?
VS Code, an Electron app written in TypeScript, requires all the same components. And you keep saying "Firefox" when it's not appropriate to do so.
The millions of lines of code in _Gecko_, along with Spidermonkey, establishes
a platform for building apps that's on par with the Electron
platform. Gecko + Spidermonkey does not a Firefox make, however. The code
that makes Firefox Firefox[1] is in a separate application bundle, which includes
on the order of hundreds of thousands of lines of JS.
1. ... and not, say, Zotero, which is literally built by downloading a release build of Firefox, stripping out all the Firefox code while leaving Gecko et al intact, and dropping the Zotero code in its place.
Solr is the one exception I have personal experience with. The rest of it basically comes down to the culture of complexity: HotSpot is no match for the average enterprise architect.
This is only partly true. HotSpot is pretty amazing performance wise. For certain code patterns it really does produce assembly competitive and even better than what you get from the equivalent vanilla C++ solution.
The issues are (a) it only kicks in once something gets profiled quite a few times (so your first encounters with a function - the one you base your impressions of usually, are at its worst), (b) the overhead of JIT weighs down the machine further at exactly the moment (a) is occurring. And then (c) there are quite a lot of code patterns and in particular architectural styles encouraged by the Java ecosystem that are hostile to this whole process.
I do wonder why Java has not gone the python direction of caching the JIT output in binary form so at least the 2nd time you launch an app it doesn't need to be redone every time.
It's complicated to do binary caching for various low level reasons. Amongst other things, the generated binary code is specific to the precise location in memory and makes lots of assumptions about the state of the runtime like what classes have been been initialized.
Still, HotSpot has been slowly (too slowly) getting AOT-like optimizations in the form of AppCDS. It doesn't actually store compiled code but a lot of other internal data structures can be stored to disk in native form and just mmapped at startup. It's usually a 30% win or so, which isn't bad.
It did actually work for a time that you could point the jvm to precompiled class files, but it got discontinued (it was part of GraalVM which has a different pace to OpenJDK)
But imo that is only relevant for startup - otherwise the problem with Java’s JIT compilation is the identity of objects, which makes it much harder to do some optimizations. Hopefully with valhalla we will see quite a boost.
I think you're ignoring the giant world of custom, bespoke, enterprise software which is majorly written in Java (and these days on web) - the fact which makes Windows in the Enterprise (Microsofts main money maker) much much less sticky as they would have liked.
The little bubble you're talking about is far from Microfts main concern.
Luckly, Linux and macOS never really could grow out of their niches to really hurt Microsoft.
> Luckly, Linux and macOS never really could grow out of their niches to really hurt Microsoft.
"Kind of" (indirectly as others pointed out) - the Dotcom bubble from a systems perspective was based on "Put these words on your VC funding paperwork and we'll throw money at you: Netscape Enterprise Webserver, ATG Dynamo (or similar), Solaris 5/6/7 on Sun E250s and E450s, Oracle Database and Java". I was at a services company doing systems work for Java engineers and built countless versions of this stack; java code was written on Windows workstations and deployed to the Sun servers (this might help explain why Java is deployed the way it is - many devs just zipped up a directory, uploaded it and unzipped it remotely).
Then Blackdown JDK[1] entered the room and changed the game - it gained it's first release right after the Dotcom bust and turned that stack on it's ear; now you could use Apache, Tomcat and MySQL (because Java developers could run MySQL on Windows, it "won the war" against Postgres at that time) creating a way to survive in the money-vacuum years following the Dotcom bubble crash when things were very scrappy and people were looking to just survive the storm if they could. My services company had to lay off some 80% of employees because all the clients dried up during the bubble burst.
There was a shot right here to have Java production workloads run on Windows Server (NT etc.) since all the java devs were doing it personally, but running on Linux was a much higher performing stack at the time and of course pennies compared to the previous stack even in the kernel's younger years or paying for Windows licenses (and more hardware). Red Hat's IPO in 1999 preceded the Dotcom bubble, putting them in the right place to handle these workloads post-Dotcom as they had a mature Linux offering with a business plan to Enterprise minded shops (appeal to the business folks - save money, have someone to blame if it breaks). Techs loved it because we'd been doing Linux for a decade and here it was about to take over the server world, and Java workloads were helping make that happen.
my understanding was that java was originally envisioned as a runtime for iot. i remember reading a lot about how they were expecting it to land in cell phones, set top boxes and other internet connected devices.
they started with applets in the browser. at the time javascript was incredibly immature and used mostly for client side validation of form fields; but was hated by users and developers alike because browser support was inconsistent leading to spaghetti code and bad ux.
java applets were also frowned upon. the jvm was quite heavyweight and would struggle to start up on the pcs of the time. the immaturity of the technology made the uis sluggish and fragile.
i don't think anyone expected it at first, but using java in web backends became very popular. i suspect this was because performance was reasonable once a server was warmed up and it was sort of turning into an ecosystem that a lot of money was being poured into. the microsoft ecosystem for internet stuff at the time was buggy and terrible, with its "systems built to run internally on corporate networks" lineage showing. on the backend, iis was known to be insecure and hard to code for and on the front end, nobody wanted to aid microsoft lock-in with client side vbscribt and activex.
the geeks wanted internet native unix based servers and the well trod options there were java, perl and php (or bespoke options built on them). nobody wanted to do strings in c/c++, further pushing towards high level languages of which java could be a performant one for heavy workloads.
ironically, the java iot dream was eventually realized by google with android. even more ironically, it's probably the most complicating and complained about part of the platform.
It was basically sort of like the web but for mobile Java - a whole bunch of not entirely compatible and uniquely buggy implementations, to which adding features was a very slow committee driven process meaning every new feature got reimplemented in 4 different incompatible APIs first.
Additionally at the time the mobile makers were totally in hock to carriers, who usually insisted on having their own app stores with totally developer hostile processes. So to even run on a lot of phones was a huge PITA because you had to get every carrier to sign the "midlet" and they had no easy process for this.
So the issue was not so much Java the tech - Android proved that - but more the model around how it was managed. Android took the basic concept of J2ME, dropped the actual APIs and design-by-committee (triggering the lawsuit with Sun/Oracle in the process), created a robust open source implementation, gave it away for free and invested heavily in their app store tech. And that led to success.
ahh yeah. forgot all about the wapiverse. afaik there was really only one application, and that was the wap browser which was really simple except for ssl support.
i think most people didn't even realize their phones had something browserlike back then and even if they did it was tough to use.
i never used it. google's sms gateway was more useful for my purposes.
Not a J2ME developer but I've heard time and time again that it had extremely poor cross platform compatibility and each different handset needed modifications to the source to get it to function.
This was back when there were a million competing incompatible handsets. Not a fun time!
> I am literally losing sleep over this issue since together with a move to more server based applications it seems like it could make it easy for people to do competitive operating systems.
Gates was talking about server applications, and he was right. Within 10 years, people were using Gmail instead of Outlook and Google Docs instead of Word. Both are written in Java on servers not running Windows, exactly as Gates feared.
I mean it's also a lot of client-side JavaScript, but yeah, I thought this line was the most prescient.
As I've moved back and forth between Windows and Linux over the past 15 years, I've found it increasingly easy to do everything on Linux, and that's mostly because more and more of what I do is just in the browser. At this point, it's Linux on my personal laptop with a Windows virtual machine for only two or three Windows-only desktop applications that I still occasionally require.
As long as Firefox and Chrome are cross-platform, the OS matters less and less.
> Desktop apps are still C++ and some newer apps are Javascript(Electron)
I think the reason java failed on desktop and electron works is because electron is an entire runtime packaged into the app. The java team failed to recognize that people want to install an app without worrying about external dependencies. Later on the Adobe AIR team failed to realize this as well and while AIR had a promising start it flopped as well due to external dependencies.
I’ve always wondered why Java didn’t take off more for desktop apps. Was it a compromised user experience vs native apps? Was Swing bad to work with? Did Web 2.0 come in and steal the show right when it was starting to gain traction?
I think it's the core, the 2D engine, just never got the love it needed to be a great place to start. Nobody seemed to prioritize making that happen.
Like, the antialiasing was noticably fuzzy. I never found an applet that looked like it belonged on the webpage. And when I built a few, it was a lot of work to even get font rendering to not be horrendous. And even then, you'd see what the browser rendered vs what the applet rendered and they were always off. I remember using images instead of font rendering sometimes.
So, if you made a swing app, it was easy to put together, but hard to make look "professional".
By the time of the Oracle acquisition, I'm pretty sure everyone just realized the browser and mobile "won" and that's why we just had JavaFX get broken off the platform and basically put out to pasture. But it's not like much went into the core platform itself to make building great UIs easy. The underlying 2D rendering just a great place to start.
When I look at where JetBrains is going, it sure seems like they are building on top of a better 2D engine, in this case, skia: https://github.com/JetBrains/skija.
It was a PITA to manage for end users. They had to install the JVM and update it when the JVM updater told them so. Many people didn't update (slow connections for a file size comparable to today's one, no time, etc.)
Then the application had its own non native widgets and was noticeably slower than native ones.
Then (more importantly IMHO) developers discovered that HTML interfaces were good enough even 25 years ago and being able to update a web application (they were no app back then) even only once per month was so much better than having to distribute thousands or millions of copies of a desktop application. Game over. BTW that was web 1.0.
I wrote a Java Webstart app for internal users way back when. It was harder to work with and not as end user friendly as what I could create in VB5. Of course all my internal client were on Windows so VB was an option.
Then the web came in and stole the show. Even a slower web app was so much faster to develop and push out to 10k internal clients (that was a lot then hah).
As an end user, the UX was always goofy. If the devs made a lot of effort, it could look like a bad impression of a native app, but never exactly right. As soon as you'd hit an error state or edge case, you'd see some weird ass Java-looking error.
Electron is different, because we all got used to web apps, and electron apps are just web apps.
I never got why a web application with custom layout view is ok but a swing one looks funny
I get the browser controls look native but still as a whole they also look different from a desktop application
Through IE, Microsoft controlled what you could run in the browser and they refused to upgrade the embedded JVM. Java Applets started becoming popular but then they stagnated.
Microsoft control was broken when Google decided create Chrome. Chrome is what allowed javascript to flourish.
I think that is glossing over some important details. Sun sued Microsoft repeatedly, and eventually stopped licensing Java to Microsoft. "Upgrading the embedded JVM" was not a user-friendly mandate... think of how annoying "upgrade" or "new version available" notices are today... now consider the same over a 14.4k modem. And finally, most Java applets sucked. Very few were "popular". They looked weird, non-native, had unfamiliar icons and menus, and were often slow.
I don’t personally, but what matters here is that Electron has taken off and Java-for-desktop didn't seem to really. Maybe it was the tech, maybe it was user expectations at the time, but something was different. I’m just curious what that was.
It didn't happen because Microsoft was able to kill it.
See, for a few years MS had a tight control over the browsers and they refused to upgrade the JVM in IE when they lost their infamous lawsuit against Sun. So Java Applets never flourish.
Microsoft control was broken when Google decided create Chrome. Chrome is what allowed javascript to flourish.
I think Gates was losing sleep because he had come to expect to win everywhere all the time. Myrhvold’s reply (in a lower tweet) is a gentle way of saying that Microsoft doesn’t have to, to succeed as a company.
I think as a company finds continuous, outsized success, there is a risk for a leader’s mindset to get warped and resistant to anything but outsized success. Anything less than domination looks like a problem, an anomaly that must be found and destroyed.
I think it might explain some otherwise indefensible behavior, like HP spying on their board, or all the shady stuff that Uber was doing, or even MS’s own anti-competitive behavior.
I think leaders have to get shocked out of this mindset or just removed. Gates was shocked by MS’s conviction and stepped down. Ballmer and Kalanick were pressured to resign by investors. Both MS and Uber have benefited from new leadership that lowered the temperature and refocused the company.
I also think it explains why Facebook is the way it is now. There doesn’t seem to be such pressure points available for Zuckerberg though.
Microsoft's new leadership may have "lowered the temperature and refocused the company" to open-source software, but now they're more than ever anticompetitively promoting Edge and Videos and etc., progressively making it harder to switch browsers or make Start/F1 search open a different browser, manipulating users who use Edge search for Chrome, making Edge run in the background for fast start (I suspect to make it appear faster to start than Chrome), baking telemetry into Windows and VS Code and PowerShell and vcpkg, releasing proprietary extensions for proprietary VS Code which won't run on open-source VSCodium, performing hostile takeovers of .NET Foundation projects, etc.
One of the weird things about this is that Microsoft had compiler and programming language stuff as their bread and butter for a time. So Myrhvold's reply does include "embrace and extend" and that they'll do J++, but I'm not sure why that point wasn't emphasized more. A programming language ecosystem was their wheelhouse. They of course got in trouble trying to out-Java Java, and still calling it Java. They did C# and while it did not "kill Java", it was hugely successful for them.
It'd be a somewhat reasonable and simple answer, and an honest one, to Gates's concern: "well, let's be a kickass platform to run Java on."
Uber made the smart choice. They can always buy back into autonomous vehicles when a company comes up with an autonomous vehicle the works well in all weather conditions. All they have to do is buy them and add them to their fleet and combine with their current app infrastructure.
Tech companies don't have a choice but to grow fast all the time. As soon as the growth stops even a little, they lose investor interest and their stock will crash unless they find the way to keep going.
Since this thread contains a lot of comments about Java's ergnomics and speed of innovation, it might be interesting what has changed in the last years:
It is pretty impressive how Java keeps up to date over decades! I think in the long run it is very wise to be conservative over new language features. For example the work von "green threads" (project Loom) is a really good, fundamental approach with backwards compatiblity and there are some voices on the web thinking that such an approach is more clever then introducing "async" to the language (C#, Python, etc). I really appreciate how careful the engineering is and how they don't shy away from putting years into some topics.
I guess I've never read these emails before. I was a child when these emails were released, so I really wasn't following these events in real time.
I'm blown away at how openly they discuss being anti-competitive. When I think about a company being monopolistic, I usually envision market and environmental pressures that culminate in actions that can be broadly identified as anti-competitive. I don't typically envision leaders sending emails to each other on how to best be cartoonish villainous monopolists. And I guess it's strange that there was a time that it was considered even feasible that Windows could corner the whole web. Then seeing "embrace and extend" literally quoted in the email feels like some bad hit piece on Microsoft.
Developers my age grew up with multiple OSes with web capability. When I graduated, Chrome OS just came out, Android, iOS, and OS X were all widely used. Most of my career Microsoft has... "embraced" FOSS. Just some thoughts from a different perspective.
yeah, in addition, a lot of younger people see Gates as some sort of savior given his philanthropy. I think a lot of older people in the tech industry see it as Gates trying to buy his way into heaven.
It's easy to handwave away Bill's concern today because windows is still the main OS on PCs and laptops.
That's kind of missing the point. What you don't see is all the areas where MS could have 'won' had the world not moved in a more platform agnostic direction. Remember all of the little miniature laptops in the 90s? Practically all of them ran some version of windows even if it was laughably impractical for such a device. MS completely missed the 'mobile' train and could have dominated if they were paying attention.
Remember all of the enterprise systems running some version of windows server? Imagine a world where java didn't exist and the .net runtime was dominant. That's a cash cow without end.
As it is, MS missed out on both mobile and most of the enterprise infra pie. If they had managed to capture both they'd be an absolute behemoth.
> Remember all of the little miniature laptops in the 90s?
In the 90s? Laptops barely existed, definitely not "little minature" ones. I remember e.g. the https://en.wikipedia.org/wiki/Asus_Eee_PC launched in 2007, and many follow-ons after that.
The HP95LX [1] was introduced in 1991, ran from two AA batteries, has MS-DOS and include a ROM version of the Lotus 1-2-3 spreadsheet.
Eight years earlier, in 1983, the Tandy TRS-80 Model 100 [2] was remarkable: 4 line x 40 char display, 8kB RAM, powered by 4 AA batteries, all for $799.
Incidentally, the May 1983 issue of Byte magazine in [2] was themed "The Electronic Office" and is full of ads for Apple, Microsoft and IBM products, amongst others. Back then, a 20MB hard drive was $3300, equivalent to $9000 in today's money.
PCs took a hard turn towards power-constrained (i.e. laptop running on battery) right around the same time Windows took a hard turn towards "resources are cheap and plentiful, just toss seven levels of XML in it"
The apps of tomorrow are not exclusive to Windows I would say, Instagram, Google, eBay, etc so I would say he was right also.
The response emails were also right in that the existing business was not immediately threatened, but it is definitely diminished.
"Java" in 1996 isn't what Java is today. In 1996 Suns focus was providing a runtime for executing code anywhere on the network, on any machine. That's why security managers, class loaders, applets, rmi, and jndi were baked in from the beginning. That future didn't pan out; no one wanted to run other peoples code. So J2EE was the pivot to the Enterprise and server apps. That's what we ended up with.
In a way, Gates may have been imagining or extrapolating the "run code anywhere" idea to the cloud services of today, which we've seen is a bit of a threat to proprietary operating systems. Well, more than a bit.
This obviously didn't stay true; the browser is everything the JVM wanted to be today. A JIT for a universal programming language and multiple layers of sandboxing.
I don't think people care about running other people's code. Java just wasn't seamless enough. Or they lost some key political battles (few major OSes shipped with it).
Microsoft had already established itself as the dominant market player in the early 90s. Bill Gates was the richest person in America by 1992 and the richest in the world by 1995.
The 90s Java hype must really have been otherworldly to make him panic this much.
You lose the developers, you lose the platform. That's what Bill Gates was thinking.
Microsoft was "lucky" that:
1. JVM was too slow to run desktop apps on machines even in the early 2000s
2. Web and Javascript became so important that it reduced the impact of losing out on Java
3. Linux killed Sun Microsystems.
Still, so much server infrastructure runs on Linux+JVM stacks that you could argue that it was a major reason Microsoft failed to gain dominance outside their desktop stronghold. Years later, their biggest existential threat in the form of Android was basically a modified Linux+JVM stack.
People may think Bill was over-pessimistic, but looking back, their failure to kill off potential competitors like Java was one of the reasons Microsoft stagnated post-2000s.
The 90s Java hype must really have been otherworldly to make him panic this much.
I think it is a certain personality type that has more than $50 million* in assets and still has this level of competitive edge.
I think most people have a number that would drive them to relax a bit and just do whatever they wanted. I think for some people whatever they want though is to engage in cutthroat competition.
if anything, Gates-era Microsoft was known for being anti-competitive. What the very-wealthy want, I think, is power and control, and for the number to go up to stroke their egos.
> Bill Gates was the richest person...the 90s Java hype must really have been otherworldly to make him panic this much
I kind of disagree with this line of reasoning. I think very successful people sometimes overestimate possible threats, and it may be one of the reasons for their success. I had this realization when watching the most dominant Age of Empires player stream once. I once struck by how paranoid he was about what the opponent might be doing, but it meant he was constantly prepared for worst-case scenarios. He seemed genuinely worried most of the game, rather than confident like I expected given his first-rank status.
If you read Nathan Myhrvold's reply he says something very similar:
"It is a new and uncomfortable feeling to be the incumbent rather than the challenger in one of these battles. However, we must not panic. The current perceptual battle is a long way distant from actual business and revenue issues, and we can't let perceptual issues cloud our thinking too much."
It was the battle for "the web" and the sun+netscape partnership was an actual menace to microsoft's activex and vbscript things. There is an espisode the Lex Fridman podcast with Brendan Eich where he talks a little about that specific time.[1]
The "panic" was right imo (only in that specific area) i mean, there is almost 0 microsoft on the web today.
C#, TypeScript, Azure, Visual Studio, VSCode, GitHub, the npm package ecosystem, Microsoft Edge, having the de facto monopoly of several markets with office and its web integrations, Microsoft Teams suite for enterprise and I think I'm missing a lot more stuff.
Claiming there's no Microsoft on the web seems far fetched when Microsoft de facto controls extremely large parts of producing modern web applications, deploying them and serving the tools necessary for businesses to coordinate.
It may have lost share to competing applications or it missed the train exactly, but I cannot think of any other single company you can lock in your organization from management, production to deployment and even consumption on Microsoft own devices from Surfaces to Xbox.
This is the "post-apocalyptic" Microsoft. These things are open-source and supporting Linux, which was unthinkable for Bill's Microsoft.
MS used to call Linux cancer, and now they're running Linux servers for people. MS used to spread FUD that it's irresponsible and amateurish to expose source code of programs, and later they had to acquire GitHub and npm to stay relevant.
Microsoft had to adapt, because the old Microsoft has lost. Remember MS was selling very expensive per-CPU licenses for servers to run IIS, ASP.Net, and SqlServer. Admin tasks that we use webapps for were supposed to be a combination of Office, Access, VBA, native Windows applications, and a dash of ActiveX.
It is also key to understand that they are far more diverse than ever. Azure earns money independently, so does Office and Windows, XBox, etc. They do not rely on each other anymore.
The only big part which is different is the former developer division. I do not think they earn the money themselves but are more a cost center to everyone else. But considering that everyone else is a giant company with a diverse set of developer needs, maybe that is just okay. Which again is interesting because the rest of the industry is also relying on this part of Microsoft.
Even if .NET is technically a cost center, the reduced cost they get from optimizing it making things like Bing faster probably still makes it indirectly a profit center by saving them so much money.
I've worked (as a consultant) on a number of 'boring' B2B web applications targeting 'boring' industries and one thing they all had in common was that they where all in on the Microsoft stack.
TS is just fancy JS. If it didn't exist, Flow, Haxe or Dart would just be in the same place (static types languages with JS-ish syntax that compile to JS).
> TS is just fancy JS. If it didn't exist, Flow, Haxe or Dart would just be in the same place
"TS is just fancy JS" is like saying "Java is just fancy machine code" or something like that. It's a major software project with a much larger scope than simply slapping a few types on top of common JS constructs. More importantly, it's been an innovating force at the language and editor tooling levels for web developers worldwide. I think it's likely to be the most successful language that Microsoft has ever produced in the long run.
> "TS is just fancy JS" is like saying "Java is just fancy machine code"
Terrible analogy. TS doesn't compile to WASM or anything, it compiles to human-readable JS. Java doesn't compile to C++ or C. The JVM is an entire platform.
> More importantly, it's been an innovating force at the language and editor tooling levels for web developers worldwide.
MS has always been decent when it comes to tooling but there's nothing particularly innovative about TS.
And if Java didn't exist we would have other tools as well. And yet Microsoft has by far the largest share of language adoption on the web, which likely applies to the tooling too.
By far? You really think the majority of websites are using TS-generated JS? The majority of the web is Wordpress and PHP frameworks. TS has only become 'popular' rather recently, and there's still a TON of websites that are full-stack SSR with only modest amounts of JS.
As for tooling, maybe. VS has always had a decent amount of mind-share. Even then though, I can see Jetbrains + Eclipse + Sublime + Emacs + Vim + others capturing at least 50% combined...
Market cap during the Steve Ballmer CEO tenure would be a better comparison, as it was during this time that MS was fighting Blackberry, Nokia, Apple and Android on the mobile OS front. This was the battle that Gates was worrying about: the declining prospects of Windows as an application platform.
Their stock exploded once Nadella came in, killed off DOA products like Windows RT and Windows Phone, and shifted the focus to Office 365 and Azure cloud where they had a deep enterprise advantage.
The consumer web absolutely existed in '96. Gates was worried that Java could become the defacto choice for authoring web applications. Microsoft didn't have much of a foothold there at the time.
How does that disprove my statement? Microsoft essentially had a monopoly on desktops and software in 1996. Just because their market cap is larger now doesn't mean they weren't on top in 1996.
Does anyone really think Microsoft has as much influence on tech today than they did in 1996? They've clearly been pushed out by Google, Apple, etc, which is exactly what Gates was fearing would happen (although in this instance, the threat he feared was from Java/Sun).
I think what they were trying to say is that, to the kind of mind capable of being as ruthless in getting to the top as Gates was, the biggest anxiety they would have after making it to the top is that someone will come and take it from them.
I mean, it's a rational position to want to defend the business you created or the market share you carved out. Every business has to do this to survive. The only problem is when a business resorts to unethical tactics.
Gates seemed to go through a bit of a transition sometime after this (perhaps after the antitrust case), where he seemingly lost his uber competitiveness and then stepped down from CEO position.
Ain't Java the 2nd most used language in the world, after JavaScript? The enterprise world uses Java everywhere. Java powers pretty much the entire banking infrastructure.
Aren't there billions of Java smartcards that people carry in their pocket/wallet and use on a daily basis?
Aren't there billions of Android apps installed that are, basically, Java?
One can dispute the numbers a bit but... How is Java not one of the biggest success story ever for a programming language?
I'd also add: it's kinda funny to see so many programmers hating on Java and thinking that, somehow, Java is dead or dying, yet on a daily basis they'll use one of the JetBrains tools, written in Java, to work on their "non Java" code.
I do not only think he was right to lose sleep over it: I think Java delivered.
> How is Java not one of the biggest success story ever for a programming language?
It absolutely is.
Java isn't sexy, for the most part. It lets a lot of innovation happen in other languages, then takes the successful parts for itself. This is how we (eventually) got generics, lambdas, streams, and local type inference, for example.
Java slowly becomes more ergonomic, and that slowness - the slowness to change, not execution speed - is why it gets a lot of hate. Why use Java, when $LANGUAGE_OF_THE_DAY has $FEATURE_OF_THE_DAY?
What people fail to realize, what people fail to see the value of, is that this slowness means Java doesn't get worse. Java has avoided most unforced errors. It's not like C++, where the template language is both Turing complete and the fastest way to summon Beelzebub from the depths of his infernal pit, and where you need a team of PhDs to decide which version of `auto_pointer` actually works the way you think it does. It's not Javascript, where the framework your front-end lead sold you on last week has already been superseded by the hot new thing.
And you don't generally have to worry about compatibility. Until v9, you could take code written against the 1.0 spec of the language and expect it to run pretty much out of the box. And the changes post v9 honestly aren't that difficult to work through, as opposed to Python's 2 -> 3 split.
Java isn't the sexiest language out there, but it hits a very sweet spot, right in the middle of the "familiar", "stable", and "productive" Venn diagram. It's probably the second-most important computer language developed in my lifetime, after Javascript, and is without a doubt a smashing success story.
When I was using it I didn't particularly mind it except for the clumsy handling of functions (i.e. as objects instead of first-class citizens) and verbosity (no automatic accessors, implicit typing, etc). Adding Lombok solved most of these. *EDIT: Except for runtime type erasure of generics which caused (not sure about new Java) performance issues and made certain type operations difficult.
> but the culture around it is what's grown the distaste many have for it.
Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth. I've lived that life and have no desire to do so again. Because Java is the lingua franca of enterprise development it also tends to rear its ugly head on modernization projects and rewrites. 80% of the abhorrently-engineered codebases I've encountered in my career were written in Java by body shops (C# and Coldfusion were the runners up).
> The overuse of design patterns, etc.
I'm not an adherent of the design pattern cargo cult but I'm one of four people under the age of 50 that have actually read the GoF book and I do indeed sometimes name objects after patterns described in the book; I typically design components and name them such after the fact as opposed to constructing systems from the ground up using design patterns. Calling a thing that persists comments in a database `CommentRepository` is a lot more useful than calling it `CommentHelper`.
> Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth.
The term "DLL Hell" came from Windows development before it. The Node/Ruby/Python equivalent is getting native libraries to build (node-gyp, I'm looking at you!). I've burned days in Ruby Version Hell and Node Version Hell. Javascript dependency upgrades are a nightmare compared to Java dependency upgrades.
I don't think this problem has gone away, or even improved. It's just a grim fact of life, and Java doesn't deserve special mention.
Despite my love for the language (and Stack has mostly fixed this), I feel like Haskell's "Cabal Hell" is amongst my least-favorite headaches from my past.
Getting weird, hard to follow conflicts between different packages on Hackage and dealing with weird compiler hack flags is something that never got fun or easy.
The things you mention are no fun either (`node-gyp` in particular), but the Java issues I encountered were far beyond run-of-the-mill runtime linking and interop issues you describe. The details are lost to time and a bit fuzzy but I recall the primary issue being competing CDI implementations stepping on each other when we tried to use JSF with a recent version of Spring... and because most everything in the Java ecosystem was doing some opaque Aspect4J magic it was nigh-impossible to debug.
If you don’t like putting objects and classes on the left you can write
import static example.Library.*;
And proceed to write in your main method
var x = someFunction(6, ‘that’);
in a style like C, LISP, or ML. You can write a whole program (like the answer for a HackerRank problem) in a single file. The developers of Java have always respected the ML family and JDK17 incorporates pattern matching, records, algebraic types and and many other features that make functional programming fun.
The type erasure problem for generic classes goes away when you use generic methods; type inference works without limitation for generic methods and is great for defining APIs for internal domain-specific languages
any(grammar,you.want(ifIt.parses(ON_THE_LEFT)));
the great thing about Java is a quality IDE is certain to support this programming style.
Any complaint that the internal DSL is too verbose can be attacked by the use of code generation which is straightforward to incorporate in a maven build and your IDE. (The LISPer is using code generation and you have to do it if you want to keep up.)
I think the real majority of hate that I've seen for design patterns are when juniors go into a system looking to slap a design pattern anywhere they possibly can, quickly creating a ball of mud that is difficult to work with and figure out. At least that's been my experience (and I have to sadly admit I did the same when I was a junior without a mentor to help me through figuring out how to refactor my code into these patterns only when needed).
I'm one of the rare people who was writing vb and then c# during the terrible Java j2ee days. Then I got a job in a startup using Java which avoid the 'enterprise' idioms. So my experiences with Java over the last decade or so have been mostly good (except for a foray into Hibernate, never again - jOOQ for life). No crazy class models, no xml configuration, etc...
Amen to esoteric Spring issues. I once dealt with a jar that suddenly started failing despite no code changes because Spring uses the order of files in the zip file/jar to determine initialization order. Turns out one that particular time files ended up in a weird order inside the jar file.
If Common LISP had become popular I think there would be a popular distaste for everything about it and people would be wishing they could write code in PHP, Visual Basic, COBOL, Cold Fusion, etc. (There was a popular distaste for Common LISP at the time, it was hard to find a LISPer in the 1980s who liked it. Half of that was it was hard to fit it into a 16-bit machine and wouldn't become really implementable on microcomputers until a 32-bit OS was available... Thus BASIC got another decade of life extension.)
Until Java came around every book on Object Oriented programming (say "C++") had examples such as "Stack", "Queue", etc. In the case of Java you saw people starting to write objects mirroring the business and application domains. People who were trying to use objects in Smalltalk or C++ in 1990 just weren't accomplishing enough that somebody could step back and say "object orientation sucks", rather they were getting stuck and blaming themselves or blaming the tools, rather than the concept.
A lot of us jumped off the Java train in disgust at the height of the J2EE craze and never looked back, so fairly or unfairly we'll forever be judging everything Java by that tainted memory.
Wait, is that true? I know WebObjects was designed around ObjC, but a quick ten seconds on Wikipedia doesn't indicate that J2EE was designed around ObjC initially.
----
Unnecessary opinion: I don't like either, but WebObjects sucks about 1/10th as much as J2EE.
> By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.
No issues, and here is another one, while Java might have a C++ like syntax to make it more appealing to mainstream, its main influence was Objective-C, not C++.
Bringing it back to a previous point I made, I met someone who claimed to have helped port over the WebObjects framework from Objective-C to Java, and he claimed that while it's not a 1-to-1, you can fairly easily map a lot of the Objective-C semantics to Java, making the porting process not that hard.
Modern Spring Boot is still incredibly bloated and full of questionable design patterns. A simple web application should not consume hundreds of megabytes of RAM by default and startup time on modern hardware should be basically instantaneous. Classpath scanning and annotations are still massively overused and most of the time they're accomplishing little more than obfuscation and turning compile time errors into runtime errors.
Why exactly? How often do you start up a web application? And it’s not like the RAM is not there to use it — thread pools, db connection pools, etc have to be set up.
Sadly it is not: they still get taught, and then juniors come and they expert-beginner projects to death. And yes in 2022 expert-beginner is a verb! Cheers
Java's (Oracle's) strategy is to spend most the innovation on the runtime, and in that regard, it's probably the most advanced platform. The net effect is that you can write some pretty naïve and boring OO-style code that will almost always perform superbly. This is a good thing, and something that I envy as a C# programmer.
Writing Java in my day job currently, I really miss C#. It feels slightly more like a "Java done right" -- the same strategy of bringing "fancier" features from F# or other languages, but it has just a _few_ more features that make day to day development just a little more pleasant.
C# is an excellent contrast. It has always moved quicker than java (not hard), but that has left some features that in retrospect seem half baked. For example they needed some sort of function reference thing, so we had 'delegates', but then later we got lambdas with LINQ. And although LINQ has a lot of good parts, I'm not sure the expression bit was a good idea even people familiar with SQL linked it.
And reified generics are nice for c#, but a right pain if you want to implement another language on the CLR which isn't very c#-ish.
More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course.
Even slow moving java shows that bad decisions have a cost down the road even if the features are unused: there can be monitors on any object to support synchronisation, serialisation similarly lurks around internally.
> More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course
Async/await work much much better than goroutines for GUI programs, which was still a major market at the time this feature was added to C#. Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.
I believe COM also has some similar requirements, but I am less sure than I am for GUI.
Finally, C# has a lot of influence from the functional langauge community, so it's possible that async/await and Task values were a more appealing solution given those particular tastes.
> Async/await work much much better than goroutines for GUI programs, which was still a major market at the time this feature was added to C#. Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.
Couldn't you have the GUI thread on one core, and the "goroutine pool" taking all the other cores, and distribute work on that pool? The model would be a bit more complex than Go, but considering C# is made for a wider variety of usages, multiple models wouldn't be so far fetched.
> Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.
Isn't that just a limitation of Go since its goroutines all run in the same pool? As far as I know, in the Java implementation you'll be able to create virtual thread pools from regular threads (i.e. the gui thread) and then have another virtual executor for the rest of your program. You'll still have the backend vs gui split but you won't have the entire async await split for the rest of your application.
IIRC, they went with async/await because it could be implemented through desugaring in the compiler using a technique similar to what they had implemented a few months earlier with IEnumerable. That is to say, the team was thinking about desugaring at the time the need for asynchronous functions arose and they were not thinking about CSP. Remember that C# was in production at the time and they needed something that would not potentially upset the world.
> More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course.
No one was willing to approve another extension of the old runtime, and a major one at that. If they had already completed the .Net Core rewrite back then they would've probably baked async into the runtime.
Nah, C# has a shitton of more features, some of them indeed making the day to day development more pleasant, while the other ones are known only by a handful of people, has strange interoperability with everything else or is superseded already by another one. It is really on the way to become as complex as C++ is.
Could you list these features? I was under the impression that apart from some things that can be easily done in C# but are pretty much impossible to do in Java (like value types* and pointers) the languages were pretty similar.
Some C# things seemed rather strange (like delegates), some purely cosmetic (like indexers) and there were also things that Java had but C# did not like covariant return types (available from C# 9.0)
*Project Valhalla is supposed to bring it to Java but I wouldn't hold my breath waiting for it.
dynamic is amazing for the extremely niche use case of interop with dynamic languages. I had a system which executed Python scripts on devices using an orchestrator written in C#. With dynamic and IronPython, I could seamlessly unit test the whole enchilada without writing un-Pythonic Python or ugly C# wrappers.
Allow you to get/set the value of someFoo.Bar as if it were a public member.
If you want read- or write-only members, you just remove the "set" or "get" portion.
If at some point you need to add logic to the setter, you just do
int Bar { get; set { /* setter logic goes here */ } }
You still use assignment syntax ("someFoo.Bar = newValue"), but this syntax is desugared into a call to the setter method. Ditto for the getter.
IMHO they make class APIs much cleaner and forward-compatible (on the other hand, if you started with a public member and then need to add a proper setter with some logic, you would break the API).
Also, non-nullable types are a pretty nice way to avoid checking for null every other line of code.
And these are literally just the first couple examples that came to mind.
I think this is can be handled with Lombok using @Getter and @Setter annotations (https://projectlombok.org/features/GetterSetter).
It is not exactly the same because you call generated methods instead using assignment syntax but I guess it's close enough - if you need some custom logic in the getter/setter then you remove the annotation and write your own implementation (I think Lombok might be smart enough to ignore the annotation if an appropriately named getter/setter is present).
Non-nullable types sound great, I wonder if this could be introduced to Java in a backwards-compatible way (I suppose it would follow the same path with introducing explicitly nullable types first, though I guess it could be handled using Optionals?).
This allows you to override the logic later. Public fields in a language where "x.y" means "directly access field y on value x" don't allow that; x.y forever means "directly access field x" and you can't later interpose code between attributes and the code accessing it.
This isn't the only way of doing it, depending on your language. Python has a completely different mechanism where a class can start with a directly-accessed "y", but in a later version make it a property. (More than one, actually.) Some languages route all property accesses through something you can hook. Some languages simply automatically do what C# is doing here.
Semantically and abstractly, there's no reason to every not be able to override a property access in later versions like that, because it is so darned useful. Unfortunately, performance wise, it's hard to beat a language that guarantees structure layout and guarantees that x.y can be compiled into a single constant memory load instruction, and unfortunately, you can't just wave "compiler optimization" at the problem and make it go away (considered in isolation this seems like an obvious solution but as usual as it starts interacting with all the other features it gets much harder than the simple cases). The higher performance languages have a strong reason to give people ways to get guaranteed direct struct member accesses.
Though please note that if you "upgrade" anything from a field to a property, you need to recompile any dependencies. Otherwise they will obviously try to invoke the field that no longer exists, instead of calling the property methods.
Not if you need to implement some setter logic though, or want to reserve the option to do so in the future. And not if you want those instance variables to be available as JavaBean properties.
I haven't developed in Java in a long time, but public instance variables were a no-no when I did for these reasons.
In 1996, Java was pretty darn sexy. Managed runtimes in a high performance[1] language were an absolute revelation at the time.
It's absolutely true that as it evolved, Java grew to embrace the affects and aesthetics of its biggest customers (Enterprise backend coders). And that's not sexy at all. But at the time? We all thought this was going to be the systems language for the next century.
[1] Almost. At the time this email was written, the first JIT JVM was still a few months out from its early beta releases. But Gates could absolutely see where the wind was blowing.
It was about 10 years ago that the community agreed that it was the JVM that was successful. It's a platform with multiple viable languages. Scala obviously comes to mind. Kotlin is a somewhat mixed case because its popularity comes from the mobile world where you don't really have the JVM.
Java is not the most pleasant language for sure. It started as a dumbed-down as golang was (still is?) for years. It's still catching up with C++ (e.g. see all the Valhalla project discussions on HN). It certainly shows its age. It's not clear to me why so many people are still fixated on Java when solid alternatives have existed for years within the same ecosystem.
Kotlin is pretty popular on the server side too, and Kotlin (the same compiler) generates JVM bytecode for both mobile and server in the same way because Android very much has a JVM.
How could it catch up to C++? They are not even in the same category of languages, other than some surface level syntax, they are as different as they get.
> It's not like C++, where the template language is both Turing complete and the fastest way to summon Beelzebub from the depths of his infernal pit, and where you need a team of PhDs to decide which version of `auto_pointer` actually works the way you think it does.
Value types on the JVM have been described as "6 PhDs, knitted together". In C and C++, this is just struct.
> It's not Javascript, where the framework your front-end lead sold you on last week has already been superseded by the hot new thing.
You should stop spreading stuff like that, it's false. React has been the most popular frontend framework for 6 years at this point, and Express the most popular backend framework in JS for at least 8 years. The backwards compatibility of JS is at least as good as Java, ES5 and ES6 were great upgrades (a bit like Java 5 and 8 in a way).
I like Java and I think it's very important. I can say that without feeling the need to dismiss other languages that are as important as Java to the modern world.
But that is regarding the implementation/specification. For the users it will be two new keywords and .ref. It will even ease the language by healing the rift between primitives/objectsz
C++ has been used by lots of people without PhDs to great success. The language is not perfect, but for most people it's far from the hell that's described in the comment I replied to. Some people will complain about the AbstractFactoryBeanInterface in Java and say that it's hell, they are the minority. Same with C++.
I’m not saying that C++ needs PhDs to write, but it is one of the most complex languages out there. Even just basic usage is considerably hard (RAII, r/l-values, etc). Of course it is in part inherent in the system programming domain.
But Java is a trivial language comparatively, your mentioned complexity is user-generated.
> It lets a lot of innovation happen in other languages
Only if you're defining innovation as syntax and semantics to the language. Java has been the pinnacle and cutting edge of language implementation innovation decades - Sun/Oracle is/was the Bell Labs of VM and JIT research.
> It lets a lot of innovation happen in other languages, then takes the successful parts for itself
The only time I've ever had to use Java was for a computer science class, and I thought it was a solid language (pun intended), but I hated its half-assed attempt at operator overloading.
I think it's a major feature that's long overdue to be fully implemented in Java, because it's already used for some of Java's built-in classes and it's proven useful in many other programming languages.
Most of Java seems very well-thought-out to me, but for some reason they decided to add only some operator overloading, instead of planning ahead more.
I remember hearing somewhere that they were planning on adding operator overloading, but last I checked it didn't look like it was going anywhere.
Java chose not to implement (general) operator overloading because it's really hard to do right. We're left with just a fluent syntax for appending text to strings.
Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)
Python's operator overloading works remarkably well given that it has a very simple model (always look to the left hand side to decide how to interpret the operator.) C++ on the other hand ought to make anybody skeptical of the idea, but C++ would make anybody thoughtful and sensitive question the idea of computers entirely.
> Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)
Well, neither Java, Common Lisp nor ALGOL60 support operator overloading, so there does seem to be a trend there.
Common Lisp in fact, as most lisps, has no support for "operators" in the infix sense at all. If you have a need for a very algebra-heavy portion in your program (say, a linear algebra library), the best idea would be to define a DSL for that particular algebra - especially since this will give you much more control over efficient evaluation than using the built-in evaluation order.
A good example of the limitations of simplistic operator overloading is matrix algebra: A+B•C can be computed efficiently as a ternary operation, more efficiently than doing A+B then multiplying the result by C. Now of course, you can implement this in C++ by having operator+() return some kind of matrix_addition object, and then defining the efficient operations in operator*(matrix_addition, matrix) etc, but that is much more roundabout than defining a simple addAndMul(A,B,C), or an explicit optimizing DSL.
The lack of operator overloading makes it impossible to implement new numeric types in a consistent way. For example imaginary numbers or numbers with units.
You can make the case that both intX (x=16, 32, 64) and floating point are bad for general purpose computing. Like Common LISP and Python, Java has bigints and rationals in the stdlib, but Java makes you use non-operator syntax to get at them. Contrast that to Clojure which puts them on your fingertips.
Java has always been in a strange place of not deciding if it wants to be a systems or application language. (The standard architecture is that demanding systems, say video games, are written in both a systems language and a scripting language. A Python coder feels smart when the incorporate, say, number is written in C or FORTRAN but Java’s xenophobia makes that feel like a personal failure. Java is ‘good enough’ for applications programming that you might find something like Spring or Guava gives you all the dynamism you need with less hassle than adding an embedded scripting language like Groovy or Clojure.)
If you are serious about using the JVM, I would suggest Kotlin or Scala as a better alternative to Java as they have all the libraries and greatness of the JVM but they have less of the historical baggage that Java brings with it.
Both can be written in a Java like fashion to start, and have 100% interop with Java (you can mix the languages in projects) so the learning curve is pretty alright.
JDK 17 has most of the good features of Scala and Kotlin.
Scala seems to be designed so that you can write a short book with very fluent and natural looking demos. Make a small deviation from that and there is nothing fluent or natural about it.
Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries. (It's a similar problem to Typescript.)
Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit. I'd point to Clojure as a language that is radically different from Java AND that takes advantage of the strengths of the JVM to be worth the cognitive load of having to know both a new and old language to be productive.
> JDK 17 has most of the good features of Scala and Kotlin.
I keep reading on HN that "Kotlin isn't much better than Java X". Having used Java and Kotlin (mainly targeting JVM) full-time for 6 years, this doesn't match my experience at all.
Here are some of my favorite Kotlin improvements over Java that I leverage all the time:
* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)
* Local variables are final by default ("val")
* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)
* Much improved collection API
* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)
* Extension functions (incredibly useful in practice)
* Much better DSL capabilities (great for UIs, generating HTML, etc.)
* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)
* Great serialization support (kotlinx.serialization)
* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)
* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)
Although I'm glad to see that Java is still improving, it will never get close to Kotlin. The most obvious reason is that many of Java's early design decisions were revised in Kotlin but are impossible or impractical to revise in Java. Also, Java carries the burden of being a platform language, whereas Kotlin can focus on being the best possible application language.
These days, I only use Java for libraries intended to be used from languages other than just Kotlin. In that case, I don't want to force Kotlin on users (stdlib dependency, debugging, etc.).
> Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries.
One of the big benefits of Kotlin is that if you know Java, you pretty much already know Kotlin, too. A good Java dev can get spun up on the basics in a day or two.
> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit.
Kotlin provides a ton of ergonomic features that I absolutely adore. Named parameters and default parameter values alone save me tens or hundreds of lines of code.
I think of Kotlin as what would happen if a Java developer looked at Javascript and asked "okay, but what if this didn't suck?"
How so? While yes Android is one of the most common uses at the moment for Kotlin (thanks to Google making it a first class supported language for the platform) it is still dependent on the JVM, thus can do anything that Java Can.
> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit
Sorry but "no real benefit" seems to come from a position of ignorance.
I can only talk about Scala which I know pretty well.
While Clojure is a radical departure from Java, being a Lisp, Scala is a departure thanks to its type system and features that help you writing more functional (as in functional programming) code. And I mean this in a good way: it helps you avoid mutations and side-effects, while giving you the freedom to use good old OOP if you wish so. In general it provides tools that help you better express your intent that Java doesn't have.
I think that Java has too much baggage to ever become as good as Scala, especially on the type system side, and, in addition, Scala is also moving forward.
Also don't forget Scala.js [1], which is rock-solid and just plain amazing, and Scala Native [2].
> JDK 17 has most of the good features of Scala and Kotlin.
I'd be sooo happy if that were the case, but sadly, it's not. From the point of view of Scala, I still see many features missing. Roughly in the order of importance:
* Immutable persistent collections in the standard library (and thus lingua franca in the libraries). Just so much better than mutable collections. Way less headache. Once you start using them, you realize how rarely you actually need mutable ones.
* Pattern matching. Java will surely improve on what is currently available. But why wait? It may take a long time.
* Sophisticated string interpolation. It's powerful, and yet is still easy to read. Again, Java is on its way to get it, but with Scala you can have it right now.
* Type Classes. Sometimes it is very good design to separate data from functionality. Java designers (Brian Goetz IIRC) mention they would like to get this eventually. Scala has an interesting design of Type Classes -- "givens" -- which is also modular (in contrast to Haskell). Scala also has an elegant mechanism for Type Class derivation using the "derives" clause.
https://docs.scala-lang.org/scala3/reference/contextual/deri...
* for-comprehension syntax and IO/Task/ZIO for async programming. Project Loom still hasn't delivered. But Scala has you covered. It gives you for-comprehension syntax, so that you don't have to suffer from nested callback hell. And there are many great libraries for async programming, like ZIO or Cats Effect. These are easier to work with, compared to other Futures from various Java libraries, because they're lazy, not eager. for-comprehension syntax is also useful for other things, it's just that async is the typical usecase.
Higher-kinded types. Not everything has to be super fancy higher-kinded type-level craziness. And very often one gets away without needing to use higher-kinded types and that's good (just as often a solution without parametric polymorphism aka generics is enough). But other times it's awesome to have this power of abstractions. Typically, but not only in libraries.
* Object. Sometimes you just need to have an object (which might implement an interface/class/trait). But Scala doesn't force you to create a whole class, if you only even want just one instance anyway. A small thing, but way more elegant.
But I'm really happy to see Java/JVM improve. The 17 release has brought some great features, but in the language level (records, embryonic pattern-matching, ...) and the VM level (GCs in particular). We all benefit more or less directly, one way or the other.
Also, Scala’s optional null checking (where null becomes a type that is not at the bottom of the type hierarchy) is really cool!
All in all, I do find using Scala can absolutely worth it, but I really don’t feel it with Kotlin. It feels like a watered down Scala, and add to that where modern Java currently is, I feel it is not needed.
Also Java doesn't run on android? Not 17 anyway...
I guess you could try to argue mobile is bad or something, but you get Kotlin not JDK on mobile.
Yes, Clojure is probably better, but on the flip side as a developer knowing Java 8 and Kotlin is better than knowing Clojure and JDK 17. Perhaps you can point to some salaries here but Java developers are not in short supply, if you wanted to play that game there are better languages for more lucrative payout (assuming you can even get them, these tend to be boutique shops not generally hiring publicly)
The fellowship of Kotlin at Mountain View will ensure that Android Java stays as it is, any further improvement might happen only if the community is very vocal about any Java library on Maven Central that fails to target Android.
However they will most likely assign an intern to port it to Kotlin than improve Java's support on Android.
Scala has just as much historical baggage imo. It's community is split between functional zealots and "better java". You also have the Scala 2/3 split that is currently going on and just the general complexity of the language makes it not so appealing.
IMO if you're serious about using the JVM you should be using Java 17 and following the latest version. Kotlin is usable, but it doesn't bring that much more to that table other than longer compile times.
The community split is what makes Scala better in my opinion. The fact that you can have the split between functional first and better java people is a nice thing to see over Java where if you want to do functional programming, you are a second class citizen.
I was really into Scala ten years ago, but felt that a "Scala--" might be more accessible to most devs and hurt Scala adoption. Lo and behold, we got Kotlin.
But isn't the great thing about using the JVM supposed to be not using Java?
Or at least the perf advantages it brings. Java has nice stuff today maybe but one could argue that it is primarily defending market share that caused Oracle to move forward with its language updates.
I'm inclined to say the opposite, the more the JVM stays healthy and the stronger the third party ecosystem the more likely it doesn't become a 'dead' language like COBOL or FORTAN (not dead but in terms of marketshare).
They may have a little less of the historical baggage, but that's still a lot of baggage. Same goes for F#. It's a shame that three of the best programming languages in existence are built on top of Java and C#, instead of doing their own thing. Admittedly their VMs are mostly fantastic, but trying to reuse libraries and language constructs has just created more problems.
And lets not forget that the JVM runs all kinds of things that aren't Java. So Java devs who get bored can write a few packages in whatever new hotness they like until either they're sated, Java catches up, or all new development moves over.
Because there is no way to define such a number. We only “know” as per Brook’s famous paper, No silver bullets that this number has not passed a cumulative value of 10 in like 3 decades now, since the first programming languages. The only way to increase productivity is through code reuse - and given the flourishing JVM ecosystem, Java has that as a big plus.
One of the biggest turn off to me of java has always been the poor quality of many java apps. Especially on mac, you know when its a java app vs native.
And when you leave aside Java (the language) and consider the jvm platform broader ecosystem with all the various interoperable languages like kotlin, scala, clojure… it’s a huge space.
I understand some level of heathy criticism but, I don’t really understand the level of hate the jvm gets.
When you look at recent and upcoming features, a lot of the complaints about it being “heavy” are being directly addressed.
There is a wide spectrum of age, experience, and attitude in the programming population. Hot take: I am guessing that a lot of the noisy hating and hemming and hawing comes from the newer, less experienced cohort, we just can't tell on the Internet and so the perception skews that a significant fraction of all programmers think this way. I am basing this on having been there, done that, where I would scoff with indignation at any software not written in hand-optimized assembler with a bunch of unnecessary (to my newbie self) layers of abstraction.
JVM is not really that heavy since the Intel released "Core i" series processors. Also, JVM uses its resources well. It's one of the best engineered software artifacts if you ask me.
I really enjoyed using the language back then, and will not hesitate to restart if there's a scenario which would fit the bill to use it.
I really dislike Java but I like the JVM and am a big fan of clojure. I don’t trust/like Oracle, and maybe it’s just confirmation bias, but I hear much more along these lines than people who just dislike the jvm.
It's not heavy, it's the syndrome where wild success gets you associated with the good and the bad.
Enterprise Java is extremely slow, over-engineered, complex, that's where the majority of hate comes from. Then they had their security debacle, coupled with a couple strange roadmap changes, and being bought out by Oracle, an unpopular company for different reasons.
Java the language then sat mired by the corporate world and went nowhere for almost a decade (java 6, 7, 8).
Oh, and don't forget Billy, wonder why C# has made such a comeback in recent years. It's a nice(r) more modern language, it's not that great, come on...and I say this currently working in it full time.
So yeah political prop and the normal stuff popularity brings with it. It has also happened to JS too...
>I do not only think he was right to lose sleep over it: I think Java delivered.
He's not losing sleep over Java, the language, becoming popular. He's losing sleep over the threat to the business (at the time, operating systems). I think if you consider Microsoft's market cap ($2.39 trillion this morning), despite some bumps along the way, Microsoft protected and grew its value.
It's not to say Java hasn't enabled monetization. But if you have "billions of Java smartcards" and the long tail of those installs don't create much value or affect Microsoft's bottom line, then, to Bill, that particular point is moot.
I think Gates didn't have anything to worry about regarding Java... at the end of the day, the company that created it went under the water in 2009. Java as a technology was great, but as a business just didn't cut it.
Nobody knew that at the time. 2000 is the peak for both for companies before the dotcom bust and Sun Microsystems had $18.3 billion in revenue, not that far behind Microsoft's $22.9 billion in revenue.
I had a summer job programming Java when it was still in beta.
I remember getting into an argument in the men's room of the basement of center Ithaca with two guys who were saying that Java was overhyped and I was saying "believe the hype"
That time I was right.
Java was one of the first programming languages to be specified by adults. (e.g. they didn't know how to specify PL/I and make it work, C worked by accident, ...) When researchers realized the memory model was broken the first instinct of the Java creators was "let's fix it" while other languages first made excuses and waited a decade + for a "fix"
The original promise of Java was cross-platform user-facing visual apps. (Which is why Gates was scared of it.) This promise certainly failed to deliver.
Instead Java is now Cobol 2.0, but nobody lost sleep over this fact.
There was the idea that Java Beans would work like the COM model does for Visual Basic and it would be straightforward to build a GUI to build form GUIs.
That never happened, but few visual UI builders have come close to what Visual Basic was in 1995.
But it isn't necessarily there strictly on the merits of the language. Sun put a billion dollars of marketing into it. Managers, directors and others with expectation of ever programming were taking Java courses because it was going to change everything.
It was going to run on every device in my kitchen, and they were all going to talk to each other. Instead the first niche it found was J2EE, and that "write once, run anywhere" was a bit comical, because who swaps out the OS on their server?
It was apparently good enough to be the choice for Android and similar, but that was much later.
It's really difficult to describe how people -- especially non programmers -- bought into the hype surrounding Java.
I've since seen a bit of that hype around some things, but never to that extent: XML, SPA, a strange obsession with tiled widgets.
> It was going to run on every device in my kitchen, and they were all going to talk to each other. Instead the first niche it found was J2EE
The first niche was applets. A managed language with a batteries-included library, familiar syntax and cross-platform GUI story was a new thing at the time.
I honestly wonder what made java so prevalent server side. JVM jit speed and memory safety are good arguments but the rest was not so shiny. Remember the J2EE era, it was horrible and the reason java got there seems, IMO, to be heavy marketing.
ps: I forgot, the JVM spec was a good thing, it made a lot of things sound for people, so easier deployments and less inconsistencies.
Not exactly a java fan here, but java targeted the enormous block of people writing in C/C++ for their enterprise servers, and gave them "machine-independence". Being able to upgrade your server, and not having to rewrite your app, was huge. The competition wasn't PHP, at the time; it was C/C++.
It's interesting in today's era of Rust, that people think of Java as failing to replace C++; in practice, it was only 90% successful, and managed to replace the vast majority of cases where people did use it.
About the only things that didn't get replaced were (some) desktop gui apps, and apps that were so tiny that they weren't worth the launch of the JVM.
Also - you have to remember that in the late 90's / early 2000's, Windows was at peak dominance, nearly 100% of developers at work were stuck with a Windows desktop to develop on. At the same time nearly all servers were linux or maybe solaris. So how are you going to develop on Windows and deploy on Unix? C++ was a nightmare, scripting languages were far from ready ... Java was really transformational in how it gave a complete, totally portable standard library in a mature language framework. All these things are take for granted today.
Yeah I remember steele saying they wanted to make c++ move toward lisp.
But you got me curious.. what kind of backend code was written in c++ ? did people write server side logic in it ? I remember seeing some Oracle C code but it felt like a strange thing and not a c/c++ land. But to be honest that's not my world.
PHP was a scripting language that got big because my aunt could create a “website” with it and host it for pennies. If anything, its popularity was the only surprising thing.
The JVM on the other hand was not chosen by Google, Apple, Alibaba and basically the majority of web servers to be the base stone of their functionality by accident.
But the server side position of java is already a strange notion of success, as mentioned above java wasn't meant to live there. Hence the parallel with PHP, its mod_php was the reason admins installed it on servers, because it was easier and leaner (compared to mod_perl), a happy accident.
Indeed. Reminds me of an early 1997 interview I had about the future of Java, when it was trying hard to displace JavaScript in the browser (swing gui and such) and flash was already starting to beat it out.
https://wanderingstan.com/netguide-interview-february-1997
I still wonder what would have happened if Java decided to take Javascript's approach by giving access to the DOM, rather than an entirely separate GUI mode.
Things like Google Maps and Gmail came as something of a shock. They were near-desktop-level apps entirely within the browser. That meant JS, not because of the language but because it was the only cross-platform system that gave access. It should have been possible to do that for Java as well, but they never really tried.
>Java would be the same success as PHP .. it might be everywhere but due to all kinds of side forces.
People like you that complain about C,PHP,Java etc forget the history , your favorite cool language did not exist at that time or if it existed had probably a lot of downsides. Also many complainers do not work with the languages and repeat like parrots something they read. I would love to get some perfect programming language, something with more maths in it that forces thinking of solutions and less glueing shit together or rewriting X and CoolLang for my CV.
I rarely run into client side programs being better (or even interesting) due to java/jvm. Eclipse was quite a clusterf.. (at least when I left that side in 2008). Note that I'm not anti Java. I just think its course was fluctuating across time and "success" is really a strange term. The rare times people were happy about Java was the advanced JIT.
Minecraft Java Edition IMO has this giant community because it is easy to mod and this is because of Java since the devs did not create modding tools. I am sure it was much easy for one person to develop such a complex game in a manged language too , from my experience with desktop apps the ones I made in Adobe AIR using AS3 had a lot fewer bugs and fewer support tickets and we got cross platform too.
I also worked on a Java screen sharing in browser web conference solution back when this was not possible with native stuff or with Flash, if you understood the language you could get good performance.
>Also please don't make comments on me assuming I'm parroting, that would be nice :)
I did not said you specifically but I doubt you have years of experience in PHP and Java but let me know How what was the better alternative back then? Writing webpackes in C or some proprietary language with a paid compiler? Was there something much better and for some reason people used PHp because was cool and were tons of "write in PHP zelots"?
From my memory the LAMP stack was free and was easy to start with, Java was much more productive then the alternatives and it had good tools, books and documentation. I can't think at any good alternative except the late C# but Microsoft was to incompetent to do the right thing and kept it proprietary and Windows only for a long time.
I don't think the word productive ever reached my brain when I was learning websphere. Annotation driven servlets never felt exciting or clean (unlike the post closure / decorator era where you can write stuff clearly and rapidly). I'm calling for a winner language here, I'm saying praising java position is a strange notion of success, it's everywhere indeed, but for what reasons ?
> don't think the word productive ever reached my brain when I was learning websphere.
So what else was more productive? you said PHP is not the answer and "websphere" is not Java the language or Java the ecosystem (think of the many Java libraries out there and at the good enough Java standard library compared to others)
"How is Java not one of the biggest success story ever for a programming language?"
The language is an enormous success. But in one key area it did not succeed in popularity: in building cross-platform desktop GUI apps.
Many businesses did use it for building internal GUI desktop apps. However, Java did not find much success in consumer-facing desktop apps - despite the considerable effort made to encourage developers use Java for this purpose. For example, in the late 1990s Java had it's own GUI look-and-feel called 'Flush 3D'. It was designed to be consistent across operating systems.[1]
But Java desktop apps earned the reputation as being slow and unresponsive, not fast and nimble. The Java applets that ran in the browser were no better. Today, perhaps Java will find success creating consumer-facing, high-performance applications on web pages using WebAssembly?
I think much of the hate for java came from non-programmers, or future programmers who had to deal with runtime issues. For a long time if an app was written in Java it meant it was going to be a pain at some point.
I'd say it runs distant descendants of Java. The fact that Gates lost sleep not only over Java, but over JavaBeans is undeniably funny. JavaBeans delivered frustration and secure employment for a legion of developers.
Just a couple of weeks ago we got a reminder of how horrible early Enterprise Java was, with the Log4j exploit. The kind of thing everyone goes, "why would they think that was a good idea?" today, but the answer then was "almost everyone, certainly everyone who makes decisions..."
In a very indirect way; leveraging its popularity, and coming on the heels of Apple to create a captive audience for their ad networks and surveillance machinery, Google used Java to spring up a developer base for Android, which ate away at the use of MS product outside of the US like iOS did stateside.
I’m COBOL “certified” for whatever iota that’s worth. I don’t think I would say “all the time.” There are legacy systems that are being ported to JVM that remain in COBOL because it “just werx” especially for batch processing.
But I have no experience in banks, but in the military and government. So maybe I’m wrong about what they’re doing, but in my experience it was either all being moved to Java or at least JVM just because some of the physical hardware was getting too old to maintain.
I actually think a lot of the new C-family “modern” languages could learn a couple of things from COBOL. It really makes you be explicit about data.
Those things were almost all things that you could ignore if you weren't trying to specifically make a program for Windows, and that if you were trying to make a program specifically for Windows made it a lot easier and made the resulting program a lot better as a Windows program.
If Sun had blessed Microsoft's approach and encouraged Apple to do similar for Mac and done similar themselves for Solaris and encouraged someone to do similar for Linux then Java could have become a major language for mainstream desktop applications rivaling C/C++ or perhaps even becoming the most common language for such development.
But Sun didn't want you to be able to write for Windows or Mac or Linux using Java. They wanted you to write for the Java platform which happened to run on Windows and Mac and Linux.
And so Java desktop apps were almost always inferior to desktop apps written in C/C++/Objective C that could make better use of the native GUI and other facilities and did not stand out as some weird ugly alien thing.
They altered things in the java.* namespace [1], making it easy for developers to make things incompatible, as well as leaving out support for cross-platform enabling stuff like JNI and RMI. I can't read those actions as in good faith.
J++ was the final straw for me. I realized it’s sole purpose was to screw over Java. Not to be useful.
Spent last 20 years avoiding Microsoft tech after that.
> Unfortunely the new generation seems not to have any issue with Android Java being Google's J++.
Perhaps that's because it is not? Google aren't adding packages to the java.* namespace, and the language is 100% compatible with Oracle's compiler. Only the bytecode format and runtime are different, but that's no worse than how J2ME was, with SonyEricsson/Samsung/$OEM having their own custom packages (which Sun/Oracle approved of.)
edit: preempting another argument: limiting support to an old version of software/language spec is not a crime, though I'd be happy if Apple could be compelled to update the GPL software they bundle to the latest version (:
> Google aren't adding packages to the java.* namespace, and the language is 100% compatible with Oracle's compiler.
It just shows how little experience you have porting anything beyond Java 7 into Android Java.
> Only the bytecode format and runtime are different, but that's no worse than how J2ME was, with SonyEricsson/Samsung/$OEM having their own custom packages (which Sun/Oracle approved of.)
Yet that is the whole sales pitch of Android that it isn't as fragmented as J2ME was.
Also you missed the part of SavaJe OS being on the path for making SE available on mobile and Java 8 introduced Embedded Compact Profiles, whose APIs aren't fully available on Android to this day.
They lie to the public that they use OpenJDK, when the truth mirrored on Gerrit code reviews is that they cherry pick features, tracking down which Android version supports what from Standard Java is a painful detective work.
To add to it, the fellowship of Kotlin cleverly misuses their broken Android Java to sell Kotlin features, instead of comparing it with the real deal.
None of those are wrong but I think they're missing the point slightly. Bill Gates seemed concerned that Java represented either some existential threat to MS or at least something that would heavily dent their bottom line and pierce their dominance of the desktop market. And really it turned out to neither. Java is indeed very popular and undeniably a successful language + ecosystem, but I don't think what it has become was what Gates had feared.
I'd be interested to see if, knowing how it all played out, Bill Gates now believes he was right to be fretting about Java back then. Given the position Microsoft is in today, maintaining its hold on the desktop with Windows and with a strong cloud offering in Azure, I think he'd answer "no, I wasn't".
> I'd also add: it's kinda funny to see so many programmers hating on Java and thinking that, somehow, Java is dead or dying, yet on a daily basis they'll use one of the JetBrains tools, written in Java, to work on their "non Java" code.
And even JetBrains is working on a language to replace Java (which yes, runs on the JVM, but it also runs not on the JVM).
Java is a fine language, and one that I have the most experience with. I'm glad it's there, but I also think that increasingly it will not be the default choice for greenfield projects. That is typically what people mean by a dying language: it's only used for projects in maintenance mode.
It actually failed at what Bill Gates feared it would to: it is pervasive, but not a competition to Windows and the Windows GUI stack. Smartcards were never MS's target market, and nobody was yet thinking about smartphones.
The move to server-based experiences made the Mac competitive and made iOS wildly useful despite not bundling jvm.
I think what most helped it was that it was the common language against early commercially-supported app servers from big vendors.
BSD started as a Pascal compiler for Unix and enabled a community of researchers to work with a common language on machines more accessible than those from DEC.
Bill was right that consumer-oriented products with server-side software had Java as the wind at their backs.
Exactly, it was the Web that threatened Microsoft. But Java is not the only player that could have dominated in the backend. Also, the backend lost its importance to the frontend, where the HTML/JavaScript/CSS (both in the browser and as Electron) stack rules.
Actually, people were, even the non-technical everyday Joe. I remember a sales guy commenting once at a beginning of a meeting as he pulled out his PDA and set his oversized cell on the table "I'm just waiting for the day they combine these together so I only have to carry one of these". I think this would have been 1998 or 99, but people talked about "PDA phones" for quite some time before the iPhone appeared on the scene. The technology just wasn't there, and the CE based PDAs were clunky, nearly useless.
Except Java never truly threatened the Windows OS. Nathan's reply back was on point: Java expanded into some voids but didn't kill Windows.
Android beat Windows mobile because MS pissed away their advantage (they had a mobile OS before either Android or iOS but it sucked) and Windows mobile was too little, too late. Nothing to do with Java really.
Well in the context of the emails: no, Java failed at delivering.
Solaris OS is now history and many programming language competitors raised and won over it at its own game in all areas but android, although it was an industry leader for quite long time its time is over and now it is mainly corporative legacy.
Even as general programming language Python and JavaScript took over, and in dedicated areas like webservers it’s been long since Java’s time is gone. The analysis in the replies is correct.
> Even as general programming language Python and JavaScript took over, and in dedicated areas like webservers it’s been long since Java’s time is gone.
I don't think this is true. Yes in the US in the startups Python, RoR and JS are more popular but in the enterprise Java (and .Net to some extent) still rules. In India right now the demand for Java programmers is sky high. Salaries for Java programmers have increased by 100% or more in the past 6 months or so. Actually overall salaries for programmers have increased a lot in India in the past 6 months due to very high outsourcing demand but Java is in especially high demand.
Note: I am in the outsourcing industry since past 12 years.
I’ve been part of companies which decide to outsource and very often what they send to India is the legacy code no one wants in research labs or headquarters, so it makes all sense to me.
Yes, Java is successful, both as a language and as a runtime. Obviously. You can't argue with billions of Android phones. Or the (possible?) news that FB has already given up and will be simply using Android for Meta.
I don't think a lot of folks here were around at the time to remember that a lot of the early hype around Java and the Web were both about unseating Microsoft.
Microsoft has thrived.
Sun is in the dustbin of history. Yes, mountains of cool tech came out of Sun, but as a company, as a existential threat to MS? Java didn't deliver.
That's not to say it couldn't have, had Sun managed it differently. But if Sun had managed it differently, it probably wouldn't have been the success that it is as a technology.
Just a note but android doesn’t run javaTM, especially not in a runtime. It compiles Google’s decade old java version AOT and native code gets executed on mobile phones.
Until iPhone, Java on Linux was the standard for smartphones. Was that Java Micro editon? I think the handset makers actually licensed Java/JDK/JVM, not sure it cost money or control or what.
Without cloning the language, Alphabet would never have been able to standardize non-Apple phones under one advertising platform.
C# isn't, it's highly successful but locked into one ecosystem. .NET Core is very new (by enterprise standards) and hasn't yet had time to supplant usecases for Java.
Go is even newer and even less successful vs Java.
Firstly it's awful in large business logic heavy programs. It's getting better with generics but it's error handling and module structure mean it's very ill-suited to the sort of software Java thrives in.
I think the only real competitor to Java (both on Android and backend/desktop) is Kotlin.
FWIW, there is no ".NET Core" anymore. Now its all just ".NET", whether or not you're running it on Windows or Linux. Theoretically its all just the same from the application's perspective, there's no separate toolchain or library.
While that might be true now enterprise is still running stuff on .NET 2.X and .NET 4.X is still dominant overall.
It will be years until enterprise shops are caught up to where .NET is atm, that is just the way of things.
FWIW it's not much better in Java-land. Most enterprise shops have apps they refuse to invest in upgrading off of Java 6. Java 8 still has huge share though thankfully in the last few years Java 11 is catching on.
I like Java and C# a lot, they appeal to me above the rest of the langs for practical reasons but I don't miss distancing myself from actual enterprise development - that is where passion goes to die.
I used to think like that just to realize that the main two variables to guess the language a project got started are the industry and the year the coding began.
For example, projects that got started 10 years ago are very likely to have got in Java started (as it still even was the main programming language teacher at universities.)
New projects are more likely to get started in python, typescript, go or even c++ just depending the industry. It’s been a while since I do not see a new brand project starting in Java.
Someone may dismiss my opinion with a statistic, and it will also be fine. I don’t think Java did endanger Microsoft,
So wikipedia says that it is, but honestly I am not an expert so let's just set that aside for argument's sake unless someone can definitively say one way or another. But it's definitely in SIM cards, which are indeed carried and used by billions daily
I'm inclined to cite that saying where there are those programming languages everybody complains about, and those that nobody is using. Doesn't hold for HN, though ;)
I hate on Java because it's terrible to program in and seems to make it harder to actually solve problems, between the store-brand version of object orientation that it's based on and the mountains of useless abstraction that begets. There's a reason its relative popularity is on a downward trend [0] - my generation of programmers were taught Java in college and learned to hate it. Though I will say that its narrowness and structure make it the best choice for outsourcing/getting the most out of the cheapest development resources. Just not something that I want to deal with.
Tiobe is next to useless, and Java doesn’t beget useless abstraction - it is entirely up to you how you write your code. Also, while it is indeed started out as an OOP language, it is a mixed paradigm one nowadays (just as almost all languages are) — you are entirely free to program it in a much more functional way. It is especially freeing with the new records.
It’s true java the technology is actually pretty good. Java the culture on the other hand… It’s probably less to do with the language itself rather the fact it’s used mostly for boneheaded enterprise crud
Java has as many developers as a smaller country, ranging from the numerous enterprise domain (you mention) to robotics, to HFT. The culture between these are really distinct between them.
Google says there are 7 million java devs globally. Lets put number of robotics/hft java devs at 100k which seems rather generous. So what are the remaining 98% working on?
How did Sun manage to get so much hype around Java?
There can't be many things in tech which have had that kind of PR achievement, especially if you move away from flashy user-facing things like iPhones and Playstations.
Java and its compiler were free and easy to install into CS department labs.
There was a huge hype train around object-oriented development being the way that somewhat continues to this day. OO was all the rage along with the "Design Patterns" book. OO hype in the enterprise also seemed to drive CS departments to use Java for just about all classes because it was "pragmatic" and a "real" job skill to give students.
I mainly remember being excited about garbage collection.
As sibling says: applets. They were there from launch, and they offered the never-before-seen combination of "write once, run anywhere" and zero-installation and sandboxed code.
They were kind of clunky, but anyone who had the responsibility of managing a client-server app across a fleet of PCs would have had a lightbulb go on over their head on seeing that.
The university hype seems to have been real as well; I was being taught Java in late 1997, when it had only launched in 1996 and was maybe on version 1.1? Previous years were taught object orientation through Modula-3, and you really don't see a lot of that these days. Java offers the decisive advantage of braces rather than BEGIN..END.
100% of the hype around Java was that it was "write once, run anywhere". That was the marketing slogan for it, after all. And remember, in the 90s cross-platform was HARD. We had Windows NT, Windows 98, Mac OS, Linux, Unix, big endian, little endian, weird filesystems (resource fork, anyone?). gcc wasn't even cross-platform, so good luck cross-compiling things. You had to somehow write one C++ codebase that would compile in Metrowerks CodeWarrior, MS Visual Studio, GCC, and across different endian CPUs, or compilers with different definitions for int and long. Plus, the standard libraries for these systems were radically different.
No one even tried to solve this problem until Java came along and made it performant through bytecode JIT.
Richard Feldman (Elm) analyzes why programming languages become popular and says Java is unique. It became popular because Sun spent 100's of millions of dollars promoting it, even after the dot com crash. Others like Ruby, had a killer app.
His thesis is object oriented programming wasn't inevitable or is the best way to program. It was an accident of history that OOP became so popular.
Why Isn't Functional Programming the Norm? – Richard Feldman
Another Java tidbit is that Miguel de Icaza (Gnome, Mono) really wanted an open source higher level language on Linux so he approached Sun about Java and they wouldn't work with him, so he settled on C# and is probably the man most responsible for the move to cross platform C# and .NET (dotnetcore, v5)
Java had a combination of things that made it really interesting at the time; the tooling was free, it had automatic memory management, it had easily distributable apps, it had some sort of multi-platform UI (even if it wasn't very good). Nothing else at the time really satisfied all of that. It also had problems, of course (in particular, it was very slow at first, and Java 1.0 had a lot of weird baggage that got fixed, too late, in 1.1 and hung around for years), but it really was something interesting at the time.
Others have mentioned that the tooling was free, but I think younger folks might easily underestimate how big of a factor this was. In 2000 I was blown away that I could download NetBeans for free and learn the language just by reading free documentation on Sun’s website. Yes, there were already free languages that had significant mindshare (e.g. Perl), but Java was backed by a big name company and came with pretty sophisticated GUI and networking libraries baked in. Perl was associated with ‘scripting’, whereas Java was marketed as a serious language for writing serious applications. Compared to the free C++ dev environments available at the time it was mind blowing.
I think part of it was that Java promised Unix-y/open systems to stay around when in 1995 it seemed like Windows would dominate server-side programming, in addition to the desktop.
Lots of marketing backed by lots of money..
I remember trying to use Java in the Java2 days when every magazine would tell you how it's great, but the reality was that I was wasting a lot of time working around bugs in the Java libraries (and once even a bug in the JVM itself).
One way was Java applets. Back in the mid-nineties, applets were the only way to make web pages meaningfully flashy and interactive. They pioneered the space later conquered by Flash.
Parity yes, but documentation and support not so much. Using Java on Azure always felt like being Microsoft's red headed step child when compared to C#, and for good reason since C# is of course a Microsoft Language.
I don't fault Azure to much on this, but it did leave my team annoyed a lot of the time.
I think it depends. .NET on UNIX has allowed it to survive in some places. I don't think I would still be a .NET developer if it wouldn't have happened. It's far easier to sell .NET as a technology to upper management now than we can deploy it on Linux servers with no Windows Server licenses cost.
And even though developing on .NET is fun for a lot of developers, using Windows Server is definetly not.
While on others the rewrite required to move from .NET Framework into Core, while leaving 20 years of Windows only libraries behind has prompted several polyglot shops to jump ship.
I have done two such migration projects.
The reference to Sitecore was an example of one of the strongest .NET CMS on the enterprise space that now is having a portfolio based on .NET, Java and NodeJS.
Microsoft always behaves as if rewrites weren't a cost center, but they are and with Core, alongside the whole desktop mess, many have reached their rewrite budget with Microsoft technologies.
I've only heard about him as a patent troll before, but apparently he wears many hats. A mathematician, a photographer, a cook, at least dabbler in biology, astronomy, and other scientific fields. An interesting character for sure.
I think he did: an OS agnostic web means people choose OS based on other factors. Obviously price is one, but features is another. And he points out that winning on price is actually the same as losing (and Sun's sale to Oracle appears to confirm this). But can anyone name exciting new features in Windows 11? Or Windows Vista?
In some sense the web enabled smartphones, but unlike Sun, Google has a profit strategy for their cheap OS. And the patents and wireless regulations put a high barrier on new entrants, which MS was late to and had to acquire Nokia to enter. And again, does anyone remember MS Mobile's killer features?
for those who do not have a twitter account (twitter won't let me load all the images without asking me to log in) or just want a textual version / transcript.
Text version in a website can also be found here about two pages down under "Appendix: Comes vs. Microsoft – exhibit plex_5803, as text":
Technically speaking (so ignoring Oracle), Java the language is actually pretty good. When I took a MOOC and a Data Structures course that were all Java, I actually enjoyed writing Java. It’s verbose, but very straightforward to work with once it clicks, and a pretty powerful language.
My first two full-time dev jobs were at Java shops (one was about ~100 employees, the other was Chase), and that’s where I developed a severe distaste for the ecosystem. Getters and setters everywhere, dependency injection with Spring (I know there are alternatives, but Spring seems the most popular), so much convoluted and over-engineered garbage. Wrestling with that nonsense was one of the triggers for a bout of depression last year.
Also last year, I moved to Elixir and never looked back.
Man feel you. A few years ago I got out of the Spring swamp, and worked at a shop using a different framework, but still in Java. It got rid of almost all the bad things about the Java ecosystem, and it was so liberating! Last year I was back in the spring swamp again and I couldn't stand it! Glad to hear it's not just me
I think its important to sepate Java the language from JVM runtime
Likes of Kotlin (and controversially Scala) do quite well on it and solve many of the ugly deficiencies of Java
Its also probably important to separate latest Java (which is improving) from enterprise Java out there which usually feels like an archeology dig with decades of boilerplate and rubbish and terrible code
Currently in an enteprise java team and hate my life and regreting moving away from Kotlin+Springboot team.
Nathan Myhrvold's reply is interesting, 20 years later and windows is a pretty easy experience now. Games on Xbox is massive, though I'm sad that they didn't embrace VR. Playstation seems to have outflanked them there.
Their mobile game isn't really there though, but I'm not sure if they care, and it seems like the vacuum that java was expanding into was too big to leave be, hence the c#.
They tried to get a foothold in mobile (even bought Nokia’s mobile phone business), they just didn’t succeed.
Given how long Windows CE was around and then whatever they called the subsequent mobile focused OSes, I’m sure they did care while they still had a shot, but Android ate their lunch. Probably deserved to IMO, in the limited mobile development I’ve done Android was an easier platform to develop for.
10-15 years later, Microsoft is adopting Android for a Surface device.
I spent the 2000's writing a lot of java servlets with a smattering of JSP and a little bit of Android. I spent the first few years of the 2010's doing multiple Android apps. Java as a language is verbose but overall isn't that bad. The problem is enterprises love patterns and love ceremony and boilerplate and so that became the defacto way to write it, which then got cargo culted everywhere else.
Over my 20+ year career I see programmers demanding their tools give them the freedom to shoot themselves in the face. Then, upon shooting themselves in the face they turn to the nearest person and say "why did it let me do that?". Your tools are rarely the problem. The problem almost always is how the people doing the building actually use the tools.
Imagine being this stressed and miserable over someone else building something cool and valuable when you already have enough money to never need to work again. What a wretched existence
If we think about it, Java was hyped, but it had poor execution. Very poor execution.
It tried to be too much and lost focus. "Run everywhere" where everywhere was Solaris+X, some other Unixes+X and Windows.
The language itself was a bit better than C++ (while it filed some hard edges and made it cleaner it wasn't much better) and overly bureaucratic. The API/stdlib worked but wasn't great.
Nathan Myhrvold's answer was mostly on point and time proved it right. Especially about what the PC should be.
There was that gaping pause after Java 6. I learned that version in high school, took the AP test, went to college, graduated, and got a software engineering job, and it was still Java SE 6. It's almost incomprehensible nowadays to imagine a programming language with that kind of stasis for five years.
Something I'm really not surprised about, but it's nonetheless interesting to see how the discusson never touches points like "is this enthusiasm founded?", "what are they doing right?" or "where do we lag behind? What could we learn from them? Where can we improve?". Gates just immediately jumps to "how can we kill it?".
That itself explains so much about even today's state of computing in a simple e-mail conversation.
When I was teaching my then 14yo the basics of programming, I started him off with python instead of java.
It was way easier to explain pip install pygame or whatever than explaining how to import a jar he needs(and all it's dependencies)
name = Input("What is your name ?")
print("Hi ",name)
That's a working Python program. To do the same in Java requires a ton of boiler plate. I don't think there's a person alive who can write a Java program which compiles from memory alone.
I hope I never have to work another job with Java again, most of it's not even the language but the tooling.
I was at a shop where we had to use Eclipse. Such a horrible IDE, it's apart of why I left.
It’s funny because Java has hands down the best tooling out of any language.
I would honestly be surprised if I would be pressing more keys per a given program with IntelliJ, than someone does with a much less verbose language.
This has also been my experience, but to me the detriment of verboseness is not only a matter of writing code, it also means there is a lot of noise when I try to read the code. I guess it might just be a personal preference whether we prefer explicit and typically more verbose or terseness at the cost of more implicit behaviour / magic? At least I am unfamiliar with a language which is both explicit and has no boilerplate.
Fortunately it's not an either/or choice. Python is easier to write, but JVM applications are significantly easier to distribute cross-platform. When you publish a Python game, compiling it to a JAR with Jython is far easier than figuring out x86 and ARM builds for Windows/Linux/macOS.
What a visionary Nathan was (Java becoming important, but not right then, emphasizing the importance of media and a frictionless PC experience). Whatever happened to him?
Their relationship is so interesting to me because it ties to the old "child" monarch vs his steely-eyed advisors. Long story short, its emotional manipulation to come at someone from a position of power and complain about "worry" and "losing sleep." In fiction and history we see these childish kings acting out with their advisors sort of calming them down as this stereotype of how wrong monarchy is, but instead its a valid and intentional leadership strategy: to emotionally manipulate your underlings by seeming hurt and needing of help. Gates played up this coddling attitude because it gets him the results he wants with minimum effort. Nathan recognized this signal and wrote out the logical part of the brain to counter Gates' emotional side. He coddled the child king. This is his job.
The C-levels in my life do this all the time. I've been manipulated many times like this. I think its linked to the habits of being a low-empathic personality. Its run of the mill manipulation which is what powers offices and sales all over the world. I imagine it gets results more often than not but its a bit pathetic looking and an acknowledgment human beings aren't logical animals, but primarily emotional and even the most hardened tech CEO is essentially playing emotional games with their staff, constantly. Its just so brazen and obvious when you see it like this. Especially when Gates is supposed to be the anti-Jobs, and this hard-nosed programmer not a diva, but surprise, surprise its diva behavior top to bottom in the C-suites, because diva-ism works.
I think the CEO playing as toddler has a ego stroking element to it and probably why this strategy is preferred over others. I tend to see C-levels in two groups, the alpha-male no-BS type and then the emotional manipulator type. I think both are ego pleasing (and probably both get similiar results), because the alpha gets the validation of his toughness and the manipulator gets the validation of his cleverness.
I think the latter is probably more pleasing for most personality types. You can still come off as the "nice guy" in polite company, even though you're being very demanding. Think how much warmer people like Sundar Pichai come off as compared to someone like Larry Ellison.
I also think there's a salesmanship aspect here. Its easier recruiting if you sell your company culture as a "nice" place led by a "nice" leadership. I think its a harder see to say "Look we're assholes here but the job and pay is good."
A wise leader surrounds themself with people they can truly trust in. In this message we see a glimpse into the dynamic between Bill Gates and Nathan Myhrvold, and my main takeaway is that Bill truly trusts Nathan here, enough to be vulnerable and speak openly about his worries.
While it's humorous and perhaps even enlightening to think of him as a "child king", I don't think he was only "seeming hurt" here or manipulating (unless you count all forms of emotional appeal as manipulation). Being honest and straight is a very effective way to lead those close to you.
It's also the leader's job to worry about threats like this and direct the attention of his advisors.
I'm just not seeing your pangloss-like explanation in the real world. Gates' words are very carefully crafted. He's not being vulnerable, he's being a leader and that means engaging in the Machiavellian action of manipulation and dishonesty to get the outcome he wants. Nathan knows he's being yelled at without being yelled at, its face-saving for both of them. This is saying "Why the fuck are you sleeping on Java, your future here depends on fixing the Java problem and telling me how you're going to do it," without saying that.
That's what I was trying to point out in my original comment. The "nice" and "hurt" leader is a common ploy and it gets results.
I see where you're coming from in the general case; I think it has been well established that leadership positions attract people well described by the dark triad. However, I don't agree that being a leader has to revolve around manipulation and dishonesty, and I've certainly seen this in the real world.
Even if Bill Gates has the dark triad traits I do not think they were on display in this particular email exchange. I truly don't think they were engaging in any "face-saving" here -- Nathan had been working for Microsoft for 10 years at this point, leading Microsoft Research and rising to the first ever Microsoft CTO. They coauthored a book called "The Road Ahead" in 1995. Bill has called him the greatest hire he made at Microsoft.
From every single source I've come across it seems clear that Bill Gates and Nathan Myhrvold are friends and share a deep mutual respect. No wonder they are still working together in 2021! You'd think after a lifetime of supposed abuse Nathan would have stopped working with him after becoming a billionaire, right?
Wow, we've really come full circle on this. If you're a business who wants to simply use the official Java JRE to run Java applications you now have to pay Oracle for a license.
This is false. You can (and always could) get the free OpenJDK, which is built and distributed by Oracle. It doesn't get much more "official". If you have some specific needs, you can pay for enterprise support, i.e. the Oracle JDK.
Since some months(?) you can also get the Oracle JDK for free (and use it commercially). But you have to pay for extended support. The free support given by the Oracle JDK is until a new major version is released (for non-lts versions) or one year after the next LTS version (which currently is released every two years).
Honestly, at this point I’m not sure if it’s just blind stupid hatred for Oracle, or deliberately spreading libel.
Oracle was the goddamn company that completely open-sourced Java for the first time to begin with. There are no longer paid-only tools in OracleJDK. Recently, they even made the support version free to use, and then people go on and claim this bullshit.
For me it's mostly the unpredictability of the garbage collector and it's magic ability to suffer cascading failures in cases you thought you'd properly loadtested...
Perhaps billG and I are thinking on different levels...
> cascading failures in cases you thought you'd properly loadtested...
That's hardly unique to Java. If you crash your processes because you didn't design your application to scale to your needs, there's not much the language can do about that.
It just seems easier to get yourself into a bad performance corner with Java. Other languages seem to just start slowing down as load increases. You see more variation in response times, but still plenty of throughput. Whereas Java has a sudden performance cliff that's reached, and you usually won't get it to perform well again without either removing 99% of the load or restarting the process.
I assume you've run profilers against it and captured CPU/memory snapshots? You may be filling up the heap, leading it to get into GC cycles to try to free memory. If that's happening you either have a memory/resource leak, or you just need to allocate more heap to run your application.
This is a hard problem and definitely not unique to Java.
For example networks, or perhaps more appropriately, network protocols, have these kinds of cliffs as the offered load on the network increases.
As I understand a particularly bad traffic jam in the early internet is what motivated congestion control in TCP. As a matter of a fact traffic is also an example of this phenomenon playing out without any (effective) compensating measures.
I find "Metastable failures in distributed systems" [1] to be a really interesting and accessible exploration of the problem.
> It just seems easier to get yourself into a bad performance corner with Java
Well, Java’s GCs are the state of the art. If they can’t deal with the amount of garbage a program creates than nothing can.
As for the rest:
Which may or may not be the correct response depending on use-case. The JVM gives you the freedom to choose the approach you want. The default G1 GC for example has the target pause time setting where you can set whether you would want lower latency or higher throughput.
>The new Java applications are NOT credible threats to traditional PC software any time soon. [...] Cool new technology always expands rapidly into NEW ares (where there is a vacuum).
Java's hype of Write-Once-Run-Anywhere to kill Microsoft Windows didn't happen on client desktop apps like many expected. Desktop apps are still C++ and some newer apps are Javascript(Electron). Yes, there are a few niche desktop apps using Java like JetBrains IDEs but history has shown that Java made more market penetration on server-side code. The 1990s dot coms like Ebay and Amazon were early users of Java on their servers. I read that Google uses Java on the web servers to generate the results page. (To be clear, I think Google uses C++ for the crawlers to build the index and the algorithms for search engine ranking.)