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

81–90 of 154 posts

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

#81

Post by rich_sasha »

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…

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, that sounds good too. I use org mode, often with html export and latex maths, having it render quickly and seamlessly would be a win for me.

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

#82

Post by anthk »

admax88q wrote: post #69
anthk wrote: post #20

Earlier quoted context omitted.

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.

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.

I meant Guile supporting Elisp, it already supports a few more languages than Scheme.

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

#83

Post by anthk »

bitwize wrote: post #55
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…

> 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 having good stuff such as Guix, Artanis and a JIT.

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

#84

Post by anthk »

bitwize wrote: post #73
celeritascelery wrote: post #68

Earlier quoted context omitted.

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

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

- TCL and LUA interpreters are everywhere, too.

- On JS machines, I doubt it, because if some better language it's better than JS, that could yield to huge losses to ARM CPU producers. And that will happen, sooner or later.

>I hope so too, but... I've worked with people who really don't want to touch anything besides JavaScript.

These people are professionaly dead if they want to create something more performant than a bullshit, slow JS application.

QT5 it's being used in LOTS of professional software. Not even WASM Google Earth can be close to the performance of Google Earth Pro used in offices for professional tasks.

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

#85

Post by lf-non »

reidrac wrote: post #78
bitwize wrote: 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…

> The Emacs-ng team doesn't have to convince the Emacs community -- they only have to convince their replacements. Those are using VS Code already, isn't it?

Not quite. You are able to extend VSCode using TS/JS for sure, but it is not even remotely customizable to the extent that emacs is.

There is definitely ample room for a hacker-centric text editor with a minimal core where every aspect of UI and behavior can be customizable through TS.

This is not really a criticism of VSCode. If you want to prevent the kind of cross-extension conflicts and unstability that has plagued emacs since forever, a restricted extension runtime is absolutely the best way to go. But there are certainly people who would want to *build* an editor uniquely tailored to their preferences out of low level blocks and deal with the complexity associated therein.

Atom was expected to fill that niche, but it's web based UI is too slow for most large projects.

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

#86

Post by anthk »

bitwize wrote: post #27
anthk wrote: post #8

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

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.

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

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

#87

Post by bambataa »

bitwize wrote: post #73
celeritascelery wrote: post #68

Earlier quoted context omitted.

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

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

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.

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

#88

Post by anthk »

taeric wrote: post #50
eddieh wrote: post #44

Earlier quoted context omitted.

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

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

#89

Post by fock »

rich_sasha wrote: post #81
janoc wrote: post #26

Earlier quoted context omitted.

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…

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.

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

#90

Post by wiz21c »

monsieurbanana wrote: post #70
singingfish wrote: post #38

Earlier quoted context omitted.

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.

> A side effect of that is that emacs does everything I need I'm certain you're telling the truth. And I'm sure that's the case for a lot of old-timers emacs users. But I have the feeling it's less and less true. People that have used emacs for a long time don't need anything else, so they don't want any change. People for whom emacs doesn't cover everything want change, but clash against the first group of people (w…

I slowly moved everything I need into emacs. That's not because it's superior in all places. It's just that it's the same interface, all the time for me. So I don't have to learn a new editor every now and then.

But my way of working is : many little projects in various languages, much text reports with Latex/markdown, lots of notes (orgmode), bit of email, bit of IRC. In a traditional business, I'd had to use beefier IDE such as IntelliJ (hat beats emacs without a doubt) and maybe Word. But for the rest, emacs fills all the little holes...

One area where I find emacs lacking is appointment (org mode is too big for little things such as quick reminders for today's stuff); a good calculator (calc is very clumys if you compare it to SpeedCrunch for example); a good calendar (emacs calendar is a nightmare to use, for exampe why on earth doesn't display what happens in a day below the calendar and instead forces me to hit 'd' which opens a new mostly empty buffer...); a good console on Windows (on Linux vterm is mostly perfect). Email support is OK with Wanderlust but a nightmare to set up.

Also, since it's very old, there's this warm comforting feeling that will last forever. And also I'm GPL zealot, which helps too :-)

Post reply on HN