▲ 185 points
back
75 comments
A similar language that was created to make creating GUIs more pleasant is Jakt [1] for SerenityOS which is Impressive to see how fast they've been able to develop a pleasant modern native language, went from 0 to rust-based then self-hosting compiler inc. VS Code static analysis & intelli-sense in weeks.
Like most of SerenityOS you can follow much of its development is on YouTube [2]. A good video series that captures the language ergonomics is in the "Jaktness Monster" series which goes through creating a NES Emulator from scratch [3].
[1] https://github.com/SerenityOS/jakt
Jakt looks pretty interesting. Would “rust without the productivity sapping affine types / lifetimes / borrow checker, but with zig’s take on comptime” be a fair summary or am i doing an injustice?
For me it looks like a more pleasant, productive and safer native language than C++ with emphasis on readability and safety. It's definitely inspired by other languages with similar goals but I wouldn't consider it defined by them.
One of its Co Creators @jntrnr was on both the Rust core language and TypeScript language teams which was how they were able to build the first rust based compiler + VSCode static analysis so quickly. Once the language was capable enough they rewrote the compiler in Jakt where it's now self hosting.
Excited to track its trajectory given how fast they were able to develop it, which already has a nice development experience in VSCode.
Jakt looks very much like Swift. Objects are reference counted, structs are always value types, all function arguments require labels, no semicolons.. it's clear that Kling has worked for Apple.
I like the language! It is so much more readable than Rust. I might switch from Rust to Jakt once version 1.0 has been published.
Funny, because I feel that affine types make me much more productive in Rust :)
Comptime would be nice to have, though!
So they made Swift and slapped a new name to it
Exactly my thought. Looks like a poor man's swift (poor because many features from Swift are still only in planning).
The one difference is that jakt is transpiled to C++ (IMHO it's a disadvantage, but could be useful).
Obviously Swift is going to have more features given Lattner started first developing it in 2010, but it's built on flawed foundation given many years after release valid syntax would kill both the compiler and bring down Xcode as well.
Having experienced compiler engineers from the start is important for how well designed the language is syntactically and how strong its foundation is which helps with correctness and development velocity. Swift is always going to be the primary choice for Mac/iOS Apps but it sees relatively little usage elsewhere, either way it's going to be interesting to track Jakt's progress given how well designed it is and how fast they've been able to develop it.
>was created to make creating GUIs more pleasant
Checking through the repo and videos, I don't see how this is the case. It seems a pleasant language but there isn't something GUI specific. That said the last one seems to have an issue frequently attributed to Rust, specifically requiring much effort to wrap an "unsafe" library for usage on "safe" language.
In his videos Andreas mentions the motivation for creating Jakt was wanting a safe productive language for developing SereneityOS and its GUI Apps for the long term future as he didn't believe the trajectory of C++ was going to be suitable and found other languages unsuitable for adoption in SerenityOS so he teamed up with JT to create a new one without C++'s unsafe footguns, initially transpiling to C++ so it's easily integrated into SerenityOS build system and able to access their existing C++ libraries.
They're still actively developing inheritance support which I believe is the last remaining feature before they can start creating SerenityOS's (OOP) GUI Apps with it [1].
Any idea what kind of effort it would take to get Jakt working on another OS?
It already can, as it currently just transpiles to C++ it just needs clang to build [1].
Even though it doesn't require SerenityOS, even SerenityOS GUI apps can be ported to run on Linux, Andreas already has ported its Ladybird Browser that wraps SerenityOS LibWeb engine in a QT App [2] to Linux, his last video shows "Abstracting the event loop so Ladybird can be fast & responsive on Linux" [3]
[1] https://github.com/SerenityOS/jakt#usage
They're making it as a transpiler to their dialect of C++. On other OS it can also work because they have the Serenity Browser engine running on Linux. So probably take some parts of the build chain there and off you go.
GTK invented its own bespoke Object Oriented Programming system for C, called GObject: https://docs.gtk.org/gobject/
Naturally, it's very annoying to use this C-based OOP API in any other language, especially languages that have their own incompatible OOP type system like Java or C++.
One of the biggest reasons to use Vala is that it's OO system is GObject, making interacting with GTK and GLib code significantly more painless.
GObject is a real tragedy of the NIH syndrome in open source.
In the late 1990s there already was Objective-C. It already had open source compiler support, a battle-tested runtime, a free software desktop environment, and a corporate sponsor that became the world’s most valuable corporation.
Instead of using what was already there, the Linux GUI community extracted a poor shadow of Obj-C out of the GIMP image processing program (itself a poor shadow of a commercial market leader).
GIMP development started in 1995. The GNU Objective C frontend (the one that has stayed in use) started in 1993.
I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world.
And all these years later, at a time when Apple has essentially abandoned Objective C, GTK and Glib continue to provide bindings for dozens of languages to create cross-platform GUI applications, and even if many of us don't agree with the direction(s) it has taken, GTK itself has continued to evolve, whereas UI libraries that came with Objective C have become frozen in time.
So in short, not really a tragedy at all.
Apple has not abandoned Objective C. It still has first class support on all their platforms, and the vast majority of their OS frameworks and applications are developed in ObjC. Swift is growing as an internal tool, but it’s nowhere near even 50% of the 1st party code on a mac or iphone.
Improvements have slowed on ObjC, as Apple’s focus switched to swift - ObjC 2.0 in 2014 was the last major change.
> I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world.
I think you misunderstood the criticism. They didn't say GIMP used the wrong model when it started, they said the greater community was wrong for copying GIMP later on.
> And all these years later, at a time when Apple has essentially abandoned Objective C, GTK and Glib continue to provide bindings for dozens of languages to create cross-platform GUI applications, and even if many of us don't agree with the direction(s) it has taken, GTK itself has continued to evolve, whereas UI libraries that came with Objective C have become frozen in time.
The suggestion is that Objective C should have been used instead of GObject. That doesn't mean having to use any particular libraries. And the same work to bind and evolve could have been poured into any reasonably solid library.
> GIMP development started in 1995. The GNU Objective C frontend (the one that has stayed in use) started in 1993. I would hardly consider the GIMP developers (who became the early developers of GTK) to be rash in their option not to adopt a language that had only been available for a couple of years in the open source world.
Early in 1997, Guillaume Laurent and I spent some time looking into Objective C as a possible language for the "next version" of the Rosegarden sequencer on Unix/X11. At the time Rosegarden was a C application[1] using Athena widgets with my own little styling library, and we were sure there must be better options and were prepared to rewrite the UI entirely if we had to.
We ended up ruling it out for a few reasons, which I've just looked up in old email archives. I had some trouble getting the then-new gcc Objective C runtime working across Unix systems (we didn't only target Linux) and feared that we wouldn't be able to give our code to someone else and have them compile it easily. We couldn't find a working graphical toolkit: we thought GNUstep wasn't ready and also that it was probably going to be overkill. Other possibilities like NSXKit[2] weren't there either. Guillaume experimented with writing a toolkit himself but quickly ran into various obstacles that I don't have a record of.
(What is striking in hindsight is how hard it was to find reliable information to help us make a decision like this. There was documentation, and there were opinions, but there was very little of the form "we used this for our project and here's how it worked" that you would begin to see after blogging had become commonplace. We worked mostly on supposition and projection - install something, see if we could get it to build at all, spend a couple of hours with it and make guesses based on that, as well as on external info such as how much we knew about the developers that worked on it.)
So we switched to C++ instead. Considered Qt, argued about it, looked at LessTif, then GTK, then contributed a bit to gtkmm, then after a couple of years of nominally using gtkmm and getting nothing done, we switched to Qt after all and were happy. Happy-ish.
Even for people who really liked Objective C in 1997, it was pretty hard to make a case for. Maybe an open source company with staff and capital could have, but they barely existed.
[1] https://all-day-breakfast.com/cannam/x11-rosegarden/rosegard...
[2] http://www.hardcoreprocessing.com/home/anoq/Programming/GNUS...
How so?
You probably don't understand the context of mid-90s free and open software. Nothing is free, nothing open, relevant business models do not yet exist. Few things that are open barely work: linux takes hours to compile-tweak-recompile, all the tools are half-baked and semi-broken. You had to fix most things yourself.
Anyways, the only tools that do work reliably and have no license issues are coming from FSF: Emacs, gcc, unix utils, etc. Note that objC was not free, and the free version sucked most of the time. GCC did have world-class support for C though.
C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject.
It all makes total sense, and that's why the whole thing survives to this very day.
> “C was and still is a good choice for a core portable cross-language library. But UIs are probably the only programming context where OOP fits well. So people came with Gobject.”
That’s my exact criticism: they came up with GObject instead of using the C-based solution that already existed, had open source compiler support, and was actively developed by Apple.
The GTK community made a huge mistake in trying to turn GIMP’s poor design into a generic GUI framework rather than collaborating with GNUstep on creating a next-generation framework.
I've always wondered why GNUstep didn't work out; would've been a fantastic way of porting Mac OS apps, in theory at least. I guess that is what you're saying as well.
> In the late 1990s there already was Objective-C.
Objective-C is closer to the original, or at least early, Alan Kay and Smalltalk flavor of object oriented languages. In the late 1990s, we had already had 10 years of C++, so the C++ flavor "C with classes" type of object oriented programming was more familiar to most people.
I'd guess already then, the Smalltalk flavor of Objective-C felt a bit alien to many, who had grown familiar with the C++ flavor.
> GObject is a real tragedy of the NIH syndrome in open source.
It is, but I wouldn't look at Objective-C as the previous invention. X11 already hat the Toolkit Intrinsics (Xt), and it's not like they were unknown to the developers, the first version of Gimp having been written in Motif.
A new toolkit in the vein of Xaw/Motif/OLIT would've been a more immediate choice, but then again, no two persons seem to have the same preferences when it comes to object-orientation.
(I'm sitting in the proverbial glasshouse here, having switched my own "let's make some widgets for Qt 0.x" project to "let's reinvent X11 toolkits" in the mid to late 90s)
I've been writing C++ GUI apps with gtkmm for more than 22 years. I rarely notice GObject, other than in a few minor cases where the gtkmm wrapper didn't fully provide everything from the C level. In almost all those cases, the only reason I am still aware of them is because I use an ancient version of both gtk and gtkmm.
I would say that it is essentially completely painless to interact with GTK and Glib via gtkmm and glibmm.
> I've been writing C++ GUI apps with gtkmm for more than 22 years
How did you resist Qt?
When I started, Qt required a preprocessor (moc) for the build process. Gtkmm did not do, and use libsigc++. This seemed like a clear sign to me that it was technically superior.
22+ years later I would say that both Qt and Gtkmm have their own pros and cons. They have both run into pretty deep issues with integrating their own drawing model into the windows, macOS and X11 models. They both provide things that the other does not.
At this point, I don't see one as better than the other, and for a long established application like mine, the idea of switching is essentially unthinkable.
I did the same as PaulDavisThe1st; gtkmm is an excellent C++ interface for Gtk, such that I wonder why they even bothered to create Vala except for NIH syndrome. Qt had similar issues in the past: it wasn't pure C++, it was C++ "with extensions"; you had to use a custom compiler (moc), and you had to use Q-versions of everything the STL provides (QString, QVector, and so on).
Of course things were different more than a decade ago: C++11 did not exist yet or compiler support was lacking, and Gtk and Qt couldn't wait for it to catch up.
It's very pleasant to use in Python, though.
The object model is very close to C++ and Java, and I wonder if they could have made the memory layouts slightly different so that they were compatibile with C++, like in COM. But anyway gtkmm for C++ seems to work well.
That's a 2014 article by the way.
Did Elementary survive the fall out between its two cofounders? I haven't really followed.
Danielle has been posting substantial update blogs every month, so I'd at least tentatively say that the project seems to be moving forward.
It's a little bit sad, because I wish the game theory didn't work this way, and because I'm someone who tends to stay attached to the same project, but I almost wish smart people like her and anyone else working on ElementaryOS would move on to projects that have a better chance of gaining a foothold in the marketplace. At this point, I think EOS is probably NGMI
Honestly, I think this is the sort of project that where if you manage to get 0.5% of the market share you're still going to make enough money to get by. The market is massive. A partnership with the right orginsation to make this their operating system and it would be able to survive and allow the developers to carry on doing what they want to do.
Not a fan of bala itself, but I think this approach generates a filter for Elementary like apps, to have a strong commitment and standard practices that translate in an amazing UX and look and feel
ElementaryOS had an app store in which your code had to be open source and they still were going to take 30% of the revenue. As an indie app developer initially interested, that really turned me off.
Hey I just wanted to respond to this comment real quick. This platform fee covers the cost of payment processing and helps pay for the server infrastructure. AppCenter in itself is not a profitable venture at this time and it struggles to break even. Reducing this fee would guarantee that it runs at a loss, which might be feasible to consider in the future but for right now there’s not such a wide margin in the budget to run services that lose money
I actually don't have big problem with the 30%, especially for a small operation, but I do have a problem with both the 30% AND the ideologically-driven requirement that my software be open source. You just didn't provide a compelling alternative to other platforms. Your platform actually demands more of me, the developer, than Apple does, amazingly.
I don’t really want to wade into the Rust vs other languages thing, but I would be curious for Elementary’s take on why Vala over Rust (gtk-rs seems to see widespread use and all).
Anyone know if they’ve noted it somewhere? Is it just the investment in Vala and their custom widget library that set the direction?
Elementary is heavily dependent on the GTK ecosystem, which has its own OOP system implemented in C (for example like GObject). It is really hard to map GTK's OOP semantics to Rust. People have tried things like https://github.com/gtk-rs/gtk3-rs, but it requires heavy macro usage and doesn't feel like ergonomic Rust. On the other hand Vala is directly built upon the GObject system on the first place, so it's more fitting for GTK-specific development.
Yeah, this is a problem in a couple modern languages. For some time I tried to make a binding for Nim and encountered the same problem.
How do you make it so you can call "Widget" methods on a "Button"? Without proper subclassing, you have to either create a lot of duplicate functions, or the user has to explicitly cast up. Nim has implicit converters, so I tried defining conversions from all types to their base classes (Button -> Widget). But this made compilation time insanely slow.
Modern languages make this about "favor composition over inheritance" and say it helps you avoid monstrous Java-esqe class hierarchies. But it is really about subtyping and the Liskov substitution principle. You have a heterogeneous list of different "Widgets", how easily can you treat them as one kind, even if they need different behavior in detail?
Nim had experimental support for generics co-/contravariance. So you could say a "IF Button struct is a subclass of Widget struct THEN a GObjectPointer[Button] can be used in all cases where a GObjectPointer[Widget] can be used" (covariance). This was a unique feature and would solve the problem without implementation inheritance, but unfortunately it didn't work properly and I think it has been removed.
Nim actually does support inheritance though, so you could have just used that with methods. Though I can understand if you wanted to avoid inheritance.
Until barely a couple of years ago, nobody wrote GUI applications in Rust anyway.
GTK's OOP semantics have been mapped very successfully to, among other languages, C++, Python, Perl and Go. It's unfortunate perhaps that the Rust bindings do not feel idiomatic for Rust programmers, but that's hardly fatal or unexpected.
I think it's just that Rust doesn't have inheritance/subclassing as a feature. As a result you have to do all sorts of mental gymnastics with impls and macros to fit Rust interface on GTK, while with other languages subclassing just "works".
I also think this is why Rust has lagged heavily on the GUI development front. No matter how you claim component or ECS-based architectures are better and faster, sometimes the only thing you really need might be a good ol' inheritance-based scenegraph... You can definitely do UI with a component-based object model (ex. Unity game engine), but the whole process seems a bit more... convoluted.
Well, for a start, that blog post was written one year before Rust 1.0 was released.
A counterpoint: Vala hasn't done a 1.0 release yet.
But still, back at that time (2014) there was far less research done on how Rust library authors can ergonomic bind to C/C++ libraries that have their own object system. Nowadays people have figured out some techniques and we can actually use GTK and Qt from Rust, albeit in an awkward manner (lots and lots of macros).
Ha! You're totally right. I read this on mobile and I don't think the title had (2014) in it when I did, completely overlooked it.
I wonder whether this choice ended up leading to Elementary OS being the least stable Ubuntu-based I’ve ever attempted to use. I really wanted to make it work but neither Luna nor Jólnir were actually stable enough to daily drive, as much as I liked the looks of the DE.
>Elementary OS – Why we write elementary apps in Vala (2014)