4 ms·

I pay for Jetbrains Ultimate every year, and I've been considering boycotting it. Not because of this AI thing, but because IntelliJ IDEA seems to break more a

I pay for Jetbrains Ultimate every year, and I've been considering boycotting it. Not because of this AI thing, but because IntelliJ IDEA seems to break more and more things on their WSL + Gradle support every update. I've filed over 15 issues on YouTrack over the years, and almost half of them are Gradle + WSL related. The latest IDEA update completely broke it for me. I could no longer even load the projects I was working on. I am so fed up with the complete lack of QA and testing for this fundamental workflow.

Avamander 3y ago
To be fair WSL is quite cursed. There are a lot of things Microsoft has done that result in less than good workarounds.
- Culonavirus 3y ago
  So far I managed to get by using wsl just for redis, most software packages these days do actually have decent windows version, including pytorch etc. I considered switching over to wsl more, but I ran to wsl being very slow in terms of filesystem access, I think it had something to do with wsl 1 being (somewhat?) native while wsl 2 runs under hyperv. I think it's still not fixed.
  - hackandthink 3y ago
    Rancher Desktop is very slow. There must be a driver (virtio?) issue in their WSL VM. Podman is much faster.
  - iimblack 3y ago
    Wsl2 has been significantly faster for me as long as I store the files in the wsl drive. I had react projects that would completely fail to get through npm install on windows but finished no problem on wsl. Microsoft docu seems to recommend wsl 2 as well. https://learn.microsoft.com/en-us/windows/wsl/compare-versions#increased-file-io-performance https://learn.microsoft.com/en-us/windows/wsl/compare-versio...
- gavinray 3y ago
  In my experience, WSL2 works like a dream. I have nothing but good things to say about it. WSL1 was sort of clunky and slow but I feel no difference from using native Linux in WSL2. Plus, the VS Code integration for it is spectacular.
  - Daynil 3y ago
    Second that. I was tepid on WSL on initial release, but recently decided to try a full switch after hearing good things and I'm glad I did. You're literally using a full Linux distro, it's really fast, and it even has neat integrations with windows like allowing use of windows explorer if you're inclined. And it's totally seamless to use with vscode.
  - hackandthink 3y ago
    Remote VS Code for WSL feels sometimes clunky to me. Another option: running Emacs as GUI App in WSL. https://code.visualstudio.com/docs/remote/wsl-tutorial https://code.visualstudio.com/docs/remote/wsl-tutorial https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-...
- politelemon 3y ago
  Quite the opposite - WSL(2) is one of the best things that have come out of MS in a long time.
mdasen 3y ago
I'm kinda getting to that point as well. The new UI is a big one for me. The issue is that it hides a lot of the buttons until you hover over a certain area. If I want to minimize the terminal, I have to move my pointer to the terminal's toolbar and only then will the minimize button appear. That means that I can't target the minimize button. It becomes a two-step process with a slight delay waiting for the minimize button to fade in so I can move the cursor to it. Likewise, the "x" button to close tabs is hidden until you hover over the tab. This means that I'll go to try and select a tab and when I move my cursor over the tab and click, an "x" has just appeared under my cursor and I close the tab instead! Whoops, I guess I should have known better than to aim my cursor at the right portion of the tab. It feels like they're trying to make it seem more like VSCode, but it's just poor UX from where I'm sitting. Plus, as VSCode gets better, I'm finding less reason to keep paying for the JetBrains suite.
- vips7L 3y ago
  If the new UI is such an issue, why haven’t you switched back? The majority of developers I know haven’t even bothered with the new UI.
  - GordonS 3y ago
    I switched back too, as the new UI is just... ugly. It looks and feels more like something for children than a serious IDE. I've even gone back and tried it in earnest, but in all honesty I just don't understand why JetBrains have spent so much time and effort on something that's simply worse than the original UI. I'm dreading the day where the old UI is replaced with the new UI... I might seriously have to look at going back to Visual Studio, and I'd really rather not - I just want to keep the existing, perfectly fine UI!
  - lacrimacida 3y ago
    Switching back is a deferral until it eventually gets shoved down on our throats
  - therealdrag0 3y ago
    I never tried the new UI. Happy with the original!
vips7L 3y ago
Gradle breaks itself every month, without Jetbrains’ help. Just use Maven. It works everywhere, all the time.
- somehnguy 3y ago
  I’ve never experienced Gradle outright breaking itself, but it does deprecate things at a high rate. We try to update dependencies whenever we touch a project, which every few months means making an adjustment for whatever Gradle decided to deprecate and start warning about now. I’ll still take it every time over Mavens XML based config though.
  - vips7L 3y ago
    I honestly don’t understand this position. You’d rather have to update your build or have it be inconsistent or down right broken over having to write some XML?
  - gavinray 3y ago
    I would consider myself a very advanced Gradle user. I keep up with experimental/nightly features and best-practices. I have a love-hate relationship with Gradle. I think it's a better alternative to XML (if you keep it declarative and any kind of stateful logic the hell out of your build scripts). BUT. Gradle introduces breaking API changes frequently, and they have changed around "best practices" every year or two. You can easily see this by using "gradle init" to create a new project. It used to be the case that "buildSrc" was the recommended way to do multi-module build logic composition. But it didn't even work with the recommended "libs.versions.toml" file for managing dep versions (you couldn't reference the generated code from within your buildSrc logic). Sometimes I consider switching to Maven, lol. Have to weigh the effort required to keep up w/ changes against the benefit of using strongly-typed build files.
- ptx 3y ago
  Unfortunately you can't use it for Kotlin/JS anymore. Jetbrains recently removed the Maven support from the Kotlin/JS tooling, so it now just pops up a message telling you to migrate to Gradle.
kevingadd 3y ago
This has always been the jetbrains customer experience. They don't prioritize quality so if you're unlucky they'll break your workflow repeatedly, and the fixes will arrive in a major release with new bugs that you have to pay for. I eventually gave up and ate the productivity loss that came from ditching their products.

Avamander 3y ago

To be fair WSL is quite cursed. There are a lot of things Microsoft has done that result in less than good workarounds.

Culonavirus 3y ago
So far I managed to get by using wsl just for redis, most software packages these days do actually have decent windows version, including pytorch etc. I considered switching over to wsl more, but I ran to wsl being very slow in terms of filesystem access, I think it had something to do with wsl 1 being (somewhat?) native while wsl 2 runs under hyperv. I think it's still not fixed.
- hackandthink 3y ago
  Rancher Desktop is very slow. There must be a driver (virtio?) issue in their WSL VM. Podman is much faster.
- iimblack 3y ago
  Wsl2 has been significantly faster for me as long as I store the files in the wsl drive. I had react projects that would completely fail to get through npm install on windows but finished no problem on wsl. Microsoft docu seems to recommend wsl 2 as well. https://learn.microsoft.com/en-us/windows/wsl/compare-versions#increased-file-io-performance https://learn.microsoft.com/en-us/windows/wsl/compare-versio...
gavinray 3y ago
In my experience, WSL2 works like a dream. I have nothing but good things to say about it. WSL1 was sort of clunky and slow but I feel no difference from using native Linux in WSL2. Plus, the VS Code integration for it is spectacular.
- Daynil 3y ago
  Second that. I was tepid on WSL on initial release, but recently decided to try a full switch after hearing good things and I'm glad I did. You're literally using a full Linux distro, it's really fast, and it even has neat integrations with windows like allowing use of windows explorer if you're inclined. And it's totally seamless to use with vscode.
- hackandthink 3y ago
  Remote VS Code for WSL feels sometimes clunky to me. Another option: running Emacs as GUI App in WSL. https://code.visualstudio.com/docs/remote/wsl-tutorial https://code.visualstudio.com/docs/remote/wsl-tutorial https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-...
politelemon 3y ago
Quite the opposite - WSL(2) is one of the best things that have come out of MS in a long time.

mdasen 3y ago

I'm kinda getting to that point as well. The new UI is a big one for me. The issue is that it hides a lot of the buttons until you hover over a certain area. If I want to minimize the terminal, I have to move my pointer to the terminal's toolbar and only then will the minimize button appear. That means that I can't target the minimize button. It becomes a two-step process with a slight delay waiting for the minimize button to fade in so I can move the cursor to it. Likewise, the "x" button to close tabs is hidden until you hover over the tab. This means that I'll go to try and select a tab and when I move my cursor over the tab and click, an "x" has just appeared under my cursor and I close the tab instead! Whoops, I guess I should have known better than to aim my cursor at the right portion of the tab. It feels like they're trying to make it seem more like VSCode, but it's just poor UX from where I'm sitting. Plus, as VSCode gets better, I'm finding less reason to keep paying for the JetBrains suite.

vips7L 3y ago
If the new UI is such an issue, why haven’t you switched back? The majority of developers I know haven’t even bothered with the new UI.
- GordonS 3y ago
  I switched back too, as the new UI is just... ugly. It looks and feels more like something for children than a serious IDE. I've even gone back and tried it in earnest, but in all honesty I just don't understand why JetBrains have spent so much time and effort on something that's simply worse than the original UI. I'm dreading the day where the old UI is replaced with the new UI... I might seriously have to look at going back to Visual Studio, and I'd really rather not - I just want to keep the existing, perfectly fine UI!
- lacrimacida 3y ago
  Switching back is a deferral until it eventually gets shoved down on our throats
- therealdrag0 3y ago
  I never tried the new UI. Happy with the original!

vips7L 3y ago

Gradle breaks itself every month, without Jetbrains’ help. Just use Maven. It works everywhere, all the time.

somehnguy 3y ago
I’ve never experienced Gradle outright breaking itself, but it does deprecate things at a high rate. We try to update dependencies whenever we touch a project, which every few months means making an adjustment for whatever Gradle decided to deprecate and start warning about now. I’ll still take it every time over Mavens XML based config though.
- vips7L 3y ago
  I honestly don’t understand this position. You’d rather have to update your build or have it be inconsistent or down right broken over having to write some XML?
- gavinray 3y ago
  I would consider myself a very advanced Gradle user. I keep up with experimental/nightly features and best-practices. I have a love-hate relationship with Gradle. I think it's a better alternative to XML (if you keep it declarative and any kind of stateful logic the hell out of your build scripts). BUT. Gradle introduces breaking API changes frequently, and they have changed around "best practices" every year or two. You can easily see this by using "gradle init" to create a new project. It used to be the case that "buildSrc" was the recommended way to do multi-module build logic composition. But it didn't even work with the recommended "libs.versions.toml" file for managing dep versions (you couldn't reference the generated code from within your buildSrc logic). Sometimes I consider switching to Maven, lol. Have to weigh the effort required to keep up w/ changes against the benefit of using strongly-typed build files.
ptx 3y ago
Unfortunately you can't use it for Kotlin/JS anymore. Jetbrains recently removed the Maven support from the Kotlin/JS tooling, so it now just pops up a message telling you to migrate to Gradle.

kevingadd 3y ago

This has always been the jetbrains customer experience. They don't prioritize quality so if you're unlucky they'll break your workflow repeatedly, and the fixes will arrive in a major release with new bugs that you have to pay for. I eventually gave up and ate the productivity loss that came from ditching their products.