On Problems with Vala

If you’re going to be writing a new application based on GNOME technologies and targeting the GNOME ecosystem, then you should seriously consider writing it in the Vala programming language.

That’s a pretty controversial statement! Emmanuele just told us that Vala is dying and that you should find an alternative. So, if I’m recommending that you start writing new applications in Vala, clearly I disagree with him at least somewhat. Even so, I actually think pretty much all of Emmanuele’s points are correct. Vala really is dying! The status quo really is pretty bad. Using a dying programming language to write your application is rarely a good idea. You should think twice before doing so.

Still, I wouldn’t be so quick to write off Vala. For one thing, it’s a pleasure to use. The design of the language is very good. The integration with GObject and the GNOME ecosystem, from GObject signals and properties to native support for D-Bus and composite GTK+ widget templates, is second to none, and will probably never be surpassed by another language. It’s hard to understate how good the syntax of the language is, and how tailored it is for GNOME programming. People like Vala for good reasons.

Emmanuele says that it’s time to look at alternatives to Vala, but the alternatives we have to Vala right now have big problems too. If I were to start writing a new GNOME app today, Vala is still the language I would use. So now I have to try to convince you of that! First, let’s look at current problems with Vala in more detail. Then, let’s look into the alternatives we have available.

The problems with Vala are real and very serious, so I can only give it that qualified recommendation. The Vala community is slowly dying, and I would not recommend starting a big, complex application in Vala today, given the risk that the compiler might be completely unmaintained in a few years. But most GNOME applications are fairly small — only a few, like Builder or Evolution or Epiphany, are big and complex — and I think most will probably do well enough in the long run with Vala even if the Vala compiler stops improving.

Problems with Vala

Yeah, I’m afraid this is not going to be a short post. Let’s take this in two: first, common complaints that I don’t think are actually serious problems, and second, the actual serious problems.

Minor Problems with Vala

Let me start off by pointing out a couple things that I don’t consider to be serious problems with Vala: bindings issues and tooling issues.

People often complain that there are bugs with the bindings. And there are! Debugging bindings bugs is not fun at all. But I get the impression that bindings complaints are generally about the state of the bindings five years ago. The bindings situation is a lot better now than it was then, and it is constantly improving. Vala bindings actually are well-maintained (thanks mostly to Rico Tzschichholz); it’s only the compiler itself that is having maintenance problems. And most of the bindings problems are caused by introspection issues in the upstream libraries. That means that if you’re hitting a bindings problem in Vala, it’s probably a problem in every other language you might want to use as well… except C and C++, of course. And bindings issues are actually arguably far easier to debug in Vala than they would be in Python or JavaScript, since you can look for errors in the generated C code. Fixing bindings is generally easy, and you can work around the problems using a drop-in vapi file if you can’t wait to get the fix upstreamed. Adding new bindings is work if the library is not introspectable, but much easier than it is in other languages. No doubt programming would be nicer if bindings were not necessary, but unless you want to write everything in C or C++, bindings are a fact of life that won’t go away, and Vala’s are pretty darn good.

As far as tooling: it’s true that the Vala ecosystem does not have great tools, but I don’t think this is really a horrible problem. The most common complaint I see is that debugging requires looking at generated C code, and there’s no special Vala debugger. Now, in the case of crashes, it usually does indeed require looking at the generated code. But, in my experience, crashes are much, much rarer in applications that are written in Vala, so we’re going to be spending a lot less time in the debugger than we would when working on C applications anyway. And debugging the generated code with gdb isn’t so horrible. It’s hardly a great experience, but you get used to it. Be sure that you’re using vala -g to emit Vala line numbers into the generated code, otherwise you’re just making your life unnecessarily difficult. At any rate, gdb plus line numbers is the way to go here. Vala debugging is never going to be as simple as C or C++ debugging, but you’ll have to do less of it than you would in C or C++, and that’s a reasonable trade-off.

Another problem with Vala is that it suffers from the same safety issues as C and C++. You will make mistakes, and your mistakes will allow remote attackers to take control of your users’ computers. Vala doesn’t do anything to avoid buffer overflows, for instance. That’s pretty bad. But you will at least make fewer mistakes than you would in C or C++. For instance, I believe the language makes refcounting errors an order of magnitude less likely, drastically reducing the number of use-after-free vulnerabilities in your code. Compared to Rust or Python or JavaScript, this is not very good at all, but compared to C or C++, it’s excellent.

Major Problems with Vala

I see two serious problems with Vala. The first is that the compiler has bugs, and debugging compiler bugs is very unpleasant. The second is that the compiler is not well-maintained. Like Emmanuele says, the Vala community is dying, or, if you want to be generous, at least not in a very healthy state. So when you report compiler bugs, probably nobody is going to fix those bugs. This can be very frustrating.

Vala Bugs

I can confidently say that Vala has more bugs than any other programming language you might be considering using for GNOME development. It’s sad, but true. Most of the bugs are just small annoyances; for instance, bugs in which the Vala compiler emits C code that does not actually compile. These are usually easy to work around, but that can be pretty annoying. Other bugs are more serious. For instance, see signal handler spuriously runs when signal is emitted by object not connected to once every 98 emissions (which was fixed a few years ago, but a good example of how Vala bugs can cause runtime problems) or Incorrect choice of signal marshaller causes crash when promoting a pawn in GNOME Chess when built with Fedora or Debian hardening flags (still broken).

Of course, all bugs are fragile if there is an active community of developers fixing them. But, as Emmanuele has already pointed out, that is not going so well.

Vala Maintainership and Community

Vala’s greatest strength — its focus on GNOME — is also its greatest weakness. Vala is not very interesting to anyone outside the GNOME and GTK+ development communities. Accordingly, the community of Vala developers and maintainers is several orders of magnitude smaller than other programming language communities.

Relative to the fairly small size of the GNOME ecosystem, there are actually a very large number of Vala applications in existence. (All of elementary’s applications use Vala, for example.) So there is a relatively large number of Vala application maintainers with a stake in the success of the Vala project. But they’re mostly focused on developing their applications, not Vala itself. A programming language is probably not the greatest tool for any job if it requires that you participate in maintaining the compiler, after all. And the barrier for entry to Vala compiler development is high. For starters, compilers are difficult and complicated; working on a compiler is far more difficult than working on desktop applications. Moreover, of the people who are motivated to contribute to the compiler and submit a patch, most probably get discouraged pretty quickly, because most patches posted on Bugzilla do not get reviewed. There are currently 179 unreviewed patches in Vala’s request queue. The oldest patch there is 2,556 days old, so we know that it’s been seven years since anyone has cared for the outstanding patches. Any of those discouraged contributors might have eventually turned into Vala maintainers if only their patches were reviewed. Of course, most would not have, but if only one or two of the people who submitted patches was an active Vala maintainer today, the project would be in a significantly better state. And I see patches there from a large number of different developers.

But who can review the patches? Vala needs more maintainers. Rico is taking good care of the bindings and appears to be committing patches to the compiler as well, but he’s just one person and can’t do it alone. Vala stakeholders need to increase investment in the compiler. But this is a familiar problem: the majority of our modules need more maintainers. Maintainers do not grow on trees. Ideally a company will step in to support Vala compiler development, but few companies seem to have taken an interest in Vala, so this doesn’t seem likely. This is unfortunate.

I frankly expect that Emmanuele’s prediction will prove true, and that the Vala situation will only get worse in the next five years. It’s more likely than not. But I’m not very confident in that guess! Several people have contributed significant patches to the Vala compiler recently. (Carlos Garnacho, you have earned much beer.) The future is still uncertain. I very much hope that my pessimistic expectation is proven wrong, and that the maintainership situation will improve soon.

But while the Vala compiler may stagnate, it’s probably not going to get worse. I think it’s good enough for writing GNOME applications today, and I expect it will still be good enough in five years.

Alternatives to Vala

So Vala is not in great state. What else can we use to write GNOME applications? The only serious programming languages in the GNOME ecosystem are C, C++, Vala, Python (using PyGObject), and JavaScript (using gjs). No, I did not miss any options. If your favorite language isn’t listed there, it’s either because (a) it doesn’t have decent GObject bindings, or (b) the language is not popular at all. To my knowledge, all GNOME software is written in one of those five languages, except for a couple old applications that use C#. And the state of C# in GNOME makes Vala look like an active vibrant language. If you want to start writing a GTK+ 2 app in 2017, go ahead and use C#. The rest of us will restrict our search to C, C++, Vala, Python, and JavaScript.

(Tangent time! Rust is trendy, but I’m told it needs more help to improve the GObject bindings before we start using it in applications. I’m hoping that it will emerge as the superior option in the not so distant future, but it’s definitely not ready for use in GNOME yet. It has to have better GObject integration. It has to have some degree of ABI stability, even if it’s limited. Dynamic linking has to be the default. It’s not going to be successful in the GNOME community otherwise. You should join the Rust folks and help out!)

Let’s start with C. C is undoubtedly the most popular language used in GNOME programming, but it would be flatly irresponsible to choose it for writing new applications. I enjoy writing C, but like everyone else, I make mistakes, and I think it would be desirable if my programming mistakes did not allow attackers to execute arbitrary code on your computer. It’s also extremely verbose, requiring far more lines of code to do simple things than the other programming languages that we’re considering do. C is not a reasonable option for new applications in 2017, even if it is the language you are most familiar with. I wouldn’t go so far as to say that our existing applications need to be rewritten in a safer language, because rewriting applications is hard and our developer community is small, but I certainly would not want to start writing any new applications in C. We need a C migration plan.

Modern C++ is a bit safer and much more pleasant to use than C, but that’s really not saying all that much. Footguns abound. You have to know all sorts of arcane rules to use it properly. The barrier for entry to new contributors is much higher than it is with C. Developers still make lots of mistakes, and those mistakes still allow remote attackers to take control of your users’ computers. So C++ is not a good choice for new applications either.

Python… OK, I suppose Python is pretty good, if you’re willing to give up compiler errors and static typing. I prefer to use a compiled language for writing serious software, because I make a lot of mistakes, and I’d rather the compiler catch those mistakes when possible than find out about them at runtime. So I would still prefer Vala. But if you prefer scripting languages, then Python is just fine, and doesn’t suffer from any of the disadvantages of Vala, and you should use it for your new app. Some developers have mentioned that there are some gotchas and interoperability issues with moving between Python APIs and GNOME APIs, but no programming environment is ever going to be perfect. PyGObject is good enough, and I’m pretty sure we’re going to be using it for a long time.

The last option is JavaScript. With all due respect to the gjs folks — and Philip Chimento in particular, who has been working hard at Endless to improve the JavaScript experience for GNOME developers — there’s no way to change the reality that JavaScript is a terrible language. It has close to zero redeeming features, and many confusing ones. You use it in web browsers because you have to, but for a desktop application, I have no clue why you would choose to use this over Python. We have to maintain gjs forever (for some value of “forever”) because GNOME Shell uses it, and it’s also being used by a couple apps like GNOME Weather and GNOME Documents. But it should be your last choice for a desktop application. Do not use JavaScript for new projects.

Another disadvantage of using JavaScript is that there is a huge barrier to entry for newcomers. But wait, lots of web developers are familiar with JavaScript; wasn’t the whole point of using it to lower the barrier of entry to newcomers? Well look how well that worked out for us! We have approximately zero new developers flocking to work on our JavaScript applications. The only documentation currently available online is over three years old, covers only a subset of the introspectable libraries that you want to use, and is frankly pretty bad. Unless opening gir files in a text editor and reading internal gjs unit tests to figure out how to call functions sounds like a good newcomer experience to you, then we need to steer far clear of JavaScript. The documentation situation is a fixable problem — Philip has much improved documentation that’s just waiting for hosting to materialize — but there’s no momentum to fix it right now, and the defects of the language can’t ever be fixed.

So all of the alternatives to Vala have big problems too, except maybe for Python, which is not a compiled language, which many of us would consider a serious disadvantage in itself. If you don’t want to use Vala, you have to pick one of the alternatives. So which will it be? I have no doubt that many or even most of our community places different weight on the various advantages and disadvantages of the languages. I actually expect mine is a minority opinion. But at the very least, I think I’ve shown why Vala still seems attractive to many developers.

(Note that the above analysis does not apply to libraries. You cannot write a system library in Python or JavaScript. You can do so with Vala or C++, but it requires special care. GNOME platform libraries must have a C API in order to be introspectable and useful.)


If you ignore its bugs and its maintainership status, Vala is by far the best language for writing GNOME applications. But those are pretty big things to ignore. I’d still use it anyway. It’s hard to understate how pleasant it is to develop with. The most frequent complaints I see are about problems that I don’t actually consider very serious. I don’t know. I also don’t know what the language of GNOME’s future is, but I do know that we need to stop writing new applications in C, and until GObject integration for Rust is ready, Vala still seems like our best shot at that.

20 Replies to “On Problems with Vala”

  1. Nice read! Thanks for the disclosing other side of Vala. I totally agree with you.

    In a long run (5 year), I expect that Vala will be dead, Rust must be a way to go (because of wider support and active development). But I’m afraid the desktop will be more “webby” for next five years and Rust hackers will prefer cross-platform Electron-like tool-kits over Linux-focused GTK. We should be ready for that as well.

  2. It seems as though the primary downside with python is actually that it’s dynamically typed, rather than that it isn’t compiled? They are making some progress on that front [1, 2], but it’ll take a while for it to become widely used: it only really made it into python 3.6 and the type checkers themselves, which are separate to python, still need some work. Still, it’s something to keep an eye on if that’s the biggest issue….

    [1] https://www.python.org/dev/peps/pep-0484/
    [2] https://www.python.org/dev/peps/pep-0526/

  3. > I suppose Python is pretty good, if you’re willing to give up
    > compiler errors and static typing. I prefer to use a compiled
    > language for writing serious software, because I make a lot of
    > mistakes, and I’d rather the compiler catch those mistakes when
    > possible than find out about them at runtime.

    I don’t want to start a “dynamic vs static” typing war here, but to be fair when writing serious software I follow the adage of “if it’s not tested, it doesn’t work”. A solid test suite and 3rd party static analysis tools can catch pretty much all the same bugs your C compiler would have caught. Also, Python 3 now has a type checker! http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/

    That said there are performance implications to using Python (mostly high & unpredictable memory usage) that you don’t get with C or Vala.

  4. – When you say “compiled language” you most likely mean statically typed. Being compiled and statically typed are orthogonal properties of a programming language (and you could even argue that “compiled” is a property of the implementation and not of the language itself).

    – I don’t really understand why you make such a huge difference between JavaScript and Python. The difference in quality between the languages really pales in comparison to the big problem / elephant in the room which is dynamic typing.
    What Python with GObject has over JavaScript though is good documentation.

    – In all I think you make pretty good points, both for and against the use of Vala in future projects. Personally I’ll stay away.

  5. I’ve been very happy with using D for Terminix (https://gnunn1.github.io/terminix-web), it has good GTK bindings via gtkd (http://gtkd.org) and the maintainer does a great job of keeping them up to date with the latest GTK versions. It also easily interfaces with C libraries for those rare cases the binding is missing something.

    The nice thing with D is that anyone familiar with a language in the C family (C, C++, Java, etc) won’t have any issue with picking it up. Rust on the other hand has quite a learning curve associated with it.

    I think D is a great choice for GTK applications (but not libraries, I think C or Rust is better there).

    1. If you write C++ applications in a modern style with gtkmm, you will generally not be mucking around with pointers. I wrote a couple of such applications more than 10 years ago and didn’t have to free memory directly at that time, and the standard library has only improved since.

      The experience is not close to C at all – if it is, you are holding it wrong. All the stuff about multiple inheritance and whatnot – forget it, don’t use inheritance, use classes where it makes sense, but otherwise store stuff in PODs and use functional decomposition. Life will be simpler, like with C, but with a lot of dangerous stuff handled automatically. Templates are complicated, but only if you need to write them yourself, the container types given by the standard library should be sufficient these days.

      I have never written a line of Vala, but looking at the examples now, it seems to me that you can write relatively similar code in C++ with gtkmm.

      Yes, there’s some old garbage in C++ that you’ll need to ignore or get over, but really, if you like static typing, don’t let stigma hold you back.

      Personally I really think duck-typing in Python is underrated. You need some time to adjust, but it is so much easier to write generic code in Python quickly.

      It’s true that the static type checking can find some stuff for you, but it’s not a free lunch, you have to hold its hand for this to work. For instance, if you code GTK+ with C, you’re going to be doing so many casts that you aren’t really much better off than Python. If you wrote the equivalent program in C++ with gtkmm, it would be able to catch many of these problems automatically but only once you have helped it by writing out the types.

  6. The problem with Javascript isn’t the language – it’s that most of the people who code in Javascript are web developers. And web developers are the kind of people who tend to write browser-based web apps, not native desktop applications using platform-specific libraries…

  7. I wish we would hear something about this topic from juergbi. I recently started to work on a c++ project for university and must really say, modern c++ is the way to go. If you find a pointer in modern c++ you are doing it wrong. And if you compare Qt Creator with Gnome Builder you will be astonished by that neat piece of IDE the Qt folks created.

    1. You’re writing C++ without using pointers…?

      Of course, use references whenever possible, since they can’t be null, and always hold ownership in smart pointers. But when you want to pass/hold a value that can be null without transferring/holding ownership, you need to use a raw pointer.

      1. Yep, I only use raw pointers to indicate observation.

        Not that I care much personally, but it’s hard to believe none of the std::experimental::observer_ptr type things got into C++17. All that many other people want is a semantic way to indicate, without any ambiguity, that the pointer definitely has no ownership role. The fact that something so trivial hasn’t gotten in is rather strange.

        Then again, relatively few things got into C++17 overall, so…

        1. Foo* seems to me like a much easier way to indicate “no ownership” than std::observer_ptr.

  8. While I know it isn’t (hugely) poular and I know it has really bad bindings (right now), but it’s python-alike syntax, the fact it is compiled (in fact it compiles down to C) and with it’s (hygienic) macros makes Nim a serious contender to Vala, specially taking into account GNOME would only take care of it’s own libraries, not a whole language + tooling. Yet, I’m sure the fact it isn’t trendy will cut ut oif as an option.

    BTW: there’s any reason (other than bindings) for Go not being more popular inside GTK application development? people seem to use it quit happily.

    1. I’ve never heard of Nim.

      Last I checked, Go was still a static-linking ecosystem. Unless that’s changed, it’s not going to gain any traction in the GNOME community.

      1. So, just in case someone is interested here’s the Nim website: https://nim-lang.org/.

        BTW, didn’t mention crystal, ruby’s compiled cousin which supports “optional” typing (though in some places it is actually required): https://crystal-lang.org/

        After looking a lot of programming languages, those two are the ones that are compiled which I would recommend today to write applications.

Comments are closed.