First all, I’m not a Rust programmer, this is just a point of view of my first impressions about Rust, from documentation of it, and how I see it to use with GObject.
From documentation Rust provides a low level and high level API to access common operations. Provides a set of assumptions to help its great features like automatic memory management, secure and concurrent data access. On high level side, Rust provides a rich set of common collection, iterators, tuples and others.
For GObject interoperability, there is a project , and this too, I found to allow you to use GObject based libraries in Rust, while they depends on other project, or directly on GObject Introspection generated XML files to introspect these C libraries.
I don’t see a GObject equivalent, not jet at least, into Rust. From GNOME developers site, I found an introduction to GObject:
- A generic type system to register arbitrary single-inherited flat and deep derived types as well as interfaces for structured types. It takes care of creation, initialization and memory management of the assorted object and class structures, maintains parent/child relationships and deals with dynamic implementations of such types. That is, their type specific implementations are relocatable/unloadable during runtime.
- A collection of fundamental type implementations, such as integers, doubles, enums and structured types, to name a few.
- A sample fundamental type implementation to base object hierarchies upon – the GObject fundamental type.
- A signal system that allows very flexible user customization of virtual/overridable object methods and can serve as a powerful notification mechanism.
- An extensible parameter/value system, supporting all the provided fundamental types that can be used to generically handle object properties or otherwise parameterized types.
One of the most powerful features on GObject is C, but at the same time it its weakest one, because GObject through GObject Introspection makes easy to create bindings to any languages, including Rust. But is hard to write code for GObject classes and interfaces. GObject provides an Object Oriented programing paradigm to C.
I don’t think any one is thinking to rewrite GObject based libraries to Rust, because you can. Then lets put this option aside for a moment.
While Rust have great features, I would like to find a way to write a Rust library and share it through GObject Introspection GIR, making it available to other languages at day 0. Just remember GObject Introspection, is better suitable for GObject based libraries.
I don’t find in Rust a direct GInterface equivalent, no classes, no object properties and signals, no error reporting equivalent to GError. All of them are getting in, by bindings from GLib, GObject and GIO libraries, written in C, using GIR. I don’t think any one will re-write that libraries to Rust.
GObject bindings to Rust are not stable jet and may mature enough in a few years, depending on demand, resources and their use in new written code.
My personal conclusion
- GNOME will relay on GObject for next 5 to 10 years.
- GObject will be improved and maintained in same period.
- GObject Introspection will be a vehicle to easy access C libraries from other languages, including Rust.
- Rust will grow and hope they’ll add object oriented mechanisms equivalent to GObject/GInterface, in order to provide equivalent more secure and concurrent safe API to create new libraries.
- C language, will be here for next 20 years, but may gradually delegated to raw operations.
Adding object-oriented mechanisms to Rust would be a disaster. The OOP paradigm itself causes issues like rampant cache misses and code redundancy, requiring ever-increasing cache sizes to attain reasonable performance. Instead, what Rust is currently doing with a data-oriented design is much more efficient, and you can still accomplish everything that you’re doing with OOP, but with increased flexibility. You simply have to learn how to accomplish the tasks using a protocol/trait-oriented approach, which provides ad-hoc polymorphism. Signals, for example, can be achieved by having your method/function take another function as the input argument.
If you can write something in C, you can also write something in Rust. What you’re looking for specifically is not related to Rust but access to GNOME-specific APIs on Rust. This can be done either by utilizing an existing binding, improving upon existing bindings, or by simply importing the C libraries and using the functions and data structures that you want via the FFI. If you want to export your Rust library to other languages, then you can just export a C ABI for your public functions. Existing bindings may be lacking for Rust simply because there hasn’t been much want or need for them, as it’s largely exclusive to GNOME developers.
As for delegating C to raw operations, C is no more relevant for raw operations than Rust, which is capable of achieving the same low level raw operations that you can do with C, and to an extent even lower level than C as it integrates directly with LLVM primitives. You may check out the #[no_std] section of Rust, for example, which is lower level than C itself.