Re: [Vala] State of the Vala union

["Matthias Berndt" <Matthias_Berndt gmx de>]

Hi Al,

thanks for responding!

> I guess it depends on what you are producing. Some one has just stated on this list
> they have been part of a 200K lines of code project. They must have thought it was
> production ready.
Well, I suppose I have higher requirements than they have. From a production-ready
compiler I would expect
– no (or at best very obscure) type errors to get through
– no compiler crashes
– no broken code generated
I don't think these are unreasonable criteria, yet valac fails all of them.

> Some of these have been addressed with the 0.36.0 release.
Yes, some. And more remain.

> There has been a lot of bug fixing over the last six months so it can be
> hard to keep up. As far as generics I think the top priority for any 1.0
> release should be handling simply type structs by auto boxing:
> https://bugzilla.gnome.org/show_bug.cgi?id=774713
My problem is that type checking for generics is unsound because of covariance,
and as a response you point out another bug that is also not fixed yet. I'm
sorry, but I don't see how that addresses the issue I've raised?? And the
deeper issue is that this unsoundness problem is probably close to impossible
to fix without breaking large amounts of user code, the current maintainers
have really painted themselves into a corner here.
It is certainly impossible to fix if there is no way to get hold of the
current maintainers to actually discuss issues and possible solutions.

> As far as increased type checking then some of the issues that came up with
> interfaces may also be relevant:
> https://bugzilla.gnome.org/show_bug.cgi?id=779038
> https://bugzilla.gnome.org/show_bug.cgi?id=686542
So… more bugs from 2012?

> Some one did recently have a go at an AST printer if that was any help:
> https://git.gnome.org/browse/vala/log/?h=wip%2Fbaedert%2Fnullable
>
> Some one else had a go at using LLVM as a back end:
> https://github.com/chebizarro/vala/commits/master
Cool. Last commit from four months ago.

> > – autotools. In 2017.
>
> It may surprise you to learn another developer has tried switching to Meson:
> https://git.gnome.org/browse/vala/log/?h=wip%2Fmeson
And here's the next problem with Vala development: it's basically impossible
to know who's working on what. vala-devel-list seems dead. An open source
project cannot attract contributors like that, can it?

> Seriously?
Absolutely.

> People are developing tools for Vala. Jump to definition in Vim?
> Take a look at:
> https://wiki.gnome.org/Projects/Vala/Vim#Jump_to_Definition
> Auto completion in Atom? Take a look at a nice screenshot:
> https://atom.io/packages/valhalla
So I'm supposed to switch between two editors whenever I need one or the other?
You're kidding, right?

> There is a wiki page for tools:
> https://wiki.gnome.org/Projects/Vala/Tools
> These are recent contributions, but they will only improve further if people
> want to contribute.
I'm talking about the status quo and why Vala is not fun to hack with. If you want
to convince me that the tooling isn't so bad, pointing to a Wiki page won't do it.
Name one (!) editor that is free software and supports basics like jump to definition
*and* code completion and doesn't crash all the time. Really, I've tried a bunch of
them. GNOME Builder made the best impression, except it invariably crashed within
seconds when trying to edit the valac source code (I think it actually crashed in
libvala, which kinda confirms my point about the compiler not being production
ready).

> Hmm, focus on the negative. A slightly more positive take:
> https://blogs.gnome.org/mcatanzaro/2017/02/19/on-problems-with-vala/
To be honest that looks pretty bleak to me as well. Quotes like “I can confidently
say that Vala has more bugs than any other programming language you might be
considering using for GNOME development.” really say it all.
And you know what? The bugs aren't even the issue, bugs can be fixed. The issue is
that despite the activity you pointed to, I don't see people actually getting patches
merged into the comiler. And I also see a compiler that is based on a lot of mutable
state and side effects, that doesn't use best practices (e. g. many places use getters
and setters rather than properties) and that suffers from Vala's shortcoming as a 
language (e. g. defining simple model classes is a pain).

> Would map, filter, flat_map not be the Gee.Traversable interface?
> https://valadoc.org/gee-0.8/Gee.Traversable.html
Right, I missed that, essentially due to bad tooling I would argue.
But now that I know about the methods on Traversable, I'd like to point out they're
pretty useless too. Calling map or flat_map on a List yields an Iterator, which is
useless when I need a List. And it's quite hard to do much better, because Vala doesn't
support higher kinded types, that is, type parameters that can in turn take type
parameters. That's another flaw in the language design.

> That would be nice. Immutability is important. Some work with [Immutable] attribute
> may be relevant. Although I was thinking more of using const more in the C code for
> immutable simple types first.
The really bad part here is the sheer amount of boilerplate code that needs to be
written to define some very basic data types. Data types are what expresses the
design of a program, so it should be as simple as possible to define them.

> OK. So are you saying Scala is the best language ever or are you leaning more 
> towards Rust? Why were you interested in Vala in the first place?
I'm comparing to Scala because that's what I'm using on my day job and I find it
reasonably pleasant use, both in terms of language features and tooling.
I don't know that much about Rust, but it looks like a much better design than Vala.
Like Vala it doesn't require a GC, but it also doesn't suffer from the null problem,
it has fast and easy ways to define data types (including discriminated unions, which
is another feature missing in Vala). There's a real code generator based on LLVM, and
most importantly, there seems to be a lot of momentum around it and the people working
on the type checker seem to know what they're doing. Borrowing and memory safety also
look like killer features to me, too bad it doesn't have higher kinded types…

> Why were you interested in Vala in the first place?
It started when I ran into a bug in network-manager-openvpn which I then fixed.
network-manager-openvpn is obviously written in C, which is IMO a terrible language to
write that sort of thing in. Vala seemed like an attractive migration path, because
it's possible to mix C and Vala and migrate a C codebase piecemeal.

So I started toying around with the Vala compiler and noticed it doesn't support
co-/contravariant type parameters, so I thought it might be a fun project to
add them (https://msdn.microsoft.com/en-us/library/dd799517(v=vs.110).aspx). So I
started reading the compiler source code and found bugs all over the type checker.
I fixed a few of them, but after some weeks I realized two things:
- there's no real community of compiler developers to show you the ropes and discuss
  bug fixes, refactorings and features with
- the codebase is just not fun to work with, for all the reasons I mentioned earlier:
  poor tooling, poor language design and tbh also the design of the compiler itself 
  that made it very easy to break things.
The fact that basically every fix in the type checker led to a slew of compilation
failure in user code didn't help either. Jürg's insistence on keeping the language
stable despite the fact it hasn't even reached 1.0 yet made it harder yet to get
anything fixed.

Again, I'm not trying to bash anything or anyone here. If I had started a project
like that in 2006, I probably would have ended up with something similar, except
much worse. But I've been exposed to functional programming since (Haskell and 
Scala), and that massively changed the way I think about programming. For the better,
I would argue.

> That seems to pull the rug from under the work people have been doing over the
> last six months,
I don't think of it that way. I'm merely giving my opinion so that other people have
a better basis to decide which projects to work on and what tools and languages to
use. And by all means, if you guys think you can fix Vala, I won't stop you! I just
don't believe it'll happen based on what I've seen.

> Thanks for taking the
> time to express it at length. My counter points will hopefully give an alternative
> view for those who may be in doubt.
Thanks again for expressing your views here. I'm afraid I'm still not convinced
though :-)

Cheers,
Matthias