Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JetBrains Fleet: The Next-Generation IDE by JetBrains

jetbrains.com

Post reply on HN
Print view View original

101–110 of 169 posts

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

#101

Post by stetrain »

axegon_ wrote: post #99

I am not sure how I feel about this. JetBrains either get things very right or very wrong. At this point I feel like there a pattern: Their desktop applications(IDEs) are usually great. However, my experience with their server-side solutions(teamcity, upsource) has been nothing short of explosive diarrhea. With the "remote" word tossed in there, I'm not entirely optimistic.

It's as remote as VS Code is, meaning you can run it entirely locally or as a thin client to a server that's hosted in a VM, docker container, WSL, or a remote server.

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

#103

Post by closeparen »

sirsinsalot wrote: post #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…

JetBrains makes money selling to corporate engineering orgs. In that context the incentives towards remote development environments are very strong. You can get a developer immediately productive (again) by restoring a golden image. Instead of paying engineers to optimize the build or write IDE plugins to index manageable subsets of the codebase, you can just throw power at it. Remote dev environments at my company have 96 cores. The monorepo builds in about a tenth of the time. Unfortunately I think it’s inevitable.

The only thing slowing it down was developer rejection of the austerity of vim and emacs. That’s changing now with VSCode’s in-browser and SSH Remote support. That’s the golden path now at my work. Although we still pay for JetBrains licenses, the JetBrains workflow is quietly and unofficially deprecated.

They have to do this to stay relevant. And I’m glad they’re doing it, because I want my JetBrains-level capabilities back. VSCode doesn’t come particularly close.

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

#104

Post by kaba0 »

codesections wrote: post #79

> It starts up in seconds so you can begin working immediately They and I have a very different idea of what the word "immediately" means

Tell me one graphical application that starts up in less than 0.1 sec on desktop? Unfortunately, desktop OSs don’t employ optimizations like what exists on android and ios, which strangely manages to start programs in that timeframe.

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

#105

Post by johannes1234321 »

closeparen wrote: post #103
sirsinsalot wrote: post #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…

JetBrains makes money selling to corporate engineering orgs. In that context the incentives towards remote development environments are very strong. You can get a developer immediately productive (again) by restoring a golden image. Instead of paying engineers to optimize the build or write IDE plugins to index manageable subsets of the codebase, you can just throw power at it. Remote dev environments at my company h…

Just to add reasons:

Especially in corporate context this will be the future for compliance reasons. No more developers who accidentally have code on their machine and lose it. Less access tokens on the client machines etc.

Will be an interesting trend of going back to the mainframe ... and will be interesting to see how that will collide with developers who want to have control and chose their tools and setup.

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

#106

Post by packetlost »

amcoastal wrote: post #96
cedws wrote: post #77

Earlier quoted context omitted.

No wonder developers complain about sluggishness and running out of memory when they're literally using a headless web browser to write code. Sublime Text works brilliantly. I can have tens of projects, hundreds of files open and the memory usage is peanuts. I don't get the hype about "modern" IDEs let alone remote IDEs.

I'm sure you already know this, but I used to use sublime text and moved to an IDE because of the debugging features. Sublime text and a terminal is great for simple problems, but you'll cost yourself a lot of time doing print statements when you could just use an IDE.

This is perhaps more related to the language than you think. Many languages have good debugger support from a terminal.

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

#107

Post by eminence32 »

sirsinsalot wrote: post #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…

I know you are mainly commenting on "cloud remote" things, but I do want to mention that I find VSCode's "remote ssh" mode very useful, and I use it frequently when I'm sitting at my windows desktop and I want to edit code on the headless linux machine in my basement.

So in general I am positive on IDEs that allow some type remote editing experience.

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

#108

Post by discreteevent »

mmargerum wrote: post #71
nathantotten wrote: post #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 reimple…

now that we have LSP running as an external process I hope they jettisoned java and are instead using C/C++/Skia or something for the editor so it's fast.

How do you know that it is java that is making it slow? Do you work for jetbrains?

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

#109

Post by closeparen »

johannes1234321 wrote: post #105
closeparen wrote: post #103

Earlier quoted context omitted.

JetBrains makes money selling to corporate engineering orgs. In that context the incentives towards remote development environments are very strong. You can get a developer immediately productive (again) by restoring a golden image. Instead of paying engineers to optimize the build or write IDE plugins to index manageable subsets of the codebase, you can just throw power at it. Remote dev environments at my company h…

Just to add reasons: Especially in corporate context this will be the future for compliance reasons. No more developers who accidentally have code on their machine and lose it. Less access tokens on the client machines etc. Will be an interesting trend of going back to the mainframe ... and will be interesting to see how that will collide with developers who want to have control and chose their tools and setup.

The very first step of our engineering onboarding process is to turn on FileVault...

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

#110

Post by skue »

sirsinsalot wrote: post #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…

It’s an option, just as it is for VSCode.

Personally I love seeing this option because it lets me run my dev environment in a local VM. Sadly, I no longer trust community-developed editor plug-ins or dev tools to be free from malicious code. We talk about the problems with npm dependencies all the time on HN. How often do you audit the dependencies of your favorite VSCode plugins? I simply don’t want that code running on my system with full user access, and this architecture lets me avoid that. Of course there are still risks with it having access to dev code, but reducing potential exposure is a good thing.

Post reply on HN