13 ms·

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 o

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.

dbaupp 9y ago
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.
- nerdponx 9y ago
  It wasn't a complaint, it was an honest observation.
  - hammerandtongs 9y ago
    Irrelevant. Honesty doesn't keep it from being useless stop energy.
  - Aileen343 9y ago
    Im making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do... https://is.gd/qKRnJt https://is.gd/qKRnJt
- mschaef 9y ago
  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.)
  - pera 9y ago
    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.
    - omegaham 9y ago
      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.
      - rkangel 9y ago
        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.
  - dbaupp 9y ago
- achikin 9y ago
  >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.
  - coldtea 9y ago
    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.
  - dbaupp 9y ago
    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.
- achikin 9y ago
  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.
  - pera 9y ago
    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.
    - achikin 9y ago
      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.
      - always_good 9y ago
        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.
        achikin 9y ago
        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?
- coldtea 9y ago
  >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.
  - dbaupp 9y ago
    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.
- wott 9y ago
  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.
  - wtetzner 9y ago
    > 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?
melling 9y ago
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.
- mschaef 9y ago
  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.)
- sillysaurus3 9y ago
  349,615 lines of C 1,632,280 lines of elisp
  - znpy 9y ago
    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".
    - Ar-Curunir 9y ago
      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
- flavio81 9y ago
  >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.
DDSDev 9y ago
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
- peatmoss 9y ago
  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.
  - Jessica454 9y ago
    I get paid over $95 per hour working from home with 2 kids at home. I never thought I'd be able to do it but my best friend earns over 10k a month doing this and she convinced me to try. The potential with this is endless. Heres what I've been doing, •••••••••>>http://www.joinmate2.com http://www.joinmate2.com
- 9y ago
tangue 9y ago
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-transcript/ http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...
- znpy 9y ago
  Thanks for posting this. This is probably the most informative comment of the whole thread.
- bitdiddle 9y ago
  gotta love this line: "We aim to be a drop-in replacement with bug-for-bug compatibility."
  - copperx 9y ago
    That's the best policy when re-writing or fixing any legacy system. Shouldn't be surprising at all.
- mschaef 9y ago
  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.)
musha68k 9y ago
I don't know if it's a priority but it would be cool to see rendering speed improved.
- copperx 9y ago
  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.
  - FreeFull 9y ago
    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).
agumonkey 9y ago
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.
- dman 9y ago
  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.
barrkel 9y ago
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.
- mschaef 9y ago
  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.)
31h 9y ago
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.
- dotemacs 9y ago
  Brilliant. Thank you
  - 31h 9y ago
    I ought to site my source - W. H. Auden via http://www.paulgraham.com/quo.html http://www.paulgraham.com/quo.html
spullara 9y ago
Absolutely agree. Focus on porting the core Linux daemons so we can get C out of the business of parsing remotely provided data.
wocram 9y ago
People work on what they want to, a lot of times without much regard for the user.
e12e 9y ago
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 https://github.com/drmeister/clasp
- nine_k 9y ago
  Because you want a core written in a safe, statically checked language?
- dbaupp 9y ago
  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.
  - lispm 9y ago
    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.
dotemacs 9y ago
> 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-transcript/ http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...
abhi18av 9y ago
Actually, I did raise an issue towards that direction. https://github.com/Wilfred/remacs/issues/66 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.
progman 9y ago
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.

dbaupp 9y ago

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.

nerdponx 9y ago
It wasn't a complaint, it was an honest observation.
- hammerandtongs 9y ago
  Irrelevant. Honesty doesn't keep it from being useless stop energy.
- Aileen343 9y ago
  Im making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do... https://is.gd/qKRnJt https://is.gd/qKRnJt
mschaef 9y ago
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.)
- pera 9y ago
  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.
  - omegaham 9y ago
    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.
    - rkangel 9y ago
      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.
- dbaupp 9y ago
achikin 9y ago
>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.
- coldtea 9y ago
  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.
- dbaupp 9y ago
  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.
achikin 9y ago
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.
- pera 9y ago
  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.
  - achikin 9y ago
    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.
    - always_good 9y ago
      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.
      - achikin 9y ago
        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?
coldtea 9y ago
>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.
- dbaupp 9y ago
  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.
wott 9y ago
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.
- wtetzner 9y ago
  > 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?

melling 9y ago

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.

mschaef 9y ago
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.)
sillysaurus3 9y ago
349,615 lines of C 1,632,280 lines of elisp
- znpy 9y ago
  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".
  - Ar-Curunir 9y ago
    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
flavio81 9y ago
>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.

DDSDev 9y ago

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

peatmoss 9y ago
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.
- Jessica454 9y ago
  I get paid over $95 per hour working from home with 2 kids at home. I never thought I'd be able to do it but my best friend earns over 10k a month doing this and she convinced me to try. The potential with this is endless. Heres what I've been doing, •••••••••>>http://www.joinmate2.com http://www.joinmate2.com
9y ago

tangue 9y ago

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-transcript/ http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...

znpy 9y ago
Thanks for posting this. This is probably the most informative comment of the whole thread.
bitdiddle 9y ago
gotta love this line: "We aim to be a drop-in replacement with bug-for-bug compatibility."
- copperx 9y ago
  That's the best policy when re-writing or fixing any legacy system. Shouldn't be surprising at all.
mschaef 9y ago
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.)

musha68k 9y ago

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

copperx 9y ago
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.
- FreeFull 9y ago
  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).

agumonkey 9y ago

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.

dman 9y ago
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.

barrkel 9y ago

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.

mschaef 9y ago
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.)

31h 9y ago

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.

dotemacs 9y ago
Brilliant. Thank you
- 31h 9y ago
  I ought to site my source - W. H. Auden via http://www.paulgraham.com/quo.html http://www.paulgraham.com/quo.html

spullara 9y ago

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

wocram 9y ago

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

e12e 9y ago

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 https://github.com/drmeister/clasp

nine_k 9y ago
Because you want a core written in a safe, statically checked language?
dbaupp 9y ago
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.
- lispm 9y ago
  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.

dotemacs 9y ago

> 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-transcript/ http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...

abhi18av 9y ago

Actually, I did raise an issue towards that direction. https://github.com/Wilfred/remacs/issues/66 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.

progman 9y ago

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.