JetBrains Fleet: The Next-Generation IDE by JetBrains
61–70 of 169 posts
Re: JetBrains Fleet: The Next-Generation IDE by JetBrains
#62Meanwhile 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.
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
#63Earlier 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)
Re: JetBrains Fleet: The Next-Generation IDE by JetBrains
#64But 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
#65And 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
#66Meanwhile 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…
Re: JetBrains Fleet: The Next-Generation IDE by JetBrains
#67This 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…
Re: JetBrains Fleet: The Next-Generation IDE by JetBrains
#68Re: JetBrains Fleet: The Next-Generation IDE by JetBrains
#69Earlier 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)