Skip to main content

My Short Review of Visual Studio Code

I decided to try out Microsoft's Visual Studio Code. I think it's a useful open source project with a lot of potential, and I congratulate Microsoft on their contributions to the open source community. On the other hand, I think I'll still with IntelliJ IDEA Ultimate Edition and Sublime Text 3 for the time being. I used it for a few days after watching some of the videos. What follows is not a full review, but rather a few thoughts based on my experience.

VS Code is usable. On the other hand, a few of the extensions that I picked were buggy. They either munged the source code in clearly broken ways, or they caused the editor to go into a weird, infinite loop where it kept trying to edit and then save the text. I think the situation will improve with time--Rome wasn't built in a day.

One thing I really missed was being able to search for multiple things at the same time. In IntelliJ, I often start a carefully crafted search as part of a refactoring effort. That search tab might be open for a day or more. However, I can start up as many additional search tabs as I need. NetBeans also had this feature. I couldn't figure out how to do it in VS Code.

In general, it seems like the search interface was designed more by designers than by hard core engineers. Looking at the imagine, imagine trying to do a regex-based search. You have to click on the tiny ".*" symbol that's printed using gray text on black. Then, the search results themselves are shown using an inadequate amount of horizontal space. It all feels very dark and cramped.

Emacs does something useful when you hit Control-k: it deletes to the end of the line. If you hit it again, it deletes the line ending as well, which joins the next line with the current line. If this were a feature in just Emacs, it wouldn't be very important. However, this feature works pretty much everywhere in OS X, so it's something I've learned to rely on. It doesn't work quite right in VS Code. Here's the bug.

Many editors (Sublime, Vim, etc.) can by default rewrap a paragraph of text, i.e. re-insert newlines so that the text has line lengths of consistent width--not just in how you see the text, but also in the file itself. This is a critical feature for those of us who like to edit lots of plain text files. This isn't built into VS Code. However, there's a plugin--no biggie. Some editors (Vim, Sublime) get bonus points for doing this really well, such as being able to rewrap a paragraph of text even if it has comment symbols (like '#') at the beginning of each line.

One more thing I really missed from Sublime Text is that even if I'm in the middle of editing a file and have unsaved changes, if I close and restart the app, it puts things back to exactly the way they were before I closed it. In VS Code, I have to work to re-open the files I had open, etc. This is very inconvenient if you need to restart your editor because you installed an extension, or for any other reason.

The configuration system is pleasant. I liked the fact that it's based on text, and that there are global settings, user settings, and project settings. I can imagine committing settings files so that everyone on the same project shares project settings. Similarly, I liked the fact that a lot of commands are meant to be searched for using fuzzy search--the UI for this was nice.

The Git integration was nice, but perhaps inadequate. I very often have to do much more than git add, git commit, and git push. Using the command line, using Tower, and using IntelliJ's Git UI (which is kind of awkward compared to Tower, by the way), are all doable. I don't feel like I could use VS Code's Git integration without falling back to using the command line a lot.

My buddy said he preferred VS Code over IntelliJ because IntelliJ had too much "bloat". Whether or not a feature is bloat is certainly a matter of opinion. For instance, he would never rely on IntelliJ to work with Git. He'd only use the command line. I can use the command line or IntelliJ, but I really prefer using IntelliJ for dealing with messy rebases. IntelliJ's rebase flow is incredibly helpful. He'd also never use IntelliJ to refactor an expression to use a variable or rename a local variable (which isn't based on simple search and replace, but is actually based on understanding a programming language's scoping rules). Those are things I rely on IntelliJ to do very often. Hence, I think it's fair to say that IntelliJ is a little bit greedy when it comes to memory (it'll use everything you give it). On the other hand, it has tons of very advanced features that actually do help me quite a bit on a daily basis. There were a lot of features I missed when I used VS Code.

The last thing I'd say about VS Code (which I hinted at earlier) is that it made me feel very cramped and uncomfortable. I felt like it was difficult to see the text and I felt like I was typing with 10 thumbs. I don't know if it was because of the dark theme and my aging eyes (none of the themes felt exactly right), or if it was because of my inexperience with it. I don't remember feeling this way when I first tried Sublime Text. It was this uncomfortable feeling that pushed me back toward using IntelliJ and Sublime Text 3.

Nonetheless, I suspect it'll continue to get better. The plugins will stabilize. Missing features will be added. Soon, it'll be yet another perfectly good editor that some of my friends swear by. I remember going to a talk by Bram Moolenaar, the author of Vim. Someone asked why his Vi clone succeeded while all the other Vi clones didn't. He said it was because he kept making it better. I think that's good advice ;)


jjinux said…
Note, here's a plugin to open up find results in a new tab in Sublime Text 3:

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p