in GNOME, GTK+ 579 Words

Thoughts on DX: GNOME and Rust

A few months ago I spent some time to learn some basic Rust, I was interested in getting an informed view of the language, specifically about the safety and concurrency idioms as well as its compatibility with the C ABI and automatic memory management while being non GCed. I must say I was pleasantly surprised with the tooling, cargo is a breeze and crates.io is a wonderful resource. More recently though I’ve been investing time to actually understand the memory ownership model and how it plays with channels/concurrency. I must say that what these guys have achieved is really clever with a language that once you get the grasp of things feels actually really nice to use.

2000px-rust_programming_language_black_logo-svg

For a long while now I’ve been worried that the GNOME project would struggle to grow its contribution and stay attractive if it stuck to C in the long run (i.e. next 10-20 years). GObject hasn’t really caught on beyond the GNOME ecosystem. So we’re basically maintaining a whole low level framework, and we have to come up with something by ourselves everytime a new technology comes in (i.e. JSON, REST…). Given our limited resources, I’ve been wondering if there are better alternatives.

For people wanting to contribute to the core libraries consumed by the ecosystem, the only options are C and Vala. Vala has been a great tool for prototyping, I love it myself, but debugging it is a nightmare, it’s filled with security issues and even if we fixed those really difficult problems, we’d be maintaining our own language on top of everything else. I would like to see us maintaining less stuff other than a desktop and the application development framework, not more.

I trully believe Rust gives us a way out of this situation, with certain nice side benefits, Rust really ticks most boxes: C ABI compatibility, safety, modern syntax, vibrant community, ever growing set of libraries and tools and a culturally aligned organization backing it: Mozilla. So when Federico made the brave step of start using it in one of our libraries I was very encouraged by the notion that this might actually happen. I’ve been pleasantly surprised to see positive reactions to his effort by many core developers on twitter.

Now, imagine for a moment, that we decide to somewhat embrace Rust in our libraries, and we start adopting it in places like GTK+. Suddenly we have the opportunity to engage in the growing enthusiasm around Rust, and we have a channel to technologies and tools being built outside of our own community such as WebRenderer, Servo…

Additionally, we release ourselves from the burden of maintaining core libraries for everything so we can focus on producing a great desktop and application development story.

Ultimately though, there are many challenges, achieving full GObject compatibility can be difficult, we would need to be able to consume GI bindings from Rust and eventually emit GI bindings too, and in the end it would be up to the core of the community to lead an effort like this so there needs to be consensus too. It is quite a bit of work, but I believe it is worth considering as it might give us back a lot resources to focus on other stuff.

Please don’t read this as a formal proposal, I think something like that should come, I’m mostly putting my thoughts on this out there and see what the rest of the community thinks.

45 thoughts on “Thoughts on DX: GNOME and Rust”

  1. I guess the key question would be, “what would this mean for the many languages with gtk APIs that aren’t Rust, like Python, Ruby, Guile, Javascript….”? What would it mean for existing C applications?

    Liked by 1 person

    Reply

      2. Michael, we certainly need contributors to improve the situation.

        For a seamless Rust experience, Rust needs access to the existing APIs. We need help wrapping the GObject API and generating bindings from GObject Introspection. These efforts have been started already in this github project https://github.com/gi-rust. But are stalled as of now.

        Lemme know if you have other ideas, I’m aruiz in irc.gnome.org

        Liked by 1 person

  2. This would be a step in the right direction. How would you see that type of movement taking shape? A parallel effort like what has happened with firefox and servo? I have seen opinions from many developers stating that rust is great for replacing high risk portions of code but not necessarily worth the effort when it comes to completely migrating an entire codebase over. I feel that misses the other benefits that migrating over to rust brings tbh, some of which you have echoed here.

    GNOME had something similar to an rfc process before, if one of the goals is to reach out to wider rust community and reuse components developed elsewhere then trying to employ something similar again might be a good idea.

    Liked by 1 person

    Reply

    1. I can’t see a parallel effort being the way to go for GNOME, but for a gradual change piece by piece. Take a C function, rewrite it in Rust, write test units for that function, and then link it back into the C codebase. You would then start gaining some of the benefits of Rust on day one, and you can start with regions that are the most bug and error-prone first, gradually shifting towards Rust idioms over time.

      Like

      Reply

  3. So far my contributions to GNOME+ecosystem have been tiny but I think would be a great move to utilize rust. Vala is absolutely not appealing to me because it’s a complete niche (which means there will be a lot of disadvantages when it comes to tooling, libraries, …). I prefer Python but came to like Rust. One thing I really like about GTK is that I never had a problem using it from Python (while a Python+QT app is really simple to crash if I do a tiny mistake in Python).

    So as long as gobject introspection stays I would welcome a move to rust. C+rust+Python+JavaScript/CSS seem to be a really inclusive ecosystem.

    Liked by 1 person

    Reply

  4. GNOME is a C platform. Use Rust may is convenient, for high level development.

    Low level may stay at C. I don’t know how good Rust could replace C interfaces to OS and other things.

    I don’t have data, but I don’t think GNOME technologies are used just at home.

    I think diversity is a feature not a limitation, GObject Introspection is a key technology as a bridge to your preferred language.

    I don’t think we need to focus just on Desktop applications. GNOME strange is not on apps, but on its technologies. Yes, we can improve that, but I don’t think that just using Rust will make all, outside GNOME, will use our apps.

    We need a good multiplatform toolkit, to create beauty and usable UI easily, in any language not just Rust. Language is a choose to find your way to create your next killer app and good enough to increase your productivity.

    I found Vala really productive; using it to create libraries and making usable to any other language, using GObject Introspection, a great feature.

    Hope Rust is not C# threat. We can’t go away from our strange: C; just because Rust sounds great and in a big momentum.

    C have been here for many years and will be in the future. This is way I think we need Vala fixed to increase productivity and good object oriented programming a candy while we produce C code.

    GXml, DOM4 and SVG show me the great potential of Vala, by reducing development time and in line with W3C specifications, producing a set of interfaces to get a clean API, using Vala this was really easy to implement.

    Liked by 2 people

    Reply

    1. > Low level may stay at C. I don’t know how good Rust could replace C interfaces to OS and other things.

      rust is designed for being able to replace C at every level. Operating system kernels have been written in rust as well as Linux kernel modules. (However it doesn’t make sense to replace all C code with rust “just because you can” and of course for low-level development you need a lot of “unsafe” blocks.)

      > I think diversity is a feature not a limitation, GObject Introspection is a key technology as a bridge to your preferred language.

      While I agree that gobject introspection is great (and should stay) I think the gnome project should focus on a few core languages which are used for the platform and core apps. If the project uses too many languages this might lead to bottlenecks as core developers might not be able to fix some parts if they are not proficient in yet another language. The cost of integrating all the different languages (+ build systems, coding styles, …) should not be underestimated.

      > Yes, we can improve that, but I don’t think that just using Rust will make all, outside GNOME, will use our apps.

      True. Also I think this is not so much about using rust for graphical applications (though this is certainly possible) but more about replacing some C parts of basic libraries with rust parts.

      > This is way I think we need Vala fixed to increase productivity and good object oriented programming a candy while we produce C code.

      I’m skeptical if there is enough man power/motivation in the gnome project to really fix Vala. This seems to be a huge undertaking as there are very few (any?) Vala core contributors not affiliated with gnome. rust on the other hand can produce code with is easily called from any runtime/language which can call C libraries and its development/maintenance is already driven by people mostly unrelated to gnome (so this could mean gnome developers would be able to spend their time on parts which are more closely connected to the actual gnome platform instead of just creating basic tools).

      Liked by 2 people

      Reply

      1. > I’m skeptical if there is enough man power/motivation in the gnome project to really fix Vala.

        Exactly my point. I’ve been a Vala enthusiast for about 9 years, I still use it, and we still have the same tooling problems we had back then: debugging is a nightmare, it’s hard to ensure compatibility between versions of the compiler…

        These have not been fixed for years and I don’t expect that the manpower to fix the problem will appear out of the blue, and even if it did, we would still be left with a piece of technology that is niche and we have to maintain on our own.

        I love Vala, but it’s time to accept it is no alternative to those parts where now we can only use C.

        Like

    2. Daniel,

      Rust is not a high level language. It’s as low level as C is. I would recommend you actually try it before raising concerns. I know you’re a big Vala fan, I am too, but it’s just not good enough for the low level aspects of the platform.

      I’m not proposing this out of the hype behind Rust, turns out that Rust solves a bunch of problems that are really hard to solve.

      I’m not sure I follow all the points you’re making, whether GNOME technologies are useful inside or outside the desktop area does not get affected by using or not using Rust. Rust is used in both server side technologies as well as cross-platform desktop applications like Firefox.

      Our strenght is not C, our strength is a dependable ABI, the C ABI is universal and Rust actually allows us to keep that.

      I think you need to learn Rust before showing so many worries, you might be missing some of my points.

      Liked by 1 person

      Reply

      1. I’m sure I need to test Rust and learn too, in order to find if there is a way for me, I really like to know if Vala goes or not, because I have one or two big projects in course using XML Serialization to/back GObject and because is GObject is easily Introspectable and because is Vala I was able to produce XML wrappers in short time.

        I’ve pushed some patchs to Builder in order to fix some templates, but seems no interest because no buddy have answered my questions. Then is just leave Vala to die, because a switch to Rust?

        Now, GObject Introspection is better tie to GObject Introspection, making easy to provide other language bindings, this is the reason I’ve added support for it in libgda and libsoup; and is the reason I prefer to produce C/Vala projects based in GObject.

        I think GObject and, or at least, GObject Introspection should be supported by Rust out of the box, while we keep produce great better libraries for GNOME. This way may we switch to Rust.

        Some may know about my work on Vala. I see a great opportunity to create C/GObject based libraries to provide clean and easy Introspectable API using GObject Introspection, just call to other to make clear if we will get same interoperability with GObject and GI, while opens opportunity to reuse in other languages, like Python, I love it, to get web development and Desktop apps using same code base.

        Like

      2. Alberto

        >I’m not sure I follow all the points you’re making, whether GNOME technologies are useful inside or outside the desktop area does not get affected by using or not using Rust.

        C is, I think, one one the reason we have tackle better solutions and able to get great technologies; a reason that no C++ is on core libraries and GObject a way to provide an Introspectable and clean API to other language, while provide a solid basis.

        >Rust is used in both server side technologies as well as cross-platform desktop applications like Firefox.

        I’m sure about this and I’ll take a try to Rust, just tell GNOME if we go to Vala or just they will leave it die with no maintenance.

        Liked by 1 person

      3. Hi esodan (seems like I can not reply to your comment directly),

        > Then is just leave Vala to die, because a switch to Rust?

        I’m just a complete by-stander so probably my opinion is really not worth much and I don’t want to discourage anyone just because my opinion but I think Vala will go to “sleep” even if gnome won’t adopt rust.

        Basically I support Alberto’s point (without having his experience with Vala):
        > I’ve been a Vala enthusiast for about 9 years, I still use it, and we still have the same tooling
        > problems we had back then: debugging is a nightmare, it’s hard to ensure compatibility between
        > versions of the compiler…

        I feel that “gnome” developer resources are already spread *really* thin (positive spin: all devs are pushing their boundaries maintaining as much code as they possibly can). Vala helps “gnome” if it enhances developer productivity AND helps getting new developers on board (or at least does not put people off).

        As tooling (+ knowledge on StackOverflow and the like) etc. is a big issue I suspect the value of Valas “syntactic sugar”/”gobject integration” diminishes compared to creating some helper functions/macros in more widely used languages (but having better tooling, analyzers, compilers, IDE, debuggers, …). So IMHO Vala is a minus when it comes to new contributors which is very bad for any open source project.

        rust is IMHO more a contender to replace basic building blocks where security or parallelization are important. Also accepting rust as one of the “official” gnome languages could help if the rust community builds some code which would be otherwise written by GNOME.

        For GUI apps I still prefer Python. 🙂

        Like

      4. > C is, I think, one one the reason we have tackle better solutions and able to get great technologies; a reason that no C++ is on core libraries and GObject a way to provide an Introspectable and clean API to other language, while provide a solid basis.

        Daniel, I think you’re missing an important bit of information here. Rust is capable of emitting a C ABI, and there is no reason why we can’t build GObject (and therefore GObject Introspection) compatible code from Rust. Of course that’d need work to make it happen.

        Liked by 1 person

  6. C has served us well, but it has some major design flaws which need to be addressed today. One flaw is the lack of memory safety resulting in at least one CVEs per day in widely used software. Nobody stepped up to fix C, probably because it is too hard to fix, so we need an alternative. I’ve looked into Rust for some time and it feels pretty good, solving the most common language design flaws (memory safety in C, e.g. Exceptions performance and Nullpointer access from Java/Python) and still is a compiled language resulting in fast execution. I’d like seeing GNOME/Gtk+/Glib move to Rust.

    As nice as the syntax of Vala is, Vala has failed us. This is probably due to the lack of adoption, but also due to not fixing C good enough. It seems like Rust has already a larger community than Vala ever had, so I surely prefer Rust over Vala for this reason too.

    Right now there is only one major showstopper in Rust: Rust has C ABI compatibility, but only limited Rust ABI compatibility, meaning: You cannot use Rust ABIs from two different Rust compiler versions. E.g. if you compiled library liba with Rust 1.11.0, your application built with Rust 1.12.0 cannot use this library. See https://github.com/rust-lang/rfcs/issues/600 for details. Until then, we have to statically link all Rust libraries into our applications which isn’t nice.

    By the way: There are Rust bindings for core GNOME libraries online at http://gtk-rs.org/

    Like

    Reply

  7. The question is whether you could actually really abandon Vala in favour of e. g. Rust.

    That requires a momentum. How many Gnome developers would want to do so and how many would be too lazy?

    Like

    Reply

  8. I think outdated/uninteresting technology is one of the main reason why the Gnome project (and GNU projects in general) have less contributors that it should have. (Another one is the not so open development process, but that is another topic)
    The entire C/Autotools/Make/Documentation stack does’t stand up anymore in terms of productivity and safety (and, in the long run, maybe performance) with modern technologies like Rust.
    So, making Rust the Gnome official language of the future would be a blessing.

    Like

    Reply

  9. I think deprecating Vala in favour of some other language makes perfect sense. As others have pointed out, since it’s only really used for GObject applications it doesn’t attract the resources needed for it to become a first rate language with all of the tooling and features expected.

    I certainly think looking at Rust as an alternative to C for the low level code is definitely worthwhile and one I would support.

    However, as a replacement for Vala in terms of building GTK applications I actually prefer D over Rust. D adopts a syntax that will feel very familiar to developers coming from C based languages including Java. Since D uses a GC it is easy for developers to pickup without having to learn Rust’s unusual ownership semantics and the borrow checker. However, unlike Java and Python D is fully compiled and has reasonable memory usage. You can also opt out of the GC for the rare cases where it makes sense to do so.

    The typical knock against D is that it uses a GC but it’s never been a problem for me. I’ve had Terminix out for almost a year now and none of my users has ever noticed an issue with it as far as I know. I suspect a lot of the hate is the perception around early versions of Java and the way it’s GC and memory model worked.

    At this point in time D also has more complete GTK/GIO/GLib bindings then Rust via GtkD (http://GtkD.org).

    Like

    Reply

      2. Oh yeah, Rust would be no contender for things like Javascript, Python, Ruby… (or hopefully .NET if we resurrect the bindings), probably even Vala. My main excitement for Rust is that it could make maintaining the core libraries easier, make them more robust, and allow us to share a technology base with Mozilla more easily.

        Liked by 1 person

    2. The actual heavy lifting in your application is not being done by D but by the C libraries you’re importing, which is not using garbage collection. The less garbage collection that is happening, the better. Not having to feature a garbage collector in the background simplifies things, and reduces memory consumption.

      If there’s plans to start using a new language in GNOME today, I can’t see anything being better than a decision to use Rust. Syntax shouldn’t be a problem because that’s just something you learn in the first week, and we’re not talking about Haskell here, Rust syntax is quite simple to work with once you master it. It takes a little bit more time than D to implement a solution, but we can guarantee the solution to be higher quality. D doesn’t guarantee the same level of safety as Rust, or the same level of tooling/community. It’s hard to compete against Cargo, Crates.io, and how simple it is to install and manage Rust toolchains, even cross-platform toolchains.

      Like

      Reply

      1. The pun to Haskell is absolutely groundless, Haskell has the most terse and clear syntax of languages I know.

        It’s definitely hard to learn, but it has nothing to do with the syntax.

        Like

  10. Could swift also be a fit. I’m not saying that rust is a bad idea, quite the contrary.

    But it has it’s advantages, it is easier to read, higher level, it is designed specifically to build UI and there is already a lot of developers using it. Plus it would a give an incentive for developer as their gain knowledge that will enable them build application on different platforms.

    Like

    Reply

    1. I would say no because much of Swift’s libraries, even the standard library, are dependent upon Apple-specific technologies and flat out will not work on other platforms, limiting you to a small subset of Swift. It was designed from the beginning to be Apple-oriented so it does not have the groundwork in place to support all platforms, as does Rust. There’s may other issues with Swift outside of that, but I’ve always seen Swift as just Apple’s poor man attempt at copying an older version of Rust.

      Like

      Reply
  11. Pingback: Meeting Ubu-it 2016 | Jeremie

  12. I was just thinking about learning vala in order to help developing some gnome project and make my contribution. There are a number of vala project around like Geary and LaTeXila. Here you are sustaining that vala has many bugs and there is not a clear plan about his future.
    Should I pick a C project to help?

    Like

    Reply

  14. If anyone is interested I can create a proposal for the use of Kotlin as an alternative to Vala for developing GTK apps (at a high level). Take this example (what a app might look like) of a basic GTK app written in Kotlin:

    “`kotlin
    import gtk.*

    fun main() {
    val app = application(id = “gtk-app”)
    app?.window {
    title = “Kotlin”
    setDefaultSize(200, 200)
    buttonBox {
    button(“Hello World!”) { clicked += ::onButtonClicked }
    }
    }
    // …
    }

    fun onButtonClicked(parent: Container, widget: Widget, event: MouseEvent) {
    println(“Hello Kotlin!”)
    if (parent is Window) parent.destroy()
    }
    “`

    Anyone looking at the example would likely find it is easier to understand than doing the equivalent in Vala, contains less noise, and is more readable/easier to maintain. Also by doing UIs via a DSL there isn’t any need to use XML anymore which greatly reduces context switching, easier to maintain (takes loose coupling to a greater level), and can utilise pre-existing software development concepts without throwing away “the baby with the bath water” unlike XML (and other template languages).

    The example is based on the one found in this article covering using GTK with Kotlin Native:
    https://victor.kropp.name/blog/kotlin-native-0.2-and-gtk/

    Links:

    – Prototype Kotlin GTK bindings: https://github.com/kropp/kotlin-native-gtk
    – Kotlin Native GTK sample: https://github.com/JetBrains/kotlin-native/tree/master/samples/gtk
    – Kotlin Native deep dive video: https://www.youtube.com/watch?v=3Lqiupxo4CE
    – Kotlin Native overview video (Euro LLVM presentation): https://www.youtube.com/watch?v=DqsYo_4QWSg
    – Kotlin Native ACCU video: https://www.youtube.com/watch?v=3K3oQ22nqfo

    Like

    Reply

    1. I just had a look at the repo and it looks like you are creating the OO wrappers for the bindings manually. It would take ages to have the same API coverage as Vala or PyGObject. My suggestion is that you find a way to use GObject introspection to generate the bindings.

      I would love to have complete Kotlin bindings but without more coverage it can’t really compete.

      Like

      Reply

  15. Is this still an idea today ?

    Because Rust is proving every day better and better at being the kinda successor of C++, and a remake version of Gnome in ONE language that is safe, multipurpose and very fast would be such a good new and fresh start !

    Like

    Reply

    1. Rewriting GNOME would be an utter waste of time and disruption towards users and contributors. I think the interesting thing is to be able to contribute new code in Rust. We are seeing that with new applications like Fractal and GNOME Podcasts.

      Like

      Reply

      1. Do you think it would be possible to start adding Rust code to vala-based apps? Is there an infrastructure for that?

        I’m asking because I’m contributing to Geary which is Vala based, but honestly Vala sucks. For various reasons, the most important one is probably that all it offers with regard to immutability is limited to compile-time constants (and it doesn’t even offer const, so no, you can’t even call a function that can be computed at compile-time). I think, developments in various languages for past decades shown how immutability matters, and Rust is way ahead of most other languages in that regard.

        Like

    1. Well, there is _some_ infrastructure to do something like that, like the gnome-class! macro:
      https://gitlab.gnome.org/federico/gnome-class

      This allows you to emit GObject code that you can consume from vala if you emit the .vapi files.

      However the build tools to achieve this could be quite cumbersome to put together and I am not sure it is worth it.

      In general, it is a bad idea to rewrite an application that already works into another language just because of language features. Those apps have users and the rewrite is going to stall development and bugfixing and create new bugs in the process.

      Rustifying a pure C API is easy, Rustifying a complex GObject project is quite a lot of work.

      Like

      Reply

      1. > In general, it is a bad idea to rewrite an application that already works into another language just because of language features. Those apps have users and the rewrite is going to stall development and bugfixing and create new bugs in the process.

        Totally agree. I was just thinking about, maybe, writing new code in Rust. But I don’t know how feasible is that, that’s why the question about infrastructure.

        > Rustifying a pure C API is easy, Rustifying a complex GObject project is quite a lot of work.

        I see, so there’s no infrastructure for that. Thanks.

        P.S: I think this comment is gonna appear on the top level, sorry about that, it’s the same as what happend with my “constexpr” comment. Apparently it’s some wordpress bug: I am logged in through FB, but when I try to post, it says “Post error: fill required fields”. Logging out/in, and trying to reply leads to the same. So far only works: log out/log in, and immediately reply with the stored reply. But stored reply for some reason appears then on top level, even though it shouldn’t (this is probably a separate bug).

        Like

  17. Quoted from another post (that I can’t reply directly to):

    “My main excitement for Rust is that it could make maintaining the core libraries easier, make them more robust, and allow us to share a technology base with Mozilla more easily.”

    I’ve always though this seems like Rust’s ideal niche too, but it’s very hard to take seriously when they still don’t have a defined ABI and nothing to that effect even on the roadmap. How anyone can take a language without ABI stability seriously, when the use case is primarily implementing libraries? What’s the plan when these libraries are packaged for distros and then later need security updates? Do we just rebuild 2,000 dependant packages unnecessarily; wasting not only build server resources but also then repeated and magnified over X number of user’s package updates?

    Are people hoping this issue just magically solves itself by the time it becomes a *major* problem for distro packaging? Because it’s certainly showing no signs of improving and some of the core developers seem to have all but ruled it out *ever* happening.

    Like

    Reply

    1. I agree with your concerns, and it’s something I think sooner or later the Rust community will have to face or it will greatly diminish the role of Rust in the Linux distro ecosystem. OTOH C++ is about to break ABI, Go follows the same route, so I think mass rebuilds in Linux distros are going to become a thing, and perhaps these days is less of a deal than it used to be and we should just plan for it as part of the maintainer’s duties. That being said, I agree that this is less than ideal.

      Like

      Reply

Leave a comment