Originally posted by Pepec9124
Announcement
Collapse
No announcement yet.
A GNOME Developer's Arguments On Vala Being A "Dead" Language
Collapse
X
-
Guest repliedLast edited by Guest; 14 February 2017, 03:47 AM.
-
Originally posted by lordnaikon View Post
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.
Leave a comment:
-
Originally posted by stevenc View PostWhy 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?
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.
- Likes 4
Leave a comment:
-
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.
- Likes 2
Leave a comment:
-
Originally posted by ikey_solus View Post
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.)
Leave a comment:
-
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.
- Likes 1
Leave a comment:
-
Originally posted by Trevelyan View PostHow good would corrode be at converting Vala generated C source to Rust?
As some others have said, it would likely be easier to rewrite then to try and deal with automatically generated code.
Leave a comment:
-
Originally posted by Marc Driftmeyer View PostOr 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.
- Likes 2
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by Mateus Felipe View Post
I really hope not. Solus made a shitty mistake when decided to switch to Qt. ElementaryOS shouldn't do the same.
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.)
- Likes 5
Leave a comment:
Leave a comment: