I am surprised at the amount of semi-negative comments here. Yes, some features are yet to be implemented, (it's still a fairly young project and you can always follow GitHub issues on progress), but for an Electron app, it's surprisingly fast and capable.
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!
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.
VSCode really does improve with each release, and the monthly cycle is just about the perfect pace. This is a great example of how to run an OSS project.
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?
It's probably a complex set of factors including developer good will and competition in the marketplace (VSCode is obviously directly competing with Atom, for instance, which is also free).
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.
> 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?
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.
VS Code is part of the strategy to get .NET Core distributed and to support the web layers built on top of that which mostly now use open source technology (from npm and bower through to grunt, typescript and angular)
I assumed the idea was also to eventually to get some users to move to the "real" visual studio, which I ended up doing at least to debug C++, except the vs editor is so much worse!
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...
VS Code is a web dev IDE. Microsoft has lost the mobile platform wars and pushing the web is a way of countering that. Plus, web and azure do go hand-in-hand, as you point out.
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.
I have used vim for years and I was tasked with making an Electron app for a client so I tried vscode... And I love it! I still use vim for sysadmin things but it has been the first thing Microsoft has made since the original Natural Keyboard that I absolutely love. It is good. I recommend it to others. I hate bloated editors and it is good... No config/setup process either - the defaults are enough!
I do tweak a few of the defaults. I use it on windows, linux and mac and they vary, so I like them consistent (linux line endings by default, 2-spaces, etc).
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 very curious: Don't you miss Vim? After using it for years, doesn't editing code in anything else feel wrong?
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?
This is an off topic, but I just learned from the article that PowerShell will soon be the default in place of cmd.exe in Windows 10. I welcome this change as I found the experience of using PS was superior to that of bash/zsh in general cases.
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.
On that note if you are a .NET developer you owe yourself to learn PS and how to write cmdlets, it's such a powerful and easy way to expose a CLI for your .NET app compared to stdio and command line arguments parsing - it's incredibly powerful and trivial to do.
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.
Yeah this is the one thing with PowerShell: with great power comes, erm, not so great performance. I've never been a full-time shell user so after years of occasionally getting some stuff automated using bash discovering Powershell really was like a breath of fresh air.. No more trying/failing to come up with the correct regex to parse the plain text spit out by tools. Command-line completion of arguments. A whole bunch of sane defaults and command names making things easy to discover. Etc. Now at first I only ran PS on a beefy workstation and didn't notice it was kinda slow (even for common operations). But on not-so-beefy machines: yeah, not nice. Then again, cmd is worthless in comparsion with PS so I stopped caring. Thing is also: the time gained by how fast I can get stuff done in PS probably makes up for the time lost trying to figure out the weird syntax of other shells, especially cmd.
VSCode + TypeScript is the perfect foot-in-door for MS to get into the web space.
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.
You can do that right now if you use Azure ARM templates and set up project-level actions to run them through the Azure CLI. It's just a matter of someone bundling it together as an extension (I've been working on one, but solely for template snippets).
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.)
I worked on the debug inline values feature. Let me know if you have any feedback/questions regarding that. Its currently disabled for evaluation purposes but you can enable in settings via "debug.inlineValues": true
I am super pleased that VS Code exists, works on multiple platforms, and is apparently a first class project at MS Dev. Like some other devs, I ran as far from Microsoft as I could many years ago... but now it seems they are trying to be more open, or less protectionist/monopolistic.
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.
I keep trying VSCode, but the main thing that keeps me going back to Atom is the fact that I have to do everything at the command line or by editing an enormous json file. Maybe I'm spoiled, but I'd much rather have a nice UI to deal with settings than have to figure out that, say, in order to show line numbers I have to modify "editor.lineNumbers" and set it to "on" (or is it "true"? or 1? I can't remember... let me go waste more time looking it up...)
Take another look. What you get now is still a gigantic JSON file... except it opens in a two-pane window, with the default settings (including detailed documentation in comments) on the left, and your local copy on the right. And beside each setting on the left is an icon where, if you press it, it copies the setting into your local copy, with all the correct JSON syntax. And usually there's a dropdown showing the different valid options and it uses folding to divide neatly up into sections. Oh, and the settings instantly apply when you save the file.
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.)
This is preciselly the reason I and many of my collegues love it - no GUI for settings. This means you can use hundreeds of tools to manage your settings and it is in true spirit of unix philosophy to keep everything as a text file.
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.
While I agree that a real settings menu could be an improvement, they have made the settings experience better. They show a searchable annotated list of all the default settings on the left, and when you type a setting key in on the right it will show suggestions for possible values.
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.
> I'd much rather have a nice UI to deal with settings than have to figure out that, say, in order to show line numbers I have to modify "editor.lineNumbers" and set it to "on" (or is it "true"? or 1? I can't remember... let me go waste more time looking it up...)
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.
well, it's an editor for programming. those tools are usually all about typing text, automatically completing text, and validating text. appling those idea to a json config file shouldn't be allien to a programmer.
I share your opinion on the settings and command line. While I like it to loads faster than full fledged Visual Studio, in a year or so of using it on Mac OS I still doesn't use even 1% of its features because they are not _discoverable_ at all. Modifying or doing anything beyond text editing require googling. The same apply for using langages extensions beyond syntax coloring. Even Intellisense does not works as expected out of the box so I don't use it.
I have a new project at work that I decided to use it for to see how I liked using VS Code.
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.
I work on Chromium and I test every VS Code version to see how it performs with the Chromium source code (except third_party). This is the first time I'm impressed. My observations:
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.
I was a die hard ST3 user and Microsoft hater and I begrudgingly gave VS Code a shot after a dev I respected gave it a shout out on twitter. After a day of heavy use it became my daily driver. It is a great balance of speed, configurability, and features. Very impressed and highly recommend giving it a shot. Its just getting better and better.
It's nicer than Atom and almost feels as snappy as Sublime. But Vim still is miles better when you have put in the work to become proficient. MacVim works great for retina screens and high color support.
Given that this runs on electron, which is basically a web browser with a node backend, is it possible to run this either as a webserver or otherwise remotely ?
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.
Anyone know if the C# plugin supports cshtml files yet? The lack of autocomplete, inspections and so on really hampers web development with it.
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.
The slowness shown in the pre-1.9 terminal is a bit ridiculous. Was it really the case? I've never seen such a strangely-behaving emulator! Really good that they resolved the issue.
Hi, I worked on those improvements. Yes that is indeed what would happen when you ran a command with heaps of output, it would also lock up the UI while doing it. You probably haven't observed it much as you don't do recursive directory walk on a large directory ;)
[+] [-] AsyncAwait|9 years ago|reply
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!
[+] [-] computerex|9 years ago|reply
[+] [-] seabrookmx|9 years ago|reply
I will respectfully disagree and say that gogland (while still in a pre-release state) is much much better.
[+] [-] jshen|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
[+] [-] testUser69|9 years ago|reply
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.
[+] [-] christophilus|9 years ago|reply
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?
[+] [-] WorldMaker|9 years ago|reply
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.
[+] [-] Yaggo|9 years ago|reply
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.
[+] [-] nikcub|9 years ago|reply
[+] [-] CyanLite2|9 years ago|reply
[+] [-] hobo_mark|9 years ago|reply
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...
[+] [-] Joeri|9 years ago|reply
[+] [-] reynoldsbd|9 years ago|reply
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.
[+] [-] k__|9 years ago|reply
Atom and WebStorm felt rather clunky. Sublime was super fast, but somehow lacked behind in new features.
VSCode is a revelation for me :)
[+] [-] wattt|9 years ago|reply
[+] [-] tracker1|9 years ago|reply
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).
[+] [-] ikurei|9 years ago|reply
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?
[+] [-] yokohummer7|9 years ago|reply
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.
[+] [-] rubber_duck|9 years ago|reply
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.
[+] [-] chmln|9 years ago|reply
As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.
[+] [-] tonyedgecombe|9 years ago|reply
[+] [-] stinos|9 years ago|reply
[+] [-] majkinetor|9 years ago|reply
[+] [-] eob|9 years ago|reply
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.
[+] [-] rcarmo|9 years ago|reply
[+] [-] santaclaus|9 years ago|reply
[+] [-] jinmingjian|9 years ago|reply
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.)
[1] https://github.com/jinmingjian/sde
[+] [-] nojvek|9 years ago|reply
http://code.visualstudio.com/updates/v1_9#_inline-variable-v...
[+] [-] blunte|9 years ago|reply
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.
[+] [-] joekrill|9 years ago|reply
[+] [-] david-given|9 years ago|reply
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.)
[+] [-] majkinetor|9 years ago|reply
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.
[+] [-] mastax|9 years ago|reply
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.
[+] [-] whatever_dude|9 years ago|reply
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.
[+] [-] sljkdjaldjo|9 years ago|reply
[+] [-] rehemiau|9 years ago|reply
[+] [-] titanix2|9 years ago|reply
[+] [-] joaodlf|9 years ago|reply
[+] [-] pwthornton|9 years ago|reply
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.
[+] [-] sunnyps|9 years ago|reply
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.
[+] [-] vikingcaffiene|9 years ago|reply
[+] [-] vgy7ujm|9 years ago|reply
[+] [-] grandalf|9 years ago|reply
I still haven't been tempted to leave emacs, but it's great to see so much progress in the ecosystem.
[+] [-] candiodari|9 years ago|reply
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.
[+] [-] mootothemax|9 years ago|reply
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!)
[+] [-] yokohummer7|9 years ago|reply
[+] [-] Tyriar|9 years ago|reply
You can read more about the specifics if you're interested in https://github.com/Microsoft/vscode/issues/17875
[+] [-] majkinetor|9 years ago|reply
I am very happy that this is solved.
[+] [-] whatever_dude|9 years ago|reply