Hacker News Reader

Comment by RagnarD | Hacker News Reader

I've been a Jetbrains customer on and off for years. In all of that time - across vast improvements in hardware - ReSharper has been slow. So slow. It doesn't seem to matter how many orders of magnitude faster are the CPUs, how many orders of magnitude increase in RAM. It just never seems to be usably fast in Visual Studio. Unfortunate that they apparently don't care about that, it would otherwise be a very good tool.

View on HN

And yet Rider, using the same engine, is lightning fast and has been since the earliest alpha releases. If I were a conspiracy theorist, I’d say that Microsoft keeping VS 32 bit for so long in part to hobble ReSharper.

Microsoft has been recommending out-of-process extensions for quite a while now; ReSharper never moved there (they did with Rider). Might be that for an extension the size of ReSharper it's not feasible (to this day Rider is missing features in the UI that ReSharper had for ages) and they decided that making their own thing is the better approach.

However, Rider is quite a bit slower than VS 2022 (w/o ReSharper – Roslynator has been a good replacement for my needs here) and there's likely no good way around this for JetBrains. Since .NET embraces Roslyn for lots of customizations (custom analyzers, source generators, etc.) Rider must keep a Roslyn workspace around, along with its own analysis, thus doing pretty much everything twice – both for loading a solution and for every keystroke.

> Microsoft has been recommending out-of-process extensions for quite a while now;

In other words, Microsoft has been recommending rearcheticting your extensions from the ground up, because their own code base is too messed up to support 64-bit.

And it looks like JetBrains is doing that, but it takes years for such massive codebase.

Visual studio is 64 bit now.

Rearchitecting the extension out of the process makes sense. You can easily trace performance issues to an extension and they don’t have to build a bunch of extension performance tooling in the ide

It's not just 32 vs. 64 bit. There are many other reasons that require separation. Stability, performance, different dependencies from the IDE process, ...

> Rider is quite a bit slower than VS 2022

strange, this doesn't match my experience at all. VS 2022 is way better than VS 2019 and earlier but still significantly behind Rider in terms of speed.

If I were a conspiracy theorist, I'd say JetBrains are keeping ReSharper so slow in part to promote Rider (which is actually great!).

I think JetBrains made a mistake by not including a Windows Forms designer much sooner, that supports 3rd-party controls/components [0] in the Rider IDE. Dealbreaker for me now and for many other companies I've worked for or know of. Unfortunately, we had to choose Visual Studio because of this.

According to their own developer survey, Windows Forms was at 22% in 2023 [1].

WinForms != legacy, because it's very extensible! Microsoft still maintains it (last update was 1 month ago). It is also still one of the flagship products for companies that make 3rd-party controls like DevExpress [2], Telerik, Infragistics, GrapeCity and several others.

Students in academia today will not learn about WPF, WinUI, UWP and whatever else MS' pushing. They learn Windows Forms - in my country and in Europe at least.

Hopefully we'll get to switch over to Rider soon, but it's been 5 years already [3]. Big mistake.

[0] https://www.jetbrains.com/help/rider/Working_with_Windows_Fo... ("Unfortunately the support of custom controls is not implemented yet (as of v.2023.3)")

[1] https://www.jetbrains.com/lp/devecosystem-2023/csharp/

[2] https://www.devexpress.com/products/net/controls/winforms/

[3] https://youtrack.jetbrains.com/issue/RIDER-25764

Given how messed up the travel has been since Windows 8, and the focus Azure and XBox nowadays get, Windows Forms and WPF are still the best way to target Windows from .NET on the Microsoft own frameworks (naturally there are Avalonia and Uno as well).

For the C++ folks, Microsoft has yet failed to produce anything better than MFC, C++/WinRT with XAML and COM/IDL ain't it.

Reply on news.ycombinator.com