It is definitely more performant in my experience. Occasional hiccups happen as well, but way less than with VS. Please note my experience with VS 22 is a bit dated because I moved to Rider a few versions ago (probably 17.8 or 17.9). Additionally, I haven't really used VS without the ReSharper plugin extensively so that's what I can compare Rider to.

Regarding your points:

> MAUI

No personal experience yet unfortunately on my part

> Code completion

At least on par, basically ReSharper with a few extras. Navigation and refactoring is great and comprehensive.

> IIS

Also no personal experience

> Debugging

Great debugger IMHO. Matches VS, predictive debugging is nice (deemphasizes branches it knows won't run), breakpoint conditions are great (only break on a certain thread, after another breakpoint had been hit, after n hits, ...), shows return values in the watch list automatically, etc.

> Look & feel

Probably personal preference: I prefer its more modern and focused look over VS. If you're into that, its Vim emulation plugin is superb.

> WPF

Not its strong suit. VS is way better here. Rider only has a preview. Annoying: it doesn't use themes for DevExpress-libraries correctly in one project at work.

> file explorer

Pretty much like VS

> Git integration

In my experience nicer than in VS. Exposes git's features more easily than VS. Take it with a grain of salt because I use the CLI mostly anyway.

I hope this helps a bit. But you're probably better off trying it for a while if you can.

Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file.

This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.

For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`"

Edit: The flag is -N or --intent-to-add

You can use `git add -i` to pick files to add interactivelly

This is cool, wasn't aware of it.

I use `git add -p` regularly, and it's one of my major pet peeves that it doesn't include new files. I constantly forget to include those in commits because of that.

came here to say this, git add -p is such a brilliant thing.

alias ga="clear ; git add -p" is an alias i always seem to keep

What type of workflow do you use where you regularly want to commit only some of your changes to a file? I honestly don't think I've ever had that need.

It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite.

Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful.

If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.

While some might be more rigorous about working on a commit at a time, a couple other helpful bits are:

- Cleaning up print() calls and similar debug - It's a first-pass review of your own changes; re-read docstrings/comments, and easily go right back to them and update them etc. The diff view is different from the coding view and you gain insights, etc.

This might apply moreso to my often script-oriented coding that does 20 new things, rather than e.g. unit-test backed "formal" coding that does a few specific things.

My own workflow isn't quite at the "commit often" level of frequency, but instead I'm simultaneously crafting several related but separately-reviewable commits in one branch for one PR.

I already read PCL and imho it's a really great book. In case, however, you have further questions (like I did) have a look at #lisp on irc.freenode.org - the guys there are really nice and helpful.