I'm not saying you aren't having real problems, but they aren't common and they can appear in any editor -- I used to fill vim with plugins and it would hang frequently.

I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for projects that are literally 100 times smaller than the C++ project I’m working on.

I don’t really buy the anecdotal ‘other developers never have any problems with VS code’ observation. I’ve been following the VS code release announcements here on HN for a while (it’s what got me interested in trying VS code), and they regularly seem to contain fixes for weird platform problems or regressions, to the point they’ve even had to retract a few of them because of serious problems found after deploying the update.

I am actually the opposite of you: totally thankful for JS and electron, and I think they are the best possible future for apps.

To be honest, I really think people have an emotional reaction to JS/Electron one because it's seen as a threat to their preferred language, and two because it has all this built up hate due to legitimate past problems. A few years of pretty hectic pace in JS-land and now it's close to greatness, but still very inconsistent, so people still love to hate it. Couple that with some poorly made apps (looking at you Spotify/Slack) and you have a weird sect on HN that now vilifies Electron/JS with totally incorrect arguments about stability and speed (both are very doable with modern practices).

I'm not saying you are this person, or your grievances aren't real. But I'd be happy to put some money on the following points:

1. Electron/JS apps will be more prolific in the next 5 years

2. They will also be clearly the best platform for speed, stability and flexibility due to massive and ever improving ecosystems and dev tools.

Both have been happening, and to be honest, today we're at a point where I think it's a no-brainer to choose JS for just about any complex UI. The problem is you're wading into a fast-changing, diverse ecosystem, and a few wrong choices there can be very painful.

Javascript? Sure. Electron? Maybe not. Show me an Electron app with load times that aren't measured in seconds. Or an Electron-based text editor that doesn't choke on a moderately sized text file. VS Code is currently taking half a gig of ram on my notebook with three text files open...

I happen to quite like VS Code, but to claim that Electron is a no-brainer is simply false. There are serious tradeoffs.

I work in the VS Code team - the experience you are having is not the experience we aspire to. It would be great to dig into this a little more and see what we can learn.

Perhaps the easiest way to have a deeper dialogue is via a GitHub issue. The easiest path to creating one is leveraging 'help->report issue' that will include some additional context that will help us dig in a little more.

In particular, ESLint and the Go extensions randomly cause problems for me. I often lose JS autocompletion and linting; no errors, just stale or missing markers and only fix is to restart the window. Often the Go completer or "go vet" or whatever goes bananas and gets stuck taking 100% CPU. Often a random "Code Helper" sits taking 100% CPU for no discernible reason. Sometimes the Helper mysteriously gets better after a few minutes.

I can always work around these issues by restarting stuff. The main problem is that I can never report anything cogent based on this misbehaviour, because I have zero visibility into what is causing them; for example, as far as I know VSCode doesn't have a "task list" for its async operations (such as indexing, linting etc.), so there's no way to correlate misbehaving child processes with those operations like you can do in Chrome. I once submitted a Github issue with dumps (macOS process traces) when a Code Helper process had sat at 100% for an hour, but the VSCode team said it wasn't helpful, but they also didn't offer any way to actually trace the problem. There are also no logs as far as I can tell.

Admittedly, often it is extensions or external tools that misbehave, not VSCode, but the above remains true -- without any visibility there's no way to fix.

For all that, VSCode is the best IDE I have had since I was a Java developer using Eclipse around 2006 or so. VSCode doesn't quite reach that level of integration (for example, Eclipse had instant incremental compilation built in, whereas in VSCode linters are for some reason dumb and stateless and have to potentially look at your entire project every time you make a code change, which is the opposite of instant), but it's getting there.