4 ms·

GTK is just a library, you can use it from any language it has bindings for.

diskzero 5y ago
Understood. I have made significant contributions to GTK. My contributions possibly had memory leaks or memory corruption issues that will bring down the higher Rust layer. I am trying to understand the purpose of the Rust layer. It is fine with me if it is because Rust is interesting, but what is being presented doesn’t seem like a Rust desktop environment _to me_.
- IshKebab 5y ago
  It's not 100% Rust but I think you would expect that GTK itself is fairly well tested - probably much better tested than any new app you write that uses it, so it is still worth it to write that app in Rust. And it has to be said that memory safety isn't Rust's only compelling feature. It also has a pretty great build system, a decent library ecosystem, a very strong type system which gives you an "if it compiles it works" experience surprisingly often, probably the best multithreading system, etc. etc.
- Taywee 5y ago
  The big selling point of Rust in respect to these kinds of scenarios is that it's very often that a C or C++ library says things like "You must not call function CallAfterFoo before function Foo is called", or "Once you call DestroyObject, that object must not be used again", or "You must not call SomethingDangerous while a ResourceOwningObject exists", and so on and so on. In well-tested libraries like GTK, SQLite, Curl, and such, they are often quite robust just based on having been heavily developed and tested by many people over a very long time, and there are still ways that they can be misused and abused that are usually well-documented and warned against. A well-developed Rust wrapper actually makes it impossible to misuse one of these libraries from Rust, and therefore better enables a much smaller team of developers to write secure, robust applications. Rust can guarantee these documented restrictions at the type level and even make impossible many error conditions. So even though the UI is GTK, Rust still enables developers to write more robust applications with less fear. Personally, I find that GTK with Rust is a very pleasant experience. It's less about guaranteeing that the lower libraries have no bugs and more about preventing people from interacting with the libraries in dangerous or buggy ways.
- ranfdev 5y ago
  I've made some small contributions to gtk-rs-core (the library providing rust bindings to glib, gdk...). While the lower layers written in C do impact the overall safety, the bindings are made to be as safe as possible. For example: every glib parameter that may take NULL in Rust becomes an Option<T>. GObject's methods are defined on traits and checked by the Rust type system. There are also some macros to provide an easy and safe interface to the GLib type system. All of this directly applies to gtk-rs. Overall, the bindings are well documented and with many examples. There's even a book. Also, there's a great community around them. Bindings website: https://gtk-rs.org/ https://gtk-rs.org/
- pxc 5y ago
  I agree! I think they're just using Rust because they'd rather use it than C, not because they need safety guarantees for the DE applications.
- deleted 5y ago
  [deleted]
jandrese 5y ago
The issue is that Rust is extremely opinionated at to how code should be structured and there is going to be considerable interface friction with a system that is built around aliasing data every time there is a callback.
- acdha 5y ago
  Do you have an example of that friction? Looking through the docs at e.g. https://gtk-rs.org/gtk4-rs/stable/latest/book/hello_world.html https://gtk-rs.org/gtk4-rs/stable/latest/book/hello_world.ht... it doesn't seem that bad but not having used it I would be curious how it works out once you're building a serious app.
  - jandrese 5y ago
    Things are already getting quite hairy by page 4[1] of that link. And that example is showing data completely owned by the GObject. If you need to pass a mutable reference to third party data to a GObject it's not going to work in Rust. Imagine a button that you click to change the contents a GtkTreeModel connected to a GtkTreeView--you're going to need to work hard. You're going to write a fair bit Rust specific glue code to work around these issues. [1] https://gtk-rs.org/gtk4-rs/stable/latest/book/gobject_memory_management.html https://gtk-rs.org/gtk4-rs/stable/latest/book/gobject_memory...
    - rollcat 5y ago
      Asking as someone who's never spent significant time/effort working with Gtk/GObject in C (only a bit in Python). Isn't it still generally desirable to have the compiler yell at you, if you can't convince it you know what you're doing? Rather than allowing the possibility of memory corruption. I do agree that the code in the example is far from beautiful. I wonder if we were to redesign GObject from scratch, if we could make interfacing with Python, Rust, JS, etc a bit less hairy.
      - Someone 5y ago
        The work you have to do to show your compiler that certain constraints hold (say that i and j point inside the same array and that i < j can be extremely cumbersome, even in cases where it’s obvious that they do hold. That makes it not seem worth the trouble. Of course, that obvious may turn out to be incorrect for some edge condition. Basically, that’s the same reason why mathematicians don’t put all proofs through a proof assistant.

Understood. I have made significant contributions to GTK. My contributions possibly had memory leaks or memory corruption issues that will bring down the higher Rust layer. I am trying to understand the purpose of the Rust layer. It is fine with me if it is because Rust is interesting, but what is being presented doesn’t seem like a Rust desktop environment _to me_.

IshKebab 5y ago
It's not 100% Rust but I think you would expect that GTK itself is fairly well tested - probably much better tested than any new app you write that uses it, so it is still worth it to write that app in Rust. And it has to be said that memory safety isn't Rust's only compelling feature. It also has a pretty great build system, a decent library ecosystem, a very strong type system which gives you an "if it compiles it works" experience surprisingly often, probably the best multithreading system, etc. etc.
Taywee 5y ago
The big selling point of Rust in respect to these kinds of scenarios is that it's very often that a C or C++ library says things like "You must not call function CallAfterFoo before function Foo is called", or "Once you call DestroyObject, that object must not be used again", or "You must not call SomethingDangerous while a ResourceOwningObject exists", and so on and so on. In well-tested libraries like GTK, SQLite, Curl, and such, they are often quite robust just based on having been heavily developed and tested by many people over a very long time, and there are still ways that they can be misused and abused that are usually well-documented and warned against. A well-developed Rust wrapper actually makes it impossible to misuse one of these libraries from Rust, and therefore better enables a much smaller team of developers to write secure, robust applications. Rust can guarantee these documented restrictions at the type level and even make impossible many error conditions. So even though the UI is GTK, Rust still enables developers to write more robust applications with less fear. Personally, I find that GTK with Rust is a very pleasant experience. It's less about guaranteeing that the lower libraries have no bugs and more about preventing people from interacting with the libraries in dangerous or buggy ways.
ranfdev 5y ago
I've made some small contributions to gtk-rs-core (the library providing rust bindings to glib, gdk...). While the lower layers written in C do impact the overall safety, the bindings are made to be as safe as possible. For example: every glib parameter that may take NULL in Rust becomes an Option<T>. GObject's methods are defined on traits and checked by the Rust type system. There are also some macros to provide an easy and safe interface to the GLib type system. All of this directly applies to gtk-rs. Overall, the bindings are well documented and with many examples. There's even a book. Also, there's a great community around them. Bindings website: https://gtk-rs.org/ https://gtk-rs.org/
pxc 5y ago
I agree! I think they're just using Rust because they'd rather use it than C, not because they need safety guarantees for the DE applications.
deleted 5y ago
[deleted]

jandrese 5y ago

The issue is that Rust is extremely opinionated at to how code should be structured and there is going to be considerable interface friction with a system that is built around aliasing data every time there is a callback.

acdha 5y ago
Do you have an example of that friction? Looking through the docs at e.g. https://gtk-rs.org/gtk4-rs/stable/latest/book/hello_world.html https://gtk-rs.org/gtk4-rs/stable/latest/book/hello_world.ht... it doesn't seem that bad but not having used it I would be curious how it works out once you're building a serious app.
- jandrese 5y ago
  Things are already getting quite hairy by page 4[1] of that link. And that example is showing data completely owned by the GObject. If you need to pass a mutable reference to third party data to a GObject it's not going to work in Rust. Imagine a button that you click to change the contents a GtkTreeModel connected to a GtkTreeView--you're going to need to work hard. You're going to write a fair bit Rust specific glue code to work around these issues. [1] https://gtk-rs.org/gtk4-rs/stable/latest/book/gobject_memory_management.html https://gtk-rs.org/gtk4-rs/stable/latest/book/gobject_memory...
  - rollcat 5y ago
    Asking as someone who's never spent significant time/effort working with Gtk/GObject in C (only a bit in Python). Isn't it still generally desirable to have the compiler yell at you, if you can't convince it you know what you're doing? Rather than allowing the possibility of memory corruption. I do agree that the code in the example is far from beautiful. I wonder if we were to redesign GObject from scratch, if we could make interfacing with Python, Rust, JS, etc a bit less hairy.
    - Someone 5y ago
      The work you have to do to show your compiler that certain constraints hold (say that i and j point inside the same array and that i < j can be extremely cumbersome, even in cases where it’s obvious that they do hold. That makes it not seem worth the trouble. Of course, that obvious may turn out to be incorrect for some edge condition. Basically, that’s the same reason why mathematicians don’t put all proofs through a proof assistant.