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 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.
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.
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...
> 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, 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.
The Emacs-ng team doesn't have to convince the Emacs community -- they only have to convince their replacements. Much of computing in the very near future will be built on two languages: Rust and JavaScript. By basing Emacs-ng on those two languages, they just opened Emacs up to extension and hacking by a huge community who have no interest in touching Emacs's ancient, doddering Lisp nor its C underpinnings (C being, inherently, unsafe at any speed to work in). So ugly as it is, from a social standpoint it's absolutely the right approach and may well overtake GNU Emacs in terms of ecosystem size and vibrancy by the late 2020s.
> 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.
> 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.
> 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.
Am I the only one that thinks JavaScript is living on borrowed time? Once webasm matures and has a consistent story for DOM interop, JS will lose its status as the language we all have to know and be forced to compete head to head based on its merits.
I wouldn't bet on JS in that scenario.
> 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. Microsoft is adding it to their office suite, to coexist with and eventually supplant VBA. Inasmuch as developers are still writing desktop apps, odds are good they're Electron apps. It's as near to a universal language as we've had in decades. Instructions are being added to ARM to better support JavaScript.
The dream of the Lisp machine (which Emacs to some extent embodies) is dead. Computers of the future will be, largely, JavaScript machines.
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.
- 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.
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.
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.
It's true that they're conservative, but there have been non-trivial forks in its history. If a fork proves itself by doing something significant that the original can't or won't, things can get interesting! I wouldn't write this one off so quickly.
And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.
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.
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 even if the code was running 50x faster.
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 (who have been there/contributed for longer), and in the end migrate somewhere else.
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 :-)
I've used Emacs for... 10 years now? I didn't customize it for an embarrassing long amount of time, but by now I'm comfortable writing elisp code. It is a game changer.
Given enough time I can make Emacs do pretty much anything. I just don't have that much free time (anymore).
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.
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.
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.
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.
Uh, in the age of the 386 and 4MB of RAM, if you had that setup against a 486 an 8MB, you chose between running X and running Emacs. OFC you could run jmacs perfectly.
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.)
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.
