Beyond Java - Bruce Tate [88]
It seems like each major beta release breaks existing Groovy applications. Worse, the first major Groovy specification request broke existing applications. That's not good. Many of the core Groovy developers also seem to be leaving the original JSR team.
Overall
With a formal JSR backing it, Groovy is politically in a good place to succeed. After all, you could argue that EJB succeeded based on the reputations of the supporters, despite significant technical limitations. Groovy has some energy and hype, but a few false starts seem to be stalling the momentum. I'll undoubtedly get flamed for saying so, but right now, Groovy is much too young and too unstable to deserve serious consideration for any production application, let alone standardization.
That Groovy is buggy and unstable as a beta doesn't trouble me so much, though you'd expect core language features and syntax to be set very early, but basic features like closures don't work. I'm most concerned with the overall process. The community process standardized the Groovy language before it was mature, or even stabilized. To move forward in a productive way, Groovy must first solidify the major feature set, then recover some lost momentum, and then prove itself in some commercial niche before it will be considered as a significant candidate to replace Java anywhere. Until then, it's merely an experiment. I hope it succeeds, but I don't think it will. It simply has too far to go.
.NET
.NET is the only nonprogramming language that I've mentioned as a credible successor to Java. .NET is Microsoft's latest development platform, deserving special mention because it has a massive library, and a language-agnostic engine called the Common Language Runtime (CLR) that sits on top. If Microsoft makes .NET successful, and truly language-neutral, it could serve as a launching pad of sorts for many languages. Right now, like the JVM, the CLR has some technical issues to overcome before it can fully support dynamic languages like Ruby, but Microsoft is committed to doing so.
Language options
At some level, the programming libraries underneath .NET are far more important than the language. Their usage models frequently dictate application structure, often more than the choice of programming language. Still, Microsoft offers several programming languages, targeted at vastly different communities.
Visual Basic for .NET
Microsoft has a real problem on its hands with Visual Basic programmers. It seems many of those hundreds of thousands of active developers just don't like .NET, and they're looking for alternatives. The .NET framework changed the programming model for Visual Basic. So far, most of them either are actively deciding to pursue alternatives, or are passively waiting to upgrade. Either way, Microsoft loses. As a result, it looks like Visual Basic is in trouble.
In public, Java and .NET developers don't mix, but each community often reluctantly admits the strengths of the other. While married to a platform, Java developers have often stolen secretive longing looks at Visual Basic's productivity and user interface development framework. Visual Basic users secretly returned the flirtations, admiring Java's structure, if not productivity. I'm making an educated guess that Microsoft thought it could sneak in some more structure, believing that the BASIC syntax would trump the unfamiliar frameworks underneath. They were wrong.
Microsoft is making some moves toward satisfying the Visual Basic community. Some plans seem to favor a Visual Basic classic edition, which looks and acts more like the Visual Basic of old. To me, that move smacks of new Coke and Coca-Cola Classic,