Link Details

Link 358183 thumbnail
User 188481 avatar

By alext
via bluetrainsoftware.blogspot.com
Published: Feb 06 2010 / 19:18

As much as we all "try to be friends", the successor to Java (and there clearly needs to be one) "battle" between Groovy, Scala and Clojure will IMHO, only heat up this year with the introduction of Groovy++.
  • 17
  • 42
  • 6817
  • 1

Comments

Add your comment
User 30679 avatar

Kent Tong replied ago:

2 votes Vote down Vote up Reply

I don't see how a dynamically-typed by default language can be a successor to Java.

User 231703 avatar

MattRussell replied ago:

-1 votes Vote down Vote up Reply

"Groovy ++ adds to Groovy static typing"

User 30679 avatar

Kent Tong replied ago:

3 votes Vote down Vote up Reply

Static typing is an after-thought. The problem is the fundamental belief reflected in the design of Groovy that dynamic typing should be the norm.

User 388907 avatar

MCII replied ago:

-3 votes Vote down Vote up Reply

Same for a functional and a kitchen sink language.

User 201742 avatar

shantanu_k06 replied ago:

1 votes Vote down Vote up Reply

What do you mean by "functional and a kitchen sink language" -- could you cite examples?

User 388907 avatar

MCII replied ago:

-3 votes Vote down Vote up Reply

The mentioned Clojure and Scala.

User 307984 avatar

slartinyc replied ago:

2 votes Vote down Vote up Reply

Love the Fox News style headline.

User 46563 avatar

rv49649 replied ago:

6 votes Vote down Vote up Reply

Groovy was easy to learn. Had high overhead so was rather slow. Couldn't be a complete replacement of Java. (Plus I'm in the static type camp and any so-called successor to Java needs to be static typed.)

Scala has a litany of coolness in terms of features and ideas. IOW, sounds great on paper. Daunting to learn to master, though. Have to wrap head around functional programming as that is really the bias of Scala (you'll always feel like a second class citizen in Scala unless you make effort to groc functional programming).

Google Go language has been a blast - haven't seen anything this productive to program in a long, long, long time. And to think am just using "stone knives and bear skins" tool set to program in Go. The goroutines and channels are what I've wanted for ages (but in a non weird language, i.e., not Erlang). Building applications with internal async messaging using constructs intrinsic in the language itself is the bees knees.

And now there's Groovy++. This time we have compile-time static typing. So that's checked off. Type inference so has concise syntax potential ala Go. They'll be adding an actor capability - so internally intrinsic async messaging. Runs on the JVM, so uses a runtime with well over a decade of maturity. Unlike Scala, Groovy doesn't have name mangling impedance with Java, so hence is smoothly inter-operable with Java. Java can even make painless use of Groovy-authored classes.

Groovy/Groovy++ - easy to learn, especially so for existing Java programmers
Scala - really need to learn functional programming - significant obstacle

The actor capability will be the key thing in the end. If Groovy++ does a reasonable job on this, then it may very well move to the front of the pack.

User 60102 avatar

jodastephen replied ago:

-1 votes Vote down Vote up Reply

I think you might like Fantom ;-) Statically typed, familiar syntax, Java's mistakes fixed but without the radical nature of Scala/Clojure - http://fantom.org

User 393686 avatar

RawThinkTank replied ago:

-2 votes Vote down Vote up Reply

Dont worry, in few months we will get Scala dotNet compiler

User 201742 avatar

shantanu_k06 replied ago:

4 votes Vote down Vote up Reply

I don't appreciate the author's assessment of Clojure. I think the more important problems at hand are not exactly static typing in Groovy. The following might help:

1. Data should be immutable by default (I like val and var in Scala, I like Clojure's persistent/transient even more)
2. Sharing of mutable state should be made impossible, hence removing the need to lock
3. Immutable classes by default (Open-close principle)
4. Ahead of time (AOT) compilation, yet dynamic at language level (like Clojure)
5. Language-level autonomous actors like Erlang/BEAM on the top ofJVM (not sure if it will affect performance, JITability)

To replace Java we need a simpler language that can do more. Java is a kitchen sink language.

User 240010 avatar

Nikita Ivanov replied ago:

1 votes Vote down Vote up Reply

So, currently Groovy++ is ~50 times slower than Scala (or Java for that matter) and is incomprehensible mess internally (just look inside if you care). It's a hack in the effort of saving dying language that was in of itself a hack when it was designed.

Language design is hard. Very hard. It requires education, talent and experience. If you think Scala is complex - just imagine what would a static typing strap-on do to a dynamic language.

PHP folks didn't change the language - they changed runtime to have a fighting chance to continue use millions of lines of crap written in PHP. That was the right decision that unfortunately not available for Groovy - Java runtime is fast enough already, but the Groovy language is not and likely will never be.

User 209458 avatar

paulk_asert replied ago:

3 votes Vote down Vote up Reply

Do you have some benchmarks? Mine show Groovy++ on par with/faster than Scala in many/most scenarios.

User 171444 avatar

isterin replied ago:

-1 votes Vote down Vote up Reply

Not even close. You can't compare a real and advanced language like Scala to a bolted on utility like groovy. I like groovy to complement some java development, but definitely not to build full blown apps in.

User 393686 avatar

RawThinkTank replied ago:

-3 votes Vote down Vote up Reply

The reason why people go for Dynamic languages is because real programming is not everyone's cup of tea

User 362555 avatar

BillyBob321 replied ago:

0 votes Vote down Vote up Reply

Here you go, thinking like a bunch of dumb nerds again. Am I really going to go to my manager and say "We need to use Groovy++" (lol at that name btw) and he won't even know anything about Groovy and wonder why we just skipped over it straight to ++. Not to mention it's basically a clever hack onto an already existing hack-ish language. It's a non-starter and if you thought about it for more than the 5 minutes you took to write this junk blog post, you'd understand why.

User 209458 avatar

paulk_asert replied ago:

2 votes Vote down Vote up Reply

Actually managers from 200+ projects in my customer base have been happily understanding and approving of Groovy for years. They are more interested in the productivity gains and closeness to Java (hence low learning curve) than any nerd features. Less than 10 projects so far are using Scala, Haskell and Clojure combined.

User 352695 avatar

kitdavies.com replied ago:

0 votes Vote down Vote up Reply

Consider:
1. whether the implementation of the language is controlled by a standards authority v. is open-source and free for innovation (ie explicit v. implicit standards)
2. whether the language itself is open to innovation via DSLs etc
3. whether the language is sufficiently performant for your next project
4. whether the language can be extended by low-level libraries
5. whether the language has a wide range of utility libraries available
6. whether the language has a large supporting community of forums and developers

If any/all of these things are important to you, then Groovy is ahead of the game at the moment and will take some catching up now that we have optional static-typing as well. Its origins or what its source code looks like are irrelevant.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Reactive Programming with Akka
Written by: Ryan Knight
Featured Refcardz: Top Refcardz:
  1. Design Patterns
  2. OO JS
  3. Cont. Delivery
  4. Java Performance
  5. HTML5 Mobile
  1. Java Performance
  2. Node.js
  3. Debugging JavaScript
  4. Java
  5. Java Concurrency