I find this post along with the comments in "A Picture of Java in 2020" https://news.ycombinator.com/item?id=24551390 to be incongruous with my experience as a professional developer.
My first couple of years writing software I used Vim, then VSCode, then worked in a Java shop and was forced to use IntelliJ. I didn't like it at first, but now after a couple of years I cannot see how I lived without it.
The idea that VSCode is the future doesn't seem right to me. JetBrains products allow you to do so much out of the box, without installing a million plugins that may or may not work. In IntelliJ I can write a half baked statement like `new Foo()`, and then Alt + Enter my way to it being `foo = new Foo();` as a private member variable of the class in no time. If you take time to set up configuration it becomes even more powerful. Even these basics are more difficult in VSCode.
To me the future is IntelliJ for Java and all other languages should seek to have such a nicely integrated experience with an IDE.
I am not even sure I could write Java from scratch in Vim - its really that I'm using IntelliJ, not writing Java. Is this bad? In some pure sense, sure, you are further from the language. But I don't care because I can write and edit code some multiple faster than if I was in VSCode.
From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date. Then it still likes to stall from time to time or sometimes doesn't register key presses properly. It's a poor user experience, but even worse is that alternatives are often worse.
I wish there was an editor with low latency, smart search, some proper file system database, so it doesn't take ages to open a directory and built in VCS support, that works quicker than manually issuing commands in a terminal.
I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc. without having to setup a project first and that you are ready to type you code quickly after opening. If I had to open PyCharm every time I want to try some Python in a new directory, I would probably start questioning my life choices. Before VSCode I would just use nano or Sublime.
JetBrains products _are_ pretty much the best. I think Android Studio + Kotlin is the best, most impressive IDE experience I've ever had. Mostly because Android Development in general is kinda hard, and Android Studio cleans it all up so nicely for you. It really outshines XCode in this regard.
I've never used CLion but I really want to.
That being said, I think it's clear that VSCode is, and will remain, dominant.
First: its free.
Second: it's simpler.
That alone is enough to make any product dominant. The fact that's it free, simple, and pretty much just works is pretty stunning.
VSCode for Unity Game Development kinda shocks me how you can literally install the IDE while the game is running and successfully attach a debugger. It's pretty wild how reliable it is.
I'm not a VSCode fan boy. I find that it lags on my PC sometimes. I kinda hate the "notifications" that it pops up with. And I don't like the auto update mechanism or the Welcome screen, but overall VSCode (or Codium) is clearly the next level of IDE.
I think Microsoft is going to build some really wild stuff on top of VSCode and Github.
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.
I'm pretty sure that's a big reason why they bought github.
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.
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 :-()
>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!
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.
Well, I think you're right about performance being a problem, but I have 64 GiB and a 4790k and an NVMe SSD. It's like half a percentage of my pre-tax income and was even less when I bought it.
I don't need efficiency. I need something that, given fuel, gives me power. And as someone who has donated to vim, was an early backer of neovim's bountysource, and loves his terminal: vim is my ion drive, IntelliJ and friends are my conventional rocket.
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've been a JetBrains user for about a decade now (intelliJ/RubyMine/PHPStorm) and for general editing you really don't notice the performance issues at first. But if you leave it running long enough or you make use of features that lean heavily on indexing like code inspections on large codebases or language level inspections as a couple of examples it will chew through memory like crazy and drag a machine down that's newer and higher spec'ed than you've listed.
That said, given everything it provides I don't think there is a better tool for the job despite the performance issues.
IntelliJ performs poorly if you have a many-module project with multiple independent `pom.xml` or gradle files on that Mac config you described. It does require tuning in this scenario to ensure that its Maven and Gradle imports do not fail and leave you unable to resolve your types. If you have a generate-source step you're going to be in even more trouble.
Would VSCode work better in this scenario? I'm not familiar with Java tooling, so my question is whether this is a tooling problem or an IntelliJ problem.
VSCode lacks many of IntelliJ's features so it would act as a text-editor with naive auto-complete better. With plugins and presumably an LSP link, you can get some degree of functionality but it does not compare in total.
I would not write Java anywhere but IntelliJ. Any long time IntelliJ+Java user has macros and templates written so that boilerplate is automatic. `psvm` is built-in, as is `sout`, but when I wrote a lot of Java I had ones for other common patterns at my workplace.
You may change your mind if you plug your MBP into an external 4K display and try to use a scaled resolution: https://youtrack.jetbrains.com/issue/JBR-526 — don't get me wrong, I love PyCharm too for all the reasons spoken about in this thread, but this issue (which has been open for five years now) has made me attempt to jump ship to VSCode for my python work several times. I _do_ always come back to PyCharm... so far...
What's the reason for using a scaled resolution btw? Can't you just ramp up the font size in the IDE?
It looks like maybe a macOS issue as Windows/Linux don't have the same problem, but there's a port of Java to Apple's proprietary Metal API in progress for some time. It's possible that will fix it.
Yes, as it happens you can in PyCharm; in many other apps I use that's not the case, however. I've got used to running at full 4K but TBH sometimes I worry about eye strain.
I often use a 24" 4k display that I use at 2x and I never had any issue. With other "equivalent" resolutions it may be bad (never tried) but I've heard people complain about lag in that situation (even with a newer MBP and apps other than intellij).
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.
Sorry to hear that. Is that a mobile processor? Perhaps you're throttling. I boost RAM on my IntelliJ quite high (I give it like 8 gigs plus a gig each for each of the tools - Maven, Gradle, etc.). Your setup looks better than mine except for the fact that its mobile.
> From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date.
I don't know if you are talking about IntelliJ or VCS, but IntelliJ can quickly start an empty project. And you don't to spend time to figure out how things work. I mean, there is literally no entry barrier for a bare bone project.
> I wish there was an editor with low latency, smart search, some proper file system database
You are describing an IDE here. Smart search and a proper file system database, it means operating not on a collection of text files but on a project and a code tree, which is the main difference between IDE and Editor.
> I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc.
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.
Well, obviously a text editor built on top of Lisp is going to be pretty good at editing Lisp-based languages like Clojure. Emacs is pretty poor at everything else though. I remember trying to get it to do even basic completions in C++ beyond hippie-style completions and it just couldn't do it no matter how many packages or servers it had to help it. That was some years ago though, but emacs develops slowly so I doubt it's changed.
That said, the tiling WM features it has are pretty good.
"LSP tooling" for Java/Kotlin/Scala doesn't exist as far as I'm aware. I'm sceptical about LSP stuff anyway. In an IDE performance and latency really matters. IntelliJ plugins have direct heap access to the AST and editors so they can rapidly explore the code, add annotations etc. Java adds some overhead but it gets lower every year, they just never stop optimising the JVM, and serialisation/context switching is gonna add a lot back. Especially as you'll really want to be writing language servers in high level languages anyway. There's no justification for writing such a thing in C++ or Rust.
I use this with emacs, and it works pretty well: it was built for Eclipse, but it’s well-integrated into lsp-mode and, more or less, “just works”.
There are also Kotlin and Scala LSP servers that work. The servers themselves can be a bit annoying to get working, but the emacs integration “Just Works”.
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 use both VSC And IntelliJ. Searching symbols/usages/implementations in large projects is far faster in IntelliJ in my experience, not to mention it's much more accurate too but that's probably due to the language (Java/Kotlin in IntelliJ, Go/JS in VSC). It's really annoying when I have to wait seconds to find implementations of a Go interface in VSC as I am used to IntelliJ's instantaneous searches.
I think you mean VSC is faster to start up, and perhaps to type? It's certainly not faster overall.
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.
Frequent re-indexing sucks and and times it slows you down. But I see it as a direct price to pay for intelligent autocomplete, search, refactoring, etc.
It is cached and written to disk. Actually they're now going further and supporting downloads of pre-calculated indexes.
I use IntelliJ every day and I'd say reindexing only happens now when there's an actual need for it, like because I switched to a different JDK (which may therefore have different classes in the std lib). It's incremental too so this doesn't bother me like it used to. Definitely an area of focus for them.
I see them as complementary. VS Code shines if you’re jumping between independent codebases for distinct projects, and startup time matters.
But my startup monorepo I keep loaded in IntelliJ for days at a time and have never looked back. For the 1% of time it’s laggy due to a JVM GC or background indexing, the other 99% of the time it’s immensely productive to have e.g. full-stack debug breakpoints that Just Work, well-designed customizable gutters, integrated linting, and more.
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 tried both ZGC and Shenandoah (with plenty of heap space available) and haven't noticed much difference compared to the default CMS. Also, Shenandoah (or maybe both?) does not support compressed pointers, so there was a noticeable increase in memory usage.
IntelliJ isn't really the IDE for dicking around with ideas. Projects or not, it's just too fat. I am an IntelliJ diehard myself and I usually have a copy of Sublime Text open as well, usually to use it as a scratch space, to peek at logs or somesuch, or for playing with code that isn't quite yet in a runnable state.
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.
> From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it
This hasn't been my experience of JetBrains Rider at all - granted that startup does take a few seconds, but after that it seems to fly.
> Then it still likes to stall from time to time or sometimes doesn't register key presses properly
This was my experience with Visual Studio; I used it for over a decade because it is a great IDE - but performance and stability has never been great, and eventually I just couldn't stand the occasional lag any more and jumped ship to Rider. My experience there has been very different - it's rammed with at least as many features as Visual Studio, but has been rock solid, and never lags in use.
The main reason I use VS Code is I tend to work on a lot of mixed-language development. I often have Python, rust, custom DSLs and C++ in the same code base with a custom build system. VScode gives me the flexibility to use all of them to their fullest potential without needing to support the build system.
That being said if were to use Java I would probably not move away from intellij. Last time I tried clion though it was a disaster.
In IntellIJ you have scopes, where you can narrow down the project view to a set of folders, which is useful if you work on monorepos. Scopes affect not only the project view but also file search.
You can disable plugins you don't need, and mark folders as excluded if you don't need them indexed, that makes it faster.
As someone who uses all three of the editors you named, I think that each serves a pretty different purpose in practice. Each aspires to be the be-all, end-all editor/IDE, but that's just unrealistic to me.
For me, I use VIM all day, every day at work (C++), because while it doesn't have the full IDE experience out of the box, it's close enough, and can be brought much closer with various plugins and knowledgeable adjustments. I've stuck with it because "it just works" and I'm use to it. A previous colleague was a big VIM evangelist, so got a running start from him, and now I've tweaked it enough that it works well for me.
VSCode is my general purpose text editor at home. If I'm writing markdown, or fixing some script, or I just need to see what's in that file, I'll use VSCode. It is the obvious, far superior replacement for Notepad, and has plenty of niceties to make it that much easier to use.
But if I'm building something with a lot of moving parts in one of its supported languages, I'll use IntelliJ. I don't often write Java these days, but PyCharm is just a reskin for Python and I think it's great. It does so much junk for you, and it makes testing and debugging so easy. It does trip up my muscle-memory occasionally, but for the most part it's a powerful tool that's great at what it does.
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 use vim primarily for around 9 years now, and with ALE as a linter plugin it's integrated with languages I even don't know existed until I need to fix something in it in a foreign codebase.
If I need to go typescript or web, vscode is very tightly integrated with the build toolchains, so the occasional fix in vscode is necessary for me when I need to fix a bug upstream.
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.
Currently, I'm trying to migrate to kakoune because I've heard a lot of nice things, and the ecosystem seems to be better integrated with lsp and rust, but honestly my muscle memory is damn strong, so it's actually kind of a burden at the moment and I'm gonna need a while if I keep pursuing this.
One benefit though that both emacs and vim have is ssh usage. Debugging and reading logs on a remote server is pain sometimes, and my vim profile eases that sooo much up that I saved a shitload of time by using it.
> 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....
I couldn't stand VScode when I tried it. To be honest I didnt even get it working properly for C development. Visual studio on the other hand is awesome.
yeah, I tried it when it first came along, and I didn't get along with it too well, but it seems quite good now. But yes, possibly might be tricky with different kinds of build environments, I haven't really dug into that side too much.
IMHO, the main stopper for vim/emacs to go mainstream is lack of packages for preconfigured flavors of vim. E.g. `dnf install vim-perl -y ; vip myprogram.pl` or `dnf install vim-c -y; vic myprogram.c` .
I used to use Intellij for everything (and I'm not even a Java dev). It is indeed very nice and comes with so much out-of-box around languages and popular libraries. However, Intellij is _sooo_ very slow to load and edit with. This is more tolerable if you work on one project. But in the past couple years, I've had to work on many smaller projects, and loading up Intellij for multiple projects meant gigs of RAM disappearing, along with that sluggish start time wait for each project and slow editing.
I really loved Intellij and I wish it could be made to run more efficient. VSCode fills the niche of "loads fast, moving around code is fast, and I can have many instances open at once without crushing my computer"
I guess it depends on the type of project you're working on, but I think these tools still serve separate use cases.
Hardware can fix that. I'm on latest MBA but I see no problem with performance. Recent hardware does have gigs of RAM to waste.
Once IntelliJ is running, which takes less than 10 seconds, projects open instantly. Probably even better on desktop machines.
Frankly VS code isn't good enough yet. It's the best if isn't for JetBrains but for instance, SQL queries are still just a string (unless I've missed the obvious plugin to allow me to auto complete column names and such according to the live database schema) but IntelliJ can highlight, auto complete and check errors once I register my database (also through ssh tunneling).
I do like VS code being faster but feature wise, I only use it to edit server config files through sftp plugin.
In 5 years, maybe JetBrains might feel pressured from competitors.
But it's only less than $15/mo if you pay annually and from 3rd year for their all products pack.
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.
I work on TS only project but VS Code doesn't highlight my SQL queries and what part is significantly better? Genuinely want to know. I would switch if it really is.
I found (on a team with a mix of VSC and WebStorm users) that VSCode had better overall support for jump to definition and refactorings: the refactorings, in particular, were more accurate and were less likely to change irrelevant locations or leave usages unchanged. Also, at the time, prettier integrated into VSC better: that may have changed since.
(This is mostly for Javascript: Typescript is more Java-like, so IntelliJ's tooling may be better there.)
I don’t know, I don’t really use or like Typescript. But, the reason I think IntelliJ may do better with Typescript is just that TS has a Java-like type system, so IntelliJ’s Design as a Java IDE may end up being an advantage.
Are the projects related? Or all unique? If related, you can create a uber project and import each directory as a module. I’ve got a project right now with 5 modules - 2 JS, 1 Go, 1 Python, and 1 Ruby (Rails). I’ve found this keeps memory usage down.
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.
Fancy IDEs are lubricants for high-friction languages. If a language is already low-friction, there won't be much benefit to be gained from an IDE, as even a plain text editor will already get you near to optimal productivity in said language.
Personally, I'd rather use a plain-old "code editor" (with at most syntax highlighting, but no snippets, let alone autocomplete), in part because doing so will actively steer me away from languages that weren't designed with the User Experience of writing them in mind.
Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone.
Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye. That's kind of the idea behind having a source code representation of a program in the first place, divorced from a machine code representation — to give us humans a formalism we can intuitively handle. A programming language is something you can think in.
Seen through that lens, a programming language that requires the cybernetic prosthesis of an IDE to read and write it fluidly, is a bad programming language. You don't have an IDE loaded in your head. So how will you think in it? (Usually: by thinking in a vague pseudocode instead; or even, by thinking in a different language than the one you're writing in. Obviously, this is going to be lower-productivity than coming up with a mental model of the problem that can be directly typed into a computer.)
(Before anyone makes a supposition about my language biases: both "complex" and "simple" language designs can be inherently high-friction due to their design choices. Scheme has very little syntax, but it's also high-friction, in that it's easy to get lost in a sea of parens unless your editor helps you along with a feature like Emacs' paren minor-mode. Most modern code editors do have something like that, but it's still a form of lubrication to overcome a point of friction in the syntax; one that some of Scheme's linguistic siblings—e.g. Clojure—avoid by increasing syntax.)
> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone.
I remember people making similar arguments when cars started to have power steering.
> Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
I disagree; programming languages are primarily tools for programming on computers, and expecting them to be skeuomorphic to a particular approach may hold us back, just like expecting a CAD program to work the same as a physical drafting table or expecting a rendering engine to use a TV-like fixed framerate.
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. A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more. A language whose design embraces IDEs can be a better tool than one that flattens everything into the binary of written in the code or completely invisible.
> 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.
> If a language is already low-friction, there won't be much benefit to be gained from an IDE, as even a plain text editor will already get you near to optimal productivity in said language.
I don't think the IDE should do "everything" for you, and you should understand how its building/compiling the software. But with statically typed languages and library definition hints. I think I would be wasting time searching docs if I didn't have the hints and type info. I can't remember everything I work with, it's impossible.
I've so often needed to understand what a library does when I call a function or use native or third-party class. In PyCharm or IntelliJ I can easily set a breakpoint at the call and dive into that third-party implementation. IntelliJ even will download and index the original Java source. No plain editor is going to give you that. The IDEs also allow code search in the vast sea of third party code, with approximate matching. If I only vaguely remember the function or class name I need, the JetBrains IDEs are going to find them for me.
> 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?
I don't know what kind of refactoring you are doing but for me yes I absolutely know what it will look like after the refactoring. In fact, that is usually why I'm doing it: refactoring to remove complication.
For example, the typical "extract method" refactoring lets me grab a piece of code that is almost duplicated elsewhere and turn it into a method with conditional logic to handle both conditions. That's a great simplification and make it much easier to hold in my head.
If you're suggesting we all switch to writing APL then I'm probably in agreement with you :) but I still think you're partially undervaluing and partially misunderstanding the full potential of IDEs.
>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?
Not sure what you mean here, IDE built-in refactorings are tools that I use because I know exactly what I want to do and what the codebase should look like after I do it, but the work to get there is tedious and repetitive. I have never had trouble imagining how they work or what the result will be. Compilers do optimizations that alter the structure of programs reliably; an IDE with a language model as rich as the IntelliJ suite's is little different from a compiler specialized to a few high-level optimizations.
>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.
We seem to think about programming languages very similarly. Always nice to find a fellow traveler ;)
I'm not really a fan of Java though I will confess to liking C# a lot. My heart is with OCaml and Idris though. So why do I program in C#? Why do I choose such a "high-friction" language, as you put it? C# is most definitely not designed from the ground up for maximum developer ergonomics.
It's because of the ecosystem, and specifically tooling like the JetBrains IDEs. I'm more productive in a language like C# because of the depth of high-quality libraries available to me and the quality of the tooling I use. Yes, some of the worth of an IDE is in papering over ergonomic problems in languages. However, IDEs are certainly not required to write code in these verbose languages. I use them because they are powerful tools that are well adapted to the conceptual model of the languages they support, and they enhance my ability to use patterns and write code "fluidly" as you put it.
Even in more ergonomic and expressive languages this has value, probably even more than it has in C# or Java. These languages are easier to write without an IDE, but we don't know what we're missing because the high-quality tooling just doesn't exist. Idris' Atom support is a pointer in the direction I'm thinking of: https://atom.io/packages/language-idris
Just think about what an IntelliJ-level IDE could do for a language with a type system as rich as Idris'. You might be able to infer entire applications based off a handful of expressive type signatures. We have yet to see what writing in one of these languages is like with a suitably powerful design environment, and I fully believe that it will make writing them with a text editor look pedestrian just like IntelliJ did to Java.
I'm not super jazzed about where Scala sits on the syntactic complexity vs expressive power plot. Seems uncomfortably close to C++ from what I've seen of it, although I know that Dotty/Scala 3 is supposed to clean it up quite a bit conceptually.
I think the reputation is wrong there - Scala's syntax is actually very simple and uniform. e.g. a {} block can just be used anywhere to pass a block of statements instead of an expression, rather than having complex rules about which keywords do or don't need braces. Function application can be written without brackets (which I guess some people see as complex, but it's a very shallow kind of complexity) so operators aren't a special case, a + b is just calling the function called "+". If anything Scala 3 feels like a step back in my book - e.g. they've added a bunch of different syntaxes for implicits rather than treating them as a single general feature that can be used for multiple things.
> 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.
> 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?
The dominance of those formalisms is at least as much about the physical hardware as the mental hardware. In my head, a mathematical proof is usually something like a tree structure or even a wiki: I have an overview that A implies B and B and C together imply D, and then if I "zoom in" then there's all sorts of structure to the steps to get from A to B. Of course if I were to write this proof on paper or blackboard then I'd have to flatten it (though not completely; I'd certainly break it up into lemma x and sub-lemma y), but saying that a paper is the human-mind-comprehensible formalism is putting the cart before the horse. The kind of richer structures that we can use with computers - Jupyter-style notebooks, or wiki-like linked crossreferences - makes it easier for humans to comprehend, not harder.
> 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.
Completely disagree. The result of the refactoring is always the obvious thing that you'd expect, and having the IDE take care of the details of which characters change in which files makes it much easier to focus on the actual change you're making rather than get bogged down in the details. I can't imagine understanding programming as manipulating a flat sequence of symbols; it would be like trying to work in Brainfuck.
> 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.
Again I think you're getting this completely backwards. I have the structure of the program in my head, and it's something much richer than a sequence of symbols; it's a graph of directed connections, and much more besides. An IDE that can do things like showing references on hover gives me a much closer representation of the program than a linear sequence of symbols, brings me much closer to being able to manipulate the program itself; manipulating the sequence of symbols sounds exactly like manipulating the score instead of manipulating the sound.
Java doesn't have a lot of friction. In fact, IntelliJ is probably the closest you'll get today to the "golden age" of programming with something like Turbo Pascal.
Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.
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.
> 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.
That's not necessarily a bad thing. For one, writing real world code in your head would require a level of trivia memorization (e.g. the standard library function signatures) that most people have deemed a waste of time. Secondly, meticulousness is usually a positive trait in a programmer. If Java's going to be negatively evaluated for that, then it needs to be shown that the kinds of meticulousness it requires don't actually add value in cases where it's used (which may not be like your cases).
Erlang is a particularly low-friction language, in my experience; it’s just as productive (for me, at least) to edit Erlang code in vim (with no active extensions other than Erlang syntax-highlighting) as it is to edit it in Sublime Text with the whiz-bang Erlang Language Server compiling it in the background. Code that won’t compile just looks wrong in Erlang, and it’s not subtle.
Elixir is slightly higher-friction; all that weird extra Erlang syntax that Elixir eschews (the comma and semicolon statement-binding operators specifically) has a purpose in making Erlang “mentally lintable”, so Elixir loses some of that.
It gains in other places, though; for example, Elixir’s hygenic macros impose much less of a mental load than Erlang’s parse-transforms do. (Just the fact that you have to explicitly require the definition-site module before using any macro from that module, is a big boon to predicting what’ll happen when you go to run the code.)
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.
> Spin a blank "hello world" project in Android Studio
That’s Android Studio’s default workflow designed around the expectation that it's going to be used for building Android apps in a particular style, and to optimize for what is usually appropriate for that, which is very much not “Hello, world!” optimized.
As much as Java is a needlessly verbose language, the problem you are looking at is an
particular IDE / build system / project type combination issue, not a Java issue.
Heh. Some years ago, I thought I’d step away from highly available distributed systems and build an android app. Got to the point in the tutorial where we needed to define a string for “hello, world” and the tutorial said, “ok, navigate to such and such directory and add this xml file and ...”. Closed the tutorial assuming Java is not for me.
The tutorial also said that you are placing this string in an xml file for easy localization in the future. I am not defending their setup, but it sends a wrong message when you skip parts of the sentence.
But is it ideal for a "Hello, world" program to follow all best-practices? In my opinion, a "Hello, world" program should do the bare minimum to print "Hello, world" to the screen, and no more, so that it represents the language at its most basic.
javac it, adb sideload the .class file (or .jar file), and you should be done for the day. Unfortunately the bare minimum is way way way more complicated than this. Weird XML files, infestations of manifests (generate them automatically from 'ls' and 'grep' damnit), Gradle files (worst abomination of a build system ever), API levels (how about you just infer it from the functions I use? I shouldn't need to tell you), signing (ok fine but this should only be needed when uploading to an app store), zipaligning (wtf, this should be automatic, don't make me do that nonsense).
Ugh. Why can't we just make javac [STAR].java work? Tarball the resulting .class files, make sure to have one called Main.class that is the entrypoint, GPG sign the tarball and you should be ready to distribute.
Yeah I know it doesn't work like this now, but the designers of the entire Java/Android ecosystem should have designed it to be that simple.
The moment you get any of these build systems involved you instantly lose all hopes of DRY coding. Excerpts from an Ant build.xml file:
I see "HelloWorld" repeated 3 times. MASSIVE fail. I'd rather no build system than deal with this level of repetitiveness. It's bad enough that Java requires the file name == class name which is already a case of repetition (that design decision is fine with me but then files should start with "class {" and not "class Foo {")
Maven is wonderful. It's all the best parts of npm or cargo, years before them. Just don't try to fight it - accept that there is a maven way of doing things that you will have to follow. If you need something to build before something else, put it in a separate module. If you absolutely need a custom build step, write a proper maven plugin for it. But 99% of the time your build definition can and should be just a list of dependencies and a couple of basic settings values.
That's because they want you to get used to properly localizing your app. Work in any localized system and you'll define the text in JSON or XML files.
> Yeah but "Hello World" in actual java is a main class and a quick write to stdout, like most any other normal (programming, not scripting) language.
Scripting languages are programming languages, and a class with a method is only typical of a narrow class of languages (most of which that aren't Java are specifically designed to closely follow Java); leaving aside those programming languages typically called “scripting” languages, in C++ it is just a function, just like C; D is pretty similar (as are most procedural languages, including those like C++ that also support class-based OOP without being obsessive about it, and also most impure functional languages.)
In Haskell it's just:
main = putStrLn "Hello, World!"
Well here's GTK hello world in freaking C. One file that you can gcc and run "./a.out". Not 79 files with a build system that breaks every time you hit "upgrade", and which requires me to install gigabytes worth of SDK API bloat and agree to 10 different license agreements. Want a free build system that works for this for every version of Linux in the past decade and probably the coming decade? All you need is ONE "Makefile" and you're done.
>Seen through that lens, a programming language that requires the cybernetic prosthesis of an IDE to read and write it fluidly, is a bad programming language.
>Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it.
You don't use IDE to be able to use language, you use IDE to increase your productivity. Instead typing whole for loop you just use shortcuts, instead of changing class name in 5 places you just change it in once. You save time.
>We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
But do you remember that class `PurchaseHandler` has method `BegingPurchaseProcess`?
> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it.
Ah, like a jackhammer? One of those huge ones attached to a digger they use to break open the roads?
It’s a right-tool-for-the-job kind of thing. Some roads can be mended with a shovel. Some need a jackhammer.
If you limit your development to “what a human being can hold in their head” you are artificially limiting yourself. The whole reason we use higher level languages is so that the machine can exceed what a human can hold in their head.
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 money that had been spent on that RAIDed NVMe storage, could have been much-better spent on just adding more RAM to the system.
It is organizationally costly to upgrade the human brain to increase RAM. Much cheaper to increase HDD storage through rote memorization and even more cheaper to access External storage on StackOverflow. That is where Verbosity helps, to signal when to stream certain Paradigms into your active memory, and keywords to use when searching for answers online.
A 4mb Language can't run on a 3mb brain, so the efficiency it offers at compressing your mental model is useless. But if you have a 1mb Language kernel that dynamically streams 1mb of Paradigms at a time, and then uses the last 1mb to work on the code, then you are capable of functioning.
I haven’t used IntelliJ, but if it gives Java developers half of the refactoring options and shortcuts that JetBrains Resharper gives C# developers, it must be worth its weight in gold.
C# is the only language for which I have had to deal with large monolithic codebases.
For smaller codebases, I prefer VS Code. Especially now that I go back and forth between JS, Typescript, Python, and occasionally Go and Java. I’m also frequently editing yaml and JSON. Having one editor is more ideal.
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.
All of this is fine if you don't work with others. The point of these tools is to standardize around something to reduce the cognitive load someone has to experience contributing to code that they didn't write. The amount of possible paths are commonly reduced for the reader.
Linting, snippets, autocomplete, are all things that prevent you from bending the nail or breaking off the head which makes maintenance harder for the person who has to find the nail and remove the nail. If I don't have to redo the nail, the cost of the nail and my time are also saved.
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.
It’s not having just one of them is bad; it’s that striving to include as many of them as possible in your language—and not having any convention or constraint discouraging using them all at once—is bad. Look at the code that implements the C++ STL, for example.
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.
So, with a full disclaimer that I am somewhat newish to C# and have only learned it because it operates in game engines faster (currently) and has become the language du'jour for game programming.
The glaring hole with C# however is, it is designed for Visual Studios, and that is NOT available for Linux. This is a GIANT hole in the programming world. Visual Studios Code fills that gap, thankfully, and I can use it in engines like Godot to make games. While these may not be AAA titles, they aren't an insignificant portion of developers in the world. Not only that, but C# is used in other areas of development where the preferred platform is Linux.
Luckily, for me and those of my ilk, people have hobbled together a system in VSC where Linux works with Godot and the exports are fine, but it's not nearly as easy as a supported system like Visual Studios on Windows and Mac.
This is part of what led to me originally choosing Python in the first place so many years ago. I really liked Haskell but I found it hard to get things done with it. I tried to build out a large project in it, and with a deadline looming, decided to try building the rest out in Python. Python got out of the way for me and made it easy for me to "think out loud" -- perhaps this is what you mean by "hand-tools".
I was a lot earlier in my maturation at that point, but I still think my intuitions were sound. I like languages like Python which lack syntactic noise and make it easier to write compact self-explanatory things. I used to hate JavaScript but with ES7 onwards, I've begun to like it much more because it's easy to write compact, self-explanatory things.
I was forced to write Java for work a few months ago and rudely awakened in a painful manner. Yes, you adapt to it but deep down inside, you know that it sucks and you prefer going back to your better alternative.
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.
What I liked about Python when I picked it up was how simple it was. The preference for making sure there was only "one right way to do things" made it easy for me to focus on my business logic and not worry about syntax. Although this has been to a certain extent lost, I think the stylistic decision remains present in the gigantic ecosystem.
That's another thing I love about Python. There's such a high chance that someone's already written something that would take me lifetimes to write, and it's so easy for me to just pull it in and use it.
I'm not sure what you mean by "Fancy IDEs", but if it's ones that integrate with the language (eg intellij) then I really disagree that there won't be much benefit. The main benefit I find with a good IDE is that it makes your typing follow the constraints of the scope you are in.
A string literal can be any sequence of characters so it's up to you to type them, but when I'm accessing members of a class, I'm not interested in being able to try to access a random string that is not a member of that class.
Re: your thinking comment, I also think it's the opposite. When the IDE follows the constraints of the language, it's more intuitive than when it suggests typing random strings everywhere is fine. That's not how a language works, and neither do I find it constructive to think that way.
It is certainly true that languages designed for simplicity (such as go, clojure, and to some extent python) exhibit far less friction when composed in minimal editors, than [overly?] verbose/complicated languages such as Java.
However, I vehemently disagree with some of your (implied?) points. In particular, some functions offered by IDEs and other codebase management tools are almost equally useful for both simple and complicated languages. For example refactoring tools, or if we really look at the stem, code-base analysis tools that 1. parse the language, and, 2. have APIs for modifications, are some of the "power tools" that could be useful for virtually any programmer.
As an IDE-averse person, I find myself reaching out for the simpler languages far more often, and do actively dislike high-ceremony systems. All the while, I am painfully aware of the limitations of using only a [good] text editor. My main alternative (to mainstream IDEs) is to context-switch between pure code-writing episodes and refactoring/analysis/etc. periods (using other tools, most on the command line or with output to a web-browser).
Also regarding your comparison between written programs and mathematics: I think that comparison is relevant ONLY for low-churn fundamental code (such as core libraries, or generic utility libraries) and rather poor in a LOT of "business logic"/"presentation layer" code. I myself play code-golf and run several _mental_ redesigns/refactorings when working on code that should be solid and not subject to frequent revisions. In such cases, yes, the code should be readable, well designed, and simple to follow (clarity slightly preferred over performance for the core). Nearly formal and exhibiting formal/math-like traits. On the other hand, "business logic" code is inherently unstable and could require numerous revisions purely due to external requirements. Such code usually shouldn't be optimized for tight simplicity. "the first thing that came to my mind"-level clarity with comments can suffice. Common IDEs do help with the latter type of code (while, I think, not much with the former).
Beside serious analysis and modification tools, there is an extra set of features provided by many IDEs, such as lookups (lookup function/library/etc. initiated while looking at code), autocompletion (based on parsed code or just string matching), etc. These are certainly nice, but I don't think they change the landscape much between IDEs and plain text editors (or rather, editor-and-a-documentation-lookup-web–browser-on-the-side).
So, for me, IDEs are certainly valuable even if I don't use them frequently. In a more ideal setup, I would write my code in my preferred editor without much hand-holding and with just the simplest of IDE-like features. And then, separately, do codebase "polishing" with dedicated analysis tools that may or may not look like conventional IDEs.
While editors like IntelliJ are definitely more polished out of the box, something that may not be apparent is that internally they are all standardizing on tooling and protocols put in place by VS Code in the last few years.
Language toolchains are now expected to provide IDE-specific features on their own (by implementing a language server), and so IDEs themselves don't need to focus on making the language better. So the biggest sell of IntelliJ, reSharper etc. won't be relevant for too much longer, since every editor can (or will be able to) e.g. understand Java and provide basic fixes and refactorings.
In practice we're pretty far from that. Most statically typed languages, even fairly recent ones that took on LSP compatibility early, are still better supported by JetBrains' IDEs.
Most language toolchains are held together by small teams of volunteers or corporates (Apple, MS) that sell their own IDEs. They struggle to provide even the basics like solid fast compilers, portability, debuggers that aren't gdb, profilers that work and so on. Look at Go, Rust, Swift. All of them are fighting with basics like performance and language evolution. And now you want them to implement most of an IDE as well? How will they handle that? The only real exception is Kotlin (by JB!), but that was possible because the compiler and IDE plugin are a unified codebase and because they built on the JVM, so they get top quality compilers and profilers, portability layers etc for free.
The key to JetBrains' success is not any particular software architecture, although having language analysis plugins run in-process with direct access to AST structures is an obvious advantage, it's that they're a company that charges money for their tools, which has kept their cost overheads low (very low relative to never-profitable SV startups that snort VC capital like party hounds), and which are building on an already very productive platform to begin with (Java).
This combination means their feature throughput is very high but more importantly, sustainably high. They've been doing this for 20 years and aren't about to hit a tech debt wall where they suddenly need to rewrite their product from scratch.
Contrast this to their primary competitors, Microsoft and Apple.
Visual Studio has a comparable feature set to JB IDEs. But it's Windows only, totally un-portable, hardly supports web dev outside of the .NET stack, and the plugin model is native. They badly struggled with the transition to 64 bit because of this, which in turn meant users regularly hit its internal architectural limitations like project size limits (cuz of the 32 bit address space). VS doesn't scale well because there's no good way to stop plugin crashes taking out the whole IDE. Even though MS have been pushing .NET for 20 years, VS itself doesn't use it. IntelliJ built on Java which hurt them in the early days, but now Java's perf issues are mostly solved and they benefit every day from portable plugins, a seamless 64 bit transition, cross-platform portability, etc.
XCode is under-funded, has very few plugins and can't compete for any task outside of Apple's own ecosystem. It doesn't even try, really.
VSCode is a text editor with plugins. It is at least trying to compete with JB, but I don't forsee much success in the short term, especially if JetBrains pull their finger out on light mode. It at least uses managed languages. But the most mature JB plugins have been developed over a period of decades by now. The feature-set is overwhelmingly huge, and they have hundreds of employees that do nothing else but add them. How much money is MS willing to throw into the VS Code project? Its lack of revenue model limits them, even with a sugar daddy funding them. It's unlikely they can scale to JB size because a free IDE that competes with their own revenue generating VS product is simply not something they will tolerate long term. 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.
> 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.
I don't see any stats saying VSCode has won "everything that isn't enterprise Java", that's clearly wrong as it's not really used for .NET stuff and most C++ for gaming is still classical Visual Studio. And JB IDEs have a lot of traction for any language they support outside of Java too.
GitHub Codespaces isn't a revenue model for the IDE. It is a separate product that requires a separate team, so it'd have to be charging a lot of money indeed and get a lot of users to fund two products for the price of one. It also looks like a rather basic featureset - if it takes off as a product it is not very hard to integrate into its competitors or build a similar system.
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)
Other replies have expanded on this quite a bit, so I'll just add my 2 cents:
When using a strongly typed, object-oriented language like Java or C#, Jetbrains tooling, namely the intellisense and refactoring is well-worth the cost.
However I'll still spin up VSCode for most all other languages since the tooling advantage diminishes when using a loosely-typed language like JS or Python.
Also consider that VSCode is free compared to Jetbrains, and the tooling is "good enough" for most cases. Even the C# tooling is passable with the right plugins.
I write Java in vim all day and it's fine. I'm also one of the top code contributors in my org by any metric (LoC submitted, bugs fixed, tech debt reduced, etc.) And everyone else uses IntelliJ.
You devote time to learning your tools and improve the efficiency of the parts that matter, and the tool itself becomes mostly background.
THIS ! As a "professional" you owe it to yourself, to spend some time and actually learn you tools ! Not just "how to get by" but actually schedule time in your week to learn about the tool ! Shortcuts etc !
I spent a bit more than half of my professional career developing in Perl, on a large web application implemented across 100+ modules. All of my work was done through a terminal connected to a remote server, using vim.
When I had to rename something, it was a manual process: one terminal opened to the command line, using grep to locate all of the instances I might want to rename. From there I could use sed or perl on the command line to do the renaming, or I could open individual files in vim. Once in vim, I could use a global search and replace command, or search for each instance and replace manually or with a macro or . command.
Slower than an IDE? Absolutely. But it never changed something I didn't intend to change, and the process taught me the value of good naming conventions. I never felt it was a hassle, and I became very good at refactoring without breaking things.
Today, I use Visual Studio to develop in C#, Javascript, and sometimes Typescript. The C# refactoring tools are great, and I've learned to trust them, though my naming convention habits are still useful when it comes to refactoring names in comments. Javascript, and to a large extent Typescript, generally require my old manual search and replace process. And whenever I do any refactoring, I always have a separate commit for it, which I carefully review to make sure the tools didn't do anything unexpected.
If they’re using a language server plugin, it’s entirely possible that they just call a refactor function provided by the LS. This works just as well in vim or emacs as it does in vscode, since they can all use the same language servers (generally)
Conversely, I always hated the bloaty, intrusive ReSharper on VS.NET, and find IDEA very much nicer, even though C# is more naturally ergonomic than Java (but less ergonomic than Scala).
I tried out vscode for python now that I started a new job. I'm on linux for what it's worth. The experience has been massively frustrating coming from pycharm. First I installed the open source version, and found that microsoft publishes plugins that are programmed not to work with the open source version. They don't tell you this, rather, the plugin throws exceptions that some API is missing. I tried out the official version, and instead of whining about not being supported, it now just crashes intermittently. I gave up less than three days in.
I found configuration of code to be pretty annoying as well. Either you write json, having to google for things like how to format keyboard commands, or use their (subjectively) ugly configuration page.
The fact that I can't detach the terminal from the code window without some weird workaround was also something I couldn't come to terms with. I'm back in pycharm again.
It's not just the terminal, it's the python interpreter, ipython notebooks, debugger, e.t.c.
The terminal was what came to mind. Besides, when working in a remote dev project, the terminal automatically SSH's into the remote, and if local, it opens the working folder. It's practical to use the internal one sometimes.
> JetBrains products allow you to do so much out of the box
It's all nice and shiny until it takes several minutes to index your whole project structure. Then you can only hate it a little bit more every time you start it.
VSCode is not bloated (for now) with millions of options, I can add extensions and/or disable them whenever I need without losing performance or even creating my own ones without too much effort.
The indexing is what matters. After that, IntelliJ knows pretty much all about your project files. It only takes a minute on first load and reopening it will only scan what's changed which is fast.
I doubt IntelliJ plugins slow down the IDE noticeably, though I do keep the number of plugins activated to minimum for only what I use.
> I am not even sure I could write Java from scratch in Vim - its really that I'm using IntelliJ, not writing Java. Is this bad?
What I see here is the IDE being powerful to make up for a lack of power in the language. Is that bad? Maybe.
I tend to think it's bad because tooling usually does less for making code easy to read than it does for making code easy to write. Furthermore, one of the few characteristics that seems to consistently predict defect rates is codebase size.
On the other hand, increased abstraction can also require more effort to read, and you'll get a lot more resistance in most projects to switching languages than you would to you switching your editor.
I agree, I used VSCode for Python programming, until I found Pycharm is better. I also used it for Go programming, but later found Goland to be better.
But what confuses me is that the article always references it as a "Text Editor", not an IDE. As a text editor it might be the best, but as far as I am concerned, I just don't need "standalone" text editor. I don't have usage for it. I use IDE for programming, and as far as writing text goes, I need that only for writing notes or software documentation, and for that I use Drafts app, Roam Research, or Google Docs.
But I am curious to learn how people use VSCode as a "text editor".
If you spend your entire day in a huge project with a ton of code and work together with a large team of software developers, you'll probably use an IDE. Your workflow probably involves launching the IDE once per day or even leaving it open all the time.
If you do mostly consulting work, small projects, switching between languages with poor IDE support (usually dynamic languages), you'll probably use a smart editor. You'll launch that editor multiple times per day, close it, reopen it, etc.
We should talk more about workflows, there are a ton of them and they're very different in my experience.
It seems like the only distinction between an "IDE" and a "Text Editor" nowadays is that an "IDE" is slow to start up but a "Text Editor" is fast to start up.
Everything else that would be in an IDE historically (project browsers, intellisense, code completion, refactoring, integrated build and debugger UI, test runners, etc, etc) all show up in "Text Editors". The only question is how good that functionality is, which varies between editor-language pairs.
Visual Studio is very much an IDE, but it is perfectly capable of editing a single file too. I think the only reason people tend to use something else for single files is because it tends to be slow to start up.
I personally use VSCode as a text editor in the sense that you describe. I edit my notes in VSCode with Foam, a similar tool to Roam Research. Similarly my blog is based on Jekyll and Markdown files so I use VSCode to edit those markdown files when writing posts. There are definitely cases where I use VSCode as an IDE for other projects but it works well as a simple text editor too IMO.
I'll add to your Java anecdote: JetBrains editors appear to be the most sophisticated across multiple languages. PyCharm is a pleasure to use with Python, Rust, and Typescript. Perks include catching errors on its own (eg before compile in Rust or TS, and don't even need to run Python's type checker), auto-complete, and refactoring. In comparison, VsCode appears to only understand these languages at a surface/syntax level.
I don't like this situation: I wish there were more competition, but it appears one company has the edge at present. I use VsCode for one-off files, since Jetbrains isn't a good fit for these.
Intellij is always too buggy and slow for me. Things it helps you with - it's a language verbosity problem. Ideally you should just use better language.
And they also stopped bringing any more advanced features, like refactoring from null to Optional for example, or reversing template method.
If we're talking about java specifically vscode and vim would just use eclipse language server which can do most of the things intellij can like refactorings and snippets. And for other languages like python ms language server is even better than pycharm for example.
I can't stand writing C#/Java in VSCode and I can't stand writing anything but them in Intellij/Rider personally.
It's a trade off between speed and feature set.
I'm glad it's one I can decide to make when and where I want to.
Hopefully one day a full featured IDE will be as fast as I want, but until then I'll be switching between VSCode and JetBrains products depending on what I'm doing.
My personal gripe with intellij is how unintuitive the shortcuts are and how much clicking is the default way of operating.
intelligent completion is something like cmd+mayus+space. "find usages" is cmd + f7 (which in osx means cmd + fn+ f7). The "open" dialog for opening a project doesn't even have a default shortcut, it's mouse based and will open a second dialog asking if you want a new window or just reusing the current one. CMd+mayus+f for global search wont work if my focus is on the integrated terminal, I have to click out of it.
I feel like I'm learning to play piano placing my hand in weird chord shapes constantly, and half those things launch an ui pane or menu that I practically need to navigate by clicking even if they sometimes technically allow some kind of keyboard interaction.
It's not like I'm an extreme vim+dvorak user obsessed with having everything in the home row at one button press, but a bit of thought into priorizing shortcuts and placing the common ones in comfy places would go a looong way.
shift-shift is the 42 of intellij editors, open files, rename things, import ordering, search class/function/method definition etc etc.
"shift-shift open" to open projects.
next time it will probably be "shift-shift o"
It also displays the actual shortcut.
Integrated terminal (and all other cases) switch focus to the editor: escape.
For all other cases: you are probably aware that you can change shortcuts. For example to vim shortcuts. Not 100% the same but still. And yes, switching editors take some time get used to.
(I love pycharm, i like VScode for small projects, dont like the un-integrated mess of for example spell check correcting function names?)
> JetBrains products allow you to do so much out of the box, without installing a million plugins that may or may not work.
The problem is that all I need is 2 or 3 plugins. If all I need is a golf cart I don't care that your Lamborghini is amphibious and can fly to the far side of the moon
People have written the same hype driven articles about Sublime, Atom and even IntelliJ. The same articles will continue to be written for whatever comes next. Just use whatever you feel makes you most productive. Having tried VSCode I ended up sticking with PyCharm/Goland.
Before all this, almost twenty years ago, there was JPad Pro another editor that I felt as close to as I feel about VSCode now. It didn't have plugins per se, but you could very easily script new behaviors into it. After that, there was a period of vi usage, before I adopted Sublime. The lesson for me is that VSCode too, will be superseded by something different.
it's not that simple is it? I've been programming for ~40 yrs. I've used a bunch of different editors. I certainly don't know each feature of each one but many features I find to be force multipliers so ignoring them is a disadvantage IMO. I'll be wasting my time doing something manually the could be automated for example.
Unfortunately it's hard to know how to configure every editor and know how to get these time saving features.
A few I get from VSCode (love to hear about other editors)
1. the best Javascript support via integration with eslint
Eslint's plugin system means I get react specific hints and error messages. I'm not used to an editor giving me library related errors. Usually they only give language related errors
2. codespell plugin
This only matters for dynamic languages but it turns out spell checking code can be surprisingly useful. The language it self can't tell me
Lots of people mention this but it's arguably a killer feature. I can't believe that it took until now for an editor to have this. Most previous editors I've used to had to go through the process of making some kind of project to get similar functionality. If I wanted to easily search and replace in a project across files I had to make a project or configure stuff. If I wanted it to find references to other files I'd have to make project or configure stuff. vsc seems to find these things with no work on my part.
4. pretty good file support (renaming and moving files, including the required code refactoring to go with it). Every IDE-ish editor I've used since the early 90s has had some kind of file tree panel but VSC's is the first one I use regularly for more than just opening files.
5. friction-less easily discoverable plugins
I think this is overlooked but consider the Apple iOS app store vs Windows CE. I could install apps on my 1998 Casio Windows CE PDA but it wasn't friction-less like the App stores today are. That difference is huge. Every editor I've used since the 80s has been customize-able but I rarely looked for other people's customizations. It was just too much work. Not only did I have to learn how to install them and get them to run I had to go manually find them. VSC suggests them. I get that can be annoying but given low-discoverablilty or a few annoying notifications I think promoting them is a net win.
That said, I hate that VSC is slow! I work on quite a few hobby projects where I just want to put all the code in 1 file. At about 1000s lines VSC starts acting up, getting janky (on a 12core 64gig ram AMD Ryzen 9 3900XT) and eventually I'm forced to split the file. Sure, better organization is good but my tools shouldn't be forcing it on me when I'm just making something throwaway.
Out of curiosity, are you using the vim plugin for VSC? There's only one, but it has a huge install base and causes really insane performance issues in a wide variety of situations. It really should have a disclaimer in its description.
I think the fairer comparison is with Visual Studio 2019, not Visual Studio Code. Visual Studio Code is free, making it highly attractive for a larger audience. The pricing for IntelliJ is not accessible: https://www.jetbrains.com/idea/buy/#personal?billing=yearly
I've also used IDEs that are highly optimized for Java and .NET. I agree it's great for the use case I had.
If you are building software in a paid capacity then yes it's a small price to pay. But if you aren't getting paid or getting paid somewhat decently (e.g. study, hobby, open-source) then it's a lot.
It's great they have various editions, to address the above, so if those editions are good, then it makes my point moot.
edited: Recognizing different free subscriptions exists
I have had the same experience. VS Code looks like a fine lightweight text editor plus a marketplace of plugins with variable degree of maturity and interoperability whereas IntelliJ is a mature and polished IDE.
All IntelliJ lacks is two things:
1. Being a lightweight editor with syntax highlighting which IIUC they are / have already built
2. Remote development where the IDE is just the front end running on, say, a laptop and the computation runs on a remote work station
I prefer IntelliJ to VS Code but for me IntelliJ also lacks the ability to:
Disable plugins on a per-project basis. (I currently put up with plugin exception reports for other language plugins in projects for unrelated languages.)
Enable or update plugins without a full restart. (This is getting better but many plugins still need a full restart.)
Sync all plugin settings (for example, AceJump plugin settings aren’t synced).
Split the terminal pane horizontally.
Open a file in a vertical split from the navigator or search everything box. (I want to believe I missed an easy way to do this; someone let me know if so!)
Set alpha keyboard shortcuts in quicklists.
Style the title bar colour on macOS to match the editor background.
Write a quick script to add missing IDE functionality without boilerplate or build tooling.
I can do all of these in vim and Emacs and most in VS Code.
They’re nitpicks and no editor or IDE is perfect. I think I feel the pain points with IntelliJ more acutely because for many of these I can’t fix them myself.
> The idea that VSCode is the future doesn't seem right to me.
VS Code is the future of editors, not IDEs or all developing.
There will always this two sides which live from the box and those who build their own box. And for the later VS Code is nowadays one of the best road to walk.
> JetBrains products allow you to do so much out of the box,
It's also very limited on where you can work with it. It works for the handful most popular languages they support, but what if you get a bit more exotic? What if need something non-programming, like markdown, rst or plantuml? What if I am not satisfied with a certain feature in the IDEs editor or workflow?
If your Box is not supporting it, you need to customize it, and there JetBrains is just not as good as editors like VS Code, vim, emacs.. And VS Code even goes to great lengths to gain the IDE-state of having everything out of the box.
Just wanted to let you know that all those file types have support. Markdown and rst via the official markdown plugin, and plantuml via a free(in both senses of the word) third part plugin.
Yes, that's the point. For everything outside the box you need to install a Plugin for IntelliJ too. So there is no difference in that regard.
But there is a difference in culture and availability between a box-driven community and a plugin-driven community. The plugin-culture has more likely a good plugin for something exotic than the box-culture.
For example, searching for mermaid (popular diagram-tool for markdown) in InteliJ-Plugins I only found one commecial plugin that I need to pay for. So it seems here already is a popular corner which is not well covered in this box-culture. And we always can go deeper there, toward more exotic stuff.
IntelliJ is a much better experience than VSCode. Without leaving the IDE you can: edit (with autocompletion), static analysis, debug, test, code coverage, version control, profile. All using JetBrains official plugins.
I've switched between IDE's and "lighter" editors like Sublime Text and VS Code so many times now (and I can't get used to vim and co, I'm too young I guess lol).
IDE's helped me so much writing Java code; refactorings, autocomplete, code generation etc are features that never became as good in 'lighter' editors.
Then the JS era appeared, and IDE's couldn't really do much with it - in part due to its unstructured setup, lack of importing code, lack of namespaces. Autocomplete and jump-to-definition was non-existent. I switched to Sublime Text for web work, and relied heavily on the powerful and fast global search and cmd+p navigation for a good while.
Over time, things changed; JS got modules, JS got types (or type inference) through projects like Flow and Typescript, and JS got richer with e.g. JSX. Still mainly used VS Code (by then) for front-end though; heavier editors didn't seem to offer enough added value to warrant the switch.
But every time I did back-end work I would switch back to a proper IDE. Java / JVM languages are things I never did in a lightweight editor. Go (which I use as a back-end language currently) support was rough for a good while in both editors and IDEs, but it's getting there.
In my current job, I handle four languages over two projects; there's the legacy project, PHP and JS / Dojo, and the new one, Go and TS / React. I've fully switched to using an IDE again; intellij's JS / TS support is good enough, and honestly for the legacy codebase I need it. The codebase is nearly 10 years old, and the 'hip' editors simply don't support PHP 5 or 13.000 line spaghetti messes. But intellij does; I configured it for PHP 5.2 specifically (so if I use the shorthand array syntax it flags it up) and ES5, it struggles a bit but it can make sense of the huge files, and it helps me a lot in making sense of it. It's a safety net that the codebase and language itself doesn't give me.
VS Code and co wouldn't come close.
Anyway I still switch to VS Code from time to time for one-off tasks, quick edits, formatting, etc.
I'm using IDEA and VSCode in conjunction (for Kotlin and Typescript respectively) and I find them equal in power. Maybe I'm not a power user, but I reached a point where they even look the same (more or less).
There are 2 minor differences I experience very often: VCCode is blazingly fast compared to IDEA, and VSCode has much more quality plugins than IDEA (at least for those things that interest me).
I'd compare VSCode to Emacs in a sense that the architecture is really simple (all you have is functions that do something) which makes VSCode more appealing to prospective plugin developers.
I'd even go so far as to say that to me VSCode becomes the new Emacs.
Perhaps that is because of the very narrow focus on what IntelliJ does and the functionality of plugins is part of the core system of IntelliJ.
In my view, VSCode is a platform. It's unfortunate that they chose to use Node (its slow) but otherwise, its a great platform to develop extensions for.
For someone just getting into programming, it offers a great stepping stone and it can handle medium sized projects quite well.
The problem is, after installing bunch of plugins it is still no match for IntelliJ. If it was, why would I pay for it...
I want a plugin to parse the SQL query and do auto complete, check for syntax and column/table name errors according to the database I connect to through ssh tunneling but it's just a string in VS code. It also auto completes join columns by checking which foreign keys may match on the table I'm trying to join at the point of typing "JOIN [table name] ".
I want a plugin, so if I open a file, it checks the remote file and make sure it's not modified, so that I don't accidentally overwrite it in case someone has edited the remote file. (Yes, this sounds dumb but non programmers don't do like we do.)
Jump to definition should work like expected, reverse jump to uses from definition should also be there.
Formatting code with so many customizations on many languages including SQL, CSS with a hotkey or against a whole directory. Should the brackets go to next line or not, should there be spaces, should it be tabs or spaces etc. I see there's "prettier" etc but the supported languages and customizability aren't there.
My use case for the IDE should be narrower than others as I only use it for the web development but still it's a few miles ahead of VS code today.
But competition is good. I'm sure JetBrains may start sweating in 3 or so years when things actually start to be competitive but VS code is free and lighter.
> I see there's "prettier" etc but the supported languages and customizability aren't there.
Er, how? What language does VSCode not support formatters for with an appropriate, existing extension, including full customizability for the formatter?
Now, there's not an integrated UI for customization, instead relying on each formatters native configuration method, but that also makes the formatting configuration independent of the editor. For me that's a plus.
Agree.
I am now working on a project that includes development in Android, Java server side, Swift, Xamarin, Unity (c#).
By using Intellij products namely AndroidStudio, Idea, AppCode & Rider - I have a unified experience which makes development so much easier, and fun!
Only con might be the price - but I would not know as its all payed by the corporate I work for - with their IntelliJ licensing server.
> In IntelliJ I can write a half baked statement like `new Foo()`, and then Alt + Enter my way to it being `foo = new Foo();` as a private member variable of the class in no time
This will be in VS Code one day, except when it's there it will be for all languages (some neural code completion engine) and do much more.
My experience of IntelliJ is that it looks nice but it is very complex and offers little compared to Eclipse. For professional reasons I had to learn Eclipse, and now I see that IntelliJ gives a more polished product. But when I need to relearn all that I had with Eclipse, I don't see the point.
IMO Eclipse is dying. Its new release cycle is pain because it fixes bugs only on quarter releases, they don't release patch releases even if very problematic. I encountered a few bugs.
I’m going to save this comment for many years down the line. I don’t agree with your sentiment (having also used VIM and Rider, but happy right now with VSCode), so it’s a sort of personal check-in I can have with my thoughts sometime near 2030.
Not a problem I've encountered, but one that will be solved by the robust extension ecosystem of VSCode. You can apply this to any UX problem you might encounter with VSCode.
I double-checked this, you are right, I thought they completely moved to the adobe model, but they are just trying to represent themselves as they did, still you can stop paying and keep using the software you bought
I completely switched to VS Code once I discovered the remote development feature [0]. It allows you to run VS Code locally but work on a project in a different environment (via SSH, Docker, WSL). The integration is seamless - search, debugger, terminal, extensions - everything looks and behaves as if it was running locally but is delegated to the configured remote. You can even have different remotes opened at the same time.
I use this setup primarily to have at least some sort of a barrier between my system and the gigabytes of NPM packages that get downloaded as dependencies. Moving between systems easy as well - I just copy the VM images. It also makes it easy to experiment a little bit. If I want to e.g. upgrade an important package and something goes wrong, I just revert the VM and I'm back in business. Having Arch as the distro is a nice bonus.
There's a chance that IntelliJ IDEs will get the same remote functionality as well but the timeline is unclear [1].
This is such a hugely undervalued feature, and no other editors seem to provide anything remotely close. I found it particularly useful for the COVID work from home - I yeeted my work laptop into a corner and just SSH into it to continue working with the ergonomics of my home desktop machine.
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.
This is also true with TRAMP. Anything in core Emacs, and any package outside it that isn't aggressively poorly written, works transparently with TRAMP. The core utilities for interacting with the OS such as start-file-process are all TRAMP-aware. (Or more specifically, TRAMP provides file handlers which customize start-file-process)
One area I have found where TRAMP really suffers is when you have a relatively high-latency connection. I'm living on the east coast right now and connect to a dev box in Washington to work, and tramp is basically unusable. Every time you enter a folder in a project, emacs will stall for 1-2 seconds (unless the folder has been entered and cached before: unfortunately every time you restart emacs you'll have to go through it all again). If you've forgotten to disable autocomplete in a remote shell buffer, the first character you type will cause emacs itself to hang forever. There's unacceptable lag when opening and even navigating files. Good luck ever running grep or magit.
With VSCode on the other hand, I have no issues at all: couldn't even tell the project was remote.
I still use emacs (emacs -nw via ssh), but it's nowhere near VSCode's responsiveness and now I cant use GUI emacs. It's definitely a source of frustration :/
That comment doesn't contradict the post at all. If anything it supports that statement and then goes on to mentions that high latency connections are problematic.
High latency connections are a fact of life. If Emacs Tramp, for which development was started in 1998, when high latency connection were a lot more common, still has issues with high latency connections, that's not a glowing reference for its architecture.
Especially since it seems VSCode manages those connections better.
It's ok to admit your favorite tech has flaws, everything has them.
Not disagreeing with that. I am just saying that the previous post was that plugins don't have to be modified with Tramp and work transparently. The post referenced above does not disagree with that. Instead it says that tramp does not deal well with high latency connections. I think is important to be clear where the issue lies if one wants to get it fixed.
> The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection.
This is cool when the machine you are connecting to is more powerful than the one you are sitting on. This is far less cool when the machine you are connecting too is less powerful than your desktop (RPi or Beaglebone, for example).
Remote has been a game changer for my development as well. Work forces me on a Windows machine with the full suite of corporate spyware. Said spyware loses its mind when compiling, debugging, language server inspection, git actions on large repo, etc. Performance loss is somewhere in the region 2-10x.
With remote, I am able to do all coding on a non-infested Linux server with almost seamless usability.
Your company is equally cool with you just having all of your code/IP on a unsecured (i.e. not running crazy large antimalware, not actually insecure) Linux box?
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 read about this fact elsewhere also. Could you expand on this a bit? My impression was that VSCode and its associated extensions are open source, so I'm curious how Microsoft could make certain parts exclusive to its own build of VSCode.
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.
In order to contribute you have to sign away your rights, so it's only permissive to MS. It's a pervasive view on open source, cheered by sockpuppets, making people believe MS is now a open source company.
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.
Eclipse foundation has a new project, Theia[1], which forks VSCode and one of the reasons they state is that the extension ecosystem is not opensource.
They want Theia to be a tool to build your own editor and it can be built as a hosted solution (like code-server) or a standalone editor
Edit: I see that the article also mentions Theia but this point about Theia vs VSCode is not mentioned.
I use JetBrain's remote python interpreter functionality[0] with great success and convenience. For anyone whose development environment is appropriate for its use, I honestly cannot recommend it highly enough. It's only available under the full "Professional" license version, however.
This uses SSH and SCP to automatically deploy the code to the remote environment and run it with the interpreter on that machine, rather than your own local laptop/desktop. One advantage is that it does not require any special software to be installed on the remote server. I believe VS Code's solution requires a pretty hefty installation consisting of basically an entire copy of VSCode onto the remote server.
The downside of JetBrain's approach... I believe that it requires a local copy of the files in order to perform the "LSP"-like syntax error highlighting / suggestion functionality that JetBrains software is so lauded for. This could be difficult/inconvenient if your codebase is particularly enormous, or if you aren't allowed to mirror it locally.
However, given the amount of support that JetBrains has for this kind of setup, I wouldn't be shocked to see an additional option for something more in the style of "VS Code Remote Development"
I spoke to the team in KubeCon last year and they said “our research team is looking into it” with a hand wave. I doubt IntelliJ will actually implement this anytime soon, sadly.
It is also great for string all dependencies for development together in a docker-compose file. On any machine you just have to git clone and open vscode in the container and you are good to go. Even if you require a particular version of postgresql, some compiler version or a complete Kafka cluster; everything can be configured in a Dockerfile/docker-compose file and stored with the code. No more pages long readme's of how to get all dependencies set up just right. Especially when often switching between projects and machines this is a godsend. And for onboarding it is so easy to get someone a fully configured working environment.
Absolutely. I build Android images (AOSP/kernel/lk customization) and at the beginning I was using Eclipse over a shared network folder (I have dedicated remote hardware to host and build these monstrous images), but everything was a chore. Then I switched to VSCode + Remote Development over SSH.
Imagine placing the workspace at the root directory of the entire Android source tree, pressing ctrl + shift + F and finding anything in less than a couple of seconds. For C/C++ code, press F12 just ANYWHERE on the code to go to the definition, no matter if it's the entire kernel code, or vendor or AOSP code: it just finds the definition at lightspeed.
For building I use the integrated console. If there is an error or a warning anywhere, you can just click on the console an it takes you to the file with the error/warning. Also it integrates perfectly with Git and has extensions to parse DeviceTree files.
And everything was just much more appreciated while working at home during pandemic.
It sounds like a testimonial advertising, but it's the way it is.
> I use this setup primarily to have at least some sort of a barrier between my system and the gigabytes of NPM packages that get downloaded as dependencies.
You can do something similar with IntelliJ by running npm inside a Docker container with your working directory mounted into it. IntelliJ will happily index the resulting node_modules folder without executing any code on the host.
The only thing that's been preventing me from fully adopting this is that I don't have my local shell environment (autocomplete, syntax highlighting, etc.) anymore. Maybe I'll have to look at getting that setup in a container sometime, and then copy that over to every container I use.
Maybe it works for literal remote development, but the jetbrains support for remote dev in a docker container is a complete afterthought. There's tons of critical, relevant feature requests that have been stuck in the pipeline for years. In vscode, it is well thought out and polished. My team desperately wanted development out of containers to ease on-boarding and standardization of development environments. Trying to make it work with CLion was a nightmare that was practically dead before it started, and we thought we'd never get it. Then we found vscode's support and have never looked back. I sometimes laugh looking back at what we were having to do to get it to even slightly work, and think about all the troubles we would have had ahead.
I'm not a fan of VS Code because everything is a plugin.
And plugins are inconsistent, buggy, inconsistently documented, hard to use and find and update and goodness knows who developed them. Plugins can be duplicated, outdated, abandoned and incompatible.
But worst of all, a big pile of plugins isn't a consistent integrated product vision.
I gave VSCode a solid go, and I had to keep installing plugin after plugin, but it was truly painful trying to find where in the interface to use the plugin and how to use it.
It reminded me of using VIM as an IDE - not an IDE, a big pile of stuff that isn't integrated. I started using VIM as an IDE when I started programming and I believe it cost me a year of time - I should have gone straight to a consistent integrated IDE.
I prefer a batteries included approach such as the Jetbrains IDE's.
I absolutely do use VS Code - it's always loaded, but I only use it like a simple text editor.
You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality.
The Microsoft Python one is excellent, as is the Remote development one.
I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)
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.
The problem with systems that are really just frameworks for other to build on is they become reluctant to build stuff that plugins exist for. The philosophy becomes to depend on the plugins rather than built out needed features. This entrenches the spaghetti pile of plugins.
Plugins are great and necessary - Jetbrains IDEs have plugins. The difference is a philosophical one - are plugins there to provide core functionality, or are they there to provide uncommon use cases? VSCode uses plugins for basics, JetBrains builds basics in - with JetBrains you can never install a plugin and happily work away. With VSCode, the very first task you must carry out is to start managing your inventory of plugins.
I could not understand why anyone would be happy if VSCode came with 50 core un-installable plugins and none of them were useful to you, since everyone has slightly different projects they're working on. It would be inefficient and it wouldn't cater to a larger user base.
There's a happy middle ground that far too projects choose: building a modularized system, but distributing core, currated plugins with the system.
Effectively, I don't care if I receive a batteries-included product where the batteries are pre-installed and on-demand loaded, vs one where they're permanently installed.
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 thought that until I realised IntelliJ Ultimate is really IntelliJ + WebStorm + PHPStorm + RubyMine + PyCharm + Goland and with plugins you're covered for most major PLs except C,C++ and C# which require 2 separate IDEs.
That depends on perspective. If you are a professional programmer using JetBrains tools as daily drivers then I think think £100 over the InteliJ price is pretty reasonable to get access to their entire library of tools.
Consultants make at £400 day here, dotnet devs usually more.
If you are a hobbiest, it's cheaper.
And the costs decrease each year.
If you are saying £100, then it sounds like it would offer you money for value, so it's probably not for you.
> 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
>> 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.
Wasn’t there recently a thread were Microsoft interviewed someone that has a third party dev tool, declined to hire him and then recreated the same tool with almost the same name without acknowledgement?
You mean the app that he named almost the same name as another, long-existing Microsoft product? (NuGet) It's not like AppGet was developed in a vacuum. And it's definitely nowhere near the situation like Facebook cloning Virtual Desktop, threatening to crush the original developer if he didn't join them, and naming it the exact same thing.
Right, but they would. Plugins aren't paid right now, so all I'd think it would take would be Microsoft saying "hey, people like your plugin, we'll pay you to maintain it, and if you don't want to maintain it, we'll inhouse it."
Sorry to spoil the party here but I wouldn’t call it excellent. I need to set environment variables and PYTHONPATH in 3 places (for the integrated terminal, for background processes and for the debugger). New environments are only detected after restart of the UI and It doesn’t Index or allow go to definition for libraries downloaded via pip most of the time. Also no refactoring support...
This is really frustrating. Am I doing something wrong?
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.
Hey, thanks for your input. I will look into using pyenv so that might solve my problem with "go to definitions".
However, I was also having a lot of trouble with environment variables, especially PYTHONPATH. How do you solve that?
Also rope did NOT work well for me. When I tried to refactor (rename) a function definition, it also changed variables in unrelated scopes that had the same name and were not related to the function at all. So I did not gain anything from that which I couldn't achieve using CTRL+F replace.
I've never had any trouble with PYTHONPATH, I guess this is solved by pyenv with virtualenv. You just need to select the project interpreter the first time you open the project and it should just work.
I haven't used rope extensively, it's too bad that it doesn't work well. It's open source so I guess it needs more contributions.
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.
JetBrains IDEs are development environments, meant for editing code, in specific primary language. They really try their best to understand code that user works on (which is a hard problem, because code is frequently invalid while it's being actively edited), and make it as convenient as possible.
VSCode is - in my understanding - essentially, a step over older glorified extensible notepads on steroids. Unlike those older extensible notepads, it does have built-in programming language editing features, but mostly it's still not the core product but rather a job for extensions and language servers to fill that niche.
So for me VSCode wins over editors like Sublime or Atom, that don't have core programming language processing concepts baked in, but still loses to the specialized IDEs where specific language support is a primary feature (like PyCharm or GoLand).
> JetBrains IDEs are development environments, meant for editing code, in specific primary language.
I've used RubyMine and IntelliJ. IntelliJ kept me sane for the thankfully-short time I worked with Java, and I appreciate it. But I can't get past how SLOW RubyMine is. Even on my $4,000 MBP, it just feels sluggish. Maybe that's because I'm at home on Rails, and I can think faster than the IDE, but there's really not much excuse to my mind for being that slow, especially on top-end hardware. It once helped me debug a plugin of plugin of a gem, and I'll be forever grateful for that, but I keep trying it every so often, and failing to part with my cash for it. I pay a lot for software, in general, but that one's just too steep for my taste, when tools like vim, Sublime, and VS Code exist.
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.
Java, Python, Go, Terraform, Bazel, all in the same IDE at once. Best in class refactoring for all of them. Handles the monorepo surprisingly well (Bazel is a big help here, too).
I had to bump the memory a bit on the IDE, but after hundreds of thousands of lines of code the index gets large.
I used to use VSCode heavily... Emacs before that. But now with IntelliJ I don’t really need much else. The plug-in ecosystem is really nice too.
PyCharm is also a common IDE core with a bunch of Python-specific extensions on top. It just so happens that JetBrains ships those extensions pre-packaged under different names for various target audiences, and they - especially the Java ones - have a lot of features, and decades of polish.
Can’t speak to CLion and AppCode, but Rider is spectacular. It integrates all of Resharper’s (JetBrains’ C# code analysis tool) features with the IntelliJ core that run circles around the bloated, buggy mess that is modern Visual Studio (not to be confused with Visual Studio Code).
Love Rider. ReSharper makes Visual Studio unacceptably slow though. It's already borderline without RS but adding it makes it totally suck, for me at least.
Use Emacs - it's a big pile of stuff that's very well integrated, because the platform lends itself to deep interoperability - thanks to a strong conceptual model and extreme reprogrammability. :).
Jokes aside, I guess what VS Code needs is to grow a strong community of people who care about the editor as much as what they do using it. Emacs has managed to do that, so it's possible.
It seems like Emacs shares the same product philosophy of VS Code. Outside of the core functionality everything is an ELisp/Javascript plugin.
That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.
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.
Keyboard conventions do come and go but muscle memory is expensive to reprogram. Your hands are also irreplaceable. So I go for the most efficient that's not too radically unfamiliar or painful.
And honestly one could spend a career learning every editor/IDE in depth without ever accomplishing anything else. Embedded is especially bad as one often must use the IDE integrated into the platform's SDK.
Right but that requires learning Emacs well enough to change bindings. Then all the other tweaks one makes to a tool like text expansions, macros, and learning differences in find-replace, refactoring, and autocomplete.
There's no more learning required for changing Emacs keybindings than in other IDEs. If you don't want to go the scripting way, you can use the Customize interface, which is Emacs's equivalent of Settings dialog in most other software. Hell, unlike most software, Customize interface gives you a choice between applying changes temporarily and permanently, so you can try things out and if you mess up, just restart the editor.
(Under the hood, stuff you change via Customize gets serialized into a file called custom.el. But you don't have to know that to use it.)
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'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp? You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
I've long felt that this was an obvious and good use of Emacs - as a central coordination point for the entirety of one's computational life, with everything manipulated programmatically from a single programming environment with both rich UI capabilities and a full-fledged programming language. No other project seems to understand the value of such a central point... but still, there are many ways Elisp could improve to make this kind of usage easier.
> I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp?
No. But I do use Emacs Lisp to automate certain tasks and then wrap them up in an Emacs interface -- like highlighting some JSON to submit to an API endpoint, or using ivy to select a Docker container to start or stop.
> You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
Emacs provides an OOTB way to hit API endpoints in the form of 'request'. So it's not just the networking primitives, but the utilities built on those primitives that Emacs comes with.
> there are many ways Elisp could improve to make this kind of usage easier.
Emacs Lisp has had two major warts: speed, and the lack of lexical scoping and CL-like constructs. The latter is largely addressed. The former is being worked on with efforts like gccemacs.
Why? A good Lisp will give you a decent ride around the block. Even without reaching code-data-equivalence enlightment, it's a fast way to round your knowledge of various paradigms and approaches.
> At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality.
This is also true for VS Code (with JavaScript instead of Emacs Lisp of course). VS Code is just a bit more organized on the surface, giving it significant advantages over emacs in that regard, but also a bit more closed in culture.
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.
I actually deal with a lots of code, c/c++/js/python/golang/lua/sql, guess what vim can be configured to work well for them all: autocomplete, syntax highlight, auto-format,etc. along with nerdtree, I rarely need mouse at all during coding.
Curious what language/env you tend to work in? I have found that working in JavaScript and TypeScript, I don't really need any plugins when using VS Code. I do install a couple, but none are essential, just some small niceties.
I'd rather take an editor where I add in the stuff I need instead of it coming with all the xruft I won't be using. Visual Studio would be nice but the UI is way too cluttered for me and I can't focus if I can't organize the views as I need them. No issues with VS Code. I'd just wish it'd be possible to pop out the file explorer and git views into their own windows but I can use other tools for those so no harm there.
> It reminded me of using VIM as an IDE - not an IDE, a big pile of stuff that isn't integrated. I started using VIM as an IDE when I started programming and I believe it cost me a year of time - I should have gone straight to a consistent integrated IDE.
You don't start using Vim as an IDE. It's a waste of time, because like you said IDEs offer a complete product right off the bat. You start using Vim as a text editor, for text editor things, and when you're familiar enough with Vim's plugin ecosystem you may start to enhance your text editing experience with IDE-like features. And you may come to realize that's all you need.
Learning Vim for the sole purpose of tuning it into an IDE is a terrible idea no matter how you slice it. I blame people who hype their Vim setup as a complete IDE even though they started learning Vim as a text editor, not an IDE.
JetBrains is and always has been amazing, but I like VS Code mainly because I'm accustomed to Visual Studio which is a huge bloated mess, especially inside a VM. For me it's quite an improvement. I mainly do C# back end stuff, so YMMV. I'm sure C# is a first class language for VS Code.
The Mac version of VS is not actually VS at all, it's rebranded Xamarin Studio. I assume the GP was talking exclusively about "actual" VS when he says it's much better now, which I also agree with.
I totally agree with the everything plugin aspect.
Then consistent and integrated IDEs are a mix of “everything and the kitchen sink” and “our way or the highway”
Personally I prefered to pay the price of an ugly and patchworky workspace to get something that works like I want to work and without too many things I don’t care about.
I agree that there should have been some kind of "core" package for Node.js that is supervised by the developers but still an optional download, but the people that were initially in charge of NPM fought that idea to death in order to make people... use and rely on NPM.
Some people absolutely took advantage of the situation from a financial standpoint and created a business opportunity for themselves, at the expense of the community.
> And plugins are inconsistent, buggy, inconsistently documented, hard to use and find and update and goodness knows who developed them. Plugins can be duplicated, outdated, abandoned and incompatible
This is why my experience with VS Code reminds me of Eclipse.
I use VSCode with no plugins. It's an amazing code editor, and by default it does code highlighting for C++ and TypeScript. I build in a terminal, outside of the editor, the way it's supposed to be done.
Well an IDE is more than just a text editor+syntax highlighting+a terminal.
It's also about type hinting, refactoring, debugging, etc.
And for the two languages you speak of it just so happens that the support is shipped with VS Code since Microsoft is heavily invested in the development of these languages.
VS Code is awesome. If you told me ten years ago my daily driver text editor on Linux would be a Microsoft product, well, you’d have been right.
Sane defaults. Snappy interface. Universal UI on multiple OSes that doesn’t suck. First class and best in class TypeScript support. It’s going to be hard to beat, now or five years from now.
It's good for JS. It's ok for Golang, since there doesn't seem to be anything better that's free. But I still feel it's an editor trying to be IDE. I love it for markdown/asciidoc though.
I'm a long time Linux user/developer, and I've completely switched to it for C++ on Linux.
I've used vim and various simple text editors for a long time, but wow is VS Code nice. The Linux port of IntelliSense (at least for me) works more consistently than any of the of the code introspection tools plugins for vim I've tried. It works especially well if you're using CMake - it can pull all of the header paths out of the generated build system without you having to touch anything.
(using Microsoft's C++ plugin and the vector-of-bool CMake plugin (which Microsoft took over development for))
Using NVim with go-vim, disabled gopls instead using gopls from native lsp. I am fine with that combo.
Markdown on Vim requires fiddling with formatoptions but combined with live :MarkdownPreview in the browser while you type in Vim is fine and displays mermaid among many other markdown extensions.
My only problem with it is performance when you load large repos and occasionally large files because it is an Electron app eventually. I know the extension ecosystem has thrived just because it is Electron but I wish MS worked on a native editor to achieve it.
People like to bash VS code performance, but try opening a 60MB JSON file in different editors on Windows for example.
Notepad doesn't even load and crashes, Sublime will takes minutes to even load the file, Notepad++ will be unusable as scrolling will take a few seconds, and in VS Code it opens immediately and you can seamlessly scroll to any one of the 600k lines without any delay.
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!
Suzukawa Editor (Japanese shareware) is interesting project. It claims it's the best editor for huge gigantic file. It compares with EmEditor in official page and it performs unmatched performance.
I haven't used this because I have no chance to edit such gigantic files.
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).
For what it is worth, I have never experienced this issue on modern hardware, and I regularly work with a very large monorepo.
Perhaps it is my habit of opening a subset of the repo into the workspace rather than the whole thing (e.g. only the bottom 4 or 5 directory levels so there is at most only a few hundred files in the workspace - builds etc just run from the usual command line so not having the entire repo in the workspace is not an issue for my workflow) but I have been nothing apart from really happy with the performance and have never been found wanting more, apart from loading time but that only happens once or twice a week so I can live with that.
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.
Absolutely agree with the remote SSH being a game changer - it is seamless and works amazingly well.
Since the start of lockdown I've been using it to remote edit from my laptop into my dekstop still at the office and it has been a flawless experience.
Compared to laggy and visually-aliased remote desktop experience (I did this for a while a few years ago and I ended up feeling see-sick after a while), or the faff of remotely mounting disks, it has been utterly seamless.
It has the rendering engine of a browser and that also has some advantages in rendering capabilities. Browsers are really good at rendering rich text, it's what they were designed for, and a native editor can't beat that.
There's the occasional big text file that I have to open, in which case Vim would do a better job. But usually VS Code has no performance issues for me.
See, I don't think that's possible. VSCode only has 10 or so employees full time. I don't think they could make a good text editor with this kind of dev speed on 3 different platforms natively.
Sublime is great but it updates once every other blue moon for a reason.
> 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).
(Not a sublime fanboy or anything, just curious) What kind of plugins do you use that aren't on sublime? I was reluctant earlier for the same reason, but after I installed sublime-lsp I didn't think I needed much more.
> My only problem with it is performance when you load large repos and occasionally large files because it is an Electron app eventually.
Discovering & pre-loading hundreds of thousands of files is slow on native too. I'm not particularly pleased with how easily folks write off web platform tech as somehow being the source of problems or slowness.
The one complaint that does seem fair is that the memory usage can be high, because there's so much runtime to load.
Also, I just keep thinking about your ask here. You want a native editor. But it wouldn't be a native editor. It'd be a native Windows editor, a native Mac editor, a native Android editor, a native iOS editor, a native web editor, a native Gnome, a native KDE editor, &c &c; your preference seems to be that Microsoft have made at least 5 editors. I'm not sure how the plugin system could exist amid such a diverse amount of native runtimes.
the electron overhead is fixed. if it has problems with large repos it wouldn't be due to electron. it would be due to vscode itself or some extension you are suing.
There's a couple big knocks against VS Code that don't get brought up enough
The extension API is underdocumented. It's very difficult and time consuming to onboard yourself as an extension author with just the MS docs, since they don't cover the entire API and the vast majority of data structures are undocumented entirely. This is really annoying when functions take structures as arguments and have optional fields. Descriptive naming isn't descriptive if it describes how the argument is used by the callee, not what it means to the intent of the caller.
VSC also inherits the core weaknesses of Electron. Not overall performance/memory so much as startup time (just a second ago I had to wait 3 minutes for VS Code to boot because I had too many workspaces open when my laptop's battery died on me). It can't open multiple windows in the same workspace (this is actually a fundamental flaw when debugging any kind of extension that needs to open its own workspace). It's possible to build an extension that uses compiled node modules, which is great for performance and usability, but it's officially unsupported because those modules are only compatible with the node version of a client's VSCode.
But when all is said and done, VSC has shown that it's a great platform and easy to target as an extension author (or easier than others), LSP and DAP are huge milestones, and the architecture itself is just so friendly to extension that it's created a fantastic and lively ecosystem.
But petty gripe: please kill the git username/password fields when I git clone a private repo over HTTPS in the console. I don't like being aggro towards what other devs find cool, but I think hijacking a CLI with an extension incredibly annoying. And I can't find a way to disable that specific "feature" without disabling all of the git integration, which I use all the time.
We'd love to hear more about the lack of documentation you're referring to. It's definitely a solvable problem. Could you create an issue so we address the problem? https://github.com/microsoft/vscode/issues
Also on
> But petty gripe: please kill the git username/password fields when I git clone a private repo over HTTPS in the console. I don't like being aggro towards what other devs find cool, but I think hijacking a CLI with an extension incredibly annoying. And I can't find a way to disable that specific "feature" without disabling all of the git integration, which I use all the time.
This can be disabled with the `git.terminalAuthentication` setting.
>Not overall performance/memory so much as startup time
Is this actually a problem, though? I typically use VSCode as a "focused" text editor; it's for working on a codebase for a long period of time (relatively speaking). A minute or do startup amortized over hours of work is not much of a bother really.
For quick edits, vim is still my go to. Different tools for different needs.
Yes, because of how VS Code has evolved we're not using it for quick edits but as a front end to entire systems. If I need to check something quick in a remote session that is configured through some extension in VS Code without simple terminal access and for one reason or another I haven't left it idling all day, those times will hurt my productivity.
I like the enthusiasm, but this article is a little too breathless to be fully believed.
> The most important thing I look for when choosing which tools to use is longevity.
In my time, I've programmed using Director, Microsoft QuickBASIC, FutureBASIC, THINK C, CodeWarrior, BBEdit, TextMate, Visual C++, Visual Studio, Sublime Text, Eclipse, Atom, VS Code, IntelliJ, XCode, and probably a few others I'm forgetting. I don't have any particularly strong attachment to any, except for maybe Sublime (which supplanted TextMate, which supplanted BBEdit).
Instead, what I've found is that IDE evolution is converging such that hopping between them gets easier and easier over time. The shortcuts and mouse behavior is becoming standardized, and the feature sets are getting more similar. These days, I just use whatever IDE is the "main" one for whatever language I'm developing in. Within a day or two, I'm up and running fine.
The only one I particularly enjoy using is Sublime and that's mostly for what it doesn't do than what it does. Sublime is fast and unencumbered, so it stays out of my way when I use it. I strongly prefer it when I'm writing prose for that reason.
I agree. With language server protocol becoming commonplace for auto-complete and static analysis, I don't see a huge difference between various text editors.
I'm in a similar boat, except I used VSCode for two years before switching back to Sublime Text. I remember watching [this funfunfunction video](https://www.youtube.com/watch?v=dIjKJjzRX_E) and thinking how much I related to what he says about becoming addicted to tooling. This was me with VSCode; I was spending a large amount of my work time tweaking it, adding plugins, tweaking plugins, troubleshooting plugins, removing plugins, looking for new plugins, etc.
However, the main kicker that made me switch back to Sublime was that I started it up one day and was astounded by how much snappier and responsive it was compared to my plugin-ridden VSCode. Admittedly, I do miss a lot of the plugins I used to use with VSCode, but at the same time, I'm happy to no longer have to rely on them.
"Check for updates" immediately shows "Downloading updates". That's not what I expected. How about some confirmation?
Start a .NET project and you see "Downloading package 'OmniSharp for OSX' (49713 KB)", "Downloading package 'Razor Language Server (macOS / x64)' (51227 KB)". No prompt. Just starts downloading 100MB of deps.
For some reason the Output tab down the bottom has 20 options in a dropdown menu to switch to different outputs ("Github Authentication", ".NET Test Log", "OmniSharp Log"). I'm not sure why I care about any of these - if I do, why are they hidden in a dropdown menu?
F# gets its own icon on the left menu for some reason.
"Accounts" in the left menu has a notification badge with a count of 1 because I'm not signed in to sync my settings.
The settings icon on the left brings up a menu of 12 different options, some of which launch a settings editor, some launch a pre-defined search of extensions, another pops up a modal dialog.
In a .NET project, if I "Start Debugging", it opens a launch.json and in a comment tells me "Use IntelliSense to learn about possible attributes", making me define my own launch configuration instead of a default
When I used Rider at my last job, it would pick good auto defaults that you could customize based on the project configuration, including automatically generating IIS express configuration values.
Are there more explicit downsides you can mention?
JetBrains' IDEs have built-in update managers. They present you each plugin, giving you a tick-box of which ones to update. The Toolbox app manages the IDEs, allowing to update automatically or not, install pre-releases, and roll back. It's polished.
The IDEs use the established desktop UI norms of toolbar menus.
They come with pre-defined 'Run' templates for many languages/frameworks.
There is a single Event Log for output of updates etc.
The left menu has words so I know what the icons mean, and isn't obnoxiously large due to over-use of large icons.
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.
Yes it’s subpar compared to Visual Studio as a .NET IDE, but that’s probably one of the reasons .NET hasn’t been prioritized yet: There is Visual Studio.
If you want a text editor with longevity try vim or emacs. They aren't dependent on the benevolence of a greedy corporation. Over time VSCode _will_ be raided by the bean counters at MS and it will begin to track you, give you ads about MS products, and lock you in to their ecosystem.
I'll never understand why a professional developer would give so much influence over their work to the likes of MS, JetBrains, etc.
Sure vim and emacs aren't the easiest to learn but if you're going to write software for a living it is not worth wasting your time with toys like this.
Two decades of vim here, and I switched to VS Code. As a "professional developer", it's just nicer to use, and makes me feel way more productive than ever. I definitely wouldn't call it a toy.
It's not like you have to give up Vim anyway considering the good-enough VSVim plugin gives you most of the Vim basics. Personally I have found JetBrains' Vim plugin to be the best.
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.
I used VsVim for a number of years and felt the same way. Eventually, I was back in vim full-time (moved on from the projects/team that required Visual Studio). I've spent the last year migrating to neovim. I've spent the last month getting into some C# development and the VS Code neovim integration is very well done. It's not the same, and I will not be switching to VS Code for anything other than this C# work (for the foreseeable future, I just really like neovim...), but it's not an emulation layer (with this plugin the VS Code editor is a neovim instance in the backend) and it doesn't feel like one, either.
You should have switched to emacs. You could have kept the vim UI but got all the stuff (and more) that you get in VSCode. Unfortunately the vim -> emacs path is taken by very few due to religious reasons.
I find comments like this incomprehensible. Are you using a Vim emulator in VS Code? If not, how can you possibly be more productive? People use Vim precisely because it offers a faster more efficient way to write code. What is it about VS Code that makes you more productive?
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.
Sure - that's why I asked. I haven't seen any explanation for why VSCode is more productive than Vim. I hear about viewing files and folders, but you can do that in Vim very easily with no friction.
I'd like to assume you're joking but 20 years of vim doesn't get me anywhere close to the productivity of JetBrains or even VS code on their first years.
Vim first of all has its default set so that only very patient people can live with it. So you need to edit the defaults so much to make it slightly more comfortable, and you need to pick plugins that only some work as expected, mostly not updated in years and they add yet more crazy shortcuts no one can remember and still don't work like modern editors do.
I only use vim to edit config files on servers but VS code can do that these days, vim is losing a position for me as of late. Glad it invented modal typing but it's as ancient as one would guess.
In both cases its open source like Android is open source. The core code is available but its pretty much useless compared to the commercial version. On top of that it is still owned by a corporation who probably don't have their users interests in mind.
It's not that hard to learn a new editor and learning new software is something I enjoy. Even if Microsoft does ruin VSCode, who cares? Vim and Emacs will always be there waiting.
In the meantime, I'm loving PyCharm for Python, Visual Studio for C++, Sublime Text and Obsidian for Markdown, VSCode for Javascript, etc... Different tools for different jobs.
I don’t really understand “influence over your work” here. I agree that there’s a possibility MS will add some kind of monetisation I don’t like in the future... at which point I’ll switch editors.
But as it is, I’m much faster and efficient using VS Code than I am using Vim. It is in no way a “toy”. And it doesn’t influence my work. It’s a text editor!
The last time I opened VSCode was a few months ago. My work has shifted to other things, so I needed it a little less than before. I really hoped that VSCode could be an Emacs replacement, but I think that's a bigger job for me to pursue than I want to commit to.
For me, Emacs is not perfect, but it has always been the most versatile software I worked with. It's very much (and I want it to really be) the everything text editor. I got the interaction model (with a few good modes) burnt into my brain. I find it hard to get used to anything else (I usually also end up installing plugins to emulate Emacs in other editors/IDEs, but they never as good as Emacs itself.)
VSCode does get a lot of things right out-of-the-box: the interface is snappier when doing things like code completions and language plugins are rather consistent with little effort. But that's where it stops for me. At least I understand its popularity.
The thing that bugs me about VSCode is it's labeled as open source but a lot of pretty critical and interesting components are closed source so you have no idea what's going on under the hood. Normally that's not too big of a deal (I use plenty of closed source apps), but when it's Microsoft it's hard to trust what they are doing with that data. That and I feel that this promotes vendor lock-in at multiple levels.
Overall claiming you're open source when a decent chunk of your code base is closed source is kind of like those people who always bring up that they are a non-profit organization and are doing things for the greater good, meanwhile it's mainly used as a way to evade as much taxes as possible while they live very generously. I have nothing against that personally but it's the way it's presented. It just gives off a bad vibe.
I have not personally audited it to see if it's better or worse than upstream vscode, but I believe the spirit of the project is closer to what you had in mind
The biggest feature is probably remote. This is what allows you to have your code in a remote location (SSH, WSL and containers) and still get an integrated experience as if things were all running locally. If your app is Dockerized or you use Windows with WSL and you like intellisense, you're likely using this feature.
Some of the language servers for popular languages are closed source too, which is weird because I thought the idea of a language server was to work together so all editors could get excellent language specific features without having to reimplement the same logic in every editor.
That's not an exhaustive list, just what I know off the top of my head. I also vaguely recall reading something about a year ago about some core bits of the editor being written in C++ for performance reasons and those are closed source but I can't find a reference and don't know enough about the code base to track that down so I don't want to say that with any type of authority. Would be great if someone more knowledgeable in the area could track that down, or come up with a more exhaustive list of things that aren't open source.
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.
> 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.
In my mind, the remote capability is pretty critical. It's something a ton of people use and would consider it a core feature of VSCode. It being a 3rd party plugin is semantics. I know a number of people who use VSCode because of that feature alone. It's a defining feature of the editor's editing experience.
Also there's some language servers too. Yes technically a plugin, but super critical to anyone who wants to use a language server's features.
I guess they are referring to the Microsoft provided plugins which are proprietary and their license denies usage with any VS code fork. Personally I've never felt the need to use them, but admittedly, I barely use VS code at all.
Like the Chrome and Chromium relationship a lot of distros package VS Code as just Code for a version built by your distro without the proprietary extras.
Question I have for everyone who doesn't use an IDE
What is your workflow? I find the following to be true, in that one of 3 things happens inevitably:
1. The Text Editor becomes the IDE, (e.g., with VSCode, if you just live in plain HTML, CSS/SCSS/LESS and JSX/TSX/JS/TS all day, its actually pretty great, lots of well maintained extensions and Microsoft really put their energy into capturing into this market with VS Code I think. If you have more than ~10 extensions installed, I'd argue you got an IDE (not including themes or colorizers))
2. They have extensively curated vim or emacs setups that were built over time to add IDE-like features, in some cases I'd argue they become IDEs themselves via deep customization
3. They move to an IDE
So my question is if none of the 3 are true, whats your workflow like?
For context of my own workflow, it slowly over time is all around my IDE (JetBrains user, hardcore. You'll pry it from my cold dead hands). With the exception of running scripts (sometimes, like builds) and using git (git CLI is the best git interface IMO) I have moved it 100% into my IDE, and I'm so much faster at things, including picking up new languages
When I started, I used VS Code heavily professionally, and vim before that, and relied on the CLI for anything outside of editing the code (basically, I think I had some auto formatting setup too), but I hit a wall at some point where I never turned back and went full into JetBrains to this day
I run a pretty much stock configuration of Sublime Text alongside gnome terminal. I have no issues navigating projects as large as gecko/WebKit/Linux and getting spun up on a new language is really fast: Open the project, maybe install syntax highlighting if needed and you're good to go - as opposed to finding/installing an IDE.
My last Job had a large Java codebase and all my colleagues used Java based IDEs. I didn't see any performance disparity. I more than once saw a colleague take 5+ minutes making the same edit on a large number of lines because they hadn't learnt how to actually efficiently edit code in their IDE.
The way I see it, you need to keep the codebases you're working on in your head anyway (the parts you're working with anyway) to actually be productive. You do this by reading and understanding the source code on the screen. Until an IDE can provide a tailored human interpretation of the code it's analysing rather than some narrow static analysis I just don't see the point.
I'm exactly what you describe at the end: a simple Emacs editor (with Evil) and CLI for almost anything else. Building and running code? They all happen in the terminal. Version control? I tried Magit, didn't like it, and went back to git CLI in a terminal. Auto formatter? Likewise in the CLI; in fact I have shell aliases that automatically run them when I commit.
I haven't really hit a wall, and I personally think I'm just as productive, if not more, than IDE-using colleagues.
Which, admittedly, is essentially the same as the other answers you got, but that's how I've been working for three years, since I decided to use vim exclusively.
At the start, I was really tempted to install plugins, but ultimately I decided not to. Both to practice with the terminal (which has been immeasurably beneficial) and to make it as easy as possible to switch computers at the drop of a hat without losing productivity: just install vim and I'm good to go (and often not even that is required since vim comes preinstalled often enough).
For Python work I use a pretty much out-of-the-box Emacs, with "magit" being the only plugin of note installed. And I also used "web-mode" when I was doing webdev. magit is the best Git interface ever, and a built-in Emacs feature called TRAMP allows for remote editing. I'm running ipython in a separate terminal. I don't really understand why you'd need something more than a text editor to edit Python code.
Now for Common Lisp I use SLIME, which I guess does count as IDE, seeing as it's much more powerful than most IDEs.
Admittedly a lot of it is around things like built in documentation, viewing source code from inside modules (I’m a frontend software engineer so inside node_modules for instance) and the ability to simply let the IDE handle certain things with refactoring components or generating boilerplate.
I found I repeated myself less and improved my productivity this way
Given the talks from Microsoft's own React Native team regarding the 300x performance loss from Electron based apps, I am looking forward to the day it gets rewritten in React Native.
I'm looking forward to the day when you can have multiple windows open on the same project without going through some horrible kludge. Some of us (!) have more than one monitor and would like, say, to put the debug widgetry over on _this_ one.
Speaking of which, as a light user of VS Code, is anyone else completely confused by the project / workspace interface? I'm always confused as to what project or workspace I'm in and what file is associated with what workspace, and what mode I'm in. The UX could use some love with the onboarding experience.
Tried it, but I didn't like how single window seemed to work with the VCS detection. And I found it generally too messy to keep track of what files belonged to what project.
I just have a few vscode windows open in fullscreen on my laptop. So I just switch to whatever one I need to use at that time. It's never really more than 3 at a time.
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.
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.
I used to be such a huge WebStorm proponent, but when Visual Studio Code reached the point where it could handle all facets of front (and back-end) development, the rich ecosystem and fast pace of updates, I cancelled my Webstorm subscription and never looked back. Admittedly, it took me a while to ditch Webstorm, because I loved that editor. The remote development session feature is amazing in itself. I thought it was a gimmick at first, but since the pandemic hit, remote development has been a staple for our company. Being able to pair with juniors and seniors alike to collaboratively debug and code, it's game changing. There is nothing like it and the stability of the sessions is impressive.
What you get out-of-the-box without needing to install a single plugin is more than some. If you're working with TypeScript you get everything you need, including an in-built TypeScript compiler. All that being said, I still lean on Sublime Text Editor 3 when working with large files, which VSCode is still not perfect at dealing with. It's easy to forget that VSCode is an Electron app.
>TextMate, released in 2004, is arguably the most influential text editor ever.
>TextMate’s most important innovation was that it was the first popular text editor that was primarily built around extensions.
I actually laughed out loud when I read this.
Emacs invented the extensible text editor. Emacs was very popular for a long time. It's less popular today, but it's the original prototype for Visual Studio Code and every other text editor "built around extensions". Not a MacOS-only proprietary text editor written in C++ and released in 2004.
The author is right about VS Code becoming the incumbent solution for text editors ... but for the wrong reasons. As he demonstrates, extensions have largely completed their evolutionary cycle with VS Code playing a heroic role in the final act. And he is also right about the benefits of having of a Very Large Corporation collaborating with the open source community.
But instead of asking yourself what will be your daily driver in 10-15 years, ask what you would recommend to a highschool student today? Hint: it won't be EMACS.
For me what makes VS Code sing is its vision of collaboration:
* Git is a first-class citizen.
* Live Share provides real collaboration for distributed workers where you can authenticate with someone else through your GitHub accounts. That sounds pretty good for the COVID era but it will become the norm for remote development. The documentation even has a HOWTO for running a technical interview! https://docs.microsoft.com/en-us/visualstudio/liveshare/use/...
Having said that, the Live Share authentication procedure needs some serious sandpapering of its rough edges! And I would really like to see other authentication providers for Live Share beyond GitHub and Microsoft accounts.
Of course it will be Vim :p, jokes aside I think you may be surprised by the answers you get if you run such a poll
> * Git is a first-class citizen.
I don't see how it's an argument against Emacs since both Doom Emacs and Spacemacs (two of the most popular Emacs distributions) ship with Magit (the best Git interface imho) by default
> And I would really like to see other authentication providers for Live Share beyond GitHub and Microsoft accounts.
Given the current direction of VSCode development in general, this is more likely to never happen.
The "Aggressive development" point is what got me to switch to VSCode from Sublime. While most of my colleagues were switching to VSCode, I stuck with Sublime, after never fully jumping into Atom for performance reasons. However - and I'm assuming due to the open source nature of the platform, or the accessibility of JS vs Python, extensions were just higher quality on VSCode. I think the Go extension is maintained by Microsoft themselves. Very soon things just worked better in VSCode.
For those that like Vim, but also like some of the features that VS Code offers, but do not like VS Code itself and/or its Vim integrations or emulations, I must heartily recommend coc.nvim [0]. It's like using a modern IDE, minus the bloat and anti-features which make most of them (including, of course, VS Code) painful to use.
I was almost going to abandon vim in favor of VS Code due to the "intellisense" features, then I discovered coc.vim and I'm so happy that I don't have to leave vim
While Fugitive is very good, I've yet to find a better Git client than Magit, that's actually one of the things that make me reluctant to switch to Vim full time.
> This is the third time I'm posting this comment because it was removed, but doesn't violate any of the Hacker News guidelines. If it gets removed again, I know not to trust any discussion about VSCode on Hacker News again:
None of your comments were removed. They are all in the thread.
I want to like VS Code, but I can't stand the "dynamic" left side bar. It's used as an "explorer", it's used to handle "extensions" and it's used for search. I want a fixed left sidebar (fixed as an "explorer"). Is this something configurable?
You can try the following:
1. Open the explorer tab on the left
2. Drag every other item on the left bar into the explorer menu. This adds a little menu at the bottom
3. Collapse each of the menus at the bottom and never open them again
Kind of a weird set of text editors in the article. I think the preferred tools depend highly on your language and environment. I'm guessing this is for the JS-frontend specialization mainly.
If you did Java, C* etc. then the ubiquitous text editors/IDEs were not these ones.
I have converted to VSCode because it just works and I don't have to mess with PATH or whatever. I run it on Windows, Linux and MacOS and it works the same.
I love that it's extensions-centric because now I can ignore them - instead of the editor bloating into a bigger and slower hairball over the years as devs add new features.
>I have converted to VSCode because it just works and I don't have to mess with PATH or whatever.
While I love VSCode and use it every day (mostly for markdown), I have definitely needed to play around with PATHs to get VSCode working nicely with my conda installs on both windows and mac (i.e. it never seems to actually point to the right python interpreter). No idea who is at fault here, but it seems to be a consistent problem for me.
The problems with Conda usually have to do with its activation. If you manually activate whatever environment you want before starting VSCode, it should pick it up fine. But if you don't, and then later you pick a conda environment, it'll try to auto-activate it in the terminal for you - and this part is brittle, because anything else using the terminal can interfere with it (and vice versa).
Yep I think you are right. It does seem to be when VScode tries to auto activate it. This github issue had a solution in the form of adding an empty string for a particular option in settings.json [0]. This fixed it for my mac install. I can't remember what I did on windows to fix it.
VS Code is nice for green developers, however I always encourage finding a different editor. This helps encourage exploration, customization, and configuration. You will need to take the training wheels off sometime in your career.
Another reason to prefer other editors is they tend to stay out of your way. VS Code tries really hard to make you not even leave the window.
Anecdotally, a previous colleague once sold me on SublimeText. I had liked it and used the free version but VS Code was also free without pay. The colleague encouraged that it was better to buy a software sometimes (SublimeText license) than continue searching for a free solution for every tooling issue I had. It was the first time I was able to rework my reasoning as to why I should pay for software. The reasoning is simple: invest in yourself. This is more powerful than investing in an no-cost ecosystem to solve your problems.
Editor and tooling has been flame bait since vim and emacs and you're just stoking the flames.
The idea that VS Code is for "green" development only is flatly false, I've used it to work on and debug GCC, hardly green.
The idea you should always be looking for new tooling is also false. If you're a power user of emacs then enjoy it. Consider it your super power, I'm not interested in taking that from you.
VS Code is, in my opinion, thee editor for several languages. The package support is it's real killer feature and the fact that it hits a decent compromise on performance between Sublime and Atom. Atoms packaging is arguably better and more flexible but it leads to bad package performance. Sublimes packaging was annoying when I used it in the past, no better then the train wreck that is MELPA of emacs. Again, all of that being my personal opinion.
It means if I want to use VS Code for anything other than code editing then I’m out of luck. Where as alternatives are text editors first with code editing support.
VS Code wants to be in your way with a complete set of tools, even including a terminal. And your OS already has one of those.
> Isn't this exactly what vi and emacs proponents cite as a benefit?
I don’t know, is it? Are we talking text editors or IDEs? The difference being that you can configure vi and emacs to be any kind of workspace. An IDE has a text editor, a text editor can be configured to be an IDE. Similar but not the same.
I pay for a personal subscription to the JetBrains suite, use IntelliJ and PyCharm all day, and have also used Visual Studio all day in the recent past. The combination of modern IDEs with modern hardware is pretty awesome. My use of Emacs fluctuates depending on the job, language, environment, etc. but I've mostly used it for Org mode and a scratch pad since I signed up for JetBrains.
That said, I tried Nova from Panic (https://nova.app/) the other day, and the native app performance makes a noticeable difference. I know it's doing less, but I can still search the codebase quickly and the resource use is like 10% of other IDEs.
I use JetBrains suite as well. If only they could offer ONE IDE that is configurable to be used on many programming languages. Having many different binaries is a pita.
I use VS Code every day and it's a great platform, but to claim it's the endgame of editors is one big hyperbole. It's a very opinionated piece of software that serves lots of popular niches well right now, but I haven't yet been able to find a mix of extensions that makes it a viable replacement for IntelliJ for Scala, to name one example.
I'd expect the next uber popular editor to be optimized towards completely different things, though. VS Code is a great all-purpose IDE for enthusiasts and professionals, who are willing and able to dig into pretty complex UIs and complicated concepts. Take the git integration – it frequently breaks (for me), and when it works, it's really very superficial and requires me to really understand what git is doing in the background.
Last year I've tried to teach my dad how to use git, so he can put his python robotics projects in GitHub. It's been eye-opening: All the idiosyncracies and complex ideas that I've grown accustomed to over the years, that's one Eiger North Face of a learning curve if all you want to do is get those Python files on GitHub and have some people collaborate with you there.
It's also pretty hard to discover functionality in VS Code. It wants to be everything to everyone, so it can't expose functionality in a way that specialized IDEs can – and even those tend to be either messy or sort of cryptic. It's really hard to be effective in any IDE without memorizing dozens of keyboard shortcuts, which isn't a problem for software people, because we either like this, or have grown accustomed to it. I guess that's why the Touchbar is wildly popular outside of software engineering and related disciplines – for apps that support it, it exposes functionality directly and in a context-sensitive manner.
Hundreds of millions of people around the world will start programming in this decade as the world is rushing into a future where code is the stuff that most of anything outside pristine wilderness that we ever experience, is at least partially made of or faciliated by, that all social, economic, political activity rests upon.
There is no tooling that would be appropriate for this kind of use case – whatever will end up filling that niche, the casual programmer who doesn't want to get deeply involved with software engineering, but get their semi-complex problems solved without tasking a team of SWEs, whatever will do this will have to be a lot cleverer, easier to use, more discoverable, more intuitive – make collaboration feel much more seamless – and still be very powerful. VS Code with its laser focus on the current developer crowd is probably not very well-suited for this.
> It's really hard to be effective in any IDE without memorizing dozens of keyboard shortcuts,
Curious if you use the command palette much? It should be a decent replacement for route memorization of keyboard shortcuts: How do I format this document agian? Hm... F1;form;enter done. And git push? F1:gpu;enter. Etc.
I work on vs code and am trying to improve this area so all feedback appreciated!
Yes, definitely (I use Cmd-Shift-P a lot, which should be the same thing? I also use Sublime so that shortcut being the same is valuable), but more for things I need to do relatively rarely, as it's an order of magnitude slower than just pressing the respective key combo, plus requires some mindspace (what would I best type to find this?) – so it's not a complete substitute, but still extremely helpful. I'm not sure how I'd manage without. But, say, toggle comment is something I'd rather not do via the command palette, though, too slow and cumbersome, breaks my focus. It's not that great for discovering functionality, either ("autoformat" doesn't work, but might be the first search term I think of, etc.) – but it really helps with all the things I know are possible but that I use too rarely to remember a shortcut for.
I really like what IntelliJ is doing with the Mac Touchbar – that comes much closer to a substitute for memorizing (some) shortcuts for me. Cursor in a class definition, pressing shift gives me "Rename", "Change Signature", "Move Class", with Cmd pressed I get "Show usages", stuff that's somewhat context-sensitive and actually useful, though there's still lots of room for improvement, lots of useful functionality that isn't exposed that way, there could be more context-sensitivity, but it's a good start. It's something I miss a little when using an external keyboard or VS Code (which doesn't seem to support the touchbar yet). I have to look at the thing of course, but then it's right below the screen, so its not like staring at the keyboard while typing, and being able to "just do" these things without any memorization is nice, a little bit slower than shortcuts, but it doesn't break my focus nearly as much. No idea how one might offer something like this on devices with no touchbar, but I think they're on to something there, especially for people who spend only a small part of their time inside an IDE.
Good to know you use command pallet, I agree that it's not as fast as keybindings, but in my opinion it's a good way to learn about keybindings for future use -- if I search the same thing on the command pallet often enough, eventually I'll look over and see what the keybinding is.
I agree more touch bar functionality would be nice, though you can add that through extensions if you're really interested.
> No idea how one might offer something like this on devices with no touchbar,
What you describe should almost all be available by default via the F-keys already, which is nice because it works across all keyboards without needing to learn new stuff. I personally have by touch bar show just the F-keys when I'm in VS Code.
Hardly anything could pull my team and I from VS Code's performant UI, great Git integration, astoundingly fast project-wide file search, etc.
At the same time, the Go language server is the bane of our existence. It's so bad that it often blocks VS Code from saving files for minutes on end. To its credit, VS Code's handling of horribly slow plugins is as good as it possibly could be.
I've used almost all popular editors for years, Vim, Emacs, Ultraedit, Sublime and of course VSCode.
But I switched back to Sublime about six months ago.
VSCode is mostly impressively good, it is even quite fast for an electron app. But still, not as fast as Sublime, and I think it degraded at some point, and I could sense it during work.
And then, I might be a bit paranoid but I think that VSCode could be used as a kind of trojan horse by Microsoft.
I don't want a future where everything is on the cloud, including all my tools and files.
VS Code has some great features and plugins, and generally a good experience on both Linux and macOS. As a result, I use it periodically, and I like it. Most people in my developer circles use it exclusively, so it's definitely popular.
But I don't love it. Nor do I think it's the perfect code editor, or that we're in an Era of Visual Studio Code by any means.
I still find that I spend most of my time in vim as it is fast, and suits my development needs well without getting in my way.
In my experience: If you're developing anything outside of JS/TS/Web/Python, the experience in VSCode ranges from ok to totally broken. Which reflects the quality of the plugin ecosystem.
Can plugins really approach the productivity of a more specialized IDE like what JetBrains offers? I haven't seen any evidence that they can, but I'm open minded. The most powerful language support I've seen in VSCode is absolutely TypeScript, and its very good... but is it a plugin? Its not listed in my plugins, it "just works" upon a clean install. Do the Go, Rust, etc plugins just need another four years of work, or will they never approach the quality of TS in VSCode because TS is "built-in"?
And, to be frank, TS is only "very good". Its not "great" when compared to the support, for example, IntelliJ has for Java or VS has for C# when measuring things like the reliability and latency of intellisense and compiler feedback. Which, in my mind, represent the two most important things a code editor should do perfectly. When I have the question "wait, what's that io/ioutil function for reading the content of a file" in VSCode, I literally don't even consider typing "ioutil." and scrolling through the six functions in that package to get the answer, because I know before even trying that VSCode has a 20% chance of helping me. And that's a shame: Because this is by far the fastest way to get this answer; if it worked.
That's not even considering "latency from when I press a key to seeing the action on screen". VS Code is... fine. But my god its startling how much better Sublime is. It feels like spending an hour running on slightly damp soil, then suddenly finding a stretch of paved concrete. But, it lacks in the other productivity features I listed above, and I do think those are more important to get right, for the sole sake of productivity.
I mean, in short, if the next decade is VS Code As King, then it will be a sad decade. I don't trust that VS Code can solve these major issues it has had for four years. Code editors represent a top 3 item in the domain of developer productivity, and there's so much more work we need to do to get them right. We aren't there. And we'll probably never get there if we go all-in on VS Code. I'm so happy to see Panic try something different with their new Nova editor, and I hope we continue to see innovation in this space; not a VS Code monoculture.
I think if longevity is your concern, you can't go wrong with vim or Emacs. Both have been around for decades, which makes them that much more likely to be around for decades more.
This is also largely due to the rise in popularity of JavaScript. I still feel that the IntelliJ editors are still superior, and while it cost money it's not even a stop in the bucket compared to the productivity gains that come with their editors
> Learning software is an investment, and if you have to switch to another application later, you lose some of that investment.
I think the author missed a critical fifth point that they hinted at here. In my opinion VSCode is trivially easy to be productive with and not much of an investment to get into. Whereas heavier IDEs and then Vim at the far extreme demand some serious “learn how to ride this bike before you can do anything resembling useful.”
I enjoy VSCode for a number of reasons, dislike it for a few. One of the main pluses is that I start off productive on day one and can electively add complexity to further refine the tool.
I love tools with user-selected difficulty levels.
Vim has another problem. Once you grok it, it's very difficult to use anything else. If I ever find myself in an editor without some kind of vim mode, I'm totally hating life.
> If I ever find myself in an editor without some kind of vim mode, I'm totally hating life.
Most of the Vim emulations are subpar (slow, lacking features), not to mention when they redefine some keybindings[0], so my life still ends up to be miserable.
VSCode is pretty amazing but at the rate things are moving I can't imagine betting on anything being defacto for "decades". It's possible, and I even hope so, but with this kind of stuff I also always assume that a shift in perception in our industry can change overnight. Also, products themselves seem to go from "perfect" to "how did this become a joke" so quickly sometimes it's baffling. That all being said, VSCode is impressive and I applaud Microsoft. I still use Vim, but keep eyeing up VSCode.
To my mind VS Code (and not only VS Code, vim and other editors also) not only competes with editors, but with IDEs as well. It's interesting that he doesn't mention JetBrains at all. I'm curious to see if there is a trend of people migrating from it (or not?) and why.
> GitHub’s Codespaces also run VS Code as a web app, this time by spinning up an ad hoc development environment.
This probably can be the first time we'll see people use online code platform for real.
> It's interesting that he doesn't mention JetBrains at all.
Think you nailed the most salient point, quite curious in the corporate battle of wits on Twitter, HN, and other venues. Since HN rules discourage meta discussions, I'm gonna stop here.
VS Code is really meant for front-end development.
I wouldn't want to use it for anything I compile or debug. I'd use IntelliJ for Java/Kotlin, Visual Studio for C#, F#, Windows apps.
As with anything else in software development, it depends on the use case.
I'm still partial to Visual Studio and for text I use Notepad++. I used to use UltraEdit, which has some features that were extraordinary (column editing).
I've used VS Code for some things (PlantUML), but otherwise I find it cumbersome.
Seems like everybody mentions GitLens as an example of a good VSCode extension, but I really wish more people knew about Git Graph [0]. It feels like having an embedded mini git kraken into vscode, beautiful graphs and all, and without any noticeable overhead.
I love IDEs... but most languages don't support IDEs. C# and Java are lucky to have a set of features that work well with IDEs - statically typed, OOP, without metaprogramming such as templates and preprocessor. All data is known upon compile time. With languages like C, C++ or D, a lot of code isn't known until compile time, so IDE cannot do any predictive magic. Same with refactoring, in C you can create new identifiers by preprocessor. In Java, you can ask the IDE to rename all usages of printStuff functions to printMoreStuff and you can be certain it will modify all the usages of this specific printStuff function, not the printStuff function from a different module. In dynamic typed languages the types aren't known until runtime so it's another struggle for IDEs.
That's why VSCode is so appealing for languages other than Java/C#. These languages just aren't capable of having the same kind of IDE support. If you can't rely on things like perfectly working autocompletion, automatic refactoring, advanced features like extracting methods into separate class, then all you need is a good notepad application. And VSCode is just that.
The articles talks about editors, but VS Code is mainly an IDE.
Its predecessors were in order Emacs + single-language IDEs + proprietary IDEs, then Eclipse and finally IntelliJ IDEA CE.
Emacs lost because it failed to update to reasonable modern conventions and because it used a niche programming language.
Eclipse lost because they released a bunch of different bundles instead of a single install (apparently because the contributing companies saw Eclipse as a common base for their proprietary IDEs), it was slow for the time, and had a bunch of unnecessary UI complexity (e.g. it had an unnecessary perspective system that would change the IDE layout depending on language, meaning that you couldn't just customize the IDE and have it apply for all languages, but had to customize each perspective).
IntelliJ IDEA lost because only the core was open source and major parts were proprietary, resulting in reduced 3rd party confidence.
VS Code is winning because they have a major company backing it that mostly doesn't seek to make proprietary IDEs with it except for minor proprietary aspects, uses the most popular language for extensions, avoids unnecessary UI complexity and is also fast and technically good.
Don't discount free. People can talk about a good craftsman paying for good tools, but corporate developers have to go through the corporate approval process to pay for just about anything, so free is friction-free.
Before VSCode the king of this was Eclipse. It was free, so it was everywhere, used by a plethora of companies. 2012-2015, when I was using it for vanilla Java development, knowing it let me get up to speed quickly on the Scale IDE, JBoss development from Red Hat, Mulesoft's MuleStudio, Teiid database virtualization, and Salesforce's IDE.
VSCode is taking it's place, IMO; Salesforce has switched to it for its IDE.
1. People who do most of their work in the terminal and don't need a full IDE for editing their config files. A subset of those imo would be those who have lots of different servers they ssh into and like to have the same (or similar) editor everywhere. (vi and vim for example)
2. They like a more lightweight editor. Being able to configure anything relatively easily if you know what you're doing would probably also fill into this.
3. People who primarily use keyboard based navigation and like not having to move their hands as often. I count myself to this group, as I recently discovered doom-emacs and absolutely love the keybindings it has. (vim keys for navigation. Functions are handled by the spacebar and a key combination)
And people with fewer options. There are plenty of situations where you are stuck with Vim or Nano (Vim usually comes out on top if you're doing anything non-trivial).
Another cool thing about VSCode is it can be run in browser [1] now and this browser based VS code is available on GCP[2], AWS[3] and Azure[4] as well if you want to give it a try but note that there is usage cost in addition to the infrastructure usage for the cloud vm.
The author makes some good points. However, very early on after being exposed to vim I decided "CUA" keybindings were the way for me, no context-switching required.
It's paid off handsomely. From DOS Edit, to Netware admin tools, Turbo Pascal, SimpleText, Notepad++, Sublime, Geany, and micro the strategy hasn't failed me yet. I like that they are mature and not changing a lot. Using another CUA editor takes a few minutes of tweaking the control panel. Having everything automated in the terminal with a Makefile or similar is another hedge. Easy to assign to a build key too.
So, perhaps the concern of moving to another editor is a bit overblown. Maybe if you've really locked yourself in—don't do that.
These days I use Geany 90% of the time. Micro another 5% via terminal. They are lightning fast, with just enough support. Have been developing Python and Web/Javascript for twenty years so I don't really need extensive completion. Identifiers, snippets, and linters, etc. are enough for me.
For huge work projects its Pycharm or other Jetbrains tool, but as I said only if huge.
I tried Goland but it was too Java-y and too complex - there are thousands of settings. 4 different search options. 5 different methods of getting to the declaration for a function (and I'm never sure which one I should be using). I ended up spending more time messing with the editor than writing code, and there were too many incidents where I accidentally triggered a feature with a random key combination.
I love Vim but it makes my muscle memory incompatible with everything else. I stopped using it 5 years ago and I still hit ESC way too often.
I haven't tried Emacs yet. It's on the list, friends swear by it, but my experience with Vim has made me wary of investing that much time climbing a learning cliff again.
SublimeText was great, but support for Go isn't all that. Atom is too slow.
I'm back at VSCode for the moment. At least it's predictable and the Go plugin is workable. But I see the feature bloat and the complexity increasing. Its days are numbered. I don't see VSCode dominating the situation for much longer.
like I said, I love Vim. If we could change every other editor to be like Vim, then the world would be a better place.
But we can't, and my muscle memory isn't refined enough to hit "ciw" in Vim to edit the current word, and not in any other editor. Especially web input controls, that tend to react badly to hitting ESC halfway through an edit :(
I'm an iOS dev for the past 8 years, so I've been all in on mastering Xcode. I now must use VSCode for certain things at work, and while it's not my favorite, I love the plugin ecosystem. I really wish Apple had improved the ability to write Xcode plugins; instead they kneecapped it. To folks who say that VSCode plugins are a shambles: flagship IDEs have their problems too.
It's been interesting to watch some of the UX patterns popularized by the editors mentioned in the article creep into Xcode, though. Again, I dislike some, but I'm glad to see evolution taking place, and I need to repeat a mantra I've said many times: "always be learning." That's the only way to remain successful.
I don't actually use a ton of VSCode plugins, but I'll give a shout out for GitLens. It is magnificent. Big thank you to the maintainers.
I love how people bash the performance and memory consumption of Electron, but yet will concede vscode is somehow an exception.
You can write slow code in any language. There's games written in C or C++ for example that will get bad customer reviews for not running well enough for their level of graphics.
> I’m hoping it moves into the category with apps like Excel, Illustrator, Photoshop, software that has held the most popular position in its category for decades.
Products that have stagnated for decades, ignored by their intended audience due to lock-in and entrenched habits? (I have no opinion on Excel)
At first glance the history looks legit but there are missing holes. From 2004 till now we have multi platform/language editor called Eclipse. From early days it supports plugins. How that one fit in the story? Shouldn't author prefer that one for it's longevity?
The article seems to be focused on text editors, not IDEs. I'm not sure why it completely overlooks IDEs as an alternative. Perhaps the author is mostly a web developer, which I find is the main area where text editors really match IDEs in terms of features.
I think it's premature to say that visual studio code is the ultimate in human textual interfaces.
There's a ton to do with optimizing how text works. In a few decades, maybe someone will develop a properly functioning brain/neuron/text interface, bypassing VSCode entirely.
Regardless of whether that is feasible or not, it's really defeatist to just say "oh we give up, Microsoft has made the ultimate text editor" and call it a day.
That's not how the world improves, and you'll find that VS Code will also have its day when it's sunsetting and Microsoft throws in the towl and ends development on the project, similarly to how the Internet Explorer engine team was shut down.
Give it about 5 years, and then we'll talk again about this topic.
I'm glad you enjoy VS Code, but we'll have to see about longevity. I started my investment in Emacs about 25 years ago when it'd already been around 10 years before that (GNU Emacs), and it's still paying off plenty for me.
VSCode is pretty good but annoys me that many tasks are primarily mouse oriented and some keybindings require home/end/pgup/pgdn and arrow keys. Feels tedious when coming from vim/emacs.
I love VSCode, but of late I've relied mostly on vim and Textastic on the Mac, simply because of sheer _speed_ - either can be _much_ faster for simple edits across multiple files (I use Ctrl-p in vim) and have near-instant startup time.
But when I need to hunker down for a long session, it’s great. However, mine is so loaded with extensions that it feels like the “fat” IDEs of yore. And everything is constantly in need of updates.
Its big plus (and reason for success) is that it can be _anyone’s_ IDE, for anything. The extension ecosystem makes all the difference.
Honestly, the tools developed out of VSCode have made my Emacs environment so much more powerful, and so much easier to set up for new languages.
With the language server protocol & debug adapter protocol, I can just plugin in a couple of servers and have a full-blown IDE environment that uses a consistent interface across multiple languages. I remember spending so much time trying out and setting up ctags, ggtags, irony, rtags, gdb-mi, etc...
I don't see myself switching to VSCode because I can just take the best features from VSCode and use them Emacs.
My issue with the language server protocol is that it takes away power from the editor rather then giving power to the editor. Eg. sending text-edit instructions rather then providing an API for code intelligence. And in turns it creates too much work for the language server as it has to both make static analysis while at the same time baby-sitting the editor. Meanwhile the language servers I've tested is only half complete and the editor need a great deal of glue code and extra functionality for each language server. Also the language server need to run on a server, it would be much better if it was script based so it could run on many platforms.
Since I develop at work in a local VM with limited resources, I use Neovim + Coc that I found lighter than VSCode for NodeJs Js/TS, Python, Golang development.
I can be very efficient in Neovim with a bunch of plugins fzf + coc + NerdTree. For editing VI is very powerful with Macros, global + normal commands, etc.
I use VScode for typescript web development, for instance for CSS editing I like having the color displayed next to the CSS value.
For Java I still largely prefer IntelliJ especially with Maven multi modules projects.
This trend of taking StackOverflow polls as global facts has to stop. It is so misleading. Not everyone is on StackOverflow, and not everyone on StackOverflow participates in the polls.
I can't help but see VSCode as a reincarnation of Emacs. It's written in a dynamic language on top of a native-code runtime, and you can extend it the same way it's "officially" built, right from inside it. Most interesting parts are such extensions. You can access anything internally by name, not hunting through menus.
It's also open source (though MIT, not GPL).
If not the particular implementation, but the approach finally has reached the deserved widespread popularity.
A bit of a tangent, but I think it would be worth distinguishing between vim-as-the-text-editor and vim-as-the-keybindings. For me, the value of vim comes from how quickly I can manipulate text, not necessarily that I can use a text editor in the terminal.
For bigger projects, I mostly use VSCode (and used IntelliJ in the past) but with vim bindings turned on. Because of this, I feel it's a bit difficult to compare the popularity of something like VSCode and Vim.
The Vim extension in VSCode is very clumsy for many things, not to mention the lags and the slowness (which defeats the purpose of using Vim keybindings) that's what drove me back, but I keep an eye on Onivim[0] which aims to be VSCode with Vim as a first class citizen.
What I would love to see is a JetBrains code editor which is language-independent. VSCode is nice but it's still too sluggish. Sublime Text is what I really enjoyed back in the day but a lot of core extensions / plugins are stale.
Yes, I can configure IntelliJ to work with other languages but at the end of the day it's still a Java IDE.
I tried Nova from Panic the other day but it felt similar to VSCode in terms of snappiness.
Text editing is mostly a solved problem, and arguably done better elsewhere. VS Code makes improvements on interacting with particular languages / DSLs.
Except not doing ctrl-c ctrl-v easily. Or standard keybidings. I wonder if an offshoot with standard keys in a terminal based on vi would work (really simple and native, I used simple mode alas it almost were transparent but not quite. )
> Except not doing ctrl-c ctrl-v easily. Or standard keybidings.
I used to think like that but imho when you learn Vim registers it totally makes sense, plus if you're using it in a terminal emulator you can use ctrl-shift-c ctrl-shift-v. Now about Emacs I don't have much experience, but Doom-Emacs and Spacemacs use the System's clipboard by default.
I’ve switched to VS Code from Sublime and IntelliJ. Then it become so slow on a recent MacBook Pro that I finally switched to NeoVIM for editing any file of any programming language a year ago. I’m rediscovering keyboard shortcuts and custom macros. Couldn’t be happier.
Still, VS Code was a great inspiration to me. It felt much more light-weight than IntelliJ and features were superior to Sublime.
Anyone else think it's weird they used the term "text editor" ~100x in that article but what they're actually just comparing IDEs.
It's weird to read an article comparing the most popular "text editors" of all time and not have one mention Microsoft Word... I'd expect notepad, open office docs and pages to get honerable mentions on such a list.
It's just a disparaging term for people who think that good software comes only from a full IDE. To be fair though, MS Word is a lot more than a text editor, e.g. you don't save its documents as text documents but as bundles of style/layout/text/fonts.
Funny. I've basically done the same with UltraEdit. Although, when it comes to certain languages, I prefer to use the dedicated IDE. Especially if the GUI is involved. For .net, it's straight up Visual Studio. For Java, OpenBeans. And so on. I think VS Code will serve the same niche as the text editor + compiler crowd. IDEs are way too comfy to resist.
Performance is a huge issue with vs code. I’ve been using it for a couple of years and am seriously considering going to a minimal vim setup. My editor slowing to a crawl and needed to be restarted once or twice a day on a brand new high end MBP is a constant annoyance.
And if I want to test running a swarm or several servers locally, the memory usage really does become relevant.
> In most software categories, choosing the software with longevity is easy, the most popular tools are usually the ones that have been around the longest. Microsoft Excel and Adobe Illustrator were both released in 1987 and, for the most part, they’ve remained the most popular software in their categories since then.
Hold up! I'm out here still repping Lotus 1-2-3...
Hmmm, this article seems like a very Mac centered view of text editor history.
I was using jEdit long before TextMate was a thing and it had extensions and language customizations as well. If I remember correctly, TextMate mainly became popular because of all the Rails and Django developers promoting it at the same time developers were switching to Macs.
I tried to be careful with my language to not imply things were technically the first, but to describe a lineage. E.g., Sublime Text was clearly at least partly based on TextMate (lifting some technologies, like snippets and language grammars, verbatim), and Atom was so much based on Sublime Text that it's initial design could fairly be called a knockoff.
I think that the major players that lead to VS Code are TextMate, Sublime Text, and Atom, but I'll be the first to admit there's a healthy amount of subjective judgement there. And just me drawing on things I'm familiar with (e.g., the decision to focus on BBEdit, Vim, and Emacs as the earlier examples is simply because I know those editors pretty well). One thing I don't know much about is what TextMate's influences actually are, perhaps jEdit fits into the story there? I'm not sure.
In any event, I appreciate you pointing out these features in jEdit, so far that's the earliest example of a plugin system and an integrated plugin manager that I'm aware of.
VSCode looks great and has a nice debugger but going through plugin management again is too much for me.
I’ve already invested the time and effort to setup neovim with coc as my general go-to editor and have very few complaints. If I ever need a true IDE for something I’ll just open something batteries-included like Jetbrains or Pycharm.
No where in the article or the 247 comments does Jupyter Lab merit a single mention?
It’s clearly not a full fledged IDE. Yet. But it is building towards that. Is fully open source. Has a broad and deep ecosystem behind. Born in the cloud. Just got Kite plugin for better autocomplete.
If you’re doing data science it’s a very viable contender.
With more years into writing code, I think VSCode/Vim/IntelliJ etc. are just tools to be used for problems that they are good at, depending on your background, and to maximize your productivity. It’s a very personal thing, and any single tool shouldn’t be expected to be versatile.
Maybe this is not the right place to ask, but I've tried to googled it without success. I use VSCode and Geany and code mostly Go,HTML/JS(svelte),Php and some python.
I love them both, but would like some unity between them :)
Does anyone have a theme-file for Geany that mimics VSCode's look and colors ?
I have been using Sublime since 3 months and I like how lean it is. I tried VSC but I find it heavy on resources on my i5 with 24GB of ram. Maybe it is a perception thing though. What I find interesting is that UltraEdit, an editor I love, is not even on the rankings here.
I have been a heavy sublime text user. Really love the product it’s fast and responsive compared to VSCode as vscode gets slow when handling alot of files and searching through them.
Kudos to Sublime Text Team for making awesome product with never ending trial.
One of the features I really like about VS Code is the source control, which is super simple and easy to use and understand. Especially the diff view and resolving of merge conflicts using UI. I find Intellij to be somewhat more complex in this regard.
I find it interesting there is no mention of the new Adobe Brackets here. I've been using Panic Coda for years and will be transitioning to either Panic Nova or to Brackets.
Fully open source, written in HTML and Javascript. It was released in April of 2020.
I tried using VS Code but the vim keybindings were inadequate. It doesn't do anything I can't already do without it (except frustrate my muscle memory) so it lacks any kind of value proposition for me.
As much as I like vscode. I’ve yet to find a mainstream programming language that it provides support for better than a Jetbrains based IDE. Which is really sad, because if it did, I’d switch in a heartbeat.
Quite simply I use VS Code as a notepad/quick editor. If I’m fully coding in an environment I’ll spend the extra setup on getting it into a Jetbrains IDE
Its okay for web stuff but I use Jetbrains IDEs for C++ and Go. They are way better. C++ crashes and gets into weird states all the time on VSCode for me.
Microsoft is selling you into the IDE, in small portions. This is similar to the IBM approach with JAVA last decade(s?).
You install a "text editor" for simple things, like code completion. Before you realize you don't even know which compiler you are using or where it came from. You just press F5 and look at convenient break points. And somehow it only runs right on Azure :) the last one is a joke (for now?)
As a language popularity grows, it approaches the Java curve. Just like nobody who uses `npm` like (or know) maven, nobody using VS Code know about the old java IDEs, and how they become todays Java IDEs. Or how the React monolith is the same as the Java Monolith.
I guess people mixing up java and javascript in the 90s... just thad more, long term vision?
You're right - it is a trojan horse and people are eating up the 'MS heart Open Source' PR. It's obvious when you look at what they're doing with language servers.
They've replaced the open source Python language server with a closed source one. The C/C++ was always closed. Their remote feature and collaboration tools are also closed. They're slowly making people depend on MS services without even realising it.
They want you to run your development environment on Azure and are making it possible piece by piece, turning your IDE into a thin client. And they're open about that aim but still call VS Code "open source". It is not - it has open source components and lots of telemetry so MS can develop those services. If people are happy with that, so be it but the 'love' they get is undeserved.
> They've replaced the open source Python language server with a closed source one. The C/C++ was always closed. Their remote feature and collaboration tools are also closed. They're slowly making people depend on MS services without even realising it.
So, what you're saying is that the absolutely enormous number of Python and C/C++ people can't produce a decent open-source plugin while tiny communities like the Rust folks can?
I don't like what Microsoft is doing here, but, let's be honest, the "open source community" has also spoken and what it has said is "We are a bunch of cheap, selfish jerks."
You don't have to fund very many programmers to create these plugins. Full-time funding for maybe 5 or 6 programmers per plugin can pull it off (and maybe not that for something like the remote development plugin). And not all programmers around the world cost $200K per year. However, even if they did, that's $1 million per year to support a plugin.
So, no company or individual out of the entire Python or C/C++ ecosystem thinks that's a worthwhile expense? No group of 5 or 6 companies think that's a worthwhile expense?
As we found with OpenSSL and other open source projects, no, apparently they don't.
Don't bemoan Microsoft's licensing when the problem sits with the "open source community" being cheap bastards.
Open-source C/C++ LSP server exists, clangd exists and ccls(https://github.com/MaskRay/ccls) is build on libclang which works very well for a few of my projects. I am not sure about python since i don't use it much.
> And they're open about that aim but still call VS Code "open source".
Yeah, it's a principle worth remembering: "open source" doesn't mean anything if most of the software only runs on someone else's cloud without you having any control or visibility into it.
I'm legit confused on what you're trying to say. Are you saying tech stacks are a bad thing? Or that corporate investment or connection to a tech stack is a bad thing? What's your proposed solution or alternative?
One thing I _think_ you're saying that I do find important:
It's crucial to have experience in more than one ecosystem and tech stack, as you learn a lot from seeing communities reinvent the wheel and not learn from one another. You get to see common patterns in software development and engineering and, sometimes, you find novel approaches that are completely alien to the engineering ecosystem you started out in.
I am saying opaque, closed and proprietary tech stacks are the danger. See the other reply for a better discussion on what is happening. Basically Microsoft* is very well known for taking open source projects, extending them a little in a nice package, and then silently moving all the code to a proprietary closed solution that later on only works on windows or their platforms.
\* microsoft is well known for it, but Google does it a lot too.
Which IDE? If you mean Visual Studio, that's a Windows only product and it's really only good for Windows specific development like C# and MSVC. If you do C# or C++ development on Windows or XBox then you're likely already using Visual Studio and the community edition is a free product for individual use or open source products.
If you mean some future IDE that MS is working on that they plan to evolve VS Code into, I don't see MS trying to sell macOS or Linux users a proprietary dev environment or toolchain. It's certainly possible but your post doesn't provide any justification for that position.
Obviously lots of C# development is still on Windows, but let’s not act like it’s 2003. I work on C# all day everyday and most of what I write runs on Linux.
Visual Studio for Mac is nowhere near as good as on Windows. I can't speak for how it is on Linux. I'm glad it exists, but I've found it a pain to use.
Sure, just like Visual Studio Code exists for macOS and Linux. My specific argument was Microsoft is unlikely to release a proprietary IDE for macOS or Linux. Visual Studio for macOS is free and Microsoft open sourced Xamarin and Monodevelop [1] when they acquired it back in 2016.
Indeed, Microsoft Edge for Linux too is a trojan horse. Windows needs to gain leverage against open development platforms. They they need to reach other ecosystems (fedora, centos, mac os). Just like Google when you use their technologies you bet the app is talking to the mothership.
You're right; my years of experience with Java, Maven, Netbeans, Eclipse (eugh...), and IntelliJ completely evaporated when I did 'npm init' on my current (Node and React) project, which I'm working on in VS Code.
A jumped to Atom and hated it and returned to Sublime. I have used VS Code, but never made the full jump because Atom set a precedent for Electron editors.
I switched from Atom to VS Code after a long time as I always disliked the way VS Code looks but at some point you have to admit that Atom is abandonware (Microsoft isn't going to develop two text editors) and VS Code is way more lightweight than Atom ever ways.
As far as I know, there are no serious email clients for Visual Studio Code. So the kind of obsessive users, the ones that want to do everything with it, the presence of which indicates a really good piece of software, don't use Visual Studio Code. I consider that a fatal indictment of Visual Studio Code.
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." -- https://en.wikiquote.org/wiki/Jamie_Zawinski
No, Emacs is notorious for having many email clients, and many users enthusiastically read and send email through Emacs. Likewise, there are email clients for vim, though I presume they're relatively less popular.
I hate visual studio programs. They are always so slow, buggy, and when they crash, the program vanishes from the task manger but is still are running from the background, so you cannot kill it easily. Visual Studio is a crutch for real coding.
To be honest, when I first heard my colleague say they were using "visual studio code" to develop their Python apps I thought they were repurposing some Microsoft vb.net IDE and hacking it to mesh with Python
The same team that does a bulk of the "python" language service dev for VS Code did the main plugin for python development in Visual Studio. It was actually pretty good.
My first couple of years writing software I used Vim, then VSCode, then worked in a Java shop and was forced to use IntelliJ. I didn't like it at first, but now after a couple of years I cannot see how I lived without it.
The idea that VSCode is the future doesn't seem right to me. JetBrains products allow you to do so much out of the box, without installing a million plugins that may or may not work. In IntelliJ I can write a half baked statement like `new Foo()`, and then Alt + Enter my way to it being `foo = new Foo();` as a private member variable of the class in no time. If you take time to set up configuration it becomes even more powerful. Even these basics are more difficult in VSCode.
To me the future is IntelliJ for Java and all other languages should seek to have such a nicely integrated experience with an IDE.
I am not even sure I could write Java from scratch in Vim - its really that I'm using IntelliJ, not writing Java. Is this bad? In some pure sense, sure, you are further from the language. But I don't care because I can write and edit code some multiple faster than if I was in VSCode.