191–200 of 332 posts
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!
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 :)
However, from using the other JetBrains tools the performance killer for builds and indexing libraries and documentation has typically been slow file system access.
These IDE even warn you when they detect this. I don’t remember seeing this warning in the Fleet preview.
A common solution is to disable aggressive anti-virus scanning for you project folder and some key application folders so it does not slow down the build.
Another cause is slow remote mounted file systems that you might have if you are using VMs, WSL or Docker.
If I remember correctly the docs have detailed information about this.
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!
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…
I have looked into source codes of some and were horrified, but well, some people actually like Java and like that sort of stuff. Maybe I looked into wrong ones.
VSCode plugins seems to be easier to write, but maybe that’s because I know JavaScript already.
What made me switch to VSCode is that it’s generally snappier, IDEA has the “Indexing” mode that always takes forever
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…
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.
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
Earlier quoted context omitted.
> Lots of complexity for small amount of gain Being able to develop on a huge beefy cloud instance, with managed background services, possibly with different architectures, from your laptop is huge . > But then they say "distributed" so that would mean many backend machines, not just one. ‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.
A "huge beefy cloud instance" comes with a premium price, especially if you're planning to use it for a year or two, while also coming with its own set of problems: No internet connection? No luck! Downloading dependencies for your backend? Start paying per GB downloaded, and so on. > ‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two. A client server architecture is generally not considered "distributed"…
Ok? What's that got to do if it's useful or not.
> Usually when it comes to these kind of architectures, you'd refer to them as "thin clients"
Ah well the difference here is the client does a lot more work - it's running the editor, the editing and the editor state, it's not just transmitting input and receiving drawing commands.
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…
I officially have a copy of pycharm and not webstorm. I use it to maintain both a python repo and a typescript repo. You can install language support for almost every official jetbrains language into basically any jetbrains editor. The only differences I have found are the default plug-ins and the app icon.
It certainly used to be (and I believe its still the case) that the "major" language plugins besides JS are only usable in their specific IDE or in IDEA Ultimate (which can run all of them) (i.e. PHP w/ PHPStorm, Ruby w/ RubyMine and Python w/ PyCharm)