The fact that VS Code's version isn't ready yet, and Atom's is makes me think that Microsoft wanted to respond to Atom's announcement. But I honestly have no idea if that's the case. Just pure speculation.

Edit: Atom's announcement was yesterday. Microsoft's was today. That further fuels my speculative hunch. :)

Microsoft employee here. Today is also the Connect conference. My colleagues who worked on live share knew all along that Connect is their deadline.

Which makes me curious, does Github know what Microsoft is going to announce at their conference, or did Microsoft knew what Github is building?

It looks like one of the main authors of atom is presenting today at QConSF too. Seems like dumb luck. :D

Yeah, appears to be dumb luck. You don't put together branding and a demo of real-time collaborative editing in a day.

I prefer to imagine that great minds think alike! :) Or more scientifically speaking, the theory of multiple discovery [1].

[1] https://en.wikipedia.org/wiki/Multiple_discovery

The amount of [citation needed]s in that article is too high.

Or it's based on some paired programming hype/growth/buzz that happened months ago and both decided to implement it as an option. I mean it takes a while to implement complex feature sets like this, so maybe some trend in the industry got people in both communities trying to implement this at the same time?

It's not exactly groundbreaking. SubEthaedit did it years ago.

My hack-a-thon team did it in 48 hours this weekend, lol. https://www.nodeknockout.com/entries/35-nodeist-colony

You put developed "the world's most advanced code collaboration experience" as advertised by the website in 48 hours ? Can I hire you somewhere ?

not sure it really matters, either way, we win :) By we I mean coders.

I have a hard time imagining that Microsoft would make a decision like that in under 24 hours.

Microsoft is not known for finesse in their marketing tactics.

Just had a déjà vu with Microsoft's NetPC, announced just after Sun Microsystem's Network Computers.

That said, I do like VS Code very much. Gave Atom a try, but it felt sluggish and its add-ons were very fragile.

VS Code is certainly neat, but with the rush to cram everything into it, it's starting to feel more like emacs than vi.

That VS Code is not Emacs-like, that’s my problem with it.

In my experience nothing beats Emacs at editing text. Vim has better shortcuts, but Emacs is just smart about everything.

My problem with Emacs is that it’s showing its age, it’s hard to configure and you have to learn an old and obscure LISP dialect for it. On the other hand I’ve heard that VS Code plugins are a joy to develop, MS apparently did a good job at that.

But Emacs? Yes please, I want that — plus to be honest, in 20 years from now Emacs will still be around, whereas I have my doubts about these fancy new editors.

> you have to learn an old and obscure LISP dialect for it

As someone who is glancingly familiar with emacs (I have only ever written one elisp function, that too with help) it's a really stupid question, but couldn't emacs have bindings for lua or python or something? That would increase the number of people who can program for it and customize it.

> in 20 years from now Emacs will still be around

I think the real risk for emacs is, over the years, slowly losing the pool of people who care enough to contribute to it -- not just core developers, but also people who write packages, themes, etc. I already see a lot of developers who think Atom / VSCode / Sublime Text is "good enough". You may choose to discount Sublime because it's closed source (I do despite loving it otherwise), but VSCode and Atom are open-source and browser technology is only going to get better.

> but couldn't emacs have bindings for lua or python or something?

It can, and here is an example: https://blag.bcc32.com/ecaml-getting-started/2017/11/05/emac...

And here is a better link I guess: http://diobla.info/blog-archive/modules-tut.html

Elisp would still a better much better language than python or Ruby (for emacs), especially now that lexical binding is becoming standard. Emacs people would like to move to scheme, if anything. (even RMS wishes emacs would move to scheme.)

But there is an Emacs clone with JS bindings, and it's called Atom.

Emacs is a lisp; there's a very small and tiny layer of C at the bottom and everything else is a tower of lisp. You can interact with it with other languages, via many different means, but in the process you lose the joy and power of working in a live lisp environment.

> there's a very small and tiny layer of C at the bottom [...]

That layer of C is hardly "tiny." Everything from font drivers to process management to a lisp interpreter to window and buffer code, to overlays, and a lot more.

There's 1,262,537 lines of elisp in 25.3, compared to 291,203 lines of C and C headers. While there is a fair amount of C code to do what you mentioned, much of the C is definitions for the core lisp language with 1,483 DEFUN statements in it.

But yah, not tiny, sure. I'm looking forward to it being replaced via the REmacs project.

https://github.com/Wilfred/remacs

I doubt any Electron-based editor is going to feel as snappy and light as Vi. Have you been noticing performance decreases? I haven't noticed any.

> feel as snappy and light as Vi.

this is only true if we're strictly talking editing text wihtout any plugin functionality. As soon as you add code completion features vim shows its age, the Ale extension for async linting for example feels very sluggish on a few only slightly dated laptops I tried out and frequently grills the cpu.

I also noticed ALE was very slow with JavaScript so changed it to run on save only.

However Neovim’s plug-in architecture is a big improvement. I’m running Deoplete (which provides intellisense like functionality) on the same machine, and it is basically instant. There are GIFs at the bottom of the repo:

https://github.com/Shougo/deoplete.nvim

Hey, thanks for that tip. This is really great. I'd never used neovim and almost switched to vs code but this is working really well!

This. Vim also has a nasty habit of hanging completely if something goes wrong at the filesystem level (e.g. a disconnected sshfs mount).

VS Code is trying hard to be an IDE for all languages. If you use pure VS code without extensions, it quite snappy. But as you start adding more and more extensions, it starts slowing down and that too quite fast.

This is true, but its still very snappy for an electron app.

After adding around 10+ plugins on Atom it not only became slower but it started crashing or having internal errors.

With VS code I have 17 plugins installed and it still feels light enough. Personally I disable most plugins until I need them and I think most people should do the same considering how easy it is to disable a plugin.

I have all my language specific plugins disabled until I need to use them.

Serious question—

Does/would a high-end (e.g., Xeon-class) processor and/or a boatload of RAM help keep Code's performance snappy?

FWIW, I run my Code install quite light since my "duties and responsibilities", ahem, only require a few languages/data types, ergo, I am not pushing it hard at all.

FTR, I have a (licensed) install of Sublime, which I confess is snappier than Code, but the difference is so small I use whichever one is better for the task at hand and any difference dissappears under the pressure of an outage enforced deadline :-D

So you think it is awesome then?

Nothing but love for emacs, props to those who use it.

But?

Just making the point that it went from a simple text editor to a much more full-featured IDE wanna-be. That's a bit of a paradigm shift to me.

That's why I've been using Atom instead. Since 1.17 or so it got quite usable and it's getting better with every iteration. Nowhere near as fast as Sublime Text but usable for daily coding. I disabled the git plugin because we're using fossil. I hope it doesn't become an IDE like VS Code. At least they made the IDE packages separate.

Regarding fossil, do you use fossil for tickets and self-hosting? How well do fossil tickets work compared to Github issues? Do you use any custom themes for fossil tickets?

We used tickets somewhat and we are self hosting through a nginx proxy in order to log the http activity and proxy over https. The ticketing has markdown support. We use a custom theme, not for tickets but for the whole repo. Fossil tickets are only used internally, we use osticket regular ticketing.

There is also a service for hosting fossil repos called Chisel, but it's nowhere near as useful as Github.

http://chiselapp.com/

Thanks!

Are you sure Atom's was yesterday? The blog posted is dated 15 November.

Wouldn't it be nice for VS Live Share and Teletype to be compatible on protocol-level?

(Several years of realtime editing experience reporting in)

Plain text CRDT and OT systems are often mutually adaptable. Even if they aren't directly compatible, with a bit of work it'll probably be possible to adapt from one realtime editing protocol to the other.

Of course, in the medium to long term having a standard for OT/CRDT operations that works in a lot of source code editors would be fantastic.

That would be nice. https://xkcd.com/927/

I don't think VS Live Share counts as a standard, though. :)

Why is there breakneck competition here to offer the best free code editor?

I guess that when users make the habit of using the free tool, then the company that provides it can easily embed other convenience habits that could potentially lead to a future sale.

Both Microsoft and Github have commercial products to sell at a later stage, VSCode has now integrations with Azure, I don't know about Github integrations on Atom but the potential is there.

When the user is using your free tool you are one step closer to provide something additional that is so convenient that is hard to say no, even if is paid.

They're working on making Atom + Github to be a 1-1 association in your Git workflow. See https://github.atom.io/

Ballmer's Law: "Developers, developers, developers." If you want to be a platform vendor, you need to have developers. Lose the developers and you lose the business.

Microsoft has been a platform vendor for a long time. VSCode is part of their argument for why they should continue to be one.

I know, right? Vim and emacs should ease off a little :)

What I'm interested in is whether Live Code Share is a free service.... feels like it might be a paid service. Or limited free then pay? Not sure. It's also for visual studio.

Also be interesting if someone makes a teletype plugin for VSCode :)

The main reason I read this thread was to compare both announcements.

I was just noticing the same, looking at my HN feed. It's higly remarkable, to say the least.

Came here to make the same comment :D