Let's move Vala forward

Community
,
1

We in the Vala community love the language, but we are concerned about the lack of progress, and in particular our inability to get changes (fixes) into Vala.

I’m not going to surprise anybody by saying that Vala is not seen as being very actively developed. This is most famously expressed in Emmanuele’s post from 2017, which links to a mailing list thread, which back in 2016 was raising much of the same issues I want to raise with this post here, a decade later.

You might argue that as a programming language, Vala doesn’t need to come up with new and exciting feature every month to be considered successful; on the contrary there’s value in being a stable base for people to build on. However: there’s a number of improvements we should keep doing to Vala, such as fixing known compiler & codegen bugs, supporting newer GLib patterns, improving and updating VAPI/bindings, completing support for D-Bus, and so on. There are actual language features we’d like to add, too, such as constraints on generics and async lambdas/delegates.

The thing is, Vala is not exactly unmaintained. There is Rico, whose work we are grateful for. However, Rico evidently doesn’t have enough time/cycles/funding to even review & merge others’ work.

That is to say, other people’s work, patches that fix important issues, cool language additions, they sit in the bug tracker for month and years, unmerged, unanswered, frequently completely unacknowledged. This is frustrating and demotivating for the contributors. So the few people who do get interested in contributing to Vala (in spite of it not being actively developed), they get demotivated and stop contributing.

I want to stress that this is in no way a criticism of Rico: maintenance of a project takes time and energy, and it’s totally understandable that Rico can only allocate only so much of his to Vala, but not more. I’ve been on both sides of this kind of situations, I’ve been the maintainer/reviewer who stalls others’ contributions and project releases for months and years because of my lack of cycles and eroded interest (see Darling, wl-clipboard).

Yet, this causes so much frustration for us contributors & community members. When new people arrive and want to try out Vala, they quickly run into issues (to name just one: the reference cycle leak in closures). At best, they can be persuaded not to give up, and to maybe even implement a fix for the issue they ran into… and then the MR goes ignored for weeks and months and years, and the person has long given up.

However, Vala is not in a place where we could just declare it unmaintained, appoint someone a new maintainer and proceed from there. It is somewhat maintained! It’s neither here nor there, it’s stuck in this middle ground.

Rico is sometimes online in the Matrix Vala room, but only sometimes, and I never got a reply to my attempts to ping him about this issue.

I’ve talked about this to a few people (to name some names: Alice, Lorenz, Florian S., Ivan), and one recurring suggestion I’ve heard is I should file an MR adding myself as a maintainer. But that’s not what I’m pushing for, I want to be a prolific contributor, not a sole maintainer! — and of course Rico has a lot of experience with and knowledge about Vala that I lack; I couldn’t supplant him if I wanted to. Besides, the last thing I’d want is for this to resemble some sort of hostile takeover or cause a discord in the community. If we do something, let’s do it amicably.

I guess I could see a model of governance where several active contributors co-maintain Vala, review and merge each other’s work. I’d be up to be a part of such an arrangement, but I haven’t found enough interested people to actually do something like that.

Alternatively, if we can keep Rico in charge, and just somehow fund his work, so he could commit to regularly spending time on maintaining Vala — if only to get others’ work in — that’d be a great outcome too!

I’ve been trying to talk about this situation (and this post is another instance of me doing that); but this all is also moving nowhere on the meta level. You can imagine how this frustrating it is for me too.

I believe that Vala is a great language that really has a unique combination of qualities, and one that can still have its day (once again). Clearly it should be important for us in GNOME (whether we like it or not), because a chunk of GNOME is written in it, including a bunch of our core apps. Elementary people are building their whole platform on it, so they should care about keeping Vala up too.

Let’s discuss this more openly as a community.

How do we move forward? Let’s work something out, please?

Could we hear from Rico? (maybe even from Jürg?)

13 Likes
2

The new https://fellowship.gnome.org/ program might be able to fund Rico, since improving Vala is definitely in the scope of “improving tooling, …developer productivity, and ongoing maintainability” Though, again, this is entirely up to Rico.

2 Likes
3

Hey, everyone. New here. Only chiming in because bugaevc nicely invited me on the Discord server.

This is painful. Not sure what can be done without involving one or more of the last active maintainers. A fork? That’s a huge commitment, and I’m nowhere near qualified enough to contribute.

As a language user, my big worry is the Gnome wiki being discontinued while a lot of Vala docs are still trapped in it. Like a ton of introductory examples, and all the Genie documentation. People aren’t going to become interested in Vala and use it if they don’t know how. And obscurity is a vicious circle.

4

Hi, I agree that something needs to be done moving forward. I like the idea of a co-maintenance arrangement like a lot of open source projects have where funding isn’t all that plentiful. I’d prefer it, and I’m sure others would prefer it if a forking doesn’t take place (as we’ve seen time and time again what that does to the community).

I’d love to help out in any way I can, whether its financially or low-hanging fruit issues, although I can’t say that I have an abundance of time nor expertise needed for most large issues currently. My time is expected to be freer soon, and I plan to deepen my knowledge of Vala, C, dev tooling, language features and construction, etc.

I think it also would be good to have more communication with the language’s user-base and actually open the floor up for donations, more avenues for contributions, and share whats in the works. For example, just simple blog posts with technical updates would be very valuable.

5

I read this with a lot of sympathy. I have contributed Vala demos to Workbench and love working in the language. I wrote my university senior project in Vala. I was really happy to see recent progress on Geary.

I’ve seen how stalled maintenance kills contributor motivation

I’d genuinely love to help move Vala forward. But I’m also in a precarious post-grad situation (housing instability, job hunting), so I need to be realistic about what I can offer right now

I also like the idea of co-maintenance. i would love to start helping with documentation materials or VAPIs

1 Like
6

As @T_b hints at, if we decide that the way to go about this is to collectively fund Rico’s work, we need to be sure that it would make an actual impact on the state of things. For instance, could Rico, with additional funding, commit to spending several hours a week working on Vala, and post regular updates on the state of things and his plans?

I imagine there could be a lot more engagement and activity in the Vala community too. There could be posts about Vala by the people who use it (this post is one example). There could be a “This Week in Vala” (or at least: “This Month in Vala”), describing language fixes, doc improvements, releases, and news about the various projects written in Vala.

1 Like
7

Is Rico actually able to be funded to work on Vala? Has anybody actually talked to him about it?

2 Likes
8

The reason I wrote that blog post in 2017 was not to comment on the features (or lack thereof) of Vala; it was the result of a week of Vala-related build failures that blocked GNOME from actually getting its CI/CD pipeline from running. That’s where the maintenance issues usually lie: every time something updates the VAPI file for a library (especially when it’s handwritten), all the applications can use that VAPI may or may not break horribly, and maintainers do not notice.

Unfortunately, Vala does not have a “lock file” or versioning for its VAPI files: maintainers either chase the main branch, or they have to copy files in tree and then keep them up to date; on top of that, downstream distributors may decide to build against a version of the library and/or the VAPI file under they control, and thus generate even more breakage.

I’d like to caution on this: it’s not always possible to fund somebody that is already employed; and funding comes with its own expectations of availability and access that may exacerbate a burnout in former volunteers. If Rico is happy to spend (funded) time on this, and he has the ability to do so, then that’s great; but you may need to keep a “plan B” available, especially in terms of expanding the maintenance effort.

4 Likes
9

Thank you, — yes, that is what I was trying to say as well. We need to hear from Rico himself on whether he would be able to actually spend funded time on this. (His GitHub profile does indicate “freelance developer”, so it could be possible?) But we should also discuss/develop an alternative plan.

I’m unable to find Rico’s account on this forum to cc & bring him into this conversation. If he doesn’t have an account, should someone email him perhaps?

3 Likes
10

This. It’s a little scary to me that so much time has passed since @ebassi made that post and here we are with little to no movement.

@bugaevc your post on the Fediverse brought me here. Not in a position to do much financially, and considering I’m working full-time while enrolled in a degree program I don’t have a lot of time either. But I am building two different applications with Vala currently and have a lot of interest in seeing the project at least well-maintained. It’s a great language, and in particular it feels to me like how Gtk+/GObject code is meant to be written. I’ve used the C interface directly (painful), the Rust bindings (macro-heavy and feels “odd”), Gintro using Nim (ok, but buggy and incomplete). Vala is quite elegant in comparison.

1 Like
11

I feel the same way about vala: I believe it could have a future, but it’s hard to be motivated about it.

Good point. They could have valid reasons for not being able to. If anything, I think they were slightly more active since this year - then again, I haven’t made any MRs so I might be wrong.

In general, I think this information should be brought to the current maintainer first.

laslty,

There are some QoL features that I really miss from C# - and not having LINQ (Functional programming) really sucks.
There’s libgee, which is not that bad, but the problem comes from having to interact with the countless types of list systems that every library has.
Examples: in adwaita, and gstreamer.

—

I’m really looking forward for some improvements, it’s great to hear that there’s a couple of you making MRs and the like.

12

Hey, so, I intended for this thread to be about the social aspect rather than becoming technical, but this peaked my curiosity.

Why do you want LINQ in Vala? To me, LINQ always felt like a weird bolted-on nobody-asked-for-this feature of C#. Is it supposed to be an ORM for querying databases? (If so, it’s a bad one.) Is it supposed to be a filter-map syntax over lists?

What are your uses cases? Perhaps what you want is just a concise and reliable way to filter, map, and otherwise work with collections? Would Rust / Kotlin / Java streams -style chained operations fullfil your use case?

Well, you must realize that a list model is not just a list, its more of an observable collection.

13

Has anyone considered turning the project over to the elementary OS people? They really like Vala and seem to be the ones doing any new development with it

14

I don’t think anybody prohibits them from contributing…

15

The issue is not as much with contributing, as it is with maintenance, — as in, at least, getting people’s contributions merged.

As an example, here is a merge request, an important improvement for D-Bus, by @tintou from Elementary, pending since 2020.

1 Like