This post is based on my experience on not just using but creating and maintaining Vala libraries.
Rust is on the horizon and have voices to use it instead Vala. For Vala, we can say, is true to be niche oriented language, because it just create GObject based applications and libraries. For Rust, it has a more general purpose, with save concurrency and save programming: true again.
I have downloaded Rust to start using it, because seems to be very convenient for C development replacement, specially may be suitable to replace old libxml2 library, hopping some some have started to write an XML parser and writer, I can re-use in my own projects.
After taking a time to check at Rust documentation and write a post about GObject and Rust, I would like to share my thoughts about Vala and Rust.
Vala have a very specific target: GObject. We can use Vala to create GObject classes and define API interfaces using GInterface, but in a sugar and very productive syntax. Doing Object Oriented Programming using Vala and GObject is easy and natural.
I’ve managed to get W3C set of API interfaces based on specifications for DOM and SVG, because Vala provides a kindly close interface definition syntax to the ones from W3C. Implement them have been a matter of, you know, work. W3C interfaces are really complex in a way of their relations ships and dependencies, which should be very difficult to implement if doing in C and GObject/GInterface. This is not false for Rust, because it doesn’t have a GObject/GInterface mechanism, at least not jet.
In my opinion, Rust should develop its own, more powerful and secure, implementation of GObject/GInterface, based in their own internal types, like Traits.
I don’t know if Rust is planning to provide an Object Oriented like mechanisms, like GObject/GInteface, with properties, signals, introspection and inheritance, but is very convenient for other languages and implementing Object Oriented API, like the ones from W3C.
While I write this article, I’m studding Rust, to find equivalences and possibilities, thinking on how to port my work to Rust if possible. At least, for now, I can’t, but I have been just little time, I need to follow its development and road map.
Vala development can be used by Rust applications and libraries, because is C and GObject, and because it produce GIR files to create bindings easily for Rust, along with other languages.
If GObject is your choice to write your next library or Application, I can recommend to use Vala: you’ll get a very productive syntax and a easy bindable API.
No, I’ve don’t want to stop my self to Vala. Just is very convenient to produce GObject based libraries, use any C based library too, and is really productive. My work on GXml, can’t be just dropped and its capabilities to Serialize GObject classes, by introspection of its properties, are very useful and productive. I’ll share more in these later.
Rust does not need GObject or OOP as the existing approach of protocol-oriented programming with traits is a better concept. There are some things that are being improved upon that will add convenience to the existing feature set in regards to traits, generics, and inheritance, but ultimately GObject is of no benefit to the greater Rust ecosystem. I think you’ll find that when you gain mastery of Rust, you’ll see this as well. You will simply have to approach Rust with a fresh perspective instead of trying to mangle it into what you already know.
Rust also already has many XML parsers, and parsing libraries are one of the strongest aspects of the Rust ecosystem. A quick search on Crates.io will reveal that we are pretty much covered here (1), such as the xml-rs library (2). If you instead want to create your own parser, there’s generic parsers that can help you achieve this, such as serde (3), which is able to serialize a format into a native Rust data structure, and vice versa.
The problems with Vala, however, are the same as ever. It doesn’t have native support for compiling directly to efficient machine code. It has to translate Vala into C, horribly, inducing a plethora of bugs in the process that are invisible to the Vala programmer, and it is strictly limited to GNOME developers that are willing to recreate everything they need from scratch instead of taking advantage of the greater community of software libraries, as Rust does with Crates.io.
(1): https://crates.io/search?q=xml
(2): https://github.com/netvl/xml-rs
(3): https://github.com/serde-rs/serde
> […] ultimately GObject is of no benefit to the greater Rust ecosystem […]
Sure GObjec, as is, is useless and will break Rust concepts.
>[…] There are some things that are being improved upon that will add convenience to the existing feature set in regards to traits, generics, and inheritance […]
This is exactly I want to tell. Treats provides a set of futures like GInterface does. Even that Rust may need to add a GType system, where you can know who derives from, in order to implement not just one but a set of interfaces and then know at runtime what type of object you have and what you can do with it. May you can check at GXml DOM4 (1) set of interfaces from W3C standard (2), to check out what is missing in Rust to implement this kind of API.
I don’t want to say Rust is bad, I’ll take your suggestions in account in order to search robust and secure XML parsers, libxml2 and other, have a lot of security issues over the time. May use it, to produce a C API library I can bind with Vala and then use it to parse XML documents.
> […] The problems with Vala, however, are the same as ever. It doesn’t have native support for compiling directly to efficient machine code. It has to translate Vala into C, horribly, inducing a plethora of bugs in the process that are invisible to the Vala programmer […]
Sure there is anything perfect and can be fixed by the way. If you know about this problems, may you can help to file bugs against, in order to allow, in de middle transsition to Rust comes, to continue working better.
Been a GObject programmer, I check some of the C generated code, but really love to see if Rust can have a Vala->Rust code generator, with same Object Oriented approach provided by GObject at low level and limited in some areas, because C. I’m sure your comments about improvements in Rust, will be better than GObject and will provide more robust solution, but are there any one working on that? I’ll take some time to follow Rust development, for sure.
Just don’t FUD Vala, it is a tool useful and convenient for GObject programmers (GTK and other libraries based on it). It has serve its purpose and I think will be for some time, until Rust can provide equivalent futures and syntax (I know, Rust will never change its syntax, I’m talking about a macro language over Rust as Vala is for C/GObject).
(1) https://git.gnome.org/browse/gxml/tree/gxml/DomDocument.vala
(2) https://www.w3.org/TR/dom/
What a smug, fanboyish response.
> […] Even that Rust may need to add a GType system, where you can know who derives from, in order to implement not just one but a set of interfaces and then know at runtime what type of object you have and what you can do with it. [..
Statically typed languages with support for dynamic polymorphism (like C++ or Rust) generally don’t need it or only very rarely. For those rare occasions, there is already std::any::Any.
> ..] May you can check at GXml DOM4 set of interfaces from W3C standard, to check out what is missing in Rust to implement this kind of API. […]
Nothing, of course. It just uses enums instead of class hierarchies in Rust. And while enums are, unlike class hierarchies, closed, in this case it does not really matter, because the set of possible XML nodes is final.
Or it could use polymorphism. Downcast is currently only available for concrete types, but it would be trivial to add a handful of helpers to this hierarchy since it needs it. It could even be a worthy exercise to try to create suitable std::convert::TryFrom impls as it could be used as a base of proposal for trait hierarchy support.
> […] I know, Rust will never change its syntax, I’m talking about a macro language over Rust as Vala is for C/GObject […]
Rust syntax is extensible and even more powerful options at extending it are in the works. But macros 1.1 are out there and should actually be good enough for anything you might want to do with GObject.
> […] but really love to see if Rust can have a Vala->Rust code generator […]
That would be totally useless, because it would lose most advantages of Rust and would not really bring any new ones.
What would be a useful project though would be a Rust plugin providing attribute that would generate a GObject/GInterface wrappers for given Rust types and traits, including corresponding GIR definitions, vapi and C header. This would allow leveraging all the work that has been done towards easy binding of GObject-based libraries to various other languages.
You could write a normal Rust, just sprinkled with some #[GObject] and #[GInterface] attributes (regular Rust syntax) and as long as thus annotated types would only use supported features (generics, in particular, can’t be supported), it should be possible to generate the binding.
By the way,
> […] Treats provides a set of futures like GInterface does. […]
They are *traits*, not treats. And they provide *features*, not futures.