For us, every .NET upgrade since .NET 5 has gone surprisingly smoothly and reduced CPU/RAM usage by 10–15%.
We were even able to downgrade our cloud servers to smaller instances, literally.
I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.
Can only confirm that. Such a smooth platform overall for web and API development. We use it with several 100 devs on it and the choice never failed us, neither in technology or hiring. And it is not that we have .NET gurus or anything.
For what it's worth, the startup I currently work for is built entirely in C# and .NET, as was my previous employer. Both startups are based in the Dallas, TX area. Across both companies, applications were hosted on Azure and AWS using a mix of PaaS services and virtual machines running Windows and Linux. We've consistently found this stack to enable strong productivity and high-velocity release cadences.
.Net is also good as a platform for other languages. I recently started working with RemObjects, and you can compile languages like Java, Swift, Go and more (VB, Pascal) to .Net. Then, the whole framework and ecosystem is available. I'm liking it a lot.
They have customers who are startups and the 'got to have tools' folk like having lots of languages since they can onboard people who know anything-not-C# and benefit from the .Net library.
> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.
Too hard to ignore the benefits of cross-stack gains in Typescript/Python. The C# native phone, Blazor, etc just isn't quite there yet. Tried it at the last company, and full stack TS was just so much easier to do.
The reality is that the vast majority of startups don't make it. The #1 thing startups should be focusing on is hiring the right people and product velocity. TS just makes that easier in my experience.
Is it though? Backends can be any language and there's a lot more variety there -- TS+node, Go, Python, Java. It's just .NET that's largely ignored for no real technical basis.
You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.
There's that, but there's also the developer experience and functionality for people to run it on Mac and Linux.
We have a small C# service that we run locally via Docker (which I think is usually the optimal setup anyways) and develop with VSCode. Since it's small, it has worked well. Would it work well if that was our main backend? Not sure.
Wish I had the option of full Visual Studio on Mac for it regardless.
I'm founder of a 100% .NET based company (15 years, 1mil LOC), all development happens on Macs, production servers run linux. No issues so far.
No, really, I'm facing more issues from Cursor based based on a year-old upstream version of VSCode than from this, heh...
You can run .NET natively on Mac, if you wish. I would also recommend JetBrains Rider over VSCode; it works on Linux, Mac, and Windows and, in my opinion, is better than Visual Studio anyway.
I use Rider† daily to write F# and C# on my Mac. It works great, I have no issues with it. It even handles the .NET Framework 4.8 code‡ that I maintain without any issues thanks to Mono.
† And Neovim occasionally, but I mostly use it for Typescript or anything that isn't F#/C#.
Rider is your option there, it's better than Visual Studio (I used to work on VS).
There used to be a Visual Studio for Mac (since retired) but they never could get it right in comparison to the Windows version.
VS Code on a Mac works great and with the ability to run SQL Server in Docker you can have the old stack right there on your Mac.
As a daily user of F#, I'm most looking forward to the support for "and!" in computation expressions. There are a few performance-critical pieces of code I can think of that are currently wrapped up in "Task.WhenAll" / "Parallel.ForEachAsync" that I'd like to extract back into "native" F# task computations.