3 ms·
> Are people making user facing apps in rust with GUIs? yes
by tcfhgj 9mo ago
> Are people making user facing apps in rust with GUIs?
yes
- groundzeros2015 9mo agogot any to share? Should I assume native gui in these these rust performance debates?
- tcfhgj 9mo agohttps://system76.com/cosmic https://system76.com/cosmic https://helix-editor.com/ https://helix-editor.com/ https://zed.dev/ https://zed.dev/
- groundzeros2015 9mo agoWhat do you think are good use cases for multi threading in these editors?
- tcfhgj 9mo agosearch, linting
- steveklabnik 9mo ago"don't block the ui thread" is a pretty classic aphorism in any language.
- johnisgood 9mo agoHmm. "Fearless concurrency" and the flagship examples are... background threads for search and not freezing the UI? That is GUI programming 101 from the Win32 era. Every Tcl/Tk app, every GTK app, every Qt app has been doing this for 25+ years. If Rust's concurrency story were genuinely revolutionary, you would expect examples like: - Lock-free data structures that are actually hard to get right - Complex parallel algorithms with non-trivial synchronization - Work-stealing schedulers with provable correctness Instead we have "we run grep in a background thread"?
- steveklabnik 9mo agoWhen a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust! (And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)
- johnisgood 9mo agoYou cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning. In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been brought up as evidence in the first place. Plus if things like work-stealing queues and complex synchronization are not relevant to editors, then editors are a poor example for demonstrating Rust's concurrency story in the first place anyway.
- steveklabnik 9mo agoHere is the question that was asked: > What do you think are good use cases for multi threading in these editors? That question is not even about Rust. I answered the question, not some other related question.
- tcfhgj 9mo agoThe editors (and the desktop environment) are examples for apps with a GUI in Rust, to show people indeed create apps with GUIS in Rust, nothing else.
- xpe 9mo agoYou might start with https://github.com/zed-industries/awesome-gpui https://github.com/zed-industries/awesome-gpui and https://blog.logrocket.com/state-rust-gui-libraries/ https://blog.logrocket.com/state-rust-gui-libraries/
- gf000 9mo agoWell, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?
- groundzeros2015 9mo agoSure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are. To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law). Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful. The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
- gf000 9mo ago> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
- groundzeros2015 9mo agoAnd yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.
- pjmlp 9mo agoNo it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.
- PPanther 9mo agoI made this with egui and typo: https://github.com/PJaros/menu_pdf https://github.com/PJaros/menu_pdf Works under Linux and Windows.