The Era of Visual Studio Code

Today, Microsoft received an exclusive license for GPT-3. It is already known that it can write code if asked in natural language declaratively (in certain cases). I could see an integration with github's code (specifically retrained with) and see some really interesting stuff.

> I've never used CLion but I really want to.

Well, it has the best indexing of C++ I've seen but it's also the slowest IDE I've used (I've stopped using it when it froze showing a blank page for many minutes when I was compiling, since then it has improved, it no longer do this, but it's still very slow).

What's 'funny' is that all C++ IDE suck: CLion is awfully slow, VSCode likes to use >29GB of resident RAM if you let it open too long (no Vim isn't an IDE, it's a text editor which you can use to build an IDE yourself..) its indexing is quite bad most of the time, and also slow (enough that when I double click on something to get to the definition, I usually have the time to find/grep the source and open it myself before it has displayed the target :-()

Try Rider. I feel like it has all the usual JetBrains IDE features but it's faster than IDEA and the Unity integration is superb.

>I think there gonna come up with way to leverage the amount of data they can mine out of github repos to write code for you.

Somebody already did that in a plugin, trained a neural network on Github code to provide autocomplete for Visual Studio Code. I'm using it and it's great!

https://marketplace.visualstudio.com/items?itemName=TabNine....

> I've never used CLion but I really want to.

CLion user here and I think it is still behind IntelliJ and I wish JetBrains would put more focus to the product. That being said I believe it is way better for C/C++ and Rust development than any alternative that exists at the moment.

Definitely. Fedora + Android Studio + Kotlin is bonkers simple, clean and usable.

If you do decide to get a clion license, cppcast.com has a discount code for personal license which shaves 25% off the first year.

I won't post it here, just fish it out of the podcast, it's very nice.

They did something already https://github.com/features/codespaces

I'm not sure how performance is a problem for Intellij. Granted, I've only ever used Pycharm but I've never felt it sluggish or "slow" or got the impression I was waiting around for the IDE to do its thing. All this on a 2013 MBP with 16GB of RAM.

I've found it also works very well on Linux on a laptop with a i5-8250U and 16 GB of RAM.

The only thing that seems "slow" is starting up and indexing libraries and whatnot. Now I've never loaded the same projects in VSCode, but I'm not sure indexing would be that much faster and the startup doesn't really bother me, as I don't launch it multiple times a day.

I am running it most of the time with i7-8750H and also 64G or ram, plus a rather fast NVMe drive. Performance in comparison with VSCode is just bad. That being said I am using all JetBrain products (I have a license for all of them), because simply there is nothing better for my use case. But I wish they put some effort in optimising their code.

I know this is how a lot of people think of the text editor/IDE divide, but it’s just not true anymore: for specific languages like Clojure or Common Lisp, emacs has plugins that provide all the essential features of an IDE with minimal fuss. For JavaScript, VSCode or tide-mode for emacs have, in my experience, significantly better code intelligence than WebStorm. The only languages IntelliJ is better at than the competition, IME, are Java, Kotlin and Scala: and, even in these cases, the LSP tooling is catching up fast.

I've used both VSC and IntelliJ and I understand where you're coming from but when the parent comments says VSC is fast they really mean it. It's almost instantaneous and I can get a lot done in VSC even without all the complex smart functionality.

I'm a fanboy of both JetBrains and VSC. In the many years I've used JetBrains IDE variants (IntelliJ, Webstorm & Pycharm), I was never able to get rid of the frequent project re-indexing that slows everything down and makes the fans go crazy; you'd think they would cache that info and write it to disk.

You can have multiple project windows open in IntelliJ, and opening a project from an already-running instance takes only a few seconds, so I don’t think that’s really relevant.

I wonder if ZGC in Java 15, now that it is GA, would clean up any lag folks see.

I sometimes wish I hadn’t learned vim, because it limits the tools I’m happy using. Since I’ve built the vim muscle memory, every other text editing experience feels crippled, so I actively avoid products that don’t support at least basic vim key bindings. Luckily the list of products with vim bindings keeps growing.

Agreed. Converting other people is a fool's errand anyway. I am interested in things like EditorConfig to allow some similar settings between editors so that individual team members can use whatever software they like without affecting general code style. But I don't think EditorConfig is end-game and there's room to grow in this area.

> I tried migrating to neovim a lot of times, but their syntax highlighting is always so damn broken even with a plain vimrc that I stopped bothering anymore.

I haven't encountered highlighting issues in neovim, but the treesitter feature in the upcoming neovim 0.5 improves highlighting a lot. (It's a plugin at the moment that requires a bit of configuration. This is the simplest setup explanation I have found: https://www.reddit.com/r/neovim/comments/iw9nx5/moonfly_nigh... )

I tried kakoune out for a while but missed Vim's window management, had the same struggle fighting muscle memory that you describe, missed the ecosystem from Vim, and I think some of the criticisms of Kakoune here are also valid: https://github.com/noctuid/dotfiles/blob/master/emacs/editin....

What kind of problems have you ran into? I am not having any problems using VScode for C.

I tried it a loooong time ago, for C, and I couldn't get the hand of it, even though I had used IntelliJ a bunch.

I've heard it's much better than when they launched it, but our build system is so eccentric that I don't think it'd get along well at my work.

IdeaVim always seems extremely buggy to me compared to what I'm used to in vscode-vim

I think this is largely a matter of where on the stack you tend to work. VSCode is significantly better than IntelliJ/WebStorm for JavaScript projects: jump to definition and the various refactorings are, IME, more reliable on development environments based on tsserver like VSCode.

Seconded. The Dilbert plugin can also make the wait times more tolerable.

They're for separate clients. I've thought about doing something like a giant monorepo of client projects even though they aren't related. It's hacky at best, but ultimately I felt I should just use the right tool for the job and VSCode seems like a better fit for this scenario.

I'm sure someone else will benefit from this suggestion though. Intellij is pretty flexible and it is amazing what it can do, if you don't mind the performance trade-offs.

Ha! Every older point of sale software and every medical screen Seems to have that distinct java ui. Never liked it.

There are some pretty good theme options. Have a look at the material theme for example https://www.material-theme.com

With an exoskeleton I can lift a bigger hammer. A bigger hammer is more powerful.

> and expecting them to be skeuomorphic to a particular approach may hold us back

Whatever a programming language is, it has to be something you can hold onto in your head, because the human mind is where "programming" takes place. And there really aren't many forms that such a thing can take.

The step-sibling of programming languages, the mathematical proof, can really take any form we like; we're not limited to maths that can run on a computer, as long as we can "run" them in our minds. But we've still ended up with only two basic formalisms that almost(?) all mathematics is expressed in terms of: geometry (visual mathematics), and algebra (symbolic mathematics, including formal logic.) Because those are the formalisms that we have mental hardware to comprehend.

Anything that isn't in one of those shapes (say, an exhaustive computer-assisted proof-by-parts) might still be productive to prove; but we humans won't like it, and will always seek to replace it with something that we can get a mental "handle" on.

We'd certainly never take the formalisms that do work for us, throw them out, and replace them with non-human-mind-comprehensible formalisms instead. Why would we bother? What would we gain?

> Being able to push secondary parts of a program to be foldable, or visible on mouseover but not by default, makes it easier to communicate understanding to other humans. And actually that's a more faithful recreation on how you'd communicate in writing - on a blackboard you might use small text, or footnotes, or a verbal explanation.

Oh, I don't disagree. But all those things are useful for plain text, too. As you say, humans already think and manipulate text that way. And "advanced" text editors already provide facilities to manipulate text that way, without any understanding of programming-language syntax.

You can get very fancy about how you manipulate symbols... as long as "just manipulating symbols" is truly all you're doing. As pure symbol manipulation is something you can always also do in your head. Go much beyond that, though, and you stray from the land of "things humans can keep track of in their brains."

Can you think in terms of what a JetBrains codebase will look like after you refactor it, without actually doing the refactoring and seeing the result? How about with two or three such applications in play? It gets pretty hard, no? Because those aren't just pure symbol-manip. They're not just moving letters around on the mental blackboard that represents the current module. The non-local effects aren't strictly intuitive. Each layer of that that you have to hold solely in your head, bogs you thinking down. In a high-friction language, you just don't bother to try to work too far ahead with such changes; you just "take things one step at a time", applying each change and then re-learning the codebase in light of it; sometimes applying a change and then backing out once you realize you're got your sequencing wrong.

Sometimes working "with blinders on" like this is necessary (e.g. fixing up a big ugly three-way git merge); but why subject yourself to it if you don't have to? Wouldn't you rather be able to understand what you're doing, and where you're going?

> A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more.

I mean, they're usually written in LaTeX ;) But to be clear and precise, I was trying to invoke the concept of a https://en.wikipedia.org/wiki/Formal_language. Programming languages and (symbolic) mathematics are both formal languages. You manipulate them algebraically, by moving the symbols around, applying transformations that turn one valid statement into another valid statement.

Yes, there are isomorphisms, e.g. visual "programming languages" like Scratch. They're certainly neat, but as far as I've been able to ascertain, people can't really think in them the way they can think in symbols.

Ask a composer: what do you think about when you compose music? Do you think of the sound; or do you picture the score? Where music's concerned, I would guess pretty much everyone is thinking about the sound, because that's a lot more intuitive. Someone could probably write a song entirely by manipulating a score in their mind—and make it sound good!—but it'd be hell to do, in comparison.

You're conflating the language and the prosthetic used to code in it. Java is a high-friction language. Write it in a text editor, and measure how long it takes to write some working nontrivial Java. What you're measuring there is the inherent friction of Java, as a language. The IDE adds negative friction — lubrication — to the process. But that's a separate thing from the language itself.

As I said, just try to think in Java (rather than Java-esque pseudocode.) Try to write a Java program in advance, in your head, that only needs typing-in (in a plain text editor!), such that it's valid the first time you type it in. Imagine how carefully and meticulously you'd have to think, to get that code right. That required meticulousness is another measure of Java's inherent friction.

> good luck doing major refactoring with a text editor

A language can also be high-friction or low-friction when it comes to how hard it is to refactor code in that language. Though this comes from more abstract architectural constraints the language imposes, rather than things like syntax or identifier naming conventions.

For example: Erlang code is low-friction for refactoring, because code that lives in a separate process needs to be spoken to through a messaging ABI; which necessitates that every such process have an API-client module to encapsulate that ABI; where that client API then offers a de-facto interface/contract for clients of that API to hold to; which frees anything underneath that API from stability requirements, as long as the API itself remains stable. The fact that this is done "in the small", per process, rather than in the large, per package/library, means that Erlang "refactoring" almost always just consists of changing the shape of a process state-function, and then adding some polyfill logic to its client API module-function to keep the process working.

The way people use Java is a problem.

Spin a blank "hello world" project in Android Studio and you get no less than 79 files, and it won't work the next time you update Android Studio because of some Gradle errors.

I don't know what went wrong, but "hello world" should not be 79 files, it should be something that I can hand-code in something less than an IDE.

A jackhammer is like a codegen tool, or maybe a code formatter: it “writes” or “edits” a lot of code for you, quickly, but it’s not doing programming per se. You can’t use a jackhammer to put together the pieces of a lacquered cigar box, faster. You can’t use a jackhammer to build much of anything, really.

(But I should note that a jackhammer also doesn’t required a powered exoskeleton to wield. The power is instead “built into” the jackhammer itself. Less like an IDE; more like a batch command-line tool. I’ve got nothing against batch command-line tools! But their presence is usually orthogonal to the design quality of a language, so they’re kind of irrelevant here.)

Back to the point: programming is something human minds do. Not by holding the whole codebase in your head at once; but by loading and unloading parts from your mind, where at any given time you need a useful amount of mental-model loaded at once in order to see your way through to changing it. (This is why structured programming using macro-assemblers was a revolution in productivity: modules, functions, and block-statements are intuitive units to be mentally loaded/unloaded as a whole, freeing programmers from needing to keep an unbounded mental buffer of JMP spaghetti.)

The more high-friction the language, the less of it can fit in your mental buffer at a time, and so the more “cold lookups” your mind will suffer, where you need to look something up about the codebase (likely evicting something else in the process.)

Consider a process running on a computer without enough memory to keep the entire process’s hot state loaded into said memory at a time. The result is swapping: a slow, high-overhead process of constantly reloading state from disk and evicting other state in the process.

On computers, we can fix swapping by adding more memory—enough to comfortably hold the hot state. But human minds can’t just be upgraded like that. Rather than making our memories bigger, we have to make the state smaller — to pack it more tightly and efficiently into our memory. A low-friction language is one that packs better.

Using an IDE to paper over the problems of a high-friction language, is like seeing a computer system that’s swapping, and “fixing” it by replacing its slow HDD storage with fast RAIDed NVMe storage. Sure, performance increases. But the program is still doing something stupid — a bunch of needless swaps-to-disk. It’s just doing them quickly. The money that had been spent on that RAIDed NVMe storage, could have been much-better spent on just adding more RAM to the system.

And the effort that a human goes to to learn an IDE, could have been much-better spent on learning a language the mental model of which packs better into the human mind.

The one editor thing is key. I’m in and out of different languages and file formats. Many times, I just need to edit text. Today, I was navigating perl in Goland just because I don’t want to dance between editors.

High-friction languages allow you to pump your codebase full of unbounded coupling and complexity, to turn your codebase into a hypercube of connections (subclasses; interfaces; macros; annotations; DSLs; monkey-patches; etc.) IDEs for these languages give you a fancy N-dimensional submarine to efficiently navigate this "wondrous" landscape.

Low-friction programming languages just don't give people all those N dimensions of inter-module connectivity in the first place; and for what dimensions they do provide, they steer people away from using them too often, perhaps with opinionated linting, or by building the standard library out of the simple stuff, such that all code that interacts with the stdlib keeps to the same simple style to avoid style-clash.

This approach will also "reduce the cognitive load someone has to experience contributing to code that they didn't write"; but it reduces that cognitive load even for people reading the code in a text editor. Or for the maintainers throwing snippets of the code around in a PR / patch-submission mailing-list.

I can really appreciate the approach of designing a language to work alongside an IDE to allow both complexity and ease of use. That being said, in my heart of hearts I would rather have a language that I can use effectively without depending on a specific IDE, but I'm glad there are folks exploring that route.

Python is one of the few languages that I feel I can think in. I measure this by my ability to have “a ha” moments when away from my desk, where my brain has puzzled out how to solve something in idle moments (with at least a rough outline of the code).

I don’t have trouble working things out in other languages, as needed, but rarely find myself having these little bursts of inspiration.

> How much money is MS willing to throw into the VS Code project?

A lot. Not that they have to do it alone, because a lot of the work on VS Code features is done by other people with their own motives (some volunteer community types, but also each of the major cloud platform vendors is investing in VSCode integration into their systems, too, and the same is true for lots of other firms.)

> Its lack of revenue model limits them

If they are imminently going to be selling a hosted editing environment built around it (Github Codespaces), does it really lack a revenue model?

> a free IDE that competes with their own revenue generating VS product

Even with VS, they've long focussed on subscription services not software licenses as the main revenue source. “Visual Studio” subscriptions (formerly MSDN) are the big push, and most of what comes with that isn't the IDE.

And VSCode is very well integrated with lots of the services they are selling.

> VSCode is going to be stuck focusing on the JavaScript/web stack for a long time and won't receive a lot of funding to grow out of that.

It's not stuck there now, and right now MS’s biggest push in terms of domains seems to be ML/AI. I think VSCode is poised to do quite well for— in fact, has largely already won much of—everything that isn't enterprise Java, where, yeah, there’s a lot of time and money on the alternatives and not a lot of MS resources devoted to competing.

On the c# side though Jetbrains has possibly suffered a little bit. I know a lot of people have ditched ReSharper because it's just too slow in VS2019 and the built in stuff is often 'good enough' for them. Others either deal with the pain or have switched to Rider (I'm in this latter camp and happy about it).

On the other hand Jetbrains is a lot more diversified now than before (when their main products were IntelliJ, ReSharper, and teamcity)

Could you explain how would you go about renaming a method with a few dozen usages using VIM? (curious what's the "right" way to do this in Vim)

Rider is good but a pros for VS+Resharper is it can avoid to use Java GUI app.

As someone who used tramp and switched to VS Code, it's absolutely not the same thing. The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection. VS Code makes this work by having an agent running on the remote host. For the first time I actually got autocomplete and code jumping working without a horrendous amount of effort.

... and now he's the president. that shows ya!

sounds like my company: any windows machine is infested with a dozen or so McAffee things that make it unworkably slow. But none of the drones that role out McAffee has ever touched linux or osx, they prefer to leave that alone. So even though I actually prefer windows as a desktop OS, I mostly worked on a MacBook (until the pandemic, now I WFH on a my personal windows machine). But since WSL2 is finally backported to whichever outdated windows my corporate laptop runs, it is actually quite usable with VSCOde/remote containers + docker

> I'm curious how Microsoft could make certain parts exclusive to its own build of VSCode.

By packaging it as an extension that isn't licensed like the rest of VSCode.

Also on a related note, if you're using an open source build of VSCode (such as VSCodium) then you cannot use marketplace.visualstudio.com/

https://github.com/VSCodium/vscodium#extensions-and-the-mark...

Because VSCode is under a permissive license (MIT) rather than a copyleft license (GPL), Microsoft can add any proprietary extensions it wants. "Permissive" licenses are only permissive for the creator and other developers (only sometimes), not for the end user.

The situation is similar to Google Chrome/Chromium: Most of it is open-source, but the release binaries contain some proprietary bits for telemetry, marketplace access, etc.

A FOSS build is available at https://vscodium.com/

Can't be at phase 2, because VS Code was written by MS.

The beauty of open source. Take code written by others rename and call it an alternative to the original product.

VSCodium is able to do this, it is just more work.

https://github.com/VSCodium/vscodium/blob/master/DOCS.md#pro...

I agree and not saying they would get to it, but considering that was pre-COVID, I would imagine/hope they might reprioritize.

Remote and Docker based Python environments have worked for a while in PyCharm.

No way, it sucks when you've got a monolith full of unnecessary gadgetry. Right now VSCode is already getting pretty bloated w/ builtins

This is the difference between an opinionated vs non-opinionated IDE

You seem to prefer opinionated, where other people like the fact they can pick and choose from various plugins to my their IDE their own, and if they do not like the default implementation of a feature there likely is another plugin that may work for them.

For example there are a couple of git plugins, all of them act slighty different based on the workflow of the users of that plugin, if MS came in and said "No this is how git workflow is in VSCode and no other way is possible" that would turn off alot of users

Further you stated another glaring problem, Jetbrians mikes IDE's plural, specialized for each lang they are targeting, VSCode needs to work with many lang, there is not a VSCode:Python edition, and VSCode:Powershell edition, etc et c etc

It is just VSCode and plugins add the Languages you need / want support for

> I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins.

microsoft already has an IDE like this for their core languages; it's called visual studio. it's kinda bloated, but it's still a great tool for languages that microsoft has deigned to grace with its direct attention. for anything else, you're SOL; the plugin ecosystem is pretty limited for VS. the more VSCode reimplements plugins "natively" (isn't it all JS anyway?), the less it has a reason to exist.

It’s pretty easy though. You open a Python file, it asks if you want Python plug-in installed. Then you’re pretty much done except specifying your virtualenv. If you have linter settings it will ask if you want the linter installed.

The big thing with Jetbrains is the cost. PyCharm is $9-$25/month and VSCode is free

Or, better yet, to re-implement the best plugins as installed by default plugins that could then be enabled/disabled by the user.

>> I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins.

Unlike the FANG companies, Microsoft doesn't tend to rip the carpet out from under independent developers like that.

In my company we use pyenv with virtualenv and everything works seamlessly. VSCode automatically runs the activate script from pyenv in a new terminal (in my case it is even the fish shell), debugging works fine, and I can go to definitions.

Note that a new extension, that works alongside the original python extension, has been developed by Microsoft: Pylance. It speeds things up based on pyright, a python type-checker.

For refactoring you can use rope [0] as a VSCode extension.

[0] https://github.com/python-rope/rope

Yeah, my experience of attempting a very simple refactor (change variable name) with the VSCode Python plug-in is:

“Rope is not installed. Install?” - so I need a package in my virtual env just to rename variables?

“Rope is installed. Refactoring failed”.

I only dabble in VS Code on occasion, so only saw this in passing: https://github.com/VSpaceCode/VSpaceCode

They do have extensions that install multiple other extensions.

I think Facebook did make something like that a few years ago.

are you asking if anyone implemented the 3d first person shooter DOOM inside of the vscode plugin system? that could be a summer of code project for some aspiring coder.

I’m curious, why does this fact require that on be careful. I’m not trolling, I’d like to understand the cautionary stance.

How are you guys all working in one language?

I work on a stack that has ruby on rails on the backend, javascript on the frontend, .NET Core apps to do data transformation, and some NodeJS thrown in there, too. I have to switch back and forth between these projects regularly. There is no other tool like VS Code that provides me the flexibility to have snippets and highlighting and the things I need to maintain these projects, while also giving me the flexibility to switch between languages and syntax on the fly without having to wait 20 minutes just for the IDE to load up.

That's true, but that's Jetbrains core product. They sell it as Python IDE, batteries included, and they develop it with that intent.

VSCode does not get that kind of love, it is marketed differently and has different core values.

But there are JetBrains IDEs for those too — CLion, Rider and AppCode respectively. No IDEA how well they work though.

It's a slightly different philosophy. Emacs is best viewed not as text editor with plugins, but as a Lisp Machine emulator with a text editor. The joke about it being an OS is more true than people think: what you get is a (2D, not 1D like shell) text-oriented programming environment, back from the times where "a programming environment" meant a fully end-user-programmable OS.

This has an important downstream consequence on the "plugin" ecosystem: since these "plugins" are better seen as small applications running on in a shared, restriction-free OS, they don't need a fixed and restrictive API to interoperate. The entire Emacs is the API, and as long as an elisp app follows conventions and plays nice, it will almost seamlessly interoperate with every other app. And in cases where it doesn't (e.g. you try to use two apps that do roughly the same thing), it's relatively trivial to patch out the conflicts yourself. Having an integrated debugger and REPL is also helpful :).

VSCode philosophy feels more restrictive compared to that.

As for the keyboard conventions, it's true and it impacts the market share, but that's a problem for almost any software that reaches longevity. Conventions come and go, so it shouldn't stop one from learning a tool that keeps proving its worth over decades. And in case of Emacs, if you don't like the default keybindings, you can quite easily patch them up to follow whatever convention you fancy :).

Terminology is a slightly worse problem because you can't patch that out if you don't like it - but then again, it's just a bunch of terms you need to learn; par for the course for any developer.

The difference between VSCode and Emacs is the difference between an extensible text editor, and an editor that was designed to be extended, molded, and shaped as you work. At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality. What's more, the always-on presence of Lisp turns Emacs into a computing environment with strong editing primitives, rather than a text editor with stuff bolted onto it. I use it to automate tedious tasks, where it serves as a sort of Lisp-programmable super-shell that can ingest data from processes and network connections into buffers, as well as the inverse, all under the control of a powerful programming language.

I've recently switched from Spacemacs (vim-style modal editing and keyboard commands, in Emacs) to "Vanilla" Emacs.

I've been finding that once I changed capslock to become control, the various keyboard commands in Emacs make a lot of sense to me. In fact, far more than I thought they would, to the point where I'm feeling a lot more comfortable and competent performing the shortcuts, which means I remember a lot more of them. (Remembering shortcuts has always been a problem for me because I have various Adult ADHD issues.)

Sure, it's just one person's anecdotal and subjective, experience, but I've found myself using Emacs to edit my code (mostly Terraform and Ansible) much more than VSCode.

out of curiosity what language do you write primarily?

Arduino also has "Arduino Pro IDE" that's based on Theia, a VSCode fork.

https://blog.arduino.cc/2019/10/25/new-arduino-pro-ide-a-clo...

https://github.com/arduino/arduino-pro-ide

Yes it seems to be different everytime I use it. But the one time that the debugger worked was amazing. Wish I could make it happen again.

Have you tried out the vscode-clangd plugin?

For markdown I don't use/need a plugin, with entr[0] and Pandoc you can emulate the live preview feature easily, without even needing a browser.

0: http://eradman.com/entrproject/

Load it in Vim and it works as smoothly as with a single line file.

there's a great but not well known editor for windows called EmEditor that has a strong emphasis on performance and large file support. afaik the author has a background in low level performance optimization from Intel. if you work with large csv and/or json files you want this editor - it's amazing!

fwiw, I have the opposite experience with JSON files and sublime vs. vscode. Sublime opens fast and seamless, VSCode basically ceases to operate while it struggles to figure out syntax highlighting of such a "massive" file. I have near barebones installs of both, I do not believe it's plugins nor settings related.

Ultimately VSCode is my daily driver but I use sublime3 when I need to do fluid text editing, anything column/multi-select based, regex replaces, or manipulating large files. VScode has those features but they feel slow and buggy in comparison.

I can't agree on Notepad++. It is my go-to for opening very large log files and I've never noticed scrolling issues. I love VS Code but I've found notepad++ to be the better solution for 'read-only' situations (opening very large files, searching files / directories).

That's why... (insert brain's attempt to argue for vim)... you don't open files on Windows.

With some reasonable delay VSCode will even manage format and highlight this 60mb json. Search will work instantly.

I use VS Code daily, and most of the time I have a single workspace open with everything in it, probably more than a thousand repos.

Checking now, the workspace contains ~3.7 million files. I have had no perceivable performance issues with the editor, it works like a champ. Granted I have a beefy machine, but VS Code has been a pleasure from my first impression. For my needs, it's a great development environment.

Recently I onboarded someone to set up remote SSH editing. It did require a few technical steps, but after that they were joyous to see how well it works - a "game changer" in their words, saving them a lot of time and effort.

Me as a Vim fan I thibk its save to say that even vim doesn't handle large files well and is especially bad with files containing long lines.

> Sublime is great but it updates once every other blue moon for a reason.

I like both editors (VSCode and Sublime) and just want to point out that Sublime Text 4 is in semi-public alpha. It is "semi-public" in the sense that the download link is given in the Discord channel, but anybody could join it.

For nine months or so, there has been a new release of ST4 every 2-3 weeks. Development is definitely ongoing (though I'm quite happy with ST3 as it is).

I agree its good for a single framework. But the amount of features/ui for things I'll only use once on a blue moon is too high. I'll take config files and shell commands over multiple layers of buttons and menus any day of the week.

I've tried vim support extensively in VSCode, IntelliJ, and Emacs. The vim plugin for VSCode is sorely lacking; particularly with macro support. For my use case, it's unusable. The vim plugin for IntelliJ is slightly better. It's usable, but I still find it lacking. In my experience, the best (by far), is Evil for Emacs.

If you use vim to its utmost a plugin that emulates vim in another editor pales in comparison.

It is like learning to play an instrument. Some people stop digging into it when they learn to play a few tunes but the true beauty comes out when you really invest the time into it.

Not the parent, but I switched from vim+plugins to vscode+plugins for most development. I absolutely use the vim plugin because I can't stand to edit text without vim keybindings anymore. The reason I switched is that plugins in vim are more of a pain to configure and they are usually less maintained and polished than their vscode equivalents.

For example, let's say I'm not set up to program rust at all. In vscode, I just search "rust" in extensions, grab the most popular one, and it sets itself up magically. In vim, my experience was that I would lose a few hours to configuration, and the plugin would still be a little janky.

I still use vim as a plain text editor, and every once in a while I need to open a file in vim to do some serious macro editing (macros aren't perfectly supported by the plugin), but for the most part vscode+vimplugin is just nicer to use for day to day development. I should specify that my daily work languages are typescript & c#/unity on linux, but I've also been writing a fair amount of rust lately.

I use both. If I want to look at a single file I'll use vim. If I want to look at a group of files in a folder I'll use vscode.

They are both text editors that support plugins to the point of becoming an ide, but it is far easier to make vscode work as an ide than it is vim, and that's coming from somebody that's been using vim since it's inception.

There are more aspects to productivity than typing efficiency.

I think vim is like a rock, so it takes quite an effort to even scratch it then.

But even if you use a drill, can vim even become as useful as IntelliJ or VS code? I doubt that.

Is this a joke?

What you don't seem to grasp is the difference between a project, and the eco-system that grows around it. SSH, WSL, Docker, third party language servers etc are not a part of VS Code.

> That's not an exhaustive list

What list? You haven't mentioned a single one of "all these pretty critical and interesting components" you talked about.

If I've never heard of those plugins, they cannot be that critical or even interesting.

Yep, I set up aliases and scripts for similar needs.

I open a new window for each project, so I don't share this pain.

I think there's a plugin for it but workspaces would be much more valuable to me if they weren't a file you saved. The idea, I assume, is something like "these 10 repos with these 15 plugins are how I deploy this project."

In the end due to its UX I think it's pretty useless. I do use it on BIG projects because sometimes vscode will update or barf and forget what I had open.

I mostly just do "open folders in workspace" then hope it never goes away.

Not at all. You can open a directory, or a workspace. A workspace is just a collection of directories.

If you want a confusing workspace/project system try Eclipse!

Yes, and your video shows Electron at ~700% of UWP C++ while React Native for Windows is at ~200% of UWP C++. That means an Electron program's reference set is ~3x as large as a RNfW program's, not 300x.

Yes, I did, which is why I’m specifically mentioning it.

"Microsoft loves open source".