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?
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.
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.
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.
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.
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)
> 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?
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.
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"
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
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.
> 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.
> 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.
> 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.
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.
Microservices ... laptop user sets breakpoints on a Django/Python API/web server, a Java financial transaction processor, and a golang outgoing webhook queue server.
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.
> 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.
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.
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.
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:
(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.
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.
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
> - 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.
> - 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.
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.
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 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.
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...
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
This looks really promising. But by far the biggest moat that Jetbrains is going to have to cross to get into VSCode territory is the plugin ecosystem. Personally I work on React projects so my first thought was: "is there a Prettier[1] plugin?". Looking through the landing page it looks like Plugins are in the works but until that is implemented, it's going to be hard adopting it.
ALSO I just noticed this but can 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.
> 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
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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 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.
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.
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
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 :)
> 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.
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.
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.
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.
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)
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.
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.
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.
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)
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’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 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.
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.
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.
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.
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].
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.
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):
> 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.
> 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.
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.
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.
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
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.
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
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).
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)
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.
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.
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 :)
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 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.
> 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)... .
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.
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 :)
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.
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.
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.
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.
This is my dream. Being able to use Fleet/JetBrains's backend as an LSP/DAP for Neovim. It sounds like the architecture is there with Fleet. Please JetBrains friends!
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
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
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.
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.
331 comments
[ 2.9 ms ] story [ 239 ms ] threadIt 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?
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.
>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. 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.
- 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)
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.
I believe this is a reaction to VS Code, which has supported this functionality for a while already.
e.g., quassel, an irc bouncer + client, used the same term since 2007.
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
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.
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.
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.
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.
> ‘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.
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.
I assume this is their answer to that.
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
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.
They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list
Is Fleet to IntelliJ as VS.Code is to 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
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.
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.
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.
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.
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
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...
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 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.
Edit: more info:
https://plugins.jetbrains.com/plugin/8182-rust/docs/rust-faq...
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.
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.
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
Sounds like a nightmare! What do IT know about development to be picking tools?
Anything beyond the standard development image requires opening a request to IT and procurement, with the respective OK from management.
Every developer has their own way of being productive which involves different tools & software. Forcing everyone to use one standardized environment sounds horrible.
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.
"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.
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.
Also I think that it's more like $600/yr for companies.
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?"
I really like the licensing model they employ.
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.
VSCode Web as modern version of X Windows based IDEs is great, as yet another Electron app not really.
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.
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
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/
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
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.
This also really baffles me. You can see it a lot in various discussions even here on HN.
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.
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.
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.
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.
No they didn't. This is a total mischaracterisation of how JB's subscription works.
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...
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.
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
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 :)
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.
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.
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.
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.
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)
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.
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.
Other than that, IntelliJ is as universal as it gets.
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)
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 very happy that VSCode is mostly just editor.
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.
What about Gitlab, or some other repo such as gitlab.gnome.org? This seems like it's ripe for edge cases.
gitlab.gnome.org - I'd expect it to be all open source, right? Open source program should cover such cases.
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 info in the link provided addresses the only concrete portion of your comment, which is that, yes, most Russian employees have moved elsewhere.
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.
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/
https://code.visualstudio.com/docs/getstarted/telemetry
You can also dump all possible telemetry events at the command-line.
Source: https://www.roboleary.net/tools/2022/04/20/vscode-telemetry....
> 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.
> 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.
If you're really trying to win VS Code users, such a flexible rule may scare them away.
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.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
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
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 :)
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)
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.
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.
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...
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.
But the ram is typical intellij, they take what they can get from the OS :)
I mean please don't judge the CPU profile of an EAP to the final product.
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.
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.
Congrats on the launch, and kudos to the Fleet team!
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.
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.
At least that's my understanding.
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