We’ve all heard the rants: Mono has patents, Microsoft releases community promise, community ignores, flamewars continue. Enough to make any developer want to stop programming out of sheer annoyance. Mono is an excellent language and platform; there’s nothing anybody can do to change that. People will continue to develop C# apps, and those that continue to hate Mono will continue to complain.
There was always one thing about Mono/C# that I wondered: why does it have to use a JIT or a runtime? It seems like the sort of language that you could just compile and forget about. Perhaps I was a little naïve; Mono provides a lot of benefits like managed memory.
_And then here comes Vala Saunters into the room like it owns the place. Claims to be that magical language that translates C#-ish code to C with a little help from GLib and GObject. What?! Skeptical, over the past couple of months I decided to give this fancy language a try.
And I am left stunned. Vala code is very easy to write, and compiles without a complaint. It feels a lot like C#. Being a Python programmer, actually writing in this language felt really new, yet somehow familiar. Time to summarize!
It’s a runtime without a runtime. Vala, true to its word, converts the source to C and compiles it. Memory and variables are all managed using GObject. Opened files and resources are closed automatically. Less and less do I have to worry about a leaky application. Sure, it requires the GLib library, but that is almost as ubiquitous as the standard C library on free software desktops.
The bindings! This is the real sweet spot. Since Vala code appears as C to the target machine, that means that almost all existing libraries can be made compatible. Vala bindings can be as simple as a single file. 200 lines is all it takes to bind to WebKit. On top of that, it was automatically generated! Thanks to GObject introspection, bindings for many GObject-based libraries can be entirely automatic. That’s smart.
It has nice error messages, unlike GCC. This alone might be a compelling reason to switch. ;-)
There are cases when Vala doesn’t quite hit the target. Granted, it’s still under active development and hasn’t hit a 1.0 release yet. While it is pretty good at catching potential programming issues, there are cases where some errors might slip by and you are left with debugging C source. This is mostly when you have a stray reference or unowned variable that goes berserk.
Speaking of C sources… they aren’t very pretty. _tmp_ variables are thrown all over the place, and the memory management code seems to take up a bulk of the source.
If you’re looking for documentation on Vala, well… you might be looking for a while. There is a constantly updated tutorial and a plethora of examples, but I wasn’t able to find anything that really went in-depth. Installing Devhelp and looking through C documentation helped out. The fact that the bindings’ VAPIs are fairly readable makes them a good place to look for function definitions, but explanations might be hard to find. If you’ve a C# or Mono programmer, Vala shouldn’t be much of an issue. Someone like myself who hasn’t worked with a C#-like language might be baffled for a few moments understanding how things work. Again, since Vala is constantly changing, it could be difficult to keep documentation up-to-date. But it would certainly be a nice thing to have.
All in all, Vala is a pretty sweet language. If you’ve ever had an interest in C#, I highly suggest you check it out.