Question: future of elisp in remacs?

[edvorg]

Hi. Does remacs have any plans on improving things with elisp? Are there any plans on extending elisp with concurrency primitives or maybe even introducing alternative language in addition to elisp?

[qgymib]

I have this question too. I have following this project for a while and still not switching to it.

It seems porting C functions to Rust hardly bring benefits to end-user, as you known C already fast enough.
A lisp interpreter completely rewrite in Rust might be faster, but require lots of work.

Is it possible to rewrite internal elisp functions into Rust? This should be really really faster than original one.

[kidd]

I don't think the aim of remacs is to be ahead of gnu emacs featurewise. I doubt we want to have unique features that would make some elisp only remacs-y.

Maybe a "remacs--*" prefix for crazy experimental features would work though...

[shanavas786]

There is already an effort to replace elisp with guile. https://www.emacswiki.org/emacs/GuileEmacs

[Wilfred]

Concurrency: Trunk GNU Emacs does actually have support for threading, but you have to enable it at build time. Rust makes it much easier to write safe multithreaded code, so I'm hopeful that Remacs will be more robust once we port the relevant bits.

Other languages: No. See 'What Remacs Isn't' in this blog post. A big strength of Emacsen is that everything is inspectable and debuggable with the same tools. There's also way too much elisp out there and it would split the community.

Experimental elisp features: This is possible if there's interest. For example, adding bindings to libgit (though I think the magit maintainer plans to use FFI, which is probably a better fit), allow users to generate their own Emacs images (I'm really interested in this), or additional opcodes for the bytecode interpreter. We should do this carefully, considering compatibility and I'd encourage anyone interested to write an RFC issue with a concrete proposal.

Moving functions to Rust: This is possible if there are hotspots. This works both ways though: we've recently ported identity to Rust, and this could totally be an elisp function.

[meadofpoetry]

@Wilfred Why not to change architecture in the first place? Current Elisp implementation looks odd: functions like mapcar are written in C and everything is being evaluated in a very straightforward manner. There is no decent inliner/JIT/optimizer, no tail call optimizations, I've never looked into emacs' GC, but I'm pretty sure it could also be improved a lot. Wouldn't it be more prudent to make a decent modern compiler/interpreter/runtime that would make it possible to write more stuff in pure elisp (e.g. mapcar, which is to slow since evaluator can't inline closure, we are stuck with ugly macro loops instead of higher order functions) and also would make pure elisp libs faster (i.e. dash)? I know, that straightforward rewriting is easier, but I'm not sure there would be any reasons to use the exact same emacs but in rust.

[shaleh]

Once there is no more C we will be able to investigate improvements. Porting is the first step, not the last one. By moving the code slowly, Remacs is always functioning. This makes it less likely we miss something along the way. With 30+ years of history there are plenty of dark corners in the C code which have to be replicated in Rust or functionality breaks.

As just a user, Remacs today does not offer much today. So unless you are interested in being an alpha tester just keep using Emacs. If you are interested in coding there are plenty of opportunities to help us improve either how we are porting or just grabbing chunks of C and tossing them over the fence. The sooner we start emptying C files the sooner we can perform whole system analysis. Look at PR #547 as an example of seeing enough ported code that a better way was found. A month and change back I added a similar bit to auto generate the defsubr calls during the build process.

If you cannot help now, come back in 6 months. Or submit Issues as a user.

[troglotit]

One of the interesting approaches would be to write a full elisp interpreter (thanks to it's being a lisp, should not be that big of a deal?) and shove it into https://github.com/nbp/holyjit - which is like RPython, GraalVM (Interpreter -> JIT compiler). They have some hopes to replace SpiderMonkey with it.

[shaleh]

The issue with re-implementing elisp is you need to be bug for bug compatible. It is not always easy to recreate warts.