Interesting project. Is the plan to only translate however much of Emacs is implemented in C to Rust, or will design quirks also be fixed along the way? I’m by no means familiar with Emacs internals, but, as an Emacs user, this post doesn’t paint a flattering picture of one of the programs I have come to rely on a daily basis.
Most of Emacs’s faults have nothing to do with the implementation language and everything to do with accretion and design for much more limited systems. How much of the Emacs ecosystem depends critically on the display code’s current design? I don’t know but I’d guess a lot. Doing the wrong thing in Rust is not going to magically be faster or better than doing the wrong thing in C, no matter how magical Rust is.
I’m somewhat more enthusiastic about moving Emacs to Guile, which now supports Elisp, but I don’t know the current state of that project.
Perhaps a reasonable hope is that transitioning from the wrong thing to the right thing without breaking everything can be done more easily in a Rust port.
Certainly, for bad design deep in the implementation. If the design problems you want to address are visible to Elisp, it won’t be sufficient. Seems like a lot of work to fix half the problem—but I don’t know that for sure.
“half the problem” is probably an overstatement. Breaking everything will certainly happen, memory safety doesn’t save you from incomplete domain understanding, but that’s a hump you’ll get over. I don’t think the existing errors are due to memory management and some of the other safeties that rust brings, but its nice that you’ll be able to avoid that on your path back up the mountain. I think the bigger struggle is ELisp and the wide amount of extensions. If I had to rewrite emacs, I’d probably use a lisp, I hate lisp but it seems like the most correct choice for the editor.
I agree. I think if Emacs were less robust there would be a stronger case for moving to Rust here.
That post is hilarious.
This was the first thing that came to mind as well. What would be great is to have something that’s compatible with the elisp code that runs on top of emacs but that doesn’t still need to pretend it’s running on a terminal emulator a few decades ago.
Maybe this will make it easier, and I certainly expect refactoring afterwards to be easier in Rust than C, but I can’t shake the feeling this is fixing the wrong problem. I do certainly wish them the best of luck.
Sometimes though, it really is running on a terminal emulator.
I don’t think it’s very unflattering or flattering, but rather the expected outlook for a program that has grown together with the computing world for 30 or 40 years, depending on how you count. It is still used widely, because it has been able to maintain backwards compatibility with all the different ways people are using it, and because of its featureful customization model.
People have tried to replace big parts of Emacs before. Guile Emacs wants to rip out the interpreter, and there have been several talks of replacing the C core with Common LISP.
The challenge is, as you identify it, decades of legacy and a universe of code that relies on minute details in the API.
Replacing the core with Rust may be a more achievable goal than any of the others, for the reasons given in the post. It is relatively easy to do piecemeal replacement of the code.
Once all the C is gone, if that ever happens, or maybe even before then, I’m sure the new infrastructure will allow for easier rearchitecting of whatever layers in the cake people have issues with.
The first sentence is the only one that mentions Forrest Gump. It’s been a while since I’ve seen the movie, so I don’t get it at all. Can anyone fill me in here?
I think it’s because both were involved in important events and know/knew important or well-known people but they themselves remain largely unknown.
It’s seems like a very weird way of describing anybody, but maybe it’s a common comparison in some circles.
I thought it was both of them were earnest but still successful.