Month: February 2017

Yes is time to consider a Vala 1.0 release. Vala 0.34 code generator and bindings support LTS versions of GTK+ 3.22 and GLib 2.50. Next stable version of GTK+ will be 4.0 and GLib 2.x, but they have to traverse through 3.9x versions and any GLib 2.x on the way. Reaching that point we can consider Vala 2.0 release.

Traditionally a new Vala version is released along with GLib and GTK+, with bindings updates, from them and other projects. Some times, is necessary to change some Vala syntax or implementations, like threats, in order to be in sync with current GLib/GObject/GIO features. Because this, may we can consider to increase Vala API each stable version of GTK+.

In order to reach Vala 1.0, may we should identify stoppers bugs before to go. Some of them can be related to GNOME Builder, but may is not a real problem is you don’t use it for Vala development. I really would like to file, find and send patches for some of them, producing warnings at C compilation, for a better experience.

A road map could be stated at Vala’s Wiki, in order to track that stopper bugs/features to fix/implement before 1.0 release. This will mark a good stand point for any developer using Vala.

Debian is around corner. It supply Vala 0.34, then it should be considered, and backport fixes, as a LTS version.

Vala provides you a way to write C/GObject/GInterface code using a different syntax. Vala doesn’t require to develop a “core library” in order to provide its features. Its “compiler” is not a compiler, is a C code generator.

Vala can’t be compared with Rust, Go, Python, Java or C#, all of them provide their own “core library” in order to provide most of their features, allows you to create modules (like a library) to extend the language for their users consume. Their core generally is written in C, for very basic features, but almost in the language itself.

Vala is different in many different ways to other real programming languages. Vala can’t exists without GLib and GObject. It just wraps that libraries to provide its Object Oriented syntax. It doesn’t provides any feature by it self, just a syntax to use the ones already present in above libraries, a part to provide some convenient methods to reduce coding boilerplate.

GLib, GIO and GObject are C libraries. They are the basis for GNOME, GNOME Shell and any other application using GNOME technologies. GTK+ and any library or application using it, relays on above libraries, they can’t exists without them. VMWare and LibreOffice consume GTK+ and so GLib/GObject.

Vala provides mechanism to create bindings. They are conventions to help Vala’s code generator to produce correct C code to consume any other, apart of GLib/GObject, libraries. It can do better job if the library use GObject.

Vala is not a Language: This is a conclusion after the On Vala article, comparing Vala’s repository’s activity with other real languages.

May we need to add to Vala’s activity, all commits and developers on GLib, GObject, GTK+ and GObject Introspection, because they are, indirectly, supporters of Vala’s features and usefulness; may be we need to consider all other libraries’ activity, like libsoup, libgda, and any other one supporting GObject Introspection, because they can be consumed by Vala; this is specially true if we consider their support to generate, automatically, Vala bindings.

Considering all of these, if Vala was a real language: it can be considered to be one with a very reach, secure and stable “core”, with years of development behind; with a reach set of other libraries for your use, as a developer, to choose from. But again: Vala is not a Programming Language.

Vala is multiplatform as long as its Code Generator and their libraries it depends on, or can bind, are present in your target platform: Windows and OS X, are just examples.

May is time to update Vala’s README and vala.doap at git.gnome.org, in order to avoid missunderstandings.