CLion is an amazing tool -- I've purchased licenses for my personal self in the past, but my employer pays for it these days.
My problem is they've done a terrible job of making it scale up to large code bases. I work on the chromium tree -- CLion is completely useless on it. I have a dual 24-core xeon with 128GB of RAM and SSD and I've given it a wackload of memory, and it becomes completely inoperable, freezing all over the place.
Awful because I have such muscle memory for the JetBrains tools, and such a fondness for them.
I've gone back to using Emacs, but now with Eclim. I just couldn't get into VSCode.
On a multi-artifacts maven JavaEE project (not submodules, just a lot of independent modules), it has serious difficulties. Support for Java12+ is far better than Eclipse, but working on IntelliJ and using auto-formatting tools (Checkstyle and Save-Actions) makes it suffer enormously. I've never had those problems on Eclipse.
I had to assign over 4GB RAM to handle more files (by default it is set to 2GB max)
Interesting. Chromium seems to be huge indeed. I googled statistics: 3+ million lines of code? Is that about right? (Not that LOC is a great universal metric of everything, but it's something.)
I'm curious, have the VM garbage collection and allocation settings been adjusted? In other words, not just the memory limits but also switching to a different garbage collector and the GC control mechanisms adjusted? I've been reading up on the collectors. As far as I can tell the G1 collector is strongly indicated when you go above a 4 or 8GB heap. It then has a number of settings to adjust. I got really good and smooth performance out of it - few and short enough pauses that I was at peace with CLion - but seemingly I set the garbage collection to be "too continuous" which caused constant CPU usage when I used that profile in Pycharm on a Python project. Had to switch Pycharm back to a more, uh, classical GC setup. (I didn't reconfigure to rein it back in as it was unnecessary in that context. I'm sure it's possible.) The JVM and the GC are a rather interesting beast.
Yes it's a massive project. I've attempted all sorts of GC tuning. I'm not convinced it's all GC issues; I think whatever data structures or algorithms they are using for their semantic tree must not scale well to extremely large data sets. It also doesn't seem to be terribly friendly to high concurrency. Having lots of cores doesn't really help.
CLion seems to struggle in particular with the presence of the out / generated source directories in Chromium. Even when asked not to index (exclude), the mere presence of the directory seems to bog it down.
The tool also needs to have a more flexible notion of source roots/include roots. I should be able to notify it that a directory is an #include root without having it try to index every .c file etc. underneath there. I should be able to select a group of directories and say "these have headers, but they're relative to path X, rather than themselves" etc.
Is this even including all the stuff that gets pulled in as a 3rd party dep? Some significant portions of the code live there such as angle, blink etc.
You may want to give the CLion 2019.3 EAP build a try. I was having the same issues as you with a very large (~1 million SLOC) C++ code base. To my surprise, the EAP build has seemingly removed almost all hesitation/hanging. They did rename the keymaps for some odd reason, which I worked around by extracting from a previous version's resources.jar file and placing in my preferences directory.
I have been using it. No real improvement. Freezes all over. And I gave the GC something like 20gb.
It's even worse when adding in our internal repositories on top.
Also having a back and forth on a ticket about their support for compiler_commands.json; the one generated by ninja for Chromium simply doesn't work for me. Their person says it works for them, though. I don't know how. Right now I manually create a CMakeLists.txt with the directories I need.
But one thing that is discouraging about CLion is that even directories that you explicitly tell it not to index as source seem to still be looked at and indexed in some fashion, so a huge number of files just drags it down to a halt. My coworker was able to get decent performance by creating an empty directory and symlinking in only the directories he is working on. Simply having directories with large quantities of files is enough to drag it down.
It's very disappointing, as its my tool of choice. I feel handicapped without it.
It's slow and freezes even on tiny projects.
They're aware of the issue and apparently the next release will be focused entirely on trying to address those.
At the moment that's my number one issue with CLion.
I had similar issues when I included the standard library with templated data structures and googletest. The IDE would consume my entire MacBook Pro 2016. The UI froze, input would be delayed on the orders of 10s of seconds, and I can go on...
I really really hope they can fix this because at my work I'm trying to get CLion working. The Codebase is quite large and I have to turn inspections off or else input freezes and won't be responsive for up to 30 seconds. It's at times unusable.
When it works it's amazing but it still has some ways to go.
This statement is false. It's way too broad a claim to hold up. With all due respect I'd consider it harmfully incorrect.
Counterexample: I use CLion to work on Cataclysm: Dark Days Ahead. It's ~360,000 lines of pretty hairy C++. It's fine.
There may be conditions that make a stricter definition of the claim true. I don't know what those conditions would be. A link to Jetbrains' definition of the issue would be good.
I don't think I'm making an extraordinary statement.
If you look in their bug tracker, there are 500+ tickets with the term "freeze" in it.
The reason is actually known: being a Java IDE, the design takes for granted that many operations that are almost instant in the Java world can takes many seconds in the C++ world (meaning they'd need to put that in the background instead of blocking the GUI).
Obviously there are (many) reasons for that. What you think is hairy might not be that hairy, in terms of parsing, to a compiler or static analyzer. If you're like most game developers, you use a simple subset of C++ that's C-like, which might explain why you're lucky.
Maybe the word 'tiny' was excessive. It might not affect someone's homework, but in my case it definitely does have performance issues for my relatively small one-man projects. I'm not bashing the tool; I'm a paying user too. But no one can deny the many performance issues, and indeed the focus of the next major release is precisely to start addressing those.
The thing is that I've been using IntelliJ since version 3something, 15 years ago or so. It's _always_ had freezing problems. Over the years they made incremental progress on the Java front such that it became less common; or else workstations just caught up with the software. Or both.
I also used AppCode extensively, that one actually behaved pretty well, overall.
So I am not really surprised by CLion's performance/stability issues. I have a long love/hate type thing around this with Jetbrains.
I hope they can get these things sorted out.
I often wonder if they wouldn't be better rewriting in a non-GC'd language. Rust or something.
My statement was inadvertently aggressive. I was attempting to be clear and logical but came out wrong. I am sorry :)
It's a question of for-all-x vs. there-exists-x. I acknowledge that there exist x'es that are small projects that make CLion hang.
I just wanted to make sure it was known that it's not all x'es. And that there exist y's that are large projects that don't hang. Cataclysm DDA is not a simple codebase :)
I've run into this issue, also. It's not Visual Studio levels of constant freezing, but it definitely pauses once in a while. Seems to mostly occur when I'm developing on Windows, though.
EDIT: Wanted to add that it's definitely a regression. I've been using CLion without the pauses for years.
I use Emacs + Eclim. Other coworkers use Vim + you complete me. Or just raw vim, because they're far more patient than me. Others us VSCode + clangd, etc.
You can generate a compiler_commands.json from ninja for these tools. I don't have the command handy -- but you can google for it.
They all perform quite admirably when compared to CLion, unfortunately.
I had to use Qt as the UI lib for a project, it made me discover that QtCreator was actually not a Qt-only tool but a very good lightweight and generic C++ IDE.
That's my choice now. I need something that can navigate easily in a code base, I don't really like learning all the oddities around emacs and vim (even though I am a bit competent at vim) and I don't see what is so bad in using a mouse.
At first I thought annoying to have to manually edit the .includes and .config to add the includes and the macro I needed in our complex, hard-to-parse CMake based project, but now I really enjoy the freedom it gives.
The worst thing about C++ is the endless sequences of choices you need to make about tooling before you even write a line of code. This is actually what made me switch to Go for personal projects - I'm a professional C++ programmer, but setting up a development environment required so many choices and so much futzing with various tools that I would spend all my energy getting set up and never make progress on the projects themselves.
Go, Rust, and even Java are all way better in this department - the tools are standard enough that you only have to make a choice if you are doing something less common. I would love a Dropwizard-like bundle that just gives me a pre-set-up config with everything I need to write a C++ CLI app or daemon.
If you standardize on CMake, lots of up-front choices go away, and will be converted to options which can be changed on per-developer basis. CMake can generate the whole project part for lots of different developers, allowing the devs to use practically any IDE they wish.
Plus, you'll get a properly configured project with automatic dependency tracking.
I don't understand why CMake isn't used by default. (or Meson)
> The worst thing about C++ is the endless sequences of choices you need to make about tooling before you even write a line of code.
I don't know about endless. CMake is supported in almost every IDE toolchain these days, so there's your build generator. Compiler choice may as well be down to the platform you're developing on.
> I'm a professional C++ programmer, but setting up a development environment required so many choices
Me too, and it's about as complicated as Java or any other language I've worked in.
> I would love a Dropwizard-like bundle that just gives me a pre-set-up config with everything I need to write a C++ CLI app or daemon.
Visual Studio, CLion, QtCreator all do this. They'll even add your main.cpp to your CMakeLists.txt for you.
Now, if we're talking dependency management on Windows, I'm all about griping there. vcpkg is not quite the drop-in solution Microsoft makes it out to be.
Rust does support binary libraries. You just have to interoperate with them via the system/C ABI. It doesn't support binary crates, but a crate is just a compilation unit, like a file in C/C++. Do people commonly use binary .o files in C/C++ across compiler versions? That would be the equivalent of what you call "binary libraries".
Right. I would say that any large C++ project, especially one with multiple binary targets, will naturally split the code base in dynamic or static libraries.
Ive spent a good part of my 20+ year career wrangling c++ dependencies, and it's hard. MS has introduced vcpkg, which should make things better, closer to a pip or npm style package manner, but I haven't used it, so I have no idea how well it works.
Yep, I think this is my main gripe with C++ on Windows right now. vcpkg is meant to work with CMake or Visual Studio, but you still have to manually tell it where your toolchain file is - which means it's additional work for the rest of your team. In Visual Studio, it's seamless.
On Windows, it's gotten to the point where I try to build dependencies as part of the build chain and hope the tooling is smart enough to not rebuild them a million times. Would be really nice if Windows 10X (or whatever) could come with a package manager or integrate vcpkg.
Agreed that Java tooling is amazing. The only reason I said "even Java" here was the fact that you have to choose a build system from a handful of fairly popular options, which adds some up-front cognitive overhead to your project vs. Go or Rust.
As a cross-platform C++ Builder replacement, I have been using wxFormBuilder and wxWidgets in the past. There are some manual steps, but it let's you build a GUI quickly, hook up event handlers and then write implementation code in a derived class, so that stuff generated by GUI editor doesn't rewrite your code.
QWidgets are stuck in desktop deployment scenarios, with QML taking front row for everthing else, something that they plan to change with Qt 6, which remains to be seen in what form it will be done.
Qwt is not the same as the commercial support from component oriented companies, including the UI/UX care of some components.
wxWidgets is worth looking at. I use it and really enjoy using it. Used it for a largish cross-platform job a few years ago which is why I think all the modern garbage like Slack and Electron-based apps is sheer laziness.
The forum can be a bit quiet sometimes but you'll likely get a response. Bug reports and stackoverflow questions also might get some help.
Much preferrable to me than the MFC stuff I had to use at work for years. wxWidgets is actually nice to use and can have bind/connect instead of macros for event handling, as well as CallAfter(...) for easy firing of events from background threads etc.
wxFormBuilder and wxWidgets is indeed "Dialog Resource Editor and MFC" wannabe, though more cross platform, with a nicer API and with more features. Also wxWidgets is actually what people think MFC was (a layer on top of Win32/native API) instead of what it really was (a C++ extension utility of Win32 that did not try to hide Win32 API).
wxFormBuilder is nicer than Qt Designer but they are both essentially based on the same core idea of designing a dialog visually and then wiring everything by hand (code).
In another comment above i go into more details, but i guess you already know most of that :-P.
No. Qt and C++ Builder are very different. Qt with Qt Designer is much closer to wxWidgets with wxFormBuilder than C++ Builder, but from my experience so far (i am working with Qt+Qt Designer at day job and worked with wxWidgets and wxFormBuilder at previous job) Qt Designer feels like an alpha product at best when compared to wxFormBuilder.
It is interesting that Qt as an API feels more polished, but the designer is barebones whereas wxWidgets as an API is a bit more clunky but the designer is much more polished (wxFormBuilder is the most common one, though there is also wxSmith which is a commercial designer that is supposedly better - though i never used it myself). In comparison at least, wxFormBuilder does have its own warts.
Though you use both in essentially the same way you'd use MFC with Dialog Resource Editor in Windows 3.0 - just with a bit more features and an easier API. But the core ideas behind the workflow remains the same.
In C++ Builder, even the original version from 1996, is much easier to work with because you design the UI and assign the handlers in a visual way. You are also working with live objects instead of stand-ins (when you create a control or other -nonvisual- component, you compile it into a DLL and the IDE loads and creates an instance of that DLL that you are editing through the rich RTTI it has - this relies on extensions to Delphi/C#-like C++ language). Your form is serialized as a resource inside the executable and deserialized when it is instantiated.
The IDE uses RTTI (remember that this is richer than C++'s regular RTTI) to manipulate the objects, create event handlers (just double click a button or click on a menu and the IDE will create the methods for you - update the header file, write the method body, associate the handler with the event, etc). When you drop a component in a form, it will automatically add any necessary header file #include's at your code (later versions of C++ Builder will also automatically add any necessary includes if you use any function the IDE knows of - like a stdlib function or a function from another file).
In general the IDE will do most of the work for you, you focus on the "meat" of your applications and any busywork/pumbling/boilerplate is handled by the IDE.
I have heard that QtCreator does provide something similar, but from the very little i've used it, it looks that these "whispers" come from people who haven't really used (or understood) C++ Builder as it feels more like how Visual Studio integrated the Resource Editor that back in the day used to be a standalone application inside its UI but still acts as if it was a separate application, than a really interwoven integration like VCL (C++ Builder/Delphi's framework) and C++ Builder have. But truth be told, i have used QtCreator very little to judge properly - i'll need to do a more in-depth experiment (though again, i never had to do that with C++ Builder or Delphi).
(as a sidenote, in general i have a bias against anyone that only focuses on the form designer aspect of C++ Builder/Delphi when comparing it to some other supposedly similar tool as the form builder is only the tip of the iceberg that only works as well because of the rest of the iceberg beneath it)
Now if modern C++ Builder wasn't such an overpriced DRM-infested PITA it'd be nice. Though like with Delphi, if $whoeverownsittoday decided to release a cheap (similar to their mid-90s prices) DRM-free version (especially on a box, though i'm ok with an installer or ISO i can keep on my own media) i'd (most likely) buy it instantly.
Though their community editions are free (but with a bad license that says you can use it only if you make up $5k annually and still needs activation that can go away at any time they feel like) so if you just want to play around they're fine.
These days most people moved on from Valgrind to ASan and other sanitizers, which provide much of the same functionality with lower performance penalty.
Valgrind's memcheck is still useful: it doesn't require recompiling, can handle external (binary-only) libraries, handles inline asm or jitted code, and provides uninitialized memory read instrumentation (yes, memsan does this, but it's tricky to set up). For me personally, I've required memcheck for applications using CUDA because CUDA and sanitizers don't play well together (for example, see https://github.com/google/sanitizers/issues/629). but indeed, the sanitizers are soooo much faster :)
Sanitizers are not compile-time: they're runtime checks (aka dynamic analysis). For some strengths of valgrind compared to sanitizers, see my other comment in this thread.
I love valgrind, but it falls on its face if you're dealing with more realtime aspects. In particular, dealing with high frequency trading systems. Valgrind, in of itself can through timings off in of itself to be unusable in some contexts.
Do people use Valgrind much in C++? I've never had to. I feel like the only time I'd need it is if I'm writing "C++" code that is really just glorified C.
Due to the memory unsafety of C++, memory debuggers are absolutely used, including valgrind's memcheck and the Google sanitizers. Memory leaks and double frees are easier to avoid in C++ than C even without tooling, but use-after-free (for example) is absolutely a problem. And "modern" C++ won't necessarily help you here: even heard of string_view, span, or ranges? Memory debuggers are also often used in conjunction with fuzzing to track down bugs that the compiler may not tell you about.
clangd is really good these days (clangd-9), I suggest you give it a try. It's incredibly easy to set up if your distribution packages it. I'm using it with Emacs' lsp-mode, it's great.
I'm interested in this too! I've been looking for one that can be used with arm-gcc for cross compiling on embedded platforms. What do people use in such situations?
Clang has support for cross-compiling [1] without needing separate builds for each target so you should be able to use clang-analyzer and clang-tidy whit the right -target flag for your ARM platform.
Besides that, most bugs found by static analysis are platform independent so you should be able to use any static analyzer you get your hands on as long as your code is cross-platform.
The free (Community) edition is licensed for working on open source projects, individual developers, and up to 5 users in “non-enterprises” (< 250 PCs or < $1 Million US Dollars in annual revenue.)
So covers most people, but could be a pain if you’re in a big company that otherwise doesn’t do much engineering.
I see no mention of various implementations of C/C++ standard libraries. It's like the second most important decision to make just after compiler vendor (or THE most important, whatever your priorities are)
I would say that in 99% of the cases, using the standard library of the compiler is the right decision. Also you should target multiple compilers, possibly on multiple platforms.
Does anyone know a good debugger plugin for vim? I've tried a few and found them not great. This is seriously the only thing I currently want more from vim. I keep an IDE around just for this purpose. (A debugger with support for C++ and python. Don't care if two plugins)
Personally, Ive never tried to make Vim my IDE on Linux. Just Vim as my editor, make as my "builder" and gdb as my debugger. Effectively, bash was my IDE.
I know on the older spectrum of the audience here, but that is an effective workflow for me. But, as a nearly 40 yr old, the command-line is very natural to me. I actually get irritated when I have reach for a mouse to complete an action.
I agree. Vim with ctags and gdb is a pretty performant workflow. I just turned 40. So maybe it is context. I do like vscode though. Its pretty snappy and has good keyboard shortcuts so I don't have to touch the rodent.
You know how in GDB you can see the lines you are working on? Really I just want that to have color, like I do in vim. We don't like in 1970 anymore. We have color. The other thing I want is that while editing I can add break point.
Maybe I'm too young (28), but how I read your and the parent's comment is "My workflow has been working fine, why improve it?" which sounds weird to me. There's always room for improvement.
Have you tried ConqueGDB? It lets you start the GDB from within your vim session and uses your vim buffers to show the current file. I recently started using it and didn't really get into familiarizing with it yet, but it seems to integrate the gdb quite well. I am uncertain whether or not you can set breakpoints within the code though.
IME, if you haven't already then I'd suggest biting the bullet and learning GDB. It's not as nice to step through code but far more powerful than the features typically exposed by an IDE, or at best are only exposed by GDB's command line interface anyway. Reverse debugging and scriptability (the command interface is a DSL) are the big ones. Like vim, GDB is an incredibly powerful tools that deserves the time to learn well.
I'm fine with GDB. But I would like it in vim. You know how in GDB you can get the line by line representation? Just that but with my colorschemes and so I can set breakpoints while in vim. GDB isn't an issue, it is that GDB is old, doesn't support colors, and doesn't integrate with my editor.
I assume you're using cmake? For C/C++, cquery does completion (which I got working, but honestly didn't like and turned off. There are these two plugins for cmake:
It would be fairly quick to put something in your vimrc to pop open a small split on the side, run a build command, and show an output. You could also probably pop open a terminal (new vim has the :term command) and maybe script that? If not cmake, it shouldn't be too difficult to replace cmake with something else. I've always found I can get better results from vim that more exactly what I want, but I've got to kind of want it and be willing to write some script to do it. The results are better, but there's more up-front investment.
That doesn't enable the same marking of break points and other features you typically get from IDEs. In GDB you can see multiple lines and split your screen, so I wouldn't use :term (I'll split with tmux). But other things that IDE debuggers have are like a file list (nerd tree) and display works better (off to the side). GDB technically has all these things, but it isn't formatted nicely. I use vim to be fast and efficient (and vim plugins for IDEs SUCK, plus are bloated).
Fair enough; I do like the visual breakpoint interface. Honestly, that's one thing MSVC does really well: the debugger. Just curious to see why that didn't work for you. I'm assuming it's viable to implement this, I guess no one yet has.
It looks like there is a debugger in the newest vim. A little playing around with it shows some nice features. Still not quite what I want, but better than nothing.
Alternatively, running "M-x gdb"[1] within Emacs configured with Evil[1] for Vim keybindings[2]. Running a separate program is a pain, and it won't have config from your .vimrc, but the tight integration between GDB and Emacs is really nice.
I use tui (well I just hit `<C-x>a`) but there's more I want, like color (because we aren't living in 1970!). Maybe this vi more does the other part I want, which is code exploration and allow me to select lines for break points instead of typing as much. But I'm not sure what `M-C-j` is (I'm sure this is a dumb question). Both of these things are pretty standard in modern gui debuggers. The other thing I kinda want but isn't necessary is my display variables to be in a different pane and to have a nerdtree like file structure.
Frankly a lot of times I know where I need to investigate my in my code. But it is annoying to switch to vim, find the file and line number, go back to gdb then do `b my/file/structure/is/long:1825`. That gets hectic in large projects.
edit: My current setup I used vim+zsh+tmux. So I don't mind having gdb in a new pane that isn't a vim pane, but I just want colors and some of the basic features. I don't need everything that the IDEs do, just the basics.
These days, I found the best IDE like experience coding C to be CMake generating the compile_commands.json and a handcrafted .clang-format.
Both used as input to clangd via VSCode’s vscode-clangd plug-in.
spdlog is well regarded (I use it and I like it). It's configurable enough that should be able to use it in an embedded environment; you can control the flush policy and use it in either sync or async mode. You can use method calls or macros (if you want to completely removed things like DEBUG and TRACE calls in production). You can use it as either header-only or traditional library.
+1 for Conan, my favourite feature is using the deploy generator to gather my dynamically linked libs to deploy with my binaries - so powerful, and generally breaks the coupling between the distribution (and which packages it provides) and my application.
I've tried to use Conan, but was unable to use 'openssl', because it was named 'OpenSSL'. So, then I wanted to use HarfBuzz library, but Conan was unable to find one. Later I've found out HarfBuzz exists, but it's named 'harfbuzz'.
The 'case sensitivity' bug was created in 2017, is still open. I think it's connected to a case sensitivity flag in filesystem which is used in the system. So, since 99% of Linux systems use case-sensitive fs, it's not usable on Linux.
... I use Conan in projects with dependencies on OpenSSL on Linux and I don’t have any issues. I use the Makefile generator (because our build system is plain make + Conan). The name of the package shouldn’t impact you at all, unless I’m misunderstanding what you mean?
Another example is a dependency on a package called ‘jsonformoderncpp’, which I use by ‘#include “nlohmann/blah.h”’ - the package name is arbitrary, even if you have to refer to the dependence using the package name in your build system rather than the canonical name I don’t see how that would be an issue (even with FindPackage or whatever you use in CMake)?
No mention of the only build system worth using: Bazel. Fail. No valgrind/callgrid/cachegrind either. No google-perftools. No Linux `perf`. No mention of YouCompleteMe. This is not a comprehensive list, to say the least. I use all of these tools pretty much all the time working with C++.
Microsoft Visual Studio has the best c++ debugger. You get spoiled by it. Highly recommend it. If you are a beginner start with Visual Studio; it will make lots of things easier for you. Once Microsoft ports it to Linux the competition is fucked.
MS has explicitly stated they dont intend or expect to make VS 64-bit in any near timeframe. They say they dont need to because the components that would benefit from 64 bit are already out of process and communicate to the main UI over IPC.
That said, nothing stops a 32 bit VS building/debugging a 64 bit process. I was doing this 10+ years ago.
MS doesn't support running VS at all on Linux/Mac, and probably won't ever, or for a very long time out. Use VS Code, instead. Yes, you can target Linux/Mac from Windows running VS, but VS wont run on the same OS.
The blog post is 10 years old, the reasoning was poor then and has not aged well. No mention of the performance benefits of extra registers, new instructions, security benefits, etc.
The only advantage I can see to staying 32-bit is that Windows on ARM64 only has an x86 emulator, not x86_64.
I think there’s a 0% chance of a Linux port: VS Code is the cross-platform/future dev environment for Microsoft. But I wouldn’t be surprised to hear that a 64-bit Visual Studio is coming soon to Windows.
The new instructions are generally special-purpose, Visual Studio doesn't sound like an obvious target for vectorisation. Security is meaningless - VS is not on a security boundary. The memory size cost disadvantage is real, though.
It is very nice .. but I suspect that even Microsoft have realised it has serious maintainability issues within itself, so it will probably never be ported. Expect VSCode to acquire a comparable debugging plugin instead.
i bought clion then realized it is really only for cmake-based c++ projects, yes you can bend others to kind of work but it sucks, i hope clion can work with autoconf/makefile/cmake/whatever and stay neutral to build tools soon.
still looking for some online c++11 course these days, udemy had none that looking good.
My problem is they've done a terrible job of making it scale up to large code bases. I work on the chromium tree -- CLion is completely useless on it. I have a dual 24-core xeon with 128GB of RAM and SSD and I've given it a wackload of memory, and it becomes completely inoperable, freezing all over the place.
Awful because I have such muscle memory for the JetBrains tools, and such a fondness for them.
I've gone back to using Emacs, but now with Eclim. I just couldn't get into VSCode.