Hacker News Reader

Comment by mschaef | Hacker News Reader

This looks like a lot of work for what amounts to very little end-user benefit.

Honestly, I'd rather see more progress on the Emacs Lisp/Guile migration than on a putative C/Rust migration. At least with the Guile switch, it's something that will have an obvious (and probably positive) impact on the people that use the editor.

View on HN

In response to the general critiques of "Why rewrite emacs at all!?", I believe there are hidden benefits to an incremental rewrite to Rust executed this way.

First is that remacs has been able to reduce the amount of non-Elisp code in the editor needed to implement a number of different features. It was able to do this by replacing hand rolled C functionality with high quality crates from cargo, or code in the standard library. I'd attribute this to how easy the cargo system makes implementing libraries into your project.

Second is I believe that this project overall is increasing knowledge share of not just Rust, but also mainline emacs. I personally was intimidated by looking into contributing to mainline emacs. The remacs community was so friendly and welcoming I felt very encouraged to jump in and start working on things, and now I not only have better knowledge of Rust, but a pretty decent knowledge of the C layer in emacs and how it lays out and implements it's data structures etc.

Third is that the majority of the emacs codebase is written in emacs Lisp. Remacs aims to be fully Elisp compatible, and any differences are considered bugs and should be reported. This means that the project is still able to keep up feature and bug parity with the mainline, while incrementally rewriting the core of the editor.

Disclosure: I am a contributor to this project

There is a huge amount of C code in Emacs that already isn't using the standard C library. As an example, the other day I noticed that Emacs has its own hand rolled implementation of mkstemp(). Unsurprisingly, the Emacs version uses a less secure implementation, so the custom implementation is of no value.

A lot of people have already written about the difficulty of getting changes to fix things like this (or eliminate dead code, etc.) landed in upstream GNU Emacs. Rewriting parts of Emacs in Rust is an interesting idea, and I applaud it as a fun project. But for people who are interested in making more incremental improvements to Emacs, there's a lot of work to be done in the existing C code base to make it smaller and more secure.

If it's hard to upstream code in emacs, doesn't that improve the case for a rewrite/fork?

The mkstemp you are seeing is probably the one from gnulib. A lot of GNU software uses their own versions if they detect the platform one is broken; it may be incorrectly replacing it in this case.

https://www.gnu.org/software/gnulib/manual/html_node/mkstemp...

https://github.com/emacs-mirror/emacs/blob/65eee8392ff95f58f...

I don't see how it is any more incremental than what Remacs is trying to do. They're doing a parasitic rewrite of GNU Emacs, it's not a from-scratch implementation.

To be fair: emacs was written in an era where the idea of a "standard" C library was kind of a joke. Those functions provide "no value" today on systems that have been POSIX-valid for decades. They certainly did in the mid-80's when Unix portability was the biggest hassle of the day.

That said, though: wouldn't that argue for things like "remove custom mkstemp" and not "rewrite it all in rust?"

As more of an admin kind of guy, i find this explosion of language specific repositories worrying.

I have already had to deal with python code that do little to no dependency documentation, that just carpet bomb my system with stuff pulled from the net at the install stage.

Python has/had a terrible packaging story though. As you said, dependencies weren't really documented. Rust, on the other hand, documents all dependencies in Cargo.toml. And dependencies can easily be parsed from Cargo.toml without the need to execute any code (as would be required in the case of python)

> Python has/had a terrible packaging story though. As you said, dependencies weren't really documented.

I wonder where have you lived? I rarely found (if ever) an undocumented dependency list for any serious Python project in the last couple of years.

python's packaging, especially compared to state of the art which cargo represents, is really, really poor. documenting direct dependencies is just a start. requirements.txt is somehow simplistic and complex at the same time (remember about the special options which thankfully aren't used too much) and you can also list dependencies in setup.py, too.

there's the Pipfile initiative which gives me much hope, though :)

Are you talking about requirements.txt? Requirements.txt falls short of cargo or really any other mainstream language's dependency doc (no reproducible builds, for one thing -- effectively almost as bad as undocumented).

Mostly requirements.txt, yes. It's a standard and it has been a really long time I used a package where I didn't find one.

What you mean by no reproducible builds?

Requirements.txt + virtualenv, everything is fine.

Really, significantly easier to not screw up in a large org than bundler, because dependencies don't leak by default.

Actually, `bundle exec` is way easier to use than virtualenv.

(I hope I'm not misunderstanding your concern), but a quick search reveals that Rust prefers to statically link, so in this case, remacs would distribute as a 'single' binary. Only the developers (of remacs) would need all the dependencies/crates.

This creates its own headaches as a fix for the next Heartbleed becomes not "upgrade this one shared library", but "upgrade these dozens of individual programs when an update becomes available".

There has always been war b/t static vs dynamic linking. The debate will continue forever, but it doesn't really matter anymore. Each side understands and has solutions to its deficiencies.

Fwiw, lisps have a somewhat interesting third way: you distribute everything in a single image like a statically linked program. But, since that image includes the compiler, it can upgrade itself.

Or they include a loader and can load code, code which may be compiled somewhere else.

Programs all need to update all the time anyway.

language specific repositories worrying

What is the alternative? Every major Linux distro has its own repository, as do all the BSDs. The picture on Windows and macOS is even more convoluted. Are developers in all these languages supposed to support the packaging of their software in half a dozen different repositories?

Maybe all programmers should get together and build "one repository to rule them all"? I have no idea how we herd that many cats!

Nix(OS) is basically that... If only we could get upstream to start building with Nix

Ugh...no. I tried Nix until I found that all packages that depended on OpenSSL were broken on OS X. I checked for a bug report and found that one had been filed and sat open and unfixed for 18 months. Given that this bug makes Nix basically unusable on OS X, it seems like developers of Nix are uninterested in becoming anything resembling a universal package manager.

Meanwhile, cargo works flawlessly on every system I've tried (Linux, Mac and Windows). Sure, it only compiles Rust programs, but there's no way that I'd advocate moving those programs to a package manager with as little regard for such a large part of its potential userbase.

> Given that this bug makes Nix basically unusable on OS X, it seems like developers of Nix are uninterested in becoming anything resembling a universal package manager.

Or that they just don't have enough manpower to actually support all the platforms.

FPM is at least a step in the right direction to reduce the overhead of creating all of these.

At a minimum, Linux should have a common packaging system; though there may never be agreement. It's hard to see macOS and windows endingnup with a common one.

But maybe we could do a third party option that is independent of each OS? Those rarely work out well though.

And that is forgetting that are many more OSes out there than just those three.

Of course there are many more, but if you could build the one true package manager for all the major OSes, my guess is that the smaller ones would join the fray.

Not really, because it would meant that their semantics weren't accounted for.

As an example, IBM just released yesterday a new mainframe model.

z/OS is a totally different animal compared with POSIX based OSes or Windows, starting by the file system, catalog based.

Sounds like xkcd 927 ...

with python the rule should to be to run every deployment at least in its own venv.

That's not so practical if the application is a text editor, or some other administration tool (debugging, statistics etc).

I recently came across this: https://github.com/spotify/dh-virtualenv

For a system utility, you can still use virtualenvs. The launcher script just needs to use a shebang like:

    #!/usr/share/spiffyapp/venv/bin/python

My rule of thumb is to never install anything into system Python by pip, etc. If it's not an OS package, it belongs to a virtualenv.

I more or less have this rule, except I generally will use the --user flag to install things on a per-user basis if it's not being installed for a particular project.

It really does surprise me that languages come with their own package managers. In most linux contexts, there's really no need for it since linux distributions come with package managers.

Part of me feels like a better solution is to maintain older branches to give distributions opportunity to catch up.

> In most linux contexts, there's really no need for it since linux distributions come with package managers

This single sentences hints at least major two reasons for language-specific package managers:

- non-Linux platforms

- there's many different Linux package managers (apt, rpm, pacman, nix, portage, ...)

A language-specific package manager means developers (i.e. the ones writing the packages) only have do to packaging work once, instead of for every platform they might want to support, including ones that they have no way to test on (and a lot of code, especially in the modern wave of languages like Rust, often works on all platforms with no particular effort from the developer).

From an asymptotic perspective, using the platform package managers results in something like O(# libraries * # platforms) work and likely a lot of code not being packaged for some platforms, whereas language-specific package managers is something closer to O(# languages + # libraries) work (or maybe O(# languages * # platforms + # libraries). Looking at this decision purely in terms of developer effort, the latter seems like the better choice.

(There's also things like fpm that are designed to be more like O(# platforms + # libraries) work, which is nicer than either of the above!)

For anything but C, one can't really trust the distributions to care enough for that to be an option. You can install Common Lisp libraries from the Debian repositories, but if you do, you'll find yourself in a world of problems since they are mostly severely out of date, if they work at all.

Far too many times have I had to explain to newcomers to Common Lisp that they can't install stuff from the repositories, and instead have to download their CL implementation separately and then use Quicklisp.

This is a really great description of the benefits of this sort of thing. In a code base like Emacs, I could easily see where learning the guts could be very hard / daunting for a new-comer (I've never peeked under the hood for exactly this reason).

You all are scratching an itch, and increasing the general mindshare for Emacs. If Remacs runs out of steam, then the world has some extra people who grok Emacs guts. If Remacs fully succeeds in remaking Emacs, but better, then maybe Remacs just becomes Emacs.

> Disclosure: I am a contributor to this project

Thanks for posting this and thanks for your contributions.

It seems a bit rude to complain about volunteers for doing something they want to do rather than what you want them to do.

I imagine that this, for the most part, isn't even opportunity cost: the people working on it probably wouldn't be contributing to full Emacs (or the Guile effort) anyway. And this sort of effort seems like it could be an on-boarding experience to improving the original code base, e.g. in the process of porting, someone notices a bug and so submits a patch upstream, or maybe the repeated exposure to a variety of the internal components gives someone enough familiarity with them to contribute if this project peters out.

I intended it more as a friendly suggestion or observation than anything else. Looking at the Github README, I see a lot of enthusiasm for Emacs and Rust, but not much justification for the (tremendous) effort of a port. Losing site of the value produced in the end result seems like the kind of 'software engineer mistake' I've made myself (many times) in the past.

In any event, I think we would do volunteers a disservice if we placed them in a special class to which we could only provide positive feedback. (Maliciousness is never appropriate, of course.)

As an Emacs user one could see zero gain in this effort. But new languages like Rust do benefit (I believe) from this kind of projects: new libraries may be create for this port that could be useful for completely new applications. Also, it's more users/testers for Rust, which is always a good thing for their community.

Another thing is that having large-scale successful projects make Rust a more likely language for other people to choose when creating a new project themsleves.

"It's a neat language, but no one has used it to make anything that isn't a toy" is a really common mindset for the people who make such decisions.

The only way to change that mindset is for the evangelists to write software and show that yes, it is possible to write For Realsies software in that language. If that happens to be a rewrite of a successful project, fine - it's still a large project, and it'll inspire more development than someone coming out of nowhere with a project.

Rust has always had an advantage in this respect as it was being used to write servo. "Good enough for Mozilla to write a browser rendering engine" (I believe) helped a lot of people take it seriously early on and helped build the community.

Both are good points, but I think it's always good to remember the humans behind work, even if you don't think it's useful work. It's perfectly reasonable to be unconvinced of the value of a project, but that doesn't mean one needs to be entirely "stop energy" (to take a nice phrasing from a now dead comment).

Fortunately, your top level comment was taken in good faith by one of the contributors, but this won't always happen (and, especially in a space like editors, where everyone uses them and many people have unreasonably strong opinions, so people doing "unconventional" things may have a history of feeling attacked for their hobby) but not phrasing a comment as uncompromising criticism can encourage productive discussion (instead of randoms like me bringing up non-technical things like this whole subthread).

> one needs to be entirely "stop energy" (to take a nice phrasing from a now dead comment).

I'm sorry that comment got down modded. In fact, I think/hope I voted it up.

One of the interesting tensions this dialog has surfaced (at least for me) is the relationship between volunteerism and the way outsiders interact with the volunteer community. More than a few people effectively suggested my comment shouldn't have been made. While I do agree with the need to protect contributors from a lot of what they have to put up with, I'm not sure I'd ring fence those communities quite that securely.

Put another way, if my comment really does fall into a class of those that shouldn't have been made, what are the 'rules' for outsiders engaging open source (or other volunteer) communities?

> Fortunately, your top level comment was taken in good faith

Agreed. But after 30 years on the net, it still surprises me how many people just automatically default to whatever the 'bad faith' interpretation might be. We all read what we read in our own context, and this suggests to me that, for many of us, that context is rather angry and upset.

> this suggests to me that, for many of us, that context is rather angry and upset.

This doesn't even seem unreasonable to me: if every time my project was discussed it was met with scepticism and outright "why are you bothering to do this?", I would get fairly tired and, after the first few times, get fed up with putting in the emotional effort to see the positive nugget buried in the negative phrasing.

Someone taking 5 minutes to write a comment about a project they've just been made aware of is unlikely to have the context to know whether that project regularly gets these sort of comments ("I really meant it as a way to learn more about the project, please, authors, can you politely answer my rudely phrased question/criticism") and so they should be the ones putting in the effort of research and of starting the conversation on a good foot: questions about the points of scepticism (rather than blank statements) are a good start.

>It seems a bit rude to complain about volunteers for doing something they want to do rather than what you want them to do.

It is, a little, but then again it's par for the course for Open Source projects, which are both volunteer AND seeking to engage a larger community.

It's not like its just some people doing what they like and keeping it to themselves or just offering it as-is. Open Source projects that want to become larger communities and attract more developers AND end users, have to accept external opinion and criticism.

There's many different sorts of open source projects, I've been involved with projects that

- are mainly driven by paid contributors, with some volunteers

- some number of paid contributors with many volunteers

- have only volunteers

And they are open source:

- in order to engage a larger community of end users

- in order to engage a larger community of developers (doing things with people is often more fun, and/or having more people poking at keyboards allows more, say, of an experiment to be accomplished)

- to serve as a portfolio, e.g., for job seeking

- as a political position (some variation of "code should be open")

- out of habit/because there's no reason to not be open source

(Or some combination of the above.)

As far as I know, remacs is driven entirely by volunteers, but I don't know where it fits into the latter category. The original author has written blog post(s) about it, so clearly they want people to know about it, but it isn't obvious to me if they care particularly about people using the result for editing text rather than, say, investigating and showing off the solutions to problems encountered along the way (portfolio) or being able to collaborate on a fun project with people (community of developers).

In any case, I agree with you about projects accepting criticism, but I think the style of criticism needs to take into account the specifics of the project: something like, there should be less "this is a waste of effort"/"I think you should do something else" and more of the pure technical stuff ("algorithm ABC might be more efficient than the XYZ currently used, as ABC is O(n log n)", or something) as one moves further down either list.

This is one of the main issues of open source - people tend to work on what seems fun/interesting/rewarding. As a result a lot of people work on different implementations of the same things instead of coming up with one good solution and creating new things on top of it.

Moreover, while some people work on the endless clones of the same thing, the completely different set of contributors is wasting their time cleaning up / fixing bugs / writing documentation for those endless clones.

Examples are: a lot of Linux distros, which are almost the same but not one of them comes even close to MacOSX as a desktop OS. Javascript frameworks which solve the same rendering problem again and again.

On the other side, there is Spacemacs, which tries to provide solid modern IDE-like experience on top of existing Emacs solution, leaving low-level stuff to emacs core team.

This is not something intrinsic in the nature of open source, but in how humans like to spend their free time. Of course we could all be much more efficient if we all had the same goals, but that's not how things work in a free society.

As a society we win big by collaboration in the first place. Not by diversity, disagreeing with other people and doing everything "your way". Imagine 1000 independent people trying to build Boeing in an opensource way.

Labor has negative utility. You have to compensate if you want people do labor.

In a business setting, you pay people.

In a hobby setting like that, people compensate by having fun.

Either approach is compatible with producing open-source software; I suspect most LOC of open-source projects are written by salaried contributors at large corporations.

What a bizarre argument. 1,000+ independent people trying their hand in the business world is ultimately how a Boeing is conceived. That is the extreme diversity that benefits society.

I didn't quite get it. Do you mean that Boeing is built by independent people who work on whatever they want to and then a plane is assembled of that independently built parts and no one takes the responsibility of the result? Or you mean that Boeing is subcontracting particular work to independent firms serving as architect, coordinator, and sponsor and taking all the responsibility?

> "Do you mean that Boeing is built by independent people who work on whatever they want to and then a plane is assembled of that independently built parts and no one takes the responsibility of the result?"

Somewhere in the middle. If you consider the work that goes into making a plane, you'll see quite a bit of it happens outside Boeing. To give one example, think of the aluminium that goes into the plane. Boeing doesn't have to mine bauxite, extract the aluminium from the bauxite, transport it to the place where its sold, etc...

A classic example of this ground-up view was this example given by Milton Friedman about the pencil. I don't agree with many of his views, but I think he makes a good point in this video:

https://www.youtube.com/watch?v=R5Gppi-O3a8

EDIT: Turns out the source of this example may have been Leonard Read:

https://en.wikisource.org/wiki/I,_Pencil

Great video, thank you! Yes, most of the work is done outside of Boeing, but it is done specially for Boeing, not that people work on whatever sort of aluminum they want but they know Boeing demand and supply them with the particular sort. On the other side Boeing pay them money so they can proceed to mine. This is what I mean under the collaboration.

Glad you liked the video.

Regarding...

"On the other side Boeing pay them money so they can proceed to mine."

Perhaps you know more about Boeing's business arrangements than me, but I certainly couldn't verify that that's true. From what little I know, it's possible Boeing's aluminium suppliers work exclusively for Boeing, but it's also possible these same aluminium suppliers have multiple customers. The point being, there could be people who work as part of the chain to produce and transport the aluminium who have no idea who will eventually use it.

>> This is one of the main issues of open source - people tend to work on what seems fun/interesting/rewarding. As a result a lot of people work on different implementations of the same things instead of coming up with one good solution and creating new things on top of it.

You could say the same thing about commercial software (and other) development. They just call it competition. In business they claim it is efficient and drives innovation. In open source it's said to be inefficient and a waste of time.

I think it's incomplete analysis. I partly agree but what makes the Desktop Environment problem is more an issue of culture and education. People creating distro are implementing what they saw and it's often recent similar efforts. If people knew how OS2, Xerox, BeOS worked they'd have a different desires and goals.

> This is one of the main issues of open source - people tend to work on what seems fun/interesting/rewarding. As a result a lot of people work on different implementations of the same things instead of coming up with one good solution and creating new things on top of it.

Creating new things is better than sitting on a sofa watching TV or playing video games all day. Furthermore, it often opens the door to possible new, unforeseen use cases, concepts, and success. Open source has a natural evolutionary path. Survival of the fittest, rather than survival of the richest.

It wasn't a complaint, it was an honest observation.

Irrelevant.

Honesty doesn't keep it from being useless stop energy.

>the people working on it probably wouldn't be contributing to full Emacs

>in the process of porting, someone notices a bug and so submits a patch upstream

I find it a little bit controversial.

You probably meant conflicting.

But it's not: one might very plausibly not care to hack on C emacs, but care to hack on a Rust emacs.

And at the same time, the same person, might be able to spot a bug while porting C code to the Rust emacs, that will also help fix C-emacs.

These aren't in opposition: it's what I meant by "on-boarding".

If remacs didn't exist the hypothetical developer wouldn't be contributing to full Emacs (it never crossed their mind, or it's too intimidating, or whatever other reason), but through their work on remacs, they've also contributed to the original emacs. The point is that the latter contribution would never have happened without remacs.

I see no problem in anyone willing to toy with whatever he likes. I have a problem when huge efforts are invested by huge teams on huge projects which clearly have no purpose.

I mean, if you have a lot of energy to use and give, and you want to clone something huge, clone one the proprietary tools that have no free/open source equivalent yet in your domain or one of the domains where there are the most serious lacks of FOSS; or clone a web app into a real desktop program; or reverse engineer a proper open driver for whatever device you have which request a proprietary OS, a proprietary driver or a manufacturer specific tool; rewrite a library which only exists in Python or C# into a C or C-compatible library so that every language on Earth can wrap it, etc. Don't go cloning something that is already free multiplatform software just for the purpose of cloning.

We have never had so many people writing open-source programs, taking part in open-source projects, and yet it looks like the progress of open-source over proprietary (and its new form: services) is not what it was in the 90's and 2000's, it stalled, and it regresses in some areas. There has to be a problem somewhere.

> I have a problem when huge efforts are invested by huge teams on huge projects which clearly have no purpose.

This strikes me as a very entitled viewpoint. Why should people work on what you want them to work on? They could be watching TV or playing video games in their free time, but if they work on a project you don't think is valuable, it's somehow a problem?

STOP/ I just think that before judging remacs everyone had to read this blogpost: http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...

Thanks for posting this. I agree with one of the other commenters that this is probably the most informative comment on the thread. (And, to be honest, the kind of answer I was hoping to get to my initial post.)

Thanks for posting this.

This is probably the most informative comment of the whole thread.

gotta love this line:

"We aim to be a drop-in replacement with bug-for-bug compatibility."

That's the best policy when re-writing or fixing any legacy system. Shouldn't be surprising at all.

I believe remacs is already having some sort of positive impact, yet not a user visible that is true. But for decades emacs core was somehow a blackhole. Now it's been modeled in another very different language. That's very nice.

Also maybe it will help testing emacs, and even improving faster since rust typesystem is said to help refactoring tremendously.

We'll see.

I hope that the other side of forking is also being considered - forks have a draining effect on existing contributors and can potentially have a divisive effect on an existing community.

This looks like a lot of work for what amounts to very little end-user benefit.

The sons of Hermes love to play

And only do their best when they

Are told they oughtn't;

Apollo's children never shrink

From boring jobs but have to think

Their work important.

Brilliant. Thank you

I ought to site my source - W. H. Auden via http://www.paulgraham.com/quo.html

My initial thought was that if you want to rewrite emacs, why not rewrite it in common lisp? Apparently there are a few cl editors/ides - along the "original emacs" path - but like all things GNU I gather GNU Emacs is more than "just" (a) Free Emacs.

Now, there's a fairly recent (and active) project for implementing a common lisp in c++[clasp] -- perhaps making a real common lisp in rust would make sense?

[clasp] https://github.com/drmeister/clasp

It's touched on elsewhere in this thread, but one of the benefits of doing the port in the style of remacs is that one has a completely functional editor the whole time: things can get rewritten one small piece at a time because Rust and C have similar binary models. It's easy and fast to call from one language to the other, so one can rewrite a a single C function to Rust and have the rest of the C code call it, and that function call into the rest of the C code (and without any pervasive per-call-site expense).

I have no idea how feasible this is in any implementation of common lisp, but the mere fact the language (AFAIK) requires a runtime beyond the C runtime (garbage collector, etc.) suggests it may not be as easy as with Rust. If it's possible, maybe someone else could start a project attempting that, if they thought they'd enjoy it.

The idea would be:

* replace the GNU Emacs runtime written in C/Rust with one which is already provided by a Common Lisp implementation. Each Common Lisp implementation has its own runtime already, but those are not application specific to an editor. Several Common Lisp runtimes for example support multi-threaded Lisp code, native Lisp code, various GCs, support for more data types, better error handling, ... plus they support much of the basic Lisp stuff which is in the GNU Emacs runtime (evaluating code, loading code, ...)

* move some C/Rust code into Common Lisp, since Common Lisp compilers make it possible to write a wider range of code directly in Lisp.

* provide some low-level C code to Common Lisp via it's FFI. That way the C code does not need to be a part of the runtime.

But the topic is dead, because the expertise to do something like that is rare and the GNU Emacs community has no interest moving in this direction.

Because you want a core written in a safe, statically checked language?

> This looks like a lot of work for what amounts to very little end-user benefit.

Oh, but how wrong you are.

At London Emacs meetup Wilfred gave a talk about his motivations for this work. One of the big and most obvious benefits is this:

while porting some feature to Rust, he discovered a bug in Emacs, fixed it and got given commit access for his work.

You can read the transcript of his presentation here:

http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...

People work on what they want to, a lot of times without much regard for the user.

I don't know if it's a priority but it would be cool to see rendering speed improved.

That's an odd expectation to have. I would think rendering speed would stay the same or increase a bit; a lot of hand optimizations are going disappear.

Considering the age of Emacs's source code, I'd imagine there would be a lot of code that used to be optimal when it was written, but isn't any more (Sort of how replacing a lot of instances of Duff's Device in Xfree86 with memcpy has sped it up).

I agree. The attempt to port Emacs in Rust is honorable. However, I believe a successful port does not depend on a safe C backend. I am a long-term everday emacs user, and I didn't have a single segmentation fault in emacs in all those years. Actually, emacs is the most reliable PC software that I ever encountered. Code safety is not an issue at all here. Emacs is heavily based on Lisp which leaves almost no room for segmentation faults.

IMHO, a potentially successful Emacs ports depends on a new plugin system which supports code in other languages (Rust for instance) rather than elisp so that new developers get attracted who dislike Lisp. In other words, don't attempt to clone emacs but develop a completely new editor which uses the successful concepts of Emacs.

Unfortunately, plugins require dynamic code generation, and AFAIK only scripting languages like Lisp, Scheme and Python are able to do that. Emacs has that already. Emacs's plugin system has an unmatched simplicity and reliability, and that's likely the reason why any clone has a very hard time to compete.

For big rewrites, I like to see someone who's been burned by a failed rewrite at the helm. They'll be much more aware of the pros and cons, and at far less risk of underestimating the effort involved, or the value of working code.

That's part of why I made the comment I did. 15 years ago, I was starting a small little MicroISV. Rather than focus on the product, I focused on building a Scheme interpreter I was going to use to build the product. It was a lot of fun, and I learned a great deal that has stuck with me today. But it didn't result in a better product and it didn't result in a successful business.

(I'm not saying remacs is the same thing by any means, but the relationship between effort expended and the type of value realized is something I've become more attuned to the older I get. Maybe it's a mild mid-life crisis, but I'm pretty cognizant these days that there's an upper bound on the length of time we have available.)

Actually, I did raise an issue towards that direction.

https://github.com/Wilfred/remacs/issues/66

I mean why not do it properly if it's not an hostile fork.

But sadly, the lead-dev seems to have made up his mind. Being a nOOb with emacs I'm in a position to judge the reasons though.

A large part of Emacs is the Lisp source. It would be great to have another interpreter written in Rust that reads the same Lisp files.

What’s the breakout of C vs Elisp?

Ideally more of Emacs could be rewritten in Lisp with a smaller interpreter.

The last numbers I heard were from a few years ago, but on the order of 250KLOC of C and 1MLOC of Emacs Lisp. There's a lot there (and some of it gets fairly exotic around redisplay, unexec, etc.)

349,615 lines of C

1,632,280 lines of elisp

Also... I have dug the emacs sources for a while and i can testify that many times, function have two, three (sometimes more) actual implementations that gets actually built depending on configuration (example: sunos va dos vs linux vs win32 version of function foo).

So... Yeah. The c lines are in a way, "overcounted".

No... those lines still have to be maintained and kept in sync, otherwise you end up with bugs. So it's not over counting, because there is still work associated with these different implementations

>It would be great to have another interpreter written in Rust that reads the same Lisp files.

Agree, but then we would have a new case of Greenspun's 10th rule.

Absolutely agree. Focus on porting the core Linux daemons so we can get C out of the business of parsing remotely provided data.

Reply on news.ycombinator.com