[Dev] JetBrains Rider Impressions

[Quintillus]

I got back to writing some C7 code today, and wanted to do a little bit of refactoring. Not being fully satisfied with VSCode's offerings here, I decided to activate my Rider trial.

Thoughts so far:

Refactoring: Yup, it lets you refactor out code into new methods. No surprise, but if VSCode does, it's hidden.

Code Style: Wow, this is so much better than VSCode, even out of the box. Rider was immediately pointing out, "hey, this can be made readonly", "did you know this method could be made private?" "this method's name isn't capitalized - by the way, do you want us to auto-detect your project's code styles, or set it yourself?" All those inconsistencies that we've noticed (or in some cases not noticed), but haven't done much about? Rider's willing to help.

Tabs/Spaces: The "Show whitespace" setting lets you show leading, trailing, all, or leading and trailing. (In VSCode, this is "Render whitespace"; works the same but without the "leading and trailing" option.

Godot Integration: It detected that we had GodotSharp references, but even after activating and restarting, if I control-click on a Godot object (Vector2, for example), it offers to disassemble it rather than just showing the metadata as VSCode does. VSCode's approach is preferable here 90% of the time, IMO.

Shortcuts - You can set it to emulate VSCode, Visual Studio, Sublime Text, emacs, ReSharper, Visual Assist (what's that?), or use the IntelliJ mapping.

Still early on in the impressions, and too early to say if I prefer it outright or enough to buy a license, but I can see where it can add value. And at least I'm actually using the trial, unlike GitKraken where I proceeded to work only on Mercurial projects for the entire duration of the trial!

 

[Puppeteer]

My biggest gripe with VSCode is the slow Intellisense/code completion. How does Rider compare?

Also, how versatile is Rider with respect to other languages and just being a text editor for config files and the like?

 

[Quintillus]

I hadn't actually noticed VSCode being particularly slow with IntelliSense/Code Completion, and just added some random stuff in VSCode to see if I'd been ignorant of its slowness, and it seems pretty normal in responsiveness. Running a 10-year-old Core i5 2500k processor, so I don't have a supercomputer, but I do have plenty of free RAM at the moment. Haven't noticed Rider being slow in IntelliSense either, for that matter.

Speaking of RAM, at startup for the projects, Rider is using 1.25 GB versus 650 MB for VSCode, if I'm adding them up correctly. Those numbers are fairly consistent with the difference in commit size (the Windows memory metric) when each one is running, too. So if you're low on RAM, Rider might be the worse choice. Not a big concern on my 10-year-old desktop, but my 3-year-old laptop only has 8 GB (weird, I know, but each one wins about 50% of the time if you compare specs). Also not surprising a full-fledged IDE would use more though, even if VSCode is an Electron application.

As for other languages... it seems to have pretty decent support for syntax highlighting at least. The C7 JSON file is formatted and sections are collapsible; I opened up a .tscn file and it let me know that it had a plugin that could handle those, so I installed it and now those have highlighting. Although when opened a Java project, it offered to install a Xamarin Android Java plugin, rather than a desktop one. I tested Java specifically because JetBrains' flagship product, IntelliJ, is a Java IDE, so I wanted to see what it would do when I tried to use the "wrong" IDE.

--------

I'm actually somewhat surprised it didn't just say, "cool, let's write some desktop Java". In my experience, even though JetBrains has about 12 language-specific IDEs, you can often just install IntelliJ and use it for all sorts of languages. Even in Rider, if I search for a Python plugin, it returns one whose description is, "The Python plug-in provides smart editing for Python scripts. The feature set of the plugin corresponds to PyCharm IDE Community Edition." So if there are advanced Python features that you need PyCharm Paid Edition to fully use, you need PyCharm, but if you have Rider and just want to do some casual Python for a change, you don't need to install a whole new IDE for that. A 31.5 MB plugin will suffice.

As another example, once I was working with another developer on a JavaScript project and we were using IntelliJ. One day I said, you know, JetBrains has WebStorm for web development, and we have the all products license, maybe if we try it we'll find it has awesome new features? So we did, and we couldn't identify any differences. Maybe we would have if we'd been using PHP, but for our JavaScript project it didn't matter if we were using IntelliJ or WebStorm. It might've been equivalent in Rider, too, for all I know.

JetBrains is aware of this, which is why their All Products pack costs less than what two individual products cost, for some combinations of "two products". If you're a real polyglot, you might need more than one, but if you just dabble outside of your main language, there's a good chance one "premium" option will be sufficient. For that matter, now I'm curious how C7 would work in IntelliJ Community Edition... if it worked great there, that might be a good, free option. And while that would undermine JetBrains' business model, I would not be surprised if it worked fairly well.

 

[Quintillus]

Some more notes:

- Rider will auto-import your imports, which is a feature I'm used to from Java and was really missing.
- Tabs/spaces... if the file already uses spaces, and you add a new line, it seems to stick with spaces. But if you add indentation to a line with spaces, it adds with tabs. With our current inconsistencies, it's not perfect.
- I really like the swappable keyboard shortcuts; I've installed a NetBeans keymap and will switch back and forth if I remember the shortcut in NetBeans for something, but not in IntelliJ/Rider.
- There are about 1000 settings you can configure, and I don't know what most of them do yet. Some do have tooltips, but they could benefit from having interactive examples or GIFs illustrating "here's what having this enabled does, here's what having it disabled does". Perhaps something to keep in mind for our own documentation. Still, the defaults seem to generally be sensible, and it gives little notifications all over the place letting you know you can tweak how things work if you don't like the defaults.
- Rider has the great JetBrains Git conflict resolution tool, with each branch on one side and the result in the middle. It's the best one I've come across; visual and easy to use (VSCode's is the second-best one I've come across). I had a cross-branch conflict after making changes on my PR, and it looked kinda ugly in the default Git tool, and I loaded it in Rider and it was easy to resolve with its visual feedback.

And the big one... it runs C7 and can debug it with breakpoints!

I hadn't even tried it because I didn't expect it to work, but I did just now, and it had automatically picked up the configuration, and breakpoints work! It pulled in this default configuration, which works:

If you start the "Editor" configuration instead of the "Player" one, it starts the Godot editor from within Rider. You can then start C7 from within the editor-running-from-Rider, but it doesn't hit breakpoints that way.

Still, this is going to change how I work on C7 - the Godot editor is only going to be fired up when I want to work with its UI tools. No more incessant "this file got modified outside the Godot editor, do you want to reload it?" pop-ups.

 

[Quintillus]

There are only a few days remaining on my Rider trial. The overall impression is it's well worth the price, especially for the refactoring support. However... much of JetBrains' development team is based in St. Petersburg (with the company itself and a smaller portion of its staff being Czech). Thus, purchasing any licenses would be indirectly funding the Russian government via payroll and income taxes. As such, at this time, I will be going back to VSCode after the conclusion of the trial, and would not recommend switching to Rider, or other JetBrains products at this time.

This might be a more theoretical problem as I wouldn't be surprised if JetBrains is or is about to run into problems paying their developers in St. Petersburg due to sanctions. But until and less the situation returns to the status quo ante bellum, the responsible thing to do is not to purchase a license. The sudden lack of updates from JetBrains' blog and Twitter accounts since 2/24, other than one message voicing support of Ukraine, suggests they are aware that they have a problem.

I might also explore the Visual Studio, as Lanzelot did some in December, and there are clear benefits, especially to refactoring and debugging, in having a full IDE.

Although realistically, right now I'm in a bit of a lull of development, and beyond resolving a few conflicts on pull requests so they can be merged (there's at least one more still to do), the only code I've written in the past week has been Java code for my editor.

 

[WildWeazel]

Ah that's unfortunate. I only knew of them being Czech.

 

[Quintillus]

Yeah. They haven't been publicizing their connections to St. Petersburg as much in recent years. But having followed their blogs (and used IntelliJ at work) for years, it's no secret. Their programming language Kotlin is probably the most prominent example; similar to how the Java language is named after an island in Indonesia, Kotlin is named after an island in St. Petersburg.

I don't envy the situation of either the developers or the managers in the Czech Republic...

 

[WildWeazel]

Update: they've cut off business in Russia and many from their Russian team have emigrated. https://blog.jetbrains.com/blog/2022/03/11/jetbrains-statement-on-ukraine/

 

[Armageddon1]

I was able to get debugging to work in VS Code using a very similar configuration to the JetBrains one shared by Quintillus.

First, make sure to install the C# and C# Tools for Godot extensions:

Then, you'll want a configuration in `tasks.json` to build the project before running it:

        {
            "label": "build",
            "command": "dotnet",
            "type": "shell",
            "args": [
                "build",
                // Ask dotnet build to generate full paths for file names.
                "/property:GenerateFullPaths=true",
                // Do not generate summary otherwise it leads to duplicate errors in Problems panel
                "/consoleloggerparameters:NoSummary"
            ],
            "group": "build",
            "presentation": {
                "reveal": "always" // can change if you don't care to see build output
            },
            "problemMatcher": "$msCompile",
            "options": {
                "cwd": "C:/<redacted>/C7/C7"
            }
        }

Then add a configuration to launch.json to run the project:

        {
            "name": "Debug C7",
            "type": "godot-mono",
            "request": "launch",
            "mode": "executable",
            "preLaunchTask": "build",
            "executable": "C:/<redacted>/Godot_v3.4.2-stable_mono_win64/Godot_v3.4.2-stable_mono_win64.exe",
            "executableArguments": [
                "--path",
                "C:/<redacted>/C7/C7" // the path must contain a 'project.godot' file
            ]
        }

Set a breakpoint and run that configuration:

 

[WildWeazel]

Thank you, this will be great for me on Linux.