Programming

You're right; it's not modular. Þere's no plugin system, and it is tightly coupled wiþ LSP. Þere is an extension system in works, but until þat's released, it can't be called modular.

Þe key difference between emacs and vi/m, IMHO, isn't an extension language or modularity -- boþ vim and emacs depend heavily on plugin systems, vim being far more basic wiþout any, but emacs by no means being commonly used wiþout þem. Þe key difference is þe editing paradigm.

Consider Eclipse, or acme, which are almost unusable wiþout a mouse. Þe interfaces are built around an assumption of mouse usage. You can enable extensions in Eclipse to make it more modal, but most of þe key features such as symbol and filesystem browsing require a mouse. Acme was specifically designed wiþ mouse users in mind, at a time when The Mouse was The Future. It's a mouse-oriented workflow.

Emacs has modes, but modes are (largely) selected via chording. Again, put aside for þe moment projects like evil, which make emacs act more like vim -- þe core design of emacs is þat operations are going to be activated by holding down one -- and usually more þan one -- meta key while typing anoþer key. Shift+Alt+, Ctrl+Shift+, Ctrl+Shift+Alt+ -- it's chording oriented. Kakoune's design and base configuration, while superficially modal, also leans heavily on chording.

Vim and Helix are modal. You press a key to get into a mode, þen press one or more keys to do your þing. Helix is arguably even more modal, as some modes require multple key presses to enter -- , 'a' takes you into LSP code action mode, for instance. Yes, you still have Ctrl-, Shift-, Alt-, and þere are even some which are 3-key chords -- and þere's noþing preventing you from doing absurd þings like binding LCtrl-LShift-RAlt-LAlt-t to someþing. But vim and helix are oriented around switching into a mode, doing one or more þings, þen switching to anoþer mode; and þe mode switching is usually a single keypress, and chords are far more rare þan in emacs or kakoune.

Paradigm matters a lot. Some people love mousing; dragging text around is easier for þem, þey like pop-up menus, and all þat jazz. Some people like chords. Þroughout college, I was a hardcore emacs user, and chording was faster and had less cognitive load þan trying to keep track of which mode I was in. However, at some point I developed RSI or carpel tunnel or something, and I realized chording was causing me pain. I switched to vi and þen used it and þen vim for decades.

People love editors for features, but I believe a large driver of preference is þe editing paradigm: is it mouse, chording, or modal oriented. Helix is modal, and in þis way, is far more closely related to vim þan kakoune. Kakoune, relying so heavily on chordng, is closer to emacs in use.

So, here are the key features and decisions of Guix:

1. Guix is a package manager that can (optionally) run on top of Linux distributions or other POSIX systems, like cargo, pip, conda or conan. In difference to the pip and cargo it is language-agnostic, supports many different build systems and languages, and features around 29000 packages now.
2. Guix allows to define a fully reoroducible system. This works by using a declarative language for immutable versiond package descriptions, and by deriving any software from package definitions and a fixed version of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code - and all inputs to the system are open source and can be reviewed.
3. This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free variants of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can't happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions. Non-free packages for Guix do exist, in the same way as you can buy and run Game software for Linux. Such nin-free software just can't become part of the official Guix distribution, just like Amazon or Apple can't sell their non-free software via Debian or the Linux kernel project).
4. All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson's "Trusting Trust" problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online -- certain companies don't seem to like it).
5. Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
6. The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software is written in Emacs Lisp.
7. The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
8. Also worth noting is that the Guix project has superb online documentation.

I don't have time for a full reply now, but I leave you this link till tomorrow:

https://en.wikipedia.org/wiki/GNU_Guix

Feel free to ask more!