Visual Studio Code 1.9
code.visualstudio.com
code.visualstudio.com
The Microsoft-developed Go plugin makes it the best Go IDE out there, the devs, (Ramya Rao etc.) are super responsive and really trying to resolve issues quickly.
If you haven't tried it yet, I think you really should and if you have found a problem, open an issue at https://github.com/Microsoft/vscode so the devs know about it, complaining doesn't help making it better. They generally release every month, so it will get fixed sooner rather than later.
P.S. Kudos to the team & contributors for another awesome release!
At the top of the read me is the feature list for the vscode-go:
https://github.com/Microsoft/vscode-go
This is the feature list for vim-go:
https://github.com/fatih/vim-go
looks a little longer, but if you notice they both use the same back end tools. I see that VSC has partial delve integration, but vim running inside tmux makes delve (and every other CLI tool) feel like it's already integrated. I don't use debugging that much with Go though.
I will respectfully disagree and say that gogland (while still in a pre-release state) is much much better.
There is also the fact that VSCode is open-source.
I wonder how much Microsoft spends on it each month, and what value they see in it? Is it just a marketing expense? e.g. They fund VSCode in order to gain the good will of developers which they hope will turn into Azure or maybe Windows sales in the future?
> VS Code supports tasks that you can configure to build your application, and natively understands the output of MSBuild, CSC, and XBuild.
(To be clear I'm asking what workflow users use personally, since it seems like nobody else has this issue.)
There's a big JSON file with the debug configurations, and a drop-down to allow you to select which one is active. Each gdb debug configuration lets you specify the usual binary path and command line arguments, plus a whole lot of other configuration I haven't looked at. I haven't had to do any project-style setup --- it just magically finds all my source files.
It looks like it supports gdb on Windows and Linux and lldb on OSX (only ever tested on Linux, though). Out-of-the-box you get sample configurations to both run and attach to a C/C++ binary.
gdb integration is pretty seamless; breakpoints, conditional breakpoints, stack traces, local and global variables. Haven't seen threads, watchpoints, or an assembly window yet. There's a debug console, but entering commands doesn't appear to send them to gdb.
It's one of the best Linux gdb environments I've seen (even though most gdb integrations are terrible).
If you attach or launch more than one process, that's where they will appear also, as top-level tree nodes.
Samsung and Asus ones seem to have been the surviving brands and even they have Win10 devices on their brand sections.
Or the fact that all new APIs are mostly UWP only?
That could just be a regional anomaly.
On the other hand, speaking about regional anomalies, I almost never seen Chromebooks on sale, or people using them. Yet they apparently sell like hot cakes in US.
Jokes apart, I have noticed that in developing countries (I regularly visit Thailand for example) Android tablets are still more common than Win 10 ones, I believe it's because in those countries many people were first exposed to computing in the form of a smartphone, so they prefer a mobile OS like Android, whereas in the western world most people (except perhaps very young people) were accustomed to use a personal computer long before they even had a smartphone.
One interest small piece of the larger puzzle is that the Monaco text editor at the heart of VSCode was originally built for Azure and Visual Studio Team Services cloud editing. It was then also subsequently embedded into IE's Dev Tools (and now Edge's Dev Tools). It's a neat example of building a tool for several existing needs embedded into existing products/projects and then finding that the same tool was also interesting as the core to its own product.
I've just seen most comments referring to it as an IDE.
It has refactoring, and revision control integrated. You can compile and run code, you can set breakpoints and step through execution. That's waaaaay more than just an editor.
It has has debugging and task running, after all. Sounds a lot like an IDE.
I wonder what someone coming from an earlier era would have to say on that...
Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs.
So, even Microsoft doesn't think it's a full blown IDE. With enough plug-ins it certainly could be.
Or maybe put differently, IDE's are enterprise software, editors are agile startups?
For example, I use Ctrl+D for multiple editing all the time and I converted other people to vscode based on that feature alone, yet it does not exist in visual studio...
I loved VS, but pro much stopped using it after starting to use VSC.
(not that I'll stop using it, I'm sure someone will fork if gets too obnoxious)
My guess is that they will up-sell to a version with bundled plugins which offer turnkey integration with Azure.
Historically speaking, Microsoft will break compatibility when it suits them.
I think they are just trying to make Windows (and Microsoft) more relevant among web/foss developers by making sure that top-notch tools exist with first-class Windows support, so this falls to same category as Windows Subsystem for Linux.
Maybe I'm just squarely within the target audience of VSCode, but I'm consistently impressed by how many of my pain points just magically go away with each new iteration.
Atom and WebStorm felt rather clunky. Sublime was super fast, but somehow lacked behind in new features.
VSCode is a revelation for me :)
Agree - VSCode is such a good IDE, I'm constantly seeing it replace editors other devs have relied on for some time.
---
I am a very happy Jetbrains customer (ultimate, paid in full).
Now doing nodejs work. (Not a fan, it's just a job.) Really want to use latest, greatest (eg await/async). I tried to make the babel plugin workflow thingie work. Bleh.
I'll give VSCode another shot. Last effort, I stumbled on the npm package.json support. The npm plugins I tried baffled me. (Again, not a fan of npm, it's just a job.)
I agree that it's one of the best products from MS today... I keep hoping that they take this as a model and re-create SQL Management Studio as an Electron app as well (I know about the VS Code extension).
I had tried electron and brackets before VS Code, and was skeptical... other than a few learning curves in the UX, it's been great. I don't think anything compares in terms of the plugin ecosystem either (though might not quite mach sublime).
I'm all day switching between VSCode and Vim. VSCode's support for my toolset (nodejs, es6, jsx, flowtype, mustachejs...) is fantastic, but even with the (fairly good) Vim plugin, I miss Vim. Whenever something doesn't work in Vimified-VSCode as I expect, it breaks my brain and my focus a bit.
What's so great in VSCode that you abandoned something that, I imagine, was embedded in your head already?
But I hope they figured out the performance problem. As of writing, in the stable version of Windows 10, PS is perceptually slower than cmd, so I was forced to use PS only when needed. Funnily it was even slower in Windows 8, so the current affair is better than ever. But to be truly a default I think the performance of PS should at least match that of cmd.exe.
PowerShell has builtins, can import code from any .NET Assembly or native code DLL, invoke external processes, full featured programming language and structured data.
cmd.exe will never be on par with PowerShell.
As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.
I suppose this might(?) be mitigated if you're embedded in the .NET world, but I just can't seem to get the memory down for the silly cmdlet naming and since they also have the admittedly interesting object-piping thing going on, you're always battling two pain points at a time instead of just one (e.g. syntax/naming in bash)
Once you can guess the verb you want, then it can often be a simple matter of finding the right noun, and often nouns will be useful in sets similar to verbs.
Get-Verb, Get-Command, and Get-Help are all quite useful for looking for a command.
For dealing with the object pipeline I tend to find ConvertTo-Json very handy because as a developer I'm already quite used to reading objects in JSON already. (ConvertFrom-Json can similarly be used to bootstrap a PS1 pipeline with test data or remote data.)
[1] https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/...
[2] https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...
1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format.
PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS:
PS> Get-Process -Name chrome
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
362 80 169636 109896 36,411.16 484 1 chrome
497 113 274988 132544 5,161.00 656 1 chrome
404 84 87444 55356 303.56 764 1 chrome
PS> Get-Process -Name chrome | Format-Table -Property cpu,id
CPU Id
--- --
36441.265625 484
5163.09375 656
303.5625 764
PS> ps chrome | sort cpu -descending | select -first 3
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
1186 317 1876160 1055016 88,462.64 10524 1 chrome
1023 88 1825008 668684 37,740.92 6128 1 chrome
362 80 155776 64560 36,848.00 484 1 chrome
This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side.
Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist.
2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later.
3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead:
$file = Get-Item C:\Windows\notepad.exe
$file.LastWriteTime
$processes = Get-Process -Name chrome
$processes[0].CPU
Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as:
PS> 1 + 2
3
PS> 1 + "a"
Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format."
+ 1 + "a"
+ ~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvalidCastFromStringToInteger
When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays.
Whoa, my response got unintentionally huge O.o. Hope this helps anyone.
The thing about parsing text is a very huge pain point for me because I've had some tool change their output (and unicode issues) which broke some scripts.
The structured nature of PS makes it very powerful and allowed me to write a script that checks the latest versions of some software upstream and tells me if there are updates. I have that on bash as well but it's comparatively unmaintainable.
PowerShell didn't have this backward compatibility concern so it built up its own vocabulary from the scratch. While it is nowhere near to perfect (as your example shows, the VERB-NOUN naming scheme can be a bit cumbersome when some functionalities need to be grouped), I'd say it is at least much more consistent regarding basic file/device management, because there was simply no baggage to consider when they designed PowerShell for the first time.
Ah, and thanks for suggesting `Ctrl-Space`! I thought it would have been better if PowerShell had a GUI widget listing possible candidates, so I was considering sending a patch. It turns out that the MS people are definitely more clever than me. :)
The power of bash actually comes from the GNU coreutils and other userland software. It has almost very little to with bash.
Try out bash on a busybox and feel the crippled effect.
It's less great otherwise.
This makes it often great for working on Windows, and definitely great for working with Windows and other MS software that is designed for the .NET/PS world.
Unfortunately most .NET devs are programmers who grew up with VB, RAD and GUI tools they don't understand the value of exposing UNIX like small functionality CLI commands over big monolithic services, GUI apps, etc.
Can you recommend a good tutorial?
Sure, perhaps they're not as compact as some of the incredibly information-dense perl scripts that people come up with.
I'd wager though that it's easier to understand what a random powershell script is doing than a random perl or bash script that pipes output throgh a dozen utilities.
find . -type f -name '*.html' -exec cp {} /home/new_dir/{} \;
robocopy /r $pathFrom $pathTo *.html
robocopy /r $pathFrom $pathTo *.html /xf main.js
I guess copy-item should be smarter to be able to handle this.
Also, for what it's worth, your example in the linked post is a bit more verbose than it really needs to be. You're comparing a full-up programming language to nant there. So yeah, it's a bit more verbose there. But I bet I can come up with a counter-example where nant is a giant nightmare to get right (or requires just dropping straight to executing external commands) (There's a reason I've killed off all usage of nant years ago, and gone to powershell for build scripts)
ls . -r -file -fi *.html | cp -d /home/new_dir/
I think you're mistaken about what `cp` (`Copy-Item`) is intended to do. Its main purpose is to copy, not to filter. Yes, `Copy-Item` supports filtering because it's part of the "common parameters", but to be more in line with the cmdlets' original purposes, you should `ls` (`Get-ChildItem`) first, because it has more filtering capability, and then pipe the results to `cp`.
Is it complex? No, actually its complexity is exactly the same as that of your `find` example! `find` is more or less equivalent to `ls` in that both gathers the list of files that meet certain criteria. And then, like `find` invokes `cp` multiple times to do actual copying, `ls` (`Get-ChildItem`) feeds its result to `cp` (`Copy-Item`). They are structured in a similar way.
I'd even say the PS one-liner is more akin to "the UNIX philosophy". In the bash one-liner, there is a direct parent-child relationship between `find` and `cp`, which doesn't utilize pipes at all. Whereas the PS one-liner connects two equivalent processes (`ls` and `cp`) with a pipe. This is exactly what I'd call "small processes work together to get the job done", which is again the UNIX way.
It is however very powerful that Perl can be used in bash pipelines. But that is also true for any Unix tool that takes I/O.
So Bash is also very powerful with the help from all its friends that can be used with pipes. Shell native.
And you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.
> So Bash is also very powerful with the help from all its friends
> you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.
All of these things are also true for Powershell. Powershell can use any .NET Assembly, and if necessary make native windows system calls too if you really want.
However, when I need more than what a simple shell script gives me, I'm more inclined to reach for node, ruby or python than C#/.Net ... the overhead for a quick scripting environment is quite a bit lower than having to setup a project and build requirements. I've done both...
Why node, is simply npm... create a directory, npm init, write my script, etc. reference it from an alias or .cmd in my ~/bin directory (added to my path). Then it works in windows, mac and linux which I use all regularly. PS is mostly windows.
So my comment isn't PS everything or C# everything, it's if you're using C# to write a big fat monolithic app that has multiple isolated functionalities you can expose those fairly easily with PS.
They're both excellent products by themselves, but also give Microsoft the platform to start dangling turnkey Azure integration in front of developers.
Imagine if the IDE started to offer the ability to configure, deploy, and manage targeted production stacks--no browser / command line hackery required. That would be compelling.
This comment is a long-winded compliment.
VSC is an "redefined" and high hackable (largely thanks to the rich nodejs ecosystem) editing environment which you can do everything as you like. So, to pin it into an editor or an IDE makes less sense.
more technical imagination: the project lead Erich Gamma has long history works in the field of Eclipse and definitely knows the importance (and pain) of the code editing to a programmer. Then, I (and we) can expect VSC would go beyond the Eclipse and hunt the heart of coders from other IDE products some day:)
final shameless insert: recently I release an extension to provide Swift editing environment[1] to try to bring Go/Rust like experiment for Swift server side development. Now it works for both Linux and macOS.(I hope to investigate the possibility for windows 10 WSL after release 2.0 coming soon.)
http://code.visualstudio.com/updates/v1_9#_inline-variable-v...
I used VS Code (starting at v1.5) for a couple of projects (on my Mac), and I found it quite effective and very performant. The performance, particularly the interface latency, is a big complaint I have with other "fat" IDEs. And while my hands still try to do some Vi commands and a lot of Emacs commands, I found the keyboard options for VS Code acceptable.
This is as close to a Thank You to Microsoft that I have uttered in a long time. I hope they keep up the good work.
Looking at it just now, I also see that they added categories, and little edit buttons when you hover over a setting which allow you to click on what option you want. It's a bit strange to me that they're slowly turning a config file into a settings interface, but I guess it works fine for a Developer-focused product.
Much more time is wasted by looking for options in GUI equivalent and reproducibility, sharing, backup and comparing (diff) are way harder or nonexistent. Creating frontend for it is trivial, but honestly, why drop from horse to donkey as they say.
All the apps should have settings like that.
Combined with the VIM plugin and I rarely need to touch the mouse.
Custom bindings don't work on the default document. That's a pretty big failure right out of the box.
And I still prefer vimL to lisp, it's the php of editor extension languages. It's not great for big plugins but ok great to slap things together quickly.
I just find that if I have to go through a LOT more steps without a UI.
Otherwise, this quickly turns to nonsence such as Nano server image builder [1] because Microsoft is still babysitting people who CBB to spend few hours to learn Powershell basics and need a GUI that generate 1 liner script.
Microsoft should definitelly rise beyond click next culture.
[1] https://blogs.technet.microsoft.com/nanoserver/2016/10/15/in...
We had the "ease of use" in GUI paradigm for decades and it didn't hold. Why don't you give it a chance as a text ?
The comments tell you in detail how each setting works (as you can see, they are even translated), you can search for a specific setting on the top, and it's categorized as well; defaults on the left, your own on the right.
Some might say having both manual configuration and automated dialog would be better, but many such interfaces ruin the structures of my intentionally organized setting files. I will take no GUI than misbehaving GUI at any time.
It also allows you to override certain settings per project/directory, which can then easily be included in git (like files to exclude from the file view for a specific project, path/tool settings, indentation settings, ...)
I use VS Code in three locations in three different OS and I love how it works the same everywhere because I just have text files.
There are now categories in the settings file, a search bar and auto-completion, which should make discovery easier.
> The same apply for using langages extensions beyond syntax coloring.
Do you mean to say that extensions at https://marketplace.visualstudio.com/VSCode are hard for you to discover or that too much of your required functionality is in extensions?
> Even Intellisense does not works as expected out of the box so I don't use it.
If you have found a bug, it would be great to report it at https://github.com/Microsoft/vscode/issues
So yeah, json or (preferably) any other markup for settings is fine so long as it hints me with possible values as I type, tooltips each variable with its meaning and so on.
VSCode does this and more. See sibling comments.
To me, this combines the best parts of being a text file --- standard commands, formatting the way you like it, you can search it, version controllable --- with the best parts of a GUI --- prompting as to what options are available, easy selection of alternates, documentation, etc. It's an amazingly good implementation and I wish more applications used it.
(e.g. the comment for editor.lineNumbers now tells me that valid options are 'on', 'off' and 'relative', which counts relative to the line the cursor is on.)
The settings files now have intellisense in them so you don't have to lookup each option.
You can also have a separate settings.json file for that project and check it into git inside the .vscode folder and make those same settings available to your entire team.
We use that in every project and it is great.
Maybe you've taken a look at it a while ago. It's still a big json file (great! everything at hand) but very easy to edit since it provides a lot of assistance: there's icons to set a new option, references for everything, and intellisense/autocompletion for the schema of every option you want to change. It'll even show invalid options with a squiggle (e.g. when some setting becomes deprecated).
IMO it's the best way to have settings in an app, especially when you can install extensions that adds settings of their own or when you want settings to be version-controllable.
In the compiled world, I have somewhat of a background in C (haven't really done much with it in the last few years, though), so to me Go feels sort of like "C with a really strong std lib". I have really enjoyed the decisions they have made with the language, tbh, the people behind it have a proven track record. It's fun and very powerful, there is tremendous potential in it.
I miss all the libs available in C, but this is understandable due to the early age of the project. I also feel like it needs better package management (but I read that is a priority for this year).
For the most part, I like it, but it's lack of Mac-nativeness bugs me, and it may bug me enough to switch. Double clicking the window bar in all natives app minimizes them to the dock for me. In Visual Studio, it maximizes my window (but not into full screen mode). I keep clicking the menu bar to minimize a window, and this keeps happening. It's kind of maddening.
It's a years old Chrome bug. Wish they had a Chakra version of Elektron.
I always use 15pt Fira Code
Edit: And also note that, for whatever reason, GNOME does its own thing where you also have to edit the GSettings in addition to the fonts.conf settings depending on what app you're running.
Do you also criticize Chromium's font rendering? Maybe you are just looking for things to complain about?
However on Linux it does, so this sounds like a broken fontconfig setup, or a toolkit not getting the right hinting config.
"window.titleBarStyle": "native",1. Go to file is a little bit slower than Sublime Text but the extra features in VS Code make that tradeoff worthwhile. 2. The C/C++ extension enables go to definition/header without any extra configuration. 3. I like that it runs on top of Electron which is after all a fork of Chromium. 4. I haven't tried the debugger yet but I'm hopeful that will work fine too.
I'll keep playing around with it and maybe even switch from Sublime Text.
And just small stuff that is not working or works another way quickly gets very annoying.
I use more than basic editing.
I still haven't been tempted to leave emacs, but it's great to see so much progress in the ecosystem.
I'd like to run this with the webserver running on a big dev machine at work and the client at work. X forwarding is not working well for me at least.
I've now switched entirely to using Rider because of this. While it's still early days for Rider (and it makes my Laptop's fans spin nonstop), being able to hastily edit my views makes it more than worth it.
(And integrated ReSharper is always good!)
You can read more about the specifics if you're interested in https://github.com/Microsoft/vscode/issues/17875
I also liked the name of the project, xterm.js. :)
The project itself is a fork of the popular term.js which is now unmaintained, we've taken it quite far since then. Hyper are probably going to be making a switch once a few more kinks are worked out too https://github.com/zeit/hyper/issues/1275
Thumbs up for this, Daniel. Thanks.
I am very happy that this is solved.
It has some really cool features like VCS integration, "TODO" panel and "goto" functionality that works through interfaces. You can "Goto Super Method" to jump to the definition of an interface function that the highlighted function implements. You can also do the reverse which is to list all the structs that implement an interface, or a specific interface function.
The team makes very sane development decisions. Code offers a great UI, is fast and configurable. Bugs and issues are handled quickly and despite already having overtaken all other editors IMHO, there's a constant stream of improvements that are documented nicely with every update.
Good job.
The new settings (window.openFilesInNewWindow and window.openFoldersInNewWindow) don't help no matter what when I set them to 'off'
EDIT: Fixed it on Ubuntu by removing the '--new-window-if-not-first' argument from the code.desktop related command.
sudo nano /usr/share/applications/code.desktop
# set: Exec=/usr/share/code/code %UAlt-click adds a cursor. :)
Also, alt-up/down adds cursors above or below the current cursors.
I'm especially thrilled by the integrated terminal improvements.
That being said, it's nice that they're improving it still
1) Jump to definition for plain JS. Both Brackets and WebStorm can find method definitions for any JS project.
2) Multiline searches. I use this quite a lot to find files that contain 2 terms on different lines.
Edit: It does work on some symbols in JS projects. But it doesn't work on function calls. Example: 'object.methodName()' I can't click on methodName and have it find the source. Brackets and WebStorm find all possible definitions, if there is only 1, it will take you directly there, if there are multiple, then you get a list to choose from
This is the one thing I'd really like to figure out (be it out of the box or with a plugin).
By default F5 is "continue debugging," but debugging is limited to Node, so I don't think that's what I want.
Incidentally my MBP has no F5 key :)
Also, Ctrl+Shift+B is the default shortcut for whatever arbitrary task you have set as your Build Task in .vscode/tasks.json.
Also, the integrated Terminal (Ctrl+`) is more useful with each version.
I'm just trying to get the edit/build/run cycle down. So far the "run" part is missing for me.
The F5 debug support is great in Node and .NET Core and there are extensions to support other language debugging. (I've heard the Go and Rust ones in particular are great, though I don't work in either language myself.)
I use https://marketplace.visualstudio.com/items?itemName=formulah... and bound it to exactly this key.
Still I am a very happy user of Visual Studio Code.
Unfortunately, I can't seem to run my launch task in my second window anymore...
I think the team behind it has been doing fantastic work. Thank you guys.
I'm using Linux btw.
On my system, the new parallel file search from VS Code is an order of magnitude faster than Sublime. For example, searching my entire project is 2 secs in VS Code vs 20 sec in Sublime
I knew VSCode was very optimized for an Electron application, but you have no idea how fast this is. This is faster than my Vim set-up, and I have taken my sweet time making sure Vim only loads the plugins it strictly needs and I try to switch to the asynchronous version of a plugin as soon as it pops up but still, VSCode is more consistently responsive for a lot of tasks.
I'm not sure wether I'll make a full switch yet, specially once I get a proper computer back, but the quality of the plugin ecosystem (I thought vim-go was amazing, but VSCode's Go plugin is just ridiculously good and properly asynchronous) coupled with this huge performance surprise are really making me consider it.
VSCode is apparently faster than Atom, and I sped Atom up considerably by disabling languages that I rarely/never use. Timecop plugin does wonders for tracking down the slow plugins
how fast is it when grepping large number of files? Is it at least comparable to Sublime Text?
https://github.com/Microsoft/vscode/issues/329#issuecomment-...