It's proprietary software masquerading as open-source, for one, and intentionally fosters dependence on its vendor for the plugins that support the most popular languages as well as key features (remote editing, WSL support, integration with the mainline plugin repos), for one.

But Cursor, a fork not developed by Microsoft, ships with remote editing, wsl support, etc

It's their reimplementation.

That’s not what that word means

They do indeed use a different implementation of these features than the one that ships with VSCode, though they're not the original authors of it. They used to host their version separately here: https://github.com/anysphere/open-remote-ssh

But I guess they've just rolled it into the Cursor repo? Idk, because Cursor itself is proprietary.

There's a similar extension for WSL integration, though I'm not 100% sure if Cursor's implementation of this feature is based on it: https://github.com/jeanp413/open-remote-wsl

You can sideload proprietary VSCode extensions to add them to VSCodium or some downstream fork, but you may also have to patch the extensions themselves because some of them refuse to run if they aren't being used with Microsoft's VSCode: https://github.com/OliverKeefe/vscode-extensions-in-vscodium

Care to elaborate? I was under impression they built cursor-server themself

Microsoft injects proprietary spyware into the official builds that you can't see from the source code. You can get unofficial builds of just the source code from the VsCodium project, but Microsoft blocks your ability to install a lot of extensions if you don't use the official build.

It’s clumsy as hell. It’s neither a good editor, which focus on being fast when doing things with text, nor a good IDE, which is more about the tooling and getting a project done. It’s trying to be both at the same time. And the result is bad at both.

I don’t know, others might be better out of the box. But once you start adding features they all become a mess. I rather just deal with a known mess and not waste time with tools.

I have nothing against VSCode but I don’t use it.

For small files and quick edits i use neovim with no customisation at all. Back when I first started using vim I had a pretty long config and some plugins installed and so on. But now that I no longer try to use it as an IDE, neovim is perfect for small edits.

For development work I use JetBrains suite of tools. Very minimal amount of customisation there also, only a couple of extra plugins installed by me and a couple of changes in the settings. It works well enough that I don’t have any desire to spend time customising it a whole bunch.

Don’t get me wrong, I loved neovim and other tools but tbh I just nano for simple edits now. AI tab complete is just too good. Basically it’s barebones or VSCode (or its variants). I could probably use vanilla neovim instead of nano but I've not used vim all that much recently to be in that "flow".

This is like saying: I can write Swift code using Vim instead of Xcode. Yeah, you can, but that doesn’t mean you should.

Note: I use nano/vim daily to read and edit files on my servers. Just not to build complex apps.

Your point is good, I don't mean to undermine it, but because I work in this area I feel compelled to point out that depending on the type of Swift you're writing using NeoVim to write Swift is actually quite pleasant: https://www.swift.org/documentation/articles/zero-to-swift-n...

I'm hoping one day to move from a GUI to a VUI (Voice User Interface), though I still have a soft spot for TUIs. Thanks for the link :)

I'd waste time with tools. I have my vim config, my git config, my emacs config, my bash config,... that I copy over to any development environment I have. And every now and then, I go into the manual or other people config to check if there's any new trick I can apply.

Comfort is something invaluable when doing a task. I can accept discomfort when I'm in an unfamiliar environment, but not when it's going to be something I will be in for days.

Perhaps the difference is that VSCode and plugins change too often and requires too much maintenance?

Ultimately, they're about as trite as reasons to hate Vim or Emacs. It boils down to preference, and I'm outlining a path to using another editor and getting access to some of the same features.

Each time I try to use it, I find myself distracted by the impulse to fix the bugs that I notice. There's always this moment when I find a comment from myself, several years earlier, in an issue that's still open because it's unclear whether it's a VSCode problem or a plugin problem, and it's like: "oh, here I am again, doing this instead of working".

That's not to say it's especially buggy, it's just so large, there are a lot of places for bugs to hide.

I get distracted by the impulse to contribute to other editors also, but those are contributions that I'm happy about. They don't always result in bugs fixed or features added, sometimes somebody says "no" but at least it resolves in some way. With VSCode it feels like I'm going in circles.

I personally feel some inner sense of dissonance when I use software written in Electron when alternatives are available. Software targeted to the technical audience has no valid reason not to aim higher in terms of performance and fundamentals.

I will give you one reason why I don't like it much:

- The push to use Github Copilot and no option to disable that crap.

I wish there was a fork of VSCode with all the telemetry and all of the proprietary crap disabled with 100% extension support...

I do not hate it when others are using it (none of my business). But I do not like to use bloatware. Text editor that eats RAM (even excluding LSP) like 3d editing software.

Microsoft ?

Through the use of amazing PR they have made people forget about their Embrace, extend, and extinguish strategy with open source.

GP went on to recommend Microsoft devcontainers, so I presume that's not the reason.