Ada was designed to solve different problems in harsher environments than other PLs at the time. Mostly, it was designed for the defense and aeronautics industries and had to compete against other PL designs to become a govt standard, similar to how weapons of war are developed and chosen. Think developing for hardcore code audits. There is no way the language could check all the boxes and remain compatible with, say, Pascal or Modula syntax.
Many will argue that Oracle is overreacting, and they may not be entirely wrong. But as someone who reviews PRs for open source languages and tooling, their interim actions strike me as both sound and measured.
The number and size of AI-assisted PRs have reached a tipping point. Reviewing them already consumes a significant amount of time, and even filtering out the obvious ones is a drag. More importantly, the risk/reward balance is shifting in the wrong direction. For now, placing constraints on AI-assisted contributions feels like a sensible way to manage that risk.
Will this policy reject or slowdown otherwise beneficial PRs? Potentially. But that is the tradeoff. Until there is a better way to offset risk, this one is probably the least bad strategy.
In isolation, yes, I agree with you. But in the context of the cornucopia of other "carefully evaluated" features mixed into the melting pot, C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language. No thanks.
It’s not their code, and it’s not for them to understand. The endgame here is that code as we know it today is the “ASM” of tomorrow. The programming language of tomorrow is natural human-spoken language used carefully and methodically to articulate what the agent should build. At least this is the world we appear to be heading toward… quickly.
There is a large and growing segment of executives in the software world that is pushing this model hard, like betting their career on it. To them the “dark factory” is an inevitability. As a consequence, not only are developers choosing this path, but the companies they work for are in varying degrees selecting this path for them.
Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.
It's replete with oddities and limitations that signal "ah, this is because systems language."
Go’s type system, for example, is very much a systems-language artifact. The designers chose structural typing because it was lighter weight, but provided enough type safety to get by. It sucks though for enterprise app development where your team (and your tooling) are desperate for nominal typing clarity and determinism.
Kotlin's "delegation" feature isn't true delegation, it's just call forwarding, which is better than nothing, but it falls down pretty quickly as an alternative to implementation inheritance.
The manifold project provides true delegation[1] for Java.