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

JetBrains invites developers to join the Fleet Public Preview Program

blog.jetbrains.com

Post reply on HN
Print view View original

201–210 of 332 posts

Re: JetBrains invites developers to join the Fleet Public Preview Program

#201

Post by ZeroCool2u »

MikhailVink wrote: post #116
_fat_santa wrote: post #45

This looks really promising. But by far the biggest moat that Jetbrains is going to have to cross to get into VSCode territory is the plugin ecosystem. Personally I work on React projects so my first thought was: "is there a Prettier[1] plugin?". Looking through the landing page it looks like Plugins are in the works but until that is implemented, it's going to be hard adopting it. ALSO I just noticed this but can so…

JetBrains employee here, and I can clarify the point about “Requires login and periodic connection to JetBrains servers to verify the project”. If you are using Fleet in a Free (hobby) mode, we are verifying that the project comply with one of three criteria: 1. your project is local (no Git or Git Remote). 2. your project is public on GitHub. 3. your project is private but has less than 3 committers. In this case, w…

I'm sorry, I know this is off topic, but I've been looking around at the Fleet docs and can't quite find an answer to this so far, so just hoping you might have an answer.

Does the front end stack of Fleet allow one to run it in a browser when using a remote back end? The same way you can run the back end of VS Code or JupyterLab on a server and render the front end in a browser tab?

I understand you can run the front end locally on your desktop and the back end configured as a remote on a server, but the rendering of the front end in a browser is what I need for the dev environment I need to use at work[1].

[1]: https://www.dominodatalab.com/

Re: JetBrains invites developers to join the Fleet Public Preview Program

#202

Post by ZeroCool2u »

topka wrote: post #145
dangerboysteve wrote: post #136

To use Fleet you have to download the JetBrains Toolbox. Really? Look, I'm a JB subscriber and have the toolbox, but Fleet should not require another app to launch or update itself.

[JetBrains employee] In the future Fleet will be able to update itself. Right now, we use Toolbox App as it can do Fleet updates easier.

I personally love Toolbox in our corporate environment. I just wish it would default to using system proxy settings on Windows and propagate Proxy settings to the IDE's it installs by default.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#203

Post by tomjen3 »

kburman wrote: post #100

Jetbrains seems so confident about future being full of collaboration. For me it would be very hard to work if someone else is also updating the codebase at the same time. Anyone working like can you share your experience

It only makes sense for distributed pair programming. But that’s not a bad idea either.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#204

Post by miroljub »

TheCondor wrote: post #170
MikhailVink wrote: post #116

Earlier quoted context omitted.

JetBrains employee here, and I can clarify the point about “Requires login and periodic connection to JetBrains servers to verify the project”. If you are using Fleet in a Free (hobby) mode, we are verifying that the project comply with one of three criteria: 1. your project is local (no Git or Git Remote). 2. your project is public on GitHub. 3. your project is private but has less than 3 committers. In this case, w…

Emacs keys would be awesome...

I never understood what's the point of Emacs keys without elisp and Emacs plugins. Emulating only the editor part of Emacs without the rest of what makes Emacs great is not something I would spend time on.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#205

Post by vips7L »

speed_spread wrote: post #195
Kukumber wrote: post #128

They made a mistake to keep using the JVM.. They should have went with kotlin-native from the start EDIT: Ok i gave it a try, so far very responsive, typing latency feels much better than vscode, overall i like the UX, they kept it simple yet very well organized Much better than vscode already, congrats!

Native code makes it much harder to design a runtime plugin system. Also, other than fast startup and lower memory usage, native code does not make the app faster.

And if OP is concerned with latency, you're not going to beat the JVM's latency sensitive GC's.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#206

Post by bombardier6789 »

tester756 wrote: post #142
jasode wrote: post #49

Earlier quoted context omitted.

>But what does distributed mean in this context? The older Jetbrains IDEA IDE is a monolithic local application. E.g. it does both UI navigation _and_ batch processing work like source code indexing . Fleet is re-architected to be "distributed" aka "client/server" style into a "lightweight" frontend + "heavyweight" backend. E.g., the frontend does UI navigation and basic syntax parsing but the backend (which can be o…

so, modular? :) crud app with frontend + backend is not distributed, but it definitely is client/server architecture but that's just nitpick, iirc "distributed" means something different in their context

What would be your definition of distributed?

Re: JetBrains invites developers to join the Fleet Public Preview Program

#207

Post by evgen »

miroljub wrote: post #204
TheCondor wrote: post #170

Earlier quoted context omitted.

Emacs keys would be awesome...

I never understood what's the point of Emacs keys without elisp and Emacs plugins. Emulating only the editor part of Emacs without the rest of what makes Emacs great is not something I would spend time on.

Muscle memory. I gave up on Emacs as an editor almost 15 years ago but having spent the prior 15 using it for coding I still set most of my cli editing to use emacs key-bindings and use it in my IDEs.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#208

Post by MatthiasPortzel »

MikhailVink wrote: post #141
zamalek wrote: post #125

Earlier quoted context omitted.

> your project is public on GitHub. What about Gitlab, or some other repo such as gitlab.gnome.org? This seems like it's ripe for edge cases.

Yeah, right, I was not specific enough on this one. It'll definitely go beyond GitHub, extending to some other git solutions, but we don't have a decision whether it's "any" public repo or public repo hosted on the service from some list (like, GitHub, GitLab, Gitee, etc.) We'll look into it later on. gitlab.gnome.org - I'd expect it to be all open source, right? Open source program should cover such cases.

I really hope that in further investigation you (JetBrains) realize how futile it is to attempt to automate defining something like this.

The best-case scenario I can imagine is that I have to enter a public URL into the editor that JetBrains can then `git clone` from their server.

I can’t imagine “JetBrains curates a list of all public git servers” ends well. (As a Tildegit user.)

Re: JetBrains invites developers to join the Fleet Public Preview Program

#209

Post by Mikeb85 »

Kukumber wrote: post #198
speed_spread wrote: post #195

Earlier quoted context omitted.

Native code makes it much harder to design a runtime plugin system. Also, other than fast startup and lower memory usage, native code does not make the app faster.

> Native code makes it much harder to design a runtime plugin system That's not true, lua, lua-jit, quickjs, v8, c#, even java Game engines already have the lead in that area and they proved that it's possible and can be made very efficient The UI and host of the program should be native to maximize performance Native code helps write fast code that runs fast with optimized memory layouts

> Game engines already have the lead in that area and they proved that it's possible and can be made very efficient

Game engines basically implement their own "runtime". They all have stuff like memory management, scripting languages (and usually plugins use the scripting API), and the game is just a package of assets and code that are run by the engine...

Re: JetBrains invites developers to join the Fleet Public Preview Program

#210

Post by kobepanda »

onebot wrote: post #110

I would love this if it wasn't also built on the Java runtime. I hoped the "from ground up" rewrite to include a new much more performant backend that didn't burn resources. To be fair, I even think VSCode is too slow. I have been loving Helix Editor since it gives a great out-of-the box experience for terminal. But craving a better VSCode replacement. Had high hopes for Fleet, but I guess you can't teach an old dog…

I've been liking https://zed.dev/ for something that gives me more smarts out of the box than Sublime Text but maintains the responsiveness. Limited set of languages but it supports the ones I use on the daily
Post reply on HN