Here I want to ask JB team about the future of both products. As I see from the YT issues and other forum posts that Rider is designed as GameDev IDE which includes both popular gamedev languages, C++ and C#. On the other hand, CLion team poses the product for sole C++ development. As a C++ programmer I primarily use CLion because it's able to understand CMake project which are the most used for C++ development. On the other hand there's Rider that all of a sudden become multipurpose IDE. It's able to provide way better intention actions for the code, able to parse VS .sln projects, it even better in some code assistance moments (hover over a class shows its size and alignment, CLion doesn't). Rider is capable of attaching debugger to the remote process (over ssh) while CLion can't do that. Rider even shows better inlay hints, just compare the two:
Rider shows additional information for #ifdef conditions which is useful when ifdefs are large in the file. However, Rider lacks some of CLion intention features and code assistance.
Able to connect to a SSH machine which is very useful. Unfortunately only with .Net debugger
Rider has "Reattach to process" action which is super useful, CLion doesn't (fortunately it at least lists the recent process at the top of the list next time when you spend a lot of time to open this window [unbindable to hotkey])
Rider even more aware of C++ features. TBH I didn't even know such thing as "ref-qualifier" in C++. Rider knows about C++ function attributes more than C++-only IDE (Nodiscard attribute)
Rider context actions (intentions).
CLion can only split declaration and assignment, that's it
Rider another context action (Super simple, generic, can be applied to any imperative language)
Super useless action, I don't see anyone ever needed it in their life, only Yoda notation lovers can benefit from this
"Invert if-condition" does that
Is there any person who ever used it for what it was designed for? Leave a comment, please
Parameter hint popup. Rider
Even here Rider shines because it says which overload it will pick, what return type and what are qualifiers for the particular method (Also it renders it using color scheme, visually better, however, it can be due to my settings, can't argue on that)
CLion has its own strengths, it's able to generate definitions, can expand macros in documentation menu, able to use clangd-based indexer which is million times faster than java implementation and a lot of other stuff
Why are those products so similar and so different at the same time? Why don't you consolidate both of them to have the same set of the same functionality? I'm currently owning both annual licences of CLion and Rider. I assumed to use CLion for my everyday job and Rider for my hobby Unity projects/Plain C# development but need to use different IDE for the same kind of project are driving me mad. For instance, I applied to a job that doesn't use CMake as their primary config tool, they use VS projects and .sln. Should I pick Rider over CLion and lose money for a product I don't use and lose along the way all CLion goodies I explained above? CLion team says .sln support will make CLion not crossplatform, but platform dependent. I don't agree with that. JB has tons of products that stick to non-generic features. CLion itself has platform-depend features - profiling and memcheck are solely for UNIX-like systems, Rider's C# UI development strongly relies to the VS infrastructure and API. Implementing all missing features presented in Rider should not be a big deal because you already kinda have all that implemented for another IDE and can be somehow ported to the other product.
In addition to this post, CLion still doesn't have a public API for a long time since the first release 2015
Push-to-hint for inlay hints works only in Rider for some reason