Hacker News new | past | comments | ask | show | jobs | submit login
Visual Studio Code 1.0 (visualstudio.com)
966 points by lukehoban on Apr 14, 2016 | hide | past | web | favorite | 461 comments

VSCode knockouts Atom in a dispute for becoming a developer editor in a corporate computer.

Sure, you all have root password in your computer. Unfortunately, I belong to a lower race: the corporate developer. I work in a Windows 7 machine, don't have root password and there's a big wall called proxy around me.

I didn't know about VSCode before this HN post, but I was trying to use a new editor instead of Notepad++. In my 5 minutes comparison match between Atom and VSCode, Atom was knocked out in the first minute. To quickly test a new general code editor I just want 3 "simple" things: column selection, regexp search and replace, and a python mode.

Atom: got the regex, must install a column mode extension, need to install a ntlm proxy authentication downloaded from (argh!) Sourceforge, configured it after some google searches, failed to install the extension because it needs a compiler. Ops, just spent 30 min for my 5 min test. Can't spend more time playing with a code editor, must go back to work.

VSCode: Download the portable version https://code.visualstudio.com/docs?dv=winzip and unpack it. Just works.

You've got a new fan VSCode!

Just wanted to say I find Notepad++ to be an excellent tabbed editor, especially for XML or SQL. I use it on windows all the time and really miss it on OS X where I find Textmate to be a bit awkward.

I've been a long-time fan of Notepad++, but it's a text editor. You can extend it to make it work better with specific programming languages (e.g. here's a post I wrote 10 years ago about adding language support http://weblogs.asp.net/jongalloway/creating-a-user-defined-l...) but it's fundamentally a text editor.

VS Code is a code editor. It has IntelliSense (not text-matched autocomplete, IntelliSense), debugging support, git integration, parameter hints, go to definition, code peek, etc. (http://code.visualstudio.com/docs/editor/editingevolved). The goal is to give you code editing features with the speed and simplicity of a text editor.

They're both free and lightweight, so I use them both pretty much daily.

Notepad++ is very useful but I wish some features would be updated. The dialogs are awkward to use at times. The XML for defining custom syntax highlighting is atrocious. It's like they took a pre-XML config file and shotgunned tags into it without planning a rational format. Keywords are specified using long strings delimited by CR/LF entities for no good reason other than to destroy readability. It would be nice if an more modern hightlighting engine could be inserted as an alternative to the clunky ad-hoc design it currently has.

As you say, both are useful for different things. They complement each other if you use the right tool for the right job.

I find Notepad++ is great for handling really large files and changing UTF encoding or line endings. VS is good for pretty print formatting code/XML to be more readable, among many other non-text things such as debugging.

>and changing UTF encoding or line endings

If you need to do those things often, there are specialized tools, including in the command line, and for batch processing.

No need to do it in an editor.

I don't need to do this often but occasionally you'll need to fix inconsistent line endings, change encoding to UTF-8 or remove a BOM [0] (to stop  being prefixed by some old software).

[0] https://en.wikipedia.org/wiki/Byte_order_mark

Yeah, I know, had to do it some time or another.

In OS X and Linux (and Windows with Cygwin etc) there are several command line programs such as unix2dos (line ending conversion), iconv (encoding conversions) etc for doing just that, so that you don't need to do it in an editor and can even automate the work.

Coming from OS X, there are a bunch of minor things missing in Notepad++ that I'm used to having on OS X. Like the ability to drag tabs between windows with the mouse, to move new tabs to a new window, or to create a new file and immediately save it. The scrolling in Notepad++ is also a little buggy. Just to give you a perspective about what the other side thinks, since you inevitably develop different habits in different editors, and those habits break when you switch.

That said, I use too many editors for my own good. (I'm active in both main churches.) Neither Notepad++ nor TextMate are competitive with VS Code, Emacs, or Vim, IMO, and I use all five regularly.

> Coming from OS X

Also, do Windows editors have that Alt+drag rectangular text selection feature that most/some OS X apps have?

No, it is implemented by each editor/ ide independently with their own modifier.

On the contrary we have mostly consistent ctrl/shift + arrow behaviour over the last 15 or more years(I don't know before that). :-)

> On the contrary we have mostly consistent ctrl/shift + arrow behavior

Are you saying Windows has consistent Control/Shift + arrow behavior?

OS X is pretty consistent about this too, though Control+Arrow moves between Desktop Spaces, not related to text, but you can modify a lot of system/app shortcuts from Preferences -> Keyboard -> Shortcuts.

When I had a Mac (2009 - 2012) what modifier to use for different text movement operations varied wildly, even between the built in applications.

Mac using colleagues explained that it was because the applications where written using different toolkits.

Ctrl arrow in Windows jumps by word. In os x, it's option arrow. I believe it's widespread but not global.

I know.

Problem is: until at least 2012 not even Apple was consistent about it.

My most used editors (Sublime Text and Notepad++) have this.

Notepad++ is a great text editor, but it has no clue about your code base. It can't do searches of all functions, or Ctrl+Click on the method to go to its definition, etc.

I dropped Notepad++ for SublimeText a while back (partially because it supports both Windows and Mac). VS Code is slowly winning me over though!

I love ST, but the hotkeys are so different between Windows and Mac and it drives me up the wall. I feel like I'm abroad in the UK and now fries are chips, chips are crisps, crackers are biscuits, Ctrl+H is Cmd+Shift+F, etc... It really gets in the way of my ability to work in my editor fluently, which is ultimately all a text editor is good for.

You're aware that you can change them right?

On OS X, download TextWranger -- it's free and close to Notepad++ than TextMate.

And the best feature of TextWrangler: if it crashes, or the computer shuts down, it remembers unsaved changes in files. Start it up and it restores everything to the last keystroke.

Not sure if other editors do this too.

I'm always surprised that PSPad [1] doesn't get mentioned much in these conversations. I find the built-in utilities are more numerous and work much better than Notepad++. It also handles large files much better IME.

It may be that the customisation is a bit less polished (eg, no way to quickly set themes) and the user community is less developed. But it really does everything and much better than the others IMHO.

[1] - http://www.pspad.com/en/

edit: words

I prefer to install Notepad2, it uses the same engine as Notepad++ (Scintilla), but I have turned off most options to resemble the stock Notepad:


So, apart from the icon, how does that resemble Notepad?

one instance per file, no tabs, no toolbars and a simplified menu (all of that configurable)

I like Notepad++, but I prefer one that works in Windows and in my linux home computer.

Notepad++ does work on Linux and also Mac's using WINE.

Seriously try gvim. Not vim where you need a long ass cheat sheet just to create a new tab or move between splits. But gvim where you can be productive and use the mouse and menus when necessary.

The one thing that kills gvim for me is the inability to have one session with multiple windows. I use it anyway.

Try Emacs with vim bindings and you'll have it, its GUI is a client that connects to a server

How would that be better than opening multiple gvim processes?

I want to type :wa in one window, not four windows. I don't want to get an error message when I try to open a buffer that's already open somewhere else, I want it to just move the buffer to the new window (or alternatively, raise the window containing the buffer). I want to move buffers across windows and keep undo history and register contents. TextMate / Emacs / etc. have this capability, but I can't figure out how to do it in vim.

Agreed that Microsoft has developed a very fine code editor and a worthy competitor to Atom & Sublime.

And if you can believe it, Adobe actually produces a decent code editor: Brackets.

I personally love the way Sublime saves everything in the editor even if you close it and reopen it.

Is it open source? (VSCode)

Wikipedia: "Visual Studio Code is an open source source code editor"

How do corporate developers test and debug things without the root password? In some cases, you need to be able to start Visual Studio in UAC mode, and debug an already running process...

From a security perspective, we ask: why are you developing applications that can't be ran by normal users?

For the 1% of devs working on system level stuff we provide VMs or separate physical servers that aren't joined to the corporate domain and don't have sensitive information on them.

As an example, VS needs UAC permission to integrate with a local IIS install, so there's a big group of .NET-based web developers that really need it with such a setup.

But honestly, giving a developer non-admin privileges of their own (as in their work environment) computer is like giving a carpenter a rubber hammer to hammer nails. I find it insulting.

At a lot of workplaces (like mine) it goes beyond that - developers aren't allowed to install software even under their own user account, where admin privs aren't needed.

Consider the irony of that, when one of the approved pieces of software is a compiler. We can make our own programs, hello!?

> From a security perspective, we ask: why are you developing applications that can't be ran by normal users?

Really? This question from a security engineer on Hacker News? I can tell you've never developed on Windows because (as pointed out) Visual Studio needs root level permissions to operate. The level of access a user needs to run my program has nothing to do with the level of access I need to build the program. They are completely disjoint.

I'm sorry but you are incorrect. VS needs admin rights to install into Program Files, registry updates and GAC install, etc. Otherwise the apps a developer builds are run in in their own process and unless there are special circumstances, should not need admin privs; VS should never be run as admin apart from those special circumstances.

What about tools like Docker or VirtualBox? Every time those high-frequency release software are updated, you need to request sudo using the audit tool or request for IT to update?

I can't even imagine writing a kernel hardware driver in a corporate setup if they at subjecting development environments to strict lockdown.

I worked in a bank previously. We did not have root, but we had a utility to run certain commands "as administrator". It popped up a dialog where you had to input a justification for auditing purposes.

I don't recall needing it for debugging though, even when attaching to a running process (was your process started as a different user?)

We either don't need it, or get stuck and end up crying in the bathroom.

Thing is, why do developers create software that needs administrative access to the os? I wish that I could simply download a zip of the software, extract it and run.

And already this wouldn't work: most software is distributed only through an installer. Heck, even PortableApps website distribute their portable products using an installer!

You generate a time limited root password alongside a reason why are you requesting it.

This applies to any OS being used.

If you are an external, might additionally need to have an employee sitting with you in case you are trying to use something business critical.

I have no idea. I work for a very large software company and we all have root.

Which is to be expected since your core business is software. I work for a very large consulting company and I also have administrative access. But my client's machine do not - big insurance companies, banks, publishers, Telcos, petrochemicals, etc.

Why? Tell me, if you were a system's administrator in charge of 10.000+, would you risk it? That's everything that's bad in corporate culture, but as you get big, it happens.

> Atom: [...] must install a column mode extension

Atom has Sumblime-Text-style column selection using (on Win) CTRL-ALT; it works very well and feels familiar for people coming from Sublime Text (which has been very popular for years now).

Actually, column selection is one of the things where I prefer Atom to VS Code (I love both editors for different reasons).

But maybe you needed some particular style of column selection?

This just works if you have a package installed. It's where your problems start.

Weird, I don't recall installing it, but my case might be atypical since I have been continuously updating since beta.

If you have Powershell 3+ try http://scoop.sh/ at work. You can install many tools (including VSCode) from the command line.

Or Chocolatey ( https://chocolatey.org/ )

Nope, you need to (correctly) use chocolatey, since most things are installed.

My last attempt at this was to install kdiff on a corporate machine

Curious if you've tried Sublime Text and your thoughts about using it in a corporate environment?

I've been using Sublime Text 3 for probably 2-3 years now at work (and home) and I love it. The only downside is it costs money but you can use it for free as long as you don't mind a popup asking you to purchase it every 10-20 saves.

I used Notepad++ for a few years before Sublime, I eventually switched because of the lack of Notepad++ support on Linux. I didn't want to have to remember the commands/shortcuts for two editors (and I avoid using Vim if I can).

My company now freely buys any employee a license, if they want one. Quite a few did and got a license.

I'm not really sure how a half-IDE/half-editor intersects with corporate concerns, to be honest.

> To quickly test a new general code editor I just want 3 "simple" things: column selection, regexp search and replace, and a python mode.

What do you mean by python mode? Just syntax highlighting or something more advanced like an integrated REPL?

To me (not OP), Python mode means syntax highlighting, code linting, code completion, and unit test integration from within the editor.

There's a few other nice-to-haves, but those are the big ones.

In a simple text editor? My requirement would just be that copy/paste does intelligent things with indents.

In Sublime, Paste and Indent (Shift-Cmd-V on Mac) does that fairly well. It's not based on an AST or anything like that, but it's rarely failed to do the right thing in my experience with these: Python, XML, HTML, CSS, SASS, PowerShell, YAML, Ruby

For me, it's a robust extension API, because then I can have any feature I want given enough time. Atom definitely has an edge there imo. Performance is also a plus (I have no complaints there with Atom). VSCode looks promising, though.

Well, I can do this in vim, so... yeah. If it can't do these things (more specifically be extended to do these things), it's a text editor I'd quickly put down for one which can.

> To quickly test a new general code editor I just want 3 "simple" things: column selection, regexp search and replace, and a python mode.

FWIW since you mention Notepad++, Zeus is another Windows based programmer's editor with those three features.

"I belong to a lower race: the corporate developer. I work in a Windows 7 machine, don't have root password and there's a big wall called proxy around me"

Sounds like an undeserving environment for a developer. Why not vote with your feet?

I live in Brazil. We have some striving software houses, but they are few and pay a lot less than, say, my employer, Bigtime Consulting.

To vote with my feet I'd have to accept an income downgrade of about 30%, higher risk of unemployment, and even then (heck, I'm looking for something like this right now) it's hard to find.

Because not everyone wants 20% below market rate, consntant negotiation headaches on stock dilution, an "infinite" vacation policy that actually means none, or being part of a culture that expects 70+ hour work weeks as normal, 3 months of maternity leave being ruinous to the company, etc.

It's a tradeoff, for sure.

But also most companies are waking up to the notion that trusted network models are not effective. It just takes time to change.

Ugh. 'Infinite' vacation policies are starting to infect corporaculture. I work for a megacorp (that I actually rather enjoy working for) that recently went this way, and since my megacorp is a bit of a trend setter, you can expect it to spread. During the explanation meeting, it was made clear that we really aren't supposed to take more vacation than what we used to have, but that we are expected to still actually take about as much vacation as we used to have ... so essentially a no-change there. As far as I can tell, it's mostly about

1) Making it so that employees can't take vacation at times that are particularly bad for a project because they're 'entitled' to it. This was already frowned upon (we always did get to use our vacation eventually, so it wasn't so bad), but now it's in writing -- which is good, rules should be written.

and, more importantly to the megacorp: 2) Eliminating owed vacation from their books & marginally reducing cost. Now if somebody quits or is canned, they're not owed a payout. I'm guessing the average employee will probably also take a couple of days less than they did under the old system, yielding a further savings.

I'm glad I live in a country where it's illegal not to pay out unused leave entitlements upon termination, and where there is a sensible statutory minimum leave entitlement...

I'm in a corporate environment too. The work is interesting and I'm slowly working with IT Security to break down the walls where needed, but I still find myself submitting bug reports like:




(Note that I've since found out it's better to support SSPI and NEGOTIATE)

That's before we even get started with SSL interception -npm/node and possibly Ruby's gem don't use the system cert list.

The answer is not to vote with my feet (because there are lots of reasons to stay) but work to make things better for developers in more restricted environments. Geez, wait til you startup kids go work for the Government one day ;)

Just because SV is an employee's market that doesn't mean that everywhere is, or that everybody has a lot of mobility in their personal life.

Because my country has a 20% unemployment rate and a 50% unemployment rate for youth such as me?

If the developer needs access, the product will suffer for a lack of it, and customers will eventually leave. If not, then it's just a petty complaint.

A lot of people don't want a bloated editor with too much bundled in by default. I'd be incredibly frustrated if there was some vertical selection functionality built in if it caused issues with a Vim mode extension.

Like a full web browser, for example?

cntlm for the win. I don't know how I could do my job behind our corporate proxy without it.


Googled part of this for you:

>Why not just set up atom to use your existing corporate proxy?

"Many of these text editors support proxy servers, but none of them that I have tried support NTLM for authentication and if your corporate proxy is using NTLM they simply cannot connect to it. Or lets say not directly! Actually the only solution I have found is to use a software called CNTLM that can act as a proxy server itself and behind the scene it can connect to another proxy server that is using NTLM." [1]

As to what needed a compiler, that part I'm not sure about. Aren't Atom extensions generally in javascript? Could it have been the CNTLM installer that wanted a compiler?

[1] https://devinthefastlane.wordpress.com/2015/12/24/how-to-ins...

NTLM auth is but one of various other roadblocks in a corporate environment.

In my previous job, the company runs a MITM proxy, it broke SSL checks for package managers. You ended up having to disable SSL checks and load up company-issued certs.

I asked whether we can find a solution to this issue on the company forum, as there are other developers and data analyst whose life can be made easier if this just works, the response I get was: "just download them manually", I kid you not.

Sigh... corporate proxies are the worst software I ever had to deal with. Terrible for productivity. Enough that people bring in own 3g dongles and connect to that wifi instead. Whole audit/security defeated :(

I thought they were, but the simple installation of the column select mode failed with a message of missing compiler. I don't want to delve inside my editor internals.

The first difficult thing is to discover that I have to install the sublime-style-column-selection package. So it failed and didn't researched more.

Ops, I've just tried it to see the error message and it worked! The sysadmins just updated a lot of Windows patches, maybe it solved the problem. BTW: VSCodes starts a lot quicker than Atom.

Coffeescript compiler?

Please report issues instead of using things like CNTLM - it has at least one bug that causes crashes under heavy traffic and may require you to store your password/hash in an insecure way.

I have admin and can install anything locally, but also I can't get any Atom packages to install from behind our proxy. That's okay -- I just wait until I have my laptop on my WiFi network at home and everything is copacetic.

It's not just me -- we had a trainer giving a class, & this guy lived and breathed Atom and he couldn't install an updated version of an existing package from our network either. His solution was to tether his phone.

I have the same problem with the Atom packages behind the proxy. I had to do some npm and git configuration to add http_proxy. It worked for a bit, then the corporate password changed, and I never really updated the buried settings.

I'll probably have a pretty easy time getting the MSFT Visual Studio Code approved for machine installation for devs on my team, even though we're an Eclipse/Java shop. I've been trying to get everyone normalized on a JavaScript editor, since the tools we have in Eclipse are severely lacking.

VSCode has done the thing that nobody expected MS to do, change the way code was written on Unix/Linux.

I love linux/unix, but the problem always was with the lack of an awesome text editor cum IDE, yep there is eclipse but it is too clunky, I do not like sublime as it isn't FOSS (call me crazy), gedit took way too much memory, geany is fast and mean but the UI sucks plus functionality isn't that great.

Enter VSCode, code writing feels amazing again, not the functional part, but the actual manual part.

I do not like vi because I primarily was learning web dev and I didn't really get my head around using vi effectively and still learn the web dev, so I am not a emacs/vi superstar as I have heard that both of them are fine text editors.

but for the people like me who don't or can't use terminal based editors, VSCode is quite literally the best.

The new Che project of Eclipse does seem promising, but the last time I tried installing it, it took around an hour, consumed GBs of my bandwidth and still nothing.

I am still Waiting for the day I'll be able to program in its entirety on my android device.

I used Atom but it is too slow, it is surprising that VScode and atom share the same ancestor but one is blazingly fast and Atom is so damn slow.

Edit: yep vscode didn't transform coding on unix, it merely changed it to some extent, and why the downvoting? point out where I am wrong, I'll get to learn!

Ummm, no. VS Code is a decent editor, nothing more. It certainly doesn't transform the way code is written on Unix/Linux.

Vim and Emacs are still superior if you want to put the time in, and both have non-terminal interfaces. They can also be both customized to be whatever you want them to be, there's not really a limit to their functionality except what plugins are already written. Ditto for Atom, though of course, it does seem to be more web based for the moment (though Atom does have great plugins for Go, Nim, and I'm sure a bunch of other languages).

In the grand scheme of things, tools like compilers, debuggers, interpreters, other command line tools (like completion servers), etc..., matter more than editors anyway.

Edit - for the record, VS Code seems great. But it's not revolutionary.

>Vim and Emacs are still superior if you want to put the time >in,

TBH, not every developer is willing to become a power user or interested to learn an IDE instead of the language itself. Being someone who worked on VStudio alot and now on Linux/Mac based tools, I can safely say that Microsoft tools are Developers friendly most of the time. It's good they are introducing same touch for Linux/OSX community.

Vim is a language to edit text and you can use that language in a lot of development environments. if you code all day it's worth learning.

verbs like ci" (change inside ") which deletes inside the current double quotes and leaves you in insert mode are pretty easy to get used to. dd deletes a line and puts it into the yank register so you can paste it somewhere. u undos an action.

using a plugin with visual studio is pretty king to get the best of the IDE and the most common vim functionality.

Classic SO answer on why vi: http://stackoverflow.com/a/1220118/1772636

edit: here is another classic why vi answer that is a bit different http://www.viemu.com/a-why-vi-vim.html

Why spend a few hours over the course of 60000+ working hours to learn how to use more effective tools?

"a few hours" ??? Come on, let's not pretend that EMACS is going to take "a few hours" to come to terms with and become more productive in than an IDE.

Actually, you can get decently proficient in just few hours. Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?

Humans have this funny thing as they grow older - they look at a thing, maybe try it out for few seconds, and then immediately determine it's too difficult and it will take forever. They rarely bother to spend actual five minutes, to the clock. If they did, they might actually have learned something.

25 minutes of deliberate practice - a single Pomodoro - is enough to become acquainted with several of Emacs features - like, navigation by semantic units and incremental search and autocompletion. You won't get proficient in that time, but it's enough to rewire yourself to actually start using it when writing code. Which will then lead to you becoming proficient while doing your regular, billable work.

Seriously, set up a Pomodoro timer, sit in front of Vim or Emacs, and try to practice a few things. You'll be surprised how fast you can learn.

(And yes, I did that, so I'm not talking out of my ass. I actually almost doubled my Emacs productivity once in 5 pomodoros - in 2.5 hours - two of which I spent watching Emacs Rocks videos, two on rewriting s-expressions with Paredit, and one on multiple-cursors.)

Actual proficiency in emacs takes time, a lot of it, and practice, a lot of it.

To reach a level of skill where using emacs is easier/faster/better than something like intelli-j (for instance) requires significant dedication and repetition.

Far, far more than "a few hours".

> Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?

Not the parent, but I've spent a significant amount of time with pure vim. I use vim bindings in everything from my web browser (vimium, vimperator) to my WM (i3 & kde vim navigation bindings), to my text editors & IDEs (atom, VS, sublime)

Despite all that, I still find using pure vim to be ineffective relative to just using Atom, Sublime, VS or whatever with vim bindings. I may have internalized the most basic navigational concepts, but the more advanced / esoteric shortcuts that are essential to use vim as an exclusive editor are still ones I need to look up - and that's not counting stuff specific to vim packages liked nerdtree.

At the end of the day I'm sure you could always argue that I should have practiced differently / better / more or whatever - but to what end? There are plenty of full featured text editors on all platforms that do everything I need. Why on earth should anyone force themselves through dedicated practice just to learn the intricacies of a 20 year old editor?

> Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?

Not parent but I have. I still would recommend something else for all the stuff I work with.

That said, it is amazing, I just believe in my line of work people are better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.

> I still would recommend something else for all the stuff I work with.

I sometimes do to. In particular, when that stuff is Java or C# - it's hard to beat the support IDEs gives you there. So I personally opt to switching said IDEs to Emacs keybindings instead.

(Also, one could argue that you need IDEs there mostly as crutches to support the weak language, but that's a topic for another day...)

> better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.

Refactoring - if you mean semantic transformations supported by your IDE, then yes. See above. But for search/replace and block selection no IDE beats the convenience of Vim and Emacs. They simply can do that better and more naturally (along with plethora of similar things helping with selection and navigation). And this is exactly the type of thing I was talking about in my previous comments - you can learn both under one Pomodoro if you focus solely on it, and then normal work will quickly take you to proficiency.

I've used emacs as my main text editor at work for the past 9 months, and I can safely say I am still nowhere near proficient. I'm getting better, but I can fully appreciate why emacs has the reputation it has.

I actually switched from VS to vim (while doing a project that integrated ironruby and C#). It took me about a week to reach 75-80% effectiveness with vim. At the end of 2 weeks I was back to full speed. At the end of 2 months I was considerably more effective at editing code. I'm now several years and several jobs removed from that initial project and I can't imagine not using vim.

IronRuby... good (and too short) memories.. I hope MS will embrace Ruby again sooner or later.

I gave up on that hope a while ago. And also on developing for Microsoft platforms in general.

This is completely nonsensical.

I switched to Emacs (Spacemacs) from Sublime Text with zero prior knowledge of vim or Emacs. In a day or two I could continue doing what I was normally doing. In a few weeks I felt completely comfortable.

My 13 year old daughter came up to speed with emacs in a couple of hours. Now she's starting to realize she can make it into whatever she wants and make it work however she wants. She hadn't even thought about being able to program new functionality into an application. It's opened whole new worlds for her. Yes, emacs.

You're making the assumption that vim/emacs are more effective tools.

The best possible programming environment is comprised of emacs coupled with a "lispy" language such as Common Lisp, Scheme, Racket or Clojure and the REPL to go along with it.


And the somewhat sad thing is that this is only a shadow of what was once possible on Lisp Machines... In some areas, we really did make a big step back over the last three decades.

You're arguing that stating that water is wet is an assumption

If it's so obvious then it should be easy to back up your claim with data.

I highly doubt its even possible to obtain such data. The best you will have is anecdotal claims.

For example, do productive programmers tend to use Vim or is it the other way around? It's hard to find the causality.

Because I don't need them, and would rather focus my attention on the part of the job I actually care about. The simplest tool which doesn't waste my time is the best. I have found that I would rather use a simple editor with no features that I never have to think about, and automate repetitive tasks using the same tools I already use for automating repetitive tasks: programming languages.

That just sounds like a self rationalization to me. "I don't need them" is something you say after you tried something and realized you actually don't need them. It doesn't carry any weight when you haven't even tried. Because when you do, it's just saying you don't want to try new things. I'm not saying you must learn these, I'm just saying you shouldn't lie to yourself.

That's a little harsh, but the cognitive bias you're describing certainly is a common one, and it's one I struggled with a lot when I was younger. I've learned to manage feelings of fear or anxiety by reinterpreting their activated, buzzy feeling as excitement or anticipation. This works well, though it has turned me into something of a daredevil...

I really don't think that's what's behind my attitude toward code editors, though. I've been writing code for thirty-odd years and making a living at it for twenty-five, and I've spent the majority of that time working on dev tools. Compilers, mostly - but I've written a couple of editors, too, plus a debugger, a couple of linkers, an assembler, you name it. So I have had a lot of time to think about tools, and have been lucky enough to get several chances to put my ideas into practice.

I'd have trouble remembering the names of all the different editors and IDEs I've used over the years. Emacs and vi are ubiquitous now but that was certainly not always true, and on some platforms, particularly embedded environments, using anything but the officially-blessed toolchain can make your life unnecessarily difficult. I have learned to get my work done using whatever tools happen to be on hand. That's meant a wide variation in the kinds of features which are available, the specific control-key bindings, the details of the build environment, pretty much anything you can imagine - so I have learned to rely on the basics and ignore the rest.

I find it far more frustrating to deal with a sophisticated tool that isn't working quite right than a simple, brainless tool that does the job but requires a little extra manual labor.

I'm not here to play with editors, after all, I'm here to build software, and the editors are just a means to that end. Time spent learning sophisticated editor features has to justify itself in time reliably saved using those features, which has to be balanced against the time wasted when they don't work quite right or when you have to go dig through the documentation to remember how to use them, times some distraction multiplier for the fact that you're thinking about the tool instead of the job you're using the tool to do. In my experience, there's been too much change and not enough actual need for sophisticated editor features to justify their cost.

Even if a sophisticated editor could allow me to perform certain editing tasks more quickly, that wouldn't change my overall productivity very much at all, because I spend far more time reading and thinking than I spend typing or editing. I type fast enough already; it's my brain that needs to be accelerated, and the best way I've found to do that is to eliminate distractions and focus as much as possible on the problem I am actually trying to solve.

I wrote a simple terminal-based editor a couple of years ago, including all the features I use every day and none that I don't, and I've been using it for all my daily programming work ever since. It's an unabashedly personal expression of my own taste, so I wouldn't necessarily recommend it to anyone else, but I like it and feel good when I use it. It's nice to know everything there is to know about the tool, so that I never have to think about it or try to remember how it works. Perhaps some day I'll be working in some new environment with some new toolchain and I won't be able to take ozette[1] along with me, but that's fine - wherever I go, I'll be able to get my work done with the tools I find there, because I'm comfortable doing my job with the basics.

1 - http://www.github.com/marssaxman/ozette/

So... you'd rather spend the time writing new code to do repetitive tasks rather than use existing ones? You'd rather spend time writing 'search and replace' in your favourite language than just use an editor with it? I don't see how that doesn't waste your time.

I'm happy to spend a little extra time every now and then doing some unusual task by hand in exchange for never having to think about the editor or try to remember how some powerful, infrequently-used feature works. As long as the editor can do everything I want to do on a daily basis, I'm happy; if it can also automate tasks I only have to do every week or two or every couple of months, it's a waste, because it'll take some effort to remember that the feature exists, what it's called, where to find it, and how to use it. I'd rather just use a simpler editor and deal with that oddball task in whatever way is convenient when it comes up. Since I spend all day slinging code, bashing up a little script to do some odd code-munging job is no trouble; I already have all the tools I need to do that paged into my working memory.

I was thinking more of the sorts of automatic refactoring tools some people really like to use in their IDEs. I haven't found that such tools save enough time to be worth learning how to use them.

That is fine, I think it is great that IDEs exist for easy editing and debugging. But power users will always exist in the programming community. These people will naturally use Vim and Emacs because they support the customization levels needed for complex programming workflows.

In my experience novices have an easier time learning programming with an intuitive IDE, but experienced users use whatever makes the most sense given the task at hand, which in many cases might also be an IDE. They're just different tools with different pros and cons, and each of those pros and cons are weighted differently depending on what you're trying to accomplish.

Very few programming workflows are so complicated that it is simply not possible to do something without first creating your own highly customized environment within Emacs. However, very, very many programmers do have a lot more fun screwing around with customizing their work environment (editor, window manager, shell, etc.) than using that environment to get actual work done (myself included).

Which is not to say that Vim and Emacs aren't awesome tools, I just wouldn't generalize anything about anyone based on the tools they use.

One thing that is not immediately obvious about vim (or evil Emacs) is the gamification part. Before I switched to Spacemacs myself, I used to think -- why do those vim guys torture themselves using an old deprecated tool. Now I actually find it fun to edit text or code and think of how much everyone else is missing :)

It makes sense that if you program a lot that you will learn how to save time in the long run. It took me a day or two comfortable enough to be efficient in it, at least as I was with Atom. After the first few days, you will just learn new tricks while you are programming.

You will see that after you learn how to use Vim you won't want to use anything else to edit text, you emails, browser and word processing will be in Vim.

> I can safely say that Microsoft tools are Developers friendly most of the time

You only think that because you have used it and became accustomed to vstudio. As someone who has used vstudio, eclipse, atom, intellij, vim, emacs - I can safely say that vim and emacs are far more 'developer-friendly' than the others.


Because the low-level modularity of Vim and Emacs gives you more control, by letting you choose the combination of tools you use ; instead of tying together the language(s), the compiler, the tag/completion engine, the build/project system, the debugger, the profiler, like many IDEs do.

The sole concept of IDEs specialized for one language makes me cringe.

I am a long time Vim user but I have never ever managed to get c++ tag completion work consistently there. At some point I just stopped trying - went to Qt creator and turned on Vim plugin there. The experience (for C++) is just vastly superior. The IDE integrates with CMake natively, the debugger is graphical and works, the symbol navigation over all project is blazing fast, I have real refactoring etc...

I still use Vim a lot, for JavaScript, for text, for remote sessions... But when a tool with real semantic highlighting and understanding of code is available (with a Vim plugin) then I'll take that.

Check out https://valloric.github.io/YouCompleteMe/ C/C++ completion for VIM.

Of course an IDE like QT Creator does many things better. But it's a tradeoff always.

> The sole concept of IDEs specialized for one language makes me cringe.

Can you explain this a bit? I don't see that Sublime, VS Code, Atom, etc. were made for one language, at all. As a little background, I've used vim for a while, then switched to Sublime Text, and am just trying VS Code. I find Sublime/VS Code/Atom to be far easier to customize than vim.

This is not what I said: I consider Atom and Sublime Text to be advanced general-purpose text editors, not IDEs.

I was indeed referring to Eclipse and Visual Studio. From what I observed around me, for some reason, people don't use these to edit:

- shellscripts/perlscripts/batchfiles.

- Files written in a in-house domain-specific language.

- Configuration files.

- Makefiles and project files: vcxproj, sln ...

Actually, I observed that these kind of IDEs discouraged people doing the above things, giving them the impression that it's not "real development" (I suspect that this is, in part, where the bizarre term "scripting language" comes from, but this is another debate).

I'm pretty sure he is referring to Eclipse, Visual Studio and the like.

That's what, gone are the days when we'd spend hours and hours to learn the little little ways of vi and the myriad functions in emacs. Now we need to get things done, can't afford to sit down and study the entire functions of vi and emacs. I don't mean to troll but after switching to vscode and the go plugin I learned go webdev and wrote this small intro book, http://github.com/thewhitetulip/web-dev-golang-anti-textbook...

That is the power of vscode, it provided a good enough way to play with code, yes not outright innovation, but an awesome text editor nonetheless.

Atom has a great Go plugin: linting, context aware completion, fixes code style on save, etc..., all powered by Go's command line tools.

I'm not saying Vim and Emacs are the be-all (I program mostly in R, so RStudio is my main tool), only that VS Code hasn't changed anything fundamentally. It's just a good editor.

Sublime Text has GoSublime as well.

What, exactly and without sweeping generalities, does it do that is a transformative step over Sublime Text or Atom?

Or, hell, even Kate?

For example the Git integration is awesome and even better than Atom's (you can commit, push, ...).

Of course you can do a lot with extensions, but at least in Atom's case they break a lot for me.

Well, okay, let's talk about that. Is having source control in your text editor enough of a benefit to one's daily routine as to be a step change of productivity or quality of life? It may be for you and I'm not saying you're wrong for that, I'm asking because it isn't for me; I have an alt and a tab key.

Bear in mind that the claim wasn't that it's better in some ways, but that it's sweepingly better than the stuff that came before (and Atom wasn't even mentioned by the OP, which is funny--I mean, I don't use it, but it's obviously in the conversation).

"Well, okay, let's talk about that. Is having source control in your text editor enough of a benefit to one's daily routine as to be a step change of productivity or quality of life?"

Uh, if you edit tens or hundreds of text files per day, it's a game changer.

Being able to press ctrl+K instead of alt tab -> write "git commit -m" is pretty nice and much faster...

EDIT: that's only the most trivial benefit of git integration

Having the git diff in your editor gives you syntax highlighting and let's you edit it (the right side) like you're used to.

I guess the killer feature of VS Code is multiple cursors (Ctrl+D). I only know of Sublime Text and Atom who also have this feature on Linux, not sure about Kate. Sublime Text is closed source and not gratis, Atom is slow and buggy.

Not allowed to reply to your post, so replying here.

No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.

That they are not built-in really doesn't matter though. All these editors revolve around plugins, and it's common practice to save your preferences on github or the like so that it's easy to use the same settings and plugins on every machine.

> Not allowed to reply to your post, so replying here.

I think you have to wait a few minutes, then it gets activated.

> No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.

That's too complicated for me. Last time I've tried to set up vim and emacs to my liking it was a mess: A lot of copying and pasting around random code, changing configuration files I didn't understand, ...

In all respect, but you are presumably a software developer. If someone approached you saying that language x is a mess, as they've copy-pasted around random code and changed configuration files they didn't understand. Would you accept that as valid criticism or told the person to actually learn their tools?

Granted, Atom, Sublime, VSCode etc. are easier to start with because they expose customization through JSON files instead of a custom programming language. But if someone where to tell you that they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).

If you know your editor, adding functionality like multiple cursors is easy. The greatest strengths of extensible lightweight editors like VSCode and Emacs, is that such functionality is only a package away.

> they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).

No that's the thing: I would tell them to press Ctrl+D, simple as that. Multiple cursors in Sublime Text, Atom and VSCode are intuitive and it's the first time in an editor that I actually use them.

Emacs and Vim also have multiple cursors.

Built-in? What is the equivalent of Ctrl+D (Sublime Text, Atom and VS Code) in vim and emacs?

For me it does, depending on the project. (Using emacs/magit, having a dedicated buffer just for magit.)

I want to keep on top of my current branch, what is untracked, what is unstaged and staged, quick diffing, etc. It actually helps a lot with productivity since I don't have to actively query for this information when it's all in one screen.

If I used another editor, I would like to have similar features. Maybe it can be done, but I am quite fluent in magit already, and one major thing keeping me from moving to another text editor for my current projects (if it actually mattered.)

This is something I really do not understand. I can switch to my terminal, build, run, stage, commit, push all in like 5 seconds. As well as anything else I need to do in the terminal.

The only 'plugins' I use are a keyboard shortcut (cmd+space) which puts me in a terminal window and rupa/z[1] for jumping into a project directory.

[1] https://github.com/rupa/z

Let's say you look at `git diff` and notice something needs to be changed. What do you do now? You need to quit, open the file, find the line, do the change, save and quit. Now you need to reopen git diff and scroll to the old position. This all takes a lot more than 5 seconds on the terminal.

Another scenario: You type `git status` and see a file called `src/a/very/long/path/file.c` hasn't been staged yet. Now you need to type that file path for git add or git diff. Takes more than 5 seconds, but it's just a simple click on a + symbol in VS Code.

1. atom is slow and clunky it hangs when I paste a 10000 line sql insert statements 2. sublime text: sorry didn't try

vscode's benifits:

blazingly fast modern design works on linux/mac too little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.

It is a great way to code if you don't want or can't use vi/emacs, I don't have the luxury to learn all the nook and corners of emacs, I started using Go plugin in vscode and today I have built go apps and written partially completed book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...

i tried giving vi a chance, but nope. couldn't bear it for more than a day, large webapps require a UI IDE, vscode > everything else I tried till now

> blazingly fast modern design works on linux/mac too little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.

Literally every other popular code editor supports some form of "go to symbol".

"Some other go to symbol" It is obvious I didn't use intellij and pycharm and stuff like that, but the ones I did use, kate, gedit, eclipse, notepad++ didn't let me drop into a function "With ease" yeah you can use that feature in eclipse, but it isn't with ease, maybe it is because I am so biased for vscode. We'll never know, but the thing is I feel productive typing into vscode than I ever had with some other editor I tried.

Go ahead and downvote it, but after all every programmer worth his/her salt does realize that the choice of IDE/text editor is ultimately a personal opinion, so long as you as a person are comfortable using it, that is good for you, it does not make a tad bit of difference to anyone else in the world.

I downvoted you for your brutal incuriosity, not for your opinion.

> features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there


> Vim and Emacs are still superior

I think the parent was talking about modern text editors such as Sublime, Atom, Brackets etc.; Vim and Emacs are completely different beasts (note: I love both).

Within the category of modern text editors, VS Code is in my opinion revolutionary in several ways - I will give you three examples

The first feature that I find "disruptive" is the way VS Code offers a standardised interface for debuggers, hence debugger plugins are much easier to create - and you can see that VS Code already has debugger plugins available for many languages: https://marketplace.visualstudio.com/vscode/Debuggers?sortBy... the availability of such plugins for Atom and Sublime Text is not nearly as good.

The second aspect where VS Code changed the game is the clever way it leverages Electron (the framework it's made with, Atom is made with Electron too) - while creating clever workarounds to known Electron bugs - e.g. VS Code, unlike Atom, does not suffer from this bug https://github.com/atom/atom/issues/10720

The third aspect is the git integration - since Atom is sponsored by Github, you would think it has the best git integration out there - but VS Code has gone the extra mile by giving you a great user-friendly UI interface for staging and committing (yeah, I know, anything more complicated than git add -A requires the command line - the fact is that nearly 50% of all the git commands I type are git add -A, LOL).

PPS I totally agree with you about the importance of tooling. But e.g. if you have a debugger that does not have an interface to your editor it becomes hard to set breakpoints. So the editor needs to integrate with your tools and VS Code is great at that.

"Vim and Emacs are still superior if you want to put the time in, and both have non-terminal interfaces."

I don't need an instruction manual to figure out how to close VSCode.

You also won't need an instruction manual for a lot of other things, because you won't be able to do them at all.

It's open source, I could do it.

Oh but that's needlessly hard and annoying? Well so are Vim and Emacs.

>> and both have non-terminal interfaces.

> I don't need an instruction manual to figure out how to close VSCode.

To close GVim, you click the 'x' in the upper right/left corner, like any other window.

To close the GUI Emacs, you may just click the X as well.

True, how did I forget?

In Vim, pressing Ctrl-C (which is how you usually terminate a console application) tells you to write :quit<enter>.

Alternatively, you could just close the terminal window.

And how do you install extensions for GVim?

You put extensions into the proper folder, or use a tool like 'Vundle'. Yes it's slightly more difficult than using Atom, but anyone who can use a tool like Git or Cmake should have no problems figuring it out.

So, as a 20 year user of emacs with a .emacs file older than some people who post here: I have moved away from both.

I like being able to use other languages for editor extension, having a competent graphical and text layout layer with image support, and quite frankly I find emacs development tedious now.

So... Do I need a few more years of time to "get it?"

What I meant was that if you don't have the time or inclination to learn the myriad ways of vi and emacs, there isn't a really great light weight fast text editor, eclipse is too damn slow. so beyond eclipse, there is this great text editor which has great design. we never had the great ctrl+P option in eclipse as far as i can remember where you can jump to definitions, say I have a 100 files project and I want to change the GetUseFunction then I ctrl+P and type the function names, it tells me all the function names and lets me go to the function name directly.

I am not aware if that feature is available in other editors, I tried light table for a short time, but it isn't getting much attention since they are working on some other product. ctrl +P transformed the way i write go code, now I dont' have to bother to remember which file stored what, just ctrl +P function name, as i know what all functions I am using or I can just scroll!

Ctrl+P was taken from Sublime, which in turn took that from TextMate. I think.

VSCode and Atom are essentially just Sublime Text with Javascript instead of Python as the plugin language. Also, IntelliJ has had this for quite some time, though it doesn't meet the criteria for light weight text editor, it is certainly better than Eclipse.

While I do agree that VS Code is nothing revolutionary, suggesting Vim and Emacs are superior at this day and age makes no sense. Becoming effective at using these editors is very hard and not practical when there are so many other things any engineer worth their salt has to worry about. Most plugin systems for these tools are a nightmare. Vim has about three or four different plugin solutions and they all have different caveats.

While I agree with regards to Vim, I don't really see how Emacs is hard and impractical. It doesn't have modal editing, you just open a file and write, and the plugin system is built-in.

I do, however, agree with you. Mostly because you can customize Atom and VSCode to have all the same benefits as Emacs and Vim. Except for running them in the console, which I know some people like having the option of doing.

I used emacs as my primary editor for 22 years but switched to clion last year for c/c++ development and am thinking of switching to pycharm for python stuff.

I still use emacs for quick editing, moderately complex search-and-replace in limited numbers of files (for when I don't want to bother with perl), and a handy scratchpad for throwaway things, but I don't intend to do a lot more software development in it anymore.

Compared to Vim's learning curve, the Wall from GoT is just a small speed bump. I have tried to learn vim for 10 years now and just cannot get past the initial stages.

Please, elaborate how VSCode changed the way we write code on Unix? I mean, repeat your statement out loud and ask yourself how big statement you just said. No way in hell how VSCode change the way we write code as much as you stated, no way even Atom did that. Like it or not TextMate came first, and soon after that Sublime Text took over. Yeah, like it or hate it, ST with it’s very well known default monokai theme changed most of the things in terms of GUI Editors for programming.

I mean, what is going on, why people tend to blow VSCode out of the water about how good it is!? I mean, ok it is cool, has some really nifty features I would like to have in some X editor, but no way in hell it is as game-changing as people state. And I really can't see my self switching from Vim to VSCode. Even when I decide to use GUI Editor (I am not HC vim user, for some environments I use it, for others I don't), it is Sublime. I ditched Sublime for Atom since December, and on OS X, it is working very well. Not blazingly fast and smooth as Sublime, but it is far far better than before.

But all in all I am not biting that Electron base for text editor. I mean ok, JS is cool, web is the future, flexible cross-platform solutions are the thing, but it still isn't comparable to native stuff. At least to me, it is getting there year by year but still a long way to go.

At work I write Scala and the IntelliJ Scala support is simply unbeatable. It's refactoring engine etc. is fully Scalafied -- when you paste Java code, there's even a "translate to Scala" function offered. I use a "vim mode" plugin that allows me to hope around with 25j and such.

For my personal project (which is in Rust) I use Atom, which is new for me, but I find to be really impressive. Both its plugin system (which allow for all the extensibility and in my case Rust support) is fantastic, and I don't know where the complaints about speed come from (it's far lighter than IntelliJ, obviously).

I've really been enjoying Atom when I do use it, and don't see why I'd switch to VSCode unless it had better support for Rust. But perhaps I'm missing something.

While I find Atom really nice, and having growing sympathies for it, it definitely feels sluggish compared to Sublime. It is that 0.3-0.7 seconds that make a difference when we are talking about day to day tool usages.

I am a bit turned off by VSCode, it's workflow by the looks of it feel strange to me. Yes I've tried it, yes it was in beta, but right now I am having only Vim on my Mac. Uninstalled Atom this morning, got a little bit frustrated.

It just feels like a web app, I mean it basically is. And when I dragged it to AppCleaner, it is so heavy, 260MB+.

I want GitHub to stream line it. If other were able (look at VSCode for example) that GitHub can. That things leaks memory very now and then. Sublime feels rock solid and blazingly fast compared to Atom, and there you see the difference between native and web. Those fractions of seconds are important when you have app like text editor, especially if used by developers and geeks. :)

Really? VSCode has already transformed the way code was written on Unix/Linux? I beg to differ. 10 years ago (when I discovered Eclipse, not sure when it was originally released), Eclipse was a staggering leap forward for Java programming. I'm no Eclipse fan, but I don't think that VSCode has already changed the world in the way that Eclipse did, and certainly not in its short lifespan.

I think what the parent meant was that VSC (along with Atom, and to lesser extent SublimeText) is a good example of "the middle way" that is rapidly gaining popularity. First we had console editors, but they weren't powerful enough, especially for newer languages/frameworks. Then we had full IDEs (VS/Eclipse/IntelliJ), but they got to be slow and clunky. Now the trend is toward "enhanced text editors" (VSC/Atom/ST): editors that can have modular plugin functionality and interact with the console so you don't lose any of its versatility. They're usually faster and more lightweight than IDEs but keep most of what you need. The parent is saying that Eclipse was the flagship of "Generation 2" and VSC is for "Generation 3"

And remember, no one is saying you have to use these programs. Console editors and IDEs will still be here. This is another option for people who want it, which has turned out to be a lot of people.

What part of the IDE's is slow and clunky. Is it just startup you're talking about or other parts? I'm a heavy Intellij user as well as vi user and, apart from startup, don't notice any speed differences.

When you've got 10 subprojects open and every few new lines of code you save your file, resulting in a build triggering a cascade of plugin actions and more than a few seconds of mouse spinning, then yeah IDEs are slow and clunky.

When my IDE stops working one morning because yesterday's system crash resulted in a plugin being unable to load properly and subsequently peppering me with dialog boxes or worse, crashing the IDE, then it is definitely clunky.

When I just want to do code browsing across 500,000 lines of code and it takes 2-3 seconds every time I hover over a symbol just to populate the object list, that is slow.

Your experience sounds great. My experience has been that every IDE configuration falls into rot after 6 months to a year or so and the whole thing needs to be deleted and reinstalled. That's also slow.

Meanwhile, vim+ctags+gdb have given me years of reliable service. More than once I've had an IDE collapse into a pile of errors and turned to my trusty basic tools, only to leave the IDE as the steaming mess that it turned into for weeks or even months as I just didn't need that browsing or inline debugging power at the time.

It seems to me that if you were to disable the plugins, then you're kind of back to the equivalent of vim+ctags+gdb functionality. So, when saying an IDE is slow and clunky compared to an editor aren't you comparing apples and oranges?

Have you considered disabling some of those plugins? the functionality they give you is not worth the performance hit. Using an IDE does not mean you can't use the terminal at all.

I kind of agree with this. The thing is, Emacs has always been "Generation 3" in your terminology. Atom and VSC are kind of bringing the Emacs way (extension language is implementation language, not restricted to a narrow plugin API) to a new generation, along with the graphical experience that Emacs doesn't provide (yes, I use GUI Emacs. Yes, Spacemacs is nice. Atom with Material-UI plugin is still prettier).

I'll be an Emacs user for life, but I am currently recommending Atom to people wanting to move away from language-specific IDEs and dabble in a text editor, because it has enough of the Emacs nature while not being too daunting.

What I'm taking issue with is the description of VSC as "changing the way we code on Unix/Linux". Given your interpretation, Atom and SublimeText and other tools predate VSC and fill much the same role. So I don't see VSC as being transformative in that way. That's not to say it might not be a nice tool, but it's not a revolution either.

I understand; I just think you're being a little harsh on the OP, even if their language was a bit exuberant. They said they tried Atom and found it too slow, so if VSC was the first "3rd gen editor" (a term I just made up) that was usable in their workflow, then for them, it is a revolution. Assume good faith when comments are ambiguous :)

Yep, that's what I meant, earlier I didn't have such an awesome text editor with git inbuilt, eclipse is clunky and stuff, vi and emacs are too hard to learn, didn't have that much time to learn every small stuff that vi can do, so vscode changed the way I write code, and for most of the "new" developers, it will change the way they write code, gone are the days when you are staring at the screen wondering what was that shortcut. at least for developing webapps

Eclipse is not a code editor. It's an IDE. It offers a bazillion things out of the box (a lot of it that VS doesn't do without Resharper), but you're going to pay the price in terms of performance and RAM, sure.

I would strongly suggest that at some point in your career, you take the time to learn either vi or Emacs, even if you still use VS Code everything.

I do use vi, it is amazing, but if I want to develop a large web app then I'd rather use vscode and use vi when I am in the geek mode and don't have to manage a lot of files. Thanks for the tip :)

> First we had console editors, [...] Then we had full IDEs [...] Now the trend is toward "enhanced text editors" (VSC/Atom/ST): editors that can have modular plugin functionality and interact with the console so you don't lose any of its versatility. They're usually faster and more lightweight than IDEs but keep most of what you need

Emacs has functioned as an "advanced text editor" for at least 20 years and probably longer. There's a very common misconception that Emacs is a "console editor", but the reality is that when you first launch it in a windowed environment you get something that looks an awful lot like Sublime, VSCode & Atom: a text editor window with a menubar and toolbar similar (yes, it's not perfect!) to what you'd expect from any other editor native to your chosen platform.

The time investment involved in learning how to use it is also considerably less than implied elsewhere in this thread. In fact I really doubt that it's significantly more than you'd have to spend educating yourself about any other "advanced editor"'s configuration, keybindings for non-obvious actions, extension mechanism, etc. It's easy enough to learn the (admittedly unconventional) keybindings for a handful of common things like opening and saving files when you have the menus to refer to, and by default it'll even open a buffer containing clickable hyperlinks to helpful things like tutorials. I still haven't seen an editor or IDE with better built-in help.

Even configuring Emacs isn't all that hard: there's a built-in interface for installing packages, most of which will pretty-much auto-activate once installed (i.e. less need to mess around with elisp), and for changing configuration there's "customize", which is a nicer way to change configuration variables than just editing a JSON file. When you do have to start writing some elisp code (you'll almost certainly have to write a little) the documentation is superb and there are more than enough resources on the web to help you. A programmer who is already familiar with a dynamic language like JS will probably have less trouble learning elisp than a C programmer did 20 years ago.

None of which is to say that there aren't areas where Emacs isn't behind. I'd like to see better support for projects, snippets and auto-completion out of the box, as well as being more nicely pre-configured for popular languages like JavaScript and Python. Emacs 24 is four years old at this point, and that's a very long time for any developer tool to stay still.

These days I'd say the most confusing thing about Emacs is working out which of the many competing packages you should choose for whatever it is you're trying to do. Age is working against it here, because what was the almost-universally-recommended package five years ago - for which you'll get plenty of helpful google search results - has often been superceded by something better.

But with a handful of plugins installed (yasnippet, helm, projectile, auto-complete) it's (IMO of course) still the best editor out there.

Emacs doesn't have tabs. You can spin that any way you want: that tabs are an inefficient system, that tabs are limited, that Emacs offers more powerful systems but right now Emacs doesn't offer non-manually managed tabs respecting the tabbed interface convention found in any mainstream editor or even mainstream application (web browsers, etc.).

Noticeably missing from your list: IntelliJ and JetBrains's family of IDEs.

I understand that VSCode has changed coding for you. But how has it changed anything for the 92.8%[0] of developers that don't use VSCode?

[0] http://stackoverflow.com/research/developer-survey-2016#tech...

Intellij is an absolute beast of an IDE (in both senses, it's amazing and huge).

I haven't loved working with a tool so much since Delphi 6, it has plugins for everything I want to do, they work really well, I can have a project open and use multiple languages seamlessly, it's extremely customisable.

It's right up there with Linux in my "tools I wouldn't want to live without" category.

That said as a lightweight alternative when I don't need an IDE I'm very much liking vscode, it's a strange world when my favourite linux editor is made by microsoft.

The only bad part about Jetbrains is that no matter how much i've tried i can't use a text editor without feeling crippled.

A big factor is probably that I started programming using Jetbrains tools (except some c++ in codeblocks before that). It's so awesome everything else just sucks.

The problem is when i want to try some language that is not well supported by IntelliJ. No matter how cool the language is i get frustrated by editors like sublime/atom/emacs.

I know what you mean, I started programming back in the 80's as a kid so I spent about a decade without anything that looks like a modern IDE and since then I've used nothing but IDE's, I can live without an IDE but I seldom want to, it just suits my programming style.

Most importantly I always miss "Go to definition" that usually doesn't work (well?) in editors. Also in javascript. The exploratory power that comes with that is also incredible. I don't need to read your damn docs (unless the module is heavyweight and needs studying), I just want to be sure I called your mehod with the arguments in the correct order ffs!!

"Go to definition" works great in vscode. I tried it with golang and it also has the feature to show definitions inline :)

VSCode doesn't even change the way code was written on Mac or Windows.

Let me turn the question around. What does VSCode do that Sublime, Atom, Emacs and Vim doesn't? Nothing.

That is not to say that VSCode is bad. It's a decent editor. But the only reason I found Atom and VSCode to be interesting at all, was that way more people know Javascript than ELisp or VimScript, and so I figuere that the quality and quantity of plugins will be better on VSCode or Atom in time compared to the other two editors.

The switch to Atom was actually pretty simple. Many Emacs shortcuts still worked, and setting up a linter and multiple cursors was easy.

Another thing is that there are GUI versions of both Vim and Emacs. You don't, however, have a console version of VSCode, which means you can't use it over SSH. This isn't that big of a deal for some people (maybe even most), but for sysadmins logging in to a server to do some work, access to their editor of choice would be great.

The problem with your statement, and why you receive downvotes, is that you reveal that you really don't know what you're talking about.

>VSCode doesn't even change the way code was written on Mac or Windows.

That's probably because those two platforms have already had superior tools for a long time. On Linux, vim reigns supreme. So it is easier to revolutionize code editing on Linux

All three platforms have had access to Vim, Emacs, LightTable and Sublime. VSCode brings nothing new to the table other than Javascript as a plugin-language.

The fact that you think that VSCode is revolutionary compared to vim, only displays your ignorance. Vim can do the exact same things VSCode can, and it has been able to do so for quite a bit longer.

Atom was around before VSCode and they feel roughly equivalent to me, no? They're both web browser based even...

I'm a heavy IDE and Emacs guy though, so perhaps I'm missing something.

I've been using both Atom and VSCode over the past few months and gradually got to the point where I just prefer VSCode. It's hard to pinpoint a specific reason, but it feels faster and a little more polished.

Agreed. I don't see anything in VSCode that's not present in any of the vast array of alternatives. But then again, I live in IntelliJ and Emacs land. I don't mind Atom but don't really use it for anything.

Light Table might deserve the term "transformative", but I didn't find it usable enough to rely on.

> Atom was around before VSCode

Nope. Visual Studio Code was created before Atom.[1] Although both VS Code and Atom are based on Electron[1] and are both Chrome-based. VS Code does seem to be stealing Atom's thunder as what they say [1]

[1] https://discuss.atom.io/t/atom-seems-to-be-lossing-contribut...


Atom = 2014


VSCode = 2015

Am I missing something? Sure, MS had some preview online IDE thing before VSCode came out, but that's not the same thing obviously.

Yes you are. Please read the original blog post. [1][2]

Visual Studio code was originated from "Monaco" team, dated back in 2013.

Eletron (formally Atom-shell) was dated in Feb-March 2014.[3]

[1] http://code.visualstudio.com/blogs/2016/04/14/vscode-1.0

[2] http://arstechnica.com/information-technology/2015/04/micros...

[3] https://en.wikipedia.org/wiki/Electron_(software_framework)

Yeah, but point is, it wasn't released until 2015. Which is the part that matters. Who cares if they started developing something tangentially related to it 2 years earlier. Atom came out to the public first, and that's what matters in terms of plugins and such. I never heard anything about people making Monaco plugins, did you? VSCode was basically released because Electron came out. From the Atom devs. So while Monaco may have come first, VSCode certainly did not. And Monaco didn't offer the sort of things that VSCode and Atom focus on - namely community plugins.

So VS Code is based on Electron, but Electron came out the year after it?

That makes sense. I use things from the future all the time. /s

Electron (formerly called Atom-shell) was created for Atom.

The source you cited even says this!

Read this particular comment in that link.


If you liked Eclipse, then you should take a look at IntelliJ IDEA (and its companion IDEs), they are a leap forward from Eclipse.

Agreed, IntelliJ IDEA is so good I can't really use other editors for projects. For editing regular files outside of a project I still use vim or TextEdit/Notepad.

I prefer Intellij so much I use CLion instead of Xcode on OS X and Visual Studio on Windows 10.

I didnt think Clion worked with MSVC?

It probably doesn't. I use MinGW on Windows. Once Windows 10 adds the announced linux support I guess I'll start using that instead. :)

I can build .exe's that run fine on Windows this way and executables that run on OS X (using the X-Code supplied compiler and build tools that CLion depends on for OS X). I can get qt, wxWidgets and GLFW UIs working for both platforms from the same code base with CLion.

> gedit took way too much memory

So instead you decided to use an electron based editor?

Don't get me wrong, Atom and VSCode are both great. But "memory efficient" is not a word I'd use to describe either.

> but for the people like me who don't or can't use terminal based editors, VSCode is quite literally the best.

Sure, if you find fault with and don't use the 14 other options, the one you're left is, quite literally, the best.

> I do not like sublime as it isn't FOSS

VS Code is not FOSS, either, I believe? [EDIT: Wait... it is open source. Must have missed that announcement]

I do like it a lot, though. KomodoEdit is pretty neat, as well. Even though it's closer to a full IDE, it feels very responsive. If either VS Code or KomodoEdit added something like paredit, I'd switch to them.

All the responses to this comment seem to center around putting in many, many hours of work to get used to Vim or Emacs. I can't find a single comment about the rejection of Sublime Text because it costs $60. That's the usual complaint against it. To which I say: If you're a professional programmer, how many hours of your time does that come to, for an editor that will make you more productive for years?

As someone who got through engineering school on green screens and vi, I eventually cobbled together a massive collection of Vim plugins... to make it work, essentially like ST, with a side bar, tabs, fuzzy searching, and all of that. Once I discovered ST, I was happy to pay the measly $60 whole dollars for a license which I could run on all 3 desktop platforms, across half a dozen computers.

VSCode magically fits this one narrow set of definitions to reshape the field of coding on Linux and Mac? Are you even serious, or is this just trolling? You're going to let the fact that it's closed source remove it from your list? I obstinately ran Linux on the desktop for 19 years, but I know a good, pragmatic deal when I see it, open source or not.

What was lacking in Atom for you?

Atom is great in many ways, and I personally don't have any major complaints about speed, but it disappoints me in lots of little ways. For example, on two different machines, when I upgraded to 1.7.0, Atom failed to reopen my open tabs - they all became 'untitled'. And a couple of them were unsaved (my fault, of course, but I hadn't ever been burned by Sublime doing the same drill).

It's buggy. Plugins break all the time.

Also: Doesn't ask me to save my unsaved files when I close the editor. Sublime Text called this feature "hotexit", but in Atom there's no way to disable it.

it starts with the speed, atom is clunky and slow. If I do not have any other alternative them Atom is good enough, but geany and vscode are way way better than atom. I'd rather do all fancy plugin stuff of atom using python and use geany than use Atom because of its slow speed. I wonder why anyone isn't doing anything for that considering github is the company being atom and that vscode and atom both are based on electron yet vscode is so damn faster than atom

If you're wondering why the downvotes, the great editor war is the reason. I think your comment is valid, but what you could of said which makes the most sense to me is: VSCode has changed the way you yourself code on Unix / Linux as opposed to the way "EVERYONE" codes on Linux, if everyone dropped Vi(m) and Emacs for VSCode then that would speak volumes. I agree with you on Atom, though I've encountered an odd issue with VS Code where it freezes up completely on me, not sure what that's about.

> gedit took way too much memory

Can you elaborate?

I am fine with it taking as much memory as it took.

It is a great replacement for notepad, but that's what it is. wrong tool otherwise for a large project.

How much memory did it take? I assume that gedit would be very lightweight in terms of memory usage, maybe you hit a memory leak?

Oddly enough, on my machine a fresh gedit instance had bigger memory footprint than modestly tricked out emacs24.

How do people put up with VS Code and laggy text input though? I used it on Win10 and Linux and both occasions there is noticeably lag when typing.I look at the screen while I type most of the time and this lag makes coding impossible for me because I like to see what I'm writing in real time.

I've noticed this happen especially on big projects/files.

Also, sometimes the auto complete popup is very slow to appear and causes lag.

I don't use many GUI text editors and have not compared VS to Atom/sublime, but for me this is just unacceptable.

It's not laggy for me on any device I can run it on. I regularly use IntelliJ Idea and that feels sticky and slow compared to the input of VSCode.

For me, Kate was the solution to this since it uses text completion not code completion.

I use Visual Code for Golang, for everything else Linux has other stuff that's better imo. Like Netbeans and PyCharm. Seems like I should be using it for TypeScript.

what about node.js development?



Try building a large webapp in vi and then comment. These days what you do is more important than what you use to do it, use vi or emacs or some shitty text editor, but eventually you need a real IDE with a GUI, vi is great, I love it, but it isn't the thing to be used for a large web app.

>ut why spew uninformed bullshit when any semi-knowledgeable linux/unix dev knows that vim and emacs run laps around vscode, sublime, etc Because the rest of the entire world doesn't share your opinion.

if you really use vi for a large scale project then salute to you! I am fine with vscode, I want to get things done rather than learn my editor (read spend valuable time learning nooks and corners and the million shorcuts which I'd have rather spent on building my application product or startup)

I even wrote a short tutorial about writing webapps in golang: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...

all thanks to vscode + go plugin

I've built large web apps in vim.

Honestly you sound very misinformed. Vim is capable of pretty much everything that VS code is capable of and then some.


We've banned this account for repeatedly violating the HN guidelines.


>vim and emacs are much more powerful and flexible than eclipse, intellij, visual studio or other similar crap.

Nice claim, now do you have data to back up your claim? Meanwhile let me ask you a few quick questions.

Okay, how do you automatically organise imports in emacs? Can you jump to the declaration of an expression with just pressing one button? How do you extract functions or values quickly without having to fiddle around with copy paste? If you use a language with type inference can you quickly view the inferred type by pressing a single button?

Yes. There are plugins for all of this. When I was using Emacs, I could use omnisharp to navigate files using, yes, one button. There are refactoring tools for emacs as well, though I'm usually fine with just using multiple cursors (also a plugin) so I haven't tried them out.

All my billable work the last 3 years have been with Emacs (ok, except for the last month, that has been Atom). I have never missed the functionality of an IDE.

So, can VSCode run in a terminal window, without graphical user interface, while ssh'ed into another machine somewhere around the globe over a shitty internet connection, editing a file that's a few hundred megabytes big? As long as that's not possible it's not even a contest ;) I like VSCode because of it's debugger plugin infrastructure, but let's not get silly (MS changing the way code is written on Linux).

> editing a file that's a few hundred megabytes big? As long as that's not possible it's not even a contest ;)

I usually try to keep my source files and config files smaller than a few hundred megabytes. Sounds like you might need more specialized tools for your unusual approach to editing source code.

A good code editor should let you inspect that 800MB XML file your customer sent you.

Back in the days before I learned about vim, Textmate was the choice for editing huge data files.

Didn't ever understand people who used it for the things Notepad++ could do back then though.

If your development work mainly consists of ssh'ing into remote machines over a shitty internet connection and then editing files that are megabytes big, I think you should reconsider your development workflow.

I realize that's a pretty harsh statement but that really sounds like the worst possible way to go around writing code.

Yes, you can using `ssh -X` (except for the "in a terminal" part)

what percentage of your coding time do you spend doing things like that? rhapsodising over your text editor is a long-standing unix tradition; no reason vscode fans cannot be part of that!

I switched from Atom to VSCode for Go development on OSX a few weeks ago while Atom's Go plugin was going through a rough few days, and haven't been able to go back.

The patterns of use take a little getting used to coming from Atom or Sublime, but VSCode gives me real static-language IDE features that "just work" simply by installing the Go plugin. Comparable functionality in Atom requires multiple plugins and I never managed to make a few of them work at all. The control+tab file switching quickly became second nature.

I never had the performance issues some people have with Atom (on a 5 year old laptop), but VSCode feels a little quicker at some things. Nothing to write home about.

I love Atom's direction (plugability, a well-cultivated ecosystem, discoverable configuration), but for sheer usability I'm sticking with VSCode for now.

I never switched to Atom (from WebStorm), but I've made the switch to VSCode and I like it!

It just works. The workflow is fine for me, git integration is a plus. Compared to Atom, I don't need to try plugins to get descent functionality.

Actually, it's the first MS product I use in like... 10 years?

I used to be an emacs fan, I used to be an Eclipse plugin developer, I used to be a WebStorm user... now I prefer VSCode.

I love how it makes the best of screen real estate compared to WebStorm

I'm your standard unix greybeard, the sort that uses org-mode to outline-structure their emacs config (that's actually what I do, not even a hypothetical), so I approached VSCode with skepticism.

I have actually been really impressed. It's fast and responsive, even on Linux, and the TypeScript tooling is fantastic. I think with a bit more UI work (like vi keybindings) it could potentially become my preferred editor.

I'm chuckling (not in a bad way!) at the emacs user that prefers vi keybindings expressing optimism about a Microsoft editor written in a statically typed variant of Javascript. Progress is cool.

I try my hardest to not be dogmatic, and my answer to the argument about vi having better keybindings while emacs having better extensibility is "why not both?" :) JavaScript is almost an acceptable lisp, too...

Why? emacs has had an "evil mode" (vi keybindings) for a while

additionally i would mention that this "Microsoft editor" runs with a web browser engine by google

You made my day. Didn't even notice the irony... :D

I've seen the vi keybindings complaint a few times in here, and it's my major complaint as well. There are a few plugins, but they just aren't even close to usable in my opinion.

amVim is doing well, and I can attest that its maintainer is both sharp and very humble (in contrast to a lot of what I've seen come out of this nouveau-OSS era that GitHub seems to have ushered in). It's a shame that more people seem to have flocked to the VSCodeVim extension instead. I guess there's something to be said for being the first to grab the "Vim" label to apply to yourself.

Having said all that, many of the unimplemented parts in extensions across the board come down to limitations in the VSCode extension APIs. I've been watching the VSCode team, and they're actually pretty sharp and welcoming, too, so most issues should be ironed out, given enough time. (Although it hasn't been prioritized at this point.)

However, the appropriate unit of measurement to describe how long I've been using Vim is "decades", and through observing (but never seriously using) the attempts to emulate it over the years, I've spent a lot of time thinking about what it would actually take for an app to really support Vim keybindings—aside from actually just being Vim. Unfortunately, even if we assume a team with infinite resources intent on achieving perfection, there are several things about Vim that prove to be irreconcilable with the way almost every interested app is implemented. The only way around this will have to come down to Vim users either collectively participating in some "Great Vim Shift", or just ignoring the remaining gaps entirely and continuing to put up with incomplete emulations.

Hi, we met again! Thanks for the positive words! Appreciated!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact