Hacker News Reader

Comment by softirq | Hacker News Reader

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.

View on HN

> 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.

In the last decade, I can count on one hand the number of times I have SSH'ed into a machine to do actual editing - and in every situation, nano would have been totally fine. Crippling my workflow so I can handle the most obscure scenarios that we've moved past for the most part, is not a good decision

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.

> I can count on one hand the number of times I have SSH'ed into a machine to do actual editing

Both companies I've worked at previously employed zero trust networking. That means developer laptops don't have privileges to things like secrets management infrastructure or even feature flag config. You end up making a choice: mock services that require trust, which comes with its own set of dangerous tradeoffs, or build remotely in a trusted environment. Many devs choose the latter.

decade and a half for me and even then I remember telling my tech lead, this feels like the stone ages

> In the last decade, I can count on one hand the number of times I have SSH'ed into a machine to do actual editing

And I need to do this multiple times every workday. Generally speaking, this isn't an obscure scenario that we've mostly moved past. It's just not a common scenario in your particular work environment.

I assure you, the open source community around modern IDEs is thriving. I see plenty of innovation in plugin marketplaces that is hard to find in even the Emacs/Vim ecosystem. Despite its share of detractors, there is a lot of value in having a business model that prioritizes language support, platform stability and a well-curated plugin marketplace. The IdeaVim integration is thoughtfully designed and I seldom notice much difference coming from Vim. I see where you're coming from with resource consumption, but even Fleet is starting to offer rudimentary Vim support, which I expect will address many of the issues around bloat. [1]

[1]: https://youtrack.jetbrains.com/issue/FL-10664/Vim-mode-plugi...

I'm a happy ide with Vim bindings guy. We do exist.

I think in vim edit patterns when editing text, but I don't particularly care about most of the : commands. I'm happy to use the vscode command palette for that.

> 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.

The gold standard for remote development is Visual Studio Code. All of the UI stuff happens locally, and it transfers files and runs commands remotely. It's way less chatty than going over SSH or an X11 connection.

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.

The terminal window from VSCode still gives you all of that, with some extra ergonomics from the GUI. No need to remember ctrl b + % to split a Tmux window, scrolling and find just works, no need to install plugins to save sessions.

Can you save your session? I think I have a tmux session running for months now on my vps. Everything is exactly the same when I connect.

> The value of Vim/Emacs isn't the modal editing or key chords. It's the community and architecture

These are empty words that have no meaning. I don't use my IDE for "community" or for "architecture". I use my IDE for writing code, navigating code, finding code, refactoring code, exploring unknown code bases, analyzing code, moving code around, reading code...

How many of those things have the words "community and architecture" in them?

> you have to wait for JB to implement features that (neo)vim have already implemented

You mean the other way around. Nothing NeoVim implements trumps the depth and breadth of features IDEA offers out of the box. NeoVim (and others like vim and emacs) is busy re-creating, with great delay and poorly, a subset of a subset of features of a modern IDE.

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.

> I do believe that for some use cases, like a person who unfortunately only works with Java or Android,

Your bias is showing through :)

If people had less bias and actually looked at what an IDE can and does offer, they wouldn't be dismissive with "oh, if we just add these 12 plugins and an integration, then for this on particular language we may have a full IDE" (in actuality, a subset of a subset of all features an IDE offers).

> 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.

Looking at the "huge" list of features that Ale lists consisting of 6 very basic things, I again see that people who use vim have never ever in their life used a proper IDE.

> and so having an editor that works without indexing is a huge plus.

This I can actually agree with :) Indexing is often such a pain

It's very telling who has had to actually support prod systems and who hasn't when it comes to this topic. Very often the only interface we used to have before better CI/CD pipelines and idempotence was a serial tty or ssh connection. There were a lot of sysadmins run off in the 00s (for various reasons such as increasing salaries) and a lot of institutional knowledge about real operations such as this was lost or diluted.

Another reason why I like to encourage people to not customize their vim/emacs too much (at least for the first year or so of learning) - because when it's 0300 and prod is down you don't want to fight your tools to match your expectation. Another example while HN loves to hate on bash, but I love and live in bash.

The names and titles have changed, but I still see the same dev/ops battles.

Reply on news.ycombinator.com