Comment by capableweb | Hacker News Reader

Comment by capableweb | Hacker News Reader

Microsoft promising `dotnet watch` for a while and then dropping that certainly doesn't help with the already pretty damaged view of Microsoft not caring about open source developers. Here is the gist of the situation from Microsoft's point of view:

> Throughout the last year we’ve been working to enable the best possible Hot Reload experience in Visual Studio 2022 and .NET 6. Part of our goal was to also explore making this feature available to customers through a variety of mechanisms such as bringing the full power of Hot Reload to as many .NET and C++ developers as possible when running through Visual Studio 2022 debugger, supporting Hot Reload when running .NET 6 apps without the debugger, and the very basic Hot Reload support we added to the .NET SDK tools through dotnet watch.

> As we reflect on what was accomplished, and what is still in front of us, the backlog continues to grow. This includes many high value scenarios that will benefit the broadest number of developers, including focus areas such as .NET MAUI, Blazor, adding support more types of edits, more optimized experience when working with XAML apps, and much more.

> With these considerations, we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022 so we can focus on providing the best experiences to the most users. We’ll also continue to pursue adding Hot Reload to Visual Studio for Mac in a future release.

So, first they wanted "bringing the full power of Hot Reload to as many .NET and C++ developers as possible" but now they shifted to "focus on providing the best experiences to the most users".

Best part of this whole thing is the pull request which was opened (https://github.com/dotnet/sdk/pull/22217) but " locked and limited conversation to collaborators" straight after opening it as Microsoft anticipated the backlash but still went ahead with the change.

Seems they still have a lot to learn before they can indeed be trusted.

Ugh. I've been using dotnet core on Linux since it was introduced. While it mostly works fine, I always had the feeling that Linux (and mac probably also) is a second class citizen. They care about Linux compatibility inasmuch as it allows you to build the application on a Linux-powered CI server and deploy to another Linux server. Developing outside of Windows? most of their tools are not available or have a greatly diminished feature set (for example, you can take a memory dump of a running dotnet application, but can't really inspect it without a Windows VM).

If not for JetBrains Rider, dotnet development on Linux would be close to impossible IMHO.

When looking for my next gig I'll probably be switching to something else.

Is Jetbrains Rider acceptable for .NET work under Linux, or do you miss Visual Studio proper?

I haven't had much experience with .NET on Visual Studio, but I would say that Jetbrains Rider is probably the best thing you can get for .NET work on Linux.

As a matter of fact, they implemented their own hot-reload functionality themselves [0][1].

[0] - https://twitter.com/JetBrainsRider/status/145148793146664961... [1] - https://www.jetbrains.com/rider/nextversion/

Even on windows I prefer rider. Less resource intensive,faster and crashes less for me.

I actually preferred Rider even before fully moving my .NET work to Linux. If you have any experience with IDEA, you'll feel right at home (they are very similar and can be operated with pretty much the exact same shortcuts).

Personally, I prefer Rider to VS on all platforms, including Windows. It has much better performance, feels like a modern IDE, and after doing Java for a few years in between .NET gigs using IntelliJ I've gotten to prefer how IntelliJ-platform IDEs work anyway. The "Structure" pane is super useful.

Whereas, Visual Studio... well, let me just say first that I know real people work on that product, some of them are probably reading this, and if so, I appreciate you.

Unfortunately, every time I've ended up having to switch from Rider to Visual Studio for some edge case scenario or to do an Azure deployment (before we moved that process into CI), I'd end up frustrated. Even with VS 2022, which is better, it's slow compared to Rider. Also, despite a couple of cosmetic coats of paint and new icons and such for VS'22, it doesn't really feel like a modern IDE or like it's changed noticeably since 2010 or so. Granted, stability is often a plus, but there's a ton of workloads in there that I don't think are relevant to a modern cross platform .NET Core 3.x/.NET 5/6 development experience and I suspect supporting all of that is a factor in why it's so slow.

I haven't even gotten into how much worse the performance in VS gets when you add ReSharper to the mix, and even with all the genuine refactoring improvements in VS in the past decade, I still feel like I'm working with a couple of broken fingers when I don't have ReSharper active. Better refactorings, better intellisense.

Worth to mention the huge “demonstration” using LGTMs in the revert PR: https://github.com/dotnet/sdk/pull/22262

And it was eventually merged!

I didn't read that as, "Our focus is changing from A to B," so much as, "We originally hoped to ship A + B, but A ended up being more work than we expected. B is achievable and impacts more developers, so we're focusing on that first".

This would make sense if they literally weren't removing a functioning implementation of A in the process.

The thing you're missing is that A worked great, was already finished, in a release candidate, then removed.

Reply on news.ycombinator.com