JetBrains invites developers to join the Fleet Public Preview Program
blog.jetbrains.com
blog.jetbrains.com
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
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].
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.
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.
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
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
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.
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
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.
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.
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
Game engines basically implement their own "runtime". They all have stuff like memory management, scripting languages (and usually plugins use the scripting API), and the game is just a package of assets and code that are run by the engine...
Huh? None of these are compiled to native code ahead of time. By definition using a JIT compiler is not making things "native", it's just a way of making a very fast interpreter.
Those languages you mention are used in gaming precisely because of their dynamic qualities compensating for the rigidness of the otherwise C++ based engines.
If all I needed was a quick text editor, obviously I would stick with Notepad++ or Sublime or Kate or... Nothing wrong with that, and actually much saner than the new web-based stuff IMHO.
One entire core just for typing text and moving your mouse
If you use a laptop to code, it'll eat your battery in no time
If you compile programs, it'll slow down your builds
That's why i don't want no java on my computer or any other JIT based BS or slow tech stack like the JVM, wich was made for servers not for latency SENSITIVE programs such as a TEXT editor where i TYPE text and where i need my cores to BUILD or to do STATIC ANALYSIS
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 :)
My email is in profile.
jack [at] weakphi [dot] sh
Email is en [at] ruw.io
RubyMine is a great IDE, worth paying for, but this looks like writing on the wall.
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?
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)
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.
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...
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.
No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals.
As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
> The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
It is. Error recovery is one of the biggest issues precisely for the reason you mentioned :)
That's the conventional wisdom. The rust team's theory was that they could make it work. They did.
> As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
Possibly the Rust compiler's unusual prioritization of friendly error messages with helpful suggestions meant this wasn't as big a difference as you thought?
> None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
That's how it works for many languages: the language server implementation is a thin wrapper around an existing tool. That's not the case for rust. I've watched the work the Rust language server team did on their language server implementation and the compiler. It was impressive.
They didn't. Does the rust compiler support continuous analysis required by an IDE?
> That's not the case for rust.
Funny. Rust analyzer blog would have us believe that they have their own parser and analyzer.
From rust-analyzer's main contributor [1]
=== start quote ===
The essential complexity for a server is pretty high. It is known that compilers are complicated, and a language server is a compiler and then some.
First, like a compiler, a language server needs to fully understand the language, it needs to be able to distinguish between valid and invalid programs. However, while for invalid programs a batch compiler is allowed to emit an error message and exit promptly, a language server must analyze any invalid program as best as it can. Working with incomplete and invalid programs is the first complication of a language server in comparison to a compiler.
Second, while a batch compiler is a pure function which transforms source text into machine code, a language server has to work with a code base which is constantly being modified by the user. It is a compiler with a time dimension, and evolution of state over time is one of the hardest problems in programming.
Third, a batch compiler is optimized for maximum throughput, while a language server aims to minimize latency (while not completely forgoing throughput). Adding a latency requirement doesn’t mean that you need to optimize harder. Rather, it means that you generally need to turn the architecture on its head to have an acceptable latency at all.
=== end quote ===
Rust analyzer uses a custom parser [2]
=== start quote ===
a hand-written recursive descent parser, which produces a sequence of events like "start node X", "finish node Y". It works similarly to kotlin's parser, which is a good source of inspiration for dealing with syntax errors and incomplete input. Original libsyntax parser is what we use for the definition of the Rust language. TreeSink and TokenSource traits bridge the tree-agnostic parser from grammar with rowan trees.
=== end quote ===
[1] https://matklad.github.io/2022/04/25/why-lsp.html
[2] https://github.com/rust-lang/rust-analyzer/blob/master/docs/...
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!
Is Fleet to IntelliJ as VS.Code is to Visual Studio?
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.
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
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.
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.
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.
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'll check back in a year when it's a bit more feature rich. And when you can disable the smooth scrolling.
Literally my laptop that I bought for $1300 3 years ago.
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.
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.
"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?"