Richard Huges, on my recent post, has pointed out his interest to re-write GXml in C in order to avoid Vala dependency, quoting his words:
[…] Being honest; I’m not going to be depending on a vala library any time soon as I have to maintain all my stuff for the next decade and Vala isn’t an ideal long-term support option at all. […]
Is it Vala development a waste of time? Is Vala suitable for long term support libraries?
In GNOME, core technologies have been written in C, with high level bindings using Python and, as an intermediate solution Vala, both with strong relation to GObject Introspection.
Vala have a candy syntax, making write C API and C objects based on GLib really productive, while avoids any overhead.
While GLib have provide an Object Oriented approach because GObject, it is still C. You have to use C sentences all time even for the most common tasks. You can write really resource and speed optimized code if written in C.
GObject Introspection makes bindings to different languages available at release-day of C libraries, so for Vala ones. Vala create directly GIR required files at compilation time.
Vala generates C code. It isn’t of course, may never, perfect or reproducible. This is true and a hard issue for libraries providing interfaces, because its algorithm, I think, uses hash tables to store some parsed code representation, making impossible to generated reproducible code each time it is generated, because function position in its C form, could change producing ABI incompatible sources; this never change C behavior or security.
There are a set of fixes introduced recently to Vala to avoid interfaces issues, used by, for example libgee. This is the path for GXml to follow if it is written in Vala.
Reproducible C code generation may require to change a lot of things internally in Vala compiler.
GLib and GObject uses macros to reduce hand written C code, Vala coders use Vala compilers because C development could be slow and error prone; and because you should care about memory management by hand too.
If Vala is not going to be maintained, because a set of core developers prefer to use C, and GNOME Builder is not going to take the time to improve its Vala support, because C is the way to go for long term support projects, then may we should stop to use Vala for libraries. Is it?
Improve Vala C code generation.
While there is macros in C to reduce burden on hand code generation, still there is room to have macros written in Vala to do the same. This is a really futuristic, wish list, sentence.
Vala syntax makes possible to write GXml, with the features it have today. Serialization framework, was possible once a GObject based API (and in Vala) was available and DOM4, was possible because we was able to copy and paste specification declarations making just few changes to Vala syntax.
Vala provides a high productive C code generator with lot of candy syntax to most common activities, like string manipulation, with automatic memory management, using secure GLib’s methods and so on.
Is it possible to improve Vala compiler to create more readable C code, suitable to switch from Vala to C?
Is it possible to embed Vala code in C or C in Vala code?
We need to explode how C generated code from Vala code, can be imported *as is* to GLib and improve over time, removing temporally variables and replace some more code to C’sh style according with the target project code standard. May this, task for GXml, is a little hard because it depends on libgee, another Vala library; but no impossible.
C limits expanded with Vala
C have lot of applications and Vala generics is pushing C limits with Generics, libgee use generics along a set of interfaces and implementations, allowing as to use different kind of collection for our objects, this powerful combination of GInteface and Vala generics, is a feature hard to reproduce (in its easy and convenient way in Vala syntax) to C API.
GObject and GInterface have a set of limits, expanded with Vala too. Now is possible to define very quickly a set of interfaces and implementations, figuring out really fast its relation ship, thanks to Vala syntax.
This advantages, in others out of the scope (and my mind), make me ask if we can embed Vala code in C or C in Vala code. Even if once a feature is mature enough in Vala code, may someone can (with C code generation optimization) import to other core libraries like GLib. Again this is one of my wish list.
Vala as a Long Term supported language
Vala syntax provides lot of advantages over hand written GObject classes, in the spirit of productivity.
GXml provides C and Vala API. Vala is more easy to use and allows to implement object oriented specifications (may be based on the idea of Java classes), but providing back a C API. Vala code is more Object Oriented syntax, than C/GObject.
Then how we can continue to contribute Vala libraries to be used by any one, and suitable to be used by any other projects even written in C?
How we can make a Vala library, like GXml, a GNOME core component with Long Term Support?
There are plenty of bugs and room to improvements to C code generation in Vala compiler, we, their users, should care about and may pay for improvements. I really want to some one add Jürg Billeter, Rico Tzschichholz or Matthias Berndt to the list of “Adopt a Hacker” list from GNOME Foundation, in order to push at least one of this ideas to improve GNOME infrastructure.
I really would like to recommend Rust instead, but it is not there yet. Rust can provide interaction in both directions (C→Rust and Rust→C), has many more developers and is actively developed. Syntax is a bit more complicated. Downside: Rust toolchain is under heavy development and doesn’t have ABI stability yet, so loading dynamic Rust libraries from Rust applications can hardly be shipped.
At least, Vala is better than JavaScript in many ways: Better stability and reliability through compile-time checks; a non-esotheric type system; Performance.
And, often, Vala’s readability makes it more suitable for daily usage than C.
Why not Rust? While Vala is certainly a better option than C it’s a dead end because it’s pretty much only used in GNOME. I see no reason to write anything in Vala: if I wanted performance I’d go for C or Rust, if I wanted ease of use I’d go for Python or JavaScript.
Rust is like Vala. It has been developed to provide a high level language compatible with C.
Vala is for GLib based libraries. Providing an Object Oriented language.
I also think Rust is the better option, Although I like more Crystal: https://github.com/crystal-lang/crystal but is even younger than Rust.
Please keep Vala! I’m a Java Developer interested in Open Source. I always wanted to contribute to Open Source (Desktop) Applications. But the most Applications I use are written in C or C++. I’m not good at all at both languages and I think that those languages are not suitable for developing Desktop Apps.
Now I have found out about Vala and it’s wonderful. It has the features (and the syntax) of languages like Java and C# but it is regularly compiled what is great in terms of speed. I’d say many young developers are in a similar situation like me. The most students learn Java or C# as a primary language (at least in my country).
The problem with Vala is it’s uncertain future. But if more projects stick to Vala and maybe even support the Vala development, Vala has a bright future.
How about dropping C as well?
A lot of Foss projects move to qt and gnome would be written in qt if there weren’t license issues when they started. Well, now there isn’t.
Would this be an option? Instead of gtk+4?
License wasn’t the only issue. Qt is written in C++ and unfortunately C++ is an ABI nightmare. Creating language bindings with GObject is a lot easier.
To be honest, no you should not drop Vala. If Richard Hughes doesn’t want to depend on a Vala library, then he’ll have to fork GXml and write his own in GLib and C without the valac compiler.
Your proposal to make valac generate reproducible C code is, however, a good idea. I don’t think there is going to be a good reason for unsorted hashsets or hastables internally in the valac AST, that influences the generated C code. The same version of valac should in my opinion produce the same C and H files.
But I can assure you that people like Richard will still say that it’s not good enough. It will never be. And that’s fine. They just have to fork and write their own GXml. Don’t worry about people who are C purists. They fork projects all the time, and their forks often fail. It’s hilariously fun to watch them. Join us in watching their show, and don’t forget the popcorn! *crunch* *crunch*.
But if you like Vala. Use Vala. It’s fine.
The problem with writing a library in Vala is that the generated C API is not guaranteed to be stable. It can, and will, change when the same .vala files are compiled with different versions of valac. Since stability of the C API for a library which you intend to be used from C programs is important, this makes Vala a bit of a pain for writing libraries in.
It’s still a good choice for writing *applications* in though.
The problem is not ABI now. Vala have some annotations to avoid problems on ABI interfaces.
Point here is how it generates its C code, same order, at least now, is not possible.
Realistically, as long as Vala can’t generate ABI-stable C code from the same Vala source code, then it shouldn’t be used for libraries.
Convenience and ease of writing code are great. But if your ABI breaks everytime your library is rebuilt (whether you changed your source code or not) then you’re putting too much burden on the users of your library.
Vala CAN generated ABI stable C code, just require some annotations on, for example, GInterfaces, as libgee does.
With flatpak on the road, this is not an issue any more, you can distribute your application with all its libraries.
Now, Vala libraries are distributed on C code no Vala code. Then if you compile a version of your library it will always be ABI compatible.
Yes, please drop Vala. Introducing a GNOME proprietary language was a bad idea from the start.
What exactly do you think Adopt a Hacker is?
On Friends of GNOME, you can select one Hacker, donate and they will continue to work on GNOME technologies at https://www.gnome.org/friends/
I propose to add Jürg Billeter, Rico Tzschichholz and/or Matthias Berndt, to the list of Hackers to donate to. This donations should help to improve Vala.
That’s not what Adopt a Hacker is. You are donating money to the GNOME Foundation and it goes to the general donation fund. The hacker you chose will send you a postcard. That’s it.
Then, Change It!
Lets call it “Fund a Hacker”, as a way to support his efforts to maintain a critical piece of your infrastructure or project.
For Vala is to support your language to be LIVE!! and improve!!!
If you want people to take what you say into consideration, you should tone it down. Five exclamation marks in two sentences don’t help convey your message and only makes the people you’re talking with want to move on to something else.
Nothing prevents these hackers from running a fundraising campaign if they feel like they need it to support their work. We have several examples now:
The GNOME Builder fundraiser on Indiegogo
The Pitivi fundraiser hosted by GNOME
The recent gspell and LaTeXila fundraisers self hosted by Sébastien
If they launch something and need spreading the word, the GNOME engagement team can help.
IMHO you’re mixing concerns,
Should Vala be deprecated/obsolete/dead? I’d wish not, and I’d love to see it improve too, it certainly fits a gap. (FWIW, I don’t think the object abstraction is superior to GObject’s, certainly replacing code patterns with syntactic sugar lowers some barriers though)
Could/should Vala be used for “low-level” libraries? I think that’s entirely at the developers’/maintainers’ discretion. You can indeed make Vala libraries with C friendly APIs, as Tracker can testify, In that regard I think some of Richard’s concerns are moot. That said, would be nice to see a healthier Vala, it won’t be fun if Vala stagnates further on old/deprecated GLib features (it’s already happening with GSimpleAsyncResult vs GTask)
Should Vala-generated code be part of GLib? Hell no, that’s a dreadful start for a component in such core library. It was never the purpose of Vala to have you look into the C-generated code, let alone taking it as the starting point for further development. It would IMO be wrong to focus on making Vala generate code ready for human consumption, looks like a huge effort for this fringe usecase.
I spent a little time awhile ago learning Vala. Vala is a very interesting (and nice) language. I think it would be a shame if it were abandoned. I think it would be great if the Vala compiler could be made to generate object code directly without going through a C intermediate (but still produce a C compatible interface). Perhaps it could be integrated into the GCC collection. I think such things could give the Vala compiler more control in implementing a consistent ABI. I have no idea what that would take, but it would surely be an interesting project, and it might be what Vala needs in order to become a “serious” development language.
Well, or instead of wasting limited resources on NIH-ing a programming language, just admit that C++ has made great progress since 2003 and do what everyone does. Use C++.
C++ still hasn’t got a stable ABI.
So does really noone care? Sad
Maybe we should instead look at other more recently languages than C that are maintained by other people, for example, C++ or Rust…
Julia could be another option besides C ++ or Rust.
Julia isn’t really a general purpose language, it’s more focused on scientific computing.
I use vala because it isn’t c++ and because it’s stable. Languages like rust morph all the time, and my projects no longer compile. I guess if gnome is dropping vala, my next choice would be fsharp or scala native. Certainly not c… Or gnome either, if they drop languages when they get bored with them.