Last week we held an AMA session on Reddit. 7 of our team members (and a few more who helped behind the scenes) answered about 35 questions and participated in discussions spread over 118 comments in the threads under the post. After the session, we looked back at the questions to identify the areas where participants showed the most interest. Here’s what we found.
6 questions about project models
After introducing Makefile projects support in v2020.2 and enhancing it significantly in v2020.3, we are now mostly getting questions about Bazel and, surprisingly, Meson.
For Bazel, the Bazel plugin is available. It is a complicated plugin that is written and maintained by Google. It’s fairly feature-rich, not just for C/C++ but for other IDEs and languages as well, but it lags behind CLion when it comes to supporting new versions. We’re still trying to find a sweet spot between evolving CLion’s project model support (which we definitely need to do) and not breaking it constantly.
We’ve been keeping an eye on Meson, and we’re noticing more requests coming in lately. The YouTrack ticket for Meson is very popular, though we’re getting fewer requests through other channels, which could also be seen in the results of our Dev Ecosystem Survey 2020 (the "Other" Build System category collected only 4% of responses).
At the moment, we don’t have a specific ETA for the introduction of Meson support, and it definitely won’t appear in 2021.1. Nevertheless, we consider it an important area with a growing priority. If you’d like to work with Meson in CLion 2020.3, there’s a workaround based on Compilation Database support + Custom Build Targets.
6 questions about performance
A few AMA participants complained about CLion’s performance and suggested that we migrate its source code to C++.
The IDE’s performance has always been one of our team’s top priorities, and it’s come a long way since 2015. We’re noticing improvements both judging from user feedback and based on the statistics we collect.
The biggest performance issues have to do with the code structure and the C/C++ features that are used in a project. In general, however, thousands of source files should be handled OK. If you’re experiencing performance issues, please consult our Performance-Tuning Guide, and if that doesn’t help, please contact us for assistance.
One of the questions we received was about the GC pauses in CLion. However, GC pauses are not always the culprit when there are problems. The way most of CLion’s caches work is they trade RAM for speed. So, when memory runs low, the GC does not just collect garbage. It collects some of the caches as well, and these might have to be rebuilt immediately after, which is what causes the performance issues.
The IDE source code targeting the JVM doesn’t contribute very much to the performance problems. (The only exception is that it’s easier to trade RAM for speed in Java than it is in C++.) The real root of the problem is the combination of CLion’s ambitious feature set with the way some things are implemented in the IntelliJ Platform on which we build the product, plus some specific issues.
In general, using the JVM (or any other managed platform) for an IDE, which includes a great mixture of things like plugins, including third-party ones, seems like the correct choice to us. Still, we’re working to adjust the architecture where needed, such as by introducing the out-of-process clangd daemon and some other modifications.
Questions about CUDA and specific (embedded) compilers
CLion is evolving as an IDE for embedded development, so we expected you to ask us questions on this topic. Requests for various currently unsupported compilers were some of the most interesting ones. For now, we’re planning a workaround based on offering support for custom compilers (CPP-9615). Once this is implemented, you will be able to write a description file with the necessary compiler information and then use literally any compiler, regardless of the vendor.
We didn’t get as many questions about the debugger integrations in CLion as we expected. Maybe that’s because the latest release covered this area well. In this session, you asked us only two debugger-related questions and both were about cross-language debugging – C++/Python and C++/Java. Both of these combinations interest us; we even created an internal prototype for C++/Python several years ago. However, both cases require the language and the project model to be integrated first, which we might work on in the future.
In 2020 it’s not surprising to see a growing interest in remote development workflows. Quite a few discussions on Reddit touched on the different sides of this.
We’d like to highlight one question: “Do you have a plan to support remote work on another server via SSH like VS Code?”
This is being actively worked on for all IntelliJ-based products, but we cannot share any specific plans or ETAs for now. Please follow the IDEA-226455 ticket for updates.
What we already offer is Code With Me, a new IDE tool for collaborative development. With Code With Me, one IDE can potentially be used as a server-side engine and another one as a client.
And other questions
There were many other questions about a variety of topics, from a Rust IDE to a Conan plugin, and even Rider for Unreal Engine. We also received a question about the compiler options on Windows, which we had addressed recently with a blog post on how to use LLVM Clang with MinGW on Windows.
You asked about our processes and our relationship with the IntelliJ Platform team. We definitely enjoyed the question of the Universe: what’s one plus one? As Phil Nash said, “That depends on what definitions of
one are in scope, or in the same namespace as the
+ operator – as well as how / whether the
+ operator is overloaded.”
We hope you enjoyed the AMA session. Please let us know in the comments if you’d like us to repeat it sometime in the future. And remember, you don’t have to wait for an AMA to ask us a question! You can always get in touch with us on Twitter, via a support ticket, or in our issue tracker.
Your CLion Team
The Drive to Develop