1. 45

  2. 17

    I came here to sarcastically say “congratulations to Rust for reaching the point in language maturity to embark on another failed port of emacs”.

    But, I actually read the readme, and I have to say that the incremental C->Rust port process seems like a far better one than the usual wholesale rewrite of emacs, or even the wholesale rewrite of the elisp interpreter. I’m much more optimistic about this effort than any of the others that I’ve seen over the years, and genuinely wish it luck and success.

    1. 8

      Haha, that made me laugh in a good way :).

      Yes, it is part of our sales pitch that we support incremental ports instead of rewrites. That also means that it is feasible to integrate our tooling into your current toolchain with ease. This will certainly never be “no friction”, you end up with two compiler toolchains instead of one, but “low-friction” is important to us. If there’s anything problematic for you trying this use-case, we’d like to hear!

      1. 6

        I think that many of the language-centric emacs port projects include an objective (often unstated) that amounts to “get rid of elisp, and replace it with language X”. Of course that’s an utterly immense goal, and manages to be self-sabotaging as far as eventual adoption goes. Which is why it’s become easy for me (and others) to dismiss them.

        Whereas the goals for this project appear to be “replace C in emacs with Rust, fix found bugs along the way”, which is a goal which is not only attainable, but which can get useful results along the way. A classic example of a right way to do a rewrite.

    2. 7

      Upvoted for the Why Emacs section alone. I hadn’t heard of many of these back when people were pushing me to use Emacs. This is probably the best marketing I’ve seen for it. It also makes me want to consider trying it again.

      1. 9

        In practice, the “mutable environment” part isn’t so great. My experience with defadvice and redefining functions is that it’s a great way to have your development environment break on upgrade.

        Although it isn’t part of Emacs proper, magit is such a big part of my Emacs experience that I’d add it to any pitch. By far the best Git interface I’ve used.

        1. 3

          In practice, the “mutable environment” part isn’t so great.

          I’ve found the opposite to be true in my experience; using other programs that don’t work like this is endlessly frustrating.

          Of course as with any programming language it’s easy to write brittle code if you aren’t disciplined, but the introspective features make it easy to track down the point of incompatibility.

          1. 2

            Of course as with any programming language it’s easy to write brittle code if you aren’t disciplined

            What do you mean by discipline here? To me, this means that there exists some contract between the maintainer of a library and the user of a library, and as the user, I stay well within that contract so that my code does not rely on implementation details. I guess there are technically some uses of defadvice & redefining functions that satisfy that criteria but they generally aren’t what I think come to mind when someone says “nothing is off-limits” (which isn’t even true)

            I won’t lie and say I haven’t found the ability to patch an arbitrary function useful at times, but I try to limit my usage to temporary fixes until the maintainer accepts my patch upstream. If that goes nowhere I’d rather vendor the library w/ changes in my .emacs.d.

            1. 1

              I won’t lie and say I haven’t found the ability to patch an arbitrary function useful at times, but I try to limit my usage to temporary fixes until the maintainer accepts my patch upstream.

              I fully agree with this as far as it applies to defadvice. The “undisciplined” behavior I referred to above was more about “writing code and not taking responsibility for maintaining it going forward” which is what happens when you make a “fire and forget” defadvice.

              I would say that defadvice is only a tiny part of what makes internal reprogrammability so wonderful. Most of the time when I’m doing magical things in Emacs that wouldn’t be possible elsewhere, it’s writing new code, or reloading new definitions of functions I’ve written in the past, or adding hooks to explicit extension points which library authors have provided. I only resort to defadvice as a band-aid to be removed when the underlying lack of extensibility can be addressed.

          2. 2

            Thanks for the tip. Although I don’t use Git, the first picture is very organized and I understand quite a bit of it. The usability looks good at first glance at least.

        2. 6

          This port is getting a surprising amount of heat on hn and this site. It reminds me of the quote: “telling a programmer there’s already a library to do X is like telling a poet there’s already a poem about love”.

          I hope people are having fun writing this port.

          1. 4

            That reminds me about that xi-editor project. I wonder if they made some progress.

            1. 3

              The author of the port gave a presentation on it, here is the transcript:


              And here is the latest update of the project:


              1. 0

                Maybe I will seem like a jerk but my opinion is this is an expensive project with little to gain. Not really worth the effort spent. But prove me wrong and I’ll be happy for you.

                1. 16

                  Not really worth the effort spent. But prove me wrong and I’ll be happy for you.

                  Wilfred mentioned it in his presentation that while porting Emacs C source to Rust, he found bugs, fixed them and in turn was given Emacs commit access.

                  1. 0

                    Those are good things, but the cost benefit still does not make sense to me.

                    For the cost of many hours of time you get:

                    • A few minor bugs fixed that didn’t affect anyone majorly for years.
                    • Commit rights so you are free to give away more of your own time for free. (Trading time for prestige?)
                    1. 2

                      You can’t actually say what they get out of it because what you get out of it isn’t necessarily the same.

                      Time preferences vary according to each individual.

                      1. 1

                        I suppose I should have worded it “doesn’t make sense for me”.

                        I actually mean well by being this critical. I’ve lost lots of time and other things to projects like this and in the end it was not worth it. Programmers often don’t value time as much as they should.

                        1. 2

                          Programmers often don’t value time as much as they should.

                          Given my previous comment, I think it should be clear that I reject this notion because I fundamentally disagree with its premise: that there is some gold standard on what time preferences should be.

                          Whether spending time on projects like this was worth it or not is completely a matter of perspective. Both successes and failures can be valuable. For example, my time preferences at $work are tuned completely differently than my time preferences at home. At work, I (generally) can’t afford to take a 2 week diversion to read a couple research papers to figure out what the best of the best is, primarily because the solution we know how to build today satisfies our immediate business need for it. But at home, I have no deadlines and my only real constraint is the number of days that I live. Therefore, if I want to spend 5 years rewriting a piece of software, there’s nothing inherently wrong or mystical about that.

                          All you need to do is acknowledge that my time preferences are different than yours. It might help to consider opportunity cost. For example, this week, I can either go home and work on my pet project (which maybe you think is a giant waste of time) or maybe I could go sit on the couch and watch Game of Thrones. Is that less of a waste of time? Or more? How do you know without knowing my own personal time preferences?

                          In my experience, telling people that what they’re working on has no or little benefit can’t possibly end well. The very fact that they’re working on it means they chose to do that at the expense of every other thing that they could do with their time. So they must see some value in it. If you want to mean well and you think there’s a lesson you can teach about time preferences, then it might help to ask them what they’re hoping to gain by working on this project. In my experience, most people understand that sometimes working on a thing is just fun because they like building stuff, and something about porting an old piece of software might just catch their fancy. I’d wager that most of these projects die and fizzle away to obscurity, and you might think, “Hah! Told ya so!” But, no, in fact, you didn’t. Because I still enjoyed my time working on the project, and I achieved the goal I wanted: to have fun. In other cases, the project is so much fun that other people have fun working on it with you. And it evolves. And guess what? So do your goals. The project becomes more than just something to scratch an itch, it becomes something that solves problems for other people too.

                  2. 6

                    It certainly does. This can be said about almost any exploratory or porting project and these ones have at least made the effort to write a lot about why they thing its a worthwhile endeavor.

                    Even if the project goes nowhere, the Rust community gains a lot from this, as making this kind of porting work possible is a core target of the language. They will hit all the things we haven’t foreseen.

                    1. 3

                      I didn’t see any measurable objectives for the port. The closest thing to a justification is better thread safety. Which may be a problem, but I wasn’t aware of it, and have no way to measure if the work was successful.

                      Listing the good things about rust and the good things about Emacs is not a good justification for Emacs in rust.

                      I guess the real reason is to have fun, though that motivation is maybe one of the most flimsy to base a lasting project on.

                      1. 7

                        For example, exploration is explicitely mentioned:

                        By forking, we can explore new development approaches. We can use a pull request workflow with integrated CI.

                        It mentions that maintained forks of emacs are not unusual:

                        Forking is a longstanding tradition in the Emacs community for trying different approaches. Notable Emacs forks include XEmacs, Guile Emacs, and emacs-jit.

                        There’s a measurable objective: Emacs, written in Rust. That might be simple, but is quite enough.

                        I also wouldn’t discredit fun here. Lots of projects started as fun and got somewhere when someone got hooked.