4 ms·

If I can have a XAML/WinForms like UI dev experience with Rust on Linux, I am sold. Even just a usable rich UI framework on Linux. Cross-platform is a bonus, bu

If I can have a XAML/WinForms like UI dev experience with Rust on Linux, I am sold. Even just a usable rich UI framework on Linux. Cross-platform is a bonus, but since I believe Linux is the future I can live without other platform targets. We all hate the resource hogging desktop apps that are just browsers (which in turn are just OS'es). That is a niche as wide and as open as the ocean. Cryptography and web frameworks are nice, but not where the action needs to be. If UI is too complex for Rust, give up altogether on Rust. As C/C++ keeps the win since the nineties and we know the competition will not be held anymore.

int_19h 4y ago
UI is a poor fit for Rust, IMO, because the natural way to model UI widget hierarchies is rather painful with ownership tracking in the picture. But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.
- exceptione 4y ago
  Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser. There is a gap between the nineties and now, and it is still void. If you have to constrain it to CLI apps the average developer here on HN needs to write, I don´t see a reason to use such a complex beast as Rust. If you mean operating systems, I can see a spot for Rust. Also database systems or a web server implementation. But that is fairly niche. For userland cli-apps I am not sure if the added complexity pays of in terms of sufficient performance gains in practice. If you want to write a new implementation of grep, sure. But how niche is that? So in those cases where you need both type strictness (which I agree should be the default requirement) and cannot have an automatic garbage collector, I can see the value of Rust. But for what audience is an automatic GC really a problem? Personally I would use Haskell, Java, F# for CLI-apps, but I know there are tons of other options there.
  - xxs 4y ago
    grep inner loops are coded straight in Assembly. So Rust would be a poor fit.
    - steveklabnik 4y ago
      Yet ripgrep is extremely fast, often faster than grep. Practice beats theory. (Rust can also do in-line assembly…)
    - burntsushi 4y ago
      Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?
      - metaltyphoon 4y ago
        If I would have to guess it would be codecs.
        burntsushi 4y ago
        What do codecs have to do with grep?
        int_19h 4y ago
        grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.
        burntsushi 4y ago
        Those are locales. I've never heard them referred to as "codecs." In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)
pjmlp 4y ago
You cannot even get it with Rust/WinRT straight out of Redmond, let alone having hopes to get it on Linux. C++/WinRT tooling is a shadow of C++/CX capabilities (which feels like Microsoft's C++ Builder), and while the same folks are having fun with Rust/WinRT, its tooling is even worse. I doubt that in five years it will be any close to what C++/CX was already doing in 2015. Specially since they outsource any graphic tooling responsabilities to the DevDiv folks.
- exceptione 4y ago
  That's sad. I would love to tinker with UI programming on Linux, but it seems like to get anything decent you will have to use QT, which brings C++ as a requirement.
  - pjmlp 4y ago
    You can have a look at its issues, https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML. Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.
    - exceptione 4y ago
      Thanks. I did not mean XAML literally though, something like that would be super nice for Linux. The project you linked brings Windows RT as a requirement. But just something with the richness of QT + Rust on Linux would be welcome. I am hearing the rust bindings for QT are just a pain and incomplete. I was hoping for Rust to really offer an alternative for C++ here.
      - pjmlp 4y ago
        Well, there is Slint in that case, from former Qt devs, but it is still pretty much early days. https://slint-ui.com/ https://slint-ui.com/ Check their online demos.

int_19h 4y ago

UI is a poor fit for Rust, IMO, because the natural way to model UI widget hierarchies is rather painful with ownership tracking in the picture. But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.

exceptione 4y ago
Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser. There is a gap between the nineties and now, and it is still void. If you have to constrain it to CLI apps the average developer here on HN needs to write, I don´t see a reason to use such a complex beast as Rust. If you mean operating systems, I can see a spot for Rust. Also database systems or a web server implementation. But that is fairly niche. For userland cli-apps I am not sure if the added complexity pays of in terms of sufficient performance gains in practice. If you want to write a new implementation of grep, sure. But how niche is that? So in those cases where you need both type strictness (which I agree should be the default requirement) and cannot have an automatic garbage collector, I can see the value of Rust. But for what audience is an automatic GC really a problem? Personally I would use Haskell, Java, F# for CLI-apps, but I know there are tons of other options there.
- xxs 4y ago
  grep inner loops are coded straight in Assembly. So Rust would be a poor fit.
  - steveklabnik 4y ago
    Yet ripgrep is extremely fast, often faster than grep. Practice beats theory. (Rust can also do in-line assembly…)
  - burntsushi 4y ago
    Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?
    - metaltyphoon 4y ago
      If I would have to guess it would be codecs.
      - burntsushi 4y ago
        What do codecs have to do with grep?
        int_19h 4y ago
        grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.
        burntsushi 4y ago
        Those are locales. I've never heard them referred to as "codecs." In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)

pjmlp 4y ago

You cannot even get it with Rust/WinRT straight out of Redmond, let alone having hopes to get it on Linux. C++/WinRT tooling is a shadow of C++/CX capabilities (which feels like Microsoft's C++ Builder), and while the same folks are having fun with Rust/WinRT, its tooling is even worse. I doubt that in five years it will be any close to what C++/CX was already doing in 2015. Specially since they outsource any graphic tooling responsabilities to the DevDiv folks.

exceptione 4y ago
That's sad. I would love to tinker with UI programming on Linux, but it seems like to get anything decent you will have to use QT, which brings C++ as a requirement.
- pjmlp 4y ago
  You can have a look at its issues, https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML. Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.
  - exceptione 4y ago
    Thanks. I did not mean XAML literally though, something like that would be super nice for Linux. The project you linked brings Windows RT as a requirement. But just something with the richness of QT + Rust on Linux would be welcome. I am hearing the rust bindings for QT are just a pain and incomplete. I was hoping for Rust to really offer an alternative for C++ here.
    - pjmlp 4y ago
      Well, there is Slint in that case, from former Qt devs, but it is still pretty much early days. https://slint-ui.com/ https://slint-ui.com/ Check their online demos.