30 ms·

Emacs-ng: Emacs with Deno runtime and TypeScript

177 points by karlicoss 6y ago

JasonFruit 6y ago
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.
outworlder 6y ago
Not entirely sure I see the point. I would like to see Emacs/Guile. Emacs need a more modern elisp (or in this case, Scheme) implementation. It's much easier to make it compatible with the mountain of existing (and useful!) elisp code if you are also in a form of Lisp. That's still not trivial. It also needs a better front-end renderer, across platforms. I could understand if the "NG" part were to be just about that. But WebRender is an optional feature. Then again, it looks and runs perfectly fine for me on Linux, it's when I'm using on OSX that I see the warts. This is doubtless in no small part due to patches being refused because they are for proprietary platforms. Async I/O is needed but I am not sure we need to bring Typescript and a full JS environment to get that.
- Ericson2314 6y ago
  Came to say the same, and guile emacs was attempted in the past. It doesn't make sen to have multiple interpreters jury-rigged up (the horror!) And it also doesn't make sense to throw away all the lisp by having no interpreter for emacs lisp. Guile does support emacs lisp just for this purpose.
dan-robertson 6y ago
I’m not convinced emacs performance is that bad. It’s pretty highly optimised for typing at a normal rate though I agree the data structures aren’t great for more graphical things (lots of properties, random access inserts, even just long lines). But then the way to improve this is to improve the data structures rather than replacing emacs lisp. Emacs performs better than many other applications at important objective measures, eg the time between pressing a key and the character showing up on screen. You might expect vim to be good at this but many terminal emulators are optimised for throughput rather than latency and are slower than gui emacs. Certainly legacy is a problem but I worry that replacing eg font-lock with something with better performance properties (does this actually do that?) means throwing out the baby with the bath water as so many modes depend on these things. Typically the reason that emacs becomes slow is due to an overload of features or bad asymptotics. Examples: - global-auto-revert-mode plus lots of buffers plus some in a slow file system like nfs or maybe lots of open fired buffers - some mode using a configured alist that works fine for small lists but really sucks for big ones (ie perf is linear in size of config, but often this comes hand in hand with trying to process big inputs so it can be worse.) I think this happened with spacemacs and which-key-mode for example - flyspell + flycheck + build running in background + some autocompletion server. Even a powerful computer can be slowed down by this. Some of these are likely to slowly improve over time as they become more synchronous. Others are problems you’re likely to have with any editor (a nice emacs thing was that it was easy for me to add some advice to pin my build to not use all my cpu. It can be really hard to poke around in other plugin systems to do that sort of thing without a config option for it) - just piling on the nodes with something like spacemacs and not paying attention to the performance of the whole. I think doom-emacs shows a lot of promise here. I do think there are advantages that could be made by modernising emacs’ core and improving data structures (whatever happened to remacs?) I feel like the fundamental design of emacs is good however and I like: 1. keymaps and the command loop 2. Buffer-local variables, advice, dynamic scoping 3. Documentation 4. Fundamentally text-based interface Obviously you should disregard all of this though as I am very biased due to my emotional reaction to getting rid of emacs lisp which, frankly, you can pry from my cold dead hands. ———————————— Some other thoughts I had on emacs lisp as a good language for a text editor: 1 https://news.ycombinator.com/item?id=19343908 https://news.ycombinator.com/item?id=19343908 2 https://news.ycombinator.com/item?id=22881597 https://news.ycombinator.com/item?id=22881597 3 https://news.ycombinator.com/item?id=18605001 https://news.ycombinator.com/item?id=18605001 On the “fast” measurement that actually matters: https://news.ycombinator.com/item?id=23432292 https://news.ycombinator.com/item?id=23432292
jacobsenscott 6y ago
This looks very cool
anthk 6y ago
Compare the recursive Fibbonaci function against Scheme with Guile's JIT.
- jgon 6y ago
  As far as I understand Guile-emacs is pretty much dead in the water, it hasn't seen any substantial development in quite a while. Your best bet for better emacs performance is the gccemacs branch, that integrates the libgccjit and builds off the existing emacs bytecode infrastructure and compiles it to native code. It is much much further along than guile-emacs and on track to be merged into emacs master at some point. That would cover one major point of complaint with emacs performance, the other would be getting some form of real threading and parallelism into emacs so that long-running elisp doesn't block the UI thread, but that is a pretty huge task. With that said, I am sure that the community realizes this and is slowly working their way towards this.
- vitus 6y ago
  EDIT: as pointed out, this is run with Guile 2.2, which is pre-JIT. Results to be posted later in this thread... Okay. $ cat fib.scm (define (fibonacci n) (if (<= n 1) n (+ (fibonacci (- n 1)) (fibonacci (- n 2))))) (fibonacci 40) $ time guile fib.scm guile fib.scm 8.52s user 0.01s system 99% cpu 8.559 total Node also uses V8. $ time node fib.js node fib.js 1.29s user 0.01s system 100% cpu 1.296 total But okay, you wanted deno. $ time deno run fib.js deno run fib.js 1.41s user 0.02s system 99% cpu 1.423 total Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s. And `emacs --script fib.el` takes about 2x that, at 64s. edit: for reference, the equivalent C code runs in 0.27s on my laptop. edit edit: okay, okay, compiling the Guile code before running it speeds it up to an exciting 8.16s execution time, still about 6x slower than deno.
  - anthk 6y ago
    guile --version? EDIT: Guile3 brings JIT support... Guile always compiles code before running it, but adding a JIT it's only from v > 2.91.x, and by default at v3.
bitwize 6y ago
I personally look forward to the day when every program I run embeds JavaScript and an HTML engine in it. Then we will be living in an age of true modernity in software development. Systemd-ng, anyone?
- anthk 6y ago
  That's Gnome3-4.
- nn3 6y ago
  I'm sure Samsung, Micron and every other company selling DIMMs are looking forward for that day too. It would need how much more memory for everything? My beefy desktop computer is often already struggling just to run Chrome. Emacs used to stand for "Eight Megabytes and constly swapping", maybe they could name it now Egacs (Eight Gigabytes ...)
  - anthk 6y ago
    In the days of the 486 being nothing more than "junk" compared to a Pentium 2, running Emacs with SICP on Texinfo format was the light approach compared to open a full browser to read HTML pages. Ditto with Groff+Mom occuping a few MB (totally doable in 1997) vs a GB LaTex install lasting several minutes to render a PostScript, and then running X (if even) just to display the resulting file and nothing more. Nowadays even QT5 software looks lightweight enough compared to some Electron monsters...
- daotoad 6y ago
  Is this satire?
- dleslie 6y ago
  You're not thinking modern enough; what we need is uboot-ng!
AlexCoventry 6y ago
Looks interesting. Some examples showing how JavaScript integrates with the emacs runtime would be helpful.
_peeley 6y ago
I see a lot of parallels between Emacs' problems now and Vim's problems a few years ago: opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. I think Emacs users and the community would benefit from a ground-up modern rewrite much like Neovim did for Vim, especially compared to this project which adds even more layers to maintain. It certainly addresses performance issues, but Emacs seems to have enough problems with things breaking spontaneously - I don't think adding a JavaScript runtime to the mix will do any bit of good there.
- ducaale 6y ago
  Port of Emacs to rust https://github.com/remacs/remacs https://github.com/remacs/remacs
  - celeritascelery 6y ago
    Emacs-ng is actually a fork of remacs. Many of the same people are involved.
- turminal 6y ago
  Neovim is not a rewrite.
  - thomastjeffery 6y ago
    No, but it tackles the same aforementioned issues: > opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. The main goal of NeoVim is to ditch the backwards compatibility and simplify the codebase. Sure, it isn't a from-scratch rewrite, but it's a very deep fork.
    - p2t2p 6y ago
      The magic of it is it just keeps on working. All those big changes didn't cause any instability for even once.
anthk 6y ago
>it's an ecosystem of powerful tools and approaches that Emacs just doesn't have currently. Guile-Emacs should.
- bitwize 6y ago
  Yeah, let me know when that gets released in a form that's usable as a daily driver. I'll install it on my production-ready Hurd system, right alongside the first version of GIMP that doesn't send professional designers into fits of rage. Even then, there is no other ecosystem that has quite the volume of powerful tools and approaches that HTML/CSS/JS have.
  - anthk 6y ago
    >Even then, there is no other ecosystem that has quite the volume of powerful tools and approaches that HTML/CSS/JS have. GNU Artanis, forget Hurd, get Guix. Also, on HTML/CSS/JS, they are still 20 years behind the Pascal IDE from Borland or Lazarus, and don't let me talk on NPM and dependencies. On speed and features, QT5 slaps JS so hard that trying to get something as performant it's a ridiculous claiming. And I use OpenBSD and CWM, but FFS, JS is a toy compared, to, for example, Lazarus IDE, QTCreator and their compilers/backends running fast as fuck software even on scrap computers. And Turbo Pascal/Lazarus had RAD developing features since 20 years aso as I said. Something much faster and more native (totally native :p) than any JS toolkit is trying to do ever. Add a control? Drag and drop, edit the bindings. Cross compiling? Lazarus does that even for damn Windows 95 from a Linux machine. And so on.
toomim 6y ago
I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly obliterate the contents of the clipboard while getting ready to paste what you thought was there. Oh, but to address this problem, it makes the clipboard into a ring of clipboards, so that when you replace the clipboard with something else, you can still access the other clipboards in a ring by hitting the paste command multiple times in a row. Oh, but if you press another key in between, you get lost in clipboard madness. Emacs also has an "undo", but no "redo" command. Except that when you "undo", it actually pushes the "undo" itself onto the list of "things to undo", so that you can undo that undo, in order to redo. But people also need to undo multiple undos before getting interrupted with a redo, so Emacs only undoes the undos if you press some other key after undoing a few dos in a row. But hey, this means it doesn't need a "redo" command. So, I agree that the elisp runtime is a weird thing about Emacs, and something that is rational to change. But the thing is... if you're going to change that... why not everything else about Emacs? I mean, at some point Emacs looks a lot like Bitcoin Core, or Wikipedia -- a beautiful historical community with weird consensus rules that flowered into a very exotic, strange, and usually-functional artifact. Although sometimes it doesn't work as well as the newer technologies.
- shadowgovt 6y ago
  it is fascinating to see how (particularly in older software / systems) radically different decisions were made about what is nowadays considered "fundamental" UX, and to imagine what the world would have been like if this other thing happened to become the consensus standard. Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. Quite internally consistent; a bear to get into if you learned 3DS Max or Maya first.
  - outworlder 6y ago
    > Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. When did you last start Blender? This used to be true. Nowadays it's at least on par with commercial tools if not better.
buescher 6y ago
I wonder how the performance compares to gccemacs, with its native code compilation of elisp. That would be the fair comparison. https://www.emacswiki.org/emacs/GccEmacs https://www.emacswiki.org/emacs/GccEmacs
- matthewbauer 6y ago
  The readme says it’s based off native-comp so I think compiled lisp stuff should be no worse than gccemacs.
  - buescher 6y ago
    "emacs-ng's JS implementation clocks in over 50 times faster than emacs 28 without native-comp for calculating fib(40). With native-comp at level 3, JS clocks in over 15 times faster." I missed the native-comp note the first read through. Thanks!
shaunxcode 6y ago
And to complete the circle back to sexpr run cljs on the js engine.
stakkur 6y ago
As an Emacs user, I just have no use for this, and I get the feeling most Emacs users won’t either.
- taeric 6y ago
  I will add to this, that I also have no reason to forbid something like this. It is scratching an itch for those involved. Kudos on that, and best of luck with it. I just can't pretend this is solving a problem I have. :D
Klwohu 6y ago
I don't like this one bit. Good luck to the author and team, but I despise attempts to bring emacs "into the future."
CyberRabbi 6y ago
The inclusion of Deno/webrender almost turns this into a web browser. I wonder if this project could be imagined another way, instead of turning emacs into an application runtime, port emacs to be a SPA. It would still get to take advantage of all the latest technology, and with the new FileSystem APIs emerging it would have native file system access.
varjag 6y ago
Finally, Emacs runtime can catch up with modernity to make all size jokes relevant again.
slightwinder 6y ago
I'm curios, if this has direct TypeScript-Support, does this mean it can use VS Code-Parts and Plugins? Effortless plugin-installation would be a killerfeature... Similar advantage could become direct reuse of VS Code-Parts, like the code for language servers or the monaco editor-part. This could unfold into a project which demand relativ little work, while pushing it to a level where it can compare with VS Code. It could become a good bridge beween modern VS Code and old GNU Emacs that way.
- outworlder 6y ago
  > Effortless plugin-installation would be a killerfeature How is that different from what Emacs package managers provide?
  - slightwinder 6y ago
    They are not really effortless, especially when distributions like doom or spacemacs are used. Sure, today it's easier than 10 years ago, but compared to the modern solutions it still pretty backward. In VS Code you can search for ne plugins from inside the application (which emacs also allows), while also showing all information including pictures and animations about the plugin in-app (which emacs does not allow). VS Code also shows which bindings, functions and settings the plugin adds (in emacs only indirect possible, with effort). And best part: it just works. With emacs there are always a gazzilion problems coming with plugins. Be it some conflict or just additional work neccessary to make it work. Thouhg this is mostly a solvable problem with emacs, it just does not get solved. The Emacs communities solultion for this is the usage of distributions, which come with other problems and have only support for the more popular plugins.

177 points by karlicoss 6y ago

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.

outworlder 6y ago

Not entirely sure I see the point. I would like to see Emacs/Guile. Emacs need a more modern elisp (or in this case, Scheme) implementation. It's much easier to make it compatible with the mountain of existing (and useful!) elisp code if you are also in a form of Lisp. That's still not trivial. It also needs a better front-end renderer, across platforms. I could understand if the "NG" part were to be just about that. But WebRender is an optional feature. Then again, it looks and runs perfectly fine for me on Linux, it's when I'm using on OSX that I see the warts. This is doubtless in no small part due to patches being refused because they are for proprietary platforms. Async I/O is needed but I am not sure we need to bring Typescript and a full JS environment to get that.

Ericson2314 6y ago
Came to say the same, and guile emacs was attempted in the past. It doesn't make sen to have multiple interpreters jury-rigged up (the horror!) And it also doesn't make sense to throw away all the lisp by having no interpreter for emacs lisp. Guile does support emacs lisp just for this purpose.

dan-robertson 6y ago

I’m not convinced emacs performance is that bad. It’s pretty highly optimised for typing at a normal rate though I agree the data structures aren’t great for more graphical things (lots of properties, random access inserts, even just long lines). But then the way to improve this is to improve the data structures rather than replacing emacs lisp. Emacs performs better than many other applications at important objective measures, eg the time between pressing a key and the character showing up on screen. You might expect vim to be good at this but many terminal emulators are optimised for throughput rather than latency and are slower than gui emacs. Certainly legacy is a problem but I worry that replacing eg font-lock with something with better performance properties (does this actually do that?) means throwing out the baby with the bath water as so many modes depend on these things. Typically the reason that emacs becomes slow is due to an overload of features or bad asymptotics. Examples: - global-auto-revert-mode plus lots of buffers plus some in a slow file system like nfs or maybe lots of open fired buffers - some mode using a configured alist that works fine for small lists but really sucks for big ones (ie perf is linear in size of config, but often this comes hand in hand with trying to process big inputs so it can be worse.) I think this happened with spacemacs and which-key-mode for example - flyspell + flycheck + build running in background + some autocompletion server. Even a powerful computer can be slowed down by this. Some of these are likely to slowly improve over time as they become more synchronous. Others are problems you’re likely to have with any editor (a nice emacs thing was that it was easy for me to add some advice to pin my build to not use all my cpu. It can be really hard to poke around in other plugin systems to do that sort of thing without a config option for it) - just piling on the nodes with something like spacemacs and not paying attention to the performance of the whole. I think doom-emacs shows a lot of promise here. I do think there are advantages that could be made by modernising emacs’ core and improving data structures (whatever happened to remacs?) I feel like the fundamental design of emacs is good however and I like: 1. keymaps and the command loop 2. Buffer-local variables, advice, dynamic scoping 3. Documentation 4. Fundamentally text-based interface Obviously you should disregard all of this though as I am very biased due to my emotional reaction to getting rid of emacs lisp which, frankly, you can pry from my cold dead hands. ———————————— Some other thoughts I had on emacs lisp as a good language for a text editor: 1 https://news.ycombinator.com/item?id=19343908 https://news.ycombinator.com/item?id=19343908 2 https://news.ycombinator.com/item?id=22881597 https://news.ycombinator.com/item?id=22881597 3 https://news.ycombinator.com/item?id=18605001 https://news.ycombinator.com/item?id=18605001 On the “fast” measurement that actually matters: https://news.ycombinator.com/item?id=23432292 https://news.ycombinator.com/item?id=23432292

jacobsenscott 6y ago

This looks very cool

anthk 6y ago

Compare the recursive Fibbonaci function against Scheme with Guile's JIT.

jgon 6y ago
As far as I understand Guile-emacs is pretty much dead in the water, it hasn't seen any substantial development in quite a while. Your best bet for better emacs performance is the gccemacs branch, that integrates the libgccjit and builds off the existing emacs bytecode infrastructure and compiles it to native code. It is much much further along than guile-emacs and on track to be merged into emacs master at some point. That would cover one major point of complaint with emacs performance, the other would be getting some form of real threading and parallelism into emacs so that long-running elisp doesn't block the UI thread, but that is a pretty huge task. With that said, I am sure that the community realizes this and is slowly working their way towards this.
vitus 6y ago
EDIT: as pointed out, this is run with Guile 2.2, which is pre-JIT. Results to be posted later in this thread... Okay. $ cat fib.scm (define (fibonacci n) (if (<= n 1) n (+ (fibonacci (- n 1)) (fibonacci (- n 2))))) (fibonacci 40) $ time guile fib.scm guile fib.scm 8.52s user 0.01s system 99% cpu 8.559 total Node also uses V8. $ time node fib.js node fib.js 1.29s user 0.01s system 100% cpu 1.296 total But okay, you wanted deno. $ time deno run fib.js deno run fib.js 1.41s user 0.02s system 99% cpu 1.423 total Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s. And `emacs --script fib.el` takes about 2x that, at 64s. edit: for reference, the equivalent C code runs in 0.27s on my laptop. edit edit: okay, okay, compiling the Guile code before running it speeds it up to an exciting 8.16s execution time, still about 6x slower than deno.
- anthk 6y ago
  guile --version? EDIT: Guile3 brings JIT support... Guile always compiles code before running it, but adding a JIT it's only from v > 2.91.x, and by default at v3.

bitwize 6y ago

I personally look forward to the day when every program I run embeds JavaScript and an HTML engine in it. Then we will be living in an age of true modernity in software development. Systemd-ng, anyone?

anthk 6y ago
That's Gnome3-4.
nn3 6y ago
I'm sure Samsung, Micron and every other company selling DIMMs are looking forward for that day too. It would need how much more memory for everything? My beefy desktop computer is often already struggling just to run Chrome. Emacs used to stand for "Eight Megabytes and constly swapping", maybe they could name it now Egacs (Eight Gigabytes ...)
- anthk 6y ago
  In the days of the 486 being nothing more than "junk" compared to a Pentium 2, running Emacs with SICP on Texinfo format was the light approach compared to open a full browser to read HTML pages. Ditto with Groff+Mom occuping a few MB (totally doable in 1997) vs a GB LaTex install lasting several minutes to render a PostScript, and then running X (if even) just to display the resulting file and nothing more. Nowadays even QT5 software looks lightweight enough compared to some Electron monsters...
daotoad 6y ago
Is this satire?
dleslie 6y ago
You're not thinking modern enough; what we need is uboot-ng!

AlexCoventry 6y ago

Looks interesting. Some examples showing how JavaScript integrates with the emacs runtime would be helpful.

_peeley 6y ago

I see a lot of parallels between Emacs' problems now and Vim's problems a few years ago: opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. I think Emacs users and the community would benefit from a ground-up modern rewrite much like Neovim did for Vim, especially compared to this project which adds even more layers to maintain. It certainly addresses performance issues, but Emacs seems to have enough problems with things breaking spontaneously - I don't think adding a JavaScript runtime to the mix will do any bit of good there.

ducaale 6y ago
Port of Emacs to rust https://github.com/remacs/remacs https://github.com/remacs/remacs
- celeritascelery 6y ago
  Emacs-ng is actually a fork of remacs. Many of the same people are involved.
turminal 6y ago
Neovim is not a rewrite.
- thomastjeffery 6y ago
  No, but it tackles the same aforementioned issues: > opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. The main goal of NeoVim is to ditch the backwards compatibility and simplify the codebase. Sure, it isn't a from-scratch rewrite, but it's a very deep fork.
  - p2t2p 6y ago
    The magic of it is it just keeps on working. All those big changes didn't cause any instability for even once.

anthk 6y ago

>it's an ecosystem of powerful tools and approaches that Emacs just doesn't have currently. Guile-Emacs should.

bitwize 6y ago
Yeah, let me know when that gets released in a form that's usable as a daily driver. I'll install it on my production-ready Hurd system, right alongside the first version of GIMP that doesn't send professional designers into fits of rage. Even then, there is no other ecosystem that has quite the volume of powerful tools and approaches that HTML/CSS/JS have.
- anthk 6y ago
  >Even then, there is no other ecosystem that has quite the volume of powerful tools and approaches that HTML/CSS/JS have. GNU Artanis, forget Hurd, get Guix. Also, on HTML/CSS/JS, they are still 20 years behind the Pascal IDE from Borland or Lazarus, and don't let me talk on NPM and dependencies. On speed and features, QT5 slaps JS so hard that trying to get something as performant it's a ridiculous claiming. And I use OpenBSD and CWM, but FFS, JS is a toy compared, to, for example, Lazarus IDE, QTCreator and their compilers/backends running fast as fuck software even on scrap computers. And Turbo Pascal/Lazarus had RAD developing features since 20 years aso as I said. Something much faster and more native (totally native :p) than any JS toolkit is trying to do ever. Add a control? Drag and drop, edit the bindings. Cross compiling? Lazarus does that even for damn Windows 95 from a Linux machine. And so on.

toomim 6y ago

I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly obliterate the contents of the clipboard while getting ready to paste what you thought was there. Oh, but to address this problem, it makes the clipboard into a ring of clipboards, so that when you replace the clipboard with something else, you can still access the other clipboards in a ring by hitting the paste command multiple times in a row. Oh, but if you press another key in between, you get lost in clipboard madness. Emacs also has an "undo", but no "redo" command. Except that when you "undo", it actually pushes the "undo" itself onto the list of "things to undo", so that you can undo that undo, in order to redo. But people also need to undo multiple undos before getting interrupted with a redo, so Emacs only undoes the undos if you press some other key after undoing a few dos in a row. But hey, this means it doesn't need a "redo" command. So, I agree that the elisp runtime is a weird thing about Emacs, and something that is rational to change. But the thing is... if you're going to change that... why not everything else about Emacs? I mean, at some point Emacs looks a lot like Bitcoin Core, or Wikipedia -- a beautiful historical community with weird consensus rules that flowered into a very exotic, strange, and usually-functional artifact. Although sometimes it doesn't work as well as the newer technologies.

shadowgovt 6y ago
it is fascinating to see how (particularly in older software / systems) radically different decisions were made about what is nowadays considered "fundamental" UX, and to imagine what the world would have been like if this other thing happened to become the consensus standard. Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. Quite internally consistent; a bear to get into if you learned 3DS Max or Maya first.
- outworlder 6y ago
  > Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. When did you last start Blender? This used to be true. Nowadays it's at least on par with commercial tools if not better.

buescher 6y ago

I wonder how the performance compares to gccemacs, with its native code compilation of elisp. That would be the fair comparison. https://www.emacswiki.org/emacs/GccEmacs https://www.emacswiki.org/emacs/GccEmacs

matthewbauer 6y ago
The readme says it’s based off native-comp so I think compiled lisp stuff should be no worse than gccemacs.
- buescher 6y ago
  "emacs-ng's JS implementation clocks in over 50 times faster than emacs 28 without native-comp for calculating fib(40). With native-comp at level 3, JS clocks in over 15 times faster." I missed the native-comp note the first read through. Thanks!

shaunxcode 6y ago

And to complete the circle back to sexpr run cljs on the js engine.

stakkur 6y ago

As an Emacs user, I just have no use for this, and I get the feeling most Emacs users won’t either.

taeric 6y ago
I will add to this, that I also have no reason to forbid something like this. It is scratching an itch for those involved. Kudos on that, and best of luck with it. I just can't pretend this is solving a problem I have. :D

Klwohu 6y ago

I don't like this one bit. Good luck to the author and team, but I despise attempts to bring emacs "into the future."

CyberRabbi 6y ago

The inclusion of Deno/webrender almost turns this into a web browser. I wonder if this project could be imagined another way, instead of turning emacs into an application runtime, port emacs to be a SPA. It would still get to take advantage of all the latest technology, and with the new FileSystem APIs emerging it would have native file system access.

varjag 6y ago

Finally, Emacs runtime can catch up with modernity to make all size jokes relevant again.

slightwinder 6y ago

I'm curios, if this has direct TypeScript-Support, does this mean it can use VS Code-Parts and Plugins? Effortless plugin-installation would be a killerfeature... Similar advantage could become direct reuse of VS Code-Parts, like the code for language servers or the monaco editor-part. This could unfold into a project which demand relativ little work, while pushing it to a level where it can compare with VS Code. It could become a good bridge beween modern VS Code and old GNU Emacs that way.

outworlder 6y ago
> Effortless plugin-installation would be a killerfeature How is that different from what Emacs package managers provide?
- slightwinder 6y ago
  They are not really effortless, especially when distributions like doom or spacemacs are used. Sure, today it's easier than 10 years ago, but compared to the modern solutions it still pretty backward. In VS Code you can search for ne plugins from inside the application (which emacs also allows), while also showing all information including pictures and animations about the plugin in-app (which emacs does not allow). VS Code also shows which bindings, functions and settings the plugin adds (in emacs only indirect possible, with effort). And best part: it just works. With emacs there are always a gazzilion problems coming with plugins. Be it some conflict or just additional work neccessary to make it work. Thouhg this is mostly a solvable problem with emacs, it just does not get solved. The Emacs communities solultion for this is the usage of distributions, which come with other problems and have only support for the more popular plugins.