> Why would you continue to subscribe to a bullshit company that does this?
They said they subscribed which could mean that they have since unsubscribed. I think they’re texting them because they want them back as a customer - it makes no sense to pester your currently paying customers.
> Some of the packages are included, all of them have to be turned on and configured
I see where you're coming from, but I think this is a bit exaggerated as well.
For some concrete examples:
- Git: Emacs does have a built-in `vc-mode`, which can be used without any prior configuration by pressing `C-x v`. Or you can go to `Tools > Version Control` in the menu bar (if you haven't disabled it). Many people prefer to install Magit, but the built-in package is actually quite decent (the UX is a bit similar).
- You brought up LSP. Emacs now has a built-in `eglot` mode which connects to LSP servers, and is pre-configured to work with many of the open-source ones. You can turn it on by pressing `M-x eglot`, or go to `Tools > Language Server Support (Eglot)` in the menu bar. Many people prefer to install LSP-mode, but I think many people have also migrated to Eglot after it landed officially in Emacs.
> Every Emacs config starts by turning on the same minor modes hooked to prog major modes for simple stuff like bracket matching and line numbers. Every config sets the same early-init.el params to stop emacs from being slow.
I agree with you that the defaults should be modernized. For example, I think most people would appreciate if the defaults were updated to e.g. use one of the `modus` themes, automatically switch to a dark theme if the OS has it enabled, and enable a fuzzy-finder like fido-vertical-mode without configuration. All of these capabilities are already bundled with Emacs, just not turned on by default. I'd also advocate for disabling the blinking cursor and the bell - who wants that?
Just as a counter-example though, I don't have any of the specific settings you mentioned enabled:
- I dislike line numbers (they look weird if you work with soft-wrapped prose and they take up space)
- I don't like bracket matching (they don't work well with modal editing).
- I don't use the early-init garbage collector optimizations (Emacs anyway starts in a second as I use few packages, and leave it open all day so it doesn't matter).
> terminals whose keyboards lacked the keys vim users use to navigate in modal editing, and there's no reason for it anymore.
Vim keybindings really are more comfortable if you struggle with RSI. I’ve had such issues despite having used Caps Lock as Ctrl for years, and despite pressing it with my ring finger instead of pinkie. In my case, I have big hands and often have to work from small laptop keyboards for my job, which likely makes it worse.
The 3 times I’ve tried to go all-in on Emacs keybindings, I’ve after 1-2 months developed pain in my left forearm that then took months to heal. I developed some similar pains when I tried to use Sublime Text keybindings as well, but it was worse with Emacs. I blame this on excessive chording.
Except these excursions into other keybinding sets, I’ve used mainly Vim keybindings for nearly two decades now. I never had arm pains using Vim or Evil.
All this is to say: “There is no reason for it anymore” is too dismissive. The original reason Bill Joy wrote Vi the way he did was those constraints, but it has benefits today for other reasons.
For that example: Any reason the server doesn’t just have an SSH server? Then you can use `git clone` in the “usual way”, using SSH certificate authentication.
> If you are running servers passing passwords as command line arguments in that device, they have all that.
I make a point out of never doing that. It’s way too easy to accidentally expose things. For instance, doing a live demo with an audience, and using Ctrl-R out of muscle memory? Suddenly you flashed your password in front of everyone.
Generally, I’d recommend using a tool like Unix `pass` or your default OS keyring to store your secrets, then you can run `command1 --password=$(command2)` to feed a password from one command to another. If I really have to type something sensitive, I prefix the whole shell command with a space, which in many shells can be configured to mean that it doesn’t enter history. If you do so by accident, the shell history file can be edited in vim.
I don’t know Pyjion, but I have used Numba for real work. It’s a great package and can lead to massive speed-ups.
However, last time I used it, it (1) didn’t work with many third-party libraries (e.g. SciPy was important for me), and (2) didn’t work with object-oriented code (all your @njit code had to be wrapped in functions without classes). Those two has limited for which projects I could adopt Numba in practice, despite loving it in the cases it worked.
I don’t know what limitations the built-in Python JIT has, but hopefully it might be a more general JIT that works for all Python code.
> You'd really have to be a complete data engineering newbie to not understand it I think?
I do occasionally use Pandas in my day job, but I honestly think very few programmers that could have use for a data frame library would describe themselves as a “data engineer” at all.
In my case, for example, I’m just a physicist - I don’t work with machine learning, big data, or in the software industry at all. I just use Pandas + Seaborn to process the results of numerical simulations and physical experiments similarly to how someone else might use Excel. Works great.
There's not a lot of commercial demand for Tcl these days. Some people, like me, find that it fits their way of thinking and find its radical minimalism liberating. Many others do not.
They said they subscribed which could mean that they have since unsubscribed. I think they’re texting them because they want them back as a customer - it makes no sense to pester your currently paying customers.