Comment by softirq
2 years ago
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.
Changing IDE isn't that big of a deal.
I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
If you worked in C++, then visual studio has been around for 20 years - visual C++ for 10 years before that. If you use java, then intellij has been around for 20 years. Pycharm for 15 years. If you're writing JavaScript, I don't know what to say because the framework du hour has changed so many times in that time frame that I don't think the tool saves you much.
> 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
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.
I think the way people use IDEs is a lot deeper than just reducing them down to "purist" or "ideologist". That sounds a tad bit dismissive for something that is essentially your trade tool. It's akin to saying all keyboards are created equal because they have the same keys. The way you lay the thing out and the perspective that you build it for matters quite a lot. Distilled in a quote, "the whole is greater than the sum of the parts."
I got used to JetBrains' key mappings when I was at my last company, I also adored their debugger. My new company uses VSCode and I started down the venture of remapping all of them to JetBrains keys. I ended up with a lot of collisions and things that no longer made sense because the keys were mapped using a different perspective when laying them out. I'm sure I'm not alone being in a pool of engineers that primarily navigate using their keyboard.
VSCode's debugger is better now, but it still doesn't really stand up to JetBrains'. On the other hand, launching VSCode on a remote box is much easier and their configuration is much more portable with their JSON based settings files. I like using VSCode, but it took me months to get up to speed with how I navigated, and more generally operated with, JetBrains' IDEs.
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.
The problem with these tools is that despite having worked with computers for 35 years, I don‘t get them. My brain is not made for them.
I only use out of the box vim when I work on consoles (which is still a fair amount of the time), I can exit (hey!), mark/cut/copy/paste (ok, yank!), save, and find/replace if I must. Everything else is just beyond what my brain wants to handle.
A lot of Jupyter lab and some VSCode otherwise. I can‘t say I know all about those either.
The last IDE that I knew pretty well was Eclipse, in about 2004. I even wrote plugins for it for my own use. That wasn‘t too bad for its time, I don‘t quite get why it got out of fashion.
1 reply →
> My point still stands that the community and open architecture are more important than any one editing feature.
No, it doesn't, because it's essentially a matter of opinion, not an objective fact that can be measured and proven. You prefer to have an open architecture and a community of enthusiasts. I prefer to have most of my editor features available out of the box, and modal editors just confuse me.
At the end of the day, developer productivity is not a function of their editor of choice, so what matters is that each developer is comfortable in the environment they work in, whether that be Vim, Emacs, IntelliJ, or VS Code.
2 replies →
> I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc. because they claim it makes things easier when they have to use an environment that they can't as easily configure, like sshing into a shared box without a separate user for them to customize. This mindset has always been hard for me to understand; not only does it seem like they're optimizing for the rare case rather than the common one, but it seems like they're actually just lowering the quality of their normal experience in order to make the edge cases feel less bad without actually improving them at all
> I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc.
This is me. It's really easy to explain my mindset here, though. If I get used to a nonstandard tool or tool configuration, then it causes real productivity issues when I'm using a system that lacks that tool or the ability to customize.
This is not a rare edge case for me at all. I constantly work on a half dozen very different platforms. Having each platform work as much like the others as possible is a quality of life improvement, and improves the efficiency and quality of my work.
1 reply →
> optimizing for the rare case rather than the common one
This has been a common enough case for me to not get too used to super customized local environments. I'd rather learn the vagaries of commonly available tools than build myself a bespoke environment that I can't port anywhere easily. That's not to say I don't do any QOL changes but I try to be careful about what I end up relying on.
I’ve usually had this attitude in the past and for me it came from my background: I worked IT, help desk, PC repair, etc for years before I got into programming and none of those contexts allow customization. And then for a while I did infra work where I’d be ssh’d into a vanilla VM or container instance to debug a deployment issue. Even though I mostly work in my own bespoke environment now, I still try to stay fairly vanilla with my tools. It’s pretty nice to be able to reset my workstation every year to get a clean slate and know that it’ll only be a couple of hours of customization to get back to what I know.
>I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
Vim police has issued your red warrants. Justice will be served.
Jokes aside, I'd say yes. I have worked with Eclipse, NetBeans, JB and nowadays I'm happy with VS Code. For a polyglot, it's the best out their at price point $0.0 and tooling is pretty good for me.
I'm doing Python, Go, Typescript and occasional Rust without missing anything.
Few keystrokes faster with command kata would not going to save years of labor. Actuall effort in software engineering is not in typing text or in text editing. Not at all. The battle is far far beyond that and bigger than that.
EDIT: Typos
just to add my $0.02 WebStorm makes writing NodeJS feel a lot more like Java - it's pretty good.
The best part is, you don't need to choose between using IDEs and your favorite text editor! Most modern IDEs with proper plugin support can be configured to provide a superset of Vim's functionality. I personally use IdeaVim on the IntelliJ Platform [1] with AceJump [2] and haven't looked back. You can import many of the settings from your .vimrc and it interoperates fairly well with the IDE features. Although I prefer Vim keybindings and it is technically possible to hack together an IDE-like UX with ctags and LSP, the IDE experience is so much better I wouldn't even consider working on a large Java or Kotlin project from the command line.
[1]: https://plugins.jetbrains.com/plugin/164-ideavim
[2]: https://plugins.jetbrains.com/plugin/7086-acejump
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.
> 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
4 replies →
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.
3 replies →
> 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.
2 replies →
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.
> that attract the best talent
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.
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.
Also, you mention "proprietary", but JetBrainsIDEA and VSC are opensource to some extend, which does improve community imho. But, the fact that they are less "open access innovation" projects, and more company owned is clear to everyone.
Finally: AI will come to software devt, and I wonder if AI tools will ever be available on true open access innovated IDEs.
> 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.
> Take Reddit and Hacker News as a fitting analogy
In so many ways they are not, but I see why you come to this conclusion. Some overlap in users.
To me opensource is "common good" stuff, HN and Reddit are "us playing on some one else's computer+software".
All options have integrations, gits, fzf's, etc. And AI is not just "another black box", it's going to save you a lot of typing very soon. This is good: more time for thinking and crafting; less time for boilerplate-y stuff.
> VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff
Do any of these finally have something remotely as good as Magit? Or a good email client?
I found JetBrains' Git better in many ways than my console flow. Tried, but never got into Magit, as I moved on from Emacs.
VisualStudio (not code) has a decent git interface. The "view git changes" window is similar to magit-status.
Although magit is superior for staging custom chunks from a selection. Most other tools seem to think a single line is the atomic unit of code and cannot comprehend 2 changes 1 on line can be chunked apart.
Er.... "VSCode+TS" ... wat?
ITT: people who have not used tools they're talking about with confidence.
Everything available in VSCode is available in (neo)vim, without a slow buggy UI, modals, misfocused elements, and crashes.
All the LSPs used by vscode are easily available, including copiolt, full intellisense, and full LSP-backed code refactors/formats/etc.
Neovim has been hugely problematic for me as an IDE (lots of plugins). Lots of errors related to OS dependencies I need to manually install and keep up to date.
I use VSCode every day and cant remember the last time it crashed or the UI glitched.
3 replies →
In my anecdotal experience the best developers are the ones that don't overly focus on their tools at all. One of the most proficient developers I've known was perfectly ok programming on a little square monitor with Visual Studio where the code window was 40% of the screen real estate.
It doesn't have to be that extreme but it reminds of hobby craftsman who focus on having a garage full of the tools of the trade while never finding the time to work on a project with them.
At some point in a developer career one shifts from a tool focus to a work focus.
I used to be picky about my operating system and often would spend time making the tools that I wanted or preferred to use work within the project dev environment, as opposed to just using the tools my employer provided. It usually ends up just being easier, and if everyone is using the same tools then pair programming or collaborating becomes easier, too, as compared to having to deal with the one stubborn dev who insists on using Emacs on a Mac when everyone else is using Visual Studio.
I think the benefits are when you already know the extent of your work and you can build tools to steamline you workflows. Now having something that you love working with instead of making you frustrated every day is very nice.
This has been my experience as well. The most productive people are the ones who actually focus on the work instead of wasting time configuring a perfect editor.
Mileage varies, even the most ardent vim user I know gave up and switched to VS Code this year. It's just too much to try to keep up with when projects and technologies change. I've programmed in C++, Go, Python, Java, and Angular just in the last year. I can believe that there's vim plugins to handle all those, but the energy it would take to find auto-complete and navigation and formatting and debugging and any number of other out-of-the-box IDE functionality is more than I'd like to thing about. Then there's the associated tools - Kubernetes yamls, swagger, markup, Makefiles. In IDEs they are only one plugin download away.
I love vim, I used it exclusively for years when I was doing C/C++. I still ssh into servers a lot and use it pretty much daily. Still, I'm far to lazy to try to turn it into my full time development environment .
> I can believe that there's vim plugins to handle all those, but the energy it would take to find auto-complete and navigation and formatting and debugging and any number of other out-of-the-box IDE functionality is more than I'd like to thing about.
Well, I'll be the bearer of the good news, then!
NeoVim has a native LSP client which unifies all auto-complete/navigation/formatting into a single plugin, only requiring you to install per-language LSP server.
As for debugging, there's also DSP (Debug Server Protocol) which NeoVim doesn't have native support for, but there's a plugin for that.
There’s more to language support than LSP.
I use vscode and IntelliJ these days. In rust, IntelliJ lets me rename functions and variables across my entire project. Or select a few lines of code and extract them into their own function. It’ll even figure out what arguments the function needs and call it correctly.
I’m writing a paper at the moment using vscode and typst (a modern latex replacement). The vscode plugin shows me the resulting rendered pdf live as I type. I can click anywhere I want to edit in the pdf and the editing window will scroll to the corresponding source text.
Maybe there’s ways to do all this stuff in vim but I never found it. I used vim on and off for 20 years and I barely feel any more productive in it than when I was 6 months in. As far as I can tell, IntelliJ is both easier to learn and more powerful.
Making nontrivial software in vim just doesn’t feel productive. LSP is the tip of a big iceberg of features.
2 replies →
Emacs also has LSP support built-in with eglot and a good start for treesitter support.
VSCode is a significantly more pleasurable experience working over a 100ms+ network connection than either vim or emacs (this being the reason why I switched away from emacs/tramp myself).
If you haven’t already, and I know this doesn’t hold up for GUI emacs or vim, but consider running them through https://mosh.org/
Mosh is definitely an improvement over ssh, especially for connections with lag spikes (and I use it for terminal sessions). But it's no match for VSCode.
Visual Studio Code is currently where all of the tooling effort is focused. For the best tools with the best integration you should be using it or, depending on language, JetBrains. These are easy to use and developers can be productive in them from the word go -- without extensive customization. Hell, if you open a file in a new programming language, VSCode will suggest plugins to install.
You do NOT want to build integrations by yourself. You want to build whatever product you're building. The fact that vim and emacs users do this is yak-shaving that pulls precious time away from the task at hand and serves as a distraction for editor fetishists. Do not become an editor fetishist. Modern IDEs help you become more productive faster and give you more support for things like debugging. (You are using a debugger to inspect and analyze your code, right?)
the ide is not more complicated than your customized Vim setup once you get it close to functionality (you won't). I use all keybindings anyway, so it's not like the UI adds anything bad?
I switched from lightweight editors to IDEs many years ago and my productivity went up A BUNCH - even if sometimes it uses gigabytes of ram. so what? Even my old used machines have 8-16gb of memory now.
I would honestly much rather hire people that work in IDEs than people that like to "hack" on their vi/vim/emacs setup. The number of times I've been in a screen share with someone while they're trying to code or debug something with Vim etc, it just feels so slow to watch them work that I get that embarrassed-for-them feeling.
>"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"
Nope. Not missing Vim. Live and let live