Who is using .NET Core for their startup? I asked the same question back in 2014. I wanted to see if there is a renewed interest with .NET Core in 2022.
I started my company back when news about .NET Core was first coming out (2016).
I've been bitten by Microsoft before (relied on tech they eventually killed), but decided it was worth it because of the modernization they had planned. Things such as AOT compilation, strong cross-platform support, lightweight runtime etc. was a giant productivity booster for me and my small team of 4 people.
Microsoft eventually backpaddled on a a few of their promises, but I still believe it was the right choice. I had doubts back then, but I would not hesitate today.
I can recommend https://stackshare.io/dot-net-core as a good starting point.
As a .net developer, I always use .Net in the backend. I think it is very good in asynchronous programming.
I would find it hard to evaluate these answers without the inclusion of "upon what workstations" and "deployed via what" because if the startup requires developers to use Windows and deploys to Azure (or such), this isn't as newsworthy as heterogeneous workstations deploying on Bottlerocket/Container Optimized OS
What does it matter if the deployment is "newsworthy" or not? "Newsworthy" doesn't mean "productive" nor does it mean "good for a startup trying to build revenue". I guess it might matter to attracting talent or investment? But productivity should still be more useful to a startup over novelty.
That said, .NET Core 1.x through .NET Core 3.x and .NET 5+ have great heterogeneous support. I've seen teams develop on Linux and deploy to a mix of "nano" containers on AWS and Azure. That "novelty" certainly exists in today's .NET.
Sorry if that word ruffled feathers, I wasn't trying to be a troll :-(
And yes, I appreciate that the marketingware for .NET claims a lot of cross platform, but from outside of that ecosystem it has been my experience that Microsoft's definition of cross platform can often be "works on Windows 10 and Server 2008" which is quite different from what normal people think of as cross platform
The mention of that "nano" containers in your response is the very risk I was trying to get at, since I have absolutely zero interest in running Windows anything in production, so it's important to be able to hear from folks who roll these out alongside their existing containerd setups
I shipped a .NET Core product on a handful of Raspberry Pi's running whatever the current version of Debian was at the time. That's cross platform enough for me.
That's good to know, thank you. To help with the first part of my comment, upon which local system did you develop that product (and, I guess implied in that question is: was it just you, or were there other developers with their own workstation setups)?
Visual Studio on Windows 10. I don't know why you'd use anything else for a .NET project: it's by far the path of least resistance.
I was one of 3 developers but the others were writing iOS and Android apps that interfaced with my Web product. That said, they had identical setups. Since the code was hosted locally on the Pi and we were all remote, they needed to be able to build and deploy my code also.
I just used "nano" as a general term because I couldn't think of a better one (which does show my personal bias here more than the ecosystem's), but I was also thinking about about a lot of deployments on some sort of container optimized Alpine Linux, I forget what that was specifically called.
So far as I'm aware most of the remaining cross platform concerns in the .NET ecosystem are almost all in drawing/rendering and in cross-platform desktop UI. There's at least one MAUI fork working on a Linux renderer for MAUI UIs, but no official support like every other platform MAUI supports today (Windows, iOS, Android, Mac Catalyst). Drawing/rendering is mostly a legacy ecosystem support issue: System.Drawing API has been around a very long time and was always just a thin wrapper around Windows GDI that it had some abstraction leaks that the .NET team thought were too hard to patch and instead gave up on making System.Drawing itself cross-platform. There are multiple cross-platform replacements for System.Drawing backed by everything from Cairo to SDL to ImageMagick, but they are replacements and for the most part aren't "drop in" replacements and there's still just so many libraries (and developers) so used to System.Drawing being always available that it's still too easy in the ecosystem to stumble into a library you want to use with a hard dependency on System.Drawing.
Other than needing to watch for System.Drawing dependencies, I've got ASP.NET Core/EF web backends that build, test, run on Linux no sweat with no cross-platform issues. (Including fun things like cross-builds: a Linux CI that is also building the Windows x64 self-contained binaries for other servers. I can't think of that many cross-platform stacks where you can do that.)
I think it's still very rare to hear about cross-platform .NET not because it's uncommon (it may be much more common than anyone suspects), but just that especially to HN, .NET is still very much "dark matter". It's out there getting (boring) jobs done (in boring companies) and no one is really blogging about it or "hyping it" because no one really needs to be. That's why "newsworthy" may have touched a bit of a nerve.
Not exactly a startup (yet?), but I'm using .NET 6 in my side project to build the API backing a React SPA. It was funny arriving at it, because I started out by trying to choose between Python and Elixir, having left the Microsoft ecosystem 10 years ago (and vowing not to return to it). At the end of the day, .NET bubbled up to the top as the sweet spot of familiarity, maintainability due to strong typing, integration into the open source ecosystem, and ease of hiring should that ever become a concern (premature optimization, but still).
I just use it on the backend along with Entity Framework, a pretty neat ORM, and do my best to avoid lock-in into the rest of the Microsoft monoculture. Using Postgres for data, AWS for hosting, React with Vite for frontend because I would never trust MS to get that aspect right with their endless iteration of UI frameworks both on web and desktop.
My needs are pretty basic, so it's been fairly smooth sailing so far. I love that I can use EF to generate join tables without needing to create entity classes for them, while still retaining the ability to customize field/table names and such.
Back in the day I transitioned from coding to management in the period where Linq to SQL was being phased out, while EF was still very half-baked, so I've had a healthy dose of skepticism picking it up years later. But so far I'm quite impressed (while double checking that every query generates reasonable SQL).
We use it in production with no big complains. I'm a Dapper man myself but EF Core works fine with Postgres. Just add Npgsql.EntityFrameworkCore.PostgreSQL to your project, generate a migration script and add a Postgres container to your docker-compose.yml and you're off to the races. The migration scripts that are auto generate work well and are pretty safe for rolling forward.
The performance is insane, and the development tooling around it is pretty impressive as well. I can live debug the react frontend app in Visual Studio without any setup or config. The project builds and runs the same on every box from dev up to production, so no need for virtualization, or Vagrant or VirtualBox anymore.
I am. The core app is a desktop Electron app with a .Net 6 backend. There's some communication with a web api, also written in .Net 6 and hosted on Azure, but the desktop app is the heart of the product.
Even though it's a cross platform Electron app I haven't built the Mac version yet - so I can't answer yet for any issues that might pop up there. (Only reason being I haven't got around to buying a Mac to test it on.)
Two reasons for using .Net. The first was it's what I've used most in the day job. Second is that a core sdk I need to use inside the app is .Net. Rolling my own in a sexier language would have added months or years to the development time.
.NET Core is great. It's good to go for cross platform development for anything non-gui related.
For client-side apps it is not cross-platform. There's MAUI which might hit all the targets you want, except GNU/Linux. Although Android/Linux is supported. The way to solve this is a web-based UI. There's several ways to go about having a locally running program with a web-based UI. Hijacking a web-based UI is not unique to .NET, so this is not an advantage, it's just this hack makes the lack of native UI not quite as important.
Also, which language/platform has really nailed down cross platform UI's while still being at least "somewhat" native on each target? There's really not many options. It's an industry wide problem. .NET has some decent escape hatches like Blazor. And maybe MAUI will get it right but the jury is still out.
As far as your development environment, you can use VS-code as your IDE in a cross platform way. Develop .NET software on a new M1 Mac? Yes you can! And with LSP you are not tied down to Microsoft tooling. With a little bit of configuration, you can can make Emacs or Vim a fully featured .NET IDE.
There's native AOT compilation so if you have some microservice that needs to spin up stuff, you don't need to worry about start up time.
Overall .NET just seems like an absolute killer tech. I think people are doing themselves a disservice to dismiss it just because it's from M$.
I haven't launched a startup on .NET recently, but I've been looking into modern .NET and I'm pretty impressed. I'll probably use it for my next side-project.
I think Blazor in particular has a lot of potential. I've grown disillusioned with front-end development over the past 5 years so it's worth trying something new and experimental. But I'm not sure I'd bet my career on it or ship it widely yet.
Me, I am writing most of tools for accelerate development and automating home bored tasks with csharp, it still the best prototyping language for me. Of course, I am not a startup yet, but a hope
In 2022 we use NET6, last .NET Core was 3.1 which reaches end-of-life soon.
Our SeekTable started as .NET Core 1.1 app 6 years ago, it was upgraded to 2.1, then 3.1 and now it is a NET6 app. Upgrades up to 3.1 were pain in the ass, API/SDK evolution was quick and not backward compatible, however last upgrade to NET6 was easy - this is more a change of the run-time version, as APIs are not changed anymore and become stable.
I've been bitten by Microsoft before (relied on tech they eventually killed), but decided it was worth it because of the modernization they had planned. Things such as AOT compilation, strong cross-platform support, lightweight runtime etc. was a giant productivity booster for me and my small team of 4 people.
Microsoft eventually backpaddled on a a few of their promises, but I still believe it was the right choice. I had doubts back then, but I would not hesitate today.