7 ms·

> GUI in Rust progresses with unprecedented speed – 3 months in Rust GUI-land is like 3 years in the mortal world. areweguiyet.rs was started almost exactly 5

• KRAKRISMOTT 3y ago
  That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". For GUI programming, there is only one feature that matters: having a fuck ton of well supported widgets for every situation across every platform. Almost everything else is secondary. This is why HTML/CSS, Flutter (and to a lesser extent Qt) are so successful. No end user cares about data mutational elegance when at the end of the day, somebody has to do the unsexy work to maintain and support each individual button, scrollbar, and toggle.
  • vbezhenar 3y ago
    I'd argue that the most successful UI platform is a browser. And guess what? Browser does not have a fuck ton of well supported widgets. All it does it some button with outdated UI, few inputs nobody really uses and dropdown select suitable only for the most basic uses. Anything other built on divs with CSS and JS. And it works. So my opinion is that it's definitely solid foundations what matters. Rest will come with time from third party libraries.
    • KRAKRISMOTT 3y ago
      The browser is successful not because it has a solid foundation but because a ridiculous amount of engineering effort has been put into it. Most of the "beautiful foundation" you see are all post 2012. You young'uns don't remember the days before HTML5 and CSS3. Before npm and PWAs and the "cloud native" nonsense. Adobe Flash anyone? Silverlight? Before WebAssembly/WebGL/WebGPU unity (yes that game engine) even required a browser plugin. Web browsers were often severely incompatible with each other and web standards were a suggestion at best. Now, it's bad form to slander dead people so I will just say that the nice kind folks at apple under the orders of their dear leader did their best to destroy as much of the pre-2012 web as possible by gatekeeping the iPhone browser and using their market power to strong arm web technology.
      • setr 3y ago
        I can’t figure out if you are for post-2012 web tech or against it
        • baq 3y ago
          The answer is clearly ‘Yes’. The problem is we’re in 2011 again, except chrome is the new flash and safari is the ie6.
      • quickthrower2 3y ago
        I remember the buggy adobe svg plugin c.2000! That is an extension you had to install as an .exe to view some subset of svg!
    • jenadine 3y ago
      People dont't simply use CSS and JS to build UI for web apps, they use web frameworks that comes with their share of supported components. And there are also a bunch of these framework to choose from, they come and go.
    • stakhanov 3y ago
      > Browser does not have a fuck ton of well supported widgets [...] And it works. I beg to differ. When the economics of doing UIs shifted away from APIs like Windows Forms, Carbon, JavaFX towards the current trend of doing everything in a browser, it brought with it some serious regression in how powerful and user friendly those GUIs are. With Microsoft-level resources, you can take on a mammoth engineering task like implementing Office or Visual Studio in the browser. But if you are resource-constrained in the way that most developers are, you cut corners and drop functionality, and that's where we are today with browser GUIs ...not that any of that matters if all you're doing is CRUD, like most people are. But one shouldn't judge technology by its easiest, most boring, and degenerate use cases.
      • vincnetas 3y ago
        I beg your pardon, but why do you consider CRUD 'degenerate'?
        • stakhanov 3y ago
          A "degenerate special case" of a general concept, in mathematics [1], is a special case that no longer has the complexities that motivated the need for that concept in the first place. Consider, for example, the evolution of a CRUD app that was first written in, say, the late 80s for OS/400, using an interaction style where it's all full screen forms rendered as text that you fill out with your keyboard, then submit. Say, you rewrote that app in the 00s in Windows Forms but using the same interaction design, and then again in the 20s as a browser-based app. If you look at the evolution of what happened to UI technology through the lens of that app, you won't feel like anything is amiss in 2023, but you're also kind of missing the point of having a GUI in the first place, as opposed to, say, a text terminal. Whenever I hear "all I need is a textedit and a button" from a web developer, I kind of assume that this is what informs their viewpoint. If you instead look at the evolution of UI technology through the lens of an app like Photoshop, it will immediately be obvious to you what it is that GUIs uniquely have to offer that, for example, text terminals can't, and why rewriting such a UI in a browser is anything but trivial. [1] https://en.wikipedia.org/wiki/Degeneracy_(mathematics) https://en.wikipedia.org/wiki/Degeneracy_(mathematics)
    • croes 3y ago
      The browser is more equivalent to the .Net framework and the JVM. The GUI part was started by bootstrap and similar tools and shifted to React, Vue etc.
    • imbnwa 3y ago
      You forgot the part where the browser competently handles i18n and a11y, the later I especially wager none of these frameworks come close to
    • moonchrome 3y ago
      >Browser does not have a fuck ton of well supported widgets What are you talking about ? HTML and CSS is full of widget libraries, it's the best cross platform widget library out there. Ease of deployment + reach is the driving force behind improving the platform, but at the present nothing in Rust can even compare to something like Material UI. And let's not even go into stuff like date range picker components and shit where companies probably spent millions in engineering effort to get them right (eg. AirBnB) .
      • coderedart 3y ago
        Is a date range picker that hard to implement?
        • CuriouslyC 3y ago
          You wouldn't think so, but I've seen a lot of bad ones.
  • Klonoar 3y ago
    >That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". That's... entirely wrong and not necessary to paint swathes of developers like. Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms. Just because there's not one blessed solution doesn't mean it's not possible to write UIs in Rust today. ;P
    • chrismorgan 3y ago
      It’s not entirely wrong. Rust GUI has been held up by a significant dose of trying to do things properly, since the language definitely pushes you in that direction. It’s taken so long because Rust insists on correctness and on an ownership model that the popular solutions for GUIs simply didn’t fit into, so it’s taken time to come up with things that do work in those constraints.
      • brabel 3y ago
        Why do you guys think it's taking a lot of time because people are "trying to do it properly"?? See the comments about people trying the egui demo... that thing is as easy to crash as any junior dev React application.
        • Ygg2 3y ago
          By doing it properly chrismorgan means a native Rust solution that works with borrow checker. Egui is mostly bindings. And those can suffer from impedance mismatch (e.g. using OOP UI in Rust)
    • iudqnolq 3y ago
      Can you give an example of a real, shipped app where the majority of the GUI is written in Rust? I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust. This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite disappointed.
  • klodolph 3y ago
    I think that you’re right, and broadly speaking, there’s an inverse correlation between how invested someone is in programming and how invested someone is in the problem domain. Could be Berkson’s paradox at play here, but I think that it’s really a question of opportunity cost—the time you spend becoming a better programmer is time you could have spent learning some problem domain that you could solve with programming. So you end up with stuff like the image crate (a straight up disaster of a crate—lots of fancy Rust bells and whistles, doesn’t support a bunch of stuff you want to do with images, reading the GitHub bug reports make me feel no hope that the issues will be addressed, ever) and R (a straight up disaster of a language, just a nightmare to write, but full of useful statistics packages, always has the package you need, but the language was made by Satan).
    • wiz21c 3y ago
      Funny you mention R. I started a several months work on data analysis/science/you-name-it in python (a good language) and slowly, without noticing it, I migrated all my stuff to R (made by Satan). And exactly for the reason you give: R gets the sh*t done faster (in terms of time spent writing code) than Python... (and you can consider I am a lisper (worse: a schemer)/rust-er at heart !!!)
    • zelphirkalt 3y ago
      There is also some correlation between how solid the base is and how long a library/package/project is used, before it is cast aside for a new hip and trendy one.
      • klodolph 3y ago
        Maybe. My sense is that there’s a finite amount of developer energy you have to allocate between different concerns. If you think of R, the language, as a base, then it’s definitely NOT a solid base (in my estimation). If you see it as a continuation of S, then it’s nearly 50 years of use for something you wouldn’t want to build on. I’ll say the same thing about R+statistics as I will for Python+machine learning, for C++&game development / OpenCV, or Fortran and scientific computing. Having domain experts actually use your language to solve problems is such a massive advantage that you can almost ignore the benefits and drawbacks of the language itself. Almost.
  • weinzierl 3y ago
    Maybe you are right but it sounds a bit like: "For GUI design there is only one feature that matters: having a fuck ton of well supported colors for every situation across every platform." Replace colors with fonts or animated GIFs and you and up in late 90s web design.
    • crispinb 3y ago
      I don't think that's quite the point. It's not that you want dozens of different widgets in every app. It's that when picking an ecosystem for apps, a business will want to know that whatever they need (whatever small sample from that multitude), it's available. A large pool of resources is particularly important when you don't know exactly what you'll need up front, which is most of the time. You might only want 8 colours, but if you don't know exactly which 8, you'd better have a large palette available.
      • weinzierl 3y ago
        I used to think like that, but it doesn't match my experience from my years of building (traditional) GUIs. I believe it is almost always better to stick to the couple of standard widgets that are available everywhere and known by everyone. In the very rare cases it's not it is better to build a custom widget that matches your customers requirements exactly. Nothing is worse than a half-baked GUI element idea, badly implemented and sloppily maintained that matches like 85% of your customers requirements - and that's what most non-standard widgets are. Quality and consistency trump quantity in my opinion.
        • crispinb 3y ago
          It matches my experience precisely. Every time I've seen a GUI framework/library chosen that didn't have a huge head of steam behind it and very broad availability of off the shelf components and tooling, the project has either failed, or had to be rewritten after a swerve. This is for relatively mainstream software (consumer apps). Niches are another matter.
  • imbnwa 3y ago
    This must be why the two Rust GUIs I used daily, Neovide (Neovim) and Psst (Spotify) have stagnated as far as addressing visual bugs: they depended on Druid which, according to TFA, is abandonware
  • wiz21c 3y ago
    There are domains where "end users care about data mutational elegance" because, you know what, they care about reliability in a very strong way (not like: hey the web site is down, let's call the devs; more like: there was a bug, let's call the morgue). Just to say. But I agree with you: if your work balance is more oriented towards productivity then rust will not help much. For example, I design lots of stuff in python/jupyter/ecosystem first and then port that to rust for the speed and correctness.
  • berkes 3y ago
    > Almost everything else is secondary. For any app more complex than a demo "todolist", handling "business logic" is - by far - the most important. Hundreds of widgets that don't do anything, or do it wrong and buggy, are worthless. "handling business logic" is difficult and, ironically, perpendicular to many frameworks (as in: frameworks make dev/testing/evolving/refactoring of business-logic harder, not easier). A perfect example was (is? IDK) Visual Basic: tons of widgets, a neat builder, but terrible in managing even simple state and handling business-logic. Or React, which is a perfect framework (and paradigm/architecture) for small, or flat apps, but terrible for complex or convoluted apps. What I see in Rust, is a focus on the stuff beyond mere "providing lots of stuff that can be drawn to screen": how to manage state, react to changes, manage events etc. Which is, the way I see it, why there also are so many frameworks emerging: what architecture and paradigms work best, very much depends on your use-case.
  • PoignardAzur 3y ago
    Speaking as someone working on a Rust GUI framework: how dare you say things about me that are completely accurate. That said, it feels like it's starting to change. Lower-level components are getting stabilized, SlintUI and iced are picking up speed, etc.
  • calvinmorrison 3y ago
    That's a great point. If you've had the pleasure of writing anything in GTK/Glib with C, you quickly realize it ain't your mothers C. But like C with a bunch of object oriented casting on top of it .
  • IshKebab 3y ago
    There definitely are people like that (e.g. the Xylem stuff is an attempt to make something "perfect") but a) I don't think there's anything wrong with some people doing that, and b) that clearly isn't why we don't have a 1st class Rust GUI yet. 1. There are unprincipled Rust GUIs, e.g. Egui. It works great. 2. Making a GUI framework is just bloody hard and a ton of work. I think only a small handful of languages have native GUI toolkits. Most just wrap C or HTML. GTK is 25 years old and Qt is 27 years old. I don't think 5 years is long enough to develop a mature GUI toolkit (unless you have an enormous company backing you maybe).
    • int_19h 3y ago
      If we look at, say, Qt 3 (2002), or even Qt 2 (1999), I'd say that the comparison is still not in favor of modern Rust UI-from-scratch toolkits.
      • IshKebab 3y ago
        Actually I got the dates a bit wrong - according to Wikipedia they started writing Qt in 1991. Also that was a full time commercial project. As far as I know all of the Rust GUIs except Slint are hobby projects. Finally, modern GUIs are way more complex than they were back then - especially when it comes to graphics APIs and text handling. So I still think it's too early to say Rust has failed when it comes to GUIs.
• alkonaut 3y ago
  Would there ever be a "definitive" solution to GUIs? Like some canonical "this is how you GUI in Rust"? I mean there are about zero other languages where that has happened, how would Rust be any different? Just for N simple binary choices like immediate/retained, single/cross platform, markup/non-markup, native/non-native controls and so on, you'd quickly end up with 2^N solutions that almost have to coexist because some of those choices are deal breakers for some.
  • mcluck 3y ago
    Of course you'll always have different ways of building UIs depending on circumstances but eventually some consensus will be reached for a default approach. WinForms used to be the default for Windows, Tk was the default for Linux (or at least that was my impression, I was all in on Windows back then), etc. For many people, using web tech has become the default if you want to build cross platform UIs. You have the option of building with imgui, Qt, Gtk, etc. but I don't think it's controversial to say that your average dev who wants to make a cross-platform GUI will probably use Electron or an Electron-like. I really want to have a default for the Rust space. I've even done some work here myself which is why it's surprising to me that we aren't there yet
    • alkonaut 3y ago
      OSes that come with a native UI obviously have that as the default. But there will never be a default across OSes I think. Web UIs might be that, but I sure won't want to use html or js anywhere in my UI's if I can help it, even if cross platform. Java might perhaps be the best example of trying to make a default-for-a-language cross platform UI (Swing and whatever it was called that came before it). But I think it's also an example of why it might not be a great idea to even try. I think a key realization is that an app like Blender or AutoCad need a different UI paradigm than Spotify or a game overlay does, even on the same platform there are differences there. Apps that can use web based UIs tend to be more like Spotify than Blender...
      • revelio 3y ago
        Swing is pretty nice UX these days actually. Try the very latest IntelliJ in "new ui" mode, it looks modern and has an incredibly productive UI with tons of keyboard shortcuts, specialized widgets, etc. The API is a bit old now, but you could easily put a reactive layer on top.
• sophacles 3y ago
  C was started 50 years ago, and we don't have a definitive solution to GUIs there either. I'm not sure what your point is.