Hacker News Reader

Comment by enitihas | Hacker News Reader

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.

View on HN

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

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.

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

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)

>I've configured vim to my liking once…

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.

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/

[1] https://cursive-ide.com/

IntelliJ-Rust is sponsored by JetBrains.

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.

Please find an example here:

https://news.ycombinator.com/item?id=14857944

why weren't you allowed to use jetbrains at faang?

Editors need to be able to support our very unique way of storing code (monorepo).

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

Funny, ability to output fully functional Jetbrains configs is a core requirement for our early-stage corporate Go monorepo.

...but you can exclude directories in jetbrains tools?

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

>it automatically stages any new files

no it doesn't? it explicitly asks you whether you'd like to "add" the file.

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.

Google and Microsoft use monorepos, and it's so unique that nobody in either company can use JetBrains?

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.

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.

Google allows both Vim and Jetbrains, but Jetbrains is considered to officially supported while vim is just supported by 20% time.

Could you explain what you mean by Vim being support 20% of the time?

Google employees can use 20% of their time to work on projects of their choosing.

Reply on news.ycombinator.com