Vert.x 1.0 released with its Groovy support

Tim Fox yesterday announced the release of Vert.x 1.0.

Vert.x is a kind of asynchronous application development environment and server. It works on the JVM, with JDK 7, and supports several languages like Java, Groovy, Ruby or JavaScript.

As the website puts it, vert.x can be defined along the following axis:
  • polyglot: supporting Java, Groovy, Ruby and JavaScript or a mix and match of any of these even in a single application
  • simplicity: just a few lines of code to create your servers and components, without any XML configuration or anything like that, without being too simplistic
  • scalability: with Netty under the hood, with a message passing approach, it's taking full advantage of the cores of your CPU(s)
  • concurrency: vert.x provides a simple concurrency-model so you don't mess with traditional multithreaded programming
Vert.x competes directly with Node.js here, and Tim also positions it against the Play! 2 / Akka combo.

What's also worth looking at is the benchmark that he ran against Node.js, showing that vert.x clearly outperforms Node.js. Also interesting is the fact that when using Groovy, there's just a very small overhead over using Java, although the simple benchmark didn't even use the upcoming static compilation feature of Groovy 2.0.

Congratulations to the vert.x team for the release!

I'm impatient to play with it on Cloud Foundry, once it supports JDK 7.

Why coming to #GR8Conf?

I was reading MrHaki's interview on the GR8Conf website this morning, and he had some nice words and good points about why it's important to attend the conference. You get to meet the creators and developers of the projects you're interested in and have great content (emphasis mine):

I am looking forward to meeting all the great people that make up the Groovy ecosystem. Everybody is always nice, friendly and ready to help. The atmosphere is always nice and laid back

The presentations always are high level and mostly done by the creators of the projects and frameworks. So the information is really from the source and that means you always get the latest information first at the conference.
And on what attendees should expect (again emphasis mine):
If you are using Groovy, Grails, Gradle or any of the other Groovy-related technologies, or you plan to do so, you should really come to the conference. This is your chance to meet the people that create the great products and use it in their daily development. You will get inside information and experience real-life usage of these technologies.

After the conference you will be inspired and ready to apply your newly learned knowledge in your daytime job or projects.
I'm looking forward to meeting you there!

Slides for Domain-Specific Languages in Groovy

During the Cloud Foundry Open Tour conference in Moscow, I presented a new presentation of Domain-Specific Languages in Groovy. I've already shared the link here and there (twitter, Google+, mailing-list), but not yet on my blog. So consder this fixed now. This new presentation is inspired from the beta DSL chapter from the second edition of Groovy in Action, where you'll learn how to create a DSL for a little Mars robot. This is a pretty practical approach, bottom-up, as you progressively build the DSL, rather than listing all the existing techniques and illustrate them. I feel the flow is a bit better that way. Anyway... enjoy:

Run a Groovy script in Vi

In the Vi vs Emacs war, I'm in the Vi camp. I'm using Vim on the command-line to quickly edit files, and I'm also using MacVim on my Mac as my text editor. When I'm not using an IDE or the Groovy Console, I also want to be able to edit and run my Groovy scripts in my text editor. It's not too difficult to run a Groovy script from Vi, you can simply do:
:!groovy %
You use the colon to enter the command mode, then use the bang to issue a shell command. Here, obviously, I'm going to run the groovy command. And I can then pass the script I'm editing as parameter thanks to the percent sign, which points at the current file in my buffer.

The drawback is that the output is the command area, but I wanted to get the output in its own buffer. So I spent a bit of time to flesh out my Vi skills, and came up with a function to open a new scratch buffer and output the result of the script execution in that new buffer, with the following script that I added in my .vimrc configuration:
// the function to run my groovy scripts
function! RunGroovy()
    // copy the current buffer file name in a variable
    let gfname=@%
    // open a new buffer in my window below
    botright new
    // define the buffer to be a mere scratch buffer not intended to be edited or saved
    setlocal buftype=nofile bufhidden=wipe nobuflisted noswapfile nowrap
    // create a temporaty file name to hold the output of the execution of my Groovy script
    let gtmpf = tempname()
    // define the command line to launch my Groovy script and retrieve its output in the temporary file
    let gcmd = ':!groovy ' . gfname . ' > ' . gtmpf
    // execute the groovy command
    silent execute gcmd
    // insert the content of the output from the temporary file in my buffer
    silent execute '0r ' . gtmpf
endfunction
// add F5 as the shortcut for executing my Groovy scripts
map   :call RunGroovy()
I'm definitely not a Vi expert, and this script can be improved greatly probably. But it's good enough for now. But I'm open to improvements if the Vi experts reading this blog want to join in and give me advice!

Groovy at Devoxx France

Last week saw the first edition of Devoxx France. And what a success it was! The conference was sold out at 1200 persons. There was a great wealth of interesting topics and many passionate attendees to talk to. Overall, I come back home impressed that the first edition worked out so well, flawlessly, and was such a joy to attend. So a big thank you and congrats to all those involved in making Devoxx France such a great event!

Along with Cédric Champeau, I had the pleasure to present the novelties of Groovy 2.0 (and a bit of retrospective on some of the key features of Groovy 1.8). We covered quickly the invoke dynamic support and modularization, and went into more depth into the static type checking and static compilation aspects.

I've pushed the slides of that presentation on Slideshare, please see below for the embedded presentation.

What was also interesting was to update my informal benchmarks which looked at the performance of Groovy in a certain number of situations: 
  • without particular improvements (ie Groovy 1.7 and before), 
  • with the primitive optimizations (Groovy 1.8), 
  • and with static compilation.
The results are pretty good and show that in static compilation mode, Groovy's performance is as good as Java in most cases. There are still some improvements we can make, some bytecode to clean up, some bugs to iron out, etc, but overall, the goal of attaining Java's performance is reached.

For my benchmark, I took some Java implementations of the Fibonaci suite, the calculation of Pi (quadrature style), and a binary tree implementation. I converted them to Groovy (often, it's just a file extension rename, plus removing some semicolons for good measure), without really trying to optimize them in a Groovy manner. And the results I got looked as follows:

Fibonaci Pi (quadrature) Binary trees
Java 143 ms 93 ms 4.5 s
Groovy with static compilation 145 ms 96 ms 6.9 s
Groovy with primitive optimizations 271 ms 103 ms 29.6 s
Groovy without optimizations 3200 ms 2590 ms 50.0 s
So that's pretty good news for those who are looking for performance, and more generally it'll benefit anyone as well in any case.

And now... the slides!
 
© 2011 Guillaume Laforge | The views and opinions expressed here are mine and don't reflect the ones from my employer.