7 ms·

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 bo

by cletus 8y ago

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.

dbalatero 8y ago
I prefer the tight terminal integration I get with vim and tmux. I've tried vscode+vim but never felt as fluid.
- adrianhel 8y ago
  I prefer Vim with iTerm panes. Much easier to use.
goerz 8y ago
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.
- atomi 8y ago
  Loaded with plugins Vim is slower than VSCode on my machine. But I do use Vim, plain, on remote systems.
  - asaddhamani 8y ago
    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.
  - goerz 8y ago
    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.
    - ma2rten 8y ago
      Right. Also vim8 and neovim have async which should allow plugins to do things in the background.
      - darkpuma 8y ago
        Most plugins lazyload themselves too. I haven't had perf trouble with vim in years.
  - dwoot 8y ago
    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.
    - chessturk 8y ago
      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)
  - nickjj 8y ago
    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. My vimrc is at: https://github.com/nickjj/dotfiles/blob/master/.vimrc https://github.com/nickjj/dotfiles/blob/master/.vimrc
  - chessturk 8y ago
    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).
asaddhamani 8y ago
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. I had to install: * Fugitive * Nerd tree * Airline * YouCompleteMe * Emmet 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.
- goerz 8y ago
  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.
- kitotik 8y ago
  “I tried looking into Vim / NeoVim a few times to understand what all the hype was about.” Is vim really getting hyped anywhere? If so that must be one of the longest running hype trains in tech.
  - Redoubts 8y ago
    It's as hyped as tiling window managers.
going_to_800 8y ago
I used most of the so called IDEs for 10 years, switched to vim+tmux 3 years ago and won't go back. In those 3 years I spent 3-5 hours in total configuring my .vimrc to make it work exactly as I want. I can compare directly my productivity using Vim and other IDEs and I'm like 50% more productive using Vim.
- farisjarrah 8y ago
  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.
sophacles 8y ago
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.
- jcelerier 8y ago
  > Want to customize your build? how often do you need that though ? for me it's less than 5% of my projects which need "special handling".
  - sophacles 8y ago
    "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.
  - lugg 8y ago
    That's kind of an argument for why you don't need an IDE..
- ilovecaching 8y ago
  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.
  - Osiris 8y ago
arnvald 8y ago
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.
- pavelrub 8y ago
  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.
  - arnvald 8y ago
    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.
fatbird 8y ago
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.
gfiorav 8y ago
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.
sjellis 8y ago
"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.
wincent 8y ago
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.
veryworried 8y ago
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.
root_axis 8y ago
> 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.
- Osiris 8y ago
  > 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".
pmarin 8y ago
I suspect most of these people were former IDE users that can not be productive without those features.
freshm087 8y ago
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?
sodapopcan 8y ago
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.
mcguire 8y ago
"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.
barberousse 8y ago
> 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.

by cletus 8y ago

dbalatero 8y ago

I prefer the tight terminal integration I get with vim and tmux. I've tried vscode+vim but never felt as fluid.

adrianhel 8y ago
I prefer Vim with iTerm panes. Much easier to use.

goerz 8y ago

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.

atomi 8y ago
Loaded with plugins Vim is slower than VSCode on my machine. But I do use Vim, plain, on remote systems.
- asaddhamani 8y ago
  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.
- goerz 8y ago
  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.
  - ma2rten 8y ago
    Right. Also vim8 and neovim have async which should allow plugins to do things in the background.
    - darkpuma 8y ago
      Most plugins lazyload themselves too. I haven't had perf trouble with vim in years.
- dwoot 8y ago
  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.
  - chessturk 8y ago
    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)
- nickjj 8y ago
  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. My vimrc is at: https://github.com/nickjj/dotfiles/blob/master/.vimrc https://github.com/nickjj/dotfiles/blob/master/.vimrc
- chessturk 8y ago
  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).

asaddhamani 8y ago

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. I had to install: * Fugitive * Nerd tree * Airline * YouCompleteMe * Emmet 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.

goerz 8y ago
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.
kitotik 8y ago
“I tried looking into Vim / NeoVim a few times to understand what all the hype was about.” Is vim really getting hyped anywhere? If so that must be one of the longest running hype trains in tech.
- Redoubts 8y ago
  It's as hyped as tiling window managers.

going_to_800 8y ago

I used most of the so called IDEs for 10 years, switched to vim+tmux 3 years ago and won't go back. In those 3 years I spent 3-5 hours in total configuring my .vimrc to make it work exactly as I want. I can compare directly my productivity using Vim and other IDEs and I'm like 50% more productive using Vim.

farisjarrah 8y ago
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.

sophacles 8y ago

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.

jcelerier 8y ago
> Want to customize your build? how often do you need that though ? for me it's less than 5% of my projects which need "special handling".
- sophacles 8y ago
  "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.
- lugg 8y ago
  That's kind of an argument for why you don't need an IDE..
ilovecaching 8y ago
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.
- Osiris 8y ago

arnvald 8y ago

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.

pavelrub 8y ago
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.
- arnvald 8y ago
  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.

fatbird 8y ago

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.

gfiorav 8y ago

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.

sjellis 8y ago

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

wincent 8y ago

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.

veryworried 8y ago

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.

root_axis 8y ago

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

Osiris 8y ago
> 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".

pmarin 8y ago

I suspect most of these people were former IDE users that can not be productive without those features.

freshm087 8y ago

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?

sodapopcan 8y ago

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.

mcguire 8y ago

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

barberousse 8y ago

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