Announcement

Collapse
No announcement yet.

AMD Is Hiring To Work On New Radeon Driver Tooling Written In Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by jacob View Post

    I never tried to use it (yet) but AFAIK it's actually based on gtk-rs, so it seems it's a complement rather than an alternative. The thing that makes gtk-rs great is that now it allows you to create new widgets natively in Rust. It's a little bit more verbose and less intuitive than in Vala though.
    Right, it is not a different wrapper of gtk+, just a way to use gtk-rs it in a nicer way. Without having to deal with interior mutability.

    Comment


    • #32
      Originally posted by andrei_me View Post
      By using Rust, will they use GTK? As the most recent gnome apps were written in Rust 🤔🧐
      I doubt we are talking about new software engineers for GUIs. This will be user space libraries (possibly somewhere in the ROCm stack).

      Comment


      • #33
        Originally posted by oleid View Post

        Right, it is not a different wrapper of gtk+, just a way to use gtk-rs it in a nicer way. Without having to deal with interior mutability.
        Yeah that's definitely an improvement in code ergonomics.

        Comment


        • #34
          Originally posted by Alliancemd View Post
          There is a reason why it is the most loved programming language, 5 years in a row.
          According to a Q & A forum that avoids answering a large portion of the questions ("don't do it is, it is bad" is not an answer) and serves mainly as a google-able pastebin...
          Last edited by marios; 25 September 2020, 06:11 AM. Reason: Fixed syntax errors

          Comment


          • #35
            I think the real question here is: what exactly constitutes "driver tooling"?

            Comment


            • #36
              Originally posted by phoronix View Post
              Phoronix: AMD Is Hiring To Work On New Radeon Driver Tooling Written In Rust

              It turns out AMD is at least exploring the possibilities around using the Rust programming language in their graphics driver tooling...

              http://www.phoronix.com/scan.php?pag...ng-Radeon-Rust
              This is a real issue but I really hope that new blood can shake things up with respect to AMD's driver development. AMD has been doing a lot of hiring of late which can lead to its own problems but it is obvious that they need larger teams.

              Comment


              • #37
                Originally posted by cl333r View Post
                Probably a bad idea to use Rust.
                The reason we don't see full blown apps in Rust taking over the Linux desktop is because it's far less productive because the issues it fixes come at a heavy cost and the bindings and style you have to use is alien to the human brain because writing otherwise is not allowed because of the borrow checker - I did a quick look at the Qt bindings - they're disgusting to me as a human.

                I only see these cases as suitable for Rust:
                - some complicated multi-threaded task
                - some toy app, like fd [1] which is awesome
                - a part of code in an app like telegram, tor or whatnot that are obsessed with security.

                [1] https://github.com/sharkdp/fd

                Plenty of full-blown applications and very complex architectures are written in Rust. I've written several GTK applications and system services in Rust. At System76, we have two GTK applications written in Rust at stations processing everything from receiving to assembly. Desktop applications honestly aren't that difficult to right.

                Comment


                • #38
                  Originally posted by uid313 View Post
                  I am a dumb guy who tried out Rust, it is pretty hard to code with, but its a bit cool. It uses traits and structs instead of interfaces and classes, but its kinda similar. It doesn't support async methods in traits though. Nor does it support string interpolation. I am not sure if Option<Value> provides any benefit over nullable values, because then you have to extract it and check if it has a value or is None, so then you might as well check if its not null.
                  Sadly, all of these statements are not true.

                  - Async methods are supported
                  - String interpolation is supported, though I personally prefer fomat
                  - Not sure if you're actually serious about Option vs null.
                  Last edited by mmstick; 25 September 2020, 12:38 PM.

                  Comment


                  • #39
                    Originally posted by jacob View Post

                    I never tried to use it (yet) but AFAIK it's actually based on gtk-rs, so it seems it's a complement rather than an alternative. The thing that makes gtk-rs great is that now it allows you to create new widgets natively in Rust. It's a little bit more verbose and less intuitive than in Vala though.
                    Slightly less intuitive for building GTK widgets (although this is arguable once you throw cascade and derive_more into the mix), but significantly more intuitive when programming actual logic for those widgets. Vala's async story is also a disaster, since it's a near 1:1 map to GLib's async API, but with confusing syntax which isn't very intuitive at all. I personally have a much more difficult time working on Vala GTK projects than Rust GTK ones.

                    Comment


                    • #40
                      Originally posted by oleid View Post
                      Relm is supposed to be a nicer wrapper for gtk+. It uses message passing to deliver events and thus can easily be used in highly multithreaded code.
                      Actually, all operations on GTK have to happen on the main loop on the main thread. Relm just provides a very opinionated way of handling GTK. But you can just as easily write your own event-driven way of handling GTK with an event loop. I personally just use gtk-rs with an async channel + glib async loop so as to not have a middleman decide my architecture for me

                      Code:
                      let (tx, rx) = flume::unbounded();
                      
                      let mut app = App::new(tx);
                      
                      glib::MainContext::default().spawn_local(async move {
                          while let Some(event) = rx.recv_async().await {
                              match event {
                                  Event::DoThis(value) => app.do_this(valuie),
                              }
                          }
                      });
                      
                      gtk::main();

                      Comment

                      Working...
                      X