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

[lordnaikon]

1st class GObject support in Rust (incl. as a producer), now that would be something!!

maybe not to far away

https://siliconislandblog.wordpress....ico-city-2017/
https://wiki.gnome.org/Hackfests/Rust2017

[jacob]

1st class GObject support in Rust (incl. as a producer), now that would be something!!

[stevenc]

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?

[tegs]

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

Maybe you should wait until Budgie 11 and the next ISO come out before you act like a total prick.

[Trevelyan]

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

[Mateus Felipe]

I guess they will switch to Qt as Solus project did.

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

[pipe13]

Time to switch to world most widespread and stable toolkit, QT.

Well... it always comes down to just what you want to switch. I myself switched from GTKmm -- the C++ wrapper to GTK+ -- to Qt some years ago. I like Qt. I also liked GTKmm. Note they are both C++ development toolkits. And I like C++. But C++ does not appear to be for everyone, and one of GTK's driving philosophies is that their toolkit should be readily wrappable by other languages. That doesn't preclude C++ from the job, but doesn't make for a strong recommendation, either. *The* standard for API compatibility between languages is the C language API, which is probably a bit more readily exported from languages such as Vala, Rust, and Go than from C++.

Vala is designed to be a robust, efficient low-level language with C capabilities, but devoid of some of C's arcane gotcha's. I spent some time a few weeks back going through some Go tutorials, and as a long-time C/C++ developer, I can see some merit to the approach. Which doesn't mean Go itself -- which is garbage-collected -- is necessarily a good replacement for Vala. Hence the interest in Rust.

Also, it isn't clear yet that Vala will be replaced. Bassi just points out that Vala is still a niche language, short on support, and should probably either grow or die.

[JonathanM]

As far as I know, Vala code gets translated to C then compiled to executables that use glib. At worst, just remove the vala code and work with the already generated C code? or is not possible?

It may be easier to translate the application by hand than to clean up the mess valac generates.
It is correct code, at least in my experience, but unless you like reading long code with lots of variables named like _tmpX_ (where X is a number), it is ugly.

*takes a look at generated c code for own vala code*: I really wouldn't want to use the generated C code...

[jKicker]

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.

Agreed.
Our company depends on it because there really is no better alternative that would be cross platform, nice and fast (QML). I personally vouched for it and I still think it's the best of the rest.
But the amount of bugs is unbelievable.

As far as I know, Vala code gets translated to C then compiled to executables that use glib. At worst, just remove the vala code and work with the already generated C code? or is not possible?