Yes it can used to reduce latency of a particular task. Did you read my points about when it’s not helpful?
Are people making user facing apps in rust with GUIs?
Are people making user facing apps in rust with GUIs?
We are talking not only about Rust, but also about C and C++. There are lots of C++ UI applications. Rust poses itself as an alternative to C++, so it is definitely intended to be used for UI applications too - it was created to write a browser!
At work I am using tools such as uv [1] and ruff [2], which are user-facing (although not GUI), and I definitely appreciate a 16x speedup if possible.
Is there? UI applications historically used to be written in C++. But in this decade, I don't think many new GUI are being written in C++
Now even if it is Flutter, React Native, or Chrome/Electron, they are powered by C++ graphics engine, and language runtimes.
Multithreading is an invaluable tool when actually using your computer to crunch numbers (scientific computing, rendering, ...).
yes
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"?
(And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)
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.
> 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.
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.
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.
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.
Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty?
And it's not like the performance doesn't have its own set of negatives, like header-only libraries are a hack directly manifested from this compilation model.
Works under Linux and Windows.