I wrote a post awhile back, called "Groovy, the Python of Java"[1], which praised Groovy as a great language for Python/Ruby developers who are forced to work with the JVM and associated libraries.

In the post, I said, "Python is still my muse, but Groovy is my Winston Wolf."[2]

As for Scala and Clojure, these are wonderful JVM languages, but they force you into a new programming model. You go from Java's "object-orient all the things" to Scala/Clojure's "function-orient all the things". Groovy, like Python, strikes a balance by being dynamic and multi-paradigm. A true clean-up man.

Its only downside, IMO -- the JVM :)

[1] http://www.pixelmonkey.org/2011/04/09/groovy-the-python-of-j...

[2] Scene from Pulp Fiction introducing Winston Wolf http://www.youtube.com/watch?v=ANPsHKpti48

I can understand why in some circumstances the JVM is not the most appropriate choice, but to me, the sentence "Its only downside... the JVM", sounds like "The car's only downside... it's a Ferarri". I've worked with so many runtimes in my career but have yet to see one fit to kiss the JVM's feet. It's far from being the simplest, but in terms of sheer power (runtime instrumentation, runtime linking, performance monitoring, hardware/OS support and more) nothing else comes even remotely close.

I can't emphasize how easy it is to extract JVM runtime information and how useful that information is for performance tuning. Sure the JVM uses a bigger initial footprint when compared to a natively compiled application, but the ability to see how it's working is invaluable.

My program is RAM hungry...ish, but with its easily accessible garbage collection (GC) information, I can really get the most out of a 512MB VPS. Just have the GC logs written to RAM disk and have it rotate and you'll be amazed at what kind of useful stats you can generate.

You can see how I'm using it here:

http://screenshots.gitsense.com/jvm-monitoring.html

The 10 minute ratio stat lets me know how much time was spent doing garbage collection within the last 10 minutes.

... and VisualVM, and Flight Recorder + Java Mission Control, and BTrace/Byteman... the list goes on and on. If you need to, you can print out the assembly code generated by the JIT at runtime, modify your code on the fly, and see how the assembly changes. Erlang's BEAM VM has some of these capabilities, but not the JVM's performance. Other runtimes are decades behind.

> Other runtimes are decades behind.

To be fair, .NET also offers a similar level of support.

The only difference is that you have to pay for it, by getting Visual Studio Premium or third party tooling like dotTrace which plug into the CLR monitoring API.

For many people, the fact that they get such tools without paying a dime is a selling point for the JVM vs .NET.

Yes, .NET is excellent, too. But it's Windows only.

Many of us don't have a problem with it. :)

On my type of work, the tools are chosen by the customers, not me. So usually .NET in Windows only shops, JVM languages in heterogeneous shops, and a little sprinkle of C++ via JNI/Interop if really required.

I am curious, what type of app do you have running on the 512MB VPS? I use Java in my day job but I am considering using Python for a side project primarily because of a JVM-based app higher memory requirement.

It's a software that I'll be releasing soon:

http://beta.gitsense.com/index-dev.html

Note the test drive feature isn't working yet. I'm hoping to have this working in a couple of days. The try it now feature should be working and for that I create a 512MB digital ocean VPS instance for each trial request.

It's important to note my software doesn't use any web framework ... other than what I have built myself. This is probably one of the reasons why my program has a smaller memory requirement.

Everything is pretty much one layer above the servlet/rest layer. And the only time my program becomes memory hungry is when I do the initial indexing but once that's done, 512MB is more than enough to keep it happy.

If you know Java, I would personally use it for your side project since python will be unable to match it performance wise.

Edit:

I also forgot to mention that my product uses 3 JVMs. One for the webserver, one for my worker process, and one for the indexer.

This is HN. Trash talking anything Java related is image-enhancing amongst code fashionistas.

I use the JVM "as little as is absolutely necessary", which is often, thanks to technologies like Lucene, Hadoop, Storm, Zookeeper, etc.

And, "code fashionista"?

Hah, give me a break.

Python actually predates Java. I can't tell you how many times in the period 2005-2009 people derided me for using a "scripting" language for real work. All the "real programmers" used C++ or Java, of course!

Then, in 2009-2013, everyone suddenly realizes, oh, perhaps we don't need 200 classes per 1,000 lines of code and perhaps we don't need an IDE to that vomits boilerplate all day long and perhaps static types aren't such an important thing and perhaps generics are overrated and perhaps programmer time truly is much more expensive than machine time, ...

and, now I'm a "code fashionista" for still using Python for production projects, 6 years later? The "scripting" language that's so non-serious that it's used by thousands of production large-scale systems and scientists the world over?

Yes, that one -- the "fashionable" language. The one that isn't fussy and just gets work done.

Python is a language, and isn't any more concise than Groovy or Clojure. Also, if the "stuff" you need to get "done" is process a million transactions per second on a concurrent database that runs on a 64-core machine then it's completely inadequate. In all those companies I mentioned, Java the language's competitor is C++, not Python, and that's pretty much the language you can compare Java to.

Also, "everyone" is just most people in web startups, which are a very small minority of software developers with very specific needs. They usually work in small teams, so languages designed to help with large project management are not a requirement, but a very fast turnaround is. So, sure, Python is better suited than Java if those are your requirements. This is still just a tangent to the JVM discussion.

I don't think this is the case. After all, Twitter, LinkedIn, Netflix, Square, Foursquare and eBay are pretty much JVM-only shops, almost all of Facebook's important stuff runs on the JVM, as well as much of Google and Amazon. I don't think anyone honestly thinks the JVM is not very much in fashion.

I like the JVM but I really don't think the general population of programmers would call it fashionable. I have a friend who never visits HN but has a distrust for it even though his exposure to it was decades ago. The hardware back then was just not ready for it and it probably left some lasting scars.

I find that Java and the JVM is just something that you don't talk about, which is why it's never going to be fashionable. Useful yes. Fashionable, I'm not sure.

JVM a downside? I like the JVM. And I love Groovy. It has the easy syntax and familiarity of Java, but instead of using all the ugly stupid stuff of Java, you can also use all the cool fun stuff of Ruby. It's a very enjoyable balance with the best of both worlds.

I really like groovy, it seems to be a good sweet spot between the power of java and syntactic sugar. I just wish there were more framework options, like something between ratpack and grails. I dont want to use ORM or a heavy duty framework, but something a bit more structured than ratpack. Grails seems nice for what it is, but it just isn't what I need.

Groovy doesn't get enough love as a post java jvm language IMO.

I agree that grails is a bit heavyweight. The people at my former place did some work on using groovy with dropwizard: https://speakerdeck.com/kyleboon/webservices-with-dropwizard... which is seems to be more of a nice collection of libraries, rather than a box you in framework.

Groovy doesn't get enough love as a post-JVM language because they missed the static typing boat.

People that like static languages use Java, Scala, etc.

People that like dynamic languages use Python, Ruby (JRuby), etc.

Who's left over to use Groovy?

The people that like Grails and Gradle. Which is fine, but the popularity of the whole language is resting on these two frameworks, IMO, which seems precarious.

It's original thesis, a scripting language for the JVM, was interesting when it first started, but since then the JVM implementations of traditional scripting languages has gotten really good.

Personally, I believe that if they'd pivoted to static typing around Groovy 1.0, they would have been the Java next by now. They would have won.

They were years ahead of Scala. And it's always sounded like a great, working man's language/compiler, e.g. powerful AST/meta-programming/etc.

There were people in the Groovy camp who wanted to do this (the @Typed annotations that they have now), but it took too long, AFAICT, because the core committers had spent so much time convincing everyone that a dynamic language on the JVM was worthwhile that they didn't realize a static one would have taken their adoption to the next level.

My biggest complaint with Grails is its reliance on GORM - You can do sql, but it doesn't make it easy and the whole framework is really geared towards the ORM functionality and the opinionated view of the database and naming conventions. I need to be able to integrate with legacy data sets, and need more control over the database in general. Grails works well if your database is just a simple store for your application data.

I've used it with legacy applications with good success. If you really want, you can completely ignore GORM. Leave the domain directory blank, use command objects for your DAOs and DTOs. You can add your validation straight to command objects.

On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.

This is interesting - do you know of any examples out there of the structure you're talking about?

I've personally used it in a few hairy situations, but I haven't had to in a long time.

http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validatio...

(Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.)

It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.)

http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.

We use Grails purely for the convenience of its Views, Controllers, and Services. For the backend, we use Java - backed REST-like services.

It is trivial to remove the GORM/Hibernate dependencies from Grails.

If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.

That is my experience too, but I blame it on hibernate which GORM is just a dsl wrapper for.

Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.

Use Groovy SQL, it is as easy as:

Sql sql = new Sql(dataSource)

List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])

You can easily peel away the layers all the way down to direct SQL, completely bypassing GORM and Hibernate, when necessary.

You should definitely look at vert.x and possibly Spring Boot.

vert.x - http://vertx.io

Spring Boot - http://projects.spring.io/spring-boot/

There is a bit of buzz about Spring Boot in the Groovy space.

It's possible to wire up a micro webframework example with only a couple lines of code in Groovy.

Remember that Groovy, Grails, and Spring Boot are run by the same company, there might be some synergy between the latter two at some point.

> Remember that Groovy, Grails, and Spring Boot are run by the same company, there might be some synergy

It's because Groovy and its apps like Grails are part of the same company that many developers are afraid of creating anything web-related for Groovy that's not a Grails plugin.

Grails head Graeme Rocher was evn one of the 5 Groovy despots for 4 yrs, and didn't leave until a few months ago. This could have been what prompted the Play! 2 framework to purge itself of all its Groovy code.

If we are going all conspiracy territory on why Play dropped a language in favor of another, it would seem much easier to say that the controlling company of Play decided to drop support of a somewhat competitive alternative language for the JVM. :) No need to bring the stewardship of groovy into it.

Why exactly is that a reason to be afraid? What are they afraid of?

Grails 2.4 will have Spring 4.0 support. (Spring Boot is based on Spring 4) Of course there already is synergy in that you can reuse components between Grails and Spring, but things will be getting even better with Spring 4 and Grails 2.4:

http://grails.org/Roadmap

> I just wish there were more framework options

Grails head Graeme Rocher was one of the 5 Groovy despots [1] until a few months ago. He joined the despotry 4 yrs ago, which could have been what prompted the Play! 2 framework to purge itself of all its Groovy code. Groovy really needs its managers to be divorced from those developing the apps that use it, so others will join the ecosystem without being suspicious of what might happen in the future.

[1] http://xircles.codehaus.org/projects/groovy/members

Axe to grind, much? "Despots"? Really? What, do you work for Typesafe or Relevance or somebody with a vested interested in slagging Groovy, or what?!??

They call themselves "despots" in the link you replied to. Btw, I don't work for any company with a vested interest against Groovy, but am reimplementing Groovy as a side project. I think Groovy and its apps like Grails should be kept separate if they developers to build things using Groovy, like in pretty much every other language.

Interesting. I'm guessing that was meant to be mostly tongue in cheek, much like referring to Guido as the "Benevolent Dictator for Life" of Python.

Btw, I don't work for any company with a vested interest against Groovy, but am reimplementing Groovy as a side project.

Sounds pretty cool. Looking forward to seeing what you come up with!

You are not using that word like they were. So stop.

For anyone interested in using Groovy for web development, checkout our product (www.crudzilla.com)

here's a short video demoing coding in Groovy and other jvm languages:

http://www.youtube.com/watch?v=AqeOS2hqtMg

We use JSR-223 to support the various languages

I'd like to learn more, but your website is very scant on details. All I can tell is that it allows me to code in the browser and has quite a few screenshots, but how about a technology overview?

Our company inherited a Grails project, and I had to help the developer out occasionally.

Frankly, Grails seems horrible, especially since it mixes the nice language that is Groovy with just craptastic JVM stuff.

Is there any other mature framework for the language? I have a feeling Groovy is wasted for Grails.

> Is there any other mature framework for the language?

No. It's because Groovy and Grails are part of the same company that many developers are afraid of creating another web framework using Groovy.

Grails dictator Graeme Rocher was even one of the 5 Groovy despots for 4 yrs, and didn't leave until a few months ago. This could have been what prompted the Play! 2 framework to purge itself of all its Groovy code.

Unfortunately, Groovy project manager Guillaume Laforge uses "and Grails initiator" in this title, perhaps not realizing the message that sends to people thinking about using Groovy for something web-related but not part of Grails.

You keep repeating the same thing all over this discussion, are you?

Ratpack, Graffiti, Gaelyk, Portofino. It's hard to judge something as "mature" because this is often synonymous with bloated, filled with magic, etc. So for my money, lightweight frameworks like Sinatra for Ruby are more mature that Rails. Most languages have frameworks inspired by Sinatra, or in Python, frameworks that preceded the whole Rails and framework hypestorm.

Ratpack, though very cool, should not be considered mature. The API has has not even stabilized for a 1.0 release. (Because Luke & team are working very hard to make it a great API)

I love Groovy, and am excited about this release. Pretty much our entire app stack is based on Groovy + Grails, and that's one decision that I basically could not be happier with. Switching from Java + (Struts|Wicket|Tapestry|Spring MVC|whatever) to Grails & Groovy has worked out amazingly well for us.

Not to say Groovy is perfect, as it's not... the performance could still stand to get better, for one thing. But it's "good enough" for what we're doing, and I do expect the situation to improve over time.

Where did the traits go? The wording seems rather definite in this announcement and rather lengthy mailing discussion [1] in June this year:

> We're looking forward to implementing an often requested feature: traits! Our existing @Mixin transformation isn't ideal as it's bug-ridden and hard to properly fix, and has the drawback that Java frameworks don't "see" the mixed-in methods -- like the recent thread related to Spring MVC showed. So having an AST transformation that would be "static" would help in such situations.

The feature list in 2.2 is fairly sparse for a point release, and still no traits and the mixins are still buggy and unable to see mixed-in methods.

[1] http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td...

I'm wondering how easily Groovy will retrofit Java 8 lambdas when they come out. Groovy uses syntax

    {a,b-> a++;a+b}

for closures, whereas Java 8 uses syntax

    (a,b)->{a++;a+b}

Also Groovy uses delegates to make its closures dynamically scoped, whereas Java 8 uses lazy evaluation for its lambdas.

They're incompatible, both syntax and semantics.

According to the Roadmap, they are planning on retrofitting Java 8 syntax in Groovy 3.

I use Groovy quite a bit and like it a lot. I wish there was an easy way to use it with Android, I'd really like the groovy JSON or XML parsing libraries even if it meant I had to run my program on a device with Android 4.3 and at least a gig of ram.

I would use Kotlin for Android over Groovy, because it is

- Much more lightweight and faster than Groovy

- Statically typed

- Offers about the same level of expressivity as Groovy (closures, etc...)

- Much, much faster than Groovy

The only downside is that it's still in beta, but already working great and, obviously, with awesome IDEA support.

It seems like most people are excited for kotlin, but no one is really talking about ceylon which recently 1.0. Im curious why that is, have you looked at ceylon?

I have, it's definitely an interesting language, more ambitious than Kotlin and more bold too (lot of new keywords, disjointed types, etc...).

I prefer the most conservative, slightly incremental Kotlin myself, but it's purely personal and certainly not a knock on Ceylon, which was implemented by people I have a lot of respect for.

> most people are excited for kotlin, but no one is really talking about ceylon

Perhaps that should be "most Groovy people are excited for Kotlin". The reason "Groovers" look at Kotlin before Ceylon could be because Groovy creator James Strachan and Groovy++ creator Alex Tkachman jumped over to Kotlin.

I have experienced exactly the opposite of this. Nobody seems interested in using Kotlin, while I think it is pretty neat.

Kotlin is not an option for me. Android studio is completely inaccessible with my screen reading software as far as I can tell and there isn't an Eclipse plugin yet. Scala looks like my best bet and it's a reason to learn the language

Try Xtend: http://www.eclipse.org/xtend/ (Also see: http://blog.efftinge.de/2013/10/xtend-android-sneak-preview....)