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

91–100 of 154 posts

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

#91

Post by anthk »

bambataa wrote: post #87
bitwize wrote: post #73

Earlier quoted context omitted.

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

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.

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

#92

Post by guerby »

steveklabnik wrote: post #74
achempion wrote: post #66

Earlier quoted context omitted.

Emacs speed was good enough 45 years ago, with modern processors it's just lightning fast. You can have C / Rust / any_lang extensions like RipGrep to boost some intensive workloads as well.

“Eight megs and constantly swapping” isn’t as much of an issue these days, it’s true...

Eight megs fit in the L3 cache nowadays :)

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

#93

Post by slightwinder »

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…

The demand for lisp in emacs is overrated by a vocal minority. Most people using emacs do it for the things which are not lisp-specific. The features, the plugins, the community. All that works without touching elisp as a user. And even the swallow elisp-contact that most user have when writting their init.el could be done with any other language.

Though, it's true that the many elisp-code around usca heavy burden. But how much of that is actually still used? And how fast would a propsering community replace them really? Hacking-friendly tools tend to have a wild growing ecosystem. Emacs itself is not shy of having many clones of similar featursets and regular new implementations of old but still popular features.

In that view I don't thing a new language would a real problem long term for the prosperty of emacs. It might be even a benefit, as it mixes in new blood, more people and a broader ecosystem from outside the emacs-scope.

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

#94

Post by otabdeveloper4 »

usbline wrote: post #28
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…

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

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

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

#95

Post by otabdeveloper4 »

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.

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.

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

#96

Post by jpfr »

anthk wrote: post #20
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…

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.

There is branch for elisp support in guile. 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...

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

#97

Post by Ar-Curunir »

otabdeveloper4 wrote: post #95
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…

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

Maybe Linux won’t switch over, but it’s not unlikely that Apple would consider Rust for portions of their kernel, given that they only have to support a limited number of devices, and have a strong LLVM culture already. Googles Fuschia OS also uses Rust heavily.

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

#98

Post by Kaze404 »

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've used Emacs for 2 years and haven't had to write a single elisp function.

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

#99

Post by Kaze404 »

achempion wrote: post #66
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…

Emacs speed was good enough 45 years ago, with modern processors it's just lightning fast. You can have C / Rust / any_lang extensions like RipGrep to boost some intensive workloads as well.

I don't know if I agree with this. I love Emacs and nothing has convinced me to give up on it yet, but it is a chore to use on large projects. Helm, projectile and the likes always work with passable performance at worst, but opening a jsx file for the first time literally freezes the entire program for 5 seconds. It's really annoying and I've no idea what causes it.

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

#100

Post by auganov »

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…

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

I don't think this is a fair comparison. Emacs is a specific piece of software where implementation details are part of the offering. I don't care if parts of the Linux kernel get rewritten in Rust, I have never (extensively) looked at its code. I'll like it as much.

Being able to effortlessly examine and change other people's code is a big thing for me in Emacs. Many big Emacs users make money programming in Lisps too, it's not just some vague preference they're not willing to act on.

To implement a real mode, you WILL have to call elisp code all the time. Emacs does almost nothing asynchronously. Every tiny thing in Emacs triggers a lot of elisp that assumes sequential execution. You cannot do all the hard work in an isolated context and call Emacs once you're done. Most of Emacs performance issues have to do with latency, not long running computations. With libgccjit, native-comp Elisp is consistently 4-5 times faster (yes, really), but the actual perceived improvement is much less. Can hardly tell a difference. Emacs still hangs at all the same stuff and there's no easy fix. You'd have to completely change how Emacs works at which point it may as well be something different. I don't see how this kind of a thing can incrementally take over.

If you want to make my life better find me a way to fix long lines or get rid of GC pauses without breaking everything.

Post reply on HN