I tried it, liked that it was faster than Atom at the time (though the gap has shrunk, as I understand it), but couldn't deal with it having an "only one open project" model. That was a deal-breaker for me. All of my stuff is broken out into many small projects, and I'm trying to go further in that direction rather than toward more monolithic codebases.
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.
Cool. I'll give it another go when I have some time to play. But honestly, most of the stuff I didn't like about Atom is resolved lately. It's fast enough, small enough (for my 16GB laptop), and reliable. And, has a gazillion features, most of which I never use.
I've never used it for anything quite that large. I have three windows open on my first virtual desktop: Editor, terminal, and browser. When I want to poke around in log files or other really long files, I'm using grep, tail, awk, and Perl (and vim), in the terminal.
The biggest file I regularly work with in the editor is 10,631 lines long (I just checked, and it's longer than I thought). Atom works fine with it, including syntax highlighting, and cutting/pasting/typing/etc.
Actually...out of curiosity, I just opened up a ~110,000 line file (a log I had laying around). It seems to work fine. It took a little longer to open than it would in vim (which is effectively instant), but not as long as I would have expected. It was well under a second, and within my comfort zone for opening files. Switching tabs seems maybe a little more sluggish with it loaded, but not uncomfortably so.
I think I have to accept Atom into the category of editors that can work with pretty large files. I can't imagine having a source file any longer than that 10,000 line file I work with regularly (and I would never make a file that large, but historic codebases sometimes have weird things in them), but it seems like it'll work even if someone did.
I think it is less the line count that I have problems with lately than line length. It's quite a specific use case, but I work with geographic data and occasionally deal with absolutely enormous wkb's that can be in the hundreds of thousands of characters. Couple that with writing in Hadoop typically going to one line per JSON representation and now I am regularly opening files to review that consist of a single line of text that might have upwards of 80,000 characters on average. Even beautified it still is problematic. VS code seems to be able to do it reasonably so the software stack cannot be blamed.
Tried VSCode. Thought Atom was still a cleaner experience.
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.
This has been my experience as well. I really wanted to like Atom, but then I tried VSC. It's an incredibly well done editor, and it doesn't feel nearly as laggy as the average Electron app.
I loved c# 10 years ago but have a few issues with it these days:
* 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.
C# is a great language no doubt (been using it professionally since the early 2000's) but it always felt sluggish when creating complex forms and handling events in those forms where Delphi, C++/Qt and even Lazarus feel much faster.
> I still consider C# best language I ever learned.
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.
It's a big company, and they are not 100% evil because no company is 100% anything.
And honestly, I believe any company with a stranglehold on any market will behave badly. Rather than being salty at Microsoft in particular, let's make sure no company ever has such a stranglehold on computing again.
I didn't claim that Microsoft was unique in anything but the 3E strategy itself.
Actually, what with Google duplicating more and more of Android's core open-source functionality into their proprietary apps and then leaving the open-source code to rot ... Microsoft isn't unique in that way, either.
But more importantly...
> let's make sure no company ever has such a stranglehold on computing again.
That's a long road ahead, since Google has a monopoly on the average user's very mind. And don't forget that Microsoft hasn't lost their stranglehold either, except among programmers and similar personnel. They may be behind on mobile, but they've held onto largely the same markets+marketshares that they had in the late 90's (plus more, though not at monopoly scale, thanks to Azure), and desktops+laptops won't be dying anytime soon.
Yes, big files has always been the major issue for me.
I always kept sublime text around for some larger files and ultimately decided I would only stick with a single editor.
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.
I’m using proto-repl, bracket matcher, lisp-paredit (mostly disabled, used for better auto indents), and parinfer (simply wonderful).
I based a lot of my setup on this gist [1]. My dotfiles are here [2]. I have it set up so that ‘zc’ connects to an nREPL, ‘zb’ evaluates the top block under the cursor, and ‘zz’ evaluates the entire file.
VSCode is probably technically superior, but I just can't get past the icon. It looks pretty ugly IMO and it's significantly bigger than all the others in my dock so it stands out like a sore thumb.
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.