softirq

GUIs and proprietary protocols have killed Emacs.

Emacs isn't an editor, as the post implies, it's an environment. "You can do anything from Emacs" made sense back when everything was open and text based. Nowadays everyone is using Slack, or using an IMAP web client for mail that requires bespoke authentication, or organizer apps that automatically sync across all your devices via the cloud. All of the verticals have been slurped up by corporations who did it better in GUI, have better syncing, and have locked down the protocols needed to bridge, and now the brave Emacs user of 2024 is forced to spend lots of time not in Emacs, thus defeating the point of using Emacs.

As an editor alone I don't think Emacs is worth it. There's the old adage "They added everything to Emacs but a good editor" and I think that makes sense. If you're not going to live in Emacs for the above reasons then Vim/Neovim is a better editor with a larger community, and VSCode/Jetbrains are better IDEs that are already adopting AI, which will essentially kill off Emacs.

Emacs still has a lot of important lessons, but I feel bad for new programmers today who will never get the full experience of a text based digital life. Everything has been dumbed down for our own good, and Emacs is now nothing more than a glorified Org editor that forces you to find your own cloud syncing.

But it does mean that the kernel ABI is never stable for kernel modules. In RHEL, the ABI is frozen for point releases.

I have looked at Doom, etc. but I'm definitely turned off by the level of complexity of these "distros", especially Doom, which is essentially more divergent from Emacs than Vim. Multi-thousand line config, it's own management cli, documentation, packages, etc...

Since I'm looking to "learn" Emacs I'd love to start with Vanilla and add in things as required as you would with any other editor. Starting with something like Doom makes it near impossible to untangle what is coming from where and trim down to exactly what you want, which is sort of the point of using Emacs in the first place.

It's funny, for 2024 I decided to take a crack at Emacs after 15 years of Vim. I forgot how absolutely horrible the new user experience is. First write a bunch of config to undo all the bad settings and nonsense that comes with the stock editor, then do three days of Googling to add basic features like fuzzy finding, LSP, VCS support you would expect to be built in in 2023.

Not saying Vim is any better, at least there's a package manager and they decided to include eglot in the base. But man, sometimes I wonder if we're all suffering from Stockholm syndrome and we need to break out and just remove the bad defaults and add in the damn stuff we all know people expect in an editor in 2023 and write it into the tutorial.

The fact that he doesn't mention context as a huge failing of Go is very suspect...

I also find the post a little too self-congratulatory for what was essentially a reinvention of C with a GC at the right time, and not just C the language, but C's philosophy on programming.

I think as Go has become more popular, the core of C has been drowned out by people coming from other languages who insist on too many libraries, too many abstractions, generic solutions at every level, and more features. Go today has essentially moved much closer to Java, and some projects like Kubernetes are without a doubt just Java projects with a slightly different syntax.

Concurrency and interfaces I think are also a big fail in Go.

Interfaces because they failed to add enough of them to the standard library for simple things like logging, filesystem access, etc, causing numerous incompatible implementations, which is something that wouldn't have happened if they hadn't been so gung-ho on interfaces being defined where they are used instead of having community interfaces.

Concurrency is harder to summarize, but day to day you still get locking issues, libraries that don't expose interfaces that are easy to work with via coroutines (which is ironic given rob's finger pointing at async/await coloring), and as I said context is really a prime example of why CSP IS a bad model compared to mailboxes and the Erlang model of concurrency. Every function has to take an extra noisy argument, every function has to wait for a ctx cancellation, instead of just baking the semantics of cancellation into the language itself.

When I joined FAANG #1, JetBrains wasn't an option, and all of our work had to be done on remote servers, with code bases big enough that indexing took on the order of hours. Meanwhile there have been internal communities at all of my companies for Vim and Emacs to make them work in these environments, write plugins for various company services, etc. None of the editors or IDEs we are talking about struggle with any of the common tasks you mentioned, what something like Vim allows is extensibility and portability, and communities that support it no matter where you need to use it.

I do believe that for some use cases, like a person who unfortunately only works with Java or Android, JetBrains makes sense and is probably your only option. I believe outside of those environments, JetBrains offers no tangible benefits and plenty of downsides - cost, resource consumption, can't be run in a terminal, not easy to work with remote machines.

By the way, vim already has built in support for cscope, ctags, autocomplete, terminal windows, gdb debugging, if you work on a C-like project, it already is an IDE. With one plugin (Ale) which takes one line of config, you get an actual IDE that can auto-detect LSPs which offers refactoring, code actions, etc. that is the exact same you would get in an IDE. But for very large projects, I have found that CLion and Clangd both take far too long to index, and so having an editor that works without indexing is a huge plus.

Learning curves are uncomfortable, so by your logic we should all always take the path of least resistance and use the tool that makes things easy up front without considering the long term benefits of using something like Vim or Emacs. I find this to be counterproductive to having a great career as a software engineer.

Rapidly assimilating difficult to understand concepts and technologies is an imperative skill to have in this field. Personally, I find the whole notion of Vim being difficult to learn, or not "ready out of the box" perplexing. Writing some code that's a few hundred lines or less, where it's mostly just importing git repos, is easy. Vim has superb documentation. How hard must regular programming be if it's difficult to just understand how to configure a text editor?

I heavily disagree. From experience, working over SSH with tmux allows me to work with my editor, run commands, start up various qemu instances, start debuggers etc, and other tools that have their own TUIs. I think remote VSCode makes sense to people who have very narrow needs to edit specific projects rather than live on a remote machine.

As I said, I have worked at several FAANG companies where people had to wait for editor integrations because the source repos were so big you couldn't work locally. Having a tool that works everywhere no matter what has been incredibly valuable to my career. I also wouldn't say working for one of these companies that pays very well and handles a large portion of the world's traffic is obscure.

A person using Vim or Emacs has had best in class integration with the unix environment, modal editing, and remote development. Today, both editors have integration with VCS via fugitive or magit, fuzzy finding, LSPs, tree sitter, and code generation tools using LLMs. These tools have not stagnated, they've continued to evolve and stay best in class in many areas. So the "one tool is better than the other" argument doesn't really sway me. My point still stands that the community and open architecture are more important than any one editing feature.

> Equally, I can say purists or idealogists are so concerned with theoretical changes and breakages, and so afraid of the possibility of something changing that they miss out on game changing improvements to tooling.

Blindly following the crowd is also dangerous. Making choices based on principle is what allows good things like open source communities and solutions not swayed by corporations to exist, even though they might require more up front investment.

I think you missed the point of my post. The value of Vim/Emacs isn't the modal editing or key chords. It's the community and architecture, which you lose if you're still using JB with a frankenport of Vim on top. In fact, I think what you're suggesting is the worst of both worlds - a reimplementation of Vim on top of an already resource hungry and complicated IDE that's supposed to let you do things with a mouse. So you're left guessing whether something from real Vim will be the same in your Vim, plus you now have two competing environments for ways to do things, and you have to wait for JB to implement features that (neo)vim have already implemented, without supporting the opens source communities that did the work in the first place.

You also lose the killer feature of Vim, which is being able to work over an SSH connection on any sort of device, even those that don't have a GUI.

> I've seen hugely talented folk on vim/emacs/emacs+evil, and on VSCode/JB. I think was the latter tools do, it make some of the advantages of being proficient in vim/emacs/regex available with less learning curve.

Take Reddit and Hacker News as a fitting analogy, a community with a higher barrier to entry/more niche will be smaller, but the quality is vastly improved. There's still going to be people who sit in both communities, and smart people in both, but it's not controversial to say that an initial learning curve tends to attract people who can pass the learning curve and are motivated to do so. Another great example is the linux kernel development process.

> Currently there are some combinations that simply best-in-class: VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way in these areas, but cannot beat the integration level offered in these combinations.

Integration in some ways, in other ways a terminal based tool that adheres to the unix philosophy is more integrated with thousands of tools than an IDE where every tool has to be converted into a bespoke series of menu items. Just look at fzf, git, rg, etc. integrations in Vim. They are only lightly wrapped and so the full power of the tool shines through, and it's easy to customize it to your specific needs, or add more tools.

> Finally: AI will come to software devt, and I wonder if AI tools will ever be available on true open access innovated IDEs.

In the same vein, AI tools that act as black boxes and are integrated in the same transparent way as git or rg in Vim at least allow the editor to remain full transparent to the end user, and leave the complexity in the LSP or bespoke tool. I really see no difference between how AI tools will relate to editing as LSPs do today.

Vim is the only tool I've been able to use at every place I've ever worked at, from intern to staff engineer in three FAANG companies. I've watched tool teams spend months integrating the latest GUI editor, only for it to get killed by corporate acquisitions and replaced with N+1 that offers an almost identical feature set.

Meanwhile there's always a community of vim and emacs users who build all the internal integrations by themselves. Vim and Emacs aren't editors, they're platforms and communities, and the benefit of using them over VSCode of JB is that you get to be a part of these communities that attract the best talent, give the best troubleshooting advice, and share advanced configurations for everything and anything you could possibly ever want. They are programmable programming environments first and foremost, and that attracts people who are good at programming and like to hack on stuff.

Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways, least of all is the actual editing experience. A craftsman should understand his tools inside and out, and picking something you can't fully disassemble and doesn't have the breath of knowledge a tried and true open source tool ultimately becomes just as frustrating as the initial learning curve of these older tools.

The reason I stick with vim/emacs isn't because of the "fast editing", it's because they're modular and easy to build plugins for. I've built many job specific plugins for both editors as well as wrapped new command lines tools this way, and it's always increased my productivity far beyond what modal bindings has done for me. This is how I've been approaching LLMs, by building my own plugin. I build my own tools that behave as I would expect them to, which is generally to get out of the way unless I ask for them, and work in a pipe like manner.

Having a programmable programming environment with an open source core that's easy to dissect is really what modern editors lack. Also, having a piece that can't be removed or a black box doing who knows what with my code is hard for me to even wrap my head around. To each there own.

kvm/libvirt are the industry standard solutions for enterprise linux based distros, and I know for a fact, that multiple mega-corps use it at scale. Pretty much anything Linux based is going to have the best support path in 2023 vs. something made by a company that's being sold over and over again.

99.99% of the development of open source distros is done by mega-corps. IBM, Oracle, Google, etc. all have complete control of the Linux ecosystem. The only difference is that they have to play nice with each other, not with you, the user. You also get the worst possible experience because they have no incentive to make the desktop experience better.

You better stop using your kernel then.

If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and the robustness of static typing that directly impacts the quality of the end user experience and the readability of the code to other developers?

At that point, why not just use Go? It's designed to feel dynamic, provides concurrency primitives out of the box, and it's orders of magnitude faster for most tasks.

What isn't modern about neovim or emacs 29? Does a tool have to be graphical to be modern?

What's so hard about adding 5 lines to a config file? You're adding 100s of customizations that slow down emacs when you probably use a handful of them at most.

Yes, there's nothing special about the kernel upgrade. You either reboot or kexec.

Been using Fedora Silverblue since its release and it's absolutely the future. ostree is what everyone should be using.

The only metric that matters for a game system is whether people enjoy it or not, and by that metric D&D is a massively successful system that's succeeded in table top and video games. Normally people know that it's a game and not real life, it doesn't have to 100% make sense if people are enjoying themselves. Don't be a stick in the mud.

It could be named nodejs-api then.

Might want to think of a different name, napi is an API in the Linux kernel, a space that Rust is targeting. It's going to be super confusing searching for napi driver implementations with this node thing out there.

If you are familiar with Go, it's similar to a goroutine that waits for someone to send it an anonymous function to start executing. In Erlang, you solve problems by spawning lots of processes, and most processes are waiting to accept messages. One critical difference is that in Erlang, processes can run on remote machines, seamlessly. This process accepts a message which is a tuple containing the atom become, which is basically just an enum, and a function. Another process, such as the Erlang shell, can send this tuple message with the function to this process at any time so that it "becomes" that function.

What he is saying is that you can swap out the logic of this waiting loop with whatever protocol logic you want. His example was that he had a fleet of machines that were running this loop, and he sent all of them a function that implemented a gossip protocol. But he could easily send them all another message that turns them all into BitTorrent clients.

Joe was an absolute genius and an extremely kind person. I had the honor of meeting him once. Erlang is still one of the most beautiful technical creations I've ever encountered. It really does make you see concurrency in a whole new way.

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system

And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful languages.

In under a decade Go swept up entire markets with a simple, down to earth language you can learn in a day and keep in your head. It optimized for the masses and the common cases and has absolutely eaten the lunch of these languages with lauded type systems that takes several courses in formal logic to even get started with.

Eh, just going to stick with mutt.

The point of them owning LXD is to give them total control of the underlying technology they are using for Snaps. Snaps is the play… has nothing to do with kube/docker. It’s actually more of a synonym of ostree and flatpaks.