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