9 ms·

The Emacs community, like the Lisp community with which it overlaps, is very conservative, in the sense that it doesn't throw things away quickly or make huge c

The Emacs community, like the Lisp community with which it overlaps, is very conservative, in the sense that it doesn't throw things away quickly or make huge changes lightly. For that reason, I'd be very surprised if this took off — even though it sounds like it would be mostly backwards-compatible. I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more layers of abstraction to understand and maintain, and splitting the extensions between Emacs Lisp and JavaScript. I'm also not convinced that a significant part of the community really wants this.

anthk 6y ago
If any, having Elisp support on Guile would have far more sense, and with a JIT and non-blocking IO Emacs would be usable enough even under a high subprocess load (cough, GNUs). I am not an Emacs user but I like Scheme (scm user here) under nvi, and a lot of people could profit from a Modern Guile based Emacs environment.
- admax88q 6y ago
  I'm not sure. Guile-Emacs has been talked about for ages but never materialized. Scheme is nice and all from a language purity sense, but emacs lisp just feels so very practical for its use case.
  - anthk 6y ago
    I meant Guile supporting Elisp, it already supports a few more languages than Scheme.
- jpfr 6y ago
  There is branch for elisp support in guile. https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-elisp https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-elisp It works in principle but is slow due to some impedance mismatches that have to be bridged. Especially, Emacs has a special string format internally that is not native utf-8. Andy Wingo is making a great job with JIT-support for Guile. We have to see whether emacs-guile can become fast enough to replace native-elisp. At this time it doesn't look like it...
dleslie 6y ago
And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.
- cle 6y ago
  While technically true, you can still improve performance of existing Elisp code by redefining certain commonly-used Elisp functions perform better in Deno. Sure the Elisp bytecode itself doesn't evaluate faster, but that distinction isn't really important here. The end-to-end perf of certain functions can be improved in a backwards-compatible way.
  - deleted 6y ago
    [deleted]
  - dleslie 6y ago
    If we're entertaining writing elisp methods in a faster language to improve overall performance, then it's already been done and being done via writing methods in C. I don't see the point of polluting Emacs with Javascript.
    - cle 6y ago
      Instructing users who want high-performance code in Emacs to write their code in C and rebuild their Emacs binary, or figure out how to make it a dynamic module, is about the most user-hostile way I can imagine to improve Emacs performance.
janoc 6y ago
Well, basically this is someone trying to implement VSCode in Emacs ... Ain't gonna get far once the main developer loses interest in the project. Emacs users use Emacs because they want Lisp and don't care about web rendering and javascript runtimes ... Oh yeah and Rust is thrown in too for good measure. Good 90% of Emacs code is in the extensions which are in Lisp and nobody is going to rewrite them to Javascript even if the code was running 50x faster.
- usbline 6y ago
  Rust isn't "thrown in", it's what Deno is built with.
  - otabdeveloper4 6y ago
    No, Deno is built with V8, and V8 is written in C++.
    - bitwize 6y ago
      V8 is the only C++ component of Deno. The other bits of the runtime are written in Rust, and Rust is the native extension language.
      - otabdeveloper4 6y ago
        The "other bits" are the ones that don't matter. It's like saying that a browser skin is "built on Rust" when inside it's still Webkit and Chromium.
- singingfish 6y ago
  Nah I don't use emacs cos I want lisp. I use it because it was the only thing that made any sense at all on the HP-UX machines I got access to back in 1993. A side effect of that is that emacs does everything I need (with a little bit of pandoc on the side), and I haven't had to learn anything new since.
soamv 6y ago
It's true that they're conservative, but there have been non-trivial forks in its history. If a fork proves itself by doing something significant that the original can't or won't, things can get interesting! I wouldn't write this one off so quickly.
bitwize 6y ago
> I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more layers of abstraction to understand and maintain, and splitting the extensions between Emacs Lisp and JavaScript. I'm also not convinced that a significant part of the community really wants this. I'm reminded of when an old C hand tells me that Rust will never replace C because it's too complex, brittle, and frustrating for the kinds of applications C programmers use C for. I always tell them: Rust isn't aimed at you -- it's aimed at your replacement. The Emacs-ng team doesn't have to convince the Emacs community -- they only have to convince their replacements. Much of computing in the very near future will be built on two languages: Rust and JavaScript. By basing Emacs-ng on those two languages, they just opened Emacs up to extension and hacking by a huge community who have no interest in touching Emacs's ancient, doddering Lisp nor its C underpinnings (C being, inherently, unsafe at any speed to work in). So ugly as it is, from a social standpoint it's absolutely the right approach and may well overtake GNU Emacs in terms of ecosystem size and vibrancy by the late 2020s.
- celeritascelery 6y ago
  > Much of computing in the very near future will be built on two languages: Rust and JavaScript. It will be interesting to see if this prediction pans out. There have been similar predictions about C++, Java, TCL, php, Perl, etc. it seems “the one true language” never emerges, but it is just around the corner. Though I really hope the future is more polyglot, because that is just way more fun.
  - bitwize 6y ago
    > Though I really hope the future is more polyglot, because that is just way more fun. I hope so too, but... I've worked with people who really don't want to touch anything besides JavaScript. Such people could be coaxed to use Rust to write kernel drivers and the like, due to its safety guarantees -- but not C, nor C++. JavaScript is in everything. Both of the major DEs for Linux embed JavaScript interpreters. Microsoft is adding it to their office suite, to coexist with and eventually supplant VBA. Inasmuch as developers are still writing desktop apps, odds are good they're Electron apps. It's as near to a universal language as we've had in decades. Instructions are being added to ARM to better support JavaScript. The dream of the Lisp machine (which Emacs to some extent embodies) is dead. Computers of the future will be, largely, JavaScript machines.

anthk 6y ago

If any, having Elisp support on Guile would have far more sense, and with a JIT and non-blocking IO Emacs would be usable enough even under a high subprocess load (cough, GNUs). I am not an Emacs user but I like Scheme (scm user here) under nvi, and a lot of people could profit from a Modern Guile based Emacs environment.

admax88q 6y ago
I'm not sure. Guile-Emacs has been talked about for ages but never materialized. Scheme is nice and all from a language purity sense, but emacs lisp just feels so very practical for its use case.
- anthk 6y ago
  I meant Guile supporting Elisp, it already supports a few more languages than Scheme.
jpfr 6y ago
There is branch for elisp support in guile. https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-elisp https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-elisp It works in principle but is slow due to some impedance mismatches that have to be bridged. Especially, Emacs has a special string format internally that is not native utf-8. Andy Wingo is making a great job with JIT-support for Guile. We have to see whether emacs-guile can become fast enough to replace native-elisp. At this time it doesn't look like it...

dleslie 6y ago

And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.

cle 6y ago
While technically true, you can still improve performance of existing Elisp code by redefining certain commonly-used Elisp functions perform better in Deno. Sure the Elisp bytecode itself doesn't evaluate faster, but that distinction isn't really important here. The end-to-end perf of certain functions can be improved in a backwards-compatible way.
- deleted 6y ago
  [deleted]
- dleslie 6y ago
  If we're entertaining writing elisp methods in a faster language to improve overall performance, then it's already been done and being done via writing methods in C. I don't see the point of polluting Emacs with Javascript.
  - cle 6y ago
    Instructing users who want high-performance code in Emacs to write their code in C and rebuild their Emacs binary, or figure out how to make it a dynamic module, is about the most user-hostile way I can imagine to improve Emacs performance.

janoc 6y ago

Well, basically this is someone trying to implement VSCode in Emacs ... Ain't gonna get far once the main developer loses interest in the project. Emacs users use Emacs because they want Lisp and don't care about web rendering and javascript runtimes ... Oh yeah and Rust is thrown in too for good measure. Good 90% of Emacs code is in the extensions which are in Lisp and nobody is going to rewrite them to Javascript even if the code was running 50x faster.

usbline 6y ago
Rust isn't "thrown in", it's what Deno is built with.
- otabdeveloper4 6y ago
  No, Deno is built with V8, and V8 is written in C++.
  - bitwize 6y ago
    V8 is the only C++ component of Deno. The other bits of the runtime are written in Rust, and Rust is the native extension language.
    - otabdeveloper4 6y ago
      The "other bits" are the ones that don't matter. It's like saying that a browser skin is "built on Rust" when inside it's still Webkit and Chromium.
singingfish 6y ago
Nah I don't use emacs cos I want lisp. I use it because it was the only thing that made any sense at all on the HP-UX machines I got access to back in 1993. A side effect of that is that emacs does everything I need (with a little bit of pandoc on the side), and I haven't had to learn anything new since.

soamv 6y ago

It's true that they're conservative, but there have been non-trivial forks in its history. If a fork proves itself by doing something significant that the original can't or won't, things can get interesting! I wouldn't write this one off so quickly.

bitwize 6y ago

> I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more layers of abstraction to understand and maintain, and splitting the extensions between Emacs Lisp and JavaScript. I'm also not convinced that a significant part of the community really wants this. I'm reminded of when an old C hand tells me that Rust will never replace C because it's too complex, brittle, and frustrating for the kinds of applications C programmers use C for. I always tell them: Rust isn't aimed at you -- it's aimed at your replacement. The Emacs-ng team doesn't have to convince the Emacs community -- they only have to convince their replacements. Much of computing in the very near future will be built on two languages: Rust and JavaScript. By basing Emacs-ng on those two languages, they just opened Emacs up to extension and hacking by a huge community who have no interest in touching Emacs's ancient, doddering Lisp nor its C underpinnings (C being, inherently, unsafe at any speed to work in). So ugly as it is, from a social standpoint it's absolutely the right approach and may well overtake GNU Emacs in terms of ecosystem size and vibrancy by the late 2020s.

celeritascelery 6y ago
> Much of computing in the very near future will be built on two languages: Rust and JavaScript. It will be interesting to see if this prediction pans out. There have been similar predictions about C++, Java, TCL, php, Perl, etc. it seems “the one true language” never emerges, but it is just around the corner. Though I really hope the future is more polyglot, because that is just way more fun.
- bitwize 6y ago
  > Though I really hope the future is more polyglot, because that is just way more fun. I hope so too, but... I've worked with people who really don't want to touch anything besides JavaScript. Such people could be coaxed to use Rust to write kernel drivers and the like, due to its safety guarantees -- but not C, nor C++. JavaScript is in everything. Both of the major DEs for Linux embed JavaScript interpreters. Microsoft is adding it to their office suite, to coexist with and eventually supplant VBA. Inasmuch as developers are still writing desktop apps, odds are good they're Electron apps. It's as near to a universal language as we've had in decades. Instructions are being added to ARM to better support JavaScript. The dream of the Lisp machine (which Emacs to some extent embodies) is dead. Computers of the future will be, largely, JavaScript machines.