Visual Studio Code 1.30 Released

Hi, I'm part of the VS Code team. We have a page on our wiki that describes in a fair amount of detail how we structure iterations: https://github.com/Microsoft/vscode/wiki/Development-Process

I work at Microsoft. Generally, here, we have a relaxed philosophy towards approaching things. No pressure cooker environment. Don't feel like going to work? Stay at home. Because it's not shoved down your throat, you develop a particular affection towards your work, and when it gets to crunch time you put your head down and work because you actually want to. I can't speak for every team, but that's the general state of affairs.

It would be interesting to see a case study of this, as well as how the interaction with the public community, and collaborators has worked. I do know that some pieces do burrow from the larger community, and it's interesting even what you can glean from GitHub alone.

They seem to coincide closely with the release cycles of Visual Studio proper. I wonder if both teams (or the same team) are within similar disciplines.

Give Emacs + Tramp a shot. It might be what you are looking for.

sshfs can sort of make this work. It's not ideal because builds etc are still local.

On specifically startup time for large files (narrow use case, but thats what we got), there's this comment from user jakear from a while back on an Atom 1.28 thread [1]:

1.1GB file, 10M lines.

Code: ~10s, smooth scrolling, instant jumping.

Sublime: ~50s, smooth scrolling, instant jumping.

Atom: ~10s, smooth scrolling, very choppy jumping: ~5s loads per jump (also got some error messages about text too large for buffer)

1.0GB file, 40k lines.

Code: ~15s, scrolling somewhat choppy, quick jumping

Sublime: Application not responding after ~60s, waitied another 60s, no change. Same behavior each of the two times I attempted.

Atom: ~8s, smooth scroll, ~30s per jump, occasional "Editor is taking too long to load" messages.

Note: Atom enforces a maximum line length of ~500 chars before it wraps regardless of word wrap setting. This means the 8s load was only showing a couple lines worth of content. I find this restriction not acceptible for the long-line test case, but including anyways for completeness) Full "report": https://pastebin.com/wUv8PSgp

[1]: https://news.ycombinator.com/item?id=17369898

At home, I'm on an i7-4790K, my work laptop is an i7-8650U, so ymmv.

I've never found Code to be particularly slow, and will generally load in a couple seconds. I tend to have it open most of the day on the project(s) I'm actively working on. The benefits of the integrated terminal alone probably saves me more time than I ever spend waiting for it to load. It's always been very responsive in the application, and worst case scenario I've had is on occassion the syntax highlighting or context auto-complete may have a delay. But that doesn't stop me from being able to continue typing by hand and is generally as good or better than Sublime.

The extensions are all around REALLY nice to have. Being able to add support for more languages via extension has been great, what little I've used of that. And the integrated debugger has been very usable when I've used it. Git integration and Diffing could use a bit more work, but that's true of even dedicated Git applications.

I've really been beyond appreciative of the iterative improvements as well. Every release I notice something that I like in the release notes. I will say I did like the old open-docs layout more than the Tabs once I had gotten used to it. It still works okay, but I didn't appreciate that one regression in behavior. But most were more used to tabs, and I understand the resistance.

The thing that sucks, in my experience, is that the "fastness" of a text editor doesn't translate into productivity the way the abundance of plugins and support and popularity will. But the slower ones just manifestly feel so irritating once you're used to the speed.

I moved from WebStorm to VS Code and haven't looked back. Code is generally faster than any IDE I've used (at least for JS work). My understanding is the Go support is very good. No idea on Python. There should be extensions for both that should be easy to install.

Code has become hands down my favorite editor. I don't use the debug often, but it's passable. Just depends on your needs and use. I'd suggest giving it a try for a couple weeks (just to get past any initial pain points).

I do my JS in VSCode, but I don't think I can ever walk away from PyCharm. I feel spoiled by it.

Outside of using VSCode for JS and Typescript, I use it as a catch-all. If I don't have a better preference, then VSCode usually handles it well enough.

I've actually migrated to it from emacs for rust stuff - the RLS integration is really nice and it works well enough on both osx and linux.

I tried to use the git UI that it provides, but in the end preferred to manage my vcs from the terminal.

I'm reasonably happy with it - and I didn't think this was going to be the case when I first tried it out.

I don't write JS but there's a lot of extensions for it, related libraries (React, Angular, Vue, etc) and languages that compile to JS (TS).

There's also keymap extensions to emulate keybinds from other IDEs. You should try it at least.

I use IntelliJ on all languages I use on Mac but VSCode's font rendering is more natural and better. There's something weird about Java's rendering implementation for not being crisp.

And VSCode doesn't take 30s to launch.

I have been using VSCode with the Golang extension for around 2 years now and have been exceptionally satisfied with it.

I did use the JetBrains Goland for around 3 months since I heard some praise from my co-workers but found that it'd didn't contribute much.

The debugging works as well in VSCode as it does in Goland but yes, delve (the debugger backend) crashes sometimes when debugging goroutine heavy code.

Completions, refactorings, renames, linting and goimports all work flawlessly.

Would seriously recommend VSCode + Golang.

For JavaScript and family VSCode is the best from what the Frontend team in my organisation tells me.

I use it for Go, easy to set up and feels awesome.

Are there specific features of Atom that aren't in Code? It seems that Code could likely add some of the features missing that are in Atom easier than trying to merge them, or go the other direction.

Why is that necessary? I like the incremental approach they have been taking so far.

This isn't just something where you should go "oh, well, guess I'll switch". Please report such issues, and try to debug what is going on because it sounds like it might be a problem with your computer in general.

I don't know why you're getting downvoted. I can't stand these Electron apps, let alone a text editor that I'll write my code in.