The choice of a programming language — and I speak as one who has spent twenty years in Java's service, latterly deserting it for TypeScript, Rust, and Python, the way a diplomat might trade his motherland's embassy for three more agreeable postings — is never the purely technical decision its practitioners pretend it to be. As always, it is a story of politics, blood, corporate litigation, and managers whose strategic vision extends no further than next quarter's earnings call.
It has always seemed to me that C# is, by a considerable margin, the better language. LINQ expressions alone — and I mean the expressions themselves, the deep language integration, not merely the surface-level applications like LINQ-to-Objects — would justify this judgment. And in F#, which inhabits the same .NET platform, one finds proper type providers and a functional programming tradition that actually works, as opposed to Haskell, which spent several consecutive years segfaulting on Windows while nobody could be troubled to fix it.
But all of this is spoiled — methodically, comprehensively, and with a kind of institutional malice one almost has to admire — by Microsoft's compulsive need to annihilate its competitors, and the resulting absence of any ecosystem beyond Microsoft's own products. This is what the absence of competition looks like: not one grand catastrophe, but a slow, silent degradation. What fool would bind himself to a technology whose creator might, on any given Tuesday, decide to destroy him?
A note for the uninitiated: "Embrace, Extend, Extinguish" — three verbs that, in a gentler context, might describe the arc of a summer romance — is the documented antitrust strategy by which Microsoft captured open standards. It is described, with judicial precision, in the United States government's case against Microsoft, 1998–2001.
The situation with Oracle is, in its essentials, the same. Consider: a framework originally named Javaslang ran afoul of Oracle's legal department for the sin of containing the word "Java" in its name. The authors, displaying the kind of grim creativity that corporate bullying tends to inspire, visually inverted the name and arrived at VAVR, with the rather elegant slogan: "vavr — turns java™ upside down." A charming piece of defiance — though it does nothing to alter the fundamental truth that Oracle is a corporation one finds exceedingly difficult to love.
But here I must note a crucial exception — a singular episode in which several companies, led by IBM, managed to corner Oracle and wrest from them a significant portion of their power over Java. It is only thanks to this event that the language remains alive and interesting today.
The story is straightforward, and instructive.
It is probably no longer widely remembered, but Java was created by Sun Microsystems, a company whose fortunes were, at the relevant period, in visible decline. In an attempt to shore up their position, Sun's leadership sought to maintain maximum control over the language. But what programmer enjoys watching his beloved tool pass under a corporate yoke? This displeasure was not merely individual — it was industrial.
Thus was born Harmony: a free, open-source reimplementation of Java. Not the one now belonging to Huawei — that is HarmonyOS, a different creature entirely. This Harmony existed nominally under the aegis of the Apache Foundation, but was sustained in practice by the engineering resources of its corporate backers, IBM chief among them.
Here one must pause to admire — if that is the word — the ingenuity of Sun's defensive strategy. They took their Technology Compatibility Kit, the TCK — a rigorous test suite that was, in purely technical terms, an excellent and necessary thing — and transformed it into a weapon. Any implementation that failed the TCK's tests could not legally call itself Java. One could not build an open-source version and skip half the certification without receiving a prompt visit from the lawyers.
Well then, one might say, simply pass the tests. Do the thing properly. But this was precisely the trap: the TCK was a proprietary commercial product, distributed solely at Oracle's discretion and solely to those Oracle deemed worthy of receiving it.
When Oracle acquired Sun, they did not abandon the practice of terrorizing the community through the TCK. They expanded and deepened it.
And so, when Oracle refused to provide the Apache Foundation with the test kit — rendering Harmony "not Java" in the legal sense and triggering a cascade of juridical consequences — a remarkable thing happened. The Apache Foundation, the principal open-source organization in the world, withdrew from Oracle's Java Community Process. Companies like IBM and Red Hat supported the boycott, demanding genuine openness for Java.
Fortunately, even before the Oracle acquisition, Sun had begun the work of open-sourcing portions of Java. From this effort emerged the project now known as OpenJDK — which is, in effect, what people mean today when they say the word "Java." It was more open, governed by more reasonable licenses (GPL with certain exceptions, for those keeping track).
When Oracle finally relented and gave the green light to the total open-sourcing of OpenJDK, IBM joined the project, and Harmony was quietly shut down.
OpenJDK became a kind of pseudo-standard: its code is now the canonical — and, following the demise of Excelsior Jet, the only genuinely viable — implementation of Java-as-runtime. Its open-source governance became the rails on which all further development of Java-as-project would run.
A few technical notes for the Java practitioners among us. Eclipse OpenJ9, Azul Zing and Zulu, Amazon Corretto — these are all living implementations, but each is essentially a set of modifications applied atop the OpenJDK codebase. And every one of these organizations runs on a very short leash: any attempt at truly individual innovation, any deviation from the Java standard, earns a courteous but unambiguous invitation to speak with the lawyers.
Of all the surviving implementations, the most independent in spirit is OpenJ9 — a separate JVM descended from IBM J9, a compact runtime originally designed for maximum efficiency on low-power devices. And the most practical for everyday development, particularly with Spring, is Liberica JDK — though this is a personal opinion, and I will not quarrel if you find advantages elsewhere.
Given the industry's general cooling toward Java as a technology — other developers, after all, had not been sitting idle, and had spawned a multitude of alternative runtimes, perhaps not as powerful or elegant, but blessedly free of Oracle's involvement, which in our bewildering times is itself a feature — this arrangement proved sufficient.
The process of open-sourcing was neither simple nor pleasant. The Java Enterprise Edition framework, once central to the language's identity, was held hostage by Oracle for a full decade. The TCK for JavaEE was finally released as open source in 2017. This was, by my reckoning, the moment when Oracle simply ceased to regard Java as a serious business concern and let the whole thing slide. Their attitude was transparently antisocial: either Java was a revenue stream, or it was a community — no third option existed.
And yet Oracle did not stop tormenting developers; they merely changed their methods. The lawsuit between Google and Oracle over Google's use of Java APIs in Android dragged on for roughly eleven years and concluded with Google's victory.
Indeed, the entire existence of the Go programming language can be read as Google's careful postmortem on the question of how to avoid ever dealing with Oracle again. In its original form, Go was essentially Java 1.4 — which is to say, Java without generics, vintage spring 2003 — but equipped with a proper native-code compiler. (Java would not acquire its own, via GraalVM, until 2018, and it still loses to Go by most practical measures.) As a language, Go remains inferior to Java even now, though it is methodically retracing Java's evolutionary path — generics have been added, the garbage collector improved. Nevertheless, it is entirely possible that Go would never have existed at all had Oracle not embarked upon that decade-long legal delirium.
Someone will object that Go was really born of the pain of compiling C++ and the difficulty of managing dependencies in vast codebases, and had nothing to do with Oracle. I will not argue that Go would never have appeared without Java's troubles. I will argue only that Go in our branch of the multiverse and Go in the branch where Java never existed are not the same language.
Has the good side won, then? Not quite. God help you if you use the word "Java" anywhere without prior authorization. Half of Oracle's headcount, one suspects, consists not of engineers but of attorneys — and you, dear reader, are not Google. You cannot litigate against them for a decade.
I love Java very much, and a significant portion of my life has been bound up with it. And all this filth, this accumulated residue of corporate warfare, does terrible damage to people's willingness to engage with the technology. There comes a point where so much blood and rancor has accumulated that washing it off becomes nearly impossible.
Still, Java today is in the hands of talented, reasonable people. And perhaps it will yet come to a good end. One hopes.
With Microsoft, no such reckoning ever occurred. There exists no grand coalition, no commercial front of the Forces of Light and Goodness that managed to bring their dark practices to heel. Then again, C# was never quite vital enough to justify the effort. When Java first appeared, it was singular and therefore essential; by the time C# arrived, it was not.
The practical consequence is that the C# ecosystem is vanishingly small. You have a handful of excellent frameworks bearing Microsoft's imprimatur, a few well-known open-source projects, and — that is all. There is nothing like the extravagant bazaar of Java or JavaScript, where one might spend an hour deliberating which of several hundred libraries to use for the task of adding two numbers together.
Rust, too, stumbled into a remarkably similar quagmire. In 2023, a draft of its trademark policy unleashed a tempest of communal indignation. Among other provisions, it would have prohibited the use of the word "Rust" in the names of crates, libraries, repositories, developer tools, domains, subdomains, and software written in Rust — without explicit licensing. The outcry was so ferocious that the Rust Foundation was forced to retract the proposal.
But the most important thing we learned from this episode is that the Rust Foundation harbors people whose mindset is not fundamentally different from Oracle's. They have, yes, been educated by Oracle's bitter example, and respond more nimbly to community sentiment. But the instinct is the same. Who can say what they will devise next?
For the time being, my personal island of freedom is ECMAScript — also known as JavaScript. (The word "JavaScript" is, I should note, the legal property of Oracle, on account of its containing the word "Java." One cannot, in the strictest sense, call JavaScript by its own name. Have I mentioned that Oracle is a corporation one finds exceedingly difficult to love?)
Despite the dominance of Google's V8 and Apple's JavaScriptCore in the arena of high-performance execution, the broader ecosystem is a vast and improbable Babel — projects so diverse, so disconnected in origin and intention, that surveying them induces a mild vertigo, like peering at the world through the eyes of Doctor Strange. And yet all of it works, and — more remarkably — works together, within a single web interface or a single backend. It is genuinely difficult for any corporation to impose totalitarian control over such magnificent chaos.
The second island of freedom is C++. Here there are two subtleties.
First: C++ is developed by large, powerful, sharp-toothed companies. But there are many of them. They collaborate through an enormous committee in which everyone has a seat. If any single company were to overstep, the others would devour it instantly. This is splendid — the market, for once, functioning as advertised.
Second: the very nature of modern C++ is eclectic. Almost any member of the community can pursue almost any direction — into the forest, up a tree, wherever fancy leads. And no lawyer will come knocking. This matters enormously: to develop a feature, one needs to be a brilliant engineer, and that is possible. To fight Oracle or Microsoft in court is not possible. The difference is oceanic.
Moreover, there exists no single individual who knows "all of C++" and could design a perfectly compatible feature, and then declare himself the dictator who Knows How Things Should Be Done. This sets a healthy tone of principled anarchy.
For me, this is the essential point. I cannot speak for others, but for my part, the presence of a dictatorship — some singular Grand High Master who Knows Best — is so dreadful, so fundamentally repellent, that it overrides nearly every other consideration. One submits to dictatorship only when the alternative is destitution or death. Dictatorship is antithetical to everything human, and it is entirely natural to despise dictators.
And C++ would be excellent in every respect: it boasts more powerful features than any popular language (C# included); its development is conducted with admirable openness; and it runs fast. BUT THE SYNTAX IS AN UTTER NIGHTMARE. Before the advent of Perplexity, one could not even properly search for a C++ program on Google — the search engine perceived it as an incoherent tangle of special characters.
And here is the thought I wish to introduce at the close. We are entering an era in which human beings are ceasing to write code in high-level languages. The robots write it now.
A robot, broadly speaking, does not care what language it writes in. Languages like Java and C#, whose principal virtue was that they were comfortable and pleasant for humans to use, ought to lose their priority and recede into the shadows — into that modest, well-fenced paddock of software that humans will still write by hand. Banking, medicine, space exploration — all of this will remain in Java. Wherever the real product being sold is not software itself but the management of risk and fear, people will continue to tolerate Oracle's peculiarities.
But everyone else, in the not-too-distant future, will write their programs in ordinary English. And after that will come Neuralink, and programming languages will cease to be necessary at all.
Into which "high-level language" the neural network translates your specification will depend not on how comfortable that language is for a human to use, but on concrete technical characteristics: how well the model generates code in that language, how the runtime manages resources, how quickly compilation proceeds, how rapid the development iterations are end to end.
And it may turn out that the languages of the future are not Go or Java, but the supposedly antiquated C++ and C. Perhaps even assembly. Perhaps even punch cards — not the ordinary kind, but quantum ones. The good news: you will not need to know any of these languages any better than you currently know assembly and C. Developers in certain narrow specializations — performance engineers, say — may need to drop in from time to time and fix some gnarly edge-case bug. But for everyone else, the neural network will write everything, and this is wonderful.
In the interest of formal honesty, it must be said explicitly that, as of early 2026, the claim "the robot doesn't care what language it writes in" is debatable and more likely wrong. The quality of generated code depends heavily on the language — the volume of training data, the degree to which static typing serves as scaffolding for the model, the tooling available for verification. When writing C, for instance, the robot suffers from precisely the same affliction as the human programmer: it cannot reliably track memory, and consequently produces code that is, not to put too fine a point on it, nonfunctional. Even Claude Code. Even Grok Super Heavy. All of this deserves a separate discussion, but it exceeds the scope of the present essay. I shall write about it elsewhere.
And here is what matters most: writing code through AI in natural language is genuine freedom. Natural language does not belong to any corporation that might compel you to say only what suits its interests. Arriving at a good technical decision is difficult — but not squandering one's freedom may prove more difficult still.
And so, the conclusion. Learn to write — in English, in Russian, in Chinese, in whatever language is yours — and to articulate your thoughts with clarity. Have thoughts worth articulating. This, in the very near future, is what will be required.
Top comments (0)