The software you mentioned were pioneers in their category. On the other hand, VSCode had the benefit of learning from the many IDES in the saturated market that came before it. If VSCode was one of the first IDE it would not look anywhere near the same because it wouldn't be able to lean on the lessons of past IDEs like it does today.

Dunno, just getting VSCode to run and debug a project requires manually editing cryptic config files which is what almost any IDE does much better...

Indeed; while VSCode is held up as the "best ever IDE for everything, period", what those people gloss over is that they are web devs, not C++ hackers who need to be able to easily build projects (and have good, reliable syntax highlighting and autocompletion). In the rare occasion that I use VSCode for C++ development, I just use cmake from the built-in terminal because I really don't think VSCode is designed to build C++ projects.

VSCode is not tied to a specific language so the job of handling config files is left to the extension. Not every language has a fixed project structure so I think the major extensions have kept structure-dependent things out. In C++ for example there are CMake projects and GNU Makefile projects. Not sure why such extensions haven't bubbled yet. Other IDEs have their own fixed project structure and a project config file specific to their IDE. This means running and debugging is easier in their IDE if your project works in the specific way intended by the IDE, but this locks you to their IDE.

By your logic Sublime is an even higher feat of engineering since it made even better engineering decisions.

Ultimately they’re both very fancy text editors, not ‘the greatest feat of modern software engineering’.

I’d happily switch from Sublime to VScode or EMacs or any of the other umpteen code editors. I’d shudder to have to go back from Git to SVN. Even Mercurial seems milquetoast in comparison.

Similarly, what about the Linux kernel?

What about C?

> I’d shudder to have to go back from Git to SVN.

What are some of the Git features that make a big difference to you? I use them on different projects and I end up using them both in the same very basic way (check out code, make changes, check code in).

All git operations are several times faster than their SVN counterparts, and git is more storage efficient as well. This becomes especially relevant for larger repositories.

local commit

Merging. Sure you can “branch” on svn but you merge at your own risk.

Subversion merging has mostly been fixed. I haven't really noticed much difference between the two systems.

One place where Subversion historically did better with respect to merging is avoiding merging by allowing you to lock files. We use this with some binary files in our repository. About a year ago Git added similar functionality but I haven't had the chance to try it yet.