> 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.
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".
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.
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).
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.
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.
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).
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.
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.
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.
For some reason, .NET is extremely popular outside of major tech hubs (notably in Europe), where you're much more likely to work for (without loss of generality) Ikea than for Google.
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.
.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.
> they can onboard people who know anything-not-C# and benefit from the .Net library
I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone.
People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference.
And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.
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.
As a counter-point, my company was original purely .NET, then added Python (and later JS).
For us, hiring .NET is WAY harder than the other stacks. We get a lot more applicants in general, but almost zero that meet our standards. For Python roles we get way fewer applicants, but the average quality is much much higher than the .NET average. (JS is a whole other thing, and we frankly aren't as good at hiring there yet)
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.
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.
> 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.
This is a complete mis-perception about the modern ecosystem.
We have a full team using C# at a series-C, YC startup with every developer on Macs (some on Beelinks and Linux). The team is using a mix of VS Code, Cursor, and Rider. We deploy to Linux container instances in GKE on Google Cloud running Postgres.
There is no more tie in to Microsoft licensing than there is say for TypeScript. Yes, C# DevKit is licensed like VS, but if you don't need the features, then you can also use DotRush or just use the free C# Extension.
> 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.
No it's not. What? Visual Studio is a shitty MS product that most decent C# devs already moved away from to JetBrains/vscode.
> Need a database - should it be SQL Server? Should it be Windows Servers? etc.
.NET runs on Linux just fine, there's also zero issues using Postgres or any other popular DB of your choice.
> there are many smaller companies (and startups) that may have concern paying for such tools.
There's literally nothing you would need to pay to work in .NET ecosystem. If a company rules out a language based on thoughts like yours, I genuinely believe they deserve to fail. Literally none of those things is true and it takes a minute or two to find all of that out.
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.
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.
> To the uneducated, C# is linked to Visual Studio.. the IDE..
Not native English - does "to the uneducated" means you are directing this sentence that knows no better or you are uneducated?
Because if it is former, you need to re-educate yourself.
C# is not linked to IDE. You can do `dotnet build`? Can run on Linux if you will. Database choice? You are NOT limited to SQL Server or Windows server.
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".
Yeah, but it's very likely you won't be working like a mule, or creating a bicycle with three wheels. How could oneself be innovative and top talent under such conditions?
> 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.
I'm the same. I'm both a Python and C# developer. I use Python for all my personal projects, and given the choice, for MOST projects I'll always pitch Python first, Django gives me the strengths of something like ASP .NET / EF Core, but without feeling like they're building more abandonware. I really love Blazor and heck even MAUI, but will they still be there in 10 years? Probably, will Microsoft have some new project that replaces them? probably.
Then there's Django. Rarely changes, only for the better. Upgrading Django versions is usually painless too. The ORM is fine enough.
I had high hopes for Blazor but it didn't really materialize. Instead I'm just sticking with Angular.
I don't think Microsoft doesn't know what to do with .NET. I think it continues on a very logical and direct path. But they have no idea what to do with UI on any platform. Luckily they haven't even deprecated any of the existing options and on the web, at least, you have all the same options as every other platform.
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.
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.
> 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.
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.
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.
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#.
> 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.
>startups should consider niche language with extremely limited hiring pool.
sure, but only if you're doing something that actually demands it - and actual innovation - instead of usual 'lets repackage XYZ as SaaS and growthhack' strategy.
Seeing that any startup is more likely than not to fail, why would I work for a company that is using a niche technology that isn’t going to be in demand when I look for my n+1 job?
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.
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?
As others have mentioned Vault, Keycloak, Flink are language agnostic. Regarding the switch from Java to .NET, I would rather recommend switching to Kotlin instead of .NET for a developer experience similar to C#, while still keeping your existing expertise in Java and its ecosystem.
And this comes from someone in a .NET shop currently, but have worked with Java before.
IMHO both languages and surrounding ecosystems are good. Both have their pros and cons and quirks.
Most of that ecosystem is language agnostic, or offer much more ergonomically sane APIs in dotnet. This is especially true for anything coming out of Google (e.g. Dataflow which runs on top of Apache Beam).
C# itself has way better DX (object initializers alone are worth the switch), and most language features don't feel bolted on like with Java (anything from functional programming to extension methods to whatever).
And at least 6 years ago .net with default settings required significantly less resources (RAM, CPU) and yad significantly faster startup than comparable Java code.
C# is also significantly more consistent. You might not use LINQ, but since everything is IEnumerable, you will use the same set of methods on everything. None of the Lis.of...Collectors.collect idiocy from Java.
I also found Asp.net to have significantly less undebuggable magic than Spring.
Vault, Keycloak, Flink are language agnostic or there exist bindings for most popular languages.
Documentation is vastly better compared to Java ones, it's like day and night, LINQ is vastly superior to anything that Java offered - but i haven't used java in a very long time. And every time i had to write java it felt like i went backwards in time by 5-10 years.
If i remember right Java's webserver beats ASP.NET in performance benchmarks but .net's one performance is good enough that it does not matter until you hit really big usercount - and at that point you usually have to rethink your architecture anyways.
But frankly .net is still mostly Microsoft Java but with better developer ergonomics in my opinion. It did shed a lot of overengineered OOP legacy from .net framework days though and we're seeing major performance improvements with every version.
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 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.
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?
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.
It is no coincidence that C# and TS are similar. They are created by the same person, Anders Hejlsberg. The C# language may have some baggage from back in the day, but at least it has a very good, non-fragmented ecosystem. While Typescript may have learned from some of C#'s mistakes, the js/ts ecosystem is a dumpster fire imho.
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'm a Ruby dev of almost 2 decades now doing C# and it's extremely fast to get a API with Swagger running from C#, a few mins tops. And this is if you spend just a little bit to learn it!
Of course, if you expect a full FE+BE 'omakase' framework like Rails there isn't anything with the same weight. I began to see this as a plus, you actually don't need it all, and nowadays it's very modern to delegate auth to a service etc. I know it isn't DHH's PoV, but it makes it much easier to maintain, so you focus on writing business logic and do the FE in a widely supported framework like React, or use Microsoft stuff, your choice.
The DTOs/DI and the typical .NET developer stuff isn't bad or hard to learn, most of it comes naturally when you think "What would a statically typed language need?"
It's what allows C# code be very clean and easy to follow, where you know exactly what is available unlike Ruby that a lot of things are implicit and can get very nasty. After so many years debugging and improving Rails apps performance, I got sick of it and C# feels fresh.
Then there's LINQ and a lot of language sugar that makes C# code really beautiful. I've done also some Java, and can easily vouch for C#. It's the Ruby of statically typed langs.
And the speed, don't get me started. It's so fast.
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).
> I can't see myself ever adopting it for any real work
Why not?
I see a lot of people saying they don't like it or won't use it but few of them list any reasons to, the ones that do raise issues from 20 years ago that have since been resolved.
Maybe you should give it a try, you'd be surprised how productive the language is and how comparatively unproductive all other languages and ecosystems are.
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
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.
One of the big features in .net 10 is the ability to do `dotnet file.cs` to run an application, with package import and assembly attributes directly in the file.
It is as simple as what you get with Cargo, and possibly even more readable.
.NET, unlike Go, has all needed management commands built into its CLI too: dotnet new {template}, dotnet add/remove package, dotnet sln add/remove, etc.
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)
>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.
What exactly does this mean? I haven't touched .NET in earnest in over 10 years. I know the ecosystem has evolved a lot since then, but I don't know how or in what ways
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'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.
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 work at a large enterprise where most of our backend js .NET and I can tell you that the dev team is nearly half and half split between Linux and Mac, and nearly half and half split on using VS Code and Rider.
Most of our code is deployed on Kubernetes and runs on AWS.
Developer experience means many things to different people. Personally for my most recent project, I used F# and the IDE was Rider and my OS was a form of immutable Fedora (Ublue OS) with devpod and devcontainers and the whole system was the most joyous developer experience I think I have ever had.
I use rider on Mac (and windows to be fair) and i think the experience is better than visual studio on windows.
My biggest gripe with dotnet tooling is dotnet format. It’s not quick enough to use on a pre commit hook, so people don’t run it regularly and we get failures for it.
It’s such a small nit, dotnet is a great environment to work in
Most of the newer features make C# less cumbersome to use. I can't imagine using the language from ten years ago, in fact the first thing I do when working on a legacy app is to set langVersion=latest.
Sometimes less is more. It very easy for devs to use the language in completely different ways. I lean towards Go style in that regard. My ideal language would be like Go + Linq.
I've heard this argument before from the perspective of C# having more keywords and language features to be aware of than something else (in my particular argument, the other side was Java).
From this perspective, I can't say I disagree as such. If you look at the full set of language features, it sure is a lot of stuff to know about. The argument that it is too much, and that we should sacrifice expressiveness and signal to noise ratio in the code to keep the language simpler, I don't agree with.
> * Culturally, it feels like .NET devs are less "passionate" about their work
Only in the "stove pipe industry" as we say here. Mobile gaming is massively C#-based for example and the people are really passionate about what they do.
And for a backend dev, the scale of stuff you get to work with is cool.
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.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
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#.
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.
It’s funny, I came up in my career working in places mixed with .NET and PHP/JavaScript devs and the .NET developers all felt the PHP/JS teams were clown cars.
IMO had .NET Core come out a few years earlier it would have a much bigger marketshare today, but when you had Ruby/PHP/Node/Python devs primarily using Macs, no one wanted to touch the thing.
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
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.
Where is this worry coming from? (I'm curious, not shutting it down)
I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?
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.
> 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.
A bit off-topic, bit hiring exceptional .NET developers is like searching for a needle in a haystack. Way more people have a ton of experience with JS and marginal experience with .NET, just writing very basic API endpoints - yet claiming serious experience.
If you came to me for an interview, your story would have been a breath of fresh air. So maybe try to mention it anyway, someone will be interested.
I've managed big .Net teams. 99% of .Net devs are very, very average. Just crunching out lines of code with little care for quality, performance, readability etc. The best .Net dev I ever hired didn't know a single thing about it; brought him in as the most junior role to tinker with some HTML and within two years he had massively outclassed me.
> 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.
Could you please elaborate? Are you referring to most .NET shops not straying away from Windowsland?
It's not about what the company uses, but how informed the technical people responsible for hiring candidates are around the ecosystem they claim they work with.
Example:
Expected: "Oh, you're on Linux? I heard about Rider. We use Windows and Visual Studio here for parity. You're okay with that, right?" (me: Obviously, tools are tools)
Actual: "Does .NET run on Linux? What is Rider?"
I mean, .NET has been running on Linux since forever now (11 years according to https://news.ycombinator.com/item?id=9459513, let's say about 9 for stability because I feel generous). How do they not know about 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.
Basically, you can now write scripts in C# without the ceremony of a solution or project file — writing some code in a cs file and running `dotnet run myFile.cs`will execute the file directly.
You can also shebang to make it directly executable!
Hoping this inspires more people to give C# a go — it's incredible these days. Come in, the water is fine.
That's how I learned C in the 80s. Just compile the C file into an EXE. It's a good way to get started.
That said, I'm certain you've always been able to simple compile a .cs to an .exe? When I ran guerilla C# programming classes in jail, I couldn't get anything from the outside, so I was stuck with the .Net v2 csc.exe which is squirreled away in a subfolder of Windows on a default install of Visa.
What .Net 10 adds though is the ability to even scrap main() and just write code like it was Basic.
You've needed to have a project file in the past to compile .cs files, and this gets rid of that need. There are things that are part of more esoteric corners of Roslyn like .csx files that have allowed similar behavior in the past, but this fronts .cs directly as a scripting solution.
Scraping main() has been a thing for a while in dotnet — so called "Top-level programs" have be in since C# 9/.NET 5, aka about 5 years ago.
Meanwhile, I recently proposed doing the work of updating the runtime versions from .netframework over to even .net5+ to save $millions/quarter.
I ran benchmarks, showing 2-10x+ improvements.
Got told, “lol no, this service is unlike Bing”. For context, Bing has amazing blogs on this*.
This, btw is inside networking for Azure…
Not sure at what point I should stop caring. Could easily improve operating expenses to the tune of hundreds/billions per year if they applied this across Azure.
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.
I really like C#, but I wouldn't go that far - unions are at least on the horizon, but I've sometimes come to miss the power and flexibility of TS's structural typing...(And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc :) )
>And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc
It was more related to the fact that the existing TS code was more easily ported to Go, and also .NET AOT wasn't mature enough at that time. Structural typing has its own problems. I'm personally not a big fan of it.
Might be my own taste, but except a few of the common and easy to understand structural typing code, I find it sometimes actually make things needlessly complex.
I also write lots of Typescript, and the furthest I go is to use 'Omit' and other utility types, but already feel like it's too much.
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.
Why C# doesn't have first class functions and can't go fully functional (and likely never will): Scala tried and its compiler is slow, even after so many iterations and new novel compiler ideas.
I like the way it is, and hope it doesn't change. Unless they could make this possible without making the compile process extremely slow.
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.
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].
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"
They are very different beasts.. What problems are you having with CPP that you're not with C# ? Funny enough a lot of the 'ecosystem' is on the back of cpp..
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.
For most projects, upgrading between .NET version is quick and painless, usually just updating the TargetFramework and NuGet packages in your .csproj file.
That's... a strong statement. There is absolutely nothing wrong with going with a non-LTS version. You just have to update a little bit sooner, and that's it.
I do! Pretty sad that IronPython isn’t a thing anymore, especially now that I’ve actually had to learn Python for machine-learning related reasons. At least .net did get the dynamic data type out of its brief interest in these.
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.
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.
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.
Isn't the official .NET debugger only allowed to be used from Visual Studio and VSC? I recall Jetbrains had to remove debugging support from their IDE for a while due to that license. Also the whole kerfuffle around hot reloading first being added to .NET (Core) and then the code being deleted because it was supposed to be a VS-only feature.
These things to me seem like one faction in MSFT wants .NET to be an open platform and another faction wants it to be a sales funnel for Visual Studio.
I think I tried that (or a derivative of it, didn't know Samsung was the primary developer) that broke in some very very weird ways. Will try this version, thanks!
If you have a build command that does not specify version for things like 'dontnet-ef', your build might fail because it is not compatible in .NET 10, so update to specify version, e.g.
Apart from [the equivalent of] records, I see nothing big.
Except...
this '''let! a = fetchA() and! b = fetchB()''' really puzzles me. Does C# have a high-level syntax for concurrency timing? [something that Java is strongly lacking, and that Typescript did solve with Promise.all(), which is an ugly syntax, from my perspective]
The inlining and escape analysis changes are fairly big from a performance perspective.
Also, C# doesn't need nearly as many massive changes like project Valhalla because they got a lot of those design choices right from day 1 (mostly by looking at what Java did that was dumb and avoiding it).
As others point out, that's F#, but yes C# has `async`/`await`, and has all the `Promise` methods, just under the `Task` class instead (and with slightly different names/calling conventions through out).
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!
The go-to nowadays is System.Text.Json, developed by the same person as Newtonsoft.Json, built in to .NET.
Newtonsoft.Json as the primary JSON serializer (at least in every place I've worked) has NOT been the case versus System.Text.Json for years. Though it certainly used to be the case.
Haven't touched the newtonsoft package since .net core 3 / or about 5 years go? Something like that. Its not really getting updates and its huge/slow compare to built in one. The built in one is much better these days and plays well with other subsystems in aspnet.
Last I checked they stubbornly insisted on reinventing the wheel and ignoring everything in System.Runtime.Serialization so you had to redecorate everything with their new attributes. For example https://github.com/dotnet/runtime/issues/29975. So we stuck with Newtonsoft for the time being.
.NET has to win the title for worst naming. If you didn't know what it was, this announcement makes no sense whatsoever. All you would guess is there are probably 9 others that were just like it.
> All you would guess is there are probably 9 others that were just like it.
Lol, even this is not true. For the current runtime/stdlib package known as ".NET", they started numbering at 5. The actual sequence (only counting major version numbers) is: .net framework 1, 2, 3, 4, .net core 1, 2, 3, .net 5, 6, 7, 8, 9, 10. Easily the worst naming/version history for any product (worse than Windows).
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.
> The new syntax avoids having to do that "double" declaration.
Yes, that's right. It is in other words a way to access the compile-time generated backing field for auto-implemented properties. It is quite nice to be honest, I just wish they presented a bit of context in their announcements.
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
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.
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.
> 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.
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".
17 replies →
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.
2 replies →
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).
4 replies →
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.
26 replies →
What libraries are you referring to? I really haven't used any commercial libraries at all since the .Net Core transition (and .Net 5+ as a result).
Are you looking at older materials?
4 replies →
This site is full of people dreaming of making money off of software but refusing to pay for any software.
Silly question. If you want the C# experience but more community/OSS driven… why not Java?
23 replies →
What is wrong with paying for something that is useful?
1 reply →
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.
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).
2 replies →
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.
Is there equivalent of MassTransit in Java that works so well that you mostly can just use it with RabbitMQ and not worry much?
What are free PDF generation/handling libraries in Java ecosystem what is their performance are they up to date and which licenses?
Security and quality aside, I feel that npm have a larger selection of libraries.
4 replies →
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.
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.
> Both startups are based in the Dallas, TX area.
Aah that explains it.
For some reason, .NET is extremely popular outside of major tech hubs (notably in Europe), where you're much more likely to work for (without loss of generality) Ikea than for Google.
3 replies →
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.
At my current workplace we use a mix of on premise servers and Azure but at former workplaces we deployed to Google Cloud and AWS.
.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.
> they can onboard people who know anything-not-C# and benefit from the .Net library
I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone.
People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference.
And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.
31 replies →
You can also compile to wasm I believe
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.
As a counter-point, my company was original purely .NET, then added Python (and later JS).
For us, hiring .NET is WAY harder than the other stacks. We get a lot more applicants in general, but almost zero that meet our standards. For Python roles we get way fewer applicants, but the average quality is much much higher than the .NET average. (JS is a whole other thing, and we frankly aren't as good at hiring there yet)
3 replies →
[flagged]
7 replies →
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.
> culture of C# / Microsoft shops at al
What do you mean?
30 replies →
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.
This is a complete mis-perception about the modern ecosystem.
We have a full team using C# at a series-C, YC startup with every developer on Macs (some on Beelinks and Linux). The team is using a mix of VS Code, Cursor, and Rider. We deploy to Linux container instances in GKE on Google Cloud running Postgres.
There is no more tie in to Microsoft licensing than there is say for TypeScript. Yes, C# DevKit is licensed like VS, but if you don't need the features, then you can also use DotRush or just use the free C# Extension.
4 replies →
> Need a database - should it be SQL Server?
"I am using Java. Need a database - should it be Oracle?"
.NET Core 1.0 was released almost a _decade_ ago.
4 replies →
No it's not. What? Visual Studio is a shitty MS product that most decent C# devs already moved away from to JetBrains/vscode.
.NET runs on Linux just fine, there's also zero issues using Postgres or any other popular DB of your choice.
There's literally nothing you would need to pay to work in .NET ecosystem. If a company rules out a language based on thoughts like yours, I genuinely believe they deserve to fail. Literally none of those things is true and it takes a minute or two to find all of that out.
1 reply →
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.
3 replies →
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.
> To the uneducated, C# is linked to Visual Studio.. the IDE..
Not native English - does "to the uneducated" means you are directing this sentence that knows no better or you are uneducated?
Because if it is former, you need to re-educate yourself.
C# is not linked to IDE. You can do `dotnet build`? Can run on Linux if you will. Database choice? You are NOT limited to SQL Server or Windows server.
1 reply →
> I wish .NET was more popular among startups
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".
Yeah, but it's very likely you won't be working like a mule, or creating a bicycle with three wheels. How could oneself be innovative and top talent under such conditions?
3 replies →
> 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.
> That said, I regret that decision and won't be using it again for any new projects.
Genuinely curious, why?
> 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.
Hmm...there appears to be an interesting story and/or reason there...care to share?
I'm the same. I'm both a Python and C# developer. I use Python for all my personal projects, and given the choice, for MOST projects I'll always pitch Python first, Django gives me the strengths of something like ASP .NET / EF Core, but without feeling like they're building more abandonware. I really love Blazor and heck even MAUI, but will they still be there in 10 years? Probably, will Microsoft have some new project that replaces them? probably.
Then there's Django. Rarely changes, only for the better. Upgrading Django versions is usually painless too. The ORM is fine enough.
1 reply →
>Everywhere you look there are tons of half baked projects like Blazor
We used Blazor years ago and it worked flawlessly already then. Hard to believe it's worse today. And what's wrong with Identity?
>progress in .NET is super slow
Compared to what?
4 replies →
I had high hopes for Blazor but it didn't really materialize. Instead I'm just sticking with Angular.
I don't think Microsoft doesn't know what to do with .NET. I think it continues on a very logical and direct path. But they have no idea what to do with UI on any platform. Luckily they haven't even deprecated any of the existing options and on the web, at least, you have all the same options as every other platform.
5 replies →
Just stick with the classic frameworks. Razor works great as does MVC WebAPI
3 replies →
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.
> dotnet requiring a CLR is not particularly well-suited for containerization
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.
6 replies →
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.
> 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.
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.
A million different Javascript and Python services in delivered as Docker images would like a chance to disagree with you.
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.
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#.
5 replies →
> 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.
> ...languages that compile down to an ELF are pretty much a requirement once your deployments are over the 10k containers mark.
Why?
Exactly this point.
Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.
18 replies →
Meh. Probably 100x more startups use Python and JavaScript than anything else combined.
Start-ups should strongly consider F#.
It's a force multiplier when you have a small team of strong developers.
>startups should consider niche language with extremely limited hiring pool.
sure, but only if you're doing something that actually demands it - and actual innovation - instead of usual 'lets repackage XYZ as SaaS and growthhack' strategy.
11 replies →
Seeing that any startup is more likely than not to fail, why would I work for a company that is using a niche technology that isn’t going to be in demand when I look for my n+1 job?
2 replies →
F# seems really awesome. Used it briefly for an internal tool. Are you at a startup working with it?
4 replies →
C# is massive in (mobile) gaming because of Unity.
And when the front-end is C#, it only makes sense to do the backend in .NET too so you can share classes easily.
I only partly agree with you... if you're talking a web api, then code generation can go a long way with an OpenAPI doc file.
2 replies →
> I wish .NET was more popular among startups
C# is extremely popular in Western/Northern Europe. (Sweden/Denmark/Germany ironically in particular).
These are real Microsoft strongholds.
Australia too.
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.
As a startup I tried .NET (it was .NET 8), and it was great. The problem was the education around .NET.
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.
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?
As others have mentioned Vault, Keycloak, Flink are language agnostic. Regarding the switch from Java to .NET, I would rather recommend switching to Kotlin instead of .NET for a developer experience similar to C#, while still keeping your existing expertise in Java and its ecosystem. And this comes from someone in a .NET shop currently, but have worked with Java before. IMHO both languages and surrounding ecosystems are good. Both have their pros and cons and quirks.
Most of that ecosystem is language agnostic, or offer much more ergonomically sane APIs in dotnet. This is especially true for anything coming out of Google (e.g. Dataflow which runs on top of Apache Beam).
C# itself has way better DX (object initializers alone are worth the switch), and most language features don't feel bolted on like with Java (anything from functional programming to extension methods to whatever).
And at least 6 years ago .net with default settings required significantly less resources (RAM, CPU) and yad significantly faster startup than comparable Java code.
C# is also significantly more consistent. You might not use LINQ, but since everything is IEnumerable, you will use the same set of methods on everything. None of the Lis.of...Collectors.collect idiocy from Java.
I also found Asp.net to have significantly less undebuggable magic than Spring.
6 replies →
Vault, Keycloak, Flink are language agnostic or there exist bindings for most popular languages.
Documentation is vastly better compared to Java ones, it's like day and night, LINQ is vastly superior to anything that Java offered - but i haven't used java in a very long time. And every time i had to write java it felt like i went backwards in time by 5-10 years.
If i remember right Java's webserver beats ASP.NET in performance benchmarks but .net's one performance is good enough that it does not matter until you hit really big usercount - and at that point you usually have to rethink your architecture anyways.
But frankly .net is still mostly Microsoft Java but with better developer ergonomics in my opinion. It did shed a lot of overengineered OOP legacy from .net framework days though and we're seeing major performance improvements with every version.
13 replies →
Yes.
Startups typically have the tech stack that the one man army tech co-founder set up on no budget. Apparently then .NET isn’t too popular for that!
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 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.
I wish people stopped conflating web programming with the whole realm of software development.
19 replies →
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.
25 replies →
What are the cross-stack gains of Python?
Running TypeScript on the server is a well trodden path. It can be pretty fast too. Python on the client, not so much.
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?
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.
[0] https://typescript-is-like-csharp.chrlschn.dev/
It is no coincidence that C# and TS are similar. They are created by the same person, Anders Hejlsberg. The C# language may have some baggage from back in the day, but at least it has a very good, non-fragmented ecosystem. While Typescript may have learned from some of C#'s mistakes, the js/ts ecosystem is a dumpster fire imho.
So should I learn C# by learning Typescript? Does that make sense?
2 replies →
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'm a Ruby dev of almost 2 decades now doing C# and it's extremely fast to get a API with Swagger running from C#, a few mins tops. And this is if you spend just a little bit to learn it!
Of course, if you expect a full FE+BE 'omakase' framework like Rails there isn't anything with the same weight. I began to see this as a plus, you actually don't need it all, and nowadays it's very modern to delegate auth to a service etc. I know it isn't DHH's PoV, but it makes it much easier to maintain, so you focus on writing business logic and do the FE in a widely supported framework like React, or use Microsoft stuff, your choice.
The DTOs/DI and the typical .NET developer stuff isn't bad or hard to learn, most of it comes naturally when you think "What would a statically typed language need?"
It's what allows C# code be very clean and easy to follow, where you know exactly what is available unlike Ruby that a lot of things are implicit and can get very nasty. After so many years debugging and improving Rails apps performance, I got sick of it and C# feels fresh.
Then there's LINQ and a lot of language sugar that makes C# code really beautiful. I've done also some Java, and can easily vouch for C#. It's the Ruby of statically typed langs.
And the speed, don't get me started. It's so fast.
Agreed... 2 -> 3 was probably the most cumbersome for me, and 3 -> 5 had a few hiccups. But since 6, I haven't seen any huge issues.
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).
> I can't see myself ever adopting it for any real work
Why not?
I see a lot of people saying they don't like it or won't use it but few of them list any reasons to, the ones that do raise issues from 20 years ago that have since been resolved.
Maybe you should give it a try, you'd be surprised how productive the language is and how comparatively unproductive all other languages and ecosystems are.
1 reply →
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.
That's pretty vague. Do you have links to any articles or bug reports explaining the issue clearly?
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
I would also like to see the whole ecosystem being sustainable, financially :)
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.
Yeah I've been using non-.Net languages this week, and lamenting how much they suck in regards to smooth version management
The XML/config side of things just isn't for everyone. Sometimes Go's simplicity wins out.
One of the big features in .net 10 is the ability to do `dotnet file.cs` to run an application, with package import and assembly attributes directly in the file.
It is as simple as what you get with Cargo, and possibly even more readable.
.NET, unlike Go, has all needed management commands built into its CLI too: dotnet new {template}, dotnet add/remove package, dotnet sln add/remove, etc.
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)
>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.
What exactly does this mean? I haven't touched .NET in earnest in over 10 years. I know the ecosystem has evolved a lot since then, but I don't know how or in what ways
1 reply →
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>.
Just install the .NET SDK, and you’re ready to go.
> 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
How so, you can use a nuget.config in your project and use your local packages fairly easy, seems in part with npm and the likes.
3 replies →
Isn't it just a single file installation?
2 replies →
[dead]
too much microsoft
agree, but it lost the battle when windows was an exclusive platform for it, even when mono was rising in popularity
> 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.
1 reply →
Rider is your option there, it's better than Visual Studio (I used to work on VS).
10 replies →
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.
1 reply →
I have a much better dev experience on Linux/Rider than on Windows/VS.
I work at a large enterprise where most of our backend js .NET and I can tell you that the dev team is nearly half and half split between Linux and Mac, and nearly half and half split on using VS Code and Rider.
Most of our code is deployed on Kubernetes and runs on AWS.
Developer experience means many things to different people. Personally for my most recent project, I used F# and the IDE was Rider and my OS was a form of immutable Fedora (Ublue OS) with devpod and devcontainers and the whole system was the most joyous developer experience I think I have ever had.
1 reply →
I saw a number of key .NET team members use Rider in Youtube videos.
I've worked with .NET for over 10 years and we built our startup on top of it. Here are my thoughts:
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.
I use rider on Mac (and windows to be fair) and i think the experience is better than visual studio on windows.
My biggest gripe with dotnet tooling is dotnet format. It’s not quick enough to use on a pre commit hook, so people don’t run it regularly and we get failures for it.
It’s such a small nit, dotnet is a great environment to work in
Off topic but what is the name supposed to reference with Rider? I get that it’s a play on “writer” but what does riding have to do with anything?
2 replies →
Dotnet format is truly slow and bad. I wish the team focused on improving it, and working on better LSP support
1 reply →
* C# has way to many features, it feels bloated
Most of the newer features make C# less cumbersome to use. I can't imagine using the language from ten years ago, in fact the first thing I do when working on a legacy app is to set langVersion=latest.
Sometimes less is more. It very easy for devs to use the language in completely different ways. I lean towards Go style in that regard. My ideal language would be like Go + Linq.
I've heard this argument before from the perspective of C# having more keywords and language features to be aware of than something else (in my particular argument, the other side was Java).
From this perspective, I can't say I disagree as such. If you look at the full set of language features, it sure is a lot of stuff to know about. The argument that it is too much, and that we should sacrifice expressiveness and signal to noise ratio in the code to keep the language simpler, I don't agree with.
> * Culturally, it feels like .NET devs are less "passionate" about their work
Only in the "stove pipe industry" as we say here. Mobile gaming is massively C#-based for example and the people are really passionate about what they do.
And for a backend dev, the scale of stuff you get to work with is cool.
Unity C# is arguably its own thing.
The way you use C# is much different than anywhere else. The Unity implementation lags by a few versions. It’s an awesome language though
Anecdotal opinion , but as someone who works in Node and JS land a lot of the time. I think .NET is pretty cool.
.NET Core and ASP.NET Core (especially the minimal APIs) seem to have taken a lot of influence from Node API libraries like Express.
I've personally found Rider to be a great IDE for .NET development outside of Windows.
It’s also a great IDE for .NET development on Windows.
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.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
2 replies →
EF or EFCore? Specifically EFCore is highly regarded whereas legacy EF not so much.
EF Core is amazing -- in it's default setup it works for 99% of situation. For the 1%, you can basically turn off everything you don't want.
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#.
2 replies →
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.
It’s funny, I came up in my career working in places mixed with .NET and PHP/JavaScript devs and the .NET developers all felt the PHP/JS teams were clown cars. IMO had .NET Core come out a few years earlier it would have a much bigger marketshare today, but when you had Ruby/PHP/Node/Python devs primarily using Macs, no one wanted to touch the thing.
> C# has way to many features, it feels bloated
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...
> "astink / await"
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
Sorry, but var in C# is type inference, not dynamic typing, AFAIK. It's as strongly typed as a long-form declaration.
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.
I really like F# (as I like OCaml, Elm and Haskell); but I'm always afraid MS will kill it one day.
It helps that now most (if not all) parts of the stack are open source and run on Linux.
Where is this worry coming from? (I'm curious, not shutting it down)
I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?
10 replies →
C# Dev Kit, which VSCode pressures you to install, is a core very non-free component.
1 reply →
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.
> 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.
A bit off-topic, bit hiring exceptional .NET developers is like searching for a needle in a haystack. Way more people have a ton of experience with JS and marginal experience with .NET, just writing very basic API endpoints - yet claiming serious experience.
If you came to me for an interview, your story would have been a breath of fresh air. So maybe try to mention it anyway, someone will be interested.
I've managed big .Net teams. 99% of .Net devs are very, very average. Just crunching out lines of code with little care for quality, performance, readability etc. The best .Net dev I ever hired didn't know a single thing about it; brought him in as the most junior role to tinker with some HTML and within two years he had massively outclassed me.
> 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.
Could you please elaborate? Are you referring to most .NET shops not straying away from Windowsland?
It's not about what the company uses, but how informed the technical people responsible for hiring candidates are around the ecosystem they claim they work with.
Example:
Expected: "Oh, you're on Linux? I heard about Rider. We use Windows and Visual Studio here for parity. You're okay with that, right?" (me: Obviously, tools are tools)
Actual: "Does .NET run on Linux? What is Rider?"
I mean, .NET has been running on Linux since forever now (11 years according to https://news.ycombinator.com/item?id=9459513, let's say about 9 for stability because I feel generous). How do they not know about it?
3 replies →
You should try to get a job in Azure, you’d feel right at home!
.net462 baby!
More like 4.6.2
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.
What an absolute load of bullshit.
Something great about this release as well is the release of "file-based apps"
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
Basically, you can now write scripts in C# without the ceremony of a solution or project file — writing some code in a cs file and running `dotnet run myFile.cs`will execute the file directly.
You can also shebang to make it directly executable!
Hoping this inspires more people to give C# a go — it's incredible these days. Come in, the water is fine.
That's how I learned C in the 80s. Just compile the C file into an EXE. It's a good way to get started.
That said, I'm certain you've always been able to simple compile a .cs to an .exe? When I ran guerilla C# programming classes in jail, I couldn't get anything from the outside, so I was stuck with the .Net v2 csc.exe which is squirreled away in a subfolder of Windows on a default install of Visa.
What .Net 10 adds though is the ability to even scrap main() and just write code like it was Basic.
You've needed to have a project file in the past to compile .cs files, and this gets rid of that need. There are things that are part of more esoteric corners of Roslyn like .csx files that have allowed similar behavior in the past, but this fronts .cs directly as a scripting solution.
Scraping main() has been a thing for a while in dotnet — so called "Top-level programs" have be in since C# 9/.NET 5, aka about 5 years ago.
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
1 reply →
Meanwhile, I recently proposed doing the work of updating the runtime versions from .netframework over to even .net5+ to save $millions/quarter.
I ran benchmarks, showing 2-10x+ improvements.
Got told, “lol no, this service is unlike Bing”. For context, Bing has amazing blogs on this*.
This, btw is inside networking for Azure…
Not sure at what point I should stop caring. Could easily improve operating expenses to the tune of hundreds/billions per year if they applied this across Azure.
https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-c...
It’s exciting to see so much deep computer science that’s gone into optimising the language / JIT / GC / etc (inc. utilising hardware advances).
In a world obsessed with AI and web tech, this is a refreshing read!
Changed from Ruby to .NET and loving it.
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.
>and has the best parts of Typescript
I really like C#, but I wouldn't go that far - unions are at least on the horizon, but I've sometimes come to miss the power and flexibility of TS's structural typing...(And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc :) )
>And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc
It was more related to the fact that the existing TS code was more easily ported to Go, and also .NET AOT wasn't mature enough at that time. Structural typing has its own problems. I'm personally not a big fan of it.
Might be my own taste, but except a few of the common and easy to understand structural typing code, I find it sometimes actually make things needlessly complex.
I also write lots of Typescript, and the furthest I go is to use 'Omit' and other utility types, but already feel like it's too much.
3 replies →
I hope once they introduce unions, they also introduce some sort of error union.
> It also doesn't have the fragmentation that Java or JVM langs has
What fragmentation? Honest question
Updated a pet project of mine and got a minor break:
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.
NHibernate project stumbled upon much bigger break: https://github.com/nhibernate/nhibernate-core/issues/3651#is...
We force to use this workaround for now.
That workaround seems wild as hell.
>I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.
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
There's F# if you want to go fully functional.
Why C# doesn't have first class functions and can't go fully functional (and likely never will): Scala tried and its compiler is slow, even after so many iterations and new novel compiler ideas.
I like the way it is, and hope it doesn't change. Unless they could make this possible without making the compile process extremely slow.
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.
At last, extension properties in C#. I’ve been waiting for these for years.
Why is it better than just using a method?
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.
2 replies →
How come this quickly fell off main page and is ranked 395 right now?
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?
It looks like it was hit by some software penalties that lowered it in the rankings more than it should have been, then it just continued dropping.
I've restored it to the front page and wound back the clock so it gets its rightful dose of front page time.
Literally just got yoinked up from rank 199 to 2.
https://hackernews.life/?s=top&id=45888620&t=1762939537
It arrived at rank 86:
https://hackernews.life/?s=top&id=45888620&t=1762876085
What is the deal with Ubuntu and this version of .NET?
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?
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].
[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
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"
https://github.com/dotnet/dotnet-docker/discussions/6801
C# has the best ecosystem out there.
I wish CPP development was as robust as C# development is
They are very different beasts.. What problems are you having with CPP that you're not with C# ? Funny enough a lot of the 'ecosystem' is on the back of cpp..
Evaluating complex expressions during debugging.
In c# I can evaluate complex linq data transformation in watch window in visual studio during debug, at fly.
In cpp I cannot. Not even nested evaluation is working.
3 replies →
With C# (.NET) I can click on "install package" in my editor and within seconds it's downloaded and in my project.
With C++ it's a whole different thing.
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.
For most projects, upgrading between .NET version is quick and painless, usually just updating the TargetFramework and NuGet packages in your .csproj file.
I wouldn't worry. Updating .NET rarely breaks anything.
9 isn't an LTS version... always go with an LTS version.
That's... a strong statement. There is absolutely nothing wrong with going with a non-LTS version. You just have to update a little bit sooner, and that's it.
1 reply →
I hope .NET will become more popular
Also first time in a long time Rider is supporting it from day one. I was ready to wait for a month plus to enjoy the goodies.
Anybody remember IronPython, IronRuby, etc?
I do! Pretty sad that IronPython isn’t a thing anymore, especially now that I’ve actually had to learn Python for machine-learning related reasons. At least .net did get the dynamic data type out of its brief interest in these.
Why? It seems the latest release is quite recent (9 months ago)
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.
[0] https://github.com/IronScheme/IronScheme
[1] https://github.com/IronScheme/IronScheme/pull/141
If the US had universal healthcare I bet there would be a lot more .NET startups as corp devs would have the freedom to pursue their dreams.
Some days ago I helped migrate a service in .NET Framework 2 to 4.8.
Yup.
Copilpt will migrate it to .net 10 — there is upgrade agent
No, it won't. WebForms are .NET Framework only and are basically the key reason why any app stay on .NET Framework.
A ton of internal apps used by few user with is built upon WebForms. It's just not worth it.
1 reply →
> Today, we are excited to announce the launch of .NET 10, the most productive, modern, secure, intelligent, and performant release of .NET yet.
It looks like they got someone from Apple to write their press release.
Does this version improve or streamline the numerous options for web dev like Razor, Blazor etc? Anyone can comment on which is actually being popular
Same number of options.
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.
Thanks! Its clear..
.razor is blazor, razor pages is .cshtml
1 reply →
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.
Isn't the official .NET debugger only allowed to be used from Visual Studio and VSC? I recall Jetbrains had to remove debugging support from their IDE for a while due to that license. Also the whole kerfuffle around hot reloading first being added to .NET (Core) and then the code being deleted because it was supposed to be a VS-only feature.
These things to me seem like one faction in MSFT wants .NET to be an open platform and another faction wants it to be a sales funnel for Visual Studio.
There is WinDbg which can debug CLR code, but that is Windows only.
4 replies →
There's an open source one by Samsung that is excellent, never had any issues with it: https://github.com/Samsung/netcoredbg
I think I tried that (or a derivative of it, didn't know Samsung was the primary developer) that broke in some very very weird ways. Will try this version, thanks!
Related and useful (work in progress): Breaking changes in .NET 10 [1]
[1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
If you have a build command that does not specify version for things like 'dontnet-ef', your build might fail because it is not compatible in .NET 10, so update to specify version, e.g.
dotnet tool install --global dotnet-ef --version 8.0.8
That's a lot of goodies in a new release! It seems it is outpacing the JVM's development...
Apart from [the equivalent of] records, I see nothing big.
Except...
this '''let! a = fetchA() and! b = fetchB()''' really puzzles me. Does C# have a high-level syntax for concurrency timing? [something that Java is strongly lacking, and that Typescript did solve with Promise.all(), which is an ugly syntax, from my perspective]
Any elaboration on this is very welcome.
The inlining and escape analysis changes are fairly big from a performance perspective.
Also, C# doesn't need nearly as many massive changes like project Valhalla because they got a lot of those design choices right from day 1 (mostly by looking at what Java did that was dumb and avoiding it).
Here `a` and `b` can have different types:
Whereas `Promise.all` usually requires all promises to have the same type (returning a `List<T>` or even a `List<obj>`) .
See https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs...
2 replies →
The code snippet is in F#. And F# has so called "computation expressions".
Java has had CompletableFuture::allOf for a long time. The new structured concurrency api also has the same capabilities of waiting for futures.
As others point out, that's F#, but yes C# has `async`/`await`, and has all the `Promise` methods, just under the `Task` class instead (and with slightly different names/calling conventions through out).
I think thats F# not C#
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!
The go-to nowadays is System.Text.Json, developed by the same person as Newtonsoft.Json, built in to .NET.
Newtonsoft.Json as the primary JSON serializer (at least in every place I've worked) has NOT been the case versus System.Text.Json for years. Though it certainly used to be the case.
Doesn't Text.Json have a much narrower scope and plenty of features supported by Newtonsoft not available?
1 reply →
Uh okay! I was not aware of this. Thanks for pointing that out. Why is there so much difference in the NuGet downloads between both libraries tho?
4 replies →
Haven't touched the newtonsoft package since .net core 3 / or about 5 years go? Something like that. Its not really getting updates and its huge/slow compare to built in one. The built in one is much better these days and plays well with other subsystems in aspnet.
Is it? We've switched over to System.Text.Json entirely.
There's so much stuff they could be working on instead like a first party Postgres driver, better OpenAPI, improving Minimal APIs, etc.
What's wrong with System.Text.Json?
Last I checked they stubbornly insisted on reinventing the wheel and ignoring everything in System.Runtime.Serialization so you had to redecorate everything with their new attributes. For example https://github.com/dotnet/runtime/issues/29975. So we stuck with Newtonsoft for the time being.
3 replies →
.NET has to win the title for worst naming. If you didn't know what it was, this announcement makes no sense whatsoever. All you would guess is there are probably 9 others that were just like it.
> All you would guess is there are probably 9 others that were just like it.
Lol, even this is not true. For the current runtime/stdlib package known as ".NET", they started numbering at 5. The actual sequence (only counting major version numbers) is: .net framework 1, 2, 3, 4, .net core 1, 2, 3, .net 5, 6, 7, 8, 9, 10. Easily the worst naming/version history for any product (worse than Windows).
I'm still reminding other devs that it's not ".NET Core" anymore (and hasn't been for years), it's just .NET.
Available on Heroku https://devcenter.heroku.com/changelog-items/3479
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:
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.
Previously, if you wanted to add that Trim in, you needed to define the field behind.
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.
> The new syntax avoids having to do that "double" declaration.
Yes, that's right. It is in other words a way to access the compile-time generated backing field for auto-implemented properties. It is quite nice to be honest, I just wish they presented a bit of context in their announcements.
2 replies →
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
I love this feature. I have avoided doing some stuff in properties because I don't want the noise of a private backing field.
It’s all about the libraries in the end.
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.
I really like it!