When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.
Vim is not really an editor. It is a way to edit text, you can use vim in almost any environment. You are also totally wrong about vim or emacs not having code completion, that is just nonsense.
I use (a version of) visual studio, the first thing that I did was installing a vim extension.
Also vim itself already supports almost any of these features with some basic plugins for the completion logic. If I type "." in my vim I get the same thing I would in visual studio.
If you are saying "vim is bad because it lacks X IDE feature" you are missing the point.
Vim: I can do that too, I swear! Just configure some plugins, can’t tell you what they might be though. But I’m turing complete, and I’m the best!
VScode: Of course I can do autocomplete bud. Here, search my package repo, I’ll tell you which plug-ins are the most popular and handle the entire download and install process for you.
Visual Studio: Of course I can autocomplete! Hold my beer while I bring your machine with 16 cores and 64GB of RAM to its knees for multiple minutes ;)
EDIT: I'd also hardly call VSCode "performant", either, at least compared to the multitudes of editors that don't pull in a full-on browser engine for basic text rendering... but yes, it is indeed "performant" relative to Visual Studio.
I used to have that issue 5 years ago but since then it opens under 5 seconds and loads the solutions I need for not much more. Currently using it on a cheapish recent windows laptop but even on a 8gb x220 it works fine, just loads for 30 sec in the beginning and then it's smooth.
Granted I'm only opening .net solutions with under 100 projects each but anything above that is unnecessarily more difficult to navigate with just vim.
And in my experience VSCode is many times slower than Visual Studio on the same projects. None of them are as fast as barebones sublime or vim on an m1 mac but when I load the latter with plugins it's not a huge difference.
They’re different experiences for users with different priorities.
Your priority is evidently ease of configuration, VScode is definitely easier out of the box - there is no comparison.
My priority is hackabilty for streamlined editing and code navigation. Here neovim run circles around vscode.
Neither is “right”, just different preferences. Note that I’m not here to tell you my editor is better, I personally enjoy using it more, and that’s enough for me.
"My priority is hackabilty for streamlined editing and code navigation. Here neovim run circles around vscode."
I hear this line a lot from hard-core vim users, but it's always talked about in the general. I'd like to hear a specific use case and exact scenario where a common workflow is faster in neovim over a more full featured IDE like JetBrains or Visual Studio.
> Why do you even reply to a post that you didn't bother to read? VScode is a neovim frontend.
I did read your post Mr. snark.
> There literally is no comparison, because there is a category error.
Pure pedantry. VScode takes far less effort to get a high quality feature set when compared to vim. That’s the only point of debate that matters for most people.
I think OP wanted to make a categorical difference between vim-the-editor vs vim-motions. The latter of which are supported in all major IDEs as plugins/extensions.
For the people responding to you who are saying you can get all the same things in vim, they're right of course, but a lot of this modern functionality is now built on top of the Language Server Protocol[1], which is an open standard created by microsoft for VS Code.
Kudos on the people who have ported this to Vim[2], but I suspect the support for LSP features will still be better in VS Code
Code completion, search, cross referencing, and all sorts of other features in vim, emacs, and all kinds of other editors (including Visual Studio) predate LSP by decades.
LSP is cool though, an advancement certainly, but it is not a completely new thing.
If you think ctags or rtags are even remotely comparable to what an actual IDE brings you you have absolutely never used more than 10% of what an IDE with semantic understanding of your code can do
it brings up "Code completion, search, cross referencing, and all sorts of other feature" and again, those work much less well in ctags / rtags than with a proper IDE
Kind of a perpendicular discussion but it amazes me that with this language server thing hipsters turned what was a very mature and proven pattern (a plugin architecture) into a distributed software problem. My god talk about doing shit the hard way...
The plugin architectures that I've seen require plugins to be written in the same language as the IDE. For example, Eclipse plugins need to be written in Java.
Language servers run in a separate process to the editor, and they communicate over JSON-RPC. The nice thing about this is that the language server can be written in any programming language - which usually ends up being the language of the code being edited, rather than the language that the editor was written in.
This makes it a lot easier for language servers to be written and maintained by the people who maintain the compilers for those languages, e.g. gopls is written by the Go developers, clangd is part of LLVM.
LSPs turn a M*N problem into an (ideally) M+N problem. You can't do that with any existing single editor's plugin architecture, basically by definition.
Ctags is a better analogy, and LSP has fairly obvious advantages compared to it.
I remember using Visual Studio in college (back in 1999, 2000) and coding circles around folks who were using text editors.
These days, I use Neovim + LSP for a pretty decent approximation of an IDE-- it's quite good. Still not as good as Visual Studio + C#, but I'm on Linux now, and not writing C# anymore, and I definitely prefer an open-source, general purpose, light-weight, customizable editor.
> When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.
I can't speak for Vim, but Emacs has stepped debugging, code completion, etc.
Part of the reason I use Emacs is that I get those features and (and a ton more) with the same light weight interface across multiple languages and platforms. At the same time, it's usually very easy to make Emacs work with third-party tools. On Linux I can step through code using GDB through Emacs, but at work I spend most of my time in Emacs, but have it bring up the MSVC++ debugger when I need it. It's the best of everything.
Meanwhile, I get to listen to my coworkers celebrate new features in VSCode that I've used in Emacs for years...
There are no bonus points for learning a new IDE for every project, either.
Wait until you learn about these 2002 technologies called "extract method", "inline method", "encapsulate fields", "extract interface", "extract local", "inline local", "rename", plus about 200 code inspections...
When I was a kid learning to code, programming books recommended stridently against even using syntax highlighting. It's funny how helpful things get rejected by people who "did it the hard way."
> When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.
Why do you think they are doing things "the hard way"? Emacs can have all the things you have described. And it can do that for languages that are not part of the .NET Framework, they just have to have a language server implementation.
The problem with "IDEs" was placing all your eggs into a single basket. You are on Visual Studio and then you need to do some Java(or Scala, or whatever). And now you have to get another IDE. Some tried to be one IDE to rule them all (Eclipse, Netbeans), didn't work all that well.
You need a good editor - most IDEs don't have one. You need integration with your language of choice. You need compilers and linters and a bunch of other things. Better to glue components that do one thing and do it well, than having one IDE trying to do everything. And those components can fell just as integrated.
>Why do you think they are doing things "the hard way"? Emacs can have all the things you have described
In the first few years of my career I would try every few months to get these things actually installed and working in emacs. It was definitely the hard way.
>The problem with "IDEs" was placing all your eggs into a single basket
Eclipse is a uniquely terrible piece of software and I understand why it might polarize people against IDEs for life. The JetBrains products are pretty good and, importantly, modular and consistent enough across languages that I don't mind.
I believe they’re talking about a different “hard way” in that they’re suggesting you can’t have those features in vim / eMacs etc and have to do something else instead.
You’re not wrong, configuring these editors is 100% the hard way (that doesn’t stop me from doing it though).
IntelliJ and VSCode have both worked pretty well with anything I've thrown at them, I'd consider them both fairly successful as IDEs "to rule them all". Obviously they're both very different ends of the IDE spectrum, but they've both had intellisense, debugging, type revealing, and refactoring features for all the mainstream languages I've tried with them. VSCode particularly tends to integrate well with LSPs.
emacs has plenty of plug-ins that turn it into an IDE. For people who are already comfortable with it, these tools are great. I’m more productive in it than with “modern” tools. For newcomers the learning curve is going to be steeper. I’d recommend learning at least either vim or emacs (or perhaps other text-based editors with similar features, if they exist) though, as it does provide versatility for oneself. Those GUI IDEs aren’t available in every environment where one might want to code or debug.
> I’m more productive in it than with “modern” tools.
Are you objectively more productive, or do you perceive yourself to be more productive?
I was an Emacs diehard for nearly two decades. Then I got introduced to CLion. In retrospect, Emacs was an inferior tool.
While it's certainly true that Emacs can be configured and extended to do all sorts of interesting things, I do suspect many of its users are deluding themselves when it comes to the sheer breadth and depth of functionality offered by a modern IDE. It also doesn't help that its maintainers are living several decades in the past, and haven't kept up with what the "competition" are doing.
I'm certainly not implying that Emacs is a poor editor. Very few IDEs have text editing capabilities on par with that. But its integration with other tools doesn't hold a candle to today's IDEs.
Both Vim and Emacs have plugins for intelligent code completion and viewing inline documentation. I personally prefer to use VS Code or Jetbrains IDEs with Vim emulation, but I've seen setups for both Vim and Emacs that basically made them into full-fledged IDEs.
Full-fledged Plugin-based development environments. An IDE is an Integrated Development Environment; it comes with the features necessary for efficient development built-in.
> there are no bonus points for doing things the hard way
Perhaps not from the technical perspective, but there are social advantages if you are a member of a clique that does things the hard way and considers it a sign of competence. ("Any idiot can write a code that compiles using autocomplete and syntax highlighting, but it takes a true master to achieve the same result using a decades-old Linux equivalent of Notepad.") They don't seem to understand that the ancient masters did things the hard way not as a pointless exercise, but simply because the easy way was not available back then.
Everything is pretty much just language servers behind the scenes these days anyway. Neovim supports those natively, so those young chaps aren’t talking about your vim of yesteryear.
