Language servers are very exciting for me. This past summer I finally installed ALE [0] and it drastically improved my experience and code quality in JS. The live in-editor linting with eslint and formatting with prettier is awesome (and these aren’t even language servers, ALE just uses them as “fixers” and “linters”). So many people denigrade these things as “crutches” for bad programming languages or underdeveloped skills, but I don’t know how you can beat getting live feedback as you type. We are mere mortals! If you don’t have something like ALE installed and you use Vim, you won’t regret the time spent getting it up and running.
So many people denigrade these things as “crutches” for bad programming languages or underdeveloped skills, but I don’t know how you can beat getting live feedback as you type.
As someone who turns off autocomplete and other features when forced to use an IDE, and otherwise works entirely with code in a plain text editor (sometimes Vim, sometimes Notepad --- and sometimes just good old pencil-and-paper), I can tell you that "live feedback" is a distraction. It interrupts the thinking process like a backseat driver.
In all seriousness, I think you might be smarter than me and many/most people. What languages are you referring to? The above described setup really helps me with JS. IntelliJ really helps me with Java (I spent about a year trying to write Java in Vim!).
I agree that is nice idea but sadly only the JS server improves my experience compared to the alternatives, which is more an indictment on the JS toolchain than anything else. And even then its jump to definition leaves a lot to be desired. For example Robe jumps to a method inside Rails that was defined at run-time w/o any issue. Solargraph, even with experimental features enabled doesn't. I look forward to a future where language server implementations improve.
Which JS server do you use? I tried Webstorm a while back, for example, and found it overwhelming. It tried to do a lot of things it couldn’t do well, so there were many false flags and failed refactoring, which is really frustrating if you’re coming from Java.
One major advantage of Jetbrains products which I realised after getting a corporate job is I don't need almost any plugins and the experience out of the box is better than anything offered by vim or emacs(granted this is subjective). One major advantage is I don't need to worry about licenses of plugins or having a trust relationship with plugins, which is very essential as I don't want something like the kite episode to happen on my PC. (The kite episode was a company buying some open source plugins for atom and sublime and adding invasive telemetry). If you use jetbrains products, you need to trust only one entity. When using random plugins you are always in the danger of some malicious plugin sending your IP to some random server (rare, but worth keeping in mind.
How often are you limited to out-of-the-box configurations? I've configured vim to my liking once, uploaded my dotfiles, and now I can have the same config everywhere. There's no need to repeat yourself.
Not to mention the productivity increase from having a blazing fast editor that just gets out of the way. Even on my beefy laptop, intellij products feel clunky and slow
I’m amazed. I’ve been using Vim for, oh I don’t even want to count how many, years. My .vimrc is constantly improving. To the point where I ask myself how healthy the obsession/addiction is.
I don’t think I’ll ever make up in efficiency for the time I’ve spent tinkering. But it sure is fun. Mostly.
I’m still quite good at stock Vim though. Specially since recent distros have been shipping a much saner default .vimrc
> My .vimrc is constantly improving. To the point where I ask myself how healthy the obsession/addiction is.
I have to concede that this _was_ my experience until about a year ago. I can recall spending many evenings and even some lunches reading and experimenting with vim configuration improvements. I too wondered if the time would pay off.
Vim has been my main editor for 8 years. About a year ago I started to notice that I was no longer spending much time at all changing my configuration; however, I was aggressively deleting plugins and complex (most-unused) key-bindings.
These were replaced with intrinsic key-bindings that I didn't previously know about they were replaced with more modern and simpler plugins. I suspect this will get even better once adopt Ale and plug.
The smaller config is oddly satisfying. I'm happy that I've stuck with Vim as it continues to provide me with a full-service experience, while getting faster, not slower, yet my config continues to get more minimalist.
I don't think there is anything out there that compares, but it's an investment and YMMV.
The vim configuration process can be easily automated. I too put .vimrc on any machine I use vim on. The problem is auditing. Do you have time to audit the plugins you use? Do you keep up to date with their changes(license, policies), or simply run :Vundle update or :Plug update. In vim the configuration process itself is not that cubersome, just that the trust surface is very vast, whereas in IntelliJ I need to trust only one single entity.
Nothing updates unless you do it, but then once the update is done you can optionally go through the commit log of each plugin and even revert back specific commits if you don't like what you see.
To me that's a much better model than "hi, I see you opened your code editor, let me auto-update these 10 plugins for you. Hopefully things work out for you!".
IMO the user (you) should be in total control over when things get updated. This goes for the editor itself and your OS too. Otherwise you have no idea what the state of your system will be the next day.
As a counter point, JetBrains almost certainly uses Open Source libraries in their products. You can say you trust that they've vetted every single version of every library they've ever released and all their transitive dependencies, but the likelihood they've actually done that is slim to none (else it would be item #1 in all their marketing material)
You got a point, and this reminds me of the kite debacle with sublime . However, there's a difference. Sublime plugins update automatically startup, while mine are updated manually. If I theoretically wanted to, I could audit the plugins one by one.
I'm not sure I would trust jetbrains - it's closed source and I don't know what data they're phoning home, or telemetry. With vim at least I have the possibility to audit. With a closed source product, it's way harder.
I'm a big fan of JetBrains, but that really depends on what languages you're working with. For example, both Rust [0] and Clojure [1] require third-party plugins. However, I don't think it automatically installs plugin updates, so you could manually review new changes every few months.
Let me give you a counterpoint. I have worked at two companies in FAANG now, and I've also worked on the Linux kernel on ethernet drivers. None of those situations allowed the use of Jetbrains. In fact, I've never worked for a place or on a product that didn't allow for vim.
Sometimes you will also be required to work from a remote server. I'm not talking about to fiddle bits, I'm talking about real development.
There is also a lot of downsides to not working from the terminal. Vim users are consistently better interviewers because they spend more time interacting at the system level. There are a lot of disadvantages to working with an IDE that turns valuable knowledge into a series of black box buttons.
I don't think there is any issue with Vim itself, and can't see why any place would disallow it. I still use vim on remote servers, and am quite happy with it. Being proficient with vim helps you do things faster for sure. The issue I was raising was to get functionality even comparable to jetbrains products, you need to install a good amount of vim plugins, and then you either audit them constantly, or place a lot of trust in the maintainers. You don't need any of that with jetbrains.
I had the exact opposite issue past weeks.
Using a Go monorepo, none of the 'normal' go tools worked.
In fact, auto complete did not work with go modules at all for months, I only recently got alternative language server somewhat working and they only work for a single modules repository.
On the other hand, Goland (or Go plugin for IntelliJ) handled modules flawlessly the whole time and they handle monorepo full of go modules flawlessly as well.
Go team is now working on an offical LSP server called gopls and have in fact just recently publishes first alpha release so hopefully, the situation will improve in a while.
Yes, using gopls is the way how I finally got some support for modules for the first time since they were released (single module only though - useless for monorepo).
I'm not a Googler so I don't know for sure, but I'm pretty sure Jetbrains IntelliJ is pretty heavily used at Google considering Bazel has really good support for it and it is the basis for Android Studio... so yea, sounds more like a self-inflicted problem than a real problem.
I'm a recent convert from Visual Studio to Rider, and I love almost every aspect of it. The bit I really don't like is how it handles source control - it seems to try to generalise every source control provider, and I find the git functionality to be a real PITA - it automatically stages any new files, and I've encountered many quirks that I just don't like.
My solution thus far is to use VS Code for all git functions (yes, I prefer a UI over command line for git), and use Rider for everything else. It suits me well - VS is basically my dream git UI!
Having said that, I still wish JetBrains would fix the car-crash of their got functionality...
Strange Rider seems to stage all new files without asking for me. I'm on 2019.1.EAP1, but I had the same behaviour on 2018.3.4. It might be configurable, but I don't see anything in the git config within Rider.
There's a plugin to support the large monorepo at the FAANG i work for, i would expect there is one at the other too. A lot more people use the jetbrains products than you think at these companies.
I used to use YouCompleteMe with Vim, then switched to deoplete on Neovim, because deoplete was easier to extend without having to maintain a fork and the user experience was pretty much the same.
I briefly tried out Coc but didn't find it to deliver anything compelling to make me switch away from a relatively fine-tuned deoplete-powered set-up (along with UltiSnips, LanguageClient-neovim, and javascript-typescript-stdio etc). I like the fact that there is competition though and an LSP ecosystem that's getting more and more robust all the time. We finally have multiple high-quality options to bring IDE-like features to Vim.
I used to use deoplete.nvim, LanguageClient-neovim with javascript-typescript-stdio, but they easily broken lots of time everyday and debug the problems is also quite challenging. So I made it to be able to load fork of vscode extension, and coc-tsserver implemented more than 95% features that vscode could provide. It's not easier to switch vim plugins, consider come back when you would like to try out some new features.
YouCompleteMe is hopelessly slow even on a beefy computer with a medium-sized code repo, despite configuring and optimizing. It's simply too painful to use. deoplete is significantly faster, but also becomes painfully slow when you have a few hundred files and a few hundred thousand lines of code total.
I'll try Coc; hopefully it's fast enough. IntelliSense works great in VS.
Do you know how it compares to YouCompleteMe or Coc.vim? Is there something it can do, which the others can't? Do you feel that the suggestions are better? something else?
TabNine's selling point (literally, it's $49) is that it uses machine learning to provide completions without having to configure any sort of knowledge about the language you're using.
I'd like to see such a comparison too. I've been considering switching to YouCompleteMe from ctags/cscope, but this looks like it might be even nicer, especially since a number of my teammates already use Intellisense with other editors.
I switched my neovim setup from ale and deoplete to coc.nvim a few months ago, and am thrilled about finally being able to write also all my java with neovim. There are a few rough edges, and of course java features are miles behind IntelliJ, but the benefit of being able to use one editor to rule them all, is a massive productivity boost. Don't think I'll switch back. Also Typescript with a language server is working really well.
I was a long time YCM user but it seemed to slow down my editor, then I switched to ALE and it was much better. I'm curious to see what improvements CoC brings to the table. From the screencast it looks like it can automatically add import statements to TypeScript projects which would be a huge productivity boost for me!
I'm also not sure why people keep calling autocomplete "intellisense". Using a brand name in place of the actual name of the feature seems like going a step back to me. We got the correct words, might as well use them.
Well, yes and no. Hoover means nothing here... That is why brand names as specific names seems like an issue to me; a lot of brands don't exist worldwide.
It apparently implements LSP, which is in fact the same protocol Microsoft's VS Code uses to deliver what they call intellisense, and presumably it's possible to use Microsoft LSP servers with it.
I’m still waiting for a day where I can write Swift and Kotlin with VIM and still be productive. Maybe this will let me do that but after the last few tries I’m not going to get my hopes up.
don't know about swift but any JVM based language will have more productivity in IDE than vim. I have tried really hard to use vim for java and the trouble is not worth it. But for everything else vim is your guy.
I'm honestly confused at how much effort people spend on .vimrc and .emacs files to get poor versions of narrow slices of functionality that comes out of the box with the most basic of IDEs.
Want to dev in Rust? Get IntelliJ Community Edition (free) with the Rust plugin. I'm sure VSCode can do this too (personally I prefer Jetbrains products and have been using them for 15+ years).
You can of course use a tty-based text editor over an ssh connection and I use that for Linux servers I connect to of course. I just don't write code that way and don't know why someone would.
I'm honestly confused at how much effort people spend on learning IDE menus to get inconsistent versions of narrow slices of functionality that just comes out of the box with most basic shells.
Want to customize your build? Just drop into shell and edit your scripts. Im sure $IDE can do this too (personally I prefer just fixing the relevant script, since finding obscure features 15 layers deep in some random menu got old 15+ years ago).
You can of course run some scripts via menu when you're in IDE, and I do it when I'm IDEing of course. I just don't limit my flexibility that way, and don't know why someone would.
As amusing as your response is, there's a pretty sharp distinction between discoverability in an IDE/GUI vs discoverability in Vim/bash. The former I can usually find the feature I'm looking for by clicking around a bit and see the keyboard shortcut for it for later use, and I can find features I didn't know existed. The latter I pretty much have to google everything that I haven't memorized
> As amusing as your response is, there's a pretty sharp distinction between discoverability in an IDE/GUI vs discoverability in Vim/bash.
I find it more time consuming to go through a bunch of menus and GUI windows to find something I'm trying to do vs being able to just run a command or Google for a command and run that instead.
Plus, for common actions with annoying to type syntax you can make a custom key bind (Vim) or alias (Bash). Then it becomes extremely easy to do once you memorize a single key bind.
> I find it more time consuming to go through a bunch of menus and GUI windows to find something I'm trying to do vs being able to just run a command or Google for a command and run that instead.
Have you ever even used a modern IDE?
I don't think I've actually clicked on a menu item in IntelliJ like, ever. Not once.
I just press "shift shift" and get the the "search everywhere" dialog which searches everything including menus and customization preferences.
Yes, I used PyCharm and RubyMine for over a year. The comment I was replying to said he was clicking around menu items to see what's available.
I don't really see a difference between using "search everywhere" vs using something like fzf with Vim (which lets you search through a ton of different things besides files).
But normally in my day to day I'm just hitting key binds or typing short commands without having to search for anything except files to open (which I could do with a sidebar instead, but I prefer fuzzy finding files based on typing out the name most of the time).
The thing is though, you have to know enough to google it in the first place. I'm sure there's a lot of users of VIM that never use certain powerful features because they don't even know they exist; that happens in an IDE too but it's a lot less frequent because a button or a panel is a lot more obvious to go "hey what's that..".
True, but you usually have at least some idea of what you want to do before you start Googling for something.
Vim's help command is also world class. It's just searching it is hard, but fzf.vim makes this easy, so you can literally type 1 word of what you want to learn more about and you'll find all sorts of results.
That's not how it actually works though. You've got what, half a dozen or more top level menus, with many submenus under those, and maybe even a third layer beneath that. And then you've got even more menus in the various subwindows anything in one of those menus might launch. Menus which again may have submenus.
And the worst part is you can't even run a text search on those menus!
That seems like a decent alternative to menus, motivated by exactly the fault with menus I was describing: "Instead of wasting your time searching the menus and toolbars in an attempt find out that action you need right now [...]"
That feature doesn't make menus better. It makes the IDE better, by giving you a way to avoid the menus, because [sigh] menus suck.
I develop exclusively in Jetbrains IDEs these days, and never let the IDE control the build. A working Gradle or Make target is required for CI/CD anyway. Our projects are officially editor independent and each contributor can use whatever they want. It is nice to click in a test and run it, but you can do that from command line too.
What I do get is correct autocomplete, documentation hinting, inline git hunk visualization, inline linter and compiler output, go-to-definition that always works and sees through implicitly satisfied interfaces, language aware refactoring tools, well designed interactive debugger, etc.
Sure you can hand assemble this stuff in Vimrc, or you can buy a tool that’s already functional.
Just one feature alone - being taken directly to compiler error sites - has saved me so much stumbling around from back when I was trying to be a shell purist.
As I’ve gotten more senior, I’ve really come around to the importance of investing in tooling (whether build or buy), having high expectations for tooling support, and having low tolerance for frustration/tedium/trickery. Not just IDEs. The right interactive debugger output, profiler trace, custom visualization, etc. easily pays for itself vs. trial and error or trying to squint at the source + output and reason about it.
"customize your build" was probably a terrible example, but how about "customize your run environment"?
I do a lot of systems stuff that can affect fs/network/etc so i have lots of scripts when developing to get everything set up pristine (I guess I use the term script to also mean Dockerfiles or helper utilities too - basically something that execs a command provided by the OS :) ). Those are modified a lot as I add features or integrations, or fix bugs, or whatnot.
Amen. IDEs are a plague. I get interviewees all the time that only know programming through the lens of an IDE. They have no idea how anything works. They consistently do worse in interviews.
I don't understand this comment. Source code is source code. The IDE doesn't write my code. What is an "IDE lens"?
I knew a guy with a heavily customized vim setup for development. He could write code without it because he was so used to his custom config. How is that any different?
>I don't understand this comment. Source code is source code. The IDE doesn't write my code. What is an "IDE lens"?
I have seen many people who have absolutely no idea how the Java compilation process works because they've never had to do it from the command line, but have interacted with it mostly through IDE tools that have abstracted almost everything away.
And when something actually breaks or is idiosyncratic enough for the IDE to not handle it, they end up very lost.
I sometimes find myself on the other side. I've been using Vim for close to 10 years. I rarely edit my .vimrc file now, mostly when I want to try out some new plugin or I'm using new library and want to improve some shortcuts.
From time to time I try to switch to IDE or another editor, but I easily get lost. I work on a big screen so I want to split my window into 2/3/4 parts to see multiple files next to each other. Vim has built in shortcuts for that and in my vimrc I added 2 lines to make custom shortcuts that are even simpler. How do I do it in Intellij? The most common way is to use mouse, which I find annoying since with Vim I'm able to use keyboard 100% of the time. There's also a way to add shortcut for that, but it's buried deep into settings (Settings -> Keymap -> Main menu -> Winddow -> Editor Tabs -> Split vertically / Split horizontally).
I guess what I'm trying to say is that what you consider "poor version of (...) functionality that comes out of the box with the most basic of IDEs" is enouh for me, and I've been coding in multiple languages over the last few years. On the other hand in other editors I have to slow down my development due to lack of good editing shortcuts or I have to invest significant amount of time into making sure that I can recreate these or similar shortcuts.
Wait... You said you had to edit 2 lines of a config file to add shortcuts, so that means you have to know what file and the syntax. But, opening a menu and clicking "keymap" to add a shortcut is too hard?
I said that Vim has built-in shortcuts for that (from what I know, Intellij doesn't) and I added custom ones because I wanted a simpler one. It's a fair point that editing a config file might seem way more complicated than modifying settings in IDE, however now that I learned about existence of config file and a command to add new key mapping, I can customize every operation I use, while in IDE I have to look for a proper setting every time.
The OP's config files are probably synced across all the servers and workstations they work with.. This is probably done using a familiar tool the OP already knew.
The IDE's config might be synced. If it is it probably uses a proprietary server.
You can easily incorporate the most widely used vim commands and shortcuts (including window splitting) in IntelliJ/PyCharm by installing their vim plugin.
You are then left with choosing between the comfort of using the subset of vim that isn't available through the plugin, and the comfort of using all the IDE features that aren't available in vim. I believe that for most people the latter will be far more productive.
It's possible, it also might be a matter of preference. I find it hard to become productive with other editors, although I appreciate some features there that are hard to achieve in terminal Vim. It might be true that for most people it makes sense to user other editors. It's also possible that VSCode or Intellij make you productive immediately, but if you decide to learn and configure Vim, with certain time and effort you might beat that productivity. The latter seems to be true in my case, but I don't want to claim that it's a universal thing.
I don't think that calling them "so called IDEs" is very helpful to the conversation. I am someone that uses vs code and vim and they are both very good at different things. Furthermore, the lines are even more blurred because vs code has an integrated terminal thats just a keyboard shortcut away. The line between terminal and "GUI" editor is not as clear cut as it once was. I did basically all my sysadmining at my last job for a year just in a web browser and VS code. Was sshing into machines and running vim to edit config files all through the integrated terminal in vs code, and it was pretty nice to have an open snippets file to paste commands into the terminal. Some people just wanna do some computing right now to solve problems and dont wanna tinker with learning vim. Its got a learning curve, and when you just need to run some R or Python functions against a production dataset to get your project done, I cant imagine that you would really wanna drop everything to set up vim right then. IDE's allow people to get working on problems quickly and they accomplish that task.
There are already a lot of replies, but let me sum it up:
1. People don't spend much effort on configuration unless they like the process.
2. You won't get "narrow slices" of functionality. You win at some things, you lose at others - similarly to situation when you compare programming languages.
3. "Comes out of the box" equally applies for a canned IDE, and for Emacs/Vim (it's not forbidden to download other guy's conf from github). The real difference is "sealed box" vs "open box".
4. You are not obliged to like other people's ways, but really do you believe that multitudes of experienced developers decided to suffer constantly while writing their code? Seriously?
> I'm honestly confused at how much effort people spend on .vimrc and .emacs files
I'm not sure how this criticism applies to the post; it's a single plugin that adds language-server capabilities that almost every IDE is using today.
> Want to dev in Rust? Get IntelliJ Community Edition (free) with the Rust plugin.
Alternatively, if you use vim, you can just as easily download the popular rust.vim plugin which was written specifically for vim by the rust development team.
poor versions of that comes out of the box with the most basic of IDEs.
The functionality isn't "poor" or in "narrow slices"; with few exceptions Vim is fully capable in terms of IDE features and actually exceeds what is possible with most IDEs individually. Products like the IntelliJ suite of editors will always have more "out of the box" features because their business model is selling IDEs with lots of features. IMO the vanilla editor + plugin model is superior because it allows you to select your features a la carte as they make sense for your workflow rather than being thrown into a bundle of different features, many of which you don't need and most of which you'll never use. With Vim, every feature is deliberate and the experience can be super lightweight or relatively heavy, but ultimately customizable to the point of perfection. Of course, tweaking Vim to be your perfect IDE takes time, but that's the tradeoff for a self-tailored experience vs one that was designed for you based on someone else's ideal workflow. There's nothing wrong with just picking something off the shelf and learning it, but some people want to optimize their workflow and most people end up switching IDEs over time anyway, so I think the idea that you can simply learn one thing and use it forever isn't typical.
> I just don't write code that way and don't know why someone would.
I prefer it because its fast, clean, open source all-the-way-down, and I can manage and access my entire development environment remotely from any machine, with full fidelity and capabilities. Tty applications also combine beautifully with tmux allowing me to arrange my editor into tight visual coordination with other commonly related tasks that are specific to the context of the files i'm editing (e.g. tailing logs, running binaries/scripts, copying/moving files). Additionally, tty applications tend to integrate very well with eachother since the designers tend to have an appreciation for the the unix philosophy.
> you can just as easily download the popular rust.vim plugin
Is it really "just as easy"? The last time I tried to install plugins for Vim it was not easy. Vim doesn't have a plug-in manager built in while VS Code, in this case, does, and it's 2 clicks to install and restart.
I would consider vim more customizable but I would not consider it "easier".
It's dead simple. No, it doesn't come out of the box, but it takes literally 5 minutes to install a plugin manager and you only have to do it once; afterwards, installing, updating or removing plugins takes literally seconds.
You're right, basic Vim or Neovim are definitely not easier, especially that you have multiple packages to choose from.
I believe it's easier to start with one of existing Vim configurations like Janus[0] or spf13-vim[1]. I tried a couple of such frameworks and they helped me a lot. They come with set of packages for navigation, fuzzy finding, as well as with some package manager. They're also quite easy to install.
"I'm honestly confused at how much effort people spend on .vimrc and .emacs files to get poor versions of narrow slices of functionality that comes out of the box with the most basic of IDEs."
I think that it's the other way around: people don't want to lose the editing experience that they already have by switching to another environment that might have some other benefits. For some people, that means an environment that they've tuned to their own requirements over years, and for others, it's just the core interaction model.
For me, I like modal editing, and the Vim commands are now automatic, but I have no attachment to any implementation of these, so I use the stock Vim on CLI, and VS Code with the Vim extension everywhere else to get modern features without losing the aspects of Vim that I really care about.
> I just don't write code that way and don't know why someone would.
I mean what is the point of this comment if you don't know? What comparative warrant is there to even discuss? Having attempted to move to Sublime, Atom, VS Code with their respective Vim extensions is _not_ the same thing if you understand how to vim, so mucking around in your respective $GUI_EDITOR's Vim mode is never going to be a symmetrical experience, not even in a "good enough" way cause you always end butting up against the inherent design of the $GUI_EDITOR. It's true that vimscript, package management, etc could stand to be given a second look, but those things aren't showstoppers and have no bearing on the central value proposition.
It's true that it can be a lot of effort. But it is amortized over time. I personally don't tell anybody to run out and install tmux + vim — they'd either spend countless hours configuring it, or they'd grab an out-of-the-box config from somebody else and not really understand it, or they'd limp along with a basic and not-very-optimized config — but it's a valid path for those who really want to take it. For those who don't, installing VSCode and getting up and running quickly is a totally rational and defensible choice.
IDE’s don’t run in terminals, and the main benefits of terminals are consistency, power, and speed. Plus, at least in scientific computing, you generally have to develop and deploy code on remote workstations or HPC clusters, so an SSH-based workflow is a given.
Vim startup should be nearly instantaneous (<<1sec). If it’s not, something is broken. You can do `vim --startuptime profile.log` to find out what’s going wrong.
I'm in the camp where too many plugins (while nice for particular languages) is a crutch. I'd like to still be able to use it when my plugins aren't present on remote machines. It's part of the reason why I had, a one point, used the easy-motion plugin, but dropped it. Does it make things more cumbersome? A tad, but it forced me to build up a better workflow around it.
I'm also wondering when the last time you've used Vim was, because async plugin execution is now a thing, but I switched to NeoVim a while back it's fast.
I'm really careful to not change standard settings, so when I'm remote only cosmetic things change (linting underline, autocomplete). If I do change something standard, then it should be obvious what the original command was (<C-w> to <leader>w)
That has been my experience. Out of the box Vim is fast sure, but when you add plugins for the thousand and one missing functionalities you get OOTB with VSCode etc., it begins to really slow down.
Vim with ~40 plugins loads in about 1 second for me and that's inside of WSL too, which is a heck of a lot slower than native Linux. That's on a 5 year old i5 3.2ghz too.
I'm using NeoVim which might explain the difference, but VSCode is slow to boot and laggy when running on my Ubuntu 18 box. Nvim has never been either.
At work, on OSX, VSCode has been fine though. Still, I've never run into a situation where nvim is slower. And I use a good many plugins (deoplete, ALE, ctrlp, fzf, and 5 sets of language specific plugins).
I just enjoy vim, and I enjoy customizing vim. Customization is a hobby I do on my own time, so I don't need any of these "you get slowed down having to customize" arguments.
I work mostly in ruby and the vim ruby experience is great. I have spent a year watching coworkers work in RubyMine and there isn't much it provides that I can't do (literally) just as well in vim. In fact the navigation tools are superior in vim as far as I'm concerned. RubyMine does have better project wide refactoring support, but with ruby being a dynamic language, you still have to go and check every file that changed to make sure it did the right thing anyway.
I cringe when I see these kind of comments because for the heavy vim users it becomes clear the OP simply doesn’t get vim.
The uninitiated always stumble around with vim like bumbling bafoons wondering why anyone would use something so antiquated, but in the right hands vim becomes an elegant weapon for coding at the speed of thought.
A pity that for want of a GUI, most will never feel the power.
People ignore this fact: if you're terminal-based, you OS independent. You can work out of ssh. Really handy-dandy sometimes. Depends on your role, of course.
Much like how I've configured my syntax colouring (very limited), the fact that vim isn't an IDE becomes a virtue. For the few code-helper tasks I want, it's there, but mostly it gets out of my way.
I use VS Code sometimes, and got it configured to run unit tests on live code and constantly report on passing, and then I went back to vim. I don't need a herd of assistants begging for my attention, and it hurts my productivity.
I know right? I don't get all the hype, honestly. I've been using JetBrains products too, and they blow everything else out of the water. Even VSCode is good (though nowhere near as good as JetBrains, atleast in terms of Intellisense).
I tried looking into Vim / NeoVim a few times to understand what all the hype was about.
And I don't remember how many other plugins just to get a halfway decent editor experience. I get using Vim if you're SSHed to a server, but otherwise it feels like intentionally handicapping yourself. In case you find yourself needing keyboard based navigation, I'm pretty sure Command+P is much better than anything Vim could offer for quickly opening files, and there's a Vim plugin for VSCode for moving around in files.
I will probably get heavily downvoted for saying this, I know. But if someone feels like enlightening me instead, please do so.
JetBrains IDEs are very good indeed, and if they (or VSCode) work for you, you should use them. There's some features in these IDEs that are better than what's available with vim/tmux, and the other way around. In either case, with sufficient motivation, any feature can be implemented in the terminal, or in a good IDE. It pretty much comes down to how much your workflows are remote-based, how tied-in you are to a terminal environment in general, and personal preference (like not wanting to touch a mouse).
If you're used to IDE's it's doubtful you'll appreciate vim by "trying it out" for a weekend. The learning curve is much too steep for that. Conversely, if you've used vim and terminal tools on a daily basis for >15 years, you probably won't have much motivation to switch to GUI-based IDEs.
I'd say you are focusing on plugins far too much before you've realised what Vim is even capable of.
I've been using (Neo)Vim for a couple years now and only regularly use 6 plugins that actually do something, and 2 additional ones for the eyecandy. All the rest is just a matter of knowing the features that already come in Vim, and efficient keybindings for them.
Also, Vim isn't something where you can just jump in for a test drive. You never stop learning Vim and it takes time. But once you get hooked you won't use any other editor without a Vim plugin, no matter where you end up eventually.
this. i would seriously consider switching to jetbrains/vs code if kb-only navigation was possible. not just in the editor, but between all the integrated panes and menus too.
if this is possible... please teach me! i searched online and only found articles about enabling basic vim keybindings and gave up after that tbh.
Given that you installed Airline - which does absolutely nothing useful - I imagine you just got distracted by the red herring of people's lists of plugins instead of just trying to grok vim.
It's there more or less all the time in the background. Every 2-3 years you'll see a resurgence in "Why I vim" posts. It's also part of the shell world. Usually it's tied to new waves of tooling...
* A new language or paradigm comes out
* Clicky tool makers (IDE, management software, etc) can't really keep up with the rapid change, and they aren't sure if this will catch on, so they don't make great tools for it. People have to use the cli tools to take advantage of all the features.
* Since folks are already in the shell, they want to make their environment better, so new folks are introduced to shell stack, and new customization options for tmux or shell or vim come out.
* Eventually if the thing catches on Clicky tool makers catch up and the shell scene quiets down a bit - people abandon shell stack for clicky tools if that's their preference, and the new shell converts integrate with the broader "shell folks community". (That community is always there, just quietly using the relatively stable interfaces in the background).
* At some point a new language or paradigm comes out...
I used VSCode for over a year and recently switched to Vim.
Ctrl+P inside of VSCode is way way way slower than fzf with Vim. Even Ctrl+P with VSCode on a small amount of files had some amount of lag on it but fzf and Vim is nearly instant with thousands of files. There's also a lot of great fzf related shortcuts with Vim too, like being able to search more than 1 file with ripgrep or searching through lines in a file, etc.. All of which are super fast operations. I can search through a 900,000+ word markdown file (over 100,000+ lines) in Vim instantly with fzf's line searching tool.
"Get IntelliJ Community Edition (free) with the Rust plugin."
It's a good thing somebody put the effort into the Rust plugin for IntelliJ CE. When I started writing Rust, I used vim with syntax highlighting, so I guess I might be part of the reason Rust became popular enough to get IDE plugins. You're welcome.
I tried to get this set up for rust / go / python a few weeks ago and found it surprisingly cumbersome, requiring a fair number of other plugins. I ultimately stuck with ale / completor which support async LSP linting and async (non-LSP) completion respectively, and which I found far simpler to set up.
As a heavy user of this plugin on a daily basis, it has made me so much more productive. Recently it also got support for floating windows added in neovim, inching even closer to the quality of completions in VSCode.
I’m going to get heavily downvoted for this, I’m sure, but... If I find myself needing, or even using, code completion, I’ve fucked up my implementation. My interfaces are not intuitive nor consistent... or it’s just glue lacking adequate abstraction.
I strongly suggest all developers disable completion & tag jumping, not because I’m an elitist, but because it forces you to write better code. Not a troll. I’m serious.
On projects I’ve worked on that started with Intellisense, they quickly evolved into being unmaintainable without it. It’s an asset to skilled hands, but a debilitating crutch for the novice.
It’s like never operating a vehicle without a GPS. You never develop certain types of skills.
I get what you're trying to say, but I feel like it also implies that you've written everything you're using. I'm an Android developer, and I've worked on some huge java code bases. Not only do I rely on autocomplete to discover/remember various parts of the Android SDK, but things like "go to declaration" or "find usages" are incredibly useful for navigating large code bases. Not to mention Java isn't known for being the most terse language, so saving some keystrokes helps too :)
Personally, it slows me down considerably without intellisense, even when I know the entire codebase. If you have overloaded methods, for example, just remembering the order of the parameters is impossible without intellisense.
This makes me believe that either I have a really poor memory by not being able to memorize thousands of method names, their parameters and orders or other devs have a really, really good memory.
You're not alone. I strictly use kwargs in my functions because I can't be arsed to remember the order of arguments in addition to the structure of the rest of the program. It's more work but I need any simplification or hint I can get for my feeble mind. And I don't even use Java.
It’s a fools erand to disregard automated tooling that could benefit in API discovery, type checking, linting, code analysis, spelling, navigation, auditing, etc. which are now manual remedial tasks common in day to day development you have to do yourself and the later you catch any of these issues the more time you will have wasted.
You now have to leave your context and “break the zone” you’re in to find the symbol name you want you use elsewhere, you’re at the very least less productive as a result.
I’d also expect code quality to suffer, given the number of issues I’ve found thanks to code analysis, type checking, linting and spelling that we’re able to highlight, catch and resolve human errors before shipping.
I didn't downvote you because I understand where you're coming from. The APIs you work with probably don't change and you already know most of them, disabling code completion works for you. But if someone renames things in your API, you'll be slower without completion. And if you're working with a new language/framework (or even just a large library), you'll reaaalllyyyy wish you had code completion.
A few years ago, I started working on a project where I needed to use C#. I'd never written a line of C# in my life, so I installed VS and with the aide of Intellisense, I went from having a "Hello World" snippet from Google to using several C# libraries to create a ~1000 line PoC in a day. A few days later, it was production ready. Without Intellisense, this story would be very different.
Autocomplete isn't just a form of documentation, I very rarely use it that way (that's what go to definition or GitHub are for). I know how to override ToString(), but ov[tab]tos[tab] saves me about 40 keystrokes. Stubbing out an interface can save me hundreds.
Scott Hanselman has a great tweet chain (or blog article, can't remember) on the fact that you have a limited amount of keystrokes in your life. I'd rather not waste them on something a machine could do.
some languages are more verbose than others. if you're dealing with `ProblemProblemFactory` type of abstraction madness and subscribe to the idea of spelling out every variable (MessageCounter instead of "cnt" etc) then this would seem handy.
Maybe it's a question of mindset & philosophy. I personally prefer a minimalist but powerful editor without plugins and just rely on their internal capabilities (which granted are a learning curve).
It avoids getting stuck when doing $EDITOR foo on a system you don't own and still feel at home and as fast as on your primary workspace.
I’ve worked in multi-million line codebases with several generations of naming “conventions.” Auto-complete is a lifesaver there. I’ve also worked in small micro services with a well defined API and a SLOC that could be measured in the tens of thousands. In that case, sure autocomplete could be seen as unneeded.
Edit: replaces ableist phrasing with more precise term.
I don't agree. If you are developing with Rust, completion can be useful. It can show you the signatures of the function/struct and types. It'd be hassle to go look them up on a browser.
Good completion can help when working with a new library you are not familiar with yet. Specifically in strongly typed languages like Java or Kotlin.
Usually I kind of know what I want to do with an object so I start typing ‘myObject.’ and the editor shows me all possible methods with their argument types. It’s way faster than looking up the docs. And in the case of Java/Kotlin in intellij you get the documentation right along the method names and types.
... but with completion disabled I'm pretty sure I'll stop naming my interfaces properly because it's too hard to type, and I won't try to came up with "clever" ways of naming things like "creat" and "mv". I'll just use cr, sav, o, upd, a, b, c, d, ..., zz instead, good luck maintaining that.
I’ve long since changed my mind and really hate not having great auto-completion.
I find that grabbing pen and paper and looking at the problem from a high-level avoids the problem where you code-monkey the program by just quickly banging away at the keyboard.
I partly agree with you. Tag jumping is actually necessary though. Jumping through the linux kernel code base without tags would be a nightmare. I do agree that the pop up as you type autocomplete is actually producing worse developers. Sometimes using the standard vim completions via C-x are actually worth it, but a lot of the time it just encourages writing more code than less code.
What about when you are having to navigate and work with someone else's crappy code which is 90% of a job anyone works with. Sure if it was up to your own discipline I would agree with you, but we have to deal with other people's code constantly and I'm not rewriting it just to understand it. I need code navigation and completion.
Your words, my words. I highly recommend people read [1] where Linus explains why he thinks kernel debuggers are basically unnecessary. I think many of his arguments apply here as well.
Lack of discoverability makes for worse code, if anything. Constantly switching back and forth between documentation and the editor is a big hindrance to getting things done.
I have, and my teams write abstraction layers around both internal & external systems for testing, integration, and sanity.
It limits the scope & necessity of domain knowledge to be scattered about everywhere. The core logic is easy to reason about and there’s no tight coupling.
For example, if I’m calling libcurl directly in C++, I’ll create a generic adapter. Auto completion isn’t adequate for that library anyway, unless you can remember the docs.
If it’s some unwieldy “does everything” internally developed monolith by a team from hell, the same applies. Encapsulated composition.
Well, I think it depends on how you use it. If you use it to 'discover' huge code bases (instead of reading documentation), I am not so sure that is a good idea. But if you use it to reduce the keys you have to press, there is nothing wrong with that.
It is a powerful tool and you should be aware of that power and act accordingly (meaning: know exactly what you are typing and don't fall for bad suggestions).
I have only dabbled with intelligense and language servers, but my out-of-the-box experience has been disappointing when working with pandas and I’m wondering if anyone on HN can talk about whose fault it is and what can be done to improve it.
Modern pandas is supposed to be written along the lines of
import pandas as pd
df = pd.read_csv().transform().agg().pipe() #etc, etc
But I am very disappointing in the suggestions I get after the dots in the chain, as well as the parameters inside the functions, when trying out jedi and other language servers in different editors (even ipython is quite disappointing to me)
I tried YouCompleteMe but on a 500k line codebase, as well as it works, it's just too slow to stay below the constant annoyance threshold. Would like to play around with adding C support and see how this performs
Seeing as this is a server, is there any way to run it over the network? This seems like the sort of thing a shared codebase could benefit from, with everyone sharing the same, custom-tweaked auto-completion.
That's why you shouldn't use this product. What you are describing is LSP. This is essentially a very fat thin client. You should try the standard Vim completion framework :help ins-completion or use ALE, which is entirely in vimscript and can run linters, fixers, and LSPs.
This works really good for TS compared to anything else I've tried. I don't think this is as flexible as some of the alternatives, this one is a bit weird compared to many other vim plugins that I'm used to, but it works pretty much out of the box.
Don't forget to install yarn, not super happy about that.
So before your run off and install v8 just to get autocomplete in Vim, let me make a few suggestions based on my experience:
1. Check out the built in completion first. Vim actually has very powerful autocomplete that can look in the current file, complete file paths, tags, and more. It can look at includes, requires, etc. depending on your language's built in support. For C like languages this is usually excellent. With ctags and this built in completion, you can get 90% of what an LSP will give you.
2. Chances are you've already installed ALE, it's a pretty standard plugin. ALE has built in LSP support, and it's entirely written in vimscript. All you have to do is create an ftplugin for your LSP language and add the LSP into the configured linters list. This is in the primary docs.
Can anyone give a quick comparison to ALE? I'd only ever used YouCompleteMe and found it a bit slow. ALE and COC seem to be pretty much the same - one in vimscript and one node?
To me, using vim is more about forcing me to understand how things work, or rely less on some IDE magic. IDEs are powerful. It’s too powerful that I don’t know how certain functionalities work. Maybe it’s just me lol.
Sure. But once you know how everything works, you switch back to an IDE. Use the tools that make your life easier, and lose the elitism. There’s nothing more frustrating to me than watching junior engineers struggle to dig through a problem using Vim or Sublime because “That’s What Real Programmers Use”, thinking it’s somehow a crutch to have things like autocomplete or code click through. These tools were built by people far more talented and knowledgeable than you or I because professionals need productivity, not some ephemeral feeling of superiority or nerd cred.
Autocompletions are not limited to IDEs these days. With the advent of editor-agnostic language servers, I have high quality autocomplete in vim, with the bonus of not having to use a slow and clunky IDE.
Vim needs to come with its own package management and all languages should have a single-script which setup their features. I don't want to install 20 different packages manually and not have them work
Why? There's a few high quality package managers already. Creating yet another one is not a great idea. vim-plug is what I use and it works perfectly fine.
For a more complete vim experience out of the box, check out spacevim.
I'd like Vim to come with a hosted account feature with password, so you have the same .vimrc no matter on what machine you are working. It would also allow easy copy+pasting of text across machines.
I know, you can set this up yourself e.g. through git, but this is an extra step to take whenever you have to configure a new machine.
vim-plug is another. However I think the bigger point being made is that there is no standard one, which means each package manager makes things more confusing, not easier.
Out of curiosity I checked out if Vundle would give me YouCompleteMe but... vundle installation of YouCompleteMe just failed with `The ycmd server SHUT DOWN (restart with ':YcmRestartServer').YCM core library not detected; you need to compile YCM before using it. Follow the instructions in the documentation.`.
I love Vim but I have stopped trying to build a cathedral for it.
Vundle is really neat and so is vim. But some plugins requires external binaries or services to function and that's when a vim packager stops being helpful and you have to take extra steps. Sometimes it's just an apt-get install something or curling a bin to ~/.bin but sometimes it needs more tweaking and fiddling. In my opinion that makes your vim installation more fragile and less portable.
Vundle does install YCM, but you need to execute some more steps (compile the ycmd server), which vundle doesn't do, and YCM doesn't work without the daemon compiled.
Master grep. Searching is not perfect, but it's a trick that gets your petty close to any IDE feature. Find refs, go-to def. Even completion becomes possible via searches. Search to open the class/struct... boom now you can use dumb textual completions on the members.
Master your debugger. GDB? learn to use it.
You are set for life and can work on any language, anywhere, any time. Everyone wants a ready-made IDE, and it's great when it works out that way for your current dev environment. But it won't work for all languages, or for all project set ups.
[0] https://github.com/w0rp/ale