JetBrains invites developers to join the Fleet Public Preview Program(blog.jetbrains.com)
blog.jetbrains.com
JetBrains invites developers to join the Fleet Public Preview Program
https://blog.jetbrains.com/fleet/2022/10/introducing-the-fleet-public-preview/
331 comments
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, we will need a periodic connection to JetBrains servers to exchange information verifying that you can use Fleet for free, but in no way we would send any sensitive information, such as source code, file names, etc.
If you have Fleet license (paid, for example) there are no criteria checks at all, just the license verification with your JetBrains Account. And we plan to support offline usage similar to how it’s done for IntelliJ IDEA-based IDEs now (offline license keys, floating license server.)
Right now Fleet is in the EAP, and there are no licensing checks at all, they are not yet implemented, and we are not yet done with the verification workflow design.
If you have Fleet license (paid, for example) there are no criteria checks at all, just the license verification with your JetBrains Account. And we plan to support offline usage similar to how it’s done for IntelliJ IDEA-based IDEs now (offline license keys, floating license server.)
Right now Fleet is in the EAP, and there are no licensing checks at all, they are not yet implemented, and we are not yet done with the verification workflow design.
I don't care why but this is creepy. Use a token in a public repo, not some sort of callback scheme. My IDE should not be doing authorization checks that involve telling a third party what I'm working on, under any circumstances.
Then don't use the product for free?
Or maybe... find a way to not be creepy? They're the ones trying to convince people to move from VSCode.
The amount of data that VSCode collects dwarfs this though.
It's a single toggle to turn off all telemetry (anonymized, limited to feature usage - no reporting of source files/projects that I've seen), which takes a few seconds to configure at install time as it's literally a menu item (Code > Preferences > Telemetry):
https://code.visualstudio.com/docs/getstarted/telemetry
You can also dump all possible telemetry events at the command-line.
https://code.visualstudio.com/docs/getstarted/telemetry
You can also dump all possible telemetry events at the command-line.
You can’t really shut down all VSCode telemetry.
Source: https://www.roboleary.net/tools/2022/04/20/vscode-telemetry....
Source: https://www.roboleary.net/tools/2022/04/20/vscode-telemetry....
FTA:
> Next, I wanted to see what would happen when I disabled telemetry. After some activity, I checked the log, and found no events were logged. That is good.
> Next, I wanted to see what would happen when I disabled telemetry. After some activity, I checked the log, and found no events were logged. That is good.
One paragraph after:
> The absence of logged events doesn’t mean that data is not being sent though! A more accurate way to see what is being sent out is to monitor your outgoing network traffic and analyze the packets.
But unfortunately the author doesn't do that
A bit further down they say
> It looks like you cannot shut telemetry off 100%. These settings will opt you of most data sharing scenarios; but not all data sharing scenarios
And even VSCodium doesn't take it all out
> Even though we do not pass the telemetry build flags (and go out of our way to cripple the baked-in telemetry), Microsoft will still track usage by default.
> The absence of logged events doesn’t mean that data is not being sent though! A more accurate way to see what is being sent out is to monitor your outgoing network traffic and analyze the packets.
But unfortunately the author doesn't do that
A bit further down they say
> It looks like you cannot shut telemetry off 100%. These settings will opt you of most data sharing scenarios; but not all data sharing scenarios
And even VSCodium doesn't take it all out
> Even though we do not pass the telemetry build flags (and go out of our way to cripple the baked-in telemetry), Microsoft will still track usage by default.
Source?
Luckily, Microsoft has a track record of being totally non-creepy about your data.
Is that sarcasm?
I’ll just stick with not using JetBrains software like I haven’t for the past two decades. Bloated and slower than Eclipse.
Your IDEs' project management are broken for people who use git CLI (everyone?): https://youtrack.jetbrains.com/issue/IDEA-183490
The issue is marked "shelved" while consistently active. Do you have any ability to run this up the flagpole, please? I and many others would be very grateful.
The issue is marked "shelved" while consistently active. Do you have any ability to run this up the flagpole, please? I and many others would be very grateful.
Nope nope nope. This is creepy and I can guarantee that it'll be headache after headache. I'll stick to the alternatives so long as this is the policy. Not even going to look at it.
Doesn’t everyone run a git init even if you never push it anywhere? My local projects usually get git with in an hour of me working on them.
> 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.
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.
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.)
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.)
Manual rule that never gets defined for good sounds like a trouble waiting to happen. It will cause many support tickets asking for every edge cases and some will be angry for not being approved.
If you're really trying to win VS Code users, such a flexible rule may scare them away.
If you're really trying to win VS Code users, such a flexible rule may scare them away.
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/
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/
[off topic] Are you guys affected by the situation in Russia, or have all JetBrains employees left the country already?
They have stated their position really clearly (and much more clearly than most companies): https://blog.jetbrains.com/blog/2022/03/11/jetbrains-stateme...
I wasn't asking about the company position...
New office opened in Cyprus, lots of positions open on their site. I assume they are expanding out of Russia.
They opened a company in Serbia so I guess that some of the Russian employees already moved to Belgrade.
Will the pricing be same for all users or do users with existing licences (e.g. Ultimate) get a discount on Fleet licence?
We are not ready to share more details on pricing yet, but we are working on it. Will share as soon as we have it!
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.
> 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?".
This just reinforces my feeling that a major driver behind VSCode's popularity is that people just don't know better [1]
1. Download WebStorm (or IDEA) and write some React in it. And Typescript. Refactor. Move code around. Use suggestions. It's leaps and bounds ahead of VSCode
2. Open settings, navigate to plugins, type in Prettier. Oh look, there's the plugin. An official plugin from JetBrains
[1] https://news.ycombinator.com/edit?id=33176123
This just reinforces my feeling that a major driver behind VSCode's popularity is that people just don't know better [1]
1. Download WebStorm (or IDEA) and write some React in it. And Typescript. Refactor. Move code around. Use suggestions. It's leaps and bounds ahead of VSCode
2. Open settings, navigate to plugins, type in Prettier. Oh look, there's the plugin. An official plugin from JetBrains
[1] https://news.ycombinator.com/edit?id=33176123
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 tool in VSCode, and even a pretty full featured one for certain languages
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 tool in VSCode, and even a pretty full featured one for certain languages
It's not. At least as far as I can tell, the different Jetbrains IDEs are more like configurations or flavors of the same underlying thing. You can do most things in most of their IDEs.
You should try paying for an IDE. VSCode is great but if you're an engineer getting paid anywhere close to a Silicon Valley wage (or you can expense devtools), you deserve better :)
You should try paying for an IDE. VSCode is great but if you're an engineer getting paid anywhere close to a Silicon Valley wage (or you can expense devtools), you deserve better :)
I was considering CLion, but decided against it because I frequently need to work with a bunch of different programming languages in a single project, not just C or C++, and not just the languages they happen to have an IDE for. It seems like Jetbrains does this so you're forced to buy multiple IDEs if you need support for a multiple languages. I don't even know how that's supposed to work. If I need to switch to editing Python, am I expected to open a second IDE? CLion supports plugins, but it doesn't seem like they offer a plugin that brings it on par with PyCharm (because if they did that, they couldn't sell you a second product)
For highly specialized development teams I guess it makes sense, but for me it'd just be a waste of money.
That's why I use Sublime Text, since it's the only (good) editor that's compatible with anything I need it to do. An alternative like Fleet is very interesting, but it's still too early to make a fair comparison (Also that Adobe-esque "toolbox" app isn't winning it any points)
For highly specialized development teams I guess it makes sense, but for me it'd just be a waste of money.
That's why I use Sublime Text, since it's the only (good) editor that's compatible with anything I need it to do. An alternative like Fleet is very interesting, but it's still too early to make a fair comparison (Also that Adobe-esque "toolbox" app isn't winning it any points)
most of their ides are plugins for language support basically. i use idea for java, c, golang and python. as well as the built in db ide stuff that is standalone as datagrip
I often have all three of CLion, WebStorm, and PyCharm open. I'm pretty sure I could use IntelliJ for all the use-cases, but the configuration presets make it easier to open all three. As far as memory use goes, I've not had problems -- it seems much more that resources scale with the number of projects open, rather than the number of IDEs open.
I open polyglot projects in whichever IDE is the closest superset of the languages it uses. Which normally means whatever language the service is written in, and plugins for other languages.
I open polyglot projects in whichever IDE is the closest superset of the languages it uses. Which normally means whatever language the service is written in, and plugins for other languages.
While the various product are more or less different flavors of the same program, if you want do work on a polyglot project the best choice is probably Idea since is the more flexible. The others have a better out of the box experience for a specific language but have a few limitations here and there.
For example (and if I remember correctly), Webstorm doesn't support a project with different modules, so if you want to split it in two or more parts you have to either create it with Idea and "import" it in Webstorm, or manually edit the project file.
For example (and if I remember correctly), Webstorm doesn't support a project with different modules, so if you want to split it in two or more parts you have to either create it with Idea and "import" it in Webstorm, or manually edit the project file.
> It’s not.
From the WebStorm page on JetBrains:
> WebStorm The smartest JavaScript IDE WebStorm is an integrated development environment for JavaScript and related technologies. Like other JetBrains IDEs, it makes your development experience more enjoyable, automating routine work and helping you handle complex tasks with ease.
From the WebStorm page on JetBrains:
> WebStorm The smartest JavaScript IDE WebStorm is an integrated development environment for JavaScript and related technologies. Like other JetBrains IDEs, it makes your development experience more enjoyable, automating routine work and helping you handle complex tasks with ease.
Right, your comment implies that you can't use e.g. Webstorm for non-JS development. You can, and it'll be a pretty darn good experience. Webstorm just happens to be optimized for web stuff, and there are other IDEs that are optimized for other things.
So the answer to, "what if my employer has a repo of language X and then a different repo of Y?" is: it's very likely not a problem, because the IDEs are not as specialized as you're clearly imagining them to be.
So the answer to, "what if my employer has a repo of language X and then a different repo of Y?" is: it's very likely not a problem, because the IDEs are not as specialized as you're clearly imagining them to be.
> pretty darn good experience
At least when I last did this about two years ago, it wasn't. There are a ton of edge cases. For example, only CLion supported stepping through Rust in a debugger.
At least when I last did this about two years ago, it wasn't. There are a ton of edge cases. For example, only CLion supported stepping through Rust in a debugger.
They come with a bunch of "pre-configurations". I used to have PyCharm, and now I've switched to IntelliJ. I can still do everything I could with PyCharm, which was itself a superset of WebStorm.
Sure, some things are organized a bit differently, but basically, if you want to use multiple languages, just get IntelliJ, and you'll be set. It's cheaper than buying several other products, too.
The only one that seems a bit different is CLion, in that it does things that IntelliJ doesn't, and vice-versa.
Sure, some things are organized a bit differently, but basically, if you want to use multiple languages, just get IntelliJ, and you'll be set. It's cheaper than buying several other products, too.
The only one that seems a bit different is CLion, in that it does things that IntelliJ doesn't, and vice-versa.
I believe AppCode and Rider are more examples of JetBrains IDEs that do things that IntelliJ Ultimate can't.
Appcode, Rider, CLion and Goland are not available as language plugins to other IDEs.
Go most certainly is: https://plugins.jetbrains.com/plugin/9568-go but for the rest you are correct
There's Golang plugin for Intellij Ultimate.
https://plugins.jetbrains.com/plugin/9568-go
I have paid and vscode is simply a better product
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!
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!
I am currently using Python with IntelliJ. What exactly am I missing from PyCharm?
IntelliJ Ultimate lets you install all of the different language toolkits into one IDE via plugins.
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.
Interesting, I didn’t know that but it makes sense to me
Are you sure that works for all languages? I think it's just that the Javascript/Typescript plugins are made available to all IDEs.
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)
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)
Nope, not sure, but I've yet to run into a wall using it daily for the past 2 years.
[deleted]
>It's leaps and bounds ahead of VSCode
It's also paid vs free. For some reason, some people are very reluctant to pay for tools, even though they use them every day in their job.
It's also paid vs free. For some reason, some people are very reluctant to pay for tools, even though they use them every day in their job.
It is precisely because I use it every day that I use VSCode. As much as I like some of the features of JetBrains IDEs I have also had more headaches with them than VSCode. For example at my previous employer our dev machines weren’t great and I routinely needed to have multiple projects open at once. If I tried doing that in IntelliJ it would make my computer basically unusable. When I gave up and used VSCode for all of my projects I was able to have all the projects I needed open without any issues and without really losing any productivity. If JetBrains IDEs were lighter on the system I would consider switching back to them, but honestly at this point I don’t see a benefit in switching back.
Easy solution: make your employer pay for it. IntelliJ tools increase my productivity where saved time easily goes into days, it's easily justified from a cost perspective to an employer.
> For some reason, some people are very reluctant to pay for tools, even though they use them every day in their job.
I used to pay Jetbrains annually, out of my own pocket. I continued paying fir a personal license even after my employer bought me another license. Jetbrains then made a stupid, greedy decision[1] (and walked or back within days), but I was done with them and canceled my subscription.
Since then, my experience/growth, languages tech stacks and codebases have connived to make Jetbrains superior discoverability moot (not using Java!), I found out other IDEs are good enough for me.
1. Some years back, they decided on an IDE-as-a-service path where they were going to brick your IDE the day your subscription lapsed. The fact that they thought this was acceptable and announced it means they cannot be trusted, IMO.
I used to pay Jetbrains annually, out of my own pocket. I continued paying fir a personal license even after my employer bought me another license. Jetbrains then made a stupid, greedy decision[1] (and walked or back within days), but I was done with them and canceled my subscription.
Since then, my experience/growth, languages tech stacks and codebases have connived to make Jetbrains superior discoverability moot (not using Java!), I found out other IDEs are good enough for me.
1. Some years back, they decided on an IDE-as-a-service path where they were going to brick your IDE the day your subscription lapsed. The fact that they thought this was acceptable and announced it means they cannot be trusted, IMO.
Some years back, they decided on an IDE-as-a-service path where they were going to brick your IDE the day your subscription lapsed.
No they didn't. This is a total mischaracterisation of how JB's subscription works.
No they didn't. This is a total mischaracterisation of how JB's subscription works.
I clearly mentioned they walked back the decision within days of the initial announcement.
I don't understand how you could possibly have read my comment as describing their current licensing practices, with the tenses I was using.
You can go read up on the disastrous announcement and the followup at https://blog.jetbrains.com/blog/2015/09/03/introducing-jetbr...
I don't understand how you could possibly have read my comment as describing their current licensing practices, with the tenses I was using.
You can go read up on the disastrous announcement and the followup at https://blog.jetbrains.com/blog/2015/09/03/introducing-jetbr...
Fair enough - I guess we will have to agree to disagree on whether that warrants never trusting them again.
I think they did, but then walked back and announced that you will just fallback to the previous version of whatever IDE you were subscribed to if you cancel the subscription. I think the situation caused quite a backlash when they announced the original plans.
> I found out other IDEs are good enough for me.
IDEs as in plural, like several IDEs? What IDEs are you using now? I'm yet to find something that is as good for several languages as Idea Ultimate? Yes, for some languages Vscode plugin is superior, but overall as a polyglot I find Idea experience the best all things considered.
IDEs as in plural, like several IDEs? What IDEs are you using now? I'm yet to find something that is as good for several languages as Idea Ultimate? Yes, for some languages Vscode plugin is superior, but overall as a polyglot I find Idea experience the best all things considered.
> 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.
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.
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.
It's worth noting that JetBrains has a long history of successfully competing against free IDEs, which were normally always more popular than IntelliJ. First there was NetBeans (bought and open sourced by Sun very early), then there was Eclipse (developed and open sourced by IBM), now there is VSCode. Heck there are probably others I don't know about. So, this is nothing new for them.
Usually what happens is that after enough years have passed, the company funding the free IDE starts to wonder why exactly they're spending so much money to give away the results. The original passion-project founders have moved on, leaving behind maintenance devs who aren't motivated to defend it. Eventually it gets stripped to a handful of devs and donated to Apache. In the meantime IntelliJ continues to develop new features.
The question VSCode users might wonder about is what's Microsoft's strategy here? They have plenty of money, but then again so did Sun/Oracle and IBM. Is there a long term commercial plan to let the VSCode team justify themselves.
Usually what happens is that after enough years have passed, the company funding the free IDE starts to wonder why exactly they're spending so much money to give away the results. The original passion-project founders have moved on, leaving behind maintenance devs who aren't motivated to defend it. Eventually it gets stripped to a handful of devs and donated to Apache. In the meantime IntelliJ continues to develop new features.
The question VSCode users might wonder about is what's Microsoft's strategy here? They have plenty of money, but then again so did Sun/Oracle and IBM. Is there a long term commercial plan to let the VSCode team justify themselves.
> The question VSCode users might wonder about is what's Microsoft's strategy here? They have plenty of money, but then again so did Sun/Oracle and IBM. Is there a long term commercial plan to let the VSCode team justify themselves.
Exactly, especially since VSCode is also an "open-core" product, just like JetBrain's products (the community versions are open-source).
The difference is that the other parts are still free, as in beer. But this is precisely what makes the offer weird to me and makes me think there's a shady angle being played.
Exactly, especially since VSCode is also an "open-core" product, just like JetBrain's products (the community versions are open-source).
The difference is that the other parts are still free, as in beer. But this is precisely what makes the offer weird to me and makes me think there's a shady angle being played.
Well, I doubt it's shady. Seems more likely they don't know what to charge for it and are incentivized to create user growth rather than revenue growth.
Not really in the case of Jetbrains vs VScode, because if the fateful day came, it would simply be an inconvenience to have to set up the alternative, not the end of the world.
As long as you can build the project with standard tools (e.g. npm for javascript, maven/gradle for Java etc.) you can survive your favorite IDE disappearing suddenly from one day to the other. It is more o less a requirement if you use CI/CD and a non issue anyway since any decent IDE can generate and synchronize a project using an external tools as a source of truth.
Most of intellij is open-source.
> This just reinforces my feeling that a major driver behind VSCode's popularity is that people just don't know better
I am very happy that VSCode is mostly just editor.
I am very happy that VSCode is mostly just editor.
I’m pretty sure the verification is going to just be the normal jetbrains license verification service stuff. Since if anything I use has been shut down or offline for about that long I notice it phoning home to check my account license.
JetBrains/IDEA/IntelliJ/whatever is the name now has quite a good plugin support.
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
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
Just to add:
Fleet seems like a new lighter architecture. Which is fantastic. My hope is they can actually bring the tools from their other platforms into this.
Otherwise... they might as well just sell a IDE plugin architecture for VSCode.
Fleet seems like a new lighter architecture. Which is fantastic. My hope is they can actually bring the tools from their other platforms into this.
Otherwise... they might as well just sell a IDE plugin architecture for VSCode.
"New thing not perfect!"
Sounds like license verification.
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 :)
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 :)
While annoying, all intellij EAPs (early access previews) are very cpu intensive, as they run in debug mode by default to create diagnostics and crash reports. Kinda similar like if you would keep the debugger open in your browser. Not sure if you can disable it, but thats the main reason why I stopped using EAPs for work.
But the ram is typical intellij, they take what they can get from the OS :)
But the ram is typical intellij, they take what they can get from the OS :)
> But the ram is typical intellij, they take what they can get from the OS :)
Aha, thanks! I was wondering about that (using CLion 2021.3 with Rust plugin with currently a tiny test project open, currently using 2.3 GiB RAM, puah)... .
Aha, thanks! I was wondering about that (using CLion 2021.3 with Rust plugin with currently a tiny test project open, currently using 2.3 GiB RAM, puah)... .
Well, they cache many things to make code analysis fast, so they are one of the few softwares that do make good use of memory. Some older version had very low heap size set and that can cause slow downs, so 2+ GB is recommended at least in my experience.
i give intellij about 10GB to play with. i don't care. im not using it fot anything else. cache away. will happily trade ram for speed
> they take what they can get from the OS :
It's the opposite, they run in JVM so there's an upper bound at around -Xmx ("around" because you still have stack allocated and JNI allocated, but heap is usually the biggest pool of memory by a large margin)
on the flip side it also has a lower bound at -Xms
Personally I have mine running with 16/32G heap. It's my work computer not like I need the 64G ram for gaming :)
It's the opposite, they run in JVM so there's an upper bound at around -Xmx ("around" because you still have stack allocated and JNI allocated, but heap is usually the biggest pool of memory by a large margin)
on the flip side it also has a lower bound at -Xms
Personally I have mine running with 16/32G heap. It's my work computer not like I need the 64G ram for gaming :)
any source on that claim? I.e. that eap are cpu intensive?
I don't have a source other than that I develop plugins for IntelliJ professionally, but it's definitely true that performance is generally not a focus earlier in EAP cycles. I think they mention it when you download an EAP release.
I can't find a source to my claim. Just now downloaded webstorm 2022.2.3 stable and webstorm 2022.3 EAP to compare, but they seem to behave similar in cpu. Every now and then in the EAP in the activity monitor a "diagnostics dumper" pops up, but only for a brief moment. Maybe they improved it a lot. I remember complaining about EAP performance a long time ago and remembered an answer to expect a few more cpu usage from an EAP (the diff was not as stark as 100% though, it was more like 20% EAP vs 5% stable).
I mean please don't judge the CPU profile of an EAP to the final product.
I mean please don't judge the CPU profile of an EAP to the final product.
I haven’t experienced this with Fleet after using it some months.
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.
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.
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 guess the OS matters.
I was experiencing similar performance problems on linux. Multiple cores pegged and multiple gb used while idling.
Linux here, opened a folder with less than 3k loc in all files combined. It is currently in the background (smart mode is disabled), FF in the foreground. KDE system monitor is reporting 3%-5% CPU usage and 946,272K of memory usage. Also, if I move the window, my mouse becomes sluggish for about a second afterwards.
By comparison, the exact same folder open in Sublime is using 789,236K of memory (most of which is likely cached from the indexer + LSP plugin which has accumulated over the past few days), and no CPU usage.
Obviously this is an early preview, so it's not a fair comparison at all. I'm really excited for this though, as it's certainly very promising right now.
By comparison, the exact same folder open in Sublime is using 789,236K of memory (most of which is likely cached from the indexer + LSP plugin which has accumulated over the past few days), and no CPU usage.
Obviously this is an early preview, so it's not a fair comparison at all. I'm really excited for this though, as it's certainly very promising right now.
Did you get the Apple Silicon version? The default download for MacOS was Intel for me, had to click the drop down.
I think, correct me if I am wrong, Fleet is written in Kotlin, hence running on top of JVM. ( I am assuming Kotlin Native not being used yet )
While I dont think VSCode is fast and lean when compared to Sublime or other Native Editor. It is well optimised.
I do wonder if Fleet could catch up or even exceed VSC in the performance / resources usage department.
While I dont think VSCode is fast and lean when compared to Sublime or other Native Editor. It is well optimised.
I do wonder if Fleet could catch up or even exceed VSC in the performance / resources usage department.
Fleet, like the other JetBrains IDEs is indeed running on the JVM.
It also has some components in Rust and a special GUI framework.
There is a great series of blog posts about its architecture and design here with a lot of details:
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
It also has some components in Rust and a special GUI framework.
There is a great series of blog posts about its architecture and design here with a lot of details:
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
It totally could, the JVM is really fast. JS interpreters are fast too these days. So I don't expect much difference between the two.
One department where the JVM may win is latency (the new GCs are incredibly fast so no impact there) for typing to display.
Other than that I don't expect much difference.
One department where the JVM may win is latency (the new GCs are incredibly fast so no impact there) for typing to display.
Other than that I don't expect much difference.
I probably have that many LoC between all the open files in VScode on an M1 and also love the performance. Only issue I've had so far is the Terraform Language Server running 18 threads at all times and grabbing too much CPU once or twice a month.
Yeah, I had the same issue with the terraform plugins, I honestly had to delete them. So far I haven't found an alternative but honestly I don't write that much terraform anymore.
Well, I think NexGen Cloud IDE crowd gonna love it. From your review I take it as it is the next hot thing.
It still a beta, so I think it can be acceptable BUT it is not tiny.
What I like about VSCode is that is slick and lean without plugins, and with remote support it is still "light"... And I was a huge Emacs, Emacs-org fan, so if I use VSCode because it gets the work done at the end of the day (TM)
What I like about VSCode is that is slick and lean without plugins, and with remote support it is still "light"... And I was a huge Emacs, Emacs-org fan, so if I use VSCode because it gets the work done at the end of the day (TM)
I opened a project with about 230k lines of Java code on my Intel Mac, it's idling around 800MB of real memory. Though I don't have Smart Mode on
Sounds like there is initial setup going on in the background. I highly doubt it will keep the CPU at 100% at all times unless there is a severe bug.
JVM heap size is not Fleet's fault. You should be able to manually set it like Intellij.
A craftsman's work is always limited by the choice of his tools.
They could have built it in something different that doesn't require a huge footprint. It is inherently their fault since they chose the tools, but I definitely understand the pros they gain from it.
They could have built it in something different that doesn't require a huge footprint. It is inherently their fault since they chose the tools, but I definitely understand the pros they gain from it.
[deleted]
> Fleet is our new distributed polyglot editor and IDE.
Ok, polygot makes sense, it supports more than just one language. But what does distributed mean in this context? You run the editor across many machines? What does that mean? Coming from a backend perspective, it quite doesn't make much sense. Thinking about it from a client-side perspective, I'm guessing they mean the architecture is decoupled, meaning basically plugins/extensions but with a fancier word?
Judging by the "Features Matrix" (https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vTWt9RlJ...), sad to see not a single non C-like language is being considered.
Ok, polygot makes sense, it supports more than just one language. But what does distributed mean in this context? You run the editor across many machines? What does that mean? Coming from a backend perspective, it quite doesn't make much sense. Thinking about it from a client-side perspective, I'm guessing they mean the architecture is decoupled, meaning basically plugins/extensions but with a fancier word?
Judging by the "Features Matrix" (https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vTWt9RlJ...), sad to see not a single non C-like language is being considered.
>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 on remote servers) can do full codebase indexing. As a bonus, the code index database can be shared by many frontends.
Code indexing for huge repos (e.g. 1 million LOC) takes a very long time and is one of the complaints of classical IDEA IDE performance being sluggish.
Take the "code indexing" example and extend it to other "heavy" backend batch processes like linting, testing, etc. The backend can also be in the cloud.
As a footnote, Fleet is also a competitive response to MS VSCode by having collaborative features. But my comment mostly answers the "distributed" aspect.
Related articles that also have the client+server diagram:
https://www.infoworld.com/article/3664112/jetbrains-fleet-th...
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
>frontend + backend is not distributed, but it definitely is client/server architecture
EDIT to clarify: the "distributed" is describing "distributed application" of client+server ... like 1st sentence of wikipedia : https://en.wikipedia.org/wiki/Client%E2%80%93server_model
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 on remote servers) can do full codebase indexing. As a bonus, the code index database can be shared by many frontends.
Code indexing for huge repos (e.g. 1 million LOC) takes a very long time and is one of the complaints of classical IDEA IDE performance being sluggish.
Take the "code indexing" example and extend it to other "heavy" backend batch processes like linting, testing, etc. The backend can also be in the cloud.
As a footnote, Fleet is also a competitive response to MS VSCode by having collaborative features. But my comment mostly answers the "distributed" aspect.
Related articles that also have the client+server diagram:
https://www.infoworld.com/article/3664112/jetbrains-fleet-th...
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
>frontend + backend is not distributed, but it definitely is client/server architecture
EDIT to clarify: the "distributed" is describing "distributed application" of client+server ... like 1st sentence of wikipedia : https://en.wikipedia.org/wiki/Client%E2%80%93server_model
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
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?
Going beyond the traditional client<>server/thin client architecture with at least 2 servers is what I'd consider distributed.
> with at least 2 servers is what I'd consider distributed.
There are several meanings of "distributed" :
(1) multiple servers coordination like Google's MapReduce BigTable, Cassandra, Hadoop, etc
(2) describing a split client+server architecture that may have just 1 server. This usage of "distributed architecture" in discussions was more common in 1980s/1990s with the rise of client/server computing. Visual Basic CRUD, PowerBuilder, SAP R/3, etc.
In the Jetbrains article, if you do Ctrl+F search for all occurrences of "distributed", it is clear they're talking about meaning (2): https://blog.jetbrains.com/fleet/2022/06/fleet-below-deck-pa...
To answer your previous question: >I'm guessing they mean the architecture is decoupled, [...] but with a fancier word?
It's not a fancier word. Jetbrains is re-using an existing description of "distributed==client/server" that's been around for decades. It's just that "distributed computing" has been recently dominated by the examples of meaning (1) above.
There are several meanings of "distributed" :
(1) multiple servers coordination like Google's MapReduce BigTable, Cassandra, Hadoop, etc
(2) describing a split client+server architecture that may have just 1 server. This usage of "distributed architecture" in discussions was more common in 1980s/1990s with the rise of client/server computing. Visual Basic CRUD, PowerBuilder, SAP R/3, etc.
In the Jetbrains article, if you do Ctrl+F search for all occurrences of "distributed", it is clear they're talking about meaning (2): https://blog.jetbrains.com/fleet/2022/06/fleet-below-deck-pa...
To answer your previous question: >I'm guessing they mean the architecture is decoupled, [...] but with a fancier word?
It's not a fancier word. Jetbrains is re-using an existing description of "distributed==client/server" that's been around for decades. It's just that "distributed computing" has been recently dominated by the examples of meaning (1) above.
Distributed means you can run the editor UI and the actual backend on separate machines. One long-term goal of such deployments is developers just having a thin chromebook with the UI and the actual code being on a corporate server, like terminals and mainframes in ye olde days.
I believe this is a reaction to VS Code, which has supported this functionality for a while already.
I believe this is a reaction to VS Code, which has supported this functionality for a while already.
Another big use case is running the "backend" inside a VM or container that has a well-defined set of dependencies installed while the host OS can be updated and managed by the user.
But conventionally the word "distributed” is for apps running on multiple servers. Your definition makes every web app "distributed". And I feel like most of HN would disagree with calling Spotify Web a "distributed app"
It's not "my" definition, it used to be a very common definition.
e.g., quassel, an irc bouncer + client, used the same term since 2007.
e.g., quassel, an irc bouncer + client, used the same term since 2007.
So... every X-Window application is "distributed"?
I'd not have described them that way.
I'd not have described them that way.
Yes, that's what X-Windows was created for. The original goal was for terminals connected to large servers, where you'd have the application distributed with the UI on the terminal and the backend running on the remote server.
As you noted w/ VSCode (and others) this dev style can be done quite easily for free, what advantages does a vendor lock-in provide?
You'll get actually useful suggestions and refactoring abilities. VS Code is today still just a editor with syntax highlighting and very basic suggestions. Even with language servers it can't come close to what JetBrains does.
JetBrains first major product was an addon to improve the suggestion abilities of Visual Studio, and VS Code is a downgrade even compared to normal VS
JetBrains first major product was an addon to improve the suggestion abilities of Visual Studio, and VS Code is a downgrade even compared to normal VS
Interesting... I will have to check it out properly at some point then, thanks for the insight.
> But what does distributed mean in this context? You run the editor across many machines? What does that mean?
It means that the editor is split into two (or more) parts: a UI that runs locally on the machine you're sitting in front of, and a server that can run anywhere that does I/O, analysis, debugging, etc. It's useful e.g. if you're running Windows but target Linux (run the server-side in WSL), for dev containers (run the server-side inside a container with the toolchain for your project), or to develop in/for the cloud.
It means that the editor is split into two (or more) parts: a UI that runs locally on the machine you're sitting in front of, and a server that can run anywhere that does I/O, analysis, debugging, etc. It's useful e.g. if you're running Windows but target Linux (run the server-side in WSL), for dev containers (run the server-side inside a container with the toolchain for your project), or to develop in/for the cloud.
> But what does distributed mean in this context? You run the editor across many machines? What does that mean?
Yes:
> distributed architecture. For more details check out the Fleet product page [link].
> [Fleet product page:] Distributed for flexibility
> Fleet’s architecture is designed to support a range of configurations and workflows. You can simply run Fleet just on your machine, or move some of the processes elsewhere – for example by locating the code processing in the cloud.
Yes:
> distributed architecture. For more details check out the Fleet product page [link].
> [Fleet product page:] Distributed for flexibility
> Fleet’s architecture is designed to support a range of configurations and workflows. You can simply run Fleet just on your machine, or move some of the processes elsewhere – for example by locating the code processing in the cloud.
Ok, so I could kind of understand the use case of running the UI on one machine and the backend for the UI on another machine. Lots of complexity for small amount of gain, but somewhat makes sense.
But then they say "distributed" so that would mean many backend machines, not just one. What on earth is the backend doing where one instance is not enough for one client? How could one client UI possibly need more than one backing instance? Sounds horribly inefficient.
But then they say "distributed" so that would mean many backend machines, not just one. What on earth is the backend doing where one instance is not enough for one client? How could one client UI possibly need more than one backing instance? Sounds horribly inefficient.
> 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.
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" unless there is multiple servers involved, at least how the terminology have been understood until today, if it changed suddenly.
Usually when it comes to these kind of architectures, you'd refer to them as "thin clients", and the architecture has been around since mainframes if not longer.
> ‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.
A client<>server architecture is generally not considered "distributed" unless there is multiple servers involved, at least how the terminology have been understood until today, if it changed suddenly.
Usually when it comes to these kind of architectures, you'd refer to them as "thin clients", and the architecture has been around since mainframes if not longer.
> A "huge beefy cloud instance" comes with a premium price
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.
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.
Distributed program vs distributed computing. One is anything from MMORPGs to P2P to thin clients. The other is for heavy computations distributed across a network of task processing nodes.
Microservices ... laptop user sets breakpoints on a Django/Python API/web server, a Java financial transaction processor, and a golang outgoing webhook queue server.
[deleted]
Maybe the possibility of compiling and running on different platforms?
VS code can connect to a machine running SSH and you edit locally, but all the code, extensions, etc runs on the other machine. It is not just a matter of copying the files back and forth either, and the experience is super smooth. If you open a port on the remote computer with your program, it will even be forwarded.
I assume this is their answer to that.
I assume this is their answer to that.
Their IDEs support this workflow today
> sad to see not a single non C-like language is being considered
They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list
They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list
> Fleet’s architecture is designed to support a range of configurations and workflows. You can simply run Fleet just on your machine, or move some of the processes elsewhere – for example by locating the code processing in the cloud.
Presumably this is just easy to configure integrations so you can do things like run a build job on your CI/CD platform, push/pull artifacts, deploy applications, etc.
Presumably this is just easy to configure integrations so you can do things like run a build job on your CI/CD platform, push/pull artifacts, deploy applications, etc.
[deleted]
apparently no Scala as well??!
So I tried it out. I own a CLion license and have been using Jetbrains products since IntelliJ 3.0. It seems ok, but very very VSCode-ish.
I tried it with our Rust codebase and it seemed to be fairly competitive with CLion in terms of analysis. I didn't try any refactorings but I did notice that it doesn't have many of them. It was fairly snappy, felt more responsive than CLion. I was disappointed that even after I switched it to "IntelliJ" keybindings many keybindings still were more like VSCode than IntelliJ. I.e. Ctrl-N was still "open new tab" and not "jump to symbol" (have to do ctrl-shift-alt-N for that.)
Overall, I guess I'm curious where they go with it. I won't be trading in my CLion license, though. I am probably not the target audience; I suspect they're looking to capture customers who work in large corporations where VSCode is getting penetration as a hosted/fleet solution. With the default keybindings I suspect those coming from VSCode will find Fleet very comfortable.
For myself, I continue to give Jetbrains money for their IDEs, because as a company they do great work and give good value. I'm happy to modestly help pay the salaries of their employees. I wish them luck.
I tried it with our Rust codebase and it seemed to be fairly competitive with CLion in terms of analysis. I didn't try any refactorings but I did notice that it doesn't have many of them. It was fairly snappy, felt more responsive than CLion. I was disappointed that even after I switched it to "IntelliJ" keybindings many keybindings still were more like VSCode than IntelliJ. I.e. Ctrl-N was still "open new tab" and not "jump to symbol" (have to do ctrl-shift-alt-N for that.)
Overall, I guess I'm curious where they go with it. I won't be trading in my CLion license, though. I am probably not the target audience; I suspect they're looking to capture customers who work in large corporations where VSCode is getting penetration as a hosted/fleet solution. With the default keybindings I suspect those coming from VSCode will find Fleet very comfortable.
For myself, I continue to give Jetbrains money for their IDEs, because as a company they do great work and give good value. I'm happy to modestly help pay the salaries of their employees. I wish them luck.
that's exactly what i was afraid of. them copying vscode. vscode is getting worse and worse IMo. its not even good at the one thing it initially excelled at - being fast. im not even talking about sluggish ui, just all the bullshit what's new and oh let me connect to ssh before you can enter a single keystroke.
but more importantly, i like that intellij is full featured and has proper windows and dialogs and keybindings. vscode tries to cram everything into a single textbox or ui element and it makes everything worse.
give me intellij but let me build a language backend in whatever language i want instead of forcing java on me. and also so that i can run it at my work which doesn't like code on laptops
but more importantly, i like that intellij is full featured and has proper windows and dialogs and keybindings. vscode tries to cram everything into a single textbox or ui element and it makes everything worse.
give me intellij but let me build a language backend in whatever language i want instead of forcing java on me. and also so that i can run it at my work which doesn't like code on laptops
Some neat info on the performance side of things, Fleet is using Skija[1] and Compose[2] as a rendering engine and UI framework. Skija is a java wrapper for Skia and still does not support the full API. Compose is still relatively new and has not had nearly the amount of man hours devoted to it as Swing. This is just a technical preview, I'm sure there will be plenty of optimizations to come. I think it's pretty exciting to see Skija being used for a mainstream project!
[1] https://github.com/HumbleUI/Skija
[2] https://github.com/JetBrains/compose-jb
[1] https://github.com/HumbleUI/Skija
[2] https://github.com/JetBrains/compose-jb
Fleet does not use Compose, but it does use Skiko[1], which also provides binding for Skia[2] (the native graphics library also used by Chrome & Flutter).
The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.
[1] https://github.com/JetBrains/skiko
[2] https://skia.org/
The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.
[1] https://github.com/JetBrains/skiko
[2] https://skia.org/
JetBrains Compose UI is using Skiko, not Skija: https://github.com/JetBrains/skiko
Oh my mistake, thanks for the info!
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.
And a better way to handle certs for it, and all the IDEs, behind a corporate MITM SSL proxy would really improve my day.
Yes, absolutely!
While I believe there are JB employees in this thread, your wish is more likely to be fulfilled if it is a formal ticket: https://youtrack.jetbrains.com/issues/TBX
Tried the private beta for a while, and although it was rough on the edges, I really enjoyed the ability to "enable" the smart mode - if I needed to do a quick edit in a file, without having to load all the IDE magic, I had an editor that was quick to start, and if I needed all the bits and bobs, I just clicked a button and off we went.
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
JetBrains trying to fight back Visual Studio Code taking over their market share.
The main difference between VS Code and the various JetBrains IDEs is that for VS Code, you have to find and install the relevant plugins for your use case yourself, whereas the various JetBrains IDEs tend to work out of the box (while still supporting plugins). That's usually the difference between most free/open source solutions and commercial software: you can do mostly the same with the open source alternative, you just have to invest more effort. As far as I'm concerned, as long as my company is paying the JetBrains IDE license, why should I go to extra lengths to set up VS Code?
That is why one has the IT department configuring development images.
I remeber there was a blog post from JetBrains where they complain about VSCode taking over InteliJ market, by indirectly asserting they don't understand why VSCode adoption was rising.
Surprise surprise, a couple of months later Fleet was announced.
I remeber there was a blog post from JetBrains where they complain about VSCode taking over InteliJ market, by indirectly asserting they don't understand why VSCode adoption was rising.
Surprise surprise, a couple of months later Fleet was announced.
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 testbed for new UI for JetBrains IDEs
- while trying to both serve the Language Server crowd and keep JetBrain's vastly superior language tools
- while diluting JetBrains' offer of development tools
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 testbed for new UI for JetBrains IDEs
- while trying to both serve the Language Server crowd and keep JetBrain's vastly superior language tools
- while diluting JetBrains' offer of development tools
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's rich plugin ecosystem, I have a Magit implementation that is almost as good as Emacs Magit, the same with VSpaceCode to get Spacemacs/Doom-like spacebar-driven workflows.
My JetBrains All Products Pack is up for renewal later this month, but I am seriously considering to let it lapse...
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's rich plugin ecosystem, I have a Magit implementation that is almost as good as Emacs Magit, the same with VSpaceCode to get Spacemacs/Doom-like spacebar-driven workflows.
My JetBrains All Products Pack is up for renewal later this month, but I am seriously considering to let it lapse...
> And I found that the Rust/Python is at least as good as in CLion/PyCharm
I think Rust support is comparable (probably because they both use rust-analyzer). I've found the opposite for Python. PyCharm is WAY smarter than VS Code.
I think Rust support is comparable (probably because they both use rust-analyzer). I've found the opposite for Python. PyCharm is WAY smarter than VS Code.
same, I've used both -- gave vscode a good year of trying to do python with it and Pycharm is doing more to understand my code. I'm not even using the integrated database junk either and it still does more.
That said there is one part where I still have to turn to VSCode and that's when I want live breakpoints inside of a Tilt powered Kubernetes pod. I like the way that those settings are persisted so that other dev's can also use the debug functionality with literally one click. If pycharm just made remote debugging easy I'd never have to open VSCode for python development (but I'd probably still open it for something else like a quick editor of a file -- it's like my new vim). VSCode shines for supporting odd-ball languages and libraries sooner than JetBrains - and opens relatively quickly, sublime is much faster and I still use it for large files -- I just wish it was a little less involved to extend like VSCode.
That said there is one part where I still have to turn to VSCode and that's when I want live breakpoints inside of a Tilt powered Kubernetes pod. I like the way that those settings are persisted so that other dev's can also use the debug functionality with literally one click. If pycharm just made remote debugging easy I'd never have to open VSCode for python development (but I'd probably still open it for something else like a quick editor of a file -- it's like my new vim). VSCode shines for supporting odd-ball languages and libraries sooner than JetBrains - and opens relatively quickly, sublime is much faster and I still use it for large files -- I just wish it was a little less involved to extend like VSCode.
I don’t think CLion uses rust-analyzer. IIRC it uses their own thing which was developed by the same person who later made rust-analyzer.
Edit: more info:
https://plugins.jetbrains.com/plugin/8182-rust/docs/rust-faq...
Edit: more info:
https://plugins.jetbrains.com/plugin/8182-rust/docs/rust-faq...
> Or maybe VS Code is just really good?
It's okay. And its ecosystem is also anywhere from okay to abysmal.
For languages (like Rust) that never really had any tools to begin with it seems like an amazing IDE/editor. In comparison to what IDEA offers for more established languages (anything from language support to framework support) it's ... just okay :)
It's okay. And its ecosystem is also anywhere from okay to abysmal.
For languages (like Rust) that never really had any tools to begin with it seems like an amazing IDE/editor. In comparison to what IDEA offers for more established languages (anything from language support to framework support) it's ... just okay :)
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.
> Language server allowed languages with abysmal tools to finally have some semblance of an IDE
Oh yeah, this is absolutely true. If VS Code is the de facto standard for your language, it's probably a decent experience. I use it for 6502 assembly.
But I see people talking up VS Code over Visual Studio for C++ or C#, which I find completely baffling.
Oh yeah, this is absolutely true. If VS Code is the de facto standard for your language, it's probably a decent experience. I use it for 6502 assembly.
But I see people talking up VS Code over Visual Studio for C++ or C#, which I find completely baffling.
It's not that they don't know better. I'd say it's all down to marketing and sheer numbers in developer mindshare.
This is from my experience: Just listen to most junior developers. They regurgitate and repeat marketing fluff spoken to them by twitter evangelists or twitch developer streams. I just spent the afternoon listening to it and it was sickening. You can't reason or get through to them. Compromise and nuance just feeds their pompous attitude.
/rant
This is from my experience: Just listen to most junior developers. They regurgitate and repeat marketing fluff spoken to them by twitter evangelists or twitch developer streams. I just spent the afternoon listening to it and it was sickening. You can't reason or get through to them. Compromise and nuance just feeds their pompous attitude.
/rant
Remote (Container|WSL|SSH) extension is a game changer. IntelliJ Remote Development is similar feature but VSCode is superior.
> That is why one has the IT department configuring development images.
Sounds like a nightmare! What do IT know about development to be picking tools?
Sounds like a nightmare! What do IT know about development to be picking tools?
A lot, in many Fortune 500 where software isn't the main product, you get a machine (VM based or real one) customized for your workflows, with the set of software that is white listed for software development in the company.
Anything beyond the standard development image requires opening a request to IT and procurement, with the respective OK from management.
Anything beyond the standard development image requires opening a request to IT and procurement, with the respective OK from management.
Congratulations. You just identified one of the reasons so many dread working at such organisations and why software engineering is becoming assembly line work. Indeed what does an it person know about tooling and why do engineers need to ask for “permission” from managers by opening a “ticket”? Neither an it person nor a manger have a clue about what an engineer needs.
That's the part that cracks me up.
Developers require low-wage workers to prevent developers from doing the wrong thing. It's stupid.
I'm ok with you revoking Bob's admin privileges if Bob keeps installing malware, but don't revoke my ability to install Python because of it.
Developers require low-wage workers to prevent developers from doing the wrong thing. It's stupid.
I'm ok with you revoking Bob's admin privileges if Bob keeps installing malware, but don't revoke my ability to install Python because of it.
Sounds like an even worse nightmare!
Every developer has their own way of being productive which involves different tools & software. Forcing everyone to use one standardized environment sounds horrible.
Every developer has their own way of being productive which involves different tools & software. Forcing everyone to use one standardized environment sounds horrible.
Any developer that is willing to face the legal consequences of installing software that causes business damages, can go ahead and work around the system.
Sounds like there could be a middle path. Instead one fixed dev image, there can be base image + inventory of other software, where free ones anyone can install. Paid ones need approval and/or decision who will pay for it. But IT department is surely not one I imagine that can create decent inventory. So there needs be a catalog for such things which companies can purchase or subscribe.
And when your company starts doing that to developers it is time to dust off your resume and start looking for something better. I get it that these companies have real issues and their managers are multiple times smarter than me but I refuse to be put into a position where I cannot use the tools that I need to be productive.
I get it - have been there. Work with project/team X, and... with tools I know, I'm X productive.
"We need to switch to tool Y".
There's usually a host of reasons I may not want to move to tool Y, but in most cases, it's because I don't want to have to learn yet another tool just to do what I was doing. Why? Cognitive overload... but also for some period of time I'm going to be much less productive. I don't want to be judged on that. you are saying I have to use Y... I'm going to be slower. Every estimate will be 20% more than what it was for the next Z months. I've got 10 years of muscle memory to undo. Is it worth it?
In most cases, really not. BUT... if someone mandated that, AND also acknowledged up front that the delivery expectations will be reduced for some longer period of time... perhaps it's OK.
On the JB topic, IntelliJ was one 'heavy' tool I resisted for a long time. "I'm faster in these other tools - notepad++, vim, netbeans, whatever". I was faster, for many tasks. Adopting something new was slow. I'm generally glad I did it, but I did it mostly on my own projects, and freelancing. Had I been under pressure to deliver at a high pace while having to undo years of habits/tools/processes that got me where I was at that time, it would have been far more difficult to deal with.
"We need to switch to tool Y".
There's usually a host of reasons I may not want to move to tool Y, but in most cases, it's because I don't want to have to learn yet another tool just to do what I was doing. Why? Cognitive overload... but also for some period of time I'm going to be much less productive. I don't want to be judged on that. you are saying I have to use Y... I'm going to be slower. Every estimate will be 20% more than what it was for the next Z months. I've got 10 years of muscle memory to undo. Is it worth it?
In most cases, really not. BUT... if someone mandated that, AND also acknowledged up front that the delivery expectations will be reduced for some longer period of time... perhaps it's OK.
On the JB topic, IntelliJ was one 'heavy' tool I resisted for a long time. "I'm faster in these other tools - notepad++, vim, netbeans, whatever". I was faster, for many tasks. Adopting something new was slow. I'm generally glad I did it, but I did it mostly on my own projects, and freelancing. Had I been under pressure to deliver at a high pace while having to undo years of habits/tools/processes that got me where I was at that time, it would have been far more difficult to deal with.
These companies take liability in software seriously, and if someone installs software that damages their employer business, or their employer customers, they better dust off their CV indeed, including the reason why they got fired.
They take liability seriously? How many outright frauds and data leaks are swept under the table?
If you like to work in extremely low trust companies, you do you. If somebody trusts me to write production code but not to pick text editors, they are morons with red tape wrapped around their eyes.
If you like to work in extremely low trust companies, you do you. If somebody trusts me to write production code but not to pick text editors, they are morons with red tape wrapped around their eyes.
Surprise surprise microsoft is using useful idiots to promote its brand via a free product and in the process threatening smaller business. IntelliJ should sue microsoft in european courts for monopoly. Do you understand the issue here? Or do you imagine all developers should build crud apps while all other tooling should be free?
What monopoly, time to learn law?
The same kind of monopoly microsoft was accused it was when providing free media player and free browser apps. This is just the same type of market abuse except its leveraging people’s free work and not pre installing it inside its own os’. Perhaps you should learn law indeed.
Giving something for free is not monopoly (without preinstallation).
You can say other things about this strategy, but you're misusing the word.
The price of acquisition is 0$ but costs telemetry and branding. So microsoft is charging you for this just not money. Even if that wouldnt be the case microsoft did distribute ie and the media player for free, so there is precedence. It may not be distributed part of the os but it is a product set at a price that severely undercuts competition. Worse even the product is developed using free labour yet microsoft benefits in brand recognition. Google does it and in the process it killed plenty of startups or small businesses and got grief for it yet microsoft can get away with it.
VSCode is open source and you are free to alter it (MIT license), removing those parts that you say Microsoft is using to "charge" you. Or just use vscodium.
I'll just use intellij products to support engineering companies.
I think "projector" was a beta/trial thing before fleet. And I could never get it to work. Or... I think I got it to work once, but it was decidedly a not-great experience.
I also find JetBrains completions to be smarter than VS Code's plugins (especially for python).
In my experience it’s the opposite. In VSCode, when you open, say, a .py file for the first time, you automatically get prompted to install the Python plugin. With the JetBrains suite you would have to manually install PyCharm.
IntelliJ definitely prompts me every time I open a new file extension that the plugin isn’t installed for.
Because you do it only once and can use it in any other company you work. It's a highly portable tool for free. What are the chances that your next employer will pay for a JB license?
Honestly, it is basically about a 100% chance that the next employer will pay for JB. I couldn’t imagine an employer refusing to pay $120/yr for a JB license for an employee they are already paying $180,000/yr.
It's more than $120/year for an employee. https://www.jetbrains.com/idea/buy/#commercial?billing=yearl...
Reduced pricing in year 2 and 3, but up front it's $600/year.
And... while someone's base pay may be a lot, these sorts of 'extras' might come from a different budget. And when there are a dozen services you're paying $20-$50/month/seat for, I know some managers start to scrutinize things a bit more. "Can't you just use the free version like other people do?"
Reduced pricing in year 2 and 3, but up front it's $600/year.
And... while someone's base pay may be a lot, these sorts of 'extras' might come from a different budget. And when there are a dozen services you're paying $20-$50/month/seat for, I know some managers start to scrutinize things a bit more. "Can't you just use the free version like other people do?"
The pricing for All Products Pack was initially much less( $249.00 in 2016), and since then, it became one of the minor bills that you just pay because it is so little.
I really like the licensing model they employ.
I really like the licensing model they employ.
It's now $289 from $249 for first year - for individual purchases. The corporate/business pricing - seat counts for a company vs tied to your individual name - is the (much?) higher price.
My employee does not pay for JB license, I'm doing that myself and my colleagues are either using community editions or vscode (or cracked ones). He does not pay me $180,000/yr either, LoL, more like $30,000/yr.
Also I think that it's more like $600/yr for companies.
Also I think that it's more like $600/yr for companies.
I pay for my own RubyMine and Copilot license. At the end of the day I just want to get the job done as efficient as possible and be done with it so I can do other hobbies or code side projects. If my co-workers want to work harder, that's on them
You're wrongly assuming US salaries. Not everybody gets 180k/year on the other part of the globe. And there are junior/med. devs in US too. Plus the subscription price is 600/year per person if you buy it as an organisation - https://www.jetbrains.com/store/#commercial. If it's a small company, chances are high that they may prefer a cheaper option.
> Because you do it only once
Not really though. Extensions are frequently deprecated or outdated, need to switch to new alternative, don't play nice together, etc.
Anyway, there's no need to advocate for vscode, it's not an underdog. I imagine everyone here has already formed their opinion and tried JB IDEs, vscode, and other tools, and probably make use of all of them somewhere in their workflow.
Not really though. Extensions are frequently deprecated or outdated, need to switch to new alternative, don't play nice together, etc.
Anyway, there's no need to advocate for vscode, it's not an underdog. I imagine everyone here has already formed their opinion and tried JB IDEs, vscode, and other tools, and probably make use of all of them somewhere in their workflow.
> Extensions are frequently deprecated or outdated
Unfortunately my experience differs from yours in this area. It all of course depends on the languages you use, what you do, on which side of adoption curve you are, etc.
I work with .Net plus a plenty of web stuff, I'm rather conservative about plugins. And for me everything is quite stable in my area so that the plugins configured 5 years ago still work. Adoption of language server protocol in different languages and frameworks, adoption of .editorconfig helped a lot to stabilize everything.
Unfortunately my experience differs from yours in this area. It all of course depends on the languages you use, what you do, on which side of adoption curve you are, etc.
I work with .Net plus a plenty of web stuff, I'm rather conservative about plugins. And for me everything is quite stable in my area so that the plugins configured 5 years ago still work. Adoption of language server protocol in different languages and frameworks, adoption of .editorconfig helped a lot to stabilize everything.
Usually the images are done per project.
VSCode Web as modern version of X Windows based IDEs is great, as yet another Electron app not really.
VSCode Web as modern version of X Windows based IDEs is great, as yet another Electron app not really.
Basically microsoft is trying to crush ide makers. To achieve that its leveraging unpaid work. I dont know how someone can celebrate tools such as VSCode that despite being free are clearly products made by a corporation so large that it can crush legitimate businesses. Its not jetbrains trying to fight back vscode. Its jetbrains fighting back microsoft by providing not just good tools but also pay to those that want to build such good tools.
They could still fight back if they come up with the "community edition" similar to PyCharm
I just downloaded the Fleet beta from the App toolbox. First impressions is that it is very clean.
This is essentially Vscode but with Jetbrains language and refactoring engine.
Quick thoughts:
- It needs a bit more autocomplete e.g automatically close tags for React components
- GUI run configuration - they have made it so it uses a JSON file like Vscode to configure, GUI is quicker and easier (can still click run on gutter for package.json scripts so not that bad)
- Sometimes you want to use Vscode to make some quick changes/play around instead of firing up an IDE. Fleet replaces that for me
- Part of me think that Jetbrains should have created paid extensions for Vscode much like Resharper for Visual Studio
This is essentially Vscode but with Jetbrains language and refactoring engine.
Quick thoughts:
- It needs a bit more autocomplete e.g automatically close tags for React components
- GUI run configuration - they have made it so it uses a JSON file like Vscode to configure, GUI is quicker and easier (can still click run on gutter for package.json scripts so not that bad)
- Sometimes you want to use Vscode to make some quick changes/play around instead of firing up an IDE. Fleet replaces that for me
- Part of me think that Jetbrains should have created paid extensions for Vscode much like Resharper for Visual Studio
> - Part of me think that Jetbrains should have created paid extensions for Vscode much like Resharper for Visual Studio
IIRC, JetBrains considers LSP to be too limiting for refactoring and code-insight capabilities that they want to provide (I think they said that when there was discussion about language server for Kotlin). So it's possible that such extension wouldn't be on par with a "real" JetBrains IDE.
IIRC, JetBrains considers LSP to be too limiting for refactoring and code-insight capabilities that they want to provide (I think they said that when there was discussion about language server for Kotlin). So it's possible that such extension wouldn't be on par with a "real" JetBrains IDE.
> - GUI run configuration - they have made it so it uses a JSON file like Vscode to configure, GUI is quicker and easier (can still click run on gutter for package.json scripts so not that bad)
And better auto-complete for that. I tried to add my golang project, but had no clue what it wants from me for goExecPath or buildTargets. Why not show the help inside the editor? I had to google and look around (goExecPath is the actual link to the bin, not GOPATH or something) and buildTargets means files (main.go). The naming feels weird.
And better auto-complete for that. I tried to add my golang project, but had no clue what it wants from me for goExecPath or buildTargets. Why not show the help inside the editor? I had to google and look around (goExecPath is the actual link to the bin, not GOPATH or something) and buildTargets means files (main.go). The naming feels weird.
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!
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.
I don’t know what you’re looking at, but time-to-start is a huge factor for me. If I’m using a program as a text editor (as opposed to an IDE), I want to be able to open a file, edit it, and then close it. When I heard JetBrains was working on a lightweight text editor, I was hoping for something I could use in this way, but Fleet takes 5 seconds to launch and auto-closes after closing all files. So I’m a little disappointed.
Fleet is not a text editor, it's a full fledged web-based IDE. I don't know what your workflow is, but my IDE generally stays open all day long and so startup is irrelevant. And if that web UI was to actually run remotely on some cloud server (gasp), the I assume that fresh instances of it could at least be pre-pooled for an even quicker "startup".
If all I needed was a quick text editor, obviously I would stick with Notepad++ or Sublime or Kate or... Nothing wrong with that, and actually much saner than the new web-based stuff IMHO.
If all I needed was a quick text editor, obviously I would stick with Notepad++ or Sublime or Kate or... Nothing wrong with that, and actually much saner than the new web-based stuff IMHO.
Type text on Fleet, move your mouse around and notice how much CPU it eats
One entire core just for typing text and moving your mouse
If you use a laptop to code, it'll eat your battery in no time
If you compile programs, it'll slow down your builds
That's why i don't want no java on my computer or any other JIT based BS or slow tech stack like the JVM, wich was made for servers not for latency SENSITIVE programs such as a TEXT editor where i TYPE text and where i need my cores to BUILD or to do STATIC ANALYSIS
One entire core just for typing text and moving your mouse
If you use a laptop to code, it'll eat your battery in no time
If you compile programs, it'll slow down your builds
That's why i don't want no java on my computer or any other JIT based BS or slow tech stack like the JVM, wich was made for servers not for latency SENSITIVE programs such as a TEXT editor where i TYPE text and where i need my cores to BUILD or to do STATIC ANALYSIS
> 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
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...
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...
> lua, lua-jit, quickjs, v8, c#, even java
Huh? None of these are compiled to native code ahead of time. By definition using a JIT compiler is not making things "native", it's just a way of making a very fast interpreter.
Those languages you mention are used in gaming precisely because of their dynamic qualities compensating for the rigidness of the otherwise C++ based engines.
Huh? None of these are compiled to native code ahead of time. By definition using a JIT compiler is not making things "native", it's just a way of making a very fast interpreter.
Those languages you mention are used in gaming precisely because of their dynamic qualities compensating for the rigidness of the otherwise C++ based engines.
you don't understand, they are examples of scripting languages used in game engines
And if OP is concerned with latency, you're not going to beat the JVM's latency sensitive GC's.
Kotlin native is barely usable... it doesn't even have a standard library.
So if they are making progress to a distributed polyglot editor, then this mean that we'd be able to run multiple windows of Fleet working on different projects connecting to the same remote host? Is the connection mechanism basically the same as the Gateway product? If so, I wonder if this bug will ever gets fixed, or if it is a "works as intended" that you cannot run multiple projects on the same host? [1]
However this issue doesn't really apply if you create a VM per workspace either manually or the service that is provided...
[1] https://youtrack.jetbrains.com/issue/GTW-813
However this issue doesn't really apply if you create a VM per workspace either manually or the service that is provided...
[1] https://youtrack.jetbrains.com/issue/GTW-813
Looks and feels nice
Sadly no plugin support yet, and no VIM keybdings, that's a bummer.
I loaded up a JS project, but no support for prettier, LSP or eslint formatting means the Format Code feature doesn't match with the rest of the projects style, so I can't use it.
I'll keep it installed and revisit now and then (similar to Nova). Excited to see what they have planned
Sadly no plugin support yet, and no VIM keybdings, that's a bummer.
I loaded up a JS project, but no support for prettier, LSP or eslint formatting means the Format Code feature doesn't match with the rest of the projects style, so I can't use it.
I'll keep it installed and revisit now and then (similar to Nova). Excited to see what they have planned
It’s so slow to startup. On a laptop with 11th gen i5, 16GB ram and a fairly fast NVMe SSD running Windows 11 and I see ~10s startup time. I really hope it succeeds but for a lightweight editor it’s just too slow to start.
Nice one Jetbrains!!!
Let's see if this competition eventually leads to one of them launching something as snappy as vim but with IDE functionalities. VS Code is close but noticeably slows down as soon as you install many plugins.
With Fleet, newbies now have an alternative editor cum IDE.
Many people that were into programming in my University couldn't afford the kind of machine that would load IntelliJ or Jetbrains IDEs in short time. Rooting for Jetbrains to put up a good fight and recover some market share :)
Let's see if this competition eventually leads to one of them launching something as snappy as vim but with IDE functionalities. VS Code is close but noticeably slows down as soon as you install many plugins.
With Fleet, newbies now have an alternative editor cum IDE.
Many people that were into programming in my University couldn't afford the kind of machine that would load IntelliJ or Jetbrains IDEs in short time. Rooting for Jetbrains to put up a good fight and recover some market share :)
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 new tricks.
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
Would you happen to have an invite for zed.dev ?
I typically have 10-15 VSCode windows open and have been looking for an performant but modern IDE
Yes I have a few - is the email in your profile current?
No Ruby support out of the box - yet there is support for Java (a la IntelliJ), C# (a la Rider), Go (a la GoLand), C (a la CLion), Python (a la PyCharm), Web-anything (a la WebStorm & PhpStorm)...
RubyMine is a great IDE, worth paying for, but this looks like writing on the wall.
RubyMine is a great IDE, worth paying for, but this looks like writing on the wall.
I've been browsing their site for a few minutes now and I'm still lost on what Fleet actually is.
It says it's a new IDE, built from scratch, sure, but isn't IntelliJ already the gold standard for many languages? What problems does creating an entirely new IDE solve?
It says it's a new IDE, built from scratch, sure, but isn't IntelliJ already the gold standard for many languages? What problems does creating an entirely new IDE solve?
It seems to mostly be a competitor to VS Code, i.e. a relatively lightweight editor with support for distributed operation (where the local part is only a UI, and everything else can run remotely).
The linked product page seems to sum it up pretty well:
>We built Fleet to be a fast and lightweight text editor for when you need to quickly browse and edit your code. It starts up in an instant so you can begin working immediately, and it can easily transform into an IDE, with the IntelliJ code-processing engine running separately from the editor itself.
It's splitting the difference between text editor and IDE. It's their answer to people complaining "IntelliJ takes too long to start up" while keeping the IDE features that you lose just using a text editor.
>We built Fleet to be a fast and lightweight text editor for when you need to quickly browse and edit your code. It starts up in an instant so you can begin working immediately, and it can easily transform into an IDE, with the IntelliJ code-processing engine running separately from the editor itself.
It's splitting the difference between text editor and IDE. It's their answer to people complaining "IntelliJ takes too long to start up" while keeping the IDE features that you lose just using a text editor.
I think they’re trying to move to a browser / cloud model, presumably so that they can charge more for less.
I think it's more that there are now many large companies that now deploy VSCode as a shared, distributed editor. When I was at Google they were starting to replace their proprietary "Cider" web-based editor (for Google3) with a "CiderV" which was a modified hosted VSCode. A hosted VSCode instance makes a lot of sense for a company like Google where source-code-on-laptops is generally forbidden and developers are often issued Chromebooks etc. It solves & improves the distributed/remote development problem without requiring organizational changes. And it's much faster and smoother than RDP, etc.
So those are potential customers that JetBrains was/is losing. My brain is almost 20-years-wired for JetBrains products. I would have been much happier to be able to use a remote JetBrains IDE vs a remote VSCode.
There are also people for whom the existing JetBrains IDEs will always feel big slow and bloated. They have a lot of features packed in and come with a lot of lifestyle assumptions. I can see the value in JetBrains rolling out something that feels lighter-weight.
So those are potential customers that JetBrains was/is losing. My brain is almost 20-years-wired for JetBrains products. I would have been much happier to be able to use a remote JetBrains IDE vs a remote VSCode.
There are also people for whom the existing JetBrains IDEs will always feel big slow and bloated. They have a lot of features packed in and come with a lot of lifestyle assumptions. I can see the value in JetBrains rolling out something that feels lighter-weight.
Yeah I'm getting strange adobe-like vibes from creative cloud announcements.
Exactly, when you want to download JetBrian fleet, you'll first have to download their "JetBrain Toolbox", which looks and functions VERY similar to the adobe CC menubar app.
To be fair they ship a large number of IDEs and Toolbox makes managing them a lot easier. I mostly only use IDEA Ultimate and CLion but I use the others occasionally too for certain tasks but don't necessarily have them installed all the time. Toolbox is installed on all my machines so I can simply install what I need when I need it, i.e Datagrip to generate some nice diagrams of some random DB I need to look at, etc.
Well it makes it easier to manage rather than wrangling with multiple stand alone IDEs and versions
They just raised their prices, but their competitor is VS code, which is no cost so they can't run that route.
My gut sense from watching this for a while is that Fleet is a hedge by JetBrains against the risk of technical obsolescence for the IJ platform. VSCode introduced some key architectural changes and new UI which may or may not actually be better than their own products, but, if they are better then JB would be left without a good way to respond.
So. They start Fleet. Different to their existing products in several ways:
1. Doesn't use the Swing UI toolkit. Uses a custom home-grown thing on top of Skia. Still JVM based though.
2. Runs heavy computation in a backend with a network protocol between that and the UI.
3. Has a VSCode style UI.
4. Uses JSON files for configuration.
Meanwhile they are also attempting to respond to the threat with IJ itself. So they have been prototyping a new VSCode style UI in IJ, implemented with Swing. I'm using it at the moment and I have to say it's actually quite nice. I was super skeptical at first. No, really skeptical. I liked the classic IJ UI, nice and dense, lots of features. But the new UI has won me over. It's been freshened up, is still just as efficient, looks nicer too. I think the success of that project (at least for users who want it) calls into question a big part of the Fleet value prop. Also they've been adding remote development/backend support into IJ itself, a lot of that is being built around their pair programming Code-with-me thing which is a fairly sophisticated data sync protocol under the hood.
So JetBrains is setting themselves up here for some serious product management pain. The IJ team are rising to the challenge and it's not at all clear that VSCode will retain its competitive advantages beyond price within a year or two. Swing is not turning out to be the millstone around their neck they apparently feared, and the new UI feels modern and fast even though it's based on this old toolkit. Meanwhile the VSCode architecture in many ways doesn't make sense and is clearly the result of asking "how can we build an IDE within the constraints of a web browser" and not "how do we build a great IDE"? The client/server architecture is quite painful in all kinds of ways compared to threads+locks, devs tend to have good enough machines for code indexing and comprehension, and IntelliJ index builds can be outsourced to the cloud anyway. If IJ starts to really nail the Gateway stuff (see the recent Google Cloud Workstation announcement), what does it leave Fleet for? And how would they resolve these two competing products?
If I were running JetBrains I'd be tempted to keep resources assigned to Fleet relatively limited and wait to see if it takes off organically, whilst simultaneously closing the gaps in IJ with VSCode. This does not just mean the features listed so far but also means getting serious about their "lightedit mode" and plugin API. JetBrains have a cultural problem in which they historically have actively resisted anything resembling code documentation, thinking that code should be self-documenting. Their plugin API docs are still poor and incomplete even after many years partly as a consequence, and although the JVM can run many languages, JB only really support Java and Kotlin for plugin dev. VSCode has taken off partly for the same reason NodeJS and Electron did - it lets web devs apply their skills in a new context. Language server took off because it lets obscure language communities use their own language to make IDE plugins instead of needing to use Java. Add Graal to IntelliJ, make JS a first-class plugin language and explore how to do non-network based integration with other languages. It would help them a lot.
So. They start Fleet. Different to their existing products in several ways:
1. Doesn't use the Swing UI toolkit. Uses a custom home-grown thing on top of Skia. Still JVM based though.
2. Runs heavy computation in a backend with a network protocol between that and the UI.
3. Has a VSCode style UI.
4. Uses JSON files for configuration.
Meanwhile they are also attempting to respond to the threat with IJ itself. So they have been prototyping a new VSCode style UI in IJ, implemented with Swing. I'm using it at the moment and I have to say it's actually quite nice. I was super skeptical at first. No, really skeptical. I liked the classic IJ UI, nice and dense, lots of features. But the new UI has won me over. It's been freshened up, is still just as efficient, looks nicer too. I think the success of that project (at least for users who want it) calls into question a big part of the Fleet value prop. Also they've been adding remote development/backend support into IJ itself, a lot of that is being built around their pair programming Code-with-me thing which is a fairly sophisticated data sync protocol under the hood.
So JetBrains is setting themselves up here for some serious product management pain. The IJ team are rising to the challenge and it's not at all clear that VSCode will retain its competitive advantages beyond price within a year or two. Swing is not turning out to be the millstone around their neck they apparently feared, and the new UI feels modern and fast even though it's based on this old toolkit. Meanwhile the VSCode architecture in many ways doesn't make sense and is clearly the result of asking "how can we build an IDE within the constraints of a web browser" and not "how do we build a great IDE"? The client/server architecture is quite painful in all kinds of ways compared to threads+locks, devs tend to have good enough machines for code indexing and comprehension, and IntelliJ index builds can be outsourced to the cloud anyway. If IJ starts to really nail the Gateway stuff (see the recent Google Cloud Workstation announcement), what does it leave Fleet for? And how would they resolve these two competing products?
If I were running JetBrains I'd be tempted to keep resources assigned to Fleet relatively limited and wait to see if it takes off organically, whilst simultaneously closing the gaps in IJ with VSCode. This does not just mean the features listed so far but also means getting serious about their "lightedit mode" and plugin API. JetBrains have a cultural problem in which they historically have actively resisted anything resembling code documentation, thinking that code should be self-documenting. Their plugin API docs are still poor and incomplete even after many years partly as a consequence, and although the JVM can run many languages, JB only really support Java and Kotlin for plugin dev. VSCode has taken off partly for the same reason NodeJS and Electron did - it lets web devs apply their skills in a new context. Language server took off because it lets obscure language communities use their own language to make IDE plugins instead of needing to use Java. Add Graal to IntelliJ, make JS a first-class plugin language and explore how to do non-network based integration with other languages. It would help them a lot.
From what I’ve seen the difference is that Fleet is much faster.
I'm sure this is great for enterprises but for me, a single developer on a local machine, what benefits does Fleet bring?
Probably not that much if you are not looking forward to a remote development:
- new UI (they couldn't change it in any meaningful way without breaking workflows, but with a new IDE there are no existing workflows)
- single IDE for all languages (it was possible for most of them with IJ ultimate, but for e.g. Python the experience was slightly worse than with PyCharm)
- new UI (they couldn't change it in any meaningful way without breaking workflows, but with a new IDE there are no existing workflows)
- single IDE for all languages (it was possible for most of them with IJ ultimate, but for e.g. Python the experience was slightly worse than with PyCharm)
Yeah, I'm curious of this too, especially compared to just running standard Intellij IDEs
Sorry for the unfamiliarity with JetBrains products. Is this architecture similar to VSCode’s? So the ide has a backend that can run remotely and a frontend client that can run in multiple environments including web? I remember a long time ago pyCharm had the ability to run the interpreter remotely. What are the benefits of pulling more stuff in the backend? Is it in order to be able to run the editor in different environments?
I actually have a use case for this. I work on a big JVM app that needs some serious hardware to run locally. If I want to develop remotely I have to use a Remote Desktop to access a workstation, which is hell.
You can remote debug, but you can’t really remote develop. Intellij is index heavy so you need Intellij and the code to be collocated on a machine, otherwise IntelliJ will overload the network. You can get around this by having two copies of the code and manually transfer any differences to machine running the JVM, but it’s really brittle. Separating the front and back ends will allow me to have JVM, code, and compiler all on one machine, but the editor on another.
You can remote debug, but you can’t really remote develop. Intellij is index heavy so you need Intellij and the code to be collocated on a machine, otherwise IntelliJ will overload the network. You can get around this by having two copies of the code and manually transfer any differences to machine running the JVM, but it’s really brittle. Separating the front and back ends will allow me to have JVM, code, and compiler all on one machine, but the editor on another.
For what this is for: I think the clue is in the name. It targets large groups of developers offloading the language server with thin clients.
At least that's my understanding.
At least that's my understanding.
Anybody having memory issues with it? I opened a large react project and it utilized nearly 2GB of RAM. I am on a linux machine.
That doesn't seem that extreme if it is a large project. JetBrains products are more than just a text editor and tend to be pretty aggressive with RAM usage.
I'm at 3.28GB backend + 1.83GB frontend for a medium-large PHP project as well. Pretty huge memory requirements but I've got plenty so not a big deal, just noticeable compared to alternatives.
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?
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?
Seems pretty slick from what I've played with so far. I don't need anything fancy, I kinda just want something to replace my usecase for VS Code which is a quick-to-open text editor that I don't need a PhD in in order to use effectively. For getting work done I'll continue to use IntelliJ, but sometimes I just need to edit a file or open a directory of files and don't want to open a big IDE for that and have it start indexing things.
Slightly disappointed they've changed the default key mappings? I went to open a file with cmd+shift+o but that immediately launched a symbol search and I have to hit cmd-p to open a file search.
Seems like the git comparison UI is worse. Aside from it stacking up a giant list of diffs, it seems very simple, like Github's PR diff UI. Not doing the nice thing where it shows which lines map to which lines in the changes. I'll chock that up to being a preview.
Slightly disappointed they've changed the default key mappings? I went to open a file with cmd+shift+o but that immediately launched a symbol search and I have to hit cmd-p to open a file search.
Seems like the git comparison UI is worse. Aside from it stacking up a giant list of diffs, it seems very simple, like Github's PR diff UI. Not doing the nice thing where it shows which lines map to which lines in the changes. I'll chock that up to being a preview.
Mostly OT, I know, but... anyone have any clue as to when 'spaces' might actually be a supported task server for their IDE products? They offer 'spaces' as a project tool - keep track of issues/bugs, planning, communication, etc. But you can't connect your IDE to it the same way it can connect to Jira, Github, Trello, Gitlab, Redline, Pivotal and others. It seemed like a short-term oversight at the start, but after... 2 years(?) ... it seems like a vote of no-confidence in their own product. I was excited to use spaces but... some of the most basic stuff I wanted to use wasn't there, and still isn't.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
https://intellij-support.jetbrains.com/hc/en-us/community/po...
I have used JetBrains products for a decade (IntelliJ, Android Studio, WebStorm, PHPStorm). Does this mean that those products are having resources shifted away from them to work on Fleet? I am not a developer who enjoys the 'plugin' mindset and tend to install very few. I prefer Visual Studios over VSCode as well...
I had high hopes that JetBrains would relent on their decision to avoid implementing a Language Server Protocol server. There is a 3rd party implementation out there, but it needs a lot of help. I realize this cuts into their core business... but it'd sure make using Vim to write Kotlin a more pleasant experience.
Never seen language server come even close to what intellij offers.
When I last used them for Rust about two years ago they were racing neck and neck against a language server being refactored to share
a backend with the reference compiler.
I switched to the language server because I felt running the actual compiler will in the long term always work better than writing your own parser. I was on the Jetbrains student discount, so I made a small recurring contribution to the rust language server project.
I think in retrospect that was the correct decision. The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
I switched to the language server because I felt running the actual compiler will in the long term always work better than writing your own parser. I was on the Jetbrains student discount, so I made a small recurring contribution to the rust language server project.
I think in retrospect that was the correct decision. The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
> running the actual compiler will in the long term always work better than writing your own parser.
No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals.
As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
> The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals.
As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
> The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
> No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals.
That's the conventional wisdom. The rust team's theory was that they could make it work. They did.
> As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
Possibly the Rust compiler's unusual prioritization of friendly error messages with helpful suggestions meant this wasn't as big a difference as you thought?
> None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
That's how it works for many languages: the language server implementation is a thin wrapper around an existing tool. That's not the case for rust. I've watched the work the Rust language server team did on their language server implementation and the compiler. It was impressive.
That's the conventional wisdom. The rust team's theory was that they could make it work. They did.
> As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
Possibly the Rust compiler's unusual prioritization of friendly error messages with helpful suggestions meant this wasn't as big a difference as you thought?
> None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
That's how it works for many languages: the language server implementation is a thin wrapper around an existing tool. That's not the case for rust. I've watched the work the Rust language server team did on their language server implementation and the compiler. It was impressive.
> That's the conventional wisdom. The rust team's theory was that they could make it work. They did.
They didn't. Does the rust compiler support continuous analysis required by an IDE?
> That's not the case for rust.
Funny. Rust analyzer blog would have us believe that they have their own parser and analyzer.
They didn't. Does the rust compiler support continuous analysis required by an IDE?
> That's not the case for rust.
Funny. Rust analyzer blog would have us believe that they have their own parser and analyzer.
More to the point. Sadly I can't locate a great article outlining all the problems, bt these quotes will do
From rust-analyzer's main contributor [1]
=== start quote ===
The essential complexity for a server is pretty high. It is known that compilers are complicated, and a language server is a compiler and then some.
First, like a compiler, a language server needs to fully understand the language, it needs to be able to distinguish between valid and invalid programs. However, while for invalid programs a batch compiler is allowed to emit an error message and exit promptly, a language server must analyze any invalid program as best as it can. Working with incomplete and invalid programs is the first complication of a language server in comparison to a compiler.
Second, while a batch compiler is a pure function which transforms source text into machine code, a language server has to work with a code base which is constantly being modified by the user. It is a compiler with a time dimension, and evolution of state over time is one of the hardest problems in programming.
Third, a batch compiler is optimized for maximum throughput, while a language server aims to minimize latency (while not completely forgoing throughput). Adding a latency requirement doesn’t mean that you need to optimize harder. Rather, it means that you generally need to turn the architecture on its head to have an acceptable latency at all.
=== end quote ===
Rust analyzer uses a custom parser [2]
=== start quote ===
a hand-written recursive descent parser, which produces a sequence of events like "start node X", "finish node Y". It works similarly to kotlin's parser, which is a good source of inspiration for dealing with syntax errors and incomplete input. Original libsyntax parser is what we use for the definition of the Rust language. TreeSink and TokenSource traits bridge the tree-agnostic parser from grammar with rowan trees.
=== end quote ===
[1] https://matklad.github.io/2022/04/25/why-lsp.html
[2] https://github.com/rust-lang/rust-analyzer/blob/master/docs/...
From rust-analyzer's main contributor [1]
=== start quote ===
The essential complexity for a server is pretty high. It is known that compilers are complicated, and a language server is a compiler and then some.
First, like a compiler, a language server needs to fully understand the language, it needs to be able to distinguish between valid and invalid programs. However, while for invalid programs a batch compiler is allowed to emit an error message and exit promptly, a language server must analyze any invalid program as best as it can. Working with incomplete and invalid programs is the first complication of a language server in comparison to a compiler.
Second, while a batch compiler is a pure function which transforms source text into machine code, a language server has to work with a code base which is constantly being modified by the user. It is a compiler with a time dimension, and evolution of state over time is one of the hardest problems in programming.
Third, a batch compiler is optimized for maximum throughput, while a language server aims to minimize latency (while not completely forgoing throughput). Adding a latency requirement doesn’t mean that you need to optimize harder. Rather, it means that you generally need to turn the architecture on its head to have an acceptable latency at all.
=== end quote ===
Rust analyzer uses a custom parser [2]
=== start quote ===
a hand-written recursive descent parser, which produces a sequence of events like "start node X", "finish node Y". It works similarly to kotlin's parser, which is a good source of inspiration for dealing with syntax errors and incomplete input. Original libsyntax parser is what we use for the definition of the Rust language. TreeSink and TokenSource traits bridge the tree-agnostic parser from grammar with rowan trees.
=== end quote ===
[1] https://matklad.github.io/2022/04/25/why-lsp.html
[2] https://github.com/rust-lang/rust-analyzer/blob/master/docs/...
I was totally wrong. Thanks for the correction. Looks like it was planned but never implemented (yet): https://github.com/rust-lang/rust-analyzer/issues/10765
I once heard that an editor spends the majority of its time in an error state, and only periodically someone stops typing in hopefully(!) a valid state. Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work
> Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work
It is. Error recovery is one of the biggest issues precisely for the reason you mentioned :)
It is. Error recovery is one of the biggest issues precisely for the reason you mentioned :)
While that's absolutely true, I'd be totally fine with what an LSP _does_ offer. Auto imports, go to definition, list usages, etc. I don't need the heavy refactoring tools.
Felt really great! Snappy and familiar to modern equivalents (e.g. VS Code). That said, memory consumption is pretty high at around 3.35 GB for the backend, 1.83 GB for the frontend on a decently sized project. Compared to Nova which has that and a lot more loaded at 1.26 GB.
PHP smart mode definitely needs work. A lot of errors that wouldn't be errors if we could specify which version of PHP the project was running as. Using any PHP7+ feature ends up in an error.
Some silly issues with namespacing as well - like using "string" type-hinting on class functions in a namespaced class shows an error.
And some highlighting oddities with some of our files, but all-in-all I really liked Fleet. Will keep an eye on it!
PHP smart mode definitely needs work. A lot of errors that wouldn't be errors if we could specify which version of PHP the project was running as. Using any PHP7+ feature ends up in an error.
Some silly issues with namespacing as well - like using "string" type-hinting on class functions in a namespaced class shows an error.
And some highlighting oddities with some of our files, but all-in-all I really liked Fleet. Will keep an eye on it!
Still confused.
Is Fleet to IntelliJ as VS.Code is to Visual Studio?
Is Fleet to IntelliJ as VS.Code is to Visual Studio?
Better. It's like a VS.Code that you can turn into a Visual Studio (if needed) within the same application.
Basically yes.
I have read all the comments on this thread.
I'm fascinated by people's thoughts of VSC Vs JetBrains.
It seems the consensus is that JB is better, except for web platform?
Maybe this is because TypeScript is an excellent language server
I'm fascinated by people's thoughts of VSC Vs JetBrains.
It seems the consensus is that JB is better, except for web platform?
Maybe this is because TypeScript is an excellent language server
The only thing that matters to me is JetBrains stuff seems to actually understand my code. i.e. it never fails to be able to jump me to references if I cmd+click a symbol, it's never messed up an automatic refactor (like a variable rename or something), etc. And it just works out of the box.
I've never been able to configure VS Code to work in a way that's anywhere approaching intelligent. Maybe there's a way but I don't want to be messing with plugins and settings. And every time I've tried I just get frustrated and give up. I keep it installed for quick one-off text editing cause it launches faster than JB, but Fleet might just replace it for that usecase now.
I've never been able to configure VS Code to work in a way that's anywhere approaching intelligent. Maybe there's a way but I don't want to be messing with plugins and settings. And every time I've tried I just get frustrated and give up. I keep it installed for quick one-off text editing cause it launches faster than JB, but Fleet might just replace it for that usecase now.
VSCode is still best for anything that isn't Android development, IMO. The C/C++, Rust, JS/TS integrations in VSCode have been amazing for me. IntelliJ is a battery killer, but VSCode is something I can run on a plane or in a cafe without a power cord.
I don't know if it even wins there, to be honest. I'd say they're on par if anything, with a slight edge to JetBrains, as they have better support built-in vs needing plugins.
I'm a long time JetBrains user though, so I admit upfront I may have some bias here.
I'm a long time JetBrains user though, so I admit upfront I may have some bias here.
Can't speak of other JB IDEs, by PyCharm is awesome
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
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
We prefer sync code reviews sometimes and it's easier.
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.
It only makes sense for distributed pair programming. But that’s not a bad idea either.
I think Visual Studio code has great influence on it but after trying it, I think VS code can also learn few things about interface from it. Really neat.
Probably JetBrains thought to leverage tons of in house Java code otherwise I think Rust + Skia or similar would have been a great option with almost no run time requirements. Rust gurus can say better but I have seen pretty impressive cross platform apps in Rust such as alacritty and warp.
Probably JetBrains thought to leverage tons of in house Java code otherwise I think Rust + Skia or similar would have been a great option with almost no run time requirements. Rust gurus can say better but I have seen pretty impressive cross platform apps in Rust such as alacritty and warp.
I honestly think it would be painful to write a large GUI app like this in Rust, and it's not something I would attempt.
Backend and code analytics side, sure. But like you said they have lots of in-house code written in Java.
It's interesting they stuck with Java for the UI, but it does seem to be snappy and I'm glad to see them walk away from Swing.
Backend and code analytics side, sure. But like you said they have lots of in-house code written in Java.
It's interesting they stuck with Java for the UI, but it does seem to be snappy and I'm glad to see them walk away from Swing.
Requires some mega-ugly “toolbox” app as an installer for all the JetBrains apps - no, thanks, Adobe taught me to burn such things when I see them.
Yet another editor with no ability to switch to vertical tabs. Looks like I'm staying with the old-school JetBrains IDEs for the time being.
Interesting! Looking forward to trying it out. I won't consider paying for it until it's at least FOSS though, like IntelliJ or PyCharm. I paid for those 2 products and those 2 products alone solely because they are free and open source (I can't get shafted by a sudden change in licensing and can switch to a functionally equivalent free version on a whim).
I'm pretty confused by the product positioning. If Fleet is built on the same technologies as other Jetbrains IDEs, describes itself as an IDE, and is natively polyglot, why shouldn't it replace the other language-based IDEs? From the marketing material, it's not clear to me the value proposition of, for example, IntelliJ compared to Fleet.
Maybe eventually the other IDEs will evolve into Fleet. But in the meantime, I can see why they'd want to avoid spooking their existing customer base into worrying that their investment in existing tooling is at risk.
Unfortunately it doesn’t look like this supports remote development (at least from what I can tell poking around their site).
Until Gateway is performant & stable enough to use, I’m sticking with VSCode. It’s a shame because I prefer IntelliJ for Java development, but lacking remote development stability is a deal breaker.
Until Gateway is performant & stable enough to use, I’m sticking with VSCode. It’s a shame because I prefer IntelliJ for Java development, but lacking remote development stability is a deal breaker.
https://www.jetbrains.com/help/fleet/install-on-a-remote-mac... - It seems it does support remote dev. Just played with it on my laptop and a Linux VPS I toss things onto from time to time, it worked alright. Haven't tried anything serious with it yet. When Fleet launched I had the option of connecting via SSH, specified the IP and port, and was able to connect. It uploaded some programs which run on the remote host to support the work. I was able to edit a program and then run it. There was also a terminal available on the remote host from inside Fleet.
It's extremely far from IJ in terms of functionality, at the moment. I don't think Jetbrains will avoid the need of making Gateway stable too.
[deleted]
Already saw it in Toolbox App and installed ;-) Gonna give it a try.
Congrats on the launch, and kudos to the Fleet team!
Congrats on the launch, and kudos to the Fleet team!
Very sluggish and no vim support. It looks promising but I’m going to let it bake for a while.
Ditched VSCode for PyCharm when I started learning Python.
Simply using it for a few months convinced me to upgrade to the Pro edition, the same vibes as when I used Borland Turbo C - VSCode just has that bloated feeling like Eclipse.
Simply using it for a few months convinced me to upgrade to the Pro edition, the same vibes as when I used Borland Turbo C - VSCode just has that bloated feeling like Eclipse.
> Fleet is an opportunity for us to provide a different user experience for developers
Given they're presumably spending a lot on this development, it would be useful to give a bit more detail than this. What is different?
Given they're presumably spending a lot on this development, it would be useful to give a bit more detail than this. What is different?
It's free to download and try (well... it's in my 'toolbox').
Comment I made to a friend earlier... Loads relatively quick. On par with or slightly faster than vscode on my M1. Very 'project unaware' up front, which may be OK for some uses. Might be a step up from vim for one-off changes. Collab seems easier/faster. No plugins(?). No UI to connect to other machines so far.
Comment I made to a friend earlier... Loads relatively quick. On par with or slightly faster than vscode on my M1. Very 'project unaware' up front, which may be OK for some uses. Might be a step up from vim for one-off changes. Collab seems easier/faster. No plugins(?). No UI to connect to other machines so far.
Looks pretty and well-designed. Snappy too, but they're going to have to work on the startup time.
I'll check back in a year when it's a bit more feature rich. And when you can disable the smooth scrolling.
I'll check back in a year when it's a bit more feature rich. And when you can disable the smooth scrolling.
Rust support seems good and it's already integrated if you press the lightning button in the top right. Sadly no vim support so it's not really usable yet (at least for me).
Maybe this can replace Atom. But for that we need a OneDark theme :)
Might need some Apple Silicon testing, I could toss and egg on my M1 MBP and it'll be done by the time I scroll to the bottom of the document.
It looks very practical and I like the choices they made. But, I can't use it as a daily driver because it doesn't have vim mode.
> Run in a performant virtual machine with up to: 16 CPU cores 32 GB Memory 40 GB Disk Drive
Literally my laptop that I bought for $1300 3 years ago.
Literally my laptop that I bought for $1300 3 years ago.
Model?
Acer predator helios 300 (was $1000), 12vcores, 256GB NVME, upgraded to 32GB ram.
I like the fleet light/dark theme, can JetBrains put it as a plugin so I can use it in other JB products?
I want Darcula back. It's the only dark theme I've ever liked in any piece of software.
It's grey instead of black so it doesn't hurt my eyes, and the color contrasts for symbol highlighting and whatnot are very well tuned.
It's grey instead of black so it doesn't hurt my eyes, and the color contrasts for symbol highlighting and whatnot are very well tuned.
Just wondering, there's no way to launch Fleet directly without launching it from Toolbox or using CLI?
It gets installed as an application, so you can open it with your usual app launchers on Mac and Linux (I haven't used it on Windows). You can open it from the terminal also, but the path it gets installed in is a convoluted one and includes the version, so you will need to update your aliases/links every time a new version is installed.
Thanks! I guess I'm using Raycast (instead of Spotlight), so it actually need a reindex.
I wish they'd provide more support for C++; CLion is incredibly slow on older Macbooks.
Instead of coming up with a new project, why just they do not provide a community edition for each of their products? Currently they provide a CE edition for PyCharm only?
I remember I loved the initial version of Goland a lot but found out it is not free and expired after a while, I switched back to VSCode and did not regret at all
I remember I loved the initial version of Goland a lot but found out it is not free and expired after a while, I switched back to VSCode and did not regret at all
"Instead of trying to innovate, why don't they just give out their existing products for free to customers that aren't willing to pay?"
Jetbrains make good products. And it's great that they're trying to explore the potential for a more lightweight editor based on their technology.
Jetbrains make good products. And it's great that they're trying to explore the potential for a more lightweight editor based on their technology.
"Currently they provide a CE edition for PyCharm only?"
If I'm not mistaken, I think they have a CE edition of IntelliJ (java) too.
If I'm not mistaken, I think they have a CE edition of IntelliJ (java) too.
Yes, both are Apache 2 licensed: https://github.com/JetBrains/intellij-community#readme (pycharm is in the "python" subdirectory). It used to be painless to build them both, but the recently doubled down on jps and now it's hit-or-miss and a ton more complicated, but I can attest it is possible
[deleted]
When will IdeaVim (or similar) work? Can't use it until then.
I was hopeful, but after playing with it, I'm not impressed!
How is this different from intelliJ Ultimate?
3 gigs for a web app :crycat:
A bit OT but if any JetBrains employees read this: please, please could you change the icon for webstorm? It is so ugly that it hurts my eyes. I will pay you to change the icon. Thanks.
I think the name is a little funny, and maybe the funny is so crude and juvenile, that no one was willing to mention it? Like the Pepsi logo, I can't unsee it.
"OK, people, creative time! Blank slate, no second system syndrome. Let's rethink the JetBrains concept, from the bottom, up!"
"Jet-- Butts?"
"Will the JetButts brand fly in all markets? Riff alternatives?"
"...Fleet?"
"Explosive! Sounds fast and productive! Can we get a mark search?"
https://www.amazon.com/s?k=fleet
"OK, people, creative time! Blank slate, no second system syndrome. Let's rethink the JetBrains concept, from the bottom, up!"
"Jet-- Butts?"
"Will the JetButts brand fly in all markets? Riff alternatives?"
"...Fleet?"
"Explosive! Sounds fast and productive! Can we get a mark search?"
https://www.amazon.com/s?k=fleet
Someone had to mention it before launch.
ALSO I just noticed this but can someone (ideally from JetBrains) explain what this line means: "Requires login and periodic connection to JetBrains servers to verify the project" (specifically the last 3 words of that sentence). Quite frankly this line is extremely alarming, are you saying that you're scanning my project to make sure it's not a "professional" project? I'm going to assume this line means that they are checking the IDE and not your source but I won't be using this product until I get an explanation for this. You can find this at the very bottom in the licensing and pricing section.
[1]: https://prettier.io/