Re: [Vala] State of the Vala union (was: Starting with Vala)

[Al Thomas <astavale yahoo co uk>]

> From: Matthias Berndt <Matthias_Berndt gmx de>
> Sent: Tuesday, 4 April 2017, 23:43
> Subject: [Vala] State of the Vala union (was: Starting with Vala)


> Vala suffers from a number of problems:


> – the compiler is basically not production ready. I dug into the source code>    just a bit and found 
> trivial ways to break type checking. I fixed some of them
>    (e. g. Bugzilla bug 641418, 615830 and several more), but I soon realized those

>    were just the tip of the iceberg.

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.

> – C code generation is also broken, reports about invalid C code being generated
>    appear all the time, not to mention the C compiler warnings…


Some of these have been addressed with the 0.36.0 release. See the
"Reduce incompatible-pointer-type C code warnings" in the release notes:

https://mail.gnome.org/archives/ftp-release-list/2017-March/msg00119.html
Of course the switch to GTask will also reduce warnings with async code, but
that message was sent to this list some months ago.


> – Some type system bugs are essentially unfixable, e. g. covariant generics.> – Obvious features are 
> missing, like type bounds for generics

> – the compiler maintainers are not very active. Luca Bruno left entirely and Jürg>   Billeter is quite hard 
> to get a hold of. The problem isn't even that they're
>   not maintaining/improving the compiler but that they also don't appear to be
>   very keen to find new, more active maintainers. Yet every patch needs to go
>   through them. As an example, see this bug:
>  https://bugzilla.gnome.org/show_bug.cgi?id=772209
>   (incidentally this is also a C code generation bug)
>   I'd like to fix it, but if nobody wants to merge or even review the patch, it's
>   impossible to get anything fixed. I would have expected to be offered commit
>   access after fixing ~half a dozen bugs, but that didn't happen.


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

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

You should also take a look at:
https://wiki.gnome.org/AccountsTeam/NewAccounts

> – compiling to C is a bad idea. Among other things, it means that when you want>   to use a debugger, you 
> have to step through the generated C code rather than
>   the Vala code you actually wrote. The fix? Write a real (e. g. LLVM-based) code
>   generator, it's just a small matter of programming ;-)


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


> – 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

> – Generally poor tooling. I couldn't even find a decent editor that supports >   basic features like jump 
> to definition, find symbol usages, code completion
>   etc.. And I've tried quite a few like Anjuta, Gnome Builder and more. None
>   worked properly


Seriously? 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
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.



> – No momentum. Emmanuele Bassi's blog post should be well-known at this point,>   but just in case:
>  https://www.bassi.io/articles/2017/02/13/on-vala/


Hmm, focus on the negative. A slightly more positive take:
https://blogs.gnome.org/mcatanzaro/2017/02/19/on-problems-with-vala/
Also the GNOME developer who wrote the following blog post started going
through bugs for a 1.0 release:
https://blogs.gnome.org/despinosa/2017/02/14/vala-1-0/
And no they are not the same person who had a go at an AST printer,
or an LLVM backend or a Meson build. They are all different people.



> – Worst of all, while hacking on the compiler, I realised that programming in Vala>  is simply not a lot of 
> fun as it is fundamentally an outdated design. I use
>  Scala in my day job which certainly shapes my expectations, but boy, is
>  programming Vala a pain. The collections are useless as they lack basic methods
>  like map, filter, flatMap etc. (or Select, Where and SelectMany as C# likes to

>  call them). 


Would map, filter, flat_map not be the Gee.Traversable interface?
https://valadoc.org/gee-0.8/Gee.Traversable.html

> Immutable model classes are super inconvenient because there's just
>  so much boilerplate required for them. Compare>  Scala:>  case class Foo(bar: Bar, baz: Baz)

>  to Vala:
>  class Foo {
>    public Bar bar { get; }
>    public Baz baz { get; }
>    public Foo(Bar bar, Baz baz) {
>      this.bar = bar;
>      this.baz = baz;
>    }
>  }


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.

>  And this isn't even complete as Scala also gives you a method to create modified
>  copies of an object – a feature one would probably emulate with the builder 
>  pattern in Vala, resulting in tons of more boilerplate. And again, this
>  is just the tip of the iceberg…
>  Note that I'm not trying to bash the Vala designers here, after all junk like
>  Java and C# is what is being taught in Universities, so I can't blame them for
>  coming up with such a design.


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?

> So yeah, I agree with Emmanuele: it's time to let it go, and it's certainly not
> the language to start your next project with. That's my take on it, anyway. 


That seems to pull the rug from under the work people have been doing over the
last six months, but hey you are entitled to your opinion. 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.

Al