Live data from Hacker News

Visual Studio Code 1.0

code.visualstudio.com

61–70 of 487 posts

Re: Visual Studio Code 1.0

#61

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,…

> 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.

Atom & IntelliJ?

"gedit took too much memory" - what? It eats like 5-10Mb...

Re: Visual Studio Code 1.0

#62

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,…

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.

> 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...

Re: Visual Studio Code 1.0

#63
post #52

Earlier quoted context omitted.

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):…

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 :)

Re: Visual Studio Code 1.0

#64

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,…

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.

Re: Visual Studio Code 1.0

#65

Earlier quoted context omitted.

There are several actually, with different subsets of Vim. Sadly, none are as good as Atom's.

Hello - one of the team members from VS Code here. We built this extension sample to show the capabilities of the extension API - https://github.com/alexandrudima/vscode-vim . We've done some work to improve the API for the extensions. We'd love your feedback. https://github.com/Microsoft/vscode/issues/3600 .

The issue with Vim is that the editor has several hundred/thousand idioms and everybody uses a different subset. As an example, most people delete words with `dw` while I usually use `dt` because the t/f motions generalize to subwords. Until you have the majority of your personal subset implemented, vim support in a given editor is "bad".

I've thought about doing a vim implementation for years where motions are expressed as composable functions projecting from text range to text range with commands taking a list of text ranges, mostly because I'd like to whether non-text based motions (e.g. AST based or generalized cursors) would work. I like VSCode and expect to move over to it so I've thought about starting my project but the scope of doing a good implementation is daunting.

Congrats on the 1.0 release, VSCode is a great product.

Re: Visual Studio Code 1.0

#66
post #62

Earlier quoted context omitted.

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.

> 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...

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

The source you cited even says this!

Re: Visual Studio Code 1.0

#67
post #32

Earlier quoted context omitted.

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):…

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.

Re: Visual Studio Code 1.0

#68

Earlier quoted context omitted.

Can I ask what you'd be looking for out of a new editor that Vim doesn't already do for you? Hard to see the point of this comment.

Not suck at plugin management

https://github.com/VundleVim/Vundle.vim

Re: Visual Studio Code 1.0

#69
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.

Re: Visual Studio Code 1.0

#70
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.

Post reply on HN