5 ms·

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

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.

ilovecaching 8y ago
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.
- enitihas 8y ago
  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. Please find an example here: https://news.ycombinator.com/item?id=14857944 https://news.ycombinator.com/item?id=14857944
- mlevental 8y ago
  why weren't you allowed to use jetbrains at faang?
  - ilovecaching 8y ago
    Editors need to be able to support our very unique way of storing code (monorepo).
    - bbbobbb 8y ago
      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.
      - mr_aks 8y ago
        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.
        bbbobbb 8y ago
        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).
    - closeparen 8y ago
      Funny, ability to output fully functional Jetbrains configs is a core requirement for our early-stage corporate Go monorepo.
    - mlevental 8y ago
      ...but you can exclude directories in jetbrains tools?
- ma2rten 8y ago
  Google allows both Vim and Jetbrains, but Jetbrains is considered to officially supported while vim is just supported by 20% time.
  - throwawaytoday5 8y ago
    Could you explain what you mean by Vim being support 20% of the time?
    - ma2rten 8y ago
      Google employees can use 20% of their time to work on projects of their choosing.
chmln 8y ago
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
- enitihas 8y ago
  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.
  - chmln 8y ago
    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.
  - nickjj 8y ago
    I really like the :Plug model with Vim. 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.
  - milch 8y ago
TheAceOfHearts 8y ago
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. [0] https://intellij-rust.github.io/ https://intellij-rust.github.io/ [1] https://cursive-ide.com/ https://cursive-ide.com/
- steveklabnik 8y ago
  IntelliJ-Rust is sponsored by JetBrains.

ilovecaching 8y ago

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.

enitihas 8y ago
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. Please find an example here: https://news.ycombinator.com/item?id=14857944 https://news.ycombinator.com/item?id=14857944
mlevental 8y ago
why weren't you allowed to use jetbrains at faang?
- ilovecaching 8y ago
  Editors need to be able to support our very unique way of storing code (monorepo).
  - bbbobbb 8y ago
    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.
    - mr_aks 8y ago
      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.
      - bbbobbb 8y ago
        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).
  - closeparen 8y ago
    Funny, ability to output fully functional Jetbrains configs is a core requirement for our early-stage corporate Go monorepo.
  - mlevental 8y ago
    ...but you can exclude directories in jetbrains tools?
ma2rten 8y ago
Google allows both Vim and Jetbrains, but Jetbrains is considered to officially supported while vim is just supported by 20% time.
- throwawaytoday5 8y ago
  Could you explain what you mean by Vim being support 20% of the time?
  - ma2rten 8y ago
    Google employees can use 20% of their time to work on projects of their choosing.

chmln 8y ago

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

enitihas 8y ago
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.
- chmln 8y ago
  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.
- nickjj 8y ago
  I really like the :Plug model with Vim. 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.
- milch 8y ago

TheAceOfHearts 8y ago

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. [0] https://intellij-rust.github.io/ https://intellij-rust.github.io/ [1] https://cursive-ide.com/ https://cursive-ide.com/

steveklabnik 8y ago
IntelliJ-Rust is sponsored by JetBrains.