Live data from Hacker News

JetBrains invites developers to join the Fleet Public Preview Program

blog.jetbrains.com

121–130 of 332 posts

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

#121
post #109

I installed this 30 min ago. 1. My M1 temp went from 28c to 60c 2. CPU utilization to 103%? 3. It's using 3.29Gb of RAM And it hasn't changed. With a single python project with 3k lines of code. VSCode sits at 280Mb and CPU temp around 28c. Edit: Vim + SpaceVim sitting at 17Mb :)

On my Linux, it barely consumes anything and opened 300k line code without a problem when VSCode crashed instead. I guess the OS matters.

I was experiencing similar performance problems on linux. Multiple cores pegged and multiple gb used while idling.

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

#122

Earlier quoted context omitted.

I'd say they still don't understand why VSCode adoption is rising. There are two reasons: - People don't know better (yes, they really don't) - Language server allowed languages with abysmal tools to finally have some semblance of an IDE None of us know the future, but in my opinion Fleet is a mistake: - It tries to fight VSCode at VSCode's turf (an editor with primitive IDE functionality) - while trying to be a test…

People don't know better (yes, they really don't) Or maybe VS Code is just really good? I was skeptical for a long time as well. I am a longtime Emacs and JetBrains IDE user (starting with IntelliJ in 2013). A while back I gave VS Code a try again. I primarily used CLion for Rust and PyCharm. And I found that the Rust/Python is at least as good as in CLion/PyCharm (with the exception of Cython). And thanks to VS Code…

I also think vscode is really good enough for development and has a healthy plugin interface. I only miss my vim navigation when working in it, nothing beats vscode remote mode and it's free.

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

#123

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

Same here, but maybe it's for education / quickly talking through an issue or solution? Otherwise, I really fail to see the value add vs git.

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

#124
Problem with JetBrains support docker for PyCharm and most likely other IDEs.

1. Why JetBrains can not connect to docker running container by using exec operation and read installed packages?

Issue: - It is not possible to just go into running container install some library and get it visible within IDE, it needs to go via all pain to clear caches and wait until IDE will load again.

How it works now: - It creates copy of docker image and read installed packages from it, does not read anything installed within currently running container. - Developer needs to install packages within image creation for PyCharm to pickup it. If package is installed in current container, developer needs to go clear caches, restart IDE, wait until it loads etc. and it is because the way how JetBrains integrates and supports running docker containers.

::Reproducing issue with running docker containers within Pycharm:: --- If you want to reproduce issue create docker-compose installation with python. Start by running "docker-compose up" from terminal load PyCharm and configure everything what is require within PyCharm.

Going into running container by terminal: # docker-compose exec ... bash # pip install pip-licenses

This pip-licenses package will not be visible inside IDE! Developer needs to go clear all caches, reload PyCharm and do other things just to get package recognised from running docker container. ----

2. Why jetbrains can not find proper solution to see packages from currently running container without clearing caches? Cache should be update if recognised that new package exist within currently running container, not by developers maintaining jetbrains IDE caches. 3. VSCode(free IDE) did find how to support running docker containers, but paid product by Jetbrains can not solve this problem? 4. Can you at least implement something similar level to VSCode for running docker containers?

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

#125

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…

> 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.

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

#126
post #103

Earlier quoted context omitted.

Sure but WebStorm is targeted solely/mainly at JavaScript development. What if my employer has N repos and several other languages, and JavaScript is just one of those. VSCode allows me to stay with the same interface across multiple different repos. Yes, if I’m doing Ruby or Java or C# I might choose a _different_ IDE for certain tasks in that language. But with a few plugins you can get a reasonably good generalist…

Almost all of the jetbrain products are just intellij with a different set of plugins preinstalled (with perhaps the exception of clion which has a bit more native integration with debuggers), so you can quite likely just use intellij with a few plugins you want for everything.

Rider is also a bit different in how it handles Visual Studio solution / project files AFAIK. You can definitely rig up IntelliJ for e.g. Python development, but PyCharm is going to be a far better experience.

I pay for the All Products Pack purely out of convenience - If I wanted to spend a ton of time tweaking my IDE, I'd go back to Emacs!

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

#127

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…

[off topic] Are you guys affected by the situation in Russia, or have all JetBrains employees left the country already?

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

#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!

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

#129

Earlier quoted context omitted.

> For some reason, some people are very reluctant to pay for tools, even though they use them every day in their job. This also really baffles me. You can see it a lot in various discussions even here on HN.

Because if your tooling is closed source (and if it's paid it almost certainly is) then your ability to maintain a project is dependent on some corporation's willingness to continue to support the tooling etc.

If the possibility of your tooling being discontinued is a real concern for you, paying for a Jetbrains license is your best bet. Their entire business is developer tooling: IntelliJ isn't going away until Jetbrains goes under, and they're not going under until people stop paying them. Microsoft, on the other hand, could decide to drop VSCode at any point as soon as the bean counters start questioning how it's benefiting the bottom line.

And if Microsoft decides to kill VSCode, I seriously doubt anyone is going to keep maintaining it at the place where it is now. Even if someone decides to continue maintaining the base editor, Microsoft abandoning it will pretty quickly dry up the plugin ecosystem.

"It's open source, so it will always be available to me" only really makes sense if your backup plan is to maintain it yourself. In the case of VSCode, you are relying on a whole ecosystem continuing to survive after the sponsor abandons it.

Post reply on HN