[jbooth]

Java fills a particular niche (code with an emphasis on readability) which is not addressed by Groovy or Clojure and arguably not addressed by Scala. I'd say Go is the biggest competition for that niche as a language, although it's not JVM, it does fix many warts with how Java handles inheritance/polymorphism without sacrificing readability and simplicity.

Groovy is slow as a 1-legged dog. (we use it to fill the shell/perl niche a lot but it is slow, effectively you're doing reflection lookups every time you call a method in Groovy). The dynamicness makes it better for scripting or web programming, though, where you don't care as much about performance.

Scala is the JVM's C++, a giant pile of overlapping features, supported by an advanced and very slow compiler that yields fast bytecode. Case classes, funny operator overloading, lots of additional syntax for collection manipulation. They're giving you more expressiveness at a cost of readability and language complexity. (This is an opinion, some may disagree).

Clojure is really awesome but most dev shops will have an easier time with imperative programming models.

Ultimately, not changing in 8 years isn't fundamentally bad, and Java isn't that bad at all as a language if you avoid things like EJB and Hibernate, and if you're not looking for a dynamic language like Ruby and dissapointed by Java not being Ruby. You might just disagree with the tradeoffs.

[smrtinsert]

For me its a benefit, why would you want your language/core api changing all the time? Thats how you end up with certain unnamed languages that have fallen out of favor. Java the language tries very hard to not be redundant in its feature set, so the path to usage is clear.

I think Java suffers from too many search results (yes thats a thing). I suppose if you want to learn Java today you simply google it, and find tons of people trying to solve the N+1 hibernate problem on stackoverflow, or some other common annoying enterprisey issue, and so you start reading up on JCPs and EE apis. If that is your introduction, I can understand why people end up going "what is this shit?". The reality of course is that there are many subcultures within the Java community and that many of them are anti cruft api as well which is how innovation comes to the Java world.

[jbooth]

Yeah, a good rule of thumb is that if something was specified by a JSR, it's probably shit to work with because of all the competing corporate agendas that went into it.

[spongle]

It works sometimes and not others.

For example, if someone put as much effort in .Net's original collections API as they did with Java JCF, many a facepalm would have been avoided.

To be honest the whole JSR process is usually hindered by shoddy implementations rather than fundamental problems.

[sbilstein]

I'd argue Scala is much more readable than Java with some effective practices. Type inference (where appropriate) cuts down on distracting text, operator overloading is great when used judiciously, for comprehensions, etc are all great features.

Just because Java requires explicit typing all over the place does not make it easy to read, especially when I'm trying to decipher what the ResourceBuilderFactoryFactory class is doing in my enterprise grade codebase. There is cognitive load in parsing tons of text to express simple concepts, just as there is cognitive load in deciphering a bunch of random symbols doing something complex. Scala with discipline lets you choose somewhere in between; Java gives no choice.

[cgh]

For startups with small, disciplined teams, Scala is manageable, sure. But once things go "enterprise" and much of your ongoing development gets outsourced, and it will, all bets are off. Maintainability is THE great equalizer.

[dragonwriter]

> But once things go "enterprise" and much of your ongoing development gets outsourced, and it will, all bets are off.

That has nothing to do with language; Java for which development is outsourced and maintenance goes in house is pretty much a nightmare, too.

But that's pretty much a "myopic development practices -- including outsourcing development of code you are going to need to end up supporting in house -- will blow up in your face problem", and not an issue relating to any particular language or platform.

Chances are, if you have the authority to make enterprise-level language/platform policies, you also have the authority to make enterprise-level decisions on whether and when to outsource development of software, so it makes sense to just do the latter right than to make an otherwise second-rate choice on the former to make up for doing the latter poorly.

[sbilstein]

It's my personal goal at the current company I'm at to see Scala grow to be respected as an "enterprise" language. The startup where I learned Scala had a small disciplined team with lots of mentorship that meant almost everyone developed some very good Scala practices.

If code is becoming unmaintainable because of outsourced development, does that not have more to do with how we communicate to these external developers? Bad code is bad code in any language.

[jbooth]

Type inference is great, and is part of why I consider Scala to be "one step forward, 2 steps back" rather than just a total loss.

As far as the rest, we'll just have to disagree, I stated up front that it was an opinion :)

[sbilstein]

Haha, well what you said is true, but your spin on it I disagree with. How about "one step forward, a couple steps to the side"?

[Roboprog]

I'm curious to know if Groovy 2.x (with strict/static compiler pragmas, er, annotations) is slow relative to regular Java lang code. I know Grails doesn't use the strict mode stuff, but for hand coded "hot spots", how does Java vs Groovy 2 compare?

[vorg]

> Grails doesn't use the strict mode stuff

No one uses the strict mode stuff except those unwittingly beta testing it for Grails. It was written by one lone programmer and is still buggy.

[Roboprog]

Hmm. Interesting. I recently incorporated Groovy into an existing legacy (web) app. As the app is still under Java 1.5, I could not get the static/strict stuff to work - it needs 1.6 or better support.

So, there's consensus that this feature is not ready for prime time? (I don't want an answer from people who hate Groovy in general)

[vorg]

> So, there's consensus that this feature is not ready for prime time?

Best wait till Grails trusts the static enough to use it before you do.

> I don't want an answer from people who hate Groovy in general

I love the Groovy Language, but the current PM made some bad decisions after taking over, e.g. removing Poirier's Heredocs, disabling Scala-like catchless try statements, laundering Tkachman's Groovy++ static-typing plugin, stonewalling on Wilson's MOP upgrade, scuttling any attempt to spec the language, the horrible paren-less DSL syntax for multi-arg function calls, removing Closure Lists just before an RC release without any public discussion, how Strachan the founder was knifed over dynamically-scoped closure syntax at Devcon 2, how Java 8 lambda retrofit hasn't even been begun on, instead the PM is wasting time on non-Java compatible traits to Groovy, etc.

I still love the essence of the Groovy Language, tho, that's why I'm rebuilding it atop Clojure.

[Zak]

Java fills a particular niche (code with an emphasis on readability)

I'm a bit skeptical of this claim. While Java does remove many of the opportunities other languages provide for making a small piece of code do something unexpected, I've found that Java's verbosity makes it hard to see the big picture.

Of course, good programmers manage in spite of any limitations of the language, and bad programmers manage to write incomprehensible code no matter how much a given tool tries to guide them in the right direction. I suspect it will always be this way, and that's not a bad thing.

[unclebucknasty]

EJB (and particularly entity beans) is the worst thing that ever happened to Java and, arguably, enterprise development.

It's still unbelievable to me that so many shops drank that Kool-Aid.

[total__C]

Groovy's niche is supposed to be the same as Ruby or Python - if you want high performance, it's not the way to go. I've done a lot of Groovy for simple web applications and it works very well.

You don't have to use funny operator overloads if you use scala! Making your code readable in that language is definitely up to the developer.

[MrBuddyCasino]

> Scala is the JVM's C++

Thats what I've been thinking (and posting) since some time now, nice to see I'm not the only one. I know some Startups regretted choosing Scala.

[smrtinsert]

I would imagine without strong leadership you could end up with code looking completely different between programmers.

[camus]

which ones ? i beg the differ.

[raphinou]

Did you test statically typed groovy? Does it have better performance?

As for clojure, how does its performance compare to groovy?

Really interested to know more!

[Zak]

Clojure can be exactly as fast as Java within a function when type hints are used to avoid reflection. Calling Clojure functions has a little overhead relative to calling Java methods.

That said, an idiomatic system in Clojure will likely have a very different design than it would in Groovy or Java. Using Clojure's built-in immutable data structures, it's cheap in terms of CPU and memory to make a large number of modified copies or to concurrently access data compared to the standard collections in Java and Groovy. Single-threaded reading and writing are, however somewhat more expensive.

My prediction is that it's easier to get good performance out of a system with a lot of concurrency using Clojure than it is with Groovy or Java, though with careful design, it's possible to get better performance with Java.

[camus]

Actually, Scala core is pretty small. What you think as operators are methods. What you call case classes is pattern matching , one of the most powerfull feature of Scala along with Actors.

> lots of additional syntax for collection manipulation

Actually using collections in Scala is far more easier than in Java

And i'm not even talking about XML parsing... where you would write 30 lines in java you'll write one liners in Scala. Guess which one is easier to read...

Scala promotes immutability that make code sane.

Scala promotes recursion over loops that makes the code elegant.

Scala promotes experimentation through its REPL.

Scala saves you writing 75% of the java boilerplate, thus promotes maintainable applications.

Scala looking much like Java is a deception but also an necessity for compatibility which Java libs. but the syntax has a total different meaning . That's the genius of Scala. Scala is the guy looking outside the box when Java is trapped in Cargo Culting.

Scala is the future of the JVM.

[jbooth]

This post comes across like you're incredibly ideologically invested in Scala. I'd suggest that 'the future of computing' in any dimension will take a lot more from practicality and a lot less from theory or ideology.

Specifically, the point about encouraging recursion for more 'elegance' kinda bugs me there. Recursion is more of a natural fit than loops when walking a tree or graph, and is less so when iterating a list, set or map. It's about practicality.

If you're very interested in aesthetics, you'll never like java or even not-hate it. And that's ok.

[dragonwriter]

> Scala looking much like Java is a deception but also an necessity for compatibility which Java libs.

The fact that Scala can look a lot like Java is more for compatibility with Java devs; the code could look a lot different (and idiomatic Scala does) and still be compatible with Scala libs, but supporting code that is familiar to Java devs eases the learning process and encourages adoption.