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

141–150 of 154 posts

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

#141

Post by anthk »

bitwize wrote: post #120
blacktriangle wrote: post #113

Earlier quoted context omitted.

Meet your users where they are is great advice for consumer apps you want people to onboard to quickly and the users only interact with them periodiclly. We're talking about the power tools of our profession. Nobody designs a band-saw to meet their users where they are either. These are apps we spend 8hrs+ per day living in, and frankly the buffer wording is superior because a buffer is not a file, but a file is in a…

> Meeting your users where they are is how we got everybody moving from Textmate to Atom and now to VSCode as the new hotness that would finally kill Emacs and vi. And yet that's the mentality that prevented those newer editors from having the legs to really last. I'd like to think that too, but the sad fact is that most developers these days use VSCode. It is the new hotness that killed Emacs and vi. Emacs and vi ar…

>Most professional developers I've met hear Emacs and think it's something that last ran on dusty old DEC iron -- and that includes people who worked at DEC in the 80s! The fact that Emacs is still maintained and runs on modern systems came as a genuine surprise to them.

Bullshit, a lot of Linux/Unix developers used Emacs in the 90's and early OO's.

I was there.

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

#142

Post by anthk »

blacktriangle wrote: post #140
skissane wrote: post #131

Earlier quoted context omitted.

> Emacs and vi are both mere footnotes compared to VSCode in terms of market and mind share According to StackOverflow's 2019 developer survey [0], 50.7% of editors used VSCode, 25.4% used Vim. So that doesn't really support your claim that vi is a "mere footnote". 25% of market share isn't 50%, but it is still decent and more than a mere "footnote". [0] https://insights.stackoverflow.com/survey/2019#development-e...

Wow even Emacs doing better than I would have thought at 4.5%. People overestimate the value of massive community and apply a winner takes all mentality too often. You don't need a giant community, and almost by definition giant communities tend to have a lower average user quality leading to lower quality of libraries and support (looking at you JS ecosystem).

This. And those Mac zealot Gen-Zers know shit about what happened in late 90's and early 00's where people used vim and Emacs like Crazy, specially under X because Emacs were really affordable and fast under a mouse while keeping keyboard bindings.

They think the world revolutes around them with JS and hip editors while in the end they are the utter minority in serious IT/dev environments.

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

#143

Post by cle »

dleslie wrote: post #129
cle wrote: post #124

Earlier quoted context omitted.

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.

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.

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.

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

#144

Post by cle »

dleslie wrote: post #127
cle wrote: post #123

Earlier quoted context omitted.

I don’t think that’s a fair characterization, you should be able to redefine widely-used Elisp functions to run in deno. One that immediately comes to mind is the crappy HTTP client that Emacs ships with. (I have not tried this, just speaking hypothetically.)

... That still isn't an improvement of elisp speed. It might improve the performance of Emacs, but it's not improving the performance of elisp.

Now we're just quibbling. No it doesn't improve the speed at which the Elisp interpreter can churn through Elisp bytecode. We can however dynamically improve the speed at which some Elisp functions return, which would have the net effect of speeding up consuming Elisp code.

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

#145

Post by koral »

vitus wrote: post #130
vitus wrote: post #126

Earlier quoted context omitted.

This was emacs 27.1 (which is the version in the Arch repo). I can install native-comp via AUR. It'll take some time.

I think this is what you're looking for. time emacs --script fib-0b03fe9a-6b386e71.eln emacs --script fib-0b03fe9a-6b386e71.eln 22.47s user 0.09s system 99% cpu 22.664 total About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried. (I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)

Asking as wasn't mention, was fib compiled with comp-speed 3?

That should be considerably relevant in this benchmark.

PS you can also run a wider set of benchmarks to compare against stock Emacs using:

https://elpa.gnu.org/packages/elisp-benchmarks.html

Here some not very updated results:

http://akrl.sdf.org/gccemacs.html#org4297f0f

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

#146

Post by [deleted] »

vitus wrote: post #130
vitus wrote: post #126

Earlier quoted context omitted.

This was emacs 27.1 (which is the version in the Arch repo). I can install native-comp via AUR. It'll take some time.

I think this is what you're looking for. time emacs --script fib-0b03fe9a-6b386e71.eln emacs --script fib-0b03fe9a-6b386e71.eln 22.47s user 0.09s system 99% cpu 22.664 total About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried. (I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)

[deleted]

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

#147

Post by Ar-Curunir »

anthk wrote: post #137
Ar-Curunir wrote: post #136

Earlier quoted context omitted.

So the solution is what, exactly? To isolate people and gatekeep them from learning systems programming?

Yes? This is a meritocracy, if don't know how to do low level stuff, head to the College, or learn it properly.

tech is not a meritocracy.

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

#148

Post by [deleted] »

koral wrote: post #145
vitus wrote: post #130

Earlier quoted context omitted.

I think this is what you're looking for. time emacs --script fib-0b03fe9a-6b386e71.eln emacs --script fib-0b03fe9a-6b386e71.eln 22.47s user 0.09s system 99% cpu 22.664 total About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried. (I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)

Asking as wasn't mention, was fib compiled with comp-speed 3? That should be considerably relevant in this benchmark. PS you can also run a wider set of benchmarks to compare against stock Emacs using: https://elpa.gnu.org/packages/elisp-benchmarks.html Here some not very updated results: http://akrl.sdf.org/gccemacs.html#org4297f0f

[deleted]

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

#149

Post by [deleted] »

hvis wrote: post #110
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…

> Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s Which Emacs version is this? Any chance you want to try the native-comp branch and post its numbers here as well?

[deleted]
Post reply on HN