What an absolutely tone deaf thing to say. "It can't be our product that's using out dated philosophies. It's the users that don't know how to use it properly"
I can see that by using an abridged and edited version of my analysis of the data for this blog post that I’ve unintentionally spread confusion. I’d like to clarify the intention behind my comments on developers and IDEs. For me, if developers don’t understand what IntelliJ IDEA gives them as a fully-featured IDE, that’s a failure on my part, since it has been my job for six years to educate developers on what an IDE (specifically IntelliJ IDEA) can do for you. I feel very strongly that one should never blame users, or prospective users, for failing to understand a product.
My personal viewpoint on IDEs for Java developers comes from having been a Java developer for 20+ years, working on production Java projects large and small. I can’t imagine trying to create a complex enterprise application without the considerable help you get from an IDE like IntelliJ IDEA. I have also seen lots of developers using VSCode and I completely see the use cases that code editors cover well. There’s always room for more than one tool in your toolkit, and understanding what a tool does well helps us pick the right one for the right job.
I work on an enterprise project with 100+ gradle projects and a pile of targets for docker containers, kubernetes deployments, DB schemas, Redis stuff, etc..
Eclipse is incredibly slow in this use case compared to IntelliJ and would frequently gobble 10GB of Ram. I switched from Eclipse to IntelliJ earlier this year after years on this project and IntelliJ is amazingly better.
But if you're using some different build system and a different type of project configuration maybe it's the other way around..
I think the thing with these
This was back in 2011 though. Obviously things have changed.
The difference between Eclipse and IntelliJ was like night-and-day, however, in terms of performance.
I don't love eclipse, not a person to get too attached to an IDE, but it is an incredible piece of open source software. It works.
Also too much effort in rewiring keyboard shortcuts that have made their way to my muscle memory. So eclipse it is.
Something as simple as opening a file of code requires IDE, because everything is hidden behind `./src/main/java/com/whatever` nonsense. The language was designed for IDE.
In Rust there is hardly any need for IDE (or a debugger), as long as your text editor has LSP support. Hell, even without LSP support it feels quite OK to write Rust code.
I use Intellij for Java, and Kakoune for Rust, and I really dislike working with Java. The fancy refactoring features don't make up for how verbose, clunky and inexpressive Java is.
The Rust way is to have great modular and reusable tooling for everything. Even stuff like complex refactoring can be achieved without an IDE with something like https://github.com/google/rerast
https://www.jetbrains.com/rust/
and of course, there is the GoLand IDE
Which I personally like alot.
VSCode doesn't interpolate HTML variables for me. Its the small features that add up over time I miss whenever I try to switch development environments.
VSCode has a really good TypeScript/JavaScript and admittedly Python developer story, and the ecosystem has produced some pretty robust Style editing extensions, but if you want things like autocompletion for your template variables, I've always found you have to look elsewhere, whether it be handlebars, django templates, Jinja templates etc (and this is one example, among many)
VSCode doesn't autoload JSON schema (need an extension or hope for the best)
VSCode Extensions are also suffering from some pretty serious lack of maintenance too. Lots of extensions, very little movement on updates. I've had more than one of them break on me in major ways.
As someone who wishes they could drop everything else and just use Kate or VS Code, I disagree. IDEs like those that JetBrains offers have refactoring tools that are unmatched by what VS Code and its plugin ecosystem currently provide.
More widely used langs have better experiences though I'm pretty sure. And maybe Rust support has gotten better? Seems that other commenters in this thread had positive experiences.
For longer sessions that's not a problem, but when you're on battery or quickly hopping into the project to look something up it makes a lot of difference. Also, opening up a foreign project is two clicks and one second, compared to project creation and then loading+indexing when using IntelliJ.
I love the IntelliJ line of IDEs. But VSCode outcompetes it in simplicity by far. Especially when we're talking about something like a simple Node project, where compilation+execution is far simpler than something with a full build pipeline with artefacts.
When you start a longer session, the overhead is very much worth it, I agree fully.
I wouldn't blame that on VS Code but on the relevant extension. Go to Definition is instantaneous for me when I'm working in TypeScript
VScode is a very nice middle ground where the defaults make sense and you can get powerful extensions for everything else you want, there's a reason it's so popular.
You say that, but IntelliJ is not exactly slouching on resource usage. I see far lower memory usage in VS Code than I do IntelliJ opening the same projects.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does under similar circumstances because I've never tried to measure it, but I know that I regularly see Electron apps using less than 70MB, so we can estimate an upper bound on Electron's typical contribution to bloat as being no more than ~30% of Java's.
For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB. I doubt that much of that difference is actually attributable to using a browser rendering engine for GUI layout. In fact, I'm guessing that Chromium's net impact on the situation falls below the noise threshold of this comparison. So, yeah, not worried about it. FWIW, vscode also started up quite a bit faster, and I experience less keyboard lag when using it.
And, if we're looking for mature and full-featred cross-platform GUI toolkits, that's about it for your options. Yes, there's QT, but, with a sticker price of $4000/developer/year, it's hard to criticize people for not choosing it. And there's GTK+, which is fine, I suppose, but not exactly everyone's cup of tea.
Long story short: This Electron-flaming meme is getting old. If you don't like JavaScript, just come out and say it. If you don't like how Chromium is eating the world, that's a fair point, too. But stop scapegoating Electron for things like how Slack's desktop app used to leak memory at an astonishing rate. That was always the app developer's fault, not Electron's.
This is much lower in newer jdk's [0].
> For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB
I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram.
[0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.
If you want the QtGui module, look north of $100k buy-in.
Which to be fair is a very impressive piece of technology
Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.
> Long story short: This Electron-flaming meme is getting old.
No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.
Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap.
You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course.
I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.
Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.
So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.
I see this critisism of VSCode a lot - but the job of a browser engine is to render text really fast! Rendering text is something you want to do in a text-editor is it not? Why not use the best tool for the job?
You're probably right that something like Sublime Text is faster - but that's a massive undertaking that would take a lot of engineering to get right.
The point of Electron is to allow people to develop UIs quickly, leveraging their experience with the web. Electron is extremely bloated & slow. To some degree it has to be.
If browsers were about speed, they wouldn't interpret Javascript. I'd argue they'd probably force the UI to be specified in a form that explicitly disallows inefficiencies and probably isn't turing complete. I'd argue a domain-specific solution for rendering highlighted code specifically could be a lot faster than a browser, like multiple orders of magnitude. We know that's the case by virtue of the fact we could even do it at all in the 80s.
That would be so far beyond impractical you wouldn't last an afternoon.
The way of the future is definitely lightweight code editors loaded with as much or little customisation as the user desires. Monolothic IDEs are long dead outside of the Enterprise™© world.
Funnily enough, I also found myself using Java and .net less and less. I never had much love for Java, but C# was an amazing language that somehow got gobbled up by the Enterprise black hole and it's a huge shame.
I spend all day navigating and reasoning about the codebase I'm working in, so I need strong tools that aide me in that. That's where VSCode doesn't hold a candle to Rider IME. So Rider is my daily driver at work.
The responses from some devs leave me wondering what their env/projects/work day actually look like and how does their tooling actually work for them in practice.
It would be incredibly interesting to see the landscape of different work envs and tooling and do a comparison of what happens in each given env when you swap out the tooling.
A typical work day has me working in at least two different projects. Visual Studio/Rider is so heavy that I don't want to keep two instances of it running all the time and it's so slow that switching between projects in a single instance carries a heavy context switching cost. I also have a set of markdown files that I use as a second brain which I like to open periodically to check notes or jot down ideas.
> Do you work on multiple things that don't require coding?
I also write documentation, answer emails, review PRs, occasionally modify art assets, maintain team documents, etc. I don't always want Visual Studio/Rider hogging all of my memory or chewing up the CPU.
> Why does launch-time matter at all?
I hope what I already wrote made it clear but TL;DR I jump between projects, don't want multiple instances consuming all my resources, and (bonus) I frequently need to restart Visual Studio because it can get in to a weird state when working in C#/F# hybrid projects.
What IDEs have going for them is that the features are generally constructed by people who know what they are doing and test them at the same time. Whereas a plugin could be written by anyone. Also there's a great "works on my machine" when it comes to performance: the plugin author will just test the plugin on its own rather than with a bunch of other plugins, so their performance target is artificially low.
What in the world do you mean by this? C# is more amazing than ever...
No matter how amazing the language is, it has become hard associated with enterprise work and not much else. It didn't need to be that way, that's Microsoft's doing.
Maybe you are right on that, but why do you consider that a bad thing? Different languages are for different things.
Your statement of non-enterprise projects off by a factor of 10-100x is partly because people jumped on the non-statically typed mess that Python is. Especially with all the AI related stuff.. yeah if you are doing some random little research project and you are a math person but don't want to take the time to do programming "correctly", then sure you can jump into python, use some libraries and get some results. It has it's purpose.
I don't know it's just silly to bulk everything together and pretend you can compare them.
Also saying .net is dying in enterprise is basically laughable.