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/
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.
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.
What about Gitlab, or some other repo such as gitlab.gnome.org? This seems like it's ripe for edge cases.
If you're really trying to win VS Code users, such a flexible rule may scare them away.
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].
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
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 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.
I am very happy that VSCode is mostly just editor.
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
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.
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 :)
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)... .
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 :)
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.
I guess the OS matters.
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.
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.
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...
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.
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)
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.
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.
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
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
I believe this is a reaction to VS Code, which has supported this functionality for a while already.
I'd not have described them that way.
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.
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.
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.
I assume this is their answer to that.
They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list
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.
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?
>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.
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. 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.
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.
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!
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
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'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'm a long time JetBrains user though, so I admit upfront I may have some bias here.
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.
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.
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
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
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.
If I'm not mistaken, I think they have a CE edition of IntelliJ (java) too.
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
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.
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.
- 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)
Is Fleet to IntelliJ as VS.Code is to Visual Studio?
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.
Literally my laptop that I bought for $1300 3 years ago.
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.
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
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.
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.
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.
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?
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.
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.
"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?"
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
However this issue doesn't really apply if you create a VM per workspace either manually or the service that is provided...
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
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 :)
RubyMine is a great IDE, worth paying for, but this looks like writing on the wall.
At least that's my understanding.
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?
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.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
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!
Congrats on the launch, and kudos to the Fleet team!
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.
I'll check back in a year when it's a bit more feature rich. And when you can disable the smooth scrolling.
