.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.
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.
I've worked at multiple startups that were built on .Net from day one. One very large music streaming site built entirely on VB.NET [0].
[0] I actually think VB.NET is the superior .Net language, but it lost support at MS and died. I think the code is vastly more readable (to me) than C-style code, and I've coded in every C, Java, C#, whatever variant.
As a startup, what is it in for me to switch from Java, Spring Boot, Hibernate, Beam, Flink, Pulsar, Vault, KeyCloak ecosystem to C#.Net? Is the documentation better? Do I get better performance? Is the community larger and more stable?
That's part of it, but is also weird because C# & .NET is probably one of the most productive single-developer stack you can choose. Modern ASP.NET handles so much for you it's a lot like Rails in that regard, you can get a lot done in it solo.
I think the "confusing" aspect with C#, being part of the Microsoft eco-system, is that there are many smaller companies (and startups) that may have concern paying for such tools.
To the uneducated, C# is linked to Visual Studio.. the IDE.. and the Community edition if free as long as you are a student, open-source, and individuals. Professional and Enterprise are paid.
(Yes - there is Visual Studio Code)
Again, I am looking at this from the uneducated. With the above, as well as "going with other Microsoft products" things start to get more expensive. Need a database - should it be SQL Server? Should it be Windows Servers? etc.
Because of the above, I would not be surprised if Go is more popular especially for startups... alongside Linux, MySQL/Postgres, as well as other IDE or text editors. Sure.. I might agree that Visual Studio Code is suited for various programmers today.
Not suggesting you are wrong in any way. It's just the amount of money spent on Windows/Microsoft for small companies is rather large, compared to other alternatives that are just as good.
What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
I do my hobby .NET development in Zed and my serious work in Rider. .NET is open source and MIT licences. I do most of my development on a ARM MacBook Pro, or using my workstation which runs Fedora.
We deploy our code on kubernetes clusters usually on AWS.
All of the tooling, compiler, libraries etc are open source and cross platform and free. Not a single one of the developers in my team uses Windows or Visual Studio.
You know there are people.. programmers.. who are not C# developers... and likely refuse C# because of various reasons.. right? It can be based on the fact its Microsoft. My comment is based on startups and, from my experience, people like go all in on C# because decisions have been made to go all-in Microsoft.
C# has come a long way in the last 10 years. This much is clear, providing better support outside of the Windows ecosystem. However, many outside of the Windows/Microsoft ways are likely to be using languages like Go.
> What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
There was no C# in 1995.
(See it's easy attacking a sentence)
Silly me, using Rider (and VS Code) on Linux with C# (FastEndpoints and Dapper) with PostgreSQL...
Now the above is personal preference, while my day job is on Windows (also FE/Dapper) but with MS-SQL, which is because another group does DBA. I'm using VS Code for the work stuff though.
I'm at a series-C, YC startup. We made a switch from TypeScript to C# two months back. Now we have a team of over a dozen backend engineers working on C# transitioning from TypeScript. 90% are working with C# for the first time. (We are still hiring backend C# engs!)
I can say that it has gone waaaaaay smoother than anyone would have thought. This is a decision (language switch) that the team has been putting off for a long time and simply suffering through some big time jank and complexity with TypeScript (yes, TS at scale becomes complex in a very different way from C# because it becomes complex at the tooling layer in an "unbounded" way whereas C#'s language complexity is "bounded").
Indeed, I think more teams should give C# a shot. My own experience is that C# and TypeScript at a language level are remarkably alike[0] that if you know one well, you can probably quickly learn the other. But the C# ecosystem tooling is more cohesive, easier to grok, and less fickle compared to JS/TS (as is the case with Go, Java, etc. as well).
There still remains a lot of mis-perceptions about C# and .NET in general and I think that many startups should spend the time to give EF Core a shot and realize how every option in JS-land ends up feeling like a toy. EF Core itself is worth the price of admission, IMO.
I really liked working with C#. I spent 15 years or so with it and found it very productive. But no; I don’t miss the culture of C# / Microsoft shops at all.
Yea, but then the other end has to serialise the HTTP API stuf to a typed object on their end.
It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.
I think the key problem is that a large number of startups are shipping software in containers, and dotnet requiring a CLR is not particularly well-suited for containerization. It's like the old school Java JVM model. You have to ship a copy of the runtime with every container, and if you're doing proper microservices it's an awful lot of overhead.
Yes I'm aware MS makes it easy to build containers and even single executables, but languages that compile down to an ELF are pretty much a requirement once your deployments are over the 10k containers mark.
Nowadays it's very common to have .NET apps being containerized and running them on K8s or whatever you like in production -- I think you are relying on outdated information.
It's also well-suited for that. Of course, you won't end up with a tiny Go docker image, but this doesn't matter.
Just say you don't want to use .NET. It's fine, but how many startups ever get to over 10k containers? You can use AOT to further reduce the footprint. It's totally fine to hate Microsoft, but this is as weak an argument as I've ever seen.
> dotnet requiring a CLR is not particularly well-suited for containerization
This is a solved problem within csproj to do dotnet publish to OCI containers already. I even have some csproj override to magically add it to every console projects in the solution.
The biggest problem IMO is because of the JIT generated code not being able to be saved, so it will always be regenerated on the fly, and compound that with a not so state-of-the-art GC (wish we have ZGC someday), it will create brief moment of latency very easily and making the timing fat-tailed.
NativeAOT and ReadyToRun remedies this problem by compiling ahead of time, but you trade space with time.
If you use the same base image, is it really as bad as you're making it out to be?
I understand that you're getting a roughly 100mb dist directory for a .Net web app, and that it uses quite a bit of ram.. but people also use Node and Java which have similar issues.
Don't get me wrong on this, I'd like to use Rust+Axum a lot more and C# a bit less.. but I don't dislike C#.
You’re making the classic logical error of “your thing doesn’t have the workaround needed for an issue that only happens with my thing”.
You need 10K containers for Node and Python apps because they use a single threaded runtime! The best way to scale these is to deploy many small containers.
The .NET runtime is fully multithreaded and asynchronous and supports overlapped I/O. It scales to dozens of cores, maybe hundreds in a single process. The built in Kestrel server is full featured including HTTP/3 and TLS 1.3! You don’t even need NGINX in front of it.
Not to mention that unlike most Linux-centric programming languages, it deploys reliably and consistently without needing the crutch of containers. You can simply copy the files to a folder on the web server(s), and you’re done. I’ve actually never seen anyone bother with containers for an ASP.NET web app. There is very little actual benefit, unlike with other languages where it’s essentially the only way to avoid madness.
PS: Every Node app I’ve ever deployed has been many times slower to build and deploy than any ASP.NET app I’ve ever seen by an order of magnitude, containerised or not. Go is comparable to C# but is notably slower at runtime and a terrible language designed for beginners too inexperienced to grok how exceptions work.
> once your deployments are over the 10k containers mark.
Stackexchange famously is a dotnet application that runs on a handful of fairly (but not unreasonably) large computers. 10k containers is either "you are Facebook", or you're wasting a lot of that in some other way.
But startups aside, pretty much any company of significant size outside of the bay area/silicon valley is a Microsoft stronghold. It's an anomaly, not the norm, that so many companies in SV are on other stacks. Even for the non-tech workers (Google Docs vs. MS Office, macOS vs Windows endpoints, Slack vs. Teams, Okta vs. Entra ID or Active Directory, etc.).
When the entire enterprise's IT runs on Microsoft, you might as well pick an MS tech for the dev stack too.
> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.
I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.
Recommended by whom? I've been doing .NET for 23 years (since the first beta) and I've never paid for a single library in any commercial project I've been part of.
Easy to avoid depending on the area; I'd urge you not to be discouraged by the presence of commercial libraries. They aren't as vital as it may seem from the outside. I've been a full-time C# developer since the first open beta and I have only one (1) instance where I used a commercial library. That was 2002 and if we were doing it today, we wouldn't have needed that commercial library. I have never used a commercial C# library other than that one time. We have a tremendous supply of open source libraries in NuGet, just like every other language, and much more functionality built into the standard library than most languages have. We just also have commercial UI libraries and such. That commercial library we used was a docking/tabbing UI library; you can get that from open source packages now (and my later projects do).
Remember when people were selling COM objects in Dr Dobbs journal ads for Visual Basic in the 90s? I think it's the same culture (and partially people) that has been bought over to the .NET world via VB.NET as it was always touted as the stepping stone.
Nothing has ever forced anyone to depend on commercial libraries, there has been some upsets as people has closed-source previously popular opensource libraries.
But in the end, sometimes it feels like open-source in general is just waiting for a Jin-Tia moments everywhere, if people go commercial to prevent that happening that's just an indication that we've failed to create alternative ways of _living_ that can support open-source (this is probably most damning on companies that prides themselves on building on-top of opensource).
Heck, remember that tjholowaychuk created tons of (some popularly still used) npm packages early in the Node.JS lifecycle before first moving to go and then abandoning open source altogether.
I will pile on that I don't use any commercial libraries in .NET at all. Ironically, I do purchase a commercial library for front-end JavaScript.
I agree that the commercial library offerings seem much more "in your face" with .NET but I don't find the actual breadth and depth of the free and open source library situation to be that troubling. It certainly continues to get better every year.
.NET is very "batteries included" as well so you don't need a huge base-line of competing open source packages just to do "hello world".
This one was weird to me at first too, coming from Python.
Nowadays, the ones I use have reasonable licenses and pricing, like ImageSharp. Free until 1M gross revenue, cheap afterwards. I support this type of dual licensing wholeheartedly.
In the last 12-15 years, outside of imaging and PDF (and some office documents [0]) the only commercial .NET library I found worth it's salt was the the Devart Oracle client, if only because it sucked WAY less than the official one [1].
Yes, that includes UI frameworks. Honestly nowadays I'd just have an LLM help build my UI components, because every commercial UI component lib I've seen is never quite right to a shop I've worked at anyway and you see a bunch of kludges bolted on to make it work the way they want [2].
I guess maybe a list of the recommended libraries would help cause I'm a bit lost.
[0] - You can totally do Excel output from .NET without a commercial library, I know you used to be able to hack together a PDF output flow, Word docs well good luck dealing with that format...
[1] - Devart's lib was both x86 and x64. Oracle's you had to pick the right arch on build. And then make sure everything on the deployment chain was configured the same way, or deal with people forgetting and then burning cycles with broken stuff. That ROI on that alone was worth it to the org.
[2] - To be clear I try to avoid touching such UIs encountered, when I do I at least try to clean things up if possible... but often it's not which is why I have to bring it up.
I use .Net a lot as in Europe it's everywhere. I think it occupies the same niche in Europe as Java does in America. Startups, enterprise, you name it. Lots of jobs in London with it for Finance.
And in 20 years I've personally never needed a paid library. Maybe one company had bought Telerik back in the day? I've now built up multiple startups, some with millions of users.
The only thing I ever plugin that's not a MS library really are serilog, validation with FluentValidation, and a job server, usually Hangfire just because it's easy. Other than that, most people have good C# API clients. Oh and OAuth, though the popular one got baited and switched like you said.
The key difference is that the core libraries cover much more for .Net than most other languages. I'm constantly adding npm modules, but rarely nuget packages.
But the opensource/closed source bait and switch has happened a lot recently it does seem. Someone was blaming it on some failure of an open source initiative MS were running.
But one of the big frustrations sometimes is dealing with some American Koolaid company who thinks Erlang support is a priority but .Net isn't. No code examples, no officially supported library. Most recent example, IBM of all people (C-level insisting we use their cloud, ugh).
C# is pretty popular in the US as well in certain spaces... especially Govt or Banking and adjacent environments. Mostly line of business applications. I'd say Java is slightly more popular, but I never really liked Java's ecosystem ergonomics, though they're better today it's just not for me.
Similarly, I'm not a fan of "Enterprise" development regardless... I find a lot of .Net shops, like Jave, just create a lot of layers of indirection and abstraction that only lead to excess complexity, cost and difficulty in both maintenance and enhancement. The older I get, the more my mindset shifts to make things that are easy to replace without adding undue complexity or patterns.
The problem with enterprise apps is that they're usually wide but shallow. Which means a ton of classes that don't do a lot and managing class complexity is actually the biggest challenge.
So it's just a very different type of code and you can point at the language, but the reality is that it's the domain.
That's surprising. For the past two companies, all our library dependencies have been open-source. All our persistences, aws sdk, consul, kubernetes, github/bitbucket libraries, pdf generation, selenium testing, etc etc. I'd recommend giving C# another look, the proprietary stuff is mostly an artifact of back in 2015 when everyone was still on .NET Framework.
In my experience .NET/C# dwarfs pretty much any other framework in the SMB and there are WAY more software companies that aren't considered "startups" than those tagged as "startups".
I tried so many times to get into the .net ecosystem. I actually like f# have written a few toy things with it. but never could built anything substantial with it - as I would starting my own cement factory.
same as c# - seems asp.net comes with a lot of stuff - but to use that stuff a lot of ceremony is baked in.
with Ruby | Rails i'm one or two commands away from most things I need. I understand the language & the ecosystem.
I was somewhat recently attempting to help my manager get a C# dev environment set up. He was used to doing everything the C/Java/JavaScript/Python/almost-every-language-under-the-sun way, and avoiding the "Microsoft way" of doing things created so many roadblocks. I had no idea that over the previous ~20 years I had been practicing a C# compiler summoning ritual and had become incredibly good at it. From the start I recommended installing Rider, VS, or VSCode, and that's eventually what worked - but having to drink the kool aid to that extent is fucking absurd.
I personally won't be using it, given the choice, again. I don't like exceptions, but can live with them. I don't like null, but can live with it. Nuget is complete and utter garbage. You still have to resort to all forms of unreliable hacks in order to redirect it to a locally clone (and if you do use a feed to avoid that, good luck with getting the local cache to not be completely moronic).
(Look, it certainly didn't help that the project itself was heavily enterprisey because the developers hadn't kicked those habits)
One weird trick to avoiding nuget breakage: treat packages as immutable. If you need a new or local build of a package, you must bump the version number (use -alphaNNN or increment the patch number) for every rebuild.
Or, if you're trying to temporarily use a local source tree, swap out <PackageReference> for <ProjectReference>.
> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma
There are plenty of real issues that are not the enterprise stigma.
I built a backend web api this year with it and C# is fantastic. EF Core is truly one of the best ORMs I've ever used. That said, I regret that decision and won't be using it again for any new projects.
Honestly it looks like Microsoft is distracted and doesn't really know what to do with .NET. Everywhere you look there are tons of half baked projects like Blazor, Identity or Kiota and progress in .NET is super slow. It's probably going to get worse now with all the AI crap.
If you use LINQ and have ever used areay Contains youre about to find out it's not going to be smooth. They knew about this for a year but decided coercing to span in an expression tree despite it being invalid wasn't worth fixing.
As much as I love .NET. I would like to see the whole libraries ecosystem being sustainable again. A recent license changes from all my favorite libraries just made me hesitant using .NET for actually build a startup TBH
IMO, C# is just a somewhat better version of Java (low bar) w/ first class Windows API support. I can't see myself ever adopting it for any real work. F# on the other hand seems a pretty awesome, terse and expressive language. Unfortunately, it is very unpopular (yet still hangs around).
Had the privilege to be consistent on C# development against the tide. NuGet was pretty generous during the years and VS26 is catching up with the small VS code frontend page cousin.
As a person who looks always at Java and C sharp with curiosity, I am a bit divided.
For me C#'s value is obvious in the frontend and also games compared to Java (except for mobile, where Java can be used but Kotlin seems best).
But for the backend I always wonder if I should invest more on C# or Java as I go.
Also, it worries me that Java is a memory hog, which C# seems not to be. I like to have lean server-side software, to the point that my usual approach has been to use C++ paired with Capnproto, but if I had to go with something a bit more high-level for web work, I am not sure.
Currently I am investigating Clojure for non-critically-fast backend. It seems to be a lot of fun and since I am using https://fennel-lang.org/ (replacing part of my Lua code) and I expect https://jank-lang.org/ to become something at some point, maybe it is worth to stick to it?
How would someone that has more data than me compare Java vs C# in terms of performance as-in "what machine you need in the cloud" to do useful stuff, mainly for backend work, asynchronous, in terms of CPU and memory for both?
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.
To me, it's pretty much unbelievable that Microsoft introduces an agent framework while for JSON serializing third-party Newtonsoft is still the go-to.
Edit. I was not aware that the gap between System.Text.Json and Newtonsoft narrowed, take my comment with a grain of salt, please!
These improvements are really making me look forward to Unity finishing their CoreCLR conversion. I think this will be one of the more disruptive announcements once it's complete.
Think of it in terms of semantics. An object has certain properties that are immediately obvious and available: color, height, width and so on.
Properties in C# are for such values that are immediately available or at least extremely cheap to retrieve or form. Seeing a property tells me that getting the value is a very small op and has no side effects.
A method on the other hand is like asking/telling the object to do something that can take a bit of time and resources to do.
So if the value you are trying to read is expensive to get and isn't immediately available then the method approach works and as a developer I'll avoid making multiple calls to it unless absolutely necessary because the method is also a possible indication that it might change state.
That’s a good argument. I had not considered properties in those terms before, and have historically been skeptical of them in many languages.
I’m partly convinced now! I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
C# is a great language, it's now very modern and has the best parts of Typescript, while leaving out the bad ones.
It's also extremely fast and multi-platform.
It also doesn't have the fragmentation that Java or JVM langs has.
And it's also open source nowadays. I think Sillicon Valley hasn't caught up with those recent changes, I bet more startups would be using C# if they knew.
Every time I read about new .NET version improvements I always remember my attempt to get a job using this stack in my local job market (Greece), where .NET Framework is super prevalent, majorly used by classic companies that don't even give you a fair technical chance if you lack a degree, and the devs are considered to be a cost center.
I really, REALLY wish I was in another timeline where I could say in an interview "yes, I use Linux on my desktop and Rider for my IDE" without being seen as a traveler from outer space.
I enjoy working with modern C# way more than node.js but... that's it.
Somehow, .NET jobs seem be tied to waterfall processes ("but we are still agile, because we release two times a year"), requirements in OneNote, and a 5 kg Windows laptop.
> don't even give you a fair technical chance if you lack a degree, and the devs are considered to be a cost center.
I've never considered how lucky I am to live in the U.S. and to work at a company that absolutely sees the dev team to be a huge asset rather than another cost. The amount of time, money, stress we've saved by not allowing bad code to enter the code base.. I wouldn't have it any other way.
Also, I've had such great success hiring people without degrees. Truly some of our best contributors came from entirely different career paths. Same applies for some designers I work with.
Razor is still the "default" and "Razor Pages" has a different brand name, but just means "Razor with more things in the main .razor file and fewer code-behind .razor.cs files and less of an MVC approach".
Blazor mostly only matters if you want your frontend to also be Razor. At that point you've got the fork between Blazor using SignalR for HTML pipes from Razor files to the client versus Blazor running client-side in WASM with a Virtual DOM renderer based on Razor.
Blazor seems popular among some groups that want everything in C# rather than needing as much of a Typescript frontend. Blazor WASM bundles a full version of the CLR into WASM so mostly only popular in places where you don't need to optimize the initial web bundle.
Updated a pet project of mine and got a minor break:
var pixels = new uint[renderers.width * renderers.height];
var pixels2 = MemoryMarshal.Cast<uint, ulong>(pixels);
pixels2[idx] = ...
In NET9.0 pixels2 were Span<ulong>, but in NET10.0 a different MemoryMarshal.Cast overload is used and it is ReadOnlySpan<ulong> now, so the assignment fails.
Spans is such a fundamental tool for low level programming. It is really unfortunate they were added relatively late to the language. Now every new version includes a slew of improvements related to them but they will never be as good as if they were there from the start or at least as early as generics were.
Microsoft's Ubuntu image seems to be ready. I guess I could see a reason to use regular Ubuntu 24 and then install dotnet manually, but these images have served us well.
docker pull mcr.microsoft.com/dotnet/sdk:10.0 - Refers to Ubuntu 24.04 "Noble Numbat"
docker pull mcr.microsoft.com/dotnet/sdk:10.0-noble - Refers to Ubuntu 24.04 "Noble Numbat"
See the docs[1] where it mentions that 10 is supported, but not available in the built-in Ubuntu feed. It however is/should become available in the backports feed.
To make matters even more interesting the GitHub / Azure DevOps CI agent image Ubuntu 24.04 doesn't provide .NET 9, whereas 22.04 does[2]. .NET 10 appears to become available in both though[3].
I usually feel ambivalence with announcements of new C# versions.
Yes, a lot of great features have been added over the years. But it also introduces some amount of cognitive load and confusion. Take the first new feature in the example:
> Field-backed properties simplify property declarations by eliminating the need for explicit backing fields. The compiler generates the backing field automatically, making your code cleaner and more maintainable.
Huh, I thought we have had this for years, what were they called, ah Auto-Implemented Properties- so why is there a need for this? In this example:
// Automatic backing field with custom logic
public string Name
{
get => field;
set => field = value?.Trim() ?? string.Empty;
}
Ah so it's a way to access the backing field of Auto-Implemented Properties if you need more logic. And in the above can we just say:
get;
or do you need to refer to the field keyword explicitly in the getter if we use it in the setter?
I feel like the documentation is always somewhat lacking in explaining the reasoning behind new features and how it evolves the language from earlier versions.
Agreed. I feel like we're getting diminishing returns out of the language as they try to squeeze out every last keystroke (as though the challenge of software development is in the typing)
I'm thankful I've been along for the ride so I know the "archaeology" but pity those freshly dunked into its increasingly complicated ocean
How is .NET debugging on the command line? I don't use IDEs that often and last time I tried making something serious with .NET I couldn't find any kind of reliable debugger that I could just spin up and get to grips with. And I wasn't exactly very keen on switching from VS build tools to full VS just to debug .NET apps.
Why is EF regarded as such a good ORM? I've encountered countless bugs in different repos related to its stateful nature after many years in .NET. Personally I found it completely illogical for my ORM to maintain state. I just want it to hold my schema and build queries.
EF hits you in the face right at the start with the massive convenience that it provides. And then the paper cuts start adding up, and adding up, and adding up.
Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.
Could not agree more. Too many -- WAY too many -- "features" from Javascript and functional languages have been jammed into C#, and the language has suffered for it. Every time I see "var blah" in C# code I cringe at how lazy you must be to not use strong typing when declaring a variable.
Same goes for "astink / await". If you need asynchronous multi-threaded code, use the damned Thread Parallel Libraries that Microsoft provided over a decade ago. Being forced to have every damned thing you write in C# wrapped with astink is just one giant code smell.
Yes, I'm old. Thank ghod I'll be retiring very soon, because as far as I'm concerned the tooling and languages I've used over the past 50 years have taken one step forward and at least three steps back in the past five years...
If you take it in the context of the industry, I think async/await is the more imperative friendly option. It let's you write code sequentially without callbacks. And the performance gains are definitely worth it. I'll have to respectfully disagree
I don't think C# really has bloat — there is generally very little overlap between things they add, and each release they don't add a lot. This release's big thing was better extension method syntax and the ability to use "field" in properties. Each release is about that big, and I feel like the language is largely very easy to internalize and work in.
New features are often more likely to be semantic sugar instead of some new big thing.
IronScheme[0]! I was pretty happy to be able to expose async-await in a neat little library[1]. I wonder if it's in use anywhere. I didn't get to use it in the project I was working on at the time.
I HAVE FOUR WORDS FOR YOU: "I ... LOVE .. THIS .. COMPANY ... yeeeaaaahhhhhh1111"
Since Nadella took over, MS made some substantial steps forward: On Azure, around 30% is Linux; MS went cross platform with some of its most successful apps/ecosystems.
Its not that MS behaving like a friend today, but their Dev-tools are really great - at least they care for Devs, i wish they would care for Office users as well.
C# + .NET is from my perspective the most developed and most mature eco system when it comes to business applications.
Literally just started building a game engine with .NET 9, so naturally there's an update within a week. -_-
Seems like a good update, though! And I'm glad it's early enough that updating the framework probably shouldn't break anything. Really as long as there's no issues with the DearImGUI dependency (would be a surprise!), I'm pretty happy about the update.
127 comments
[ 0.28 ms ] story [ 117 ms ] threadWe 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.
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.
[0] I actually think VB.NET is the superior .Net language, but it lost support at MS and died. I think the code is vastly more readable (to me) than C-style code, and I've coded in every C, Java, C#, whatever variant.
It's a force multiplier when you have a small team of strong developers.
To the uneducated, C# is linked to Visual Studio.. the IDE.. and the Community edition if free as long as you are a student, open-source, and individuals. Professional and Enterprise are paid.
(Yes - there is Visual Studio Code)
Again, I am looking at this from the uneducated. With the above, as well as "going with other Microsoft products" things start to get more expensive. Need a database - should it be SQL Server? Should it be Windows Servers? etc.
Because of the above, I would not be surprised if Go is more popular especially for startups... alongside Linux, MySQL/Postgres, as well as other IDE or text editors. Sure.. I might agree that Visual Studio Code is suited for various programmers today.
Not suggesting you are wrong in any way. It's just the amount of money spent on Windows/Microsoft for small companies is rather large, compared to other alternatives that are just as good.
I do my hobby .NET development in Zed and my serious work in Rider. .NET is open source and MIT licences. I do most of my development on a ARM MacBook Pro, or using my workstation which runs Fedora.
We deploy our code on kubernetes clusters usually on AWS.
All of the tooling, compiler, libraries etc are open source and cross platform and free. Not a single one of the developers in my team uses Windows or Visual Studio.
C# has come a long way in the last 10 years. This much is clear, providing better support outside of the Windows ecosystem. However, many outside of the Windows/Microsoft ways are likely to be using languages like Go.
> What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
There was no C# in 1995. (See it's easy attacking a sentence)
Now the above is personal preference, while my day job is on Windows (also FE/Dapper) but with MS-SQL, which is because another group does DBA. I'm using VS Code for the work stuff though.
I can say that it has gone waaaaaay smoother than anyone would have thought. This is a decision (language switch) that the team has been putting off for a long time and simply suffering through some big time jank and complexity with TypeScript (yes, TS at scale becomes complex in a very different way from C# because it becomes complex at the tooling layer in an "unbounded" way whereas C#'s language complexity is "bounded").
Indeed, I think more teams should give C# a shot. My own experience is that C# and TypeScript at a language level are remarkably alike[0] that if you know one well, you can probably quickly learn the other. But the C# ecosystem tooling is more cohesive, easier to grok, and less fickle compared to JS/TS (as is the case with Go, Java, etc. as well).
There still remains a lot of mis-perceptions about C# and .NET in general and I think that many startups should spend the time to give EF Core a shot and realize how every option in JS-land ends up feeling like a toy. EF Core itself is worth the price of admission, IMO.
[0] https://typescript-is-like-csharp.chrlschn.dev/
And when the front-end is C#, it only makes sense to do the backend in .NET too so you can share classes easily.
It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.
Yes I'm aware MS makes it easy to build containers and even single executables, but languages that compile down to an ELF are pretty much a requirement once your deployments are over the 10k containers mark.
It's also well-suited for that. Of course, you won't end up with a tiny Go docker image, but this doesn't matter.
Why? I routinely put compiled .NET programs into containers.
It's also easy (easier than Rust even) to build on Mac targeting a Linux image.
This is a solved problem within csproj to do dotnet publish to OCI containers already. I even have some csproj override to magically add it to every console projects in the solution.
The biggest problem IMO is because of the JIT generated code not being able to be saved, so it will always be regenerated on the fly, and compound that with a not so state-of-the-art GC (wish we have ZGC someday), it will create brief moment of latency very easily and making the timing fat-tailed.
NativeAOT and ReadyToRun remedies this problem by compiling ahead of time, but you trade space with time.
I understand that you're getting a roughly 100mb dist directory for a .Net web app, and that it uses quite a bit of ram.. but people also use Node and Java which have similar issues.
Don't get me wrong on this, I'd like to use Rust+Axum a lot more and C# a bit less.. but I don't dislike C#.
You need 10K containers for Node and Python apps because they use a single threaded runtime! The best way to scale these is to deploy many small containers.
The .NET runtime is fully multithreaded and asynchronous and supports overlapped I/O. It scales to dozens of cores, maybe hundreds in a single process. The built in Kestrel server is full featured including HTTP/3 and TLS 1.3! You don’t even need NGINX in front of it.
Not to mention that unlike most Linux-centric programming languages, it deploys reliably and consistently without needing the crutch of containers. You can simply copy the files to a folder on the web server(s), and you’re done. I’ve actually never seen anyone bother with containers for an ASP.NET web app. There is very little actual benefit, unlike with other languages where it’s essentially the only way to avoid madness.
PS: Every Node app I’ve ever deployed has been many times slower to build and deploy than any ASP.NET app I’ve ever seen by an order of magnitude, containerised or not. Go is comparable to C# but is notably slower at runtime and a terrible language designed for beginners too inexperienced to grok how exceptions work.
Why?
Stackexchange famously is a dotnet application that runs on a handful of fairly (but not unreasonably) large computers. 10k containers is either "you are Facebook", or you're wasting a lot of that in some other way.
C# is extremely popular in Western/Northern Europe. (Sweden/Denmark/Germany ironically in particular).
These are real Microsoft strongholds.
But startups aside, pretty much any company of significant size outside of the bay area/silicon valley is a Microsoft stronghold. It's an anomaly, not the norm, that so many companies in SV are on other stacks. Even for the non-tech workers (Google Docs vs. MS Office, macOS vs Windows endpoints, Slack vs. Teams, Okta vs. Entra ID or Active Directory, etc.).
When the entire enterprise's IT runs on Microsoft, you might as well pick an MS tech for the dev stack too.
I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.
Nothing has ever forced anyone to depend on commercial libraries, there has been some upsets as people has closed-source previously popular opensource libraries.
But in the end, sometimes it feels like open-source in general is just waiting for a Jin-Tia moments everywhere, if people go commercial to prevent that happening that's just an indication that we've failed to create alternative ways of _living_ that can support open-source (this is probably most damning on companies that prides themselves on building on-top of opensource).
Heck, remember that tjholowaychuk created tons of (some popularly still used) npm packages early in the Node.JS lifecycle before first moving to go and then abandoning open source altogether.
I agree that the commercial library offerings seem much more "in your face" with .NET but I don't find the actual breadth and depth of the free and open source library situation to be that troubling. It certainly continues to get better every year.
.NET is very "batteries included" as well so you don't need a huge base-line of competing open source packages just to do "hello world".
Nowadays, the ones I use have reasonable licenses and pricing, like ImageSharp. Free until 1M gross revenue, cheap afterwards. I support this type of dual licensing wholeheartedly.
Are you looking at older materials?
I expect the baker who sells me his bread pays for the flour.
Yes, that includes UI frameworks. Honestly nowadays I'd just have an LLM help build my UI components, because every commercial UI component lib I've seen is never quite right to a shop I've worked at anyway and you see a bunch of kludges bolted on to make it work the way they want [2].
I guess maybe a list of the recommended libraries would help cause I'm a bit lost.
[0] - You can totally do Excel output from .NET without a commercial library, I know you used to be able to hack together a PDF output flow, Word docs well good luck dealing with that format...
[1] - Devart's lib was both x86 and x64. Oracle's you had to pick the right arch on build. And then make sure everything on the deployment chain was configured the same way, or deal with people forgetting and then burning cycles with broken stuff. That ROI on that alone was worth it to the org.
[2] - To be clear I try to avoid touching such UIs encountered, when I do I at least try to clean things up if possible... but often it's not which is why I have to bring it up.
And in 20 years I've personally never needed a paid library. Maybe one company had bought Telerik back in the day? I've now built up multiple startups, some with millions of users.
The only thing I ever plugin that's not a MS library really are serilog, validation with FluentValidation, and a job server, usually Hangfire just because it's easy. Other than that, most people have good C# API clients. Oh and OAuth, though the popular one got baited and switched like you said.
The key difference is that the core libraries cover much more for .Net than most other languages. I'm constantly adding npm modules, but rarely nuget packages.
But the opensource/closed source bait and switch has happened a lot recently it does seem. Someone was blaming it on some failure of an open source initiative MS were running.
But one of the big frustrations sometimes is dealing with some American Koolaid company who thinks Erlang support is a priority but .Net isn't. No code examples, no officially supported library. Most recent example, IBM of all people (C-level insisting we use their cloud, ugh).
Similarly, I'm not a fan of "Enterprise" development regardless... I find a lot of .Net shops, like Jave, just create a lot of layers of indirection and abstraction that only lead to excess complexity, cost and difficulty in both maintenance and enhancement. The older I get, the more my mindset shifts to make things that are easy to replace without adding undue complexity or patterns.
So it's just a very different type of code and you can point at the language, but the reality is that it's the domain.
What are free PDF generation/handling libraries in Java ecosystem what is their performance are they up to date and which licenses?
In my experience .NET/C# dwarfs pretty much any other framework in the SMB and there are WAY more software companies that aren't considered "startups" than those tagged as "startups".
same as c# - seems asp.net comes with a lot of stuff - but to use that stuff a lot of ceremony is baked in.
with Ruby | Rails i'm one or two commands away from most things I need. I understand the language & the ecosystem.
I personally won't be using it, given the choice, again. I don't like exceptions, but can live with them. I don't like null, but can live with it. Nuget is complete and utter garbage. You still have to resort to all forms of unreliable hacks in order to redirect it to a locally clone (and if you do use a feed to avoid that, good luck with getting the local cache to not be completely moronic).
(Look, it certainly didn't help that the project itself was heavily enterprisey because the developers hadn't kicked those habits)
Or, if you're trying to temporarily use a local source tree, swap out <PackageReference> for <ProjectReference>.
There are plenty of real issues that are not the enterprise stigma.
I built a backend web api this year with it and C# is fantastic. EF Core is truly one of the best ORMs I've ever used. That said, I regret that decision and won't be using it again for any new projects.
Honestly it looks like Microsoft is distracted and doesn't really know what to do with .NET. Everywhere you look there are tons of half baked projects like Blazor, Identity or Kiota and progress in .NET is super slow. It's probably going to get worse now with all the AI crap.
For me C#'s value is obvious in the frontend and also games compared to Java (except for mobile, where Java can be used but Kotlin seems best).
But for the backend I always wonder if I should invest more on C# or Java as I go.
Also, it worries me that Java is a memory hog, which C# seems not to be. I like to have lean server-side software, to the point that my usual approach has been to use C++ paired with Capnproto, but if I had to go with something a bit more high-level for web work, I am not sure.
Currently I am investigating Clojure for non-critically-fast backend. It seems to be a lot of fun and since I am using https://fennel-lang.org/ (replacing part of my Lua code) and I expect https://jank-lang.org/ to become something at some point, maybe it is worth to stick to it?
How would someone that has more data than me compare Java vs C# in terms of performance as-in "what machine you need in the cloud" to do useful stuff, mainly for backend work, asynchronous, in terms of CPU and memory for both?
So much DDD-this, Clean-that, CQRS-this, architecture-that.
I get all that stuff is for enterprise with bigger teams. But there wasn't much content/guidance on how to build apps 'quickly' for startups.
I am sure experienced .NET devs know this, but less experience .NET devs don't.
I ended up dropping it because I could work faster in PHP.
It helps that now most (if not all) parts of the stack are open source and run on Linux.
Don't know how trustworthy is this but it seems like it never was on top30: https://hnrankings.info/45888620/
This has 74 upvotes and posted 16hrs ago.. @dang?
I love C# and .NET and I use them extensively but I dislike the fact that the framework still kind of forces you into OOP.
If you like to have a more functional workflow you have to roll your own stuff or wrap objects in functional constructs.
But .NET is excellent for startups because:
-it is very fast to develop in
-has excellent tooling
-it is batteries included
-generally you have ONE way to do things that is accepted by most developers
-documentation is very good
-it supports large codebases with ease
-community is large enough
-you can use it for many areas, from embedded, to high performance computing, to desktop, mobile, web backend and web frontend
-it is performant
I wish CPP development was as robust as C# development is
Edit. I was not aware that the gap between System.Text.Json and Newtonsoft narrowed, take my comment with a grain of salt, please!
In a world obsessed with AI and web tech, this is a refreshing read!
Properties in C# are for such values that are immediately available or at least extremely cheap to retrieve or form. Seeing a property tells me that getting the value is a very small op and has no side effects.
A method on the other hand is like asking/telling the object to do something that can take a bit of time and resources to do.
So if the value you are trying to read is expensive to get and isn't immediately available then the method approach works and as a developer I'll avoid making multiple calls to it unless absolutely necessary because the method is also a possible indication that it might change state.
I’m partly convinced now! I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
C# is a great language, it's now very modern and has the best parts of Typescript, while leaving out the bad ones.
It's also extremely fast and multi-platform.
It also doesn't have the fragmentation that Java or JVM langs has.
And it's also open source nowadays. I think Sillicon Valley hasn't caught up with those recent changes, I bet more startups would be using C# if they knew.
What fragmentation? Honest question
It looks like they got someone from Apple to write their press release.
I really, REALLY wish I was in another timeline where I could say in an interview "yes, I use Linux on my desktop and Rider for my IDE" without being seen as a traveler from outer space.
I enjoy working with modern C# way more than node.js but... that's it.
I've never considered how lucky I am to live in the U.S. and to work at a company that absolutely sees the dev team to be a huge asset rather than another cost. The amount of time, money, stress we've saved by not allowing bad code to enter the code base.. I wouldn't have it any other way.
Also, I've had such great success hiring people without degrees. Truly some of our best contributors came from entirely different career paths. Same applies for some designers I work with.
.net462 baby!
More like 4.6.2
Razor is still the "default" and "Razor Pages" has a different brand name, but just means "Razor with more things in the main .razor file and fewer code-behind .razor.cs files and less of an MVC approach".
Blazor mostly only matters if you want your frontend to also be Razor. At that point you've got the fork between Blazor using SignalR for HTML pipes from Razor files to the client versus Blazor running client-side in WASM with a Virtual DOM renderer based on Razor.
Blazor seems popular among some groups that want everything in C# rather than needing as much of a Typescript frontend. Blazor WASM bundles a full version of the CLR into WASM so mostly only popular in places where you don't need to optimize the initial web bundle.
Spans is such a fundamental tool for low level programming. It is really unfortunate they were added relatively late to the language. Now every new version includes a slew of improvements related to them but they will never be as good as if they were there from the start or at least as early as generics were.
We force to use this workaround for now.
[1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Every since they got rid of the Microsoft packages feed, it's just been a complete mess.
Ubuntu's own documentation states:
> .NET 10 will be available in the Ubuntu archive for Ubuntu 24.04+ and included in main upon its official release
But it isn't available?
docker pull mcr.microsoft.com/dotnet/sdk:10.0 - Refers to Ubuntu 24.04 "Noble Numbat"
docker pull mcr.microsoft.com/dotnet/sdk:10.0-noble - Refers to Ubuntu 24.04 "Noble Numbat"
https://github.com/dotnet/dotnet-docker/discussions/6801
To make matters even more interesting the GitHub / Azure DevOps CI agent image Ubuntu 24.04 doesn't provide .NET 9, whereas 22.04 does[2]. .NET 10 appears to become available in both though[3].
[1]: https://learn.microsoft.com/en-gb/dotnet/core/install/linux-... [2]: https://github.com/actions/runner-images/issues/12697 [3]: https://github.com/actions/runner-images/pull/13295
Yes, a lot of great features have been added over the years. But it also introduces some amount of cognitive load and confusion. Take the first new feature in the example:
> Field-backed properties simplify property declarations by eliminating the need for explicit backing fields. The compiler generates the backing field automatically, making your code cleaner and more maintainable.
Huh, I thought we have had this for years, what were they called, ah Auto-Implemented Properties- so why is there a need for this? In this example:
Ah so it's a way to access the backing field of Auto-Implemented Properties if you need more logic. And in the above can we just say: or do you need to refer to the field keyword explicitly in the getter if we use it in the setter?I feel like the documentation is always somewhat lacking in explaining the reasoning behind new features and how it evolves the language from earlier versions.
You could have:
Or you could have: So you needed in the second case to also declare name as a field. The new syntax avoids having to do that "double" declaration.I'm thankful I've been along for the ride so I know the "archaeology" but pity those freshly dunked into its increasingly complicated ocean
Pros:
* Stability
* Very decent standard library
* Good balance between productivity and robustness
* Great package management
* Extremely easy to upgrade, so essentially free goodies (performance) every year or so
Cons:
* Very MSFT dominated (obviously)
* Subpar tooling outside of Windows (I'm looking at you C# Dev Kit)
* C# has way to many features, it feels bloated
* Culturally, it feels like .NET devs are less "passionate" about their work
* The freaking stigma of being a .NET dev: you will never be as cool as the guys who work with Node/Python/whatever
Edit: Also I'd like to add EFCore as one of the pros of the ecosystem. Hands down the best ORM. Others don't come close.
Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.
Could not agree more. Too many -- WAY too many -- "features" from Javascript and functional languages have been jammed into C#, and the language has suffered for it. Every time I see "var blah" in C# code I cringe at how lazy you must be to not use strong typing when declaring a variable.
Same goes for "astink / await". If you need asynchronous multi-threaded code, use the damned Thread Parallel Libraries that Microsoft provided over a decade ago. Being forced to have every damned thing you write in C# wrapped with astink is just one giant code smell.
Yes, I'm old. Thank ghod I'll be retiring very soon, because as far as I'm concerned the tooling and languages I've used over the past 50 years have taken one step forward and at least three steps back in the past five years...
If you take it in the context of the industry, I think async/await is the more imperative friendly option. It let's you write code sequentially without callbacks. And the performance gains are definitely worth it. I'll have to respectfully disagree
New features are often more likely to be semantic sugar instead of some new big thing.
[0] https://github.com/IronScheme/IronScheme
[1] https://github.com/IronScheme/IronScheme/pull/141
Since Nadella took over, MS made some substantial steps forward: On Azure, around 30% is Linux; MS went cross platform with some of its most successful apps/ecosystems. Its not that MS behaving like a friend today, but their Dev-tools are really great - at least they care for Devs, i wish they would care for Office users as well.
C# + .NET is from my perspective the most developed and most mature eco system when it comes to business applications.
I really like it!
Yup.
Seems like a good update, though! And I'm glad it's early enough that updating the framework probably shouldn't break anything. Really as long as there's no issues with the DearImGUI dependency (would be a surprise!), I'm pretty happy about the update.