I switched form VSCode to PHPStorm half a year ago, and while it feels a bit slower, the improvements are so unbelievable worth it for me. It does have a taste for memory, but then again, it easily saves me a lot of time each month, so just throwing RAM at it was a no-brainer for me.
I was relieved when I switched back to PyCharm.
Vscode is nice but still quite far away from some good IDEs.
As to the RAM, it's using around 1.2gb between vs code and the connecting server (WSL2), multiple isntances vary... but with the number of containers and VMs I'm running, I'm generally well over 16gb of use, and I have 64gb on my desktop. So even without VS Code, I have trouble on a 16gb system.
I usually run 3-5 instances for different projects and it'll hover around 3gb RAM, but it appears that they share a lot of memory, closing one or opening an additional project has no visible impact.
I also have to do a lot of context switching (e.g. to review someone else's code), and being able to have a separate set of tabs (even within the same repo) is super-useful for this.
At previous jobs with less separated out code, I have taken this approach (although with Sublime Text rather than VSCode).
Even in the mono-repos I work with, I'll generally open an editor per inner repo. Mostly ./feature/featurename/filename is as far as I have to open. Some of the C# projects are deeper though.
I use it daily for .net coding, while i use VS code for everything else.
AWT/Swing based IntelliJ manages to be much, much faster in comparison.
I mostly program in languages like Ruby & Perl using Vim. Even with my decked out version that has 35 plugins, and some other bells and whistles, I'm on average using 20 MB of RAM. Open/Close is near instantaneous.
Also shout out to LINQPad, for letting me test quick snippets of C# with better visualization than Visual Studio. It's also a better alternative to Sql Server Management Studio for running SQL.
I'm sure this saved me an additional hundred hours.
The amount of work Microsoft is putting in this editor is amazing. Last month we got file history, that was the last thing I needed to ditch the Git GUI I had installed.
(I’m on the team)
My typical pattern is something like: define it, try it, adjust it, then apply variable times (including “infinite until error”), maybe save 1% of them. That often takes less time to do than it just took me to describe.
I use macros probably 25x for every one time I reach for multi-cursors, though to be fair, if I came the other way, I’d probably use multi-cursor more often than currently. (I used macros for 30 years before getting multi-cursors, so if both can do the job, I’ll use a macro.)
In my experience with multicursor, I don't need to be able to "inspect" the operation as the act of typing it is inspection in and of itself. Sure they aren't saveable and thus aren't editable (but you admit this is a very rare use case - I can't recall needing that, ofc you often don't know when to want what you don't have).
As for applying across a number of files, I recently added an in-editor rendering of workspace search results to VS Code, and I've created an extension that can apply edits to those search results back to the original files. This allows for performing multicursor edits across many files.
As for using variable numbers of times, this is again quite trivial with multicursor. I simply select all the instances I need (either all in one go or iteratively), and go from there. I admit there is an art to selecting the right text such that iterative selection works with a single keypress, but once you get the hang of it it becomes pretty natural. (Unless you mean "apply this N times", which again I'm not sure I've ever been in want of)
If the use case is “every day, download this file from a server and process it using pre-defined text editing commands”, multi-cursor doesn’t help you in any way that I can see.
I admit there’s a huge overlap in use, but when someone asks for macros and a product person says “how about multi-cursor instead?” I think it’s fair to raise the cases where someone asking for macros might actually want macros.
I also prefer vim's macros to multicursors, but I think it ammounts to nothing more than habit and preference.
Macros in Vim are going to be much more powerful, with movement commands and selection commands giving yo a more flexible system... I think? Hard to be objective after so many years of Vim.
Not OP, but to take a recent example (although it was in Emacs, I'm pretty sure it would work in any advanced editor), I had a macro select the second half of the open file and pipe it through sort and uniq to replace it with each unique line and their number of occurences. That's not doable with multi-cursors; their use cases intersect but don't overlap with macros ones.
My (admittedly naive) mental model of recursion is basically a loop where you bring your entire stack frame with you (or less, in the case of tail recursion).
Lately, I'd add the remote ssh and wsl extensions have been insanely useful, but starting code from inside wsl has gotten sluggish since the last vs code update.