Financial resources required to rewrite the Emacs core

Hi y'all. I was wondering how expensive would it be, in both programmer time and money, to either mainline guile Emacs or rewrite the c core entirely. This isn't a serious post. I'm just curious.

The most difficult part would be finding people that are familiar with Emacs internals AND think that porting it to another lisp dialect / another language is A Good Thing. I also don't see what would be the benefit of rewriting the C core. IMO the "emacs has no multithreading / is ""slow""" / "I installed emacs 5 minutes ago and it's not VSCode" / "Guize why isn't emacs in lang [X]" topics are a waste of everyone's time now. Give them an entry on the subreddit's wiki and call it a day.

That's not my question though. Assume I have infinite money and I like Emacs. I want a checklist of new features and I decided that you'd have to rewrite the core. How much would I have to pay a guy to do it? Actually... How much would I have to pay Stallman to do it? A few hundred thousand? Or in the millions? Edit: I do agree with you in the sense that I like Emacs the way it is. And I know enough elisp to write a few of my own functions. It's just a thought experiment.

Real life isn't a video game where you can just pay people for stuff. Case in point : the people leaving their cushy jobs at twitter.

Yeah but real life is boring. That's why I like to do 2d vector analysis using imaginary numbers

I'll do it for 300,000 USD. I'll need a couple years. Also we'd need to agree on the checklist of features ahead of time. On a more serious note, I do accept commissions for elisp packages if you have an itch that's out of reach.

Hey thanks for the reply. Do you have a website ?

You can check out some of my current elisp projects here: https://github.com/progfolio If you have any questions feel free to DM me here.

We perhaps can start a discussion if/where are weak points, or slightly improvements needed in Emacs. In my case I cannot say anything about it, I am newbie and not a programmer...for me emacs is just fine as it is. The bigger problem (for me) is to find "readable" documentation (readable for newbies)

It would take a few developer–years, though less to rewrite it than it took to write originally :) Maybe just two, but possibly as many as five, developer years. Certain aspects of it are pretty easy; there are a lot of C functions that just implement some small editing action like `forward-char`, and you can go down that list pretty quickly and probably get them all done in a month or three. Other things are much more involved, like the lisp interpreter, the bytecode compiler, garbage collection, etc. Those require more thought.

Don't we already have those threads?

Agreed, what's the use of rewriting core if the devs working on it do not want it rewritten because they no longer can make sense of it? It would be different if they were in agreement that a rewrite is needed, but so far the most I've seen was Eli asking people to come up with a fully thought through proposal on how to rework the display engine.

Do we? Happy to read more about it!

At least, https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/TODO

For readable documentation have you tried https://emacsdocs.org/ ?

I am not entirely sure an easy answer can be provided, but I personally thought the remacs \[1\] approach was very interesting: slowly port C functions into rust over time. However, the project appears to have stalled. Given it had over 500 contributors over a period of several years, it seems to imply this is not a trivial undertaking. \[1\] https://github.com/remacs/remacs

Most people only ported small functions, for fun. There were only a few that invested more time in the project. Ambitious projects like remacs need a handful of really experienced developers willing to make it a success. But those people don't seem to be interested in maintaining a project like this. I can understand it. If I was good enough, perhaps I wouldn't be motivated to maintain remacs and even elisp packages. But that's also the main issue in the emacs community. Most of them work on projects that aren't related to emacs. I can understand it, but it's also sad. I wonder why it worked for neovim, maybe because the codebase is less complex.

> Real life isn't a video game where you can just pay people for stuff. That's literally the point of money, though. The main difference between real life and videogames is that prices are dynamic, purchases aren't instant, and both can be *much* more complex than anyone ever programmed into a game. > Case in point : the people leaving their cushy jobs at twitter. Mostly for other cushy jobs. And typically, if you can't find anyone to pay for doing some stuff, it just means *you aren't offering enough*.

This is such an odd response. Here in the real world, you do just pay people for stuff - that's kinda how it works.

Perception & People Management is much more important than throwing money at a problem. More often than not, money is an afterthought.

Not eager to discuss this topic, but I'll just state that people don't have all the same preferences or abilities - you could pay me a gazillion dollars to do your taxes and I'd fuck it up (bad example).

Yes. And considering how Emacs now has byte compilation, any changes to the core *might* lead to large changes in native-comp, too. Would love to be corrected on this though.

Yea, you have to pay people who can actually do it. Still have no idea what point you're actually making here. You know op's question was hypothetical, right?

> so far the most I've seen was Eli asking people to come up with a fully thought through proposal on how to rework the display engine. I'm only asking for proposals from people who clearly don't intend to sit down and start working on this themselves, but rather expect others to do it. If someone wants to work on reimplementing the display engine, or (better) redesign it to make it more powerful and flexible to begin with, they don't need to submit any proposals, just code away, and come back when they have something ready, even if it isn't yet 100% complete.

What would be the purpose of rewriting the core which you are asking about? Would it be to recreate the same Emacs we have today, from the POV of APIs it presents, primitives that it exposes, and basic data structures it uses internally? Or would it be a complete redesign, such that, for example, buffer text is no longer a C string with a gap, the display engine doesn't consider the screen as a rectangular canvas of glyphs, the internal representation of Lisp objects is completely different, the entire Emacs architecture is no longer MVC, etc.? If you don't say which one of these two you have in mind, the discussion will not be useful because some will think it's the former whereas others will think it's the latter. Btw, Guile Emacs is neither of these two: it is simply an attempt to make Emacs provide Guile as its extension language, instead of Lisp.

> It's just a thought experiment. The answer is zero. To paraphrase Alec Guinness, closed-source companies can strike us down with robustness and features, but open-source will obliterate them on price. Commercial Emacs has already rewritten large parts of emacs to the tune of 40,000 insertions, and 70,000 deletions. The changes are not going to butter your bread, and there are dozens of bugs, but we're doing things more correctly than the 40yo ball of mud being glommed to by the quiet quitters and procrastinating grad students. The business plan was never to withhold improvements for cash. We have GNU and the open-source movement to thank for killing off that honest way of making a living. No, the goal is to get emacs widespread enough that corporations might consider it an all-in-one workflow platform. We're currently light-years away from reviving the 1990s when Amazon's customer service system was built on emacs, but we're not giving up.

I don't quite understand your point here. Is it that open source emacs has a resilience that commercial products don't have because of its openness? Or that commercial efforts to improve the ball of mud have been strangled by the GNU's dogmatic approach to licensing? Are you involved with this commerical rewrite project? And if so, what's it called? I'm quite curious.

My point is nothing beats free. In any other market, free is unsustainable. An insane uber driver, even if he wanted to, could only give away so many free trips per day. Contrast uber rides with software which, like music and movies, is perfectly reproducible at scale and frictionlessly disseminable. Emacs and vim at one point ruled the roost because they were free. The only way vscode could topple them was by also being free.

Let's try to put this one to bed. Again. There are three main components to the core of Emacs (as I understand it): 1. The lisp processing including buffers that can be mapped to Guile of other language implementation. There is very significant impedance challenges around string handling, so this is not insignificant. 2. Operating environment issues: memory management, dish access, network access. This is where most of the "porting" issues reside. 3. Display management. (Eli can speak to this and has) The interpretation of buffer contents with properties, overlays, character encoding, and vastly different display architectures means getting text to display is probably not going to port or improve much in a rewrite. Despite these, Emacs 29 represents a huge step forward in performance. And Emacs' inherent extensibility means it can be extended in ways no one in the '70s could have imagined.

This is so much more approachable it should be in the sidebar.

Thanks for pointing that out, I seem to have missed the last line of the OP.

In large corporations, a single sr. software engineer can generate about 100 lines of debugged high level code per day. Such an engineer typically costs about $250k/year in the USA and their output is about 25,000 lines of code. Emacs has about 1.5 million lines of code in core, the last time I checked. So, your engineering cost is going to be about $15M US dollars. But, to get that done in a year, you'll need 60 engineers. So, you'll need to figure out how to coordinate that work. So you'll need to divide the group up into teams with PM's and program managers to coordinate the work and make sure everything is lining up to your plans. Figure 6 teams of 10 people, each with some sort of PM, plus a couple of architects to help with coordination. On top of that, for a year long project you'll need some release engineers, an HR specialist to restaff should anyone quite or leave, and to keep track of billing otherwise, plus you'll need a bevy of analyst level people to take notes, and document things. A project that size, to complete in a year, is going to be about 75 billable people total, and by the time you include things like cloud storage space, laptops, and the like, to do this commercially, it would run in the neighborhood of $25-30M USA. That's assuming almost no refactoring and no re-architecting of anything. This is zero new features and just taking a frozen artifact and reproducing it in another language. If you want to add something like improved multitasking, the price would go up. But probably not by much. Source: I'm a consulting delivery lead. Managing projects exactly like this for corporations is what I do.

If you can find and sell to a dumb enough buyer for $25-30M, you'd deserve the $1M sales commission I'd set aside for you. As Fred Brooks (RIP) can tell you, 75 guys are about 70 guys too many. I'd just need 1-2 guys from the sbcl team, and 1-2 guys from emacs-devel. Perhaps you'd want more though. I mean, such a sale could make George Parker blush.

Absolutely it is. I love my job, but if someone said, "I'll pay you $500k a year to port emacs to this pregnancy testing device," and I believed it were possible, I would certainly take the money. > the people leaving their cushy jobs at twitter. I love my apartment, but if a gorilla moved in, I would move out.

If someone offered me even just $1 million to do their taxes, I would learn how to prepare taxes.

Yeah, fair enough. Although the tremendous success of IDEs like IntelliJ, Visual Studio etc indicates that people are willing to pay for software if it's good enough. For Java the OSS software doesn't even come close

Well sure, but you wouldn't be very good at it even if you put six months into it, compared to any other accountant.

Decide which portions of Emacs "userspace" and which parts are "kernel", write a evolved kernel then port the "userspace" into it.

That's a great reply and you gave a me a lot to think about. And tbh I didn't think about how to have a useful discussion in the first place, but now you've got me pondering . Let's consider the first case. Since Rust is now the big meme language, how much time, money or both would it take if someone actually tried to refactor the entire core into Rust, and keep userspace exactly the same? (Don't roast me please, even I think that's dumb) Let's consider the second case. Hypothetically, let's assume we want to change the fundamental behaviour of Emacs. Is there any valid reason for doing so? Because as far as I'm aware, even if we wanted a multithreaded Emacs, you shouldn't need a complete rewrite. As for guile Emacs, I thought there were some potential performance benefits, plus a lot of people thought it was just a nicer language. How much time and funding would it need to mainline it? (Let's treat that as a separate question, since I misunderstood the difference between mainline and Guile Emacs)

Idk man. Gorillas are usually nonviolent and maintain respectful boundaries. Musk... Is a chimp. Or worse, a Homo Sapien. I'm betting on the latter.

Thanks for reminding me that Emacs is a great Os. If only it could run crysis