I really like developing Rust with CLion: when I'm using C libs and Rust bindings, I can debug it seamlessly and efficiently. If RustRover [1], the dedicated JetBrains IDE for Rust, doesn't support C/C++, It will be a showstopper for switching.
I'm running into this. I had a versatile setup previously where PyCharm had first-class support with the main languages I used: Python, Rust, JS, CSS, HTML, TS.
Now I'm working on a Rust + CUDA FFI project; RustRover has minimal support for the CUDA (essentially C++) code. It does syntax highlighting and comment-hotkey, but the introspection and refactoring appear inop. It would be nice if RustRover and CLion were combined.
My biggest gripe with JetBrains' lineup is the different "spins" for different languages. They should make a single IDE with plugins for many different languages to deliver a vastly superior experience to VSCode.
Multi-language code bases aren't that uncommon either. As you say mixing C and Rust is common in apps and systems level programming. Mixing JavaScript, TypeScript, Go, and other languages like Python is also pretty common in web-centric stuff.
Besides having to pay for Fleet, it isn't available as Web editor on Github and Azure, allowing one to develop server based software as in the timesharing gold days.
The plugin ecosystem from VSCode is the only reason I tolerate an Electron powered editor for specific use cases.
My annual renewal for CLion is coming up, and I need to make a decision.
These days I only do Rust dev really. I'm not clear on what their plans are for ongoing Rust support in CLion going forward now that they're rolling out RustRover. Are they going to pull it?!
You just need to install the Native Debugging Support plugin into IntelliJ. I recently switched from having all the language specific apps installed to centralizing on IntelliJ IDEA. As far as I can tell, that plugin gives you all the same debugging features as CLion and RustRover.
Yeah the rental/subscription model is what turned me away from CLion. It was cool while it was still in free-trial mode and I'd have happily paid for it as an app that doesn't require a subscription.
I really dislike it and every time my license expires I somehow end up getting screwed over. I'll be using version X, then pay for a year license, use version X for the entire year, never upgrade, and then after a year when the license expires all of the sudden I'm locked out of version X and told my "fallback" version is some version older than X. Why isn't my fallback version the latest stable version at the time I purchased the product?
The money is entirely worth it, to me. And I pay for it out of pocket rather than billing my employer for it, even. And I'll still be able to use the latest version I had at the time the sub ended.
you are not renting but paying for updates. The latest version when your subscription ends is what you are licensed for. I think it's after 1 year though.
I was a happy user of CLion + intellij-rust since its first version, I believe, advertising it to everyone. Switched to neovim + RA half a year ago and don't think I'm ever going back :)
The old plugin is deprecated, but the new plugin installs fine into CLion. The question is how long that will be the case.
Because I work at a company that is mostly C++, with some Rust. My team's project is 90% Rust, but I still need to do C++ now and then. I'd be super annoyed to lose that.
They should at least continue to offer the plugin as a paid expansion option for CLion.
Yeah, the future is a big question. Here is quote from some mail:
> As said in the announcement, RustRover is available as a plugin to IntelliJ IDEA during the preview period. However, we have yet to determine whether this will be the case once we’ve released RustRover.
This is because we’re still not certain whether users will need the plugin or whether a dedicated Rust IDE will be sufficient. Around the release time, when we make our decision.
We’ll also consider the cases when IntelliJ IDEA licenses were primarily bought for Rust development with the IntelliJ Rust plugin and which options we can suggest to our users in these cases. Please stay tuned!
Yep, I got intellij to work with python/rust/scala and it's frustrating to see it pulled out like that. Not sure why they need to sell so many IDEs that are almost identical. Would've been happy with some upcharge for a "premium" plugin but I don't want to install three IDEs like they apparently want me to.
No, this only works for a few languages supported as plugins. Most of JetBrains IDEs are separate even if built on a same core. I have all products license and still can't use a single app to access all languages.
even with the supported plug-ins it's still not the same either. intellij with python plugin has just enough differences with it that it throws off some of my coworkers who use pycharm.
That's already reality though, technically any language with WebAssembly support can be used in "both worlds".
In reality of course it's a bit more than just compiler support, you'd want easy interop with Javascript and Web APIs and a working debugger. With the Emscripten SDK and Chrome's and VSCode's WASM DWARF support it's looking pretty good now at least for C and C++ (but I assume the WASM DWARF debugging stuff also works for Rust, since it's the same compiler infrastructure underneath).
I have really tried using Rust for the web (because I truly enjoy Rust). The ergonomics just aren't there yet.
Leptos, as a popular recent example, suffers from one major issue (that most others suffer from too): the JSX stuff is opaque to Rust Analyzer. Code completion aside, you lose the ability to hover - massively crippling any hope of tracking down how to resolve a type mismatch.
Web Rust also has the impedance mismatch that Rust has for UI. There are several success stories - e.g. Cosmic Desktop, but I'm certain that there's more love than practicality involved.
I think part of the reason is that we are trying to shove in existing patterns - which originate from OOP languages - into Rust. In both semantic and ergonomic terms I have been bitten by trying to OOP in Rust when I was first learning it.
I think that there exists an (as yet unknown) solution to the UI problem. It's just going to look nothing like React (or Elm even).
True, I've used CLion for a few years to do C++ and Rust dev, and I'm currently making an effort to check if VSCode meets my workflow. I don't want to buy another IDE just to have what I already had.
I used to use CLion but it was so slow and clunky. The best C/C++ development experience I've ever had is VS Code with the clangd extension (and it's free as well).
For me both VSCode and CLion lag heavily.. whenver I tried CLion it was completely unuseable on my project https://ossia.io which is only 500kloc (and I try to try it pretty much once a year since it was in beta)
I’ve tried them all (nearly ;) ) and I always miss Visual Studio after a while. With Clang Powertools I’m the fastest with it than anything else so I’m always surprised how little love it gets on here. Maybe because fewer devs have Windows these days.
Vscode is missing showing the call hierarchy[0]. And in addition to the mediocre debugging experience compared to Intellij products, I would definitely rank it as one of the worst C++ IDEs available.
Hey, I am curious, when do I want to do that instead of relying on auto? Mostly curious, as I have been using auto in C++ (since C++11) relatively heavily.
Some teams discourage it because it makes code reviews a little harder. I worked on a team that allowed it for obvious things like iterators or std::make_unique<>.
> The fundamental rule is: use type deduction only to make the code clearer or safer, and do not use it merely to avoid the inconvenience of writing an explicit type. When judging whether the code is clearer, keep in mind that your readers are not necessarily on your team, or familiar with your project, so types that you and your reviewer experience as unnecessary clutter will very often provide useful information to others. For example, you can assume that the return type of make_unique<Foo>() is obvious, but the return type of MyWidgetFactory() probably isn't.
I would typically use auto while working on something but then have to replace many of them before creating a code review. I wish Visual Studio could do that, it clearly already knows the type.
> Some teams discourage it because it makes code reviews a little harder
Not just reviews, but anything that involves reading the code (which is frequently usage and maintenance). Swimming in a file where everything is auto is a special kind of hell. It's like having no firm ground to step on.
I used to despise auto as well but with new standards it’s just powerful. It’s better to truly understand how type deduction works, you’re gonna be a much better C++ programmer.
> It’s better to truly understand how type deduction works, you’re gonna be a much better C++ programmer.
I understand how type deduction works just fine, thank you.
Your assumption that I (or many others) have this stance based on some lack of understanding of how type deduction works is extremely wrong, and completely missing the arguments people are actually making.
I would expect most people to read code in their IDEs, where small amounts of type inference like this is fine because the IDE tells you what the type is.
I agree that if you spend a lot of time reading code in something like GitHub, not having explicit types is annoying, but seriously, who does that?
If the IDE only displays the type on hover, that’s a significant usability regression.
It also makes it harder to grep for usages of any given type. Of course IDEs could help with that too, but I don’t know any that provide that functionality.
IDEs don't always display every type in a useful way. Sometimes they just display an unhelpful alias which ends up being just as useless. Sometimes they display an incredibly verbose version with all the default template parameters written out, making it a nightmare. Sometimes they give useless results, like when you have a dependent type whose concrete type you know (imagine typename T::value_type vs. size_t). Sometimes they haven't even finished analyzing the code yet. I could go on. You should not be crippled without your IDE.
Can you compute elementary functions by hand? Why not? Why are you crippled without semiconductors? This attitude leads to never being able to use better tools. We can't leverage an IDE because then we're "crippled" when we don't have it, so we continue writing code as if it was the '70s and the best we have is ed.
Google's C++ style is not great and seems to be mostly designed so that Google engineers can maintain Google's vast legacy C++ code-base and maintain consistency.
I wouldn't use it for my project or any new project. It's out of date with how everyone else codes C++.
> the return type of MyWidgetFactory() probably isn't.
Isn't the return type of a widget factory method obviously Widget? This doesn't seem like a great example. Of course the method name could be wrong and not enforced at the language level like something between angle brackets, but idk.
My take is: if the code is type-agnostic (i.e. should remain identical when the type changes), and writing the type wouldn't help the reader, and the type itself isn't already a simple-to-write template (like T), then use auto. (For example, this is the case when you're just taking some value and passing it along, and have no reason to care about the type at all.) Otherwise, write it out.
The intent being that you should prefer to spell out the type unless it's genuinely adding a burden (such as being difficult to read, or adding an extra location to update if it ever changes) when the benefits are also negligible, because it's frequently useful information and a good sanity check.
On the other hand, spelling out types tends to make refactors unnecessarily complicated. Something that could otherwise be simple, like moving a type from one scope to another, or changing the return type of a function for a different but compatible type, can require changing arbitrarily many usages.
This refactoring business, I see it going two ways, there are probably more.
1. you refactor, you change the type declaration in one place, auto handles the boring work of replacing the characters throughout your project.
2. you refactor, you change the type definition in one place, auto will handle replacing all the instances in your project, hell, it might even compile afterwards.
I believe you are describing 1. I find that easy enough to do with 'Sed' or IDE refactoring tools.
2, is more subtle and the new behaviour could now be worthy of scrutiny throughout the project. I find it difficult then to 'Grep' or IDE search through the project for all instances reliably when auto is in use. It is much easier for me with spelled out types.
I would trade the benefit of auto in 1) for the safety of spelled out types in 2) every single time.
If you're replacing types in this manner you don't scrutinize the usages. You design (or choose) the new type such that it actually is compatible with the old type. For example std::vector and std::list can be replaced with each other, because they either have the same functions with analogous behavior, or you get compiler errors if you use any of the non-overlapping functions. What you can't do is replace an std::vector with a class whose clear() fills the container with default-constructed instances of the objects.
In other words, you concentrate your review on the original and new type, instead of the usages.
> You design (or choose) the new type such that it actually is compatible with the old type.
Yes I agree, in that case sure, but when refactoring the case can arise that a new type must no longer compatible with the old type, then auto becomes a hindrance.
std::vector and std::list have different behaviour regarding the validity of iterators after deletion (EDIT: and insertion so it seems!), to pick an example.
>the case can arise that a new type must no longer compatible with the old type
Then you make sure that whatever causes an incompatibility also causes a compilation error. You can't rely on text searches and IDEs for something like that.
>std::vector and std::list have different behaviour regarding the validity of iterators after deletion
Fair enough, perhaps not the best-chosen example. I was thinking about them purely as collections, rather than as part of resource management. Checking their behavior with automated tools becomes much more difficult once people start taking pointers into elements. But then again, that's true of any class. If, for example, a member function returns a reference to a member and someone gets its address, now that location is implicitly relying on the internal stability of the class in a way that's invisible to the type system.
I think the example is perfectly apt, and I would not know where to start wrapping a std::list/std::vector implementation to pick up on runtime iterator invalidation.
Since I was trying to give an example of two compatible classes, no, it's not apt, since their member functions have incompatible side effects.
Hm... Hypothetically, with a lot of effort you could design a dummy class (A) that implements only the members you want to investigate and where necessary returns a different dummy class (B) representing the element type. If someone ever tries to take the address of a B (you have to delete operator&() and/or get() if it's some kind of smart pointer) then you know you might be dealing with iterator invalidation.
Ah, well I guess I did take it as an example of something that was incompatible. It served well enough as a vehicle to drive the conversation forwards.
The iterator invalidation occurs when push_back(), insert() or erase() are called, presumably among others, so you'd also want to overload the iterator increment and decrement operators too (oh!, not to forget end(), or rend() if you are going the other way...). I'm not sure what operators and methods would be called on passing to an std::algorithm like std::find or std::sort. Most likely the only way to find out for certain would be to make everything inaccessible and replace piecemeal until the compiler was happy to run to completion.
I'd want to take a closer look where it's instantiated, but if all the uses are 'auto', well let's just say I'd be unhappy to say the least.
When you can use auto without hampering readability, and while improving maintainability, by all means do so. This is often the case when the actual type doesn't matter to the reader, for example. I basically said this in my earlier comment.
But that's second priority to readability, because people read code much more often than they refactor it, and they need to be able to easily anchor their understanding when reading. Optimizing code for efficiency of editing instead of the ability to understand it is getting the priorities very wrong.
Sure, but like I said in a sibling comment, I don't believe that knowing the types of the objects is actually helpful in understanding a piece of code. You'll need to know the actual types to know its exact performance characteristics, but if you can't understand what the code does even at a high level when you can't see any types then there's a problem anyway.
> but if you can't understand what the code does even at a high level when you can't see any types then there's a problem anyway.
Who says this implies you can't understand what the code does at a high level? Often you know the high level behavior but need to figure out how it works so you can update the code. If anything, the high level behavior is often easier to understand, since you have the API documentation etc. available.
And in the cases where that is the case, what does "there's a problem anyway" mean? That the reader is too stupid to figure it out?
Sometimes, but not necessarily. Even when that's the case (and nobody always gets all the names perfect in the first iteration), you still face the problem of understanding it before you can fix that, so throwing your hands up is not a solution.
I recently learned that Godot forbids auto in its core C++ codebase, their rationale was based on code review:
> Keep in mind hover documentation often isn't readily available for pull request reviewers. Most of the time, reviewers will use GitHub's online viewer to review pull requests.
`using` directives and typedefs are not forbidden, so this would avoid situations where a type is never explicitly declared.
Having worked in large code bases that used `auto` almost exclusively when possible… I’m not sure I agree. However, I understand.
Naming issues aside, the type of t shouldn't matter, in the same way that the type of a.b() doesn't matter. What matters is how t relates to the code around it. What's the purpose of t in the context where it's used? What does it store? If you don't know whether t is an iterator over a sequence, the timestamp of an event, or the measurement of a sensor, knowing whether t is an int or a string won't help you much. If you do know that, knowing the specific type of t will probably not provide much more additional information, since in any given codebase for almost all non-primitive types there's at most two different types with comparable purpose.
It generally tends to be in the case in large projects that having the type of every variable identified is useful. Projects that follow this rule generally restrict the use of auto to a) cases where it's necessary (lambdas), b) cases where the type is obvious but spelling it properly is annoying or difficult (e.g., x.begin()--it's an iterator, everyone should understand that, but what is the actual name of that iterator class?), and c) cases where the type is repeated (e.g., if (auto *SI = dyn_cast<StoreInst>(I)), a common pattern in LLVM).
Beyond stylistic discussions that siblings have pointed out, there are cases where explicitly using a type instead of auto would be preferable given the semantics at that location. For example, you might want to force a type conversion where auto would otherwise give you a different or even unknown type (because the source type is templated).
Intellij does a lot of smart stuff with their code - one thing I would like to see is "replace auto" but only on the visual overlay - much like they do with dynamic param types etc. That way you can visually see the type as you're working, but you can still just explicitly type "auto" if you wan.t
And now all of them except CLion Classic use the same underlying language engine, and the plan is to supersede Classic with Nova. If you need to use VS choose R++. Otherwise, use Rider for MSBuild projects or CLion for CMake projects.
Perhaps, but in this case, the same wheel (a C++ IDE) has been reinvented four times by the same company, whereas the competition (Visual Studio, Xcode) have existed for two decades or more. In this case, choice leads to fragmentation, to lack of focus, to poorer quality, and a focus on 'let's rewrite it again'.
Having used both CLion and Xcode, I would not hold up Xcode as better; certain things I find significantly worse (e.g. find usage, refactoring, version control)
Clang tooling pretty much evens the playing field in terms of parsing the AST, providing completion and locating/jumping to code. All we really need is a decent frontend for that, which vscode already provides. There isn't much jetbrains can do to justify the cost.
My experience is, I gave up using clion on a pretty large c++ project ever since they moved to clangd (it used to be decent before) because some functions gradually became much slower to the point of being unusable, eg listing symbols in a file.
The same functionality works quite well in vscode.
But I tried this release and everything works really well on the same project.
This is a complete change of the language engine. The new engine brings many new features and correctness fixes, and it's additionally now running out-of-process, which should result in better performance.
Just doing some basic stuff between classic and Nova the refactoring speed is infinitely better. I'm not sure you understand the pain people have with classic
I wish they focused on improving the editor and maybe dropped Java in its entirety, rather than on bells and whistles. I used CLion a lot, but I developed some sort of PTSD from having to wait ages for anything to open, stuttering etc. Their tools are certainly not ADHD friendly.
I recently decided it is over and moved entirely to VSCode. It's a massive improvement in terms of productivity even if it is not as rich, simply because it is more responsive.
I’m not sure why you consider this under bells and whistles? It’s a change to the most core part of the IDE, dealing with language processing and would likely solve many of the performance issues CLion has today
Apropos a recent discussion of custom corporate fonts[1], anyone notice the way "IntelliJ " is rendered with the i cradled in the J? Inspection shows the font is "JetBrains Sans". Any typographers want to guess what the base font was?
Sorry but i am not going to give them a free ride of my time testing for free their products. Hire testers to test your own products or at least give a free version of the c/c++ ide.
So tell me, please, what is the point to use for a few months this IDE?. Do you want me to start my project and stop after the trial period ends?. This is only valuable for the company because you test their products for free...
> Do you want me to start my project and stop after the trial period ends?
CLion projects are not IDE specific. CLion uses CMake.
If the trial ends and you want to continue using it then buy it. If not, then don't buy it. Your C++ project still works in every other IDE.
The preview is working flawlessly for me BTW. I prefer it to the stable release. Existing paying users are the main target for this preview.
> This is only valuable for the company because you test their products for free
None of their paying users are forced to use it. It is entirely optional to use the beta release or remain on the stable release. I have both of them installed side by side. I prefer having the option to test it out and report bugs or provide suggestions. I am effectively paying them to develop it and so am entitled to check out their work in progress and provide feedback.
They have their own internal QA department. Early access is additional to that. Improves quality overall and is a win/win for company and users.
So far I have found zero issues to report. It just works for me.
Some might argue that most software ends up "testing someone's code for free" because many products do end up leaving QA with bugs.
There's a lot to like about JetBrains. Their IDEs are good. I've use a few of them for Java, .Net and Kotlin and they don't suck. I used Visual Studio since version 6, but in earnest since 2003 and it has steadily decreased in quality over time. I feel like I am constantly testing their IDE for them. At least now with IDEs like Rider, I get something that is better than VS2022 in most ways and is easy to test the new release candidate of prior to it being an actual release. The IDE and eco system really works for me and the IDE also works the same on Windows as it does on a Mac so it is less jarring to change platforms. Vs Mac was a whole other level of pain and really, really was not good ever.
[1]: https://www.jetbrains.com/rust/