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 or kick of N threads 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.
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.