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.
JetBrains invites developers to join the Fleet Public Preview Program
121–130 of 332 posts
Re: JetBrains invites developers to join the Fleet Public Preview Program
#122Earlier 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…
Re: JetBrains invites developers to join the Fleet Public Preview Program
#123Jetbrains 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
Re: JetBrains invites developers to join the Fleet Public Preview Program
#1241. 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
#125This 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…
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
#126Earlier 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.
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
#127This 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…
Re: JetBrains invites developers to join the Fleet Public Preview Program
#128They 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
#129Earlier 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.
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.
Re: JetBrains invites developers to join the Fleet Public Preview Program
#130Literally my laptop that I bought for $1300 3 years ago.