That one factor was a deal-breaker and I went back to Atom (though I still use vim just as often as Atom, since I don't have every project open in Atom at any given time, and sometimes I just need to edit one file really quick and check it in).
VSCode is very good. But, as long as it's got a one-project model, I can't do anything with it.
Package system doesn't get much better than Atom. I think my code looks better on Atom (still not better than Sublime). I also ran into setup problems with VSCode git support on Linux.
* functions not really being first-class citizens * great collection methods with LINQ, but why did they give them such weird names? (map = select, filter = where, reduce = aggregate?) * took them a while to come up with a great async model (async/await), so legacy c# asynchronous code can be hard to figure out at first
Just my opinion but it seems like more recent languages like Swift have done a better job implementing ideas from functional programming. It's still light years ahead of Java to me though.
Thus you clearly have not learned F#, nor any other (superior) Standard ML descendant (e.g. OCaml or Rust).
(Why is F# inferior, you ask? CLR interoperation requires using types and datastructures defined in C# code, which overall mean that you will use an unidiomatic style. Hence, F# is basically "a usually-less-annoying C#", unlike other SML-likes. Except Scala, whose best description is "F# on the JVM".)
Does this include the Embrace+Extend+Extinguish strategy?
And how does anyone, other than via sheer forgetfulness, think that Microsoft doesn't have similar nefariousness on today's drawing board? The revelation of the 3E strategy showed they are inherently and absolutely untrustworthy.
Atom just could not handle big files well, and years of waiting sadly didn't yield big enough results.
Another co-worker is the one who put together proto-repl for Atom so you'll see a lot of similar functionality in the two. I still use Atom and proto-repl just because I've been too lazy to get familiar with VSCode. But when James has demoed the debugger functionality in his VSCode plugin it looks great.
Honestly, work with Atom open for a day or two on the same project, that's not uncommon right? Prepare yourself for some serious type lag.
Full disclosure, I run a Linux desktop with 32GB of RAM. I'm not accustomed to type lag. Judging by your downvotes it's an acquired taste.
Yes, Electron apps consume a bunch of RAM. Yes, Rust needs you to deal with data lifetimes. Yes, Go still doesn't have generics. Yes, Haskell has a steep learning curve if you learned imperative languages first.
No, restating those facts on HN at every opportunity is not constructive.
I dunno, I have the same Atom instance open on Linux for weeks with 20+ files open, I haven't experienced any noticeable lag. Maybe I'm just not as sensitive to the sort of lag you're experiencing.
iMac with 32GB RAM here, and I routinely work with 10+ tabs open with files of 1000-2000 lines of code, and never really noticed and lag or crashing in Atom?
I leave Atom open and running 24/7 for days at a time. In fact, this morning was the first time I remember restarting Atom in over a fortnight because I installed 1.2.
1) Old Linux laptop with 4GB of RAM which I leave open for days on end without issues
2) Linux VM on virtualbox on my 8GB Ram desktop. I went for months leaving Atom open in the VM (saving it day to day) without issues
I'm not even using an up to date version of Atom? I know Atom is not great with very large files (it warns you before you open them) but for me this is only things like logs which I read from the command line with tail and grep. I have no need to open large files in my coding editor.
Atom is big, but I haven't noticed any lag or seemingly memory-leaky behavior. Maybe one of the plugins you use is causing it?
I wonder why you get type lag, maybe you're working with really large files?
And, it's a pretty decent rebuttal to the questions folks raise about the decision to build on Electron in Javascript. The tradeoffs are big (memory, startup time, performance), but the benefits are maybe bigger (huge dev community, tremendous resources being thrown at the biggest problems in the form of work on the JavaScript engine and language, easy-ish entry for new developers, etc.). Even with all of its flaws, it's still a better experience enough of the time for enough of the people that it's become one of the most popular editors almost overnight.
Then again Atom has a nice UI. Maybe in the future...
As others above have said, me included, never experienced what you describe.
I like the customization of Sublime, and I've got it setup just how I like. In a way, Vim is similar... once you get it customized perfectly, there isn't going to be another text editor that beats it.
VScode is nice, but I don't really see any pros to it that would make me switch from Sublime, other than the Debugger maybe (which I never use).
For me, the killer feature of editors like Atom and VS Code is zero-hassle setup of linters and code formatters. The integrations with Go tools will not only tell you what is wrong with your code as you work, they will automatically manage your imports directives and reformat the source.
Periodically I think about switching to Vim. I am sure that I could set up Vim to have the same features, but I feel like I might have to find a big chunk of time to learn how to manage Vim plugins and the appropriate key combinations to get the same effect.
I've recently switched from VSCode to Vim and have really started to like it. I try to use Vim keybindings in everything I do, including browsing on Chrome with the plethora of Vim-like extensions.
I still use Sublime, mainly for its multi-cursor editing power. I don't there's an editor that can really match Sublime's multi-cursor feature. I know there's a way of doing in in Vim, but I'm still learning this language, and it seems like a difficult concept for me to grasp right now
