> From: Matthias Berndt <matthias_ber...@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 _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
