Live data from Hacker News

Emacs-ng: Emacs with Deno runtime and TypeScript

github.com

101–110 of 154 posts

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

#101
post #55

Earlier quoted context omitted.

> 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, brit…

> Much of computing in the very near future will be built on two languages: Rust and JavaScript. JavaScript runtimes will written in C++, and will run on OS's written in C. "Built on" is the wrong phrase to use here, because the actual foundations aren't Rust or JavaScript and will never be.

> will run on OS's written in C.

C++ is slowly but surely displacing C on the OS side too. The field is obviously full of, hmm, time-proven code but new project tends to use C++.

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

#102

Earlier quoted context omitted.

Neovim is not a rewrite.

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.

>Sure, it isn't a from-scratch rewrite, but it's a very deep fork.

Not really. I contribute to Neovim and in my experience the architecture is the same as in Vim. The features that were added in Neovim first do have a different architecture and are better designed though. However these new features only make a tiny fraction of all of Vim's features.

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

#103
post #89

Earlier quoted context omitted.

I like Emacs for everything except elisp. I never learnt it despite a few attempts, it feels odd and orthogonal to everything else I do. My .emacs is cobbled together from googled snippets. I would love a normal extension language, that also isn’t a hack (like Python integration). I’m not a JS guy but I’ll take it over lisp. I’m not sure what the web render things are, but if it means some kind of browser integration…

basically this means that `apt install emacs-nox` now takes 2GBs of downloads, pulls in hundreds of fast-changing, hardly audited extensions and probably is not available in sane distros. No, thanks.

Well, that would be bad, agreed. But as I see upside in the project, I certainly won't bemoan it as useless ahead of time.

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

#104
post #91

Earlier quoted context omitted.

Is someone who only wants to write JavaScript really going to be coaxed to write kernel drivers in any language? Yes there is a dominant JS crowd, but I don’t really see why they should affect what developers in other areas choose.

These people are delusional, they think they can do low level device driver thinkering with just JS... Eh, no. Not even close . Back in the day I wrote a personal patch for BTTV in order to support my video card with different tuner and radio settings. It was damn hard for a C newbie like me. For these people it would be a nightmare.

Yeah, and now imagine if you didn’t have to worry about simple things like memory safety or overflow or null pointer checks or so many C problems that Rust fixes.

The point of Rust is to enable newbies to write systems software.

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

#105
post #83
post #55

Earlier quoted context omitted.

> 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, brit…

> Much of computing in the very near future will be built on two languages: Rust and JavaScript. Ah, another Silicon Valley. Guru. Gook luck with that. Good luck replacing C, Unix which are everwhere , and not a tiny niche compared to these hipster JS trends. Not even close. EVERY teleco background is tied to C and Unix for standards and data exchanging/defining protocols. And well, even Scheme being a niche, it's ha…

Says Gartner

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

#106
post #88
post #50

Earlier quoted context omitted.

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

>And... well, serves as an amusing reminder that tree recursion has its downsides. :D OFC I would rewrite that as a iterative form (and any Schemer here could :D), but here we are testing performance :D.

Agreed. I didn't mean that necessarily as a criticism of anything. Just hard to have an intuition for just how much it slows down.

I suppose there is a bit of something in there about using the right algorithm. But I can understand picking one that will take time for comparing speed. I'm not sure either is really representative of work you expect an editor to do, though. Curse of benchmarks.

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

#107
post #101

Earlier quoted context omitted.

> Much of computing in the very near future will be built on two languages: Rust and JavaScript. JavaScript runtimes will written in C++, and will run on OS's written in C. "Built on" is the wrong phrase to use here, because the actual foundations aren't Rust or JavaScript and will never be.

> will run on OS's written in C. C++ is slowly but surely displacing C on the OS side too. The field is obviously full of, hmm, time-proven code but new project tends to use C++.

I've been hearing this for 30 years, and it hasn't happened yet.

Wake me up when it happens.

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

#108
post #28

Earlier quoted context omitted.

Rust isn't "thrown in", it's what Deno is built with.

No, Deno is built with V8, and V8 is written in C++.

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.

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

#109
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?

> cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else

Try `C-w`, `C-k` and `C-y` inside a Bash shell sometime, you might be surprised.

`M-w` is an exception, though.

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

#110
post #9
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…

> 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?

Post reply on HN