[Comment removed by author]
SLIME, as the expression of roughly 50 years of parallel evolution and refinement of a programming language, developer toolchain, and ecosystem, is absolutely the gold standard. It’s also had 50 years to get there.
Let’s furthermore not forget that homoiconicity and image-based development has meant that your source code, object code, parser, compiler, debugger, and REPL all ship as part of a single mutually-referential whole. That in turn lets you do exactly the kind of whole-program analysis that the RA article bemoans as largely intractable in Rust-land.
C as a language lags by at least 15 years, and Rust is only a smidge over 10 years old. If you want to find something closer to the Lisp/SLIME universe it’s probably in the JS or .NET ecosystems…neither of which is actually fully self-hosting AFAIK, and so you still hit a hard wall of abstraction when you drop below the standard syntax and libraries.
If we’re very lucky, perhaps Rust + $EDITOR circa the ~2040 edition will have achieved something like the smooth integration and workflow that SLIME devotees have been (rightfully) crowing about since at least the late 90s. :)
: I still don’t see VS Code being this One True Editor, but neither Emacs (given the Lisp-ness discussed above) or (N)Vim seem likely to naturally fill the gap either, since they aren’t born of the same zeitgeist and aesthetic as Rust. Perhaps it’s no coincidence that so many folks in the Rust community are focused on text processing and GUI frameworks, and the ideal “Rust environment” is both imminent and inevitable.
Forgive me, I don’t know slime well, but wouldn’t it have the same problem? Assume some macro expands its arguments by reversing the names of symbols. How would slime know to autocomplete the reverse of what is intended?