Re: [Vala] The future of Vala

["Matthias Berndt" <Matthias_Berndt gmx de>]

Hey,

> With Luca leaving the project ([Vala] Leaving the project 
> <https://mail.gnome.org/archives/vala-devel-list/2016-September/msg00000.html>), the situation is now even 
> more
> critical. Given that Joerg obviously has no time or interest it basically means that there
> is no-one left who used to help developing the core language.
I'd actually be interested, and I have a few ideas for improvements. However, the main problem I see is that
it's very hard to get patches merged or discuss technical issues with more experienced developers. And thus
the vala project in its current form is unable to recruit new compiler maintainers. Questions or suggestions
on vala-devel-list don't get answers and it's similar on the IRC channel. Worst of all, even small patches 
take ages to be reviewed, e. g. this one:
https://bugzilla.gnome.org/show_bug.cgi?id=615830
It's just very tiring when one's efforts are ignored for weeks and the general impression is that new
developers are something the project doesn't give a tuppeny-cuss about…
In addition to that, I also believe that Jürg's decision not to merge the patch is misguided. If clear and
obvious bugs like that (short summary: the compiler accepts code such as List<int> l = new 
ArrayList<string>())
are retained because of broken third-party projects (shotwell was mentioned), then it's impossible to move
things forward. And guess what: open source developers do what they do because they do want to move things 
forward. And if they can't do it in vala, they'll soon find some other, more welcoming project. And while
I understand the importance of backwards compatibility, I don't think it's as important for vala as it is for,
say, the kernel. Unlike the kernel, one machine can easily run two different versions of the compiler 
simultaneously, and if the shotwell people want to compile old, broken code, I think it's entirely reasonable
to expect them to keep an old, broken compiler version around to do so. Of course, the far more likely case is
that they, like basically anyone else, actually *want* the compiler to tell them about their broken code so 
they
can fix it! Not to mention all the other user who'd like to have this fix…

Oh, Jürg, if you're reading this: I hope you don't take any of this personally. 


> The bindings is another situation, those are quite vivid, from what I can see.
>
> Some words on my personal situation: Although I have been inactive as well for
> the past couple of years, I’m still willing to maintain the VAPIs I started or contributed a lot to
> (i.e. linux, posix, alsa, netlink, etc.).
> My pet project, the special-interest-middleware FSO – freesmartphone.org <http://freesmartphone.org/> – is 
> very dependent
> on Vala, I guess it is among the top 10 largest Vala projects and during the development I helped
> Joerg getting a number of great Vala features in a solid state, such as coroutines, closures, async dbus, 
> etc.
> Alas, my knowledge of the compiler internals is zero. One reason why FSO has been stalling is that I'm 
> unsure
> about whether Vala is going anywhere towards a stable (with reasonably sane criteria of stableness) 1.0.
> I’m also the creator of numerous bug entries where Vala generates invalid C code and the Vala programmer
> is scared with an incomprehensible gcc error message. As far as I can see many of those are still open for a
> bunch of years now – which makes me feel somewhat pessimistic about the future of Vala.
Well, given that the official maintainers are effectively inactive, the future of Vala is clearly what we
make of it! Have you ever thought about hacking the compiler? I didn't find it that hard on a technical level,
and I'd certainly answer any questions I can.

> I’d welcome advise from the father of Vala, Joerg (or anyone other with solid knowledge of the core),
> to give us some direction. Would a redesign / rewrite be necessary to move forward to an 1.0 or
> would refactoring the compiler be enough to lower the contribution barrier?
Well, it depends on where we want to take the language! I have a few fixes and features in mind that I'd like
to address, and I can go into more detail if anybody is interested. What is it that you would like to see?

Cheers,
Matthias