A GNOME Developer's Arguments On Vala Being A "Dead" Language

[ikey_solus]

I really hope not. Solus made a shitty mistake when decided to switch to Qt. ElementaryOS shouldn't do the same.

At least allow me to make said "shitty mistake" first If you read the post - you'll know its slated for Q2, and we've given strong technical reasons for the *why*. If you think a project should continue to use the wrong technology for the job at hand while integrating into a moving closed ecosystem also on the back of a dead language, then sure, please, fork Budgie. (Like that one dude.)

If however you want to see a project grow, and leverage existing technology to solve real world problems, then wait for Q2 and see how it goes. Right now we're focused on fixing
what is already there in the 10.x branch to get a last LTS-ish release out to give us more time to work on v11. Part of that includes a reduction in Vala sloc, notably in the window manager. Once v11 rolls around, not part of the Solus codebase (which also includes the Budgie codebase, but is far, far larger), will include any Vala projects. Like everyone else, we also saw the writing on the wall, and have been planning a transition for quite some time. (I'm not accelerating it, we still do have a timeline to follow.)

[Marc Driftmeyer]

Or they could just work on Swift when 4.0 arrives knowing Apple is going to roll it into Clang and it will be fully supported for decades to come.

[lordnaikon]

Or they could just work on Swift when 4.0 arrives knowing Apple is going to roll it into Clang and it will be fully supported for decades to come.

Why do you hate the Gnome developers so much? Rewriting their code every time a compiler (and a new language gets released) is not something you really want to do. We switched back from Swift to Objective-C. As much as we hate it, because Swift is overall a nice language – but there is no way we throw away three quarters of a years work in the bin because the code got useless after a year a second time. There is a reason Swift adoption is not very great among developers with more than average "fart app" code base size.

[zekesonxx]

How good would corrode be at converting Vala generated C source to Rust?

Probably pretty bad. corrode is making a lot of progress, but it's far from completion. And corrode is (largely) designed to translate human-written C, not transpiler-written C.

As some others have said, it would likely be easier to rewrite then to try and deal with automatically generated code.

[paupav]

I honestly think that Vala is perfect OOPL for beginners. Avoiding nasty header files while, providing everything necessary.
As for elementarOS team, it seems that they have just created their new appcenter using Vala. so they probably believe that Vala has future.
If they took over Vala project they would probably make Vala "next big thing". They are known for making bad stuff popular among their sheep base which is getting huge.

[paupav]

At least allow me to make said "shitty mistake" first If you read the post - you'll know its slated for Q2, and we've given strong technical reasons for the *why*. If you think a project should continue to use the wrong technology for the job at hand while integrating into a moving closed ecosystem also on the back of a dead language, then sure, please, fork Budgie. (Like that one dude.)

If however you want to see a project grow, and leverage existing technology to solve real world problems, then wait for Q2 and see how it goes. Right now we're focused on fixing
what is already there in the 10.x branch to get a last LTS-ish release out to give us more time to work on v11. Part of that includes a reduction in Vala sloc, notably in the window manager. Once v11 rolls around, not part of the Solus codebase (which also includes the Budgie codebase, but is far, far larger), will include any Vala projects. Like everyone else, we also saw the writing on the wall, and have been planning a transition for quite some time. (I'm not accelerating it, we still do have a timeline to follow.)

I hope that we will finally see goodloking qt applications, such as text editor or music player.

[Terrablit]

I tried getting into Vala a few years back. I really did. I liked the modern C# style with the ability for portable native code. At the time, the landscape had undergone a few unstated changes. Many previous Vala editors had been abandoned, new ones had been introduced, and it was extremely unclear where to start. I was working in a Windows dev shop at the time, and I had the bright idea that I could make GDI (Win32) bindings and some language auto-completion files for a few editors to make simple native x-plat GUIs more attractive. Especially if I could abstract things away into platform-specific DLLs. But the documentation on making VAPI bindings (https://wiki.gnome.org/Projects/Vala/Bindings) was horrible. Finding recent, relevant and correct information about anything in Vala was a huge chore. Tutorials for building were sometimes wrong/incomplete. Builds for windows were extremely outdated.

Not only that, it all went through MinGW and a native valac simply wasn't an option - it was trapped in a lot of GNU/GCC-isms. I built the Hello World app and it compiled, but the way things were linked made it non-functional outside of MinGW. It's like they literally don't care about this ever being used outside of GNOME, which severely reduces their potential userbase. The final nail in the coffin was the extremely reduced functionality if you didn't use GLib/GObject (http://stackoverflow.com/questions/9...ithout-gobject). I can understand reusing existing code, but I didn't want that level of dependency on a toolkit baked into a low-level development environment. I'm not sure exactly how little of GLib and other GTK+ libraries I'd be able to get away with and what the actual separation line is, but by that point, I'd lost all interest in finding out. What should have been a straightforward use case had wasted several days of my time.

Thanks for trying, but Vala's so limited that it's just not worth anyone's investment outside of GNOME. When I'm working with a language, I want something that's complete on its own with a straightforward way to do builds or obtain new binaries. Transpilers should be even less demanding of your build environment, in my opinion, since it's a source-to-source process. And the way they go about bindings is horrendous, given the relation to C#. Comparing the VAPI gerrymandering to P/Invokes (or even Rust's FFI (https://doc.rust-lang.org/book/ffi.html) shows the level of thought the devs put into it. And Vala just hasn't got nearly enough thought put into it. They've got a passable language, but a horrible binding process, limited tooling, anemic documentation, and tunnel vision for the GNOME environment. I just don't see how it's going to grow unless it makes some major changes. And that's going to be hard after it's passed the initial flurry of interest.

[Delgarde]

Why invest any time learning and developing in these trendy new languages, if 2-3 years later they could end up "dead", "unmaintained", "irrelevant". What languages will fall out of fashion next, Node.js? Go? Rust? How often do we need to rewrite the same applications for the same purpose over and over, because of this, and obsoleted frameworks/APIs?

You could say that of any language though. But the problem with Vala is that it never was particularly trendy - it was introduced as a C#-inspired language for people working with Glib and related frameworks, but even within the Gnome community, it never caught on that well... officially recommended, and adopted by some, but never got widespread attention. Not surprisingly, since who would want to learn a new language just to work on one DE?

The other languages you name - they're all *far* more successful already than Vala could ever have hoped to be. They're fashionable, yes, but they're not going away in any hurry.

[Marc Driftmeyer]

Why do you hate the Gnome developers so much? Rewriting their code every time a compiler (and a new language gets released) is not something you really want to do. We switched back from Swift to Objective-C. As much as we hate it, because Swift is overall a nice language – but there is no way we throw away three quarters of a years work in the bin because the code got useless after a year a second time. There is a reason Swift adoption is not very great among developers with more than average "fart app" code base size.

I'm all for moving the code stack to being C11 top to bottom; and then leveraging C++11/14/17 if necessary for MVC patterns. Device drivers are C/C++, Kernel is C/C++, etc., making the need for unnecessary bridge interfaces at a minimum. With Swift 4 supposedly Apple's first foray into a system-wide usable version in macOS you know its support being opened and added to LLVM/Clang project is a forgone conclusion: a guaranteed rich and long term support for the language, plus interoperability with C/C++/ObjC.

[Guest]

Yeah, right.

https://bugreports.qt.io/browse/QTBUG-58811

https://bugreports.qt.io/browse/QTBUG-57714

I think there might be more.
Segfaults every Qt update are cool.

You pointed two bugs as your argument? What a pathetic troll. Ps. broken themes in gtk 3 are cool as well!