I have used CLion, and would say JetBrains did an excellent job with making a C IDE. The issue is that C is not much of an "IDE language"; my experience has always been to just use a text editor (vim or vscode), and it seems to be the same for most C devs I know. Looking at newer languages, they seem to pair closely with IDEs; I'm still not a big IDE guy, but most use them for python, java, etc. I'm not enough of an expert to quantify the reasons behind this, but I think it's hard to build a stand-out good IDE for a language with which IDEs often aren't used or are just used as glorified text editors.

> The issue is that C is not much of an "IDE language"

This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling.

Compare to Java (set the classpath to exactly the artifacts you want and IntelliJ uses its own build system unless you explicitly tell it otherwise), Python (set up a virtualenv with exactly what you want and PyCharm handles its own builds, insofar as Python builds).

In C on Windows and Unix you have to figure out how to find and address includes and libraries in a cross platform way. CMake is probably the best bet. If they were in the position of, say, TurboC back in DOS days where they provided stdlib and you added everything else you wanted, they could do as good a job as for Java.

> This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling.

Exactly. #include "header.h". But where is it? Depends on compiler flags. Java has the same problem, but luckily has only ~2 build systems that are well-supported by IDEs.

Java doesn't really have the same problem. It has the classpath, and that's it, across all platforms. Nor do the big IDEs use ant, maven, or gradle as their internal build system, though most of them support controlling them.

If you haven't tried it recently, I'd give it another try. They've had significant speed improvements with 2019.3, whereas 2019.2 was very slow

Yeah, there was some improvement. But the issue for me is building a C++ app which requires Linux headers, Boost headers, and Wt, CLion seems to wants to take four cpu's for a hot trip. Even with a bunch of the code helpers turned off.

VSCode with CMake, clangd, and C++ code filter seems to work for the little I've used it so far.

Havn't quite taken the leap of faith in VIM, clangd to see if that is suitable.

One thing I've found with CLion is that you really, really want to edit the JVM settings for the IDE. By default it starts with a 2GB memory limit for the JVM, which even for small projects will severely drag down performance, e.g. my MBP would run very hot, spin the fans and the IDE would get very laggy. Increasing the JVM settings to allocate 8GB completely solved this.

An editor that needs (even) 2GB to be blindingly fast is a failure.

It's not the editor part that uses all this RAM I suppose, but the code parser and indexer that by default includes scanning & interpreting all your dependencies (system headers, boost, other third-party frameworks). There is a clang process that has the full AST for all of your code + its dependencies in the background all the time, so you can get search, index, autocomplete, syntax check, refactor etc. that actually works compared to the half-baked solutions you get with VIM plugins (and I've tried all of them).

I guess you can switch all of that off of course, but that's what makes it an IDE and not an editor. I think the memory tradeoff is perfectly fine for this kind of application.

At the moment I am sitting here adding couple of things to a huge desktop application written in Delphi. More then a million lines for a full build (which takes 11 seconds on laptop btw). It does all that you mention with all bells and whistles of a modern IDE and consuming whopping 380MB. How's that for a change?

Apples and oranges, Delphi != C++, and on top of that I don't think you really want to make the argument that the Delphi IDE can do all the things CLion can do for C++. I fondly remember my time writing Delphi, but I'm not jaded enough about the resource requirements of modern IDE's to pretend that you can compare these environments equally.

Anyway, I don't really see the point you trying to argue here. It appears you are principally opposed to software that uses more resources than what you consider necessary, which is fine and in the case of something like CLion or VS code justified to some extent, because they are far from lightweight. But if you remove these ideological objections from the discussion, none of this actually matters all that much considering typical workstation hardware. I honestly don't mind trading 4 or 8 of the 16 GB of RAM in my laptop for all the features I get from CLion compared to the alternatives. A full compile and run of the thing I'm building can easily get by with (much) less than 2 GB. And if I would be developing something that uses up 8+ GB by itself, I probably want a beefier workstation with 32 GB or more anyway. It's just not an issue, RAM is plentiful, and it's in there to be used.

All my laptops have 32GB of RAM. And if I had no other options I probably could've been stuck with CLion. However as I've already mention CodeLite and QtCreator are multiplatform, very responsive, work just fine as an IDE and eat very little memory comparatively to CLion. I often have to test big in memory datasets so I have way better ways of wasting RAM.

That's fine, because it's an IDE and a new dev machine tends to have more than 16gb of ram.

No it is not fine. The only impression I get from glorified notepads consuming gigabytes of RAM is the ever increasing desire to send them to /dev/null where they belong. My opinion of course

Some machines, and some people, have other uses for RAM than the text editor.

Sorry but I have other uses for RAM then to feed sloppy environments.

There is absolutely no excuse for any editing product to be perceptibly slow.

A single ordinary, commodity CPU core can sort 100M of totally random ints in 5 seconds. The amount of work any editor legitimately needs to do to provide you editing support is trivial, in comparison, by any measure.