Live data from Hacker News

JetBrains Fleet: The Next-Generation IDE by JetBrains

jetbrains.com

61–70 of 169 posts

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#62
post #8
post #7

Meanwhile IntelliJ is rotting with months-old bugs that render entire features useless, with no fixes and no ETAs in sight. The only product that I pay money for that constantly, on almost every release, pains me with new bugs, a good portion of which are never fixed. I thought about using other Jetbrains products like DataGrip (and now this Fleet), but I'm not going to invest even more into a company that simply ref…

IntelliJ IDEA along with the platform is the largest team at JetBrains and we're constantly working on bugs and features. If you can please point me to the issues you're referring to in YouTrack, I can check the status.

I shouldn't have to point out just how broken that is as a way of supporting paying customers.

Like the OP I've simply stopped reporting bugs, because they don't get looked at for literally years, let alone fixed.

The product is OK-ish, the support is abysmal.

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#63
post #56
post #8

Earlier quoted context omitted.

IntelliJ IDEA along with the platform is the largest team at JetBrains and we're constantly working on bugs and features. If you can please point me to the issues you're referring to in YouTrack, I can check the status.

People on this issue[1] have been asking themselves the same questions. New very specific features are added with every new releases. However, the Git/shelf experience is lacking the ability to commit specific lines. [1] See this highly voted issue: https://youtrack.jetbrains.com/issue/IDEA-186988 (opened since more than 3 years already)

That looks like a feature request, not a bug. Am I wrong?

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#64
I get a horrible feeling in my stomach when I see these "remote" IDE options. I am very sure that they have their benefits, coding from a thin-client machine and having an "always on" session in the cloud ...

But it feels like a slow errosion of our control and ownership of our tools. Where everything is becoming a rent-seeking opportunity and good tools are made available for a monthly rent.

Personally I like having my whole build system, IDE, CI/CD on a machine I work at. I get this might not be for everyone, but I think we need to be careful what we give up long-term for these conveniences.

Granted, I could just use VI and a terminal and nobody is forcing anyone to use anything ... but like many things, they are not like-choices.

I depend on my tools, and the fewer dependencies to paid-montly SaaS features the better.

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#65
I'd rather they fixed the remote development in IntelliJ first. You can sort of (ab)use the remote deployment feature in Ultimate for it, but it's clearly not intended for that. And it's extremely clunky - for example the ability to exclude files from syncing is completely underpowered.

And why the hell is selecting files yet another different way of doing what's basically the same task as elsewhere? I'd suggest they should be using the File Scopes feature except it's terminally useless, with it's wierd-ass, barely documented and inadequate syntax. I've never managed to get it to work adequately.

There seems to be a common failing with JetBrains product development, they try to rush out as many different features as possible, presumably for the purposes of marketing "tick lists", but many of them are poorly designed, bug ridden and never worked on after v1.0

IntelliJ - because all the alternatives are even worse.

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#66
post #7

Meanwhile IntelliJ is rotting with months-old bugs that render entire features useless, with no fixes and no ETAs in sight. The only product that I pay money for that constantly, on almost every release, pains me with new bugs, a good portion of which are never fixed. I thought about using other Jetbrains products like DataGrip (and now this Fleet), but I'm not going to invest even more into a company that simply ref…

I feel the same about Resharper. I stopped using it after many years simply because I could no longer bear the typing latency that is causes. I even bought a new laptop thinking the old hardware was to blame, only to discover the latency has barely improved. I'm now happy with "bare" Visual Studio 2022 - it may have fewer niceties, but I'm so much more productive!

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#67

This nicely shows why I like my JetBrains IDEs so much: They look at what is successful and then they don't mindlessly clone the product, but they cherry-pick the core reasons why it is successful. I have also observed that cloud coding environments (e.g. AWS Cloud9) have become more popular and I totally get why. Collaboration is easy and you can have a Linux runtime close to your production servers even though your…

But, out of the box, the interactive performance is awful, and getting worse with each version.

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#68
I use PyCharm for work and what frustrates me about JetBrains is they're constantly pursuing these greenfield projects while bugs in the IDE that are ten years old are still unresolved. I can't trust them to develop this when their other "new" features like CodeWithMe session-sharing are still very buggy and incomplete.

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#69
post #25

Earlier quoted context omitted.

Interesting that you would use Rust for those operations since the JVM was already presumably giving you cross-platform implementations. Was that a significant performance bottleneck that got alleviated by using Rust, or was there another reason?

Whole architecture of Fleet is distributed, so we need a small binary without dependencies that could be uploaded to the dev container. All the access goes through that binary (even in local case)

It's interesting and says something about the state of tooling that, in response to those requirements, it was easier to switch to an entirely different language and ecosystem than it was to build off the existing work and convince the toolchain you were using to produce output with those properties.

Re: JetBrains Fleet: The Next-Generation IDE by JetBrains

#70
While they don’t specifically say what the “language server” is, if it’s the same protocol that powers VS Code[1], this is a big deal. It potentially means that language owners can build tooling that works across IDEs much more easily. Historically, JetBrains seems to have resisted the idea of a standard language protocol (which makes sense as it comes from Microsoft). My guess is it’s becoming impractical to reimplement every language feature for Typescript, C#, Go, etc. Embracing the standard LSP will mean less time spent on low level features and more time building JetBrains only value add.

[1] https://microsoft.github.io/language-server-protocol/

Post reply on HN