VSCode memory leak issue marked “out-of-scope”(github.com)
github.com
VSCode memory leak issue marked “out-of-scope”
https://github.com/microsoft/vscode/issues/107999
73 comments
Hi, I'm a developer on VS Code and wanted to clarify that there was actually a logical memory leak in there.
The problem is that I tried to reproduce it back in October while running from sources, and I could not reproduce any leak. I believed the issue is about the memory usage reported by the OS vs the memory usage reported by the logical JS Heap Snapshot, which is a common topic for garbage collected runtimes, such as JS / v8. That is why we believed the issue is about the v8 VM not freeing memory back to the OS when we freed memory logically.
But it turns out I tried the steps again just now, and there is a real memory leak in there! It only reproduces when running a built version of VS Code, such as VS Code Insiders or VS Code Stable. The built versions of VS Code offer file type extension recommendations, for example you open a `.php` file and a recommendation comes in to point you to the PHP extension. When running out of sources, those recommendations do not show up and the entire code responsible for those does not execute.
Thank you for bringing this up to my attention and I'm sorry for misunderstanding the initial issue.
The problem is that I tried to reproduce it back in October while running from sources, and I could not reproduce any leak. I believed the issue is about the memory usage reported by the OS vs the memory usage reported by the logical JS Heap Snapshot, which is a common topic for garbage collected runtimes, such as JS / v8. That is why we believed the issue is about the v8 VM not freeing memory back to the OS when we freed memory logically.
But it turns out I tried the steps again just now, and there is a real memory leak in there! It only reproduces when running a built version of VS Code, such as VS Code Insiders or VS Code Stable. The built versions of VS Code offer file type extension recommendations, for example you open a `.php` file and a recommendation comes in to point you to the PHP extension. When running out of sources, those recommendations do not show up and the entire code responsible for those does not execute.
Thank you for bringing this up to my attention and I'm sorry for misunderstanding the initial issue.
vscode's remote mode is what pulled me away from sublime. There's just nothing like it in any other editor and it's becoming indispensable to my particular workflows.
[just to preempt: for various reasons vim or emacs in a remote terminal do not meet my needs in the same ways]
[just to preempt: for various reasons vim or emacs in a remote terminal do not meet my needs in the same ways]
It's a shame Remote SSH etc are closed source and MS has no plans to open them. The extensions even check and refuse to run under non-MS vscode builds.
Can you explain a bit more about the usecase remote supports?
I use it for developing inside docker containers.
We have a dockerized Apache Airflow setup for which I am adding plugins.
Remote VSCode allows to work inside one of the containers spun up by docker-compose, so I do not have to simulate the environment the final system is running in.
Think of it as python venv on steroids.
Another use case is remote ssh where I can work on a headless system with a graphical editor. I use it e.g. to work in a minimal Linux VM from my Windows desktop.
The remote docker plugin is a little fiddly to setup, but once running works pretty good.
Another use case is remote ssh where I can work on a headless system with a graphical editor. I use it e.g. to work in a minimal Linux VM from my Windows desktop.
The remote docker plugin is a little fiddly to setup, but once running works pretty good.
I think one use case would be working inside of a Docker container, locally or remote.
The Remote - SSH extension allows you to run Visual Studio Code on whatever computer you want to run it on but then remotely connect to another computer such that your files are on the other computer, your code runs on the other computer, and the integrated terminal can run on the other computer. So it's like SSH on steriods, where your editor and IDE works, including all the extensions you'd expect.
So for example, instead of going through the hassle of building Visual Studio Code on Raspberry Pi, where there's no official support, you can simply use the Remote - SSH extension to develop directly on the Raspbery Pi from a Windows computer. This really shines when the Linux machine you're connecting to is headless.
The Remote - WSL extension allows the same thing but in a more direct way by connecting to a WSL installation on your Windows computer.
https://code.visualstudio.com/docs/remote/remote-overview
This feature is also why I've recently been using Visual Studio Code more and more. I think something like Emacs, once you learn it and spend a huge amount of time on, would be more performant and snappy in the end, but Visual Studio Code has too many modern features and a rather frictionless configuration and extension experience that keeps me there.
So for example, instead of going through the hassle of building Visual Studio Code on Raspberry Pi, where there's no official support, you can simply use the Remote - SSH extension to develop directly on the Raspbery Pi from a Windows computer. This really shines when the Linux machine you're connecting to is headless.
The Remote - WSL extension allows the same thing but in a more direct way by connecting to a WSL installation on your Windows computer.
https://code.visualstudio.com/docs/remote/remote-overview
This feature is also why I've recently been using Visual Studio Code more and more. I think something like Emacs, once you learn it and spend a huge amount of time on, would be more performant and snappy in the end, but Visual Studio Code has too many modern features and a rather frictionless configuration and extension experience that keeps me there.
I use vscode-ssh to offload the heavy work to my desktop when working from my laptop.
The big deal is that vscode uses a client/server setup, where a "client" vscode instance runs on your machine and a "server" vscode instance runs on the remote one. Then they figured out how to make latency and/or network intermittencies a non-issue. The experience is basically the same as working locally, except the linter, language server, formatter, and compilation run on the server-side (and hence don't bog down my laptop in this case).
Then there are quality-of-life touches, such as vscode offering to tunnel ports whenever you launch something in the integrated terminal that listens for connections. That is: let's say I run "python3 -m http.server" in the terminal within vscode (where I'm working on a remote project). The http server is launched on the remote machine, and I get a prompt asking me if I want to setup a 8080 (laptop) -> localhost:8080 (server) tunnel.
I was an adept of Jetbrain's various IDEs (and smart completions are still better there for most languages), but vscode-remote works so well that it has won me over.
Not long ago, a friend of mine was considering a new laptop. He was happy with his pixelbook in general, but working in the "c++ with lots of number-crunching" space the pixelbook wasn't cutting it. I gave him an account to my desktop machine to let him try, and he's now a happy owner of a nice workstation for much less than what the laptops he was considering cost. Important point: my desktop uses a residential connection in Spain, and he's in the US. He had 0 issues with latency whatsoever (and I can attest the connection itself does have such problems).
The big deal is that vscode uses a client/server setup, where a "client" vscode instance runs on your machine and a "server" vscode instance runs on the remote one. Then they figured out how to make latency and/or network intermittencies a non-issue. The experience is basically the same as working locally, except the linter, language server, formatter, and compilation run on the server-side (and hence don't bog down my laptop in this case).
Then there are quality-of-life touches, such as vscode offering to tunnel ports whenever you launch something in the integrated terminal that listens for connections. That is: let's say I run "python3 -m http.server" in the terminal within vscode (where I'm working on a remote project). The http server is launched on the remote machine, and I get a prompt asking me if I want to setup a 8080 (laptop) -> localhost:8080 (server) tunnel.
I was an adept of Jetbrain's various IDEs (and smart completions are still better there for most languages), but vscode-remote works so well that it has won me over.
Not long ago, a friend of mine was considering a new laptop. He was happy with his pixelbook in general, but working in the "c++ with lots of number-crunching" space the pixelbook wasn't cutting it. I gave him an account to my desktop machine to let him try, and he's now a happy owner of a nice workstation for much less than what the laptops he was considering cost. Important point: my desktop uses a residential connection in Spain, and he's in the US. He had 0 issues with latency whatsoever (and I can attest the connection itself does have such problems).
That sounds great!
I've seen it and it does look cool. I seem to recall there is a way of pair programming with VSCode which could be pretty rad too. I have no need for either of those features, but I can totally see them being a game changer in certain circumstances!
> There's just nothing like it in any other editor ...
Emacs has had TRAMP[1] built-in for a while now[2].
1: https://www.emacswiki.org/emacs/TrampMode
2: https://www-cdf.fnal.gov/~cplager/cygwin/useful/emacs/tramp-...
Emacs has had TRAMP[1] built-in for a while now[2].
1: https://www.emacswiki.org/emacs/TrampMode
2: https://www-cdf.fnal.gov/~cplager/cygwin/useful/emacs/tramp-...
What did you settle on for you vim plugin? ALE, coc?
Yes, that was my ultimate solution. I tried a different auto-complete plugin previously and it was disappointing which is the reason I've been on VSCode for so long.
FWIW, I found out about CoC on a recent thread here on HN.
For out code base, having Jump to Definition and refactoring is more-or-less essential.
For out code base, having Jump to Definition and refactoring is more-or-less essential.
Do you have your setup documented? I have been checking out Vim for TypeScript once a year or so and have not had complete luck, with plugins either requiring specific versions of Python and modules or just being unstable for the more advanced features.
I posted a little about it in another reply on this thread, I use ALE for JSLint/ Prettier integration and for Code Completion and quasi-IDE like features I use CoC.
Configuring CoC is basically copy/ pasta into your .vimrc. It's pretty self-explanatory though so you can figure out what's going on.
https://github.com/neoclide/coc.nvim
Configuring CoC is basically copy/ pasta into your .vimrc. It's pretty self-explanatory though so you can figure out what's going on.
https://github.com/neoclide/coc.nvim
> the Code Helper uses massive resources and about once every couple days ends up spinning out of control causing the CPU to cook and the fan to spin constantly until it's restarted
What language are you working in?
VSCode's user experience varies widely between languages/ecosystems. Its IDE features are driven by language servers, and most are written by third-parties, and some of them are great and some of them are terrible. TypeScript and Rust (if you're using rust-analyzer) are stellar. Python is okay. Flow (an alternate JavaScript type system) was terrible last time I checked, spinning the CPU and freezing up like you describe. Language servers run as a separate process (Code Helper, I believe) and can be as inefficient/leaky/resource-hungry as they want to be.
What language are you working in?
VSCode's user experience varies widely between languages/ecosystems. Its IDE features are driven by language servers, and most are written by third-parties, and some of them are great and some of them are terrible. TypeScript and Rust (if you're using rust-analyzer) are stellar. Python is okay. Flow (an alternate JavaScript type system) was terrible last time I checked, spinning the CPU and freezing up like you describe. Language servers run as a separate process (Code Helper, I believe) and can be as inefficient/leaky/resource-hungry as they want to be.
We're straight TypeScript/ React. We have a pretty large codebase though which no doubt contributes to the issue.
The thing is, VIM uses the same language server and (so far anyhow) doesn't melt down. It seems like the issue is in the Code Helper process itself.
The thing is, VIM uses the same language server and (so far anyhow) doesn't melt down. It seems like the issue is in the Code Helper process itself.
I have heard of people running into issues with the file-search indexer taking a long time on extraordinarily large projects. The largest project I've used it on was in the thousands of files (excluding node_modules) and didn't have any issues. But I know there are much larger projects out there, so I can't speak to those.
We're approaching 3000 source files in our repo so I'm not sure. That is the issue.
Here's a question: are you using git, and is node_modules ignored?
I ask because I think VSCode (by default) leans on the gitignore to decide which files to index. If it's indexing node_modules for whatever reason, that could create some serious overhead.
https://www.reddit.com/r/vscode/comments/fpfnle/is_there_a_w...
I ask because I think VSCode (by default) leans on the gitignore to decide which files to index. If it's indexing node_modules for whatever reason, that could create some serious overhead.
https://www.reddit.com/r/vscode/comments/fpfnle/is_there_a_w...
node_modules is in our .gitignore.
I'm not sure I was super clear above, but I'm not too worried about fixing this. Now that I have a good VIM configuration I just don't feel the urge to go back.
I'm not sure I was super clear above, but I'm not too worried about fixing this. Now that I have a good VIM configuration I just don't feel the urge to go back.
Do you have tests and install any test plugins? I found out after a while my fan was blazing because a plug-in was auto running all the tests it could find in the background. Once I turned that off it’s been tolerable.
For some reason VS Code will hang and not allow interaction or input for around 25-30 seconds. I have noticed this mostly when deleting a Python file and sometimes while editing Python. How might I debug whatever is blocking the main thread to find out if it is the language server or something else?
* Firstly, may I ask are you using Vim extension?
* Can you please follow instructions listed here https://github.com/microsoft/vscode/wiki/Performance-Issues#... to profile the renderer process when that happens (more accurately start the profile before the hang happens and stop after). Usually extension should not block the typing so it might be something bad in the core. Once you have it captured, please file an issue
Thanks in advance for the help.
Thanks in advance for the help.
I have the same problem, but I think it's an extension issue. On Ubuntu it happens, but with same extensions on macOS is not happening. I wish i could debug it.
In my case it happens only when deleting files from the source tree
That's crazy. I use it on a small-medium Python project (100-200 files) every day and have never had any performance problems whatsoever. I did use the MyPy language server at first, which would take a few seconds to update type errors because MyPy wasn't designed for IDEs. But the UI thread remained responsive during that time. Eventually I switched to the Pylance language server which doesn't do a perfect job with checks, but gives feedback instantly.
How big is your project, and how big are your files? I've had massive JSON files (100MB or so) cause some slight jank in the UI, but that's about the only example I can think of.
How big is your project, and how big are your files? I've had massive JSON files (100MB or so) cause some slight jank in the UI, but that's about the only example I can think of.
Sounds to me like you have underpowered hardware. I use it constantly for all kinds of tasks and the fan never even spins up. I haven't heard "spinning out of control causing the CPU to cook" anywhere else
> Sounds to me like you have underpowered hardware.
It's a text editor. It should run fine on whatever hardware I have. In this case, it's a fairly modern 15" MacBook Pro so even a full featured IDE should be just fine.
It's a text editor. It should run fine on whatever hardware I have. In this case, it's a fairly modern 15" MacBook Pro so even a full featured IDE should be just fine.
It has happened to me with some frequency. Sorry but I dont buy the under-powered hardware excuse when vim or Sublime perform great in the same computer. And for the record I really like VS Code, but I am not deluded.
Underpowered hardware for Electron apps runs giant IDEs for Java development with ten times the features just fine.
Which Java IDEs are these?
Eclipse and Android Studio are both monster IDEs
Also, while Intelij is better than Eclipse, it's a bit of a pig too. Not crazy bad like Eclipse was, but bloated enough.
What? You expect the VSCode maintainers to write up a lengthy explanation for why they have to mark every one of their 100k closed issues as closed? Are we really ascribing malice because they didn't do that once?
C'mon, can't we be above this sort of behavior?
C'mon, can't we be above this sort of behavior?
+1. It's reasonable for projects with large backlogs to do a quick prune with lower quality, either via manually or via tooling.
If something is particularly pressing, it will re-appear. It's not ideal, but neither is a large backlog.
If something is particularly pressing, it will re-appear. It's not ideal, but neither is a large backlog.
They didn't even ask for more details. They obviously didn't attempt to reproduce anything. They just closed the issue. The person who filed later noted that identical electron versions in earlier VS Code editions do not have the same problem.
This doesn't appear to be a tiny issue either. It is leaking quite a bit of memory rather quickly. They need to find where they're retaining references in one version, but not the other (that kind of thing is what MS pays them for).
This doesn't appear to be a tiny issue either. It is leaking quite a bit of memory rather quickly. They need to find where they're retaining references in one version, but not the other (that kind of thing is what MS pays them for).
Not sure the claimed behavior counts as a memory leak? As long as it will re-use the allocated memory the next time it needs it, it seems fine to not free up memory allocated? That's how many programs work. For example many `Vector` implementations will never shrink even if you use less memory, many apps and even allocators will store freed objects in a cache for later re-allocation, etc.
This .. also it's an issue of V8, not electron or vscode.
While I understand that such issues are frustrating, I really wish people would stop using HN as somekind of Internet cannon to spam these issues.
A memory leak is bad. Feel free to add a reaction to an existing comment, but spamming the issue thread is counter-productive and gives a sense of entitlement that feels really out of place on an open-source project.
A memory leak is bad. Feel free to add a reaction to an existing comment, but spamming the issue thread is counter-productive and gives a sense of entitlement that feels really out of place on an open-source project.
Years ago I was shipping a language learning app for high school students. It was aggressively cross-platform across iOS, OSX, Android and Windows. We made a big effort to make as much of the code platform-agnostic as we could.
The app had a lot of big video and audio assets split up across various modules. Each language had a bunch of different proficiency levels which each had their own content pack. All the packs together totalled something north of 5 gig so we allowed users to download and install the packs on an as-needed basis.
This fetching code was implemented using the HTML5 FileSystem API (which incidentally was deprecated by W3 halfway through the development cycle, but that's another story). This was great as it allowed us to have this code be completely platform-agnostic!
The only problem was that it had horrendous memory leaks. I was sure we had a bug in our JavaScript code somewhere. We spent A Million Years combing through heap dumps and reviewing our code trying to get to the bottom of it. We tapped contacts at both Adobe and Apple to try and help us figure it out and nobody could.
Until... Until we hit on exactly the correct google-fu to find a a bug report about memory leaks relating to file handles in the WebKit project. We updated our version of Electron and the newer version had a version of WebKit that contained the fix. No matter what strings we pulled, though, we couldn't get Apple to give us any information about what version they shipped on iOS or whether they were likely to incorporate the patch any time soon.
In the end it was moot because the global head office based in the UK got wind of the project and axed it because it might threaten _their_ cross-platform educational content packaging strategy. Which they'd been working on for something like 3 years. Which still hadn't borne any fruit. Nor did it look likely to any time soon. (But that's another story).
Memory leaks can be maddening. The problem is always with your code, it's never in the platform. Except when it isn't and it is.
The app had a lot of big video and audio assets split up across various modules. Each language had a bunch of different proficiency levels which each had their own content pack. All the packs together totalled something north of 5 gig so we allowed users to download and install the packs on an as-needed basis.
This fetching code was implemented using the HTML5 FileSystem API (which incidentally was deprecated by W3 halfway through the development cycle, but that's another story). This was great as it allowed us to have this code be completely platform-agnostic!
The only problem was that it had horrendous memory leaks. I was sure we had a bug in our JavaScript code somewhere. We spent A Million Years combing through heap dumps and reviewing our code trying to get to the bottom of it. We tapped contacts at both Adobe and Apple to try and help us figure it out and nobody could.
Until... Until we hit on exactly the correct google-fu to find a a bug report about memory leaks relating to file handles in the WebKit project. We updated our version of Electron and the newer version had a version of WebKit that contained the fix. No matter what strings we pulled, though, we couldn't get Apple to give us any information about what version they shipped on iOS or whether they were likely to incorporate the patch any time soon.
In the end it was moot because the global head office based in the UK got wind of the project and axed it because it might threaten _their_ cross-platform educational content packaging strategy. Which they'd been working on for something like 3 years. Which still hadn't borne any fruit. Nor did it look likely to any time soon. (But that's another story).
Memory leaks can be maddening. The problem is always with your code, it's never in the platform. Except when it isn't and it is.
The lack of a public explanation is bizarre, but surely there must be an explanation internally. Does anybody have any insight?
V8 having non-ideal memory compaction behavior for any given benchmark isn't something that the VS Code team has any amount of control over.
What makes you think that's the problem? And if it was, they could easily put a cap on this by telling people that's why it's out of scope
The memory usage doesn't grow indefinitely, it's not a leak. Opening a large file, closing it, then opening more smaller files doesn't cause further growth. If VS Code was holding onto old references from opening files:
A) It would be spotted immediately, opening files is core behavior for VS Code
B) The memory usage would continue to grow after closing old files and opening new ones
What this bug is seeing is memory fragmentation and/or reluctance by V8 to release a large allocation block. In either case, those kinds of details are way outside the arena of what VS Code deals with.
Importantly, it's also not anyone's job to explain this to random Github commentators or HN. If the maintainers say its not a bug or outside the scope that's the end of it, and if you don't like that you are free to use other software or fork the project for your own needs.
A) It would be spotted immediately, opening files is core behavior for VS Code
B) The memory usage would continue to grow after closing old files and opening new ones
What this bug is seeing is memory fragmentation and/or reluctance by V8 to release a large allocation block. In either case, those kinds of details are way outside the arena of what VS Code deals with.
Importantly, it's also not anyone's job to explain this to random Github commentators or HN. If the maintainers say its not a bug or outside the scope that's the end of it, and if you don't like that you are free to use other software or fork the project for your own needs.
The original filer stated that an identical electron version on older builds didn't have the same issue.
If it were compaction is there a good reason for this behavior?
This seems very much like they are retaining references somewhere instead. Thankfully WeakRef has shipped with newer Chrome/Firefox and should make some of these things easier to code around.
If it were compaction is there a good reason for this behavior?
This seems very much like they are retaining references somewhere instead. Thankfully WeakRef has shipped with newer Chrome/Firefox and should make some of these things easier to code around.
[deleted]
I would have marked this closed as well. Memory leaks are notoriously hard to track down. Unless someone takes the first dive with a heap profiler, and provides some proof there's a leak, I'm closing the issue.
Seems like a bot auto closed it before an actual maintainer responded?
I didn't notice before but you're right, it was a bot that closed it/commented. So this could just be a runaway automation problem.
vscode-triage-bot commented between bpasero marking it out of scope and bpasero closing it.
Tangentially related - Nova is a really solid modern alternative to VSCode and Sublime Text, as long as you're on macOS.
Some of the extensions have some ornery bugs, but the ecosystem is young yet. The basic editor itself is really nice.
Some of the extensions have some ornery bugs, but the ecosystem is young yet. The basic editor itself is really nice.
I tried it out during the beta stage, but the search was really slow and the code formatting was very weird on Python. Haven't really bothered to test it again after.
Probably because it’s an Electron issue, not a VSCode issue? How about we let them respond before freaking out
Where have they indicated that it's an Electron bug when closing the issue?
The time to respond was before closing the issue, which the submitter took significant effort to explain with reproducibility steps.
This is poor communication by the maintainers over what seems to be a significant bug; there may be good reason for it being considered out of scope - so it would seem to be more courteous and professional to give it.
The time to respond was before closing the issue, which the submitter took significant effort to explain with reproducibility steps.
This is poor communication by the maintainers over what seems to be a significant bug; there may be good reason for it being considered out of scope - so it would seem to be more courteous and professional to give it.
Well, they closed the issue 21 days ago... if that’s the case, they could at least add a comment to that effect.
SublimeText's author single-handedly supported windows,macos and linux from the start, what was Microsoft's reason to choose electron? I have never used ST and Microsoft probably picked electron to capture the huge web development market and also provide a cloud IDE for it's cloud offerings, but it's worth noting that vscoded is touted as an "exemplar" electron app only because a big well funded team is doing thousand and thousands of micro-optimizations all the time full time.
I guess there are two types of software. Scrivener 3 macOS version was released in 2017. The original plan was to release the Windows version at the same time, but they couldn't get it quite ready. They have been trying to release the Windows version for the past 3 years. And in all likelihood, it is another year or two away.
Didn't they buy VSCode? Or Fork Atom early on or something?
(Update D'oh they got Atom with Github long after VSCode)
(Update D'oh they got Atom with Github long after VSCode)
Microsoft initially added Intellisense to Atom and called it VSCode. It was not great, but better than Atom.
Then VSCode got really good for an Electron-based app. It's still the quintessential Electron app, even if it trips over things like this now and again.
Then VSCode got really good for an Electron-based app. It's still the quintessential Electron app, even if it trips over things like this now and again.
It's funny, because Electron was literally invented for Atom (note the wordplay!). I was a long-time holdout for Atom; I didn't want to ditch the original for the Microsoft takeover. But eventually I had no choice but to relent. Atom just got really sluggish once you had a few plugins running, and VSCode runs like a dream.
My speculation is that it had to do with the plugin architecture. Atom was very open-ended; writing a plug-in there, even an intellisense one, was more like writing a browser extension. Your code could just do whatever it wanted, including (easily) step on the toes of other code operating alongside it. You could literally have multiple different plugins implementing an intellisense UI, and then different language plugins would depend on different ones. And then they'd draw over each other, etc. VSCode on the other hand, a) includes lots of frameworks like a debugging UI and an intellisense UI out of the box so that there's a common standard, and b) exposes clean and clear APIs for common stuff, enabling extensions to be much more cooperative with each other and with the editor itself (which not only avoids conflicts, but improves performance too). It's like the iOS app philosophy vs the Android app philosophy.
My speculation is that it had to do with the plugin architecture. Atom was very open-ended; writing a plug-in there, even an intellisense one, was more like writing a browser extension. Your code could just do whatever it wanted, including (easily) step on the toes of other code operating alongside it. You could literally have multiple different plugins implementing an intellisense UI, and then different language plugins would depend on different ones. And then they'd draw over each other, etc. VSCode on the other hand, a) includes lots of frameworks like a debugging UI and an intellisense UI out of the box so that there's a common standard, and b) exposes clean and clear APIs for common stuff, enabling extensions to be much more cooperative with each other and with the editor itself (which not only avoids conflicts, but improves performance too). It's like the iOS app philosophy vs the Android app philosophy.
Atom doesn't have intellisense. And the only thing in common wit VS Code is Electron (used to be called Atom Shell)
No. They had an editor called Monaco written in javascript for Visual Studio Online. That they decided to make standalone.
So, everyone is discussing the merit of VSCode instead of the bug in question; given this, I, too, shall give my opinion: if I want an extensible, portable, good text editor that has a great community... I'm just going to use Vim. Hell, I even abandoned my 20 year old config just to go use SpaceVim because of how great the community is.
If I want an IDE that is designed for a specific language? I use IntelliJ for Java/Kotlin projects, Visual Studio for C#, and nothing else really needs an IDE (as in, IntelliJ's siblings based on the same core IDE? I don't really benefit from them).
Where I see VSCode being used the most? Among non-programmers, programmers of beginner languages (Python, Javascript, et al), or among younger programmers that haven't taken the time to learn more ergonomic editors.
I also see it being used among some C/C++ and C# programmers... but I don't get the point, VSCode doesn't even really understand a lot of IDE concepts, for example: it doesn't understand the difference between a workspace and a project, yet gives people the obvious footgun of multi-root projects in the form of a workspace-by-name-but-not-by-concept.
I tried VSCode for like three days, and seriously cannot understand the draw of it for its advertised purpose (Visual Studio Lite), when its really just a code-oriented text editor, and Vim will always be more ergonomic for that purpose (assuming, of course, you're willing to learn how to be ergonomic).
Edit: Also, a lot of VSCode and Atom fans bring up LSPs: I can use those from Vim.
If I want an IDE that is designed for a specific language? I use IntelliJ for Java/Kotlin projects, Visual Studio for C#, and nothing else really needs an IDE (as in, IntelliJ's siblings based on the same core IDE? I don't really benefit from them).
Where I see VSCode being used the most? Among non-programmers, programmers of beginner languages (Python, Javascript, et al), or among younger programmers that haven't taken the time to learn more ergonomic editors.
I also see it being used among some C/C++ and C# programmers... but I don't get the point, VSCode doesn't even really understand a lot of IDE concepts, for example: it doesn't understand the difference between a workspace and a project, yet gives people the obvious footgun of multi-root projects in the form of a workspace-by-name-but-not-by-concept.
I tried VSCode for like three days, and seriously cannot understand the draw of it for its advertised purpose (Visual Studio Lite), when its really just a code-oriented text editor, and Vim will always be more ergonomic for that purpose (assuming, of course, you're willing to learn how to be ergonomic).
Edit: Also, a lot of VSCode and Atom fans bring up LSPs: I can use those from Vim.
I dunno man. Like you, I use vim for lighter text editing tasks and JetBrains stuff for times I need to get serious. Your comments make me think that maybe you haven't spent enough time with vscode to appreciate it though. I think for a lot of folks its a really good middle ground and I am pretty sure MS's long game on it is as a replacement for Visual Studio (that might be projection though. I've always hated that IDE...).
I guess I am saying that its a perfectly valid choice as a ones primary editor. I used it for a couple years and I have nothing but good things to say about it. I just happen to prefer vim + Intellij (with vim keybindings of course!!) :)
I guess I am saying that its a perfectly valid choice as a ones primary editor. I used it for a couple years and I have nothing but good things to say about it. I just happen to prefer vim + Intellij (with vim keybindings of course!!) :)
> I am pretty sure MS's long game on it is as a replacement for Visual Studio (that might be projection though. I've always hated that IDE...).
I hope not, at least unless VS Code improves heavily
I mean, the real VS has its flaws and is giant, but it has times more reliable intellisense and stuff than VS Code
I hope not, at least unless VS Code improves heavily
I mean, the real VS has its flaws and is giant, but it has times more reliable intellisense and stuff than VS Code
I've heard it both ways from both VS and VSCode users, both claiming their Intellisense works better. Most likely, they just implement a different set of features, and the best outcome would be one IDE that is a superset of both.
You're actually partly right: Microsoft has said they're going to replace the native VS editor with VSCode's editing element. VSCode as an editor seems to be a better editor than VS's editor, so clearly VS can only get better, but the answer isn't replacing VS with VSCode entirely.
what, what? any source where Microsoft said it?
That would be great though. Visual Studio then would finally get proper multi cursor support.
That would be great though. Visual Studio then would finally get proper multi cursor support.
I stuck with it until recently I found out how to configure VIM to do TypeScript code completion, refactoring, auto-imports, and goto definition. Every once in a while I pop into VSCode to refactor a file rename or some other little piece which I haven't figured out in VIM yet, but I don't miss the CPU and memory abuse a bit.
(Note: I suspect if I invested the same amount of time into Sublime, I'd have equally good results with fairly decent performance as well)