Elementary OS (https://elementary.io/) probably has the most thorough usage of it, most of their DE and all of their built in apps are written in Vala (as well as most of the 3rd party apps published through their store).
I wonder how much of their success is due to vala. I assume they're all gifted but vala seemed to be the right vessel to channel their ideas and reach high goals faster.
I would say the greatest strength of Elementary is being very consistent and opinionated, which I imagine the heavy usage of Vala helped with. It really does feel to me like an even more opinionated version of GNOME (heavy usage of Vala and GTK, mandating all apps published to their store also be GTK and open source, having a very specific desktop experience without many customization options).
Yorba was around for a bit and did a few really ambitious applications in Vala, but never really finished and kinda disappeared. Shotwell and Geary came from them.
I've always found Vala intriguing but a little too niche for my tastes. That said, if I wanted to write a cross-platform app in it today with a visual GUI builder (Glade?), what is the best IDE/tools on macOS to edit programs of it with? Visual Studio Code with some plugin?
FreePascal/Lazarus seem to aim mostly for the people already using its predecessors. I see little to no "evangelism". Even new niche languages like Nim or V seem to have more "momentum".
It might seem odd, but have to agree, in terms of lack of "evangelism" on the part of Object Pascal users and developers. I think this is partially because of the long "language wars" involving C/C++/C#, and continual propaganda claims by competitors that it is "dead" for the last 20 years, many might prefer to quietly indulge their preferences.
Delphi/Embarcadero does attempt to push the needle some, but of course its more for their own benefit, and arguably not as much for the language in general.
There is also the perception of what languages are favored for jobs (though freelance and independent work seems overlooked), despite that Object Pascal/Delphi is still doing quite well in the rankings (and for many years). Often floating between TIOBE's 10 to 15 rankings, and among or ahead of many notables like Go, Rust, Lua, Kotlin, D, Nim, etc... Who nobody in their right mind would claim are "dead".
One could argue that Nim had its shot, as its no spring chicken. Nim is older than Go, and has been around since 2008. So if it was going to get "the push", would think that would have already have happened.
V (vlang.io), on the other hand, comes across as a special case. Is still relatively young, so could possibly at some point make a run towards heading up the charts. It's in a sweet spot between being both a C and Go alternative, and has taken the approach of studying other languages to make itself more appealing, useful, and practical. Perhaps the sport's term, when describing a prospect, is that it has a "high ceiling" or high potential is the most appropriate.
Or companies like Microsoft finally come out with a C++ Builder alternative (C++/CX), and a couple of WinDevs starts a mutiny, brings back the C++ developers experience 20 years back to their beloved VC++ 6.0 COM development tooling, paying customers be dammed.
Microsoft are damned if they do and damned if they don't. One could just as well criticize C++/CX for being a proprietary language extension that only works with their proprietary compiler, and for not following C++'s zero overhead principle. A major selling point of C++/WinRT is that it's just standard C++. And like I've said before, thanks to modern C++, C++/WinRT is far better than libraries like ATL that were available for VC++ 6.0.
By developing and using C++/WinRT, the Windows developers are prioritizing what's best for their systems programming work, as they should. Convenient tooling for rapid application development is the job of IDE developers, like the Visual Studio team. I think one of the mistakes of Windows 8 and Windows 10 was that the Windows team tried to directly provide conveniences for high-level application developers, built into the platform. I'm glad they've backed away from that. I know VS already has some tooling for C++/WinRT. Maybe they just need to do more work on that. Personally (as someone who no longer works in the Windows org, or at Microsoft at all), I'm glad I can use C++/WinRT, which is just standard C++, with any build system I want, and presumably even with clang rather than VC.
I understand that for C++/WinRT movement, critics of paying customers left out in the cold are a bit harsh.
Well next time do a proper job, given that even ATL has better Visual Studio tooling.
The non standard extensions excuse apparently is only an issue for Microsoft compilers, as you are enjoying those clang extensions without problems.
The way management has dealt with WinRT ecosystem, it turned many of us that were hard advocates, into disgruntled developers that only wants it to implode as if it never happened.
In what concerns WinRT, "Developers, Developers, Developers" is long gone.
Short version story, a group of WinDev folks weren't happy with C++/CX and its C++/CLI extensions.
So they brought in Kenny Kerr, which was trying to create a C++ library without those extensions.
Out of that effort, C++/WinRT was born, they deprecated C++/CX (5 years ago) and told Microsoft customers to suck it up and wait for the day C++ gets reflection, because they couldn't otherwise provide the same level of tooling for C++/WinRT, as C++/CX enjoys on Visual Studio.
Nowadays they are having fun with Rust/WinRT, while every customer that has to deal with C++/WinRT enjoys editing IDL files without any VS tooling, and merging the generated C++ code manually, after every IDL change.
To the point of that even MFC has better tooling for dealing with COM.
A tiny group inside Microsoft is now happy, while all customers deal with the mess they left behind.
Pascal is an really uncomfortable language to be writing new code in 2022. In 2005 it was arguably better than most flavors of C++ but now it belongs to a museum.
But oddly, Nim never went in that direction, despite its Object Pascal roots. Have instead seen some Golang Golphers try to modify the Lazarus IDE for their purposes.
Vala does have optional parameters! Maybe it wasn't there in the initial version, and now the core API is stabalized so they don't use it for that call?
Here is a random example I found on the interwebs:
Props to the language creator for showing us example code right away, at the top of the page.
Half the time a new language gets introduced here and I spend 15 minutes hunting for some page somewhere on the site that deigns to share what the code looks like.
Agree with the point, but Vala is pretty old (relatively speaking). It's been around for a while and the whole idea is to have a GTK/GObject-focused C-family language. Last I looked it was a C transpiler and may still be.
And if you've ever used GNOME, you've probably used some Vala applications!
I like to use Cheese, the nice little webcam app, to test a webcam when I first set it up or just take a selfie, even when I'm not on GNOME. That's a Vala application :)
Yes! I also like that a lot. I think Racket has one of the best programming language landing page regarding this criterion: https://racket-lang.org/ :).
I always found it quite odd that the recommended way to start building GTK apps is to use Vala. As a young developer it was pretty intimidating (even though the syntax seemed pretty close to what I already knew) and also it was a little disheartening I can’t use JS because I really wanted to use React. Anyway, I think it’s a cool language, but I kinda wish Swift, Vala, Kotlin etc could have consolidated to one language
You can program GTK (or Gnome actually) in JS. The issue is that it's a very idiosyncratic and not very well documented Javascript engine built on top of SpiderMonkey. Most stuff works as expected, other things like npm packages are an absolute pain or just impossible.
Oh, I didn't notice Vala had this new(?) web site, it looks good.
From my early experiments with Vala, years and years ago, what I remember is that it had nice error messages and the author was very consistent in releasing new versions even when there wasn't too much momentum.
Also, on Arch I use Pamac as a GUI for package management and it is written in Vala as well.
I have used apps for quite a long time before realizing they were written in Vala. Not great for marketing but otherwise I would consider that one of its strengths.
Rob Pike famously explained that C needed its space-insensitive braces and semicolons in case code was transmitted through a channel that mangled whitespace.
Those days predate most people reading this, yet many new language syntaxes opt for "familiarity". I wish that all language design went through a filter where every character mattered like the designer was in an episode of Squid Game.
Bill Joy famously explained that syntax matters, a dense syntax puts more on screen. This is true even now. I struggle with this; my favorite syntax is a preprocessor that eliminates the need for most Lisp parentheses. The result is code poetry. Nevertheless, Haskell is more expressive.
(Here's an easy test: Anyone who proposes a way to minimize Lisp parentheses, who hasn't introduced a symbol for missing outline levels, is just pulling out chunks and hasn't used their system to write thousands of lines of code.)
I've written most of my lifetime of code in C, established my career in C, and C syntax is ground glass in my eyes.
> I wish that all language design went through a filter where every character mattered like the designer was in an episode of Squid Game.
Yes, I totally support this! Coming from languages like Haskell, most languages look so unnecessarily noisy to me. Cut the fat!
> Anyone who proposes a way to minimize Lisp parentheses, who hasn't introduced a symbol for missing outline levels, is just pulling out chunks and hasn't used their system to write thousands of lines of code.
What are outline levels? I tried Googling it but didn't find anything.
> C syntax is ground glass in my eyes.
Is that a good thing? I'm not sure what you mean by it.
> Rob Pike famously explained that C needed its space-insensitive braces and semicolons in case code was transmitted through a channel that mangled whitespace.
Interesting.
And later when he (along with his collaborators) created Go, he moved with the times and avoided the need for semicolons.
Alongside they also shipped a tool that handles formatting so people can stop talking about that.
Not only that, afaik they pioneered/popularized a style of coding where the formatter is always correct, not the coder. This made coding on every language much more enjoyable and more efficient.
This is not something to write papers about, but a very significant thing anyway.
Anecdotal of course, but a teacher of mine worked on the original Ada compiler and said each dev had their own formatting rules. The SVN had an unformatted version and everyone could format it locally. Not the exact same, but pretty similar.
>Rob Pike famously explained that C needed its space-insensitive braces and semicolons in case code was transmitted through a channel that mangled whitespace.
But did he explain why it used semicolons, rather than periods, which would make more sense because a statement is basically a sentence?
Periods are in struct.member identifiers and also in floating points. Using them again for end of statement would be complicated[1].
Imagine that your statements are "x = y.x = z." The compiler needs to figure out if that middle dot is saying "x member of y" or if it's a statement terminator.
[1]: It's already complicated by that reuse, which is, I assume, why identifiers can't start with digits so your parser can be simpler.
I assume that the statement terminator was chosen first, so they could've used something else for member access, such as `\`. Though I don't know about floats.
They could have used a comma for floats, as is common in many non-English-speaking countries. Although I guess that might become ambiguous with its use as a parameter separator.
Other reasons for the a bit of noise: speed, simplicity and unambiguity of parsing. (Impacts compilation speed, ease of additional tool development, and ability to continue parsing partially incorrect code)
Nim, last I used it a couple of years ago, stopped at the first compilation error. It's not such a bad idea considering errors are usually fixed one-at-a-time.
I'd gladly trade a little compilation speed and ability to continue parsing incorrect code for a syntax without semicolons, braces, and other unnecessary characters. It's one of the things I really like about Python, though even that is starting to add lots of syntaxy glyphs.
They should mention about it on the front page!I mean vala is looking pleasant to work with other than c++. So is there any resource to follow along? Can I create an app in macOS with vala sdk?
int main (string[] args) {
var app = new Gtk.Application(
"com.example.App",
ApplicationFlags.FLAGS_NONE
);
app.activate.connect(() => {
var win = new Gtk.ApplicationWindow(app);
var btn = new Gtk.Button.with_label("Hello World");
btn.click.connect(win.close);
win.child = btn;
win.present();
})
return app.run(args);
}
No. The Vala code is creating an entire window and application. Your HTML code is just creating a button inside a window and application that already exists.
The equivalent portion is just these two lines:
var btn = new Gtk.Button.with_label("Hello World");
btn.click.connect(win.close);
Clearly no, because Vala has a bunch of issues with memory safety. Not because it's a bad language, but since it translates directly to GObject, there is a lot of problems around pointers, ownership, ... mainly because that language lacks maintainers and GTK/Gimp developers didn't like it because they are "C essentialists".
"C essentialist" is a line very hard to hold, because C via ISO is moved towards an horrible language like c++ (generic,__thread,etc). So, it is not C anymore, it is simple and lean C which should be the target of an essentialist line of conduct.
Whatever, a good new language would first and above all be easier to write a compiler for than simple C.
To access TLS-ized system variables (for instance errno if I really need to, I would use the sysv ABI __tls_get_addr() function).
But in the application domain, I would use pthread TLS.
No, pthread TLS is the slower one. Accessing system TLS can be done fast since lib knows the details of the implementation and, worst case, it can use inline assembly.
Also, pthread TLS adds a pointer dereference to each access.
The compiler does not know the inner layout of how the system TLS variables are stored (could be musl way, bionic way, glibc way, etc). It only knows that for system TLS variables it has to go thru __tls_get_addr(), stated by the sysv ABI. Indeed, you are not forced to use pthread TLS to cache the value, you can use your own thread allocated memory, or keep it around on the stack/regs. On x86_64, once you have resolved the address with __tls_get_addr() you can use the same address value for all threads, then use common to all thread storage.
I read somewhere that some Gnome (and elementaryOS) people are looking for replacing Vala code with Rust. I can't find the exact place, but this is going on since 2016 at least https://blogs.gnome.org/despinosa/2016/11/01/rust-and-vala/
> Rust is on the horizon and have voices to use it instead Vala
As someone who has helped create the new Vala website, this seem a bit weird for me to say but I believe that people should code in whatever they feel that they can be most productive with. If that language is Rust then go for it!
And a few people liked the language, but a lot of users complained about the memory bloat this introduced (this was back when people cared about RAM).
So Vala is trying to be the best of two worlds, having C-like resource usage with some of the language niceties of C#. Probably wouldn't have happened if Mono didn't prepare the way for C# syntax in the GNOME bubble.
Not quite so literally. But Vala itself is blatantly C#-like syntactically. And if you look at the original combination of C# (circa 2.0) + WinForms, they have the same symbiotic relationship as Vala and Gtk.
Mono is much more than just C#. It was created by GNOME folks so they could use .NET to develop GNOME/linux software. In that way, Vala is similar to Mono: they were both created as replacements for using GObject-C to develop desktop Linux softeware.
It's almost more like c-flavored visual basic for gnome (based around gobject rather than COM).
c# is more of it's own thing whereas visual basic sort of had the same underlying idea of "hey we have this object library that has its own memory allocation primitives and data structures; what if we exposed it as its own language rather than making everyone use it from c/c++"
Not de facto as in universally (or even primarily) used. De facto as in "the language of GNOME", i.e. one built for and used by GNOME as a first class citizen.
I've never tried it & have no opinion, but they're often compared, have similar goals, and it's name is mistakable for Vala, so I believe this is what they were asking about.
