Vala provides you a way to write C/GObject/GInterface code using a different syntax. Vala doesn’t require to develop a “core library” in order to provide its features. Its “compiler” is not a compiler, is a C code generator.
Vala can’t be compared with Rust, Go, Python, Java or C#, all of them provide their own “core library” in order to provide most of their features, allows you to create modules (like a library) to extend the language for their users consume. Their core generally is written in C, for very basic features, but almost in the language itself.
Vala is different in many different ways to other real programming languages. Vala can’t exists without GLib and GObject. It just wraps that libraries to provide its Object Oriented syntax. It doesn’t provides any feature by it self, just a syntax to use the ones already present in above libraries, a part to provide some convenient methods to reduce coding boilerplate.
GLib, GIO and GObject are C libraries. They are the basis for GNOME, GNOME Shell and any other application using GNOME technologies. GTK+ and any library or application using it, relays on above libraries, they can’t exists without them. VMWare and LibreOffice consume GTK+ and so GLib/GObject.
Vala provides mechanism to create bindings. They are conventions to help Vala’s code generator to produce correct C code to consume any other, apart of GLib/GObject, libraries. It can do better job if the library use GObject.
Vala is not a Language: This is a conclusion after the On Vala article, comparing Vala’s repository’s activity with other real languages.
May we need to add to Vala’s activity, all commits and developers on GLib, GObject, GTK+ and GObject Introspection, because they are, indirectly, supporters of Vala’s features and usefulness; may be we need to consider all other libraries’ activity, like libsoup, libgda, and any other one supporting GObject Introspection, because they can be consumed by Vala; this is specially true if we consider their support to generate, automatically, Vala bindings.
Considering all of these, if Vala was a real language: it can be considered to be one with a very reach, secure and stable “core”, with years of development behind; with a reach set of other libraries for your use, as a developer, to choose from. But again: Vala is not a Programming Language.
Vala is multiplatform as long as its Code Generator and their libraries it depends on, or can bind, are present in your target platform: Windows and OS X, are just examples.
May is time to update Vala’s README and vala.doap at git.gnome.org, in order to avoid missunderstandings.
That Vala happens to compile to C as an intermediary language is just an implementation detail. Vala is definitely a programming language just like Rust, Java and the likes.
maybe some comparisons could be
– how easy it is to write vala applications vs to write rust application
– how performant is vala C generated code vs rust code
– how easy it is to maintain vala code generator (err… actually not that fair given rust is already maintained by other)
May is not a good idea to compare Vala with Rust. Rust have its niche too. Vala and Rust can work together in order to get benefits from each other like consume GObject C libraries (Vala ones comes in here) and Rust packages with C interfaces.Rust C interfaces can be consumed by Vala as well.
May a GSOC to create bindings automatically is a plus benefit for all.
While I agree that it is not a complete language, it is certainly a transform. In that way, you need to at least compare it to something like CoffeeScript. I haven’t used Vala in a while, so I’m quickly trying to get back up to date on it. One of the biggest things that hurt CoffeeScript was that the tools lacked the transforms, so you had to debug the Javascript.
It looks like the debugging side has been done according to https://poisonpacket.wordpress.com/2015/05/20/debugging-vala-programs-in-an-ide/ . This means it must’ve been around for over 18 months at this point, so it’s in most distros.
Has the compiler errors been corrected as well? The last point that I vala, I would get some awful compiler errors about the C code that was difficult to relate to my Vala code.
Finally, my last comment is that Vala is a niche language that is really only useful for GNOME apps and libraries. I think people would be hard pressed to recommend it for web programming or utility libraries that don’t need a GLib interface. So it’s a niche language in a niche market. This means people must not learn a general purpose language that they can take to other work and must dedicate time to learning this one as no one just “passing by” will have knowledge of this language and THAT hurts Vala.
I’m not saying that Vala’s a bad idea. I actually generally like it, but it would greatly benefit from some serious flushing of the documentation and tool support. I agree that the GNOME Foundation needs to either step up to make it easier for developers to use as a drive-by language OR stop recommending it as the suggested language for libraries. (I’d argue the same for JavaScript as well.)
Basically, I think Vala’s a great idea. I think the GNOME Foundation thought that by recommending Vala that Vala would gain more volunteers. In the end, it put more pressure on those maintaining Vala, more people comparing options and saying Vala’s not quite there and therefore skipping it or GTK+ or both, and those people not choosing GTK+ is hurting the GNOME community at large.
May you want to read:
https://blogs.gnome.org/despinosa/2017/02/14/vala-1-0/
There are some integration to other tools too, including GNOME Builder. Its level and stability of the pluging,not necessary
releated to Vala, make it usable; just turn it off and you are Ok with Builder, I prefer over GEdit.
At this point there are some reluctance to work on Vala support in projects like Builder or Autotools. I’ve filed bug reports and send patches, but review and acceptance have taken too much time.
If that continue the way for Builder, may is time to switch back to GEdit, with a more mature plugin system, in order to provide better IED for Vala, with autocomplete and online error detection. If so for Autotools, Meson is an ancient build system may open to get patches for Vala integration improvements. This is already going on by AutoVala, providing CMake and Meson support for Vala projects.
Hurts Vala is Hurts GNOME in general, because C programming is a pain way for startups. Vala can provide shorter development times and promote GNOME’s technologies. Some other prefers C++ over C, and so Qt instead GTK+.
We need to provide useful and powerful libraries in C, with good integration with C++ and other language of choice. This is true for GLib/GObject and GTK+, but while there are technologies for OOP, like the ones on W3C, they are difficut to implement and maintain in pure C. Vala at rescue, see at GXml, in order to find how “easy” was to implement DOM4 over libxml2 using Vala and GObject.
Vala is a language as much as C or C++ or Java.. For all of those, the compilers transforms them to an intermediary form before outputting a binary. The fact is that the C generated by Vala is not nicely debuggable, just like if you were to try to debug C but could only see the assembly output in your debugger, it would be a pain.
As for not having it’s own platform, you could say the same thing for Javascript, which doesn’t really have much of a standard library either. And no one doubts that it’s a real language.
How can you take Vala and compare with C? Vala produce C code, Vala is the Egg and C is the kitchen. No Vala code is directly compiled to create executables, is just a C output. JavaScript have an interpreter, compiling directly to machine instructions. Python have a binary intermediate, more efficient, format but is binary no source code.
C code in Vala, may is really hard to read, but for inexperts C/GObject/GLib readers. Any way, discussion is not on C generated code, but how Vala is just a convenient way to write C code, but limited to GObject/GLib most of the time. Vala is not for general use outside GLib/GObject.
If you choose GLib/GObject, you’ll find Vala a good choice to prototype your application or library. You can keep it or start again to re-write all in C in order to avoid Vala. Don’t use Vala outside GLib/GObject.
If you are GNOMEr, may you want to use GLib/GObject and/or GTK+ for your project, use C or Vala is your choice and will depends your time to get something working.
C may is one reason others have chosen C++/Qt over C/GLib/GTK+.
It’s a reason that I chose gtkmm over GTK+ originally, because I was just starting GUI programming and already learning C++, whereas the GObject acrobatics required for GTK+ seemed like added confusion to me. But now I can appreciate GTK+/GLib itself more and might write a future project directly in C.
The point is that one need not immediately flee to Qt (which looked like a macro-laden mess last I saw it, and there were still pointers everywhere, unlike gtkmm) but that there are other bindings available – and if you like C++, then gtkmm is fantastic. I don’t know why everyone is focussing on Vala when many other bindings exist. Even the official site’s Development section only focusses on Vala and gjs. That seems bizarre to me!
And, of course, I also chose GTK+/mm over Qt because they simply have better and more of the features that I needed for my application. They have a perception as being only for GNOME developers, but to me they seemed superior for mere ‘third parties’ like myself, in terms of the widgets available and how configurable they are, which matched my project’s scope far better.
I used to program in C++, then felt in love with C and GLib/GObject. Helped libgda to improve for a while and now improving its C API to be GObject Introspection friendly.
Now even to be more a Vala programmer, I contribute to projects in C, making things better for GObject Introspection to use them in Python, then Vala.
About documentation in C++, you’re right, examples for gtkmm are required, may you want to file bugs and attach examples to improve the situation. I feel C++ should have same attention as any supported development platform for GNOME.
Now just take in account that creating bindings for Vala are easiest than in C++. With GObject Introspection (GI), a great GNOME technology, almost all GObject can be automatically parsed to GIR and TYPELIB without human intervention, they makes available latest API in Python, JavaScript and any language supporting GI at day 1. Vala some times requires a little more work: create a metadata file once and update if thinks change, but again automatic Vala bindings are available.
With GI in your C/GObject library, you can provide Vala bindings without any extra effort. As I do for libsoup to support GI and Vala bindings upstream.
“If you are GNOMEr, may you want to use GLib/GObject and/or GTK+ for your project, use C or Vala is your choice and will depends your time to get something working.” – I think this is part of the problem Daniel.
I’d understand if this was a post in response to the tweet ebassi sent as it wasn’t the best platform to lay down constructive input as to why he was proposing what he was proposing but his blog post was fairly straight forward and offered feedback on how the situation may be improved.
I don’t think personally that it serves gnome well as a platform to require developers not only to learn about how to make use of its underlying technologies but also to learn a domain specific language in order to do so. And yes, vala is a language and always has been.
Moving the goal post in the way you are attempting to do with this post when someone points out problems is not a constructive thing to do and won’t help vala if you want to see it move forward.
Personally I think gnome would be better served advertising , improving and building communities across gobject introspection and as many languages and communities as possible.
It shouldn’t recommend for developers to just use either gjs or vala.
I see where you are coming from in terms of being recommended to just use rust instead. I like it myself but the main language I used in college was Java and can sympathise with someone asking you to completely up and change how you think and go about writing code.
I don’t think anyone is saying vala will disappear tomorrow.
In terms of Java/c#like languages, the GI documentation and support could be improved. Who knows, maybe dart might be compelling for people at some point in the future, they have an experimental llvm backened that would be more worthwhile picking up and trying to move forward with imho and language server support, the tooling is already there. And someone started gobject introspection support that could also be picked up.
It’s also been standardised.
I’ve been coding in the industry for 35+ years. Languages die when they are not used or when the vendor shuts them down. Like RatIV or VB6, examples of these reasons. Fewer commits? Is that all this is about? That speaks to stability and or lack of commitment. Or does Gnome just scare people away from Vala (my opinion)?
I see it as both a full stack, and a language – comparable to DotNet/C#. It opens up technologies I would never otherwise give a second look.
Right now, I’m independent, and for my current project, a game, the two finalists were Genie and FSharp. Genie edged out F# on performance and plus it’s easier to write code. VSCode and autovala provide sufficient tooling for a Vala project.
What is a language ?
the method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.
“a study of the way children learn language”
2.
a system of communication used by a particular country or community.
If the language definition is bounded by the means to communicate, vala is a mean to communicate, so it’s a language.
What is not a language ?
If the definition is based on the outputs, where languages that don’t generate binaries are not languages, because the premise that only languages that generates binaries are languages, vala, java (with its JIT compiler), elixir (HIPE compiler), ELM, are more… are not languages.
So,
If one day, someone write an interpreter that converts C into vala code, so C will not be a language anymore and Vala will become a language?
I prefer the dictionary definition…