Emacs-ng - Associer le runtime Deno et TypeScript à Emacs

• Il est possible d’associer le runtime Deno à Emacs pour utiliser JavaScript/TypeScript

• Le moteur V8 est mieux optimisé que la VM Elisp

• Les limites d’Emacs en traitement asynchrone et en multithreading peuvent être gérées en JavaScript (async/await, Web Workers), avec prise en charge de WebAssembly

• Accélération GPU possible (expérimentale) en utilisant native-comp, qui convertit Elisp en code natif, et le WebRender de Firefox comme compositeur

C’était récemment passé sur Hacker News.

https://news.ycombinator.com/item?id=26453174

[ryuheechul]

Je ne connais pas très bien Emacs, car à l’époque je n’ai pratiquement utilisé que Spacemacs, mais j’ai lu le passage ci-dessous sur la page principale et je l’ai trouvé intéressant. Au final, j’ai l’impression que l’essentiel est de dynamiser l’écosystème via Deno en améliorant les performances et en étendant la prise en charge des langages.

Performance#

v8's world-class JIT offers the potential for massive performance gains. For a simple benchmark (fibonacci), using the following implementations:

(defun fibonacci(n)

(if (<= n 1)

  n

(+ (fibonacci (- n 1)) (fibonacci (- n 2)))))

const fib = (n) => {

if (n <= 1) {

    return n;

}

return fib(n - 1) + fib(n - 2);

};

L’implémentation JS d’emacs-ng s’exécute plus de 50 fois plus vite qu’emacs 28 sans native-comp pour calculer fib(40). Avec native-comp au niveau 3, JS reste plus de 15 fois plus rapide. Cela, combiné à l’Async I/O de Deno, aux WebWorkers et à WebAsm, vous donne les outils pour rendre Emacs plus fluide et plus rapide sans avoir à installer d’outils supplémentaires à lancer en arrière-plan ni à vous soucier des versions de bibliothèques partagées : des performances maximales avec TOUT au niveau de la couche de scripting.

[alstjr7375]

En réalité, l’extensibilité en elle-même n’est pas mauvaise.

Les macros propres à Lisp.

La prise en charge des modules dynamiques permet des bindings vers des langages natifs (des projets comme Tree-sitter en sont des exemples représentatifs).

Avec la prise en charge de libvterm et de Xwidget, on peut aussi utiliser en interne un émulateur de terminal et un navigateur natifs..

https://github.com/canatella/xwwp

Le problème, c’est l’I/O et les threads.

Comme l’I/O n’est pas implémentée de façon asynchrone, les gros fichiers provoquent des blocages, et même si on crée des threads, cela prend en charge la concurrence mais pas le parallélisme, donc dès que la charge augmente, il finit toujours par y avoir des problèmes. 😢😢😢

Mais ce projet,

https://github.com/DavidDeSimone/ng-async-files

semble montrer des efforts pour prendre en charge le traitement asynchrone des fichiers, donc il m’intéresse en ce moment.

Et il peut aussi profiter du vaste écosystème de NPM.

[alstjr7375]

https://emacs-ng.github.io/emacs-ng/main-features/

Comme il s’agit d’une couche ajoutée de façon stricte, il est possible d’appliquer proprement les patchs de l’upstream.

Par exemple, j’ai essayé hier de fusionner la branche native-comp du miroir Emacs,

et malgré plus de 1 200 commits, il n’y a eu des conflits que dans 4 ou 5 fichiers.

https://github.com/emacs-mirror/emacs/tree/feature/native-comp

https://github.com/emacs-ng/emacs-ng/pull/185

[alstjr7375]

Finalement, j'ai rejoint l'équipe un peu par hasard haha

[xguru]

Waouh, c'est génial. Bon courage !!

[alstjr7375]

Merci !!