Ask HN: Current state of coding .NET code on non-Windows machines?
Does anyone have a good idea of how much .NET development is happening on non-Windows machines (or in non-Windows dev environments)?
I'm talking about the environment where code is written and debugged - not the environment where it is published or ultimately ran.
For example, I could imagine .NET back-end code being developed on Macs or Linux then deployed to AWS.
I enjoy the .NET language, but I much prefer a Linux dev environment over a Windows one (Ruby and occasionally others languages uses in the Linux dev environment). The release of Visual Studio 2022 for Mac has made me wonder how much demand there is for writing .NET code in a non-Windows environment. I also realize there are other alternatives, like JetBrains or VS Code.
80 comments
[ 3.4 ms ] story [ 193 ms ] threadMaybe Ryder is available in Linux? It should be just as good as VS.
Unfortunately, if you have to reach back further than .net core or standard then you'll need to work in a windows environment – Cloud VMs are pretty cool and cheap if you don't want to use your hardware for a partition.
I'm curious if you had team members with similar setups, and how well the team worked together with that setup?
[0] https://www.jetbrains.com/rider/
There's a couple extremely common plugins "everyone loves" that just murder VS performance and everyone blames VS and not the plugins.
I know people feel like they just can't possibly live without it, but the refactoring tools in VS nowadays are much better, so I encourage folks to test drive by going a couple weeks without installing ReSharper. If you still really miss it and are willing to pay the performance penalty to have it after that, go for it. But give VS a fair shake without it.
One of the reasons for this is you can't turn off the Roslyn-based MS engine in VS (which IMO is reasonable, since it's needed for a lot of stuff) so there are always 2 code analysis engines running.
That's one of the main selling points of Rider Imo, that it doesn't run 2 completion engines simultaneously, which makes it much faster.
Unfortunately Resharper is still far superior to VS with the quality and quantity of built-in refactorings.
Another thing with Resharper is that it seems to run synchronously, meaning if you type something and press the completion button, the suggestions always pop-up. A major pain point in previous VS versions is that this wasn't the case with the built-in engine.
Sometimes you just pressed the autocomplete button and nothing happened, because VS was still parsing your code.
Thankfully 2022 fixed this, and this is one of the reason I would never consider going back to the older versions.
Roslyn is extremely well tuned. (Anecdotally in any IDE including VS Code without ReSharper it's performance is incredible and hardly noticeable.) ReSharper's performance problems are ReSharper's performance problems.
Blaming ReSharper's performance on Roslyn is just as wrong as blaming ReSharper's performance on Visual Studio. It's pointing the finger at the wrong thing in the stack.
Of course that's a big selling point for Rider. It's incredibly wonderful marketing luck that almost all of ReSharper's performance problems get blamed on Visual Studio itself or on Roslyn and almost never directly on ReSharper. As long as people keep pointing the fingers away from the plugin, JetBrains gets just about free marketing from every VS performance complaint real or imagined. Their incentives aren't aligned to improve ReSharper performance when "everyone" just answers "Just switch to Rider already" because they mistakenly blame Visual Studio rather than the ReSharper's own engineering.
For further comparison, I've also used JetBrains products a lot over the past few months. They are also solid and work great.
On the one hand this is great for cross-platform development (as is the topic here), as VS Code is about as cross-platform as it gets.
On the other hand it feels increasingly interesting/weird/almost-sad that the expensive flagship of the VS brand sometimes seems to be left behind by its tinier, free (as in beer and speech) counterpart.
I don't think your theory is entirely correct, but I think some of it applies here: VS Code started as an Azure project (the core editing experience Monaco was designed for the Azure Portal first and foremost) and seems to get a lot of love precisely because of its cloud synergies and its place near Azure's heart. It does seem to have captured the hearts and minds of most of Microsoft's best tooling engineers. That said, it's possibly the most "Developers developers developers" they've ever been given how much of that tooling is now cross-platform, isn't tied so much to Windows specifically, and isn't tied as much to Microsoft-only languages either.
Really there’s three important factors in perceived VS perf issues:
1. Your codebases have gotten bigger. More projects in a solution and more code in a project means more work the IDE has to do. Various components have their breaking points and it’s not uncommon to hit them.
2. VS is really really really really big. Some components in there run like a well-oiled machine. Others, like those last touched in 2013 and with less than 10k users per month, are rickety and will freeze your UI or cause the GC to freak out or both. If you’re one of those 10k users, whoopsie!
3. For many years the mandate in the VS org at Microsoft was that of a feature factory. That changed around 2016 or so, maybe a little earlier. But cleaning up a decade of feature factory work while still needing to innovate on a growing userbase that throws more and more at the IDE each year is hard.
A lot of bigger companies want to use things like applocker to secure any machine inside their network, which makes linux problematic.
If you're looking for an enterprise job most non-tech enterprise companies still require development on a Windows machine because they require everyone to use a Windows machine.
I'm wondering if it still is in fact tied to Windows - because even though developers can use .NET without Windows, they are not for whatever reason. Don't know if this is true or not, but it is what I'm asking here.
I've developed on all 3 major OSes, and all of them have some kind of drawback (though I have to admit, since M1, Apple hardware is miles ahead of the competition).
"Microsoft people said EEE, using Microsoft- led projects is nonstarter."
"Are you going to pay me the time to relearn x,y,z in dotnetland?"
I tried to get involved in Mono-based Open Source back in the day and it left a lot of lasting sourness at the "Linux community" and how distrustful/paranoid it could be. Despite Mono being open source. Despite however many open patent agreements Microsoft signed. There was so much ugliness and so many people I encountered had a lot of passion for "Never .NET".
I hope that changes for the community. .NET doesn't get any more Open Source today. There's no longer a .NET/Mono split, they've merged. The open patent agreements with the .NET Foundation and other stewardship orgs are about as rock solid as they can possibly get.
I cynically saw so much "Never .NET" hate in that community that I can't imagine it won't linger for long past its expiration date.
That they don't show up is more indicative that there aren't that many in the first place IMHO.
Speaking as a former .NET developer, something that impedes searching for a .NET job that isn't at a huge, crufty, old school enterprise company is that the vast majority of .NET jobs are at such companies. So you have to sift through all of those to find something that doesn't fit that mold.
Yeah, but you wouldn't necessarily notice that they're using .Net.
Source: I work at MS but have used .NET on other platforms at previous jobs.
VSCode works, but JetBrains Rider is probably your best bet. It just works and works really well compared to hodgepodge of extensions in vscode. Beyond these 2, you're pretty much on your own, and things never Just Work.
But, beyond the editor, the ecosystem is not Linux-friendly. A lot of libraries expect and assume you are on Windows and just refuse to work for whatever reason. There are near-zero relevant resources (blog posts, stack-overflow Q/As, forums) for developers on Linux. (I guess this is how Emacs users on Windows feel).
The second paragraph is why I stopped. The .NET core itself is decent, and if you manage to limit use within you should be mostly fine, probably. But the experience never feels home and it is a constant reminder of being second-class that's not my personal favourite way of spending life.
I'm curious about this. Can you give an example of a library that refused to work? I'm having trouble imagining what would cause something to break on Linux - but not on Windows - in a typical .NET library or NuGet package.
To generate/process images, there are other, great, .NET library like SkiaSharp, or ImageSharp.
> If you can't use System.Drawing with your application, recommended alternatives include ImageSharp, SkiaSharp, Windows Imaging Components, and Microsoft.Maui.Graphics
Sadly .NET devs will jump on any first party software and won't look a lot in community alternatives.
I use VS 2022 Community on Windows, tested it there then published to Linux and uploaded over SSH to a VPS. It worked very nicely.
What do you mean by that? I know that the timezone definitions in txdb are not the same as the ones MS uses on Windows, but it doesn't sound like you're talking about that.
I used to use the .NET runtime on Linux but now I just use a Make file to publish to self-contained Linux binaries and rsync them to the Linux boxes in prod.
I'm really enjoying it. Honestly the only (and biggest) problem right now is with TLS 1.3. .NET on Mac doesn't support TLS 1.3, even for their client Http classes like WebClient, because of some silly ways SslStream is implemented under the covers on macOS. There is more details in this issue: https://github.com/dotnet/runtime/issues/1979
Plenty of .NET workflows still rely on libraries that are Windows only, because they either depend on classical .NET Framework, Windows specific APIs or VS plugins.
Watch this week's BUILD about all the cool features to develop on Azure and Linux (WSL) with VS, and then check which talks still refer to other workloads.
Unfortunately Microsoft's management still considers VS4Mac and VSCode second class, and hinders FOSS efforts with such actions.
A year ago I needed to quickly do something related to Xamarin and as far as I remember I actually had to move to Windows for some reason, but that was the only time. I'm not even sure if it was related to inability to run stuff or it was just too much tinkering to launch that single thing.
But it may also be, that it's just because it works on Linux. I develop mostly for Linux servers and use Linux tools that obviously integrate better with Linux-based OS than on Windows. There is WSL, but still, experience is not that fluent.
You would be really limiting yourself if you look for a .NET job without Windows. I am sure they exist but it's probably something like 95%/5% windows/not windows.
I am not really sure why you would want to use Linux/MacOS for this though. The dev experience for .NET is very consistent between platforms if you don't use Visual Studio.
Using VSCode, Rider, and the dotnet CLI, I have developed on MacOS, Windows, and Linux without noticing many differences.
So I ended up running a Windows machine on Parallels on my Mac. Now I have a consistent work environment as the other backend devs, but it's not a good developer experience. Sometimes it's extremely slow. The context switching from a Mac to Windows is distracting. I feel very disconnected from the code I'm working on. I'm going to try JetBrains Rider based on suggestions here.
It makes me reconsider if I really want to go down the .NET path in my career if I probably have to use Windows (with about 95% .NET job opportunities using Windows). Java looks like a better option for fullstack web development on a Mac.
Azure Data Studio is cross-platform and the obvious successor judging by comparative release speed and that every SSMS install automatically installs ADS. It's also more annoying than SSMS, but ADS is still a better experience than most SQL gui tools.
Cross compilation is just as good as Go, and they are just starting to have the ability to generate native code instead of a wrapped runtime.
It's a mix between Windows, MacOS, and Linux. When you join they ask if you have a preference between a Windows laptop or a MacBook.
The people on MacOS and Linux use either VSCode or Rider I believe.
Everything seems to run fine. It's kind of amazing to see, considering where .NET started.
Regarding performance, I am impressed.
The platform and language is top notch IMO. It look like MS is entirely new beast since Nadella took the ship.
:heart:
How do you sudo? AFAICS this is the biggest unsolved problem for pwsh on *nix.
On Linux, you can use something like this: sudo pwsh -C <command> (or create wrapper for it...). Sure, not exactly full blown sudo but you could wrap it into scripts when needed and give appropriate sudo rules.
Almost everyone in our team uses Rider (except me and a couple of other holdouts) and the general consensus seems to be that it is far superior to VS. We completed a long migration over to Core and now we have developers on Mac (not sure on Linux) and we don't have a hard requirement on OS.
As for general numbers/market I think it's still relatively niche as any glance at a more start-up focused jobs board indicates (though not niche overall, just tends to be enterprises where dark matter developers are employed).
I hope one day people will realise what a fantastic ecosystem is available but for now they'll be bashing out messes in write-only languages and desperately carrying out microservices migrations to try and escape the pain when the project goes above 100LOC /s
.Net itself:
Everything builds and runs no problem, on linux I occasionally have to self install the latest SDK but that's a well known problem with many languages/platforms.
This is with the preface that I work on web servers, desktop right now is a no go with things like System.Drawing, printing etc. not being cross platform.
Tooling:
VS code is in a superposition of being an excellent free editor and a complete joke, it works but it's a long way from a great experience. Funnily enough this is a spot where F# support is better than C#.
Rider on the other hand has a great, near identical experience across all 3 systems.
Other notes:
I'm on Azure so I can't comment on the state of AWS SDK's (I would not be remotely surprised if they were better) and I find the emulator support lacking in general and especially on an M1 mac. This is an Azure problem rather than .Net but one i felt worth mentioning for other .Net developers.
To answer the start of your question: I think the bulk of .Net development going on is still on windows but that's definitely changing.
JetBrains Rider. Been solid no issues. Hate going back to windows to do dev work.
You'll need the runtime to run things where they are deployed, and it is a huge dependency
No debugger/profiler available on linux (except a commercial one from jetbrains)
There are a lot of things you'll miss coming from "real" Visual Studio.
VS Code is really a very good lightweight editor, but it's not trying to be an IDE.
Visual Studio 2022 for Mac is.. fine. It's a poor choice of name given that it sounds like a Mac port of Visual Studio, which it's not (it's MonoDevelop rebranded and updated with other features, but is still really far from VS on Windows).
I use JetBrains Rider quite a bit and I really quite like it, but even then, it's not close to matching Visual Studio + Resharper.
The features that you only really get to know on large projects or specific use cases are the ones that you'll miss the most in my experience, as it tends to be the blind spot for lighter environments.
IntelliTrace is a big one. There's nothing like it on any other .NET IDE that I can think of. Also the deep AppInsights integration has always been fairly incredible in VS and while VS Code has started to adopt some of this, it's still far from what's in VS.
The last thing I really miss is Snapshot Debugging. Having an exception being reported to you from live, being able to then click the exception on Azure and immediately pop a VS window with the debugger on the line that failed with a fully rewindable call stack as if it were running locally is magical for turning around bugs - most of the time you don't even need to try to trace the cause or recreate the circumstances at all.
Rider got a lot better over the years and I would pick it over Visual Studio anytime.