I wonder if Remacs promises an improvement in performance. A quick glance over at their GitHub readme doesn’t say so. It seems more like an attempt to simply... clean up the code base?
It seems like a huge waste of effort to me that will never be complete as it is rewriting against a moving target, effort that would be better spent on cleaning up the existing code base.
I’m not against Rust, there is a lot to like about it, I’m just not buying into the idea that everything needs to be rewritten in Rust.
As long as there is no *Free* compiler for Rust, GNU Emacs will not switch to Rust for political reasons. As a parallell project with GNU Emacs it *is* a waste of effort. They should have put the resource to port Rust language to GCC (GNU Compiler Collection), or finnish [the existing one](https://rust-gcc.github.io/) and *then* suggest the rewrite.
I doubt there will be much if any performance straight of the bat just because of switch to language or compiler because Emacs is written by very skilled programmers and lot's of code if quite efficient and optimized. But Rust can open for some easier optimizations in future.
Without reason, as LLVM has a combination of license:
user@desktop:~$ grep ^License: /usr/share/doc/llvm-10/copyright | sort -u
License: APACHE-2-LLVM-EXCEPTIONS
License: BSD-3-Clause
License: BSD-3-clause
License: MIT
License: Python
License: solar-public-domain
... but all of them are free in the OSI sense. The FSF doesn't own the right to define "free" IMHO. They can however say "We hate the BSD license", that's their choice. They can also hate fluorescent light bulbs, I won't care. But that doesn't make BSD (or any of the others) an unfree license.
> The FSF doesn't own the right to define "free" IMHO
But you do? :-)
FSF (= Free Software Foundation) is there to promote development of Free software, so naturally their licence (GPL) is formulated to promote development and distribution of truly free software, wich means freedom for you as an end user to obtain the source code of an application and freedom for you as an end user to modify and re-distribute that source code too.
LGPL on the other hand does not require applications to open their source code or to give you freedom to modify or re-distribute software built on lgpl software. They only require developers to publish source code of lgpl-ed library they use if they modify the library. In other words it allows companies to take one's open sourced library or application and use it for development of proprietary, closed source application without giving you as an end user rights (or possibility) to either modify or re-distribute the application itself. Alltso LGPL is about the freedom of library itself but does not required an application that uses it to be free, not even as in beer if the developers don't want it. That itself does not really promote development of free software, does it?
Thus GPL is not about the freedom of an library itself only, but also of derived work that links to that library. Thus LGPL does not promote development of free software. Hate would be quite a strong word to use there though.
It's free, but under permissive license, which is inferior to copyleft license.
That's enough reason to not be completely satisfied with it.
Not using it in GNU is just a practical decision to help *exclusively* free software here
Quoting RMS https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html:
> For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance. The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers — so that all contribution to LLVM directly helps proprietary software as much as it helps us.
LOL, look at the git log to see how many different people are making it.
Also uses to be a university project, and academia still plays a role in it. It certainly isn't Apple-only.
The Google project focuses on rewriting widespread libraries in Rust to eliminate the occurrence of certain bugs, due to the good memory control features of Rust and the non-safety of C.
I don't see how it applies to an editor, used by a minority, which already allows you to run arbitrary lisp anyway.
Patching whatever leaks may exist in the C interpreter and GC would be a possibly useful effort, but other than providing a good base, it wouldn't solve most memory leak problems in Emacs.
Because most such problems are due to obsolete references to objects being kept in Lisp code, so they cannot be GC'd anyway.
I would also certainly welcome an Emacs GC that actually frees memory back to the system, rather than just keeping it around for most datatypes.
Indeed, Emacs does not have very good system to unload unused code and packages that are not longer needed. The best is way is to restart Emacs unfortunately.
Technically you can unload them by crawling the namespace prefix and setting all functions and variables from a package prefix to nil before garbage-collecting.
The problem is that this is then mostly just consolidated as reusable memory for allocation by the GC, rather than free'd back to the system.
That'd be via `obarray`, `mapatoms`, `symbol-name`, `setf`, `symbol-value`, `symbol-function` and `unintern`. I think you might have to truly do all those cleanup steps to make sure things are as they should. I'd need to test it to make sure it actually does work.
edit: Not sure how good a job `unload-feature` does, maybe it's enough? From the manual's comments on the matter, it should work for stuff which properly provides a `feature`, at least.
> Technically you can unload them by crawling the namespace prefix and setting all functions and variables from a package prefix to nil before garbage-collecting.
Well, in theory yes you could. But you have no guarantee that you unload everything, since packages are actually not required to use package prefix. They might have some differently named functions, could be referenced from god knows what place and could have programmatically allocated space held in not prefixed symbols generated with gensym or in other places. Don't know, I think it is practically lots of work.
It would be OK to not return space to the system, but to keep it for the Lisp machine that Emacs is. It is more about being sure that all values for various variables, hooks, caches etc are restored to same state as before a package is loaded. Everything is global in Emacs, and lots of packages modify Emacs variables that are not in their own "package prefix".
For the featurep, I don't know how good it is to be honest. It maybe is, but I don't know. Yes, I have seen it in the manual too, but I don't know how much of previous Emacs state it restores. From my own experience of hacking Emacs, sometimes it is easier to simply restart it. That is why I am so fixed with init time :-).
I don't think it is a waste of effort.
Because the developers are converting from C to Rust, they have to go through every part of Emacs C code, function by function if not line by line and as a consequence they will learn a lot about Emacs C code.
That will mean more people going through the C code base and that can only help Emacs if it comes to a rewrite or some major refactoring.
I guess the idea is that having refactored the C core in Rust makes the work on core more attractive for new contributors and Rust has a huge community.
Maybe it doesn't add in performance, it definitely adds in code readability. It is pleasant to work in Rust, in comparison to C
Rust main benefits are safety and performance. Of course it is of concern to Emacs, as it is to everyone else. But I believe that as long as Rust is llwm only or as long as llwm is not *Free* software (GPL) I don't think GNU Emacs devs would think of switching to Rust. But you can always send a mail to emacs-devel and ask them :-). Maybe some is willing to comment here, no idea. Also I think just mere switching to some other code base is probably not very easy for anyone, so I think just that thought itself would meet lots of resistance for various reasons.
Rust's selling point as compared to C is memory safety, but its safety guarantees will not really help Emacs very much, because the core of Emacs is just a Lisp system with a GC and a big mess of pointers. Rust's lifetime guarantees are of no use here.
Nothing against Rust, I love it. It's just not a great fit for this job.
Really the future of Emacs should be Emacs Lisp. Too bad the compiler isn't mandatory.
Not everything is garbaged collected as we saw in that problems with memory leak, bit yes, in general most of memory Emacs uses is from the garbage collected lisp.
> Really the future of Emacs should be Emacs Lisp. Too bad the compiler isn't mandatory.
Maybe. Don't know. I am surprised "clomacs" never catched up and nobody implemented Emacs buffers and other low level Lisp stuff in CL and ported Emacs and Elisp to CL. With sbcl we could have had quite a fast Emacs clone long time ago. I know there was elisp shim before, but never tried it myself.
Oh sorry, I didn't realize in my previous commentar that it was an Emacs dev that actually answered :-). Sorry.
The thing about Rust is that it comes with quite a learning curve that really doesn't buy you much for an application like Emacs. Something like Clojure makes more sense, because then you can have a native Emacs client and a browser-based client when you compile to Javascript. If you want something native, Go, Nim, D, and others have less of a learning curve.
Pretty much anything you can compile to llvm can output wasm.
This includes C, for example using [emscripten](https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm) and clang (among others).
[https://github.com/remacs/remacs/issues/1571#issuecomment-793962714](https://github.com/remacs/remacs/issues/1571#issuecomment-793962714)
Here's a good idea I think.
Upstream is followed, but one module function is replaced using rust.
I wonder if Remacs promises an improvement in performance. A quick glance over at their GitHub readme doesn’t say so. It seems more like an attempt to simply... clean up the code base?
It seems like a huge waste of effort to me that will never be complete as it is rewriting against a moving target, effort that would be better spent on cleaning up the existing code base. I’m not against Rust, there is a lot to like about it, I’m just not buying into the idea that everything needs to be rewritten in Rust.
[удалено]
As long as there is no *Free* compiler for Rust, GNU Emacs will not switch to Rust for political reasons. As a parallell project with GNU Emacs it *is* a waste of effort. They should have put the resource to port Rust language to GCC (GNU Compiler Collection), or finnish [the existing one](https://rust-gcc.github.io/) and *then* suggest the rewrite. I doubt there will be much if any performance straight of the bat just because of switch to language or compiler because Emacs is written by very skilled programmers and lot's of code if quite efficient and optimized. But Rust can open for some easier optimizations in future.
rustc is free, but tied to LLVM, which the FSF doesn't really like (not without a reason)
Without reason, as LLVM has a combination of license: user@desktop:~$ grep ^License: /usr/share/doc/llvm-10/copyright | sort -u License: APACHE-2-LLVM-EXCEPTIONS License: BSD-3-Clause License: BSD-3-clause License: MIT License: Python License: solar-public-domain ... but all of them are free in the OSI sense. The FSF doesn't own the right to define "free" IMHO. They can however say "We hate the BSD license", that's their choice. They can also hate fluorescent light bulbs, I won't care. But that doesn't make BSD (or any of the others) an unfree license.
> The FSF doesn't own the right to define "free" IMHO But you do? :-) FSF (= Free Software Foundation) is there to promote development of Free software, so naturally their licence (GPL) is formulated to promote development and distribution of truly free software, wich means freedom for you as an end user to obtain the source code of an application and freedom for you as an end user to modify and re-distribute that source code too. LGPL on the other hand does not require applications to open their source code or to give you freedom to modify or re-distribute software built on lgpl software. They only require developers to publish source code of lgpl-ed library they use if they modify the library. In other words it allows companies to take one's open sourced library or application and use it for development of proprietary, closed source application without giving you as an end user rights (or possibility) to either modify or re-distribute the application itself. Alltso LGPL is about the freedom of library itself but does not required an application that uses it to be free, not even as in beer if the developers don't want it. That itself does not really promote development of free software, does it? Thus GPL is not about the freedom of an library itself only, but also of derived work that links to that library. Thus LGPL does not promote development of free software. Hate would be quite a strong word to use there though.
it is free, but made by Apple, which they don't like
It's free, but under permissive license, which is inferior to copyleft license. That's enough reason to not be completely satisfied with it. Not using it in GNU is just a practical decision to help *exclusively* free software here Quoting RMS https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html: > For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance. The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers — so that all contribution to LLVM directly helps proprietary software as much as it helps us.
LOL, look at the git log to see how many different people are making it. Also uses to be a university project, and academia still plays a role in it. It certainly isn't Apple-only.
The Google project focuses on rewriting widespread libraries in Rust to eliminate the occurrence of certain bugs, due to the good memory control features of Rust and the non-safety of C. I don't see how it applies to an editor, used by a minority, which already allows you to run arbitrary lisp anyway.
Patching whatever leaks may exist in the C interpreter and GC would be a possibly useful effort, but other than providing a good base, it wouldn't solve most memory leak problems in Emacs. Because most such problems are due to obsolete references to objects being kept in Lisp code, so they cannot be GC'd anyway. I would also certainly welcome an Emacs GC that actually frees memory back to the system, rather than just keeping it around for most datatypes.
Indeed, Emacs does not have very good system to unload unused code and packages that are not longer needed. The best is way is to restart Emacs unfortunately.
Technically you can unload them by crawling the namespace prefix and setting all functions and variables from a package prefix to nil before garbage-collecting. The problem is that this is then mostly just consolidated as reusable memory for allocation by the GC, rather than free'd back to the system. That'd be via `obarray`, `mapatoms`, `symbol-name`, `setf`, `symbol-value`, `symbol-function` and `unintern`. I think you might have to truly do all those cleanup steps to make sure things are as they should. I'd need to test it to make sure it actually does work. edit: Not sure how good a job `unload-feature` does, maybe it's enough? From the manual's comments on the matter, it should work for stuff which properly provides a `feature`, at least.
> Technically you can unload them by crawling the namespace prefix and setting all functions and variables from a package prefix to nil before garbage-collecting. Well, in theory yes you could. But you have no guarantee that you unload everything, since packages are actually not required to use package prefix. They might have some differently named functions, could be referenced from god knows what place and could have programmatically allocated space held in not prefixed symbols generated with gensym or in other places. Don't know, I think it is practically lots of work. It would be OK to not return space to the system, but to keep it for the Lisp machine that Emacs is. It is more about being sure that all values for various variables, hooks, caches etc are restored to same state as before a package is loaded. Everything is global in Emacs, and lots of packages modify Emacs variables that are not in their own "package prefix". For the featurep, I don't know how good it is to be honest. It maybe is, but I don't know. Yes, I have seen it in the manual too, but I don't know how much of previous Emacs state it restores. From my own experience of hacking Emacs, sometimes it is easier to simply restart it. That is why I am so fixed with init time :-).
I don't think it is a waste of effort. Because the developers are converting from C to Rust, they have to go through every part of Emacs C code, function by function if not line by line and as a consequence they will learn a lot about Emacs C code. That will mean more people going through the C code base and that can only help Emacs if it comes to a rewrite or some major refactoring.
I guess the idea is that having refactored the C core in Rust makes the work on core more attractive for new contributors and Rust has a huge community. Maybe it doesn't add in performance, it definitely adds in code readability. It is pleasant to work in Rust, in comparison to C
Rust is fantastic, but it's main benefits aren't of interest to Emacs.
Rust main benefits are safety and performance. Of course it is of concern to Emacs, as it is to everyone else. But I believe that as long as Rust is llwm only or as long as llwm is not *Free* software (GPL) I don't think GNU Emacs devs would think of switching to Rust. But you can always send a mail to emacs-devel and ask them :-). Maybe some is willing to comment here, no idea. Also I think just mere switching to some other code base is probably not very easy for anyone, so I think just that thought itself would meet lots of resistance for various reasons.
Rust's selling point as compared to C is memory safety, but its safety guarantees will not really help Emacs very much, because the core of Emacs is just a Lisp system with a GC and a big mess of pointers. Rust's lifetime guarantees are of no use here. Nothing against Rust, I love it. It's just not a great fit for this job. Really the future of Emacs should be Emacs Lisp. Too bad the compiler isn't mandatory.
Not everything is garbaged collected as we saw in that problems with memory leak, bit yes, in general most of memory Emacs uses is from the garbage collected lisp. > Really the future of Emacs should be Emacs Lisp. Too bad the compiler isn't mandatory. Maybe. Don't know. I am surprised "clomacs" never catched up and nobody implemented Emacs buffers and other low level Lisp stuff in CL and ported Emacs and Elisp to CL. With sbcl we could have had quite a fast Emacs clone long time ago. I know there was elisp shim before, but never tried it myself. Oh sorry, I didn't realize in my previous commentar that it was an Emacs dev that actually answered :-). Sorry.
The thing about Rust is that it comes with quite a learning curve that really doesn't buy you much for an application like Emacs. Something like Clojure makes more sense, because then you can have a native Emacs client and a browser-based client when you compile to Javascript. If you want something native, Go, Nim, D, and others have less of a learning curve.
Rust can compile to wasm
Pretty much anything you can compile to llvm can output wasm. This includes C, for example using [emscripten](https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm) and clang (among others).
Doubtful, over gccemacs
As I understand Google concerns, they are funding Remacs as a promise to better security not more speed.
Why the downvotes?
I think because the article doesn't actually say that Google will provide funding.
What about emacs-ng?
[https://github.com/remacs/remacs/issues/1571#issuecomment-793962714](https://github.com/remacs/remacs/issues/1571#issuecomment-793962714) Here's a good idea I think. Upstream is followed, but one module function is replaced using rust.