Hmm. "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"?

When 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.)

You 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.

Here 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.

The 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.