[MarsIronPI]

> I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot.

The problem with doing everything in Elisp is the lack of threading. GNU Find can search down multiple directories in parallel, and an Elisp implementation of Grep would block the Emacs UI while searching. Until Elisp gets threading it will fundamentally be limited to either short bursts of computation or frustrating UX because of blocking (see also frustrations with Gnus).

[iLemming]

Emacs has had native threads (make-thread, thread-yield) since 26.1 (8 years ago), and async subprocess/process-filter patterns have existed even longer. The real issue is that Emacs threading is cooperative, not preemptive - but that's a different problem than "no threading". For IO-bound work like grep/find, make-process with async callbacks is the standard solution and it doesn't block the UI at all. consult--async-pipeline does exactly this.

The Gnus comparison is unfair because Gnus's UX problems were architectural (synchronous network IO designed before async patterns matured), not inherent to elisp itself. Modern packages don't make the same mistake.

The strongest remaining criticism is the cooperative threading model making it genuinely hard to do CPU-bound parallel work without external processes. That's real. But for the grep/find use case specifically - nobody blocks the UI on search anymore.