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.
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.
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.
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.
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'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).
(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.
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!
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.
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.
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.
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:
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.
"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.
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?
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.)
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.
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.
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?
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.
* 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.
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.)
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.)
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
Not intended to be a port, but I occasionally search for an editor that is customizable in Python to the extent Emacs is.
Leo Editor (http://leoeditor.com) fits that bill. It's been around since the 90's (and the web page looks like it's from the 90's). Even though it has many users, the documentation is quite poor. If I had another life to live, I would learn it well and improve the docs - and then port over everything I like in Emacs to it.
It is sorely in need of more tutorials. You'll find some in various people's blog posts, but not enough. I know enough of it to know that it is very powerful, but not enough to use it well day-to-day.
This is an interesting project and I wish them well. I have no opinion on Rust at the moment, but I do see this as part of a general trend towards safer languages.
Interesting - I wonder what dependency they could have that prevents its use on MacOS. I run it on both Linux and Windows just fine. At the end of the day, it's just a Python program.
>Sublime uses a Python API, though the docs are also not extensive
But how extensible is Sublime itself? For example, in Emacs I can do network connections (e.g. Gnus). Will Sublime allow this? Can I make a Tetris clone in Sublime? Both are doable in Leo.
AFAIK Sublime gives you a full Python, including network access. The problem is that you're limited to a few predefined hooks where you can integrate into Sublime's UI, so good luck making it do something that doesn't boil down to editing text.
Is Sublime itself written in Python? Or is it mostly C++ with some Python hooks? If the latter, it'll be quite limited.
Leo is all Python, and you have access to all the internals. I'm sure there are design decisions in Leo that will make changing some aspects hard, though.
I too have done a similar search and generally failed. I found Leo too when looking for a new editor - it's great but somewhat tied to the outliner model IIRC?
Looks promising. First neovim and now this. Even if it doesn't replace emacs (which it won't) if it can enrich the community and maybe bring more users while fixing archaic code bases of hard to find errors and UBs then it is still a win. Neovim pushed vim (Vim suddenly became more active around the time neovim gained traction atleast according to github graphs and releases). So I hope this project brings new life to the core C code in emacs and fixes the problems that it never had (according to the core dev knowledge). When I tried emacs I found it to be a bit like atom at startups. Couldn't get into the keybindings coming from vim.
If it gets faster, I might give it a try again (in evil ofcourse, gotta have them keys).
> Even if it doesn't replace emacs (which it won't)
I dunno. First of all it wants to replace the C-bits of Emacs, not all that is in elisp land. Second of all, why not? I do not think the goals of Remacs are overly ambitious: port the C-platform under Emacs's elisp env to Rust. This will probably result in a much healthier and hackable codebase for that functionality, as it: is a more modern language, has less legacy (platforms) to support, is fully open source (Rust) to the level RMS would approve of.
The README doesn't say much about whether and how the rewrite would differ from the main Emacs implementation in terms of threading architecture. A major problem (I think this is an uncontroversial statement) with the main Emacs implementation is that it is fairly common, in every day use, to block the main thread responsible for accepting keyboard input and repainting the screen etc. This (again, uncontroversial I think) is embarrassing in such an otherwise great bit of software in 2017.
As one poster here said, "Makes sense. Rust is systems language and emacs is an OS replacement."
If anything, it could be great if Rust is used to implement a faster Emacs Lisp compiler/interpreter, thus preserving all of Emacs Lisp source (and saving some implementation time.)
And make it fully multitasking so there are no more problems of key input getting stuck because of a process.
As I understand it, it's not lack of trust, but rather that if a legal dispute occurs, it's easier if only one party is the copyright holder rather than having to find hundreds of developers scattered around the world.
So you'll wait until the FSF finds it cannot defend the GPL in court and then try to get copyright assignments from thousands of programmers? That's downright stupid.
If there was evidence that some third party could enforce GPL compliance on behalf of the copyright holder(s) then maybe the FSF should consider relaxing the requirements.
Do you recall that Sony failed to comply with the GPL when they used LAME? The LAME community wasn't prepared to actually do anything about it. That's the kind of shit that would happen, especially to smaller projects. There are big companies out there that want to use your hard work without compensation and shit all over the GPL. Never forget that.
It's just a snail mail of a single page once and for all. If it helps FSF and GNU, that's no big deal for me. I compiled the form and sent it to US from Turkey, and all it took me was about 5 Lira's and a walk to the post office.
Missing out? I believe anybody who won't bother to compile and send the paperwork does not care enough to contribute good code anyways. There is a working, functional, and pleasing system for those who do actual work, why should a project like emacs (or any other open source project, really) chase the newest fad bargaining the layman's attention and his two lines of patch? What arrogance people show in trying to bend every project to their liking, and going as far as threathening to not do the contributions that they already aren't doing... Good god.
Some speculatively useful things that could arise out of this -
It may have useful security properties over time. People use emacs for a great deal of arbitrary text reading and transform from things directly from email and the web. Elisp would largely be at fault for security bugs but perhaps this would help in areas.
Perhaps a binding to use Alacritty directly for a port to Wayland? Emacs has a pretty terminal centric view of its UI output as is.
A tight binding to Servo allowing a serious upgrade to Emacs visual and ui capabilities.
Most security holes in my setup aren't likely to go away. I trust Emacs. And I trust it to do as I say. This means coordination my identity to many servers at a time. Executing directly on the box. Even remote boxes.
I'm open to be surprised. But I really do want Emacs to have full access to my computer.
One of the cool things about Rust is that it's compatible with C. You can rewrite individual C functions in Rust, compile both halves of the program and link them together into your executable. This lets you incrementally move from a pure-C program to a hybrid, to a pure-Rust program over time.
Also, 90+% of Emacs is written in Lisp which doesn't need to be ported at all.
I just built it, and it's fully functional. It'll be a perfect replacement for Emacs at every stage of the port, which is really cool.
The most (debatably) useful thing they could do is write the LISP in Rust. That might have some use. As it is, this project just creates an Emacs with more dependencies.
No, rewriting all of that Lisp code would be impossible. It's also unnecessary. The primary advantage of Rust is safety; the compiler ensures that either your code follows the rules or that it doesn't compile at all. The Lisp code, on the other hand, already has that safety. No manipulation of conses or vectors or other lisp data structures will ever result in a buffer overflow, or a null-pointer dereference, or in doubly-freed memory, or any of a hundred other of C's pitfalls. On top of that, Lisp is extremely fast to write, test, and debug.
But of course, that safety only exists to the extent that the Lisp interpreter/compiler is bug-free. The C side of Emacs's code base is alternatively great and terrible, depending on how you look at it. On the one hand, 30 years of continuous development has resulted in code that works really well. On the other hand, it is very hard to extend this code to support new features (good multi-threading support has been in the works for ages, moving to lexical scoping and away from dynamic scoping has taken years, etc). This is because it's difficult to maintain quality and compatibility while also navigating such an old project.
Once enough of this old C code is rewritten in Rust, it'll be possible to leverage the memory safety features (and the type system) of Rust to innovate much more quickly. Not as quickly as you can innovate on code that's written in Lisp, but much more quickly than you can innovate on the C code.
Besides, the number of libraries that a program uses is only a detriment if it means that the developers have to spend more time installing and maintaining those libraries. Cargo makes this comparatively painless.
>> No, rewriting all of that Lisp code would be impossible.
I thought the lisp was written in C and so moving it to Rust would be useful. Perhaps it's written in itself. If that's the case then my bad. I did not mean rewrite the list parts in rust.
I am unclear about what you mean by this? The lisp in emacs is elisp ([0] emacs lisp). More generally, Lisp is the name given to a class of languages including Guile, Racket, Scheme, Common Lisp that generally feature homomorphism, functional style and parentheses to enable the homomorphism.
The LISP interpreter is written in C. I was trying to suggest that it may be useful to rewrite that in Rust. That is a necessary step in getting rid of the C dependencies for emacs.
Question to the devs: are you planning on redoing how the gui subsystem works, to work with (for example) the gtk event loop? I've always wanted to try to put a qt frontend on emacs, but have always been horrified away by that subsystem.
I'd like to see a community-driven port of Sublime Text to Rust, with a basic ST3 like cross-platform UI, and offering a base set of UI primitives (buttons, panels, dropdown, inline styled annotations, etc) available for plugins, and first class support for JS plugins/extensions.
How hard would it be for the existing developers of CEmacs to get on board with Rust if they decided to make this the upstream core? I did not study Rust ever but did follow its evolution, and the language seems complicated to me, compared to c.
Emacs is relatively pervasive. It runs everywhere, including plenty of platforms that Rust does not support. Either due to current support priorities or lack of LLVM support.
That makes it something less than a drop-in replacement from the overall CEmacs project perspective. I'm sure Rust devs are working on more platform support, and it's possible Emacs devs are open to simply dropping some of the more obscure targets, but it might be a long time before alignment happens on that requirement alone.
This is only topic-adjacent, but here is my number one emacs wish: for the GTK frontend to be pure GTK with no X, so that it can be run directly as a Wayland client.
Prediction: within a year this project will be dead due to the lack of uptake. It doesn't solve any real problems and uses a relatively obscure programming language. There's no way it will ever reach anything close to a critical mass.
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.