5 ms·
In some sense, this ought to be an opportunity. VSCode’s ecosystem is, in many respects, quite weak: - cpptools is kind of amazing but also pretty bad. It reg
by amluto 2y ago
In some sense, this ought to be an opportunity. VSCode’s ecosystem is, in many respects, quite weak:
- cpptools is kind of amazing but also pretty bad. It regularly malfunctions for me. It’s essentially undebuggable. I have less experience with the other extensions, but I don’t expect that they that much better.
- The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
And that second point is a big deal. Maybe when poking at your own company’s code, you aren’t that concerned about your repo attacking you. You probably should be concerned about malicious extensions, but we’re all far too used to trusting dev tooling. (Don’t forget that MS’s extensions are just this side of malicious.)
But, with AI, you should absolutely not trust your LLM. It is entirely unsafe to give an LLM that might try to exploit you the ability to write into your repo directly or to run JS code in the context of any portion of VSCode. And it’s really quite easy to convince LLMs to engage in all manner of shenanigans.
There’s an opportunity to make a better ecosystem. In a better ecosystem, the equivalent of cpptools would not have telemetry, because the equivalent of cpptools would not have Internet access. It would have the ability to read the workspace, to create cache files for its own data, and to operate its UI, and that’s all.
- tjoff 2y agoThe clangd extension is much better for me, assuming that you have or are able to generate a compile_commands.json (at least easy in cmake) and point clangd to it.
- chpatrick 2y agoI agree VS Code + clangd is probably the best C++ development experience I ever had.
- theptip 2y agoHow does it stack up vs. CLion?
- chpatrick 2y agoCLion was what I used before and it was way clunkier than VSCode with clangd. Complicated libraries like CGAL just weren't usable for auto-complete, but were instant with clangd.
- eulgro 2y agoIt doesn't, CLion is way better.
- chpatrick 2y agoI used CLion before I switched to clangd + vscode and it was orders of magnitude slower.
- tcbawo 2y agoWhat does it do better?
- okl 2y agoOne problem I always had with VSCode, is that it seems to fill up its autocomplete suggestions with "near-string-matches" from files all over the project. The jetbrains tools are quite strict in that regard and won't propose random string matches that don't fit semantically.
- digitaltensor 2y agoThat doesn't sound right. clangd should (and does) only suggest semantically valid suggestions. It's also much faster than the CLion's own C++ engine, though that might change with CLion Nova.
- txdv 2y agoI recently tried clangd with nvim and it was so good
- ReleaseCandidat 2y agoThere are generators for the compilation databases that work with Makefiles and other build systems, like Bear: https://github.com/rizsotto/Bear https://github.com/rizsotto/Bear
- Ragnarork 2y agoCame here to suggest Bear as well, very handy piece of software to generate the compilation database in a mostly tool-agnostic way.
- ReleaseCandidat 2y agoYes, their C++ LSP isn't really good and I've heard C# isn't good either - but that's because they want to sell Visual Studio too. But especially "Remote SSH" and "Dev Containers" are so called game changers. And their Typescript and Python extensions are actually good.
- easton 2y agoLately they've begun embedding the same C# analysis stuff they have in VS into VSCode if you pay for the license. I haven't used it in anger (long since left for Rider), but it has come in handy when troubleshooting people's VS issues at work from my Mac. The test explorer now blows up in exactly the same way in VS and VSCode :)
- neonsunset 2y agoC# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) itself - this is what the base C# extension[1] uses. Both of these are licensed under MIT. The closed-source part is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2]. [0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServer https://github.com/dotnet/roslyn/tree/main/src/LanguageServe... [1]: https://github.com/dotnet/vscode-csharp https://github.com/dotnet/vscode-csharp [2]: https://github.com/muhammadsammy/free-vscode-csharp https://github.com/muhammadsammy/free-vscode-csharp (please consider giving it a star, it's the only actively maintained alternative and other tools end up relying on it downstream to support debugging - VSCodium as well as Emacs and Neovim with VSC extension bridges)
- monsieurbanana 2y ago> The client, accessing remote repos, is wildly insecure, by design Who's the best kid in the block regarding third-party extensions security? There's really not much standing in front of a supply-chain attack for my editor of choice, emacs. Most people use a community extensions aggregator that also directly fetches from git repositories. The only slim advantage we have is that I'm sure a much higher % of emacs users would actually look into the source code of the extensions they pull.
- alexhutcheson 2y agoIf you want to be cautious, I have somewhat higher confidence in the versions of Emacs packages published on the Debian repositories[1] than the ones on ELPA/MELPA. The downside is that not every package is packaged for Debian, and the versions are a bit stale. https://packages.debian.org/search?keywords=ELPA+&searchon=names&suite=stable§ion=all https://packages.debian.org/search?keywords=ELPA+&searchon=n...
- monsieurbanana 2y agoThat's a bit of an understatement, about 1% of all emacs packages are in there :)
- amluto 2y agovscode tunnel is already a massive step up from vscode remote SSH here.
- tikkabhuna 2y ago> - The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design. This is a big concern for our Infosec team. There is no middle ground between open access to every Extension on the marketplace or locked down and Extensions are installed via local files. The latter being a significant overhead in maintaining VSCode.
- spacemanspiff01 2y agoCan't you host your own extension marketplace?
- doubled112 2y agoThen you have other problems. Maintaining the store itself, obtaining the extensions people want, and keeping the extensions up to date adds some overhead. Looks like it should be possible, although I have no experience doing it myself. https://github.com/coder/code-marketplace https://github.com/coder/code-marketplace
- phillipcarter 2y agoSounds like that's the price your org is willing to pay for your its flavor of Infosec.
- EasyMark 2y agoAll these same things are true for emacs/vim/CLion plugins as well. You kind of either have to accept the risk cowboy style, do something in the middle (maybe only allow very well known extensions from source you trust), or live without the extensions.
- diggan 2y ago> Extensions are not sandboxed This is quite surprising to me if true. Microsoft has for years touted "Security is everything and the single most important thing right now", yet something that basic is not taken care of for the most security minded audience, and for the audience with probably the biggest impact in case ssh-keys and alike gets stolen? People randomly installing extensions (and Visual Studio Code suggesting random extensions by "language support") starts to look a lot worse than I thought. Guess I'm lucky I never jumped aboard the Visual Studio Code train...
- Sayrus 2y agoExtensions often rely on third-party binaries (such as Language Servers, kubectl, ssh or even git itself), internet access (SAAS providers, pulling data or definitions, ...) and on your filesystem (SSH Config, Kubernetes config, Config folder in your home, ...). Sandboxing these extensions is not easy unless everything is configured within VSCode which is rarely the case. As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.
- miohtama 2y agoPlease correct me if I am wrong but the only application (class) that currently sandboxes extensions is a web browser. So the bar is pretty high. Sandboxing does not come for a free, as it creates more complex development APIs and a performance hits.
- dumbo-octopus 2y agoAnd happily VS Code runs in the browser (vscode.dev, github.dev) if you do choose to make that security/performance trade off at some point for some reason. And with sync you can have all your UI extensions and keybindings ported over under the covers.
- essentia0 2y agonot only UI extensions. for some time now extension developers can opt in to provide browser worker targeted bundles for their extensions.
- sevensor 2y agoVSCode also, by design, obscures what’s really going on on the development environment, so that when I help a VSCode user who gets stuck, they often don’t know what computer they’re logged into, where their files actually are in the file system, which Python interpreter they’re using, what HTTPS_PROXY is set to, and so on. The ssh extension also spins up a server process for every client a user connects, and it seems a bit inconsistent about preserving state across disconnections. All in all, I spend a lot of time helping people fix problems they’ve made for themselves by using VSCode.
- spencerchubb 2y agoWhat kind of set up do you use? This does not resonate at all with my experience of vs code
- zdragnar 2y agoPresumably, this is talking about some remote devcontainer configuration. None of that really applies to using vscode locally, at least not any more than any other editor.
- shaklee3 2y agoThe bottom of the screen says exactly what you're connected to, so I'm not sure what they're referring to.
- slowmovintarget 2y agoA wild Emacs appears...