It’s probably because it isn’t laggy or cluttered for many of us. I do think its usefulness depends a lot on which tools you’re working with and what sort of VSC plugins are available for them.
One or the things we really like about VSC is how “easy” you can “enforce” opinionated coding styles and tool setups through sharing the .vscode configurations directly in your repositories. We’re not too fascist about it. The opinions are semi-democratically decided and you’re free to override them to some degree. But because our deployment pipelines are in fact fascists, it’s very helpful to have those “global” settings at times. Like when we’re onboarding new developers, or when we’re using external consultants. Because it lets anyone just jump in and build code the way everyone else does.
Now, from the sound of things getting your VSC groove on with Ruby isn’t as easy as it is with something like Typescript. Which leads me back to the thing about tooling. Because VSC is certainly better for some things. Even something like C# which is getting good in VSC, is still “better” in VS. You’re probably very likely to use VSC for C# as VS sort of sucks, in our team only one person is still clinging on to VS as an example, but it all comes down to support.
Now, my VSC isn’t slow or laggy, but it can be. I have a couple of extensions that are just horrible for performance, but I tend to turn them off any time I’m not using them to avoid this. Similarly you’re going to need to know your way around the settings to get it to really fit your needs and you’re probably not going to have a good time if you sort of “google” configure your VSC because many of the guides are absolute trash. As it is with many things, it’s very hard to tell the trash from the gold, so the only way will often involve reading the manual. You can get away with not doing that for most usage with common languages, but for power use you’re eventually likely to have to dig into Microsoft’s horrible documentation.
One or the things we really like about VSC is how “easy” you can “enforce” opinionated coding styles and tool setups through sharing the .vscode configurations directly in your repositories. We’re not too fascist about it. The opinions are semi-democratically decided and you’re free to override them to some degree. But because our deployment pipelines are in fact fascists, it’s very helpful to have those “global” settings at times. Like when we’re onboarding new developers, or when we’re using external consultants. Because it lets anyone just jump in and build code the way everyone else does.
Now, from the sound of things getting your VSC groove on with Ruby isn’t as easy as it is with something like Typescript. Which leads me back to the thing about tooling. Because VSC is certainly better for some things. Even something like C# which is getting good in VSC, is still “better” in VS. You’re probably very likely to use VSC for C# as VS sort of sucks, in our team only one person is still clinging on to VS as an example, but it all comes down to support.
Now, my VSC isn’t slow or laggy, but it can be. I have a couple of extensions that are just horrible for performance, but I tend to turn them off any time I’m not using them to avoid this. Similarly you’re going to need to know your way around the settings to get it to really fit your needs and you’re probably not going to have a good time if you sort of “google” configure your VSC because many of the guides are absolute trash. As it is with many things, it’s very hard to tell the trash from the gold, so the only way will often involve reading the manual. You can get away with not doing that for most usage with common languages, but for power use you’re eventually likely to have to dig into Microsoft’s horrible documentation.