Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs-ng: Emacs with Deno runtime and TypeScript

github.com

Post reply on HN
Print view View original

41–50 of 154 posts

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#41

Post by Ericson2314 »

outworlder wrote: post #21

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.…

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.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#42

Post by michaericalribo »

Barrin92 wrote: post #37
dan-robertson wrote: post #23

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 objectiv…

one fundamental thing I run into fairly often is Emacs horrific performance on long lines. Not really an issue for code, but looking at large JSON or text files routinely almost crashes my Emacs.

Agreed: for most of my day to day tasks, emacs is performance enough, subject to the constraints of my CPU vis a vis interpreting the underlying lisp...but I do find myself actively avoiding a long line of JSON blob, because of the reliable repeatability of emacs locking up and becoming unusable on a long line.

It’s not enough to stop me using emacs, but it is enough to make me go out of my way to avoid it (and to grumble about).

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#43

Post by buescher »

matthewbauer wrote: post #36
buescher wrote: post #35

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

The readme says it’s based off native-comp so I think compiled lisp stuff should be no worse than gccemacs.

"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!

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#44

Post by eddieh »

vitus wrote: post #9
anthk wrote: post #3

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

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 ( 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…

This got me curious about other Scheme implementations.

Chicken compiles to C

    $ csc fib.scm
    $ time ./fib

    real 0m8.461s
    user 0m8.383s
    sys  0m0.061s
Racket has a modern JIT

    $ cat fib.rkt 
    #lang racket
    (define (fibonacci n)
      (if (
For reference

    $ sysctl -a | grep .brand_string
    machdep.cpu.brand_string: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#45

Post by cle »

janoc wrote: post #26
JasonFruit wrote: post #18

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 la…

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 e…

This doesn't require rewriting extensions, it is backwards compatible.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#46

Post by throwanem »

_peeley wrote: post #6

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 e…

This sounds like a description of Emacs most of a decade ago, not long after I started using it, rather than of Emacs today.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#47

Post by celeritascelery »

ducaale wrote: post #16
_peeley wrote: post #6

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 e…

Port of Emacs to rust https://github.com/remacs/remacs

Emacs-ng is actually a fork of remacs. Many of the same people are involved.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#48

Post by throwanem »

toomim wrote: post #29

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 oblitera…

You're underplaying your hand, you know. Why leave out that cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else, and can't be rebound to match muscle memory in any way that's really useful?

I mean - if you're going to ignore everything that makes Emacs great on your way to cavil about how it's different, why not go all out, right?

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#49

Post by shadowgovt »

toomim wrote: post #29

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 oblitera…

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.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#50

Post by taeric »

eddieh wrote: post #44
vitus wrote: post #9

Earlier quoted context omitted.

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 ( 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…

This got me curious about other Scheme implementations. Chicken compiles to C $ csc fib.scm $ time ./fib real 0m8.461s user 0m8.383s sys 0m0.061s Racket has a modern JIT $ cat fib.rkt #lang racket (define (fibonacci n) (if ( For reference $ sysctl -a | grep .brand_string machdep.cpu.brand_string: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz

This got me interested in other lisps, as well. Looks like sbcl gives (time (fib 40)) to be about 1.7 seconds on my machine. (Ryzen 5 3600x.)

For lulz, I clocked a dumb loop version.

    (defun fib (n)
        (loop repeat n
              for a = 1 then b
              for b = 1 then c
              for c = (+ a b)
              finally (return a)))
And... well, serves as an amusing reminder that tree recursion has its downsides. :D

Edit: I confess the speed of the loop got me curious and.... javascript has numeric overflow. That would be a hell of a surprise if you weren't expecting it.

Edit2: (I realize overflow isn't the right term, but it is amusing that I can calc the 10000th fib in elisp... not so much in javascript. And yes, even elisp falls over sooner than sbcl does.)

Post reply on HN