> 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".
Every company should give developers $100 per year to donate to the open source project of their choosing. Right now the conditions are such that maintainers are incentivized to rug pull.
I love this. I've also been bandying about the idea of an open source equivalent of a B Corp sort of accreditation where a company can essentially brag about auditably donating to the open source projects that it depends upon.
Hmm. My company gives everyone a $500 a year allowance for training and/or tools that we can use through OneRange. It shouldn’t be that hard to get approval to donate to an open source project.
This is all hypothetical. There isn’t any open source project I depend on that isn’t backed by a large corporation.
Developers can always contribute as well but the benefits aren't really accruing to them. If open source libraries didn't exist there would be commercial offerings or things would have to be built in house. Also, $100 / year / dev is a rounding error and would add to a company's engineering brand.
It seems like a win / win to me but, of course, no one has to do anything at all. Just don't get upset when maintainers pull the rug out from under you because that is the behavior that is being incentivized: 1) make your thing widely used and hard to replace, 2) get in to large companies that can afford to pay 3) change license, pull rug and get your legal team ready to fight.
One need to see how many developers are already getting paid enough and out of them how many actually donating to OSS projects.
AFAIK developers are full of excuses like "these trillion dollar companies need to pay fair share while my hundred thousand dollar salary in this big expensive city leaves me with nothing to donate.
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.
In the world of LLMs the new version of "open source" is LLM makers using prompts which are then used in training leaking your code into the next version of the model therefore distributing your code for "free" minus your payments to the LLM maker.
It's probably a good thing because far from your "secret sauce" so much programming work is companies doing the same very boring things over and over connecting pipes together and making extremely similar design decisions for mundane tasks.
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.
Moq, lots of PDF libraries, Avalonia, Automapper, MediatR, MassTransit,Telerik stuff,etc.
I'm not inherently against it, we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.
Avalonia is FOSS (MIT licensed). You only need Avalonia XPF if you are migrating legacy stuff.
Moq is largely unnecessary today with LLMs being able to easily generate mock classes. I personally prefer to hand-roll my mocks, but if you prefer the Moq-like approach, there's NSubstitute (3-BSD).
Automapper and MediatR are both libraries I avoided prior to the license change anyways, because I don't like runtime "magic" and not being able to trace dependency calls through my code. But, there is Mapster and Wolverine to fill those needs (both MIT). Wolverine can also replace much of MassTransit.
Telerik stuff - there are many good FOSS alternatives to these UI components; too many to list since it depends on which stack you're using.
PDF is indeed a sore spot. PdfPig is good, but limited in capability. I've started offloading PDF processing to a separate Python container with a simple, stateless Flask API with PyMuPdf.
> we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.
Completely agree with this, though. My company and myself personally contribute a lot of time back to OSS, and I feel like that is part of the social contract of OSS. To have these libraries rug-pulled feels like a slap in the face as a OSS contributor and maintainer.
PDF is an enormous festering wound in .Net. I've also been doing .Net since day one and never bought a single commercial component. Used it to build some massive commercial products all on OSS.
BUT. PDF has always been a nightmare. It's made a lot better in the last year since LLMs have vast knowledge of all the functions available in each of the .Net PDF OSS libraries and can usually find a way to do the thing I need now. (I've even had them just hack the PDF streams to do something when there is no library to do it as they know the whole spec)
I agree with almost all of this, especially MediatR being nonsense, but I would recommend against using a LLM to generate a mock. That’s just more code that you need to maintain and update on every interface change. NSubstitute is a fine library.
Another popular library that went commercial is FluentAssertions, Shouldly is a good open-source alternative.
Any recommendation of good alternatives to Telerik? We've been using it for years, but I'm open to considering alternatives even though it doesn't cost me anything to pay for the license.
Depends on what layer of Telerik [0]. Honestly of late since I'm extra rusty on frontend I just get Copilot with Claude to help generate UI widgets since that's allowed.
Before that, years ago, I just YOLOed with WebSharper and built composition helpers to make 'spartan but correct' UIs that could be prettied up with bootstrap if needed.
That said, alas, Bolero (what replaced WebSharper) is F# specific rather than also supporting C#.
I mostly bring those up because they have various libraries out there to work with different JS bits.
There are a few non-paid PDF libraries, but that is the biggest pain point in .NET, anytime you need advanced features for PDF, you're better off paying for a license (it's just insanely expensive unless you're a large company).
Having worked on some basic parsing of metadata from PDF spec, I would rather pay than have to code something myself. PDF is such a PIA.
I've used libqpdf extensively from C++/CLI with excellent results, but since C++/CLI is deprecated-ish and Windows-only, I wouldn't disagree with PDF being a pain point, and if I get the time, a cross-platform open source .NET wrapper for libqpdf is at the top of my list of potential projects.
libqpdf also intentionally limits its scope to PDF structure, so doesn't address nontrivial content creation or manipulation (page content handling is pretty much limited to compressing/decompressing and parsing/unparsing the content stream).
That brings you back to managing memory though, C++/CLI having access to managed C# handles/references for GC'd objects (and finalization) would greatly simplify any memory management at the same time as having first class access to native libaries.
Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native interfaces.
I've used p/invoke extensively. You can easily make your own managed handles. It's not as easy as straight up calling c#, but it's not really that bad either.
It's not that hard to create a C# wrapper class if you need to hold on to pointers that need to be cleaned up by the C code... you can keep a private property reference and call the appropriate C code as part of your Destructor or IDisposable implementation.
If you're wanting to use a C library, yeah, you need to manage how you use that C library, this is true regardless of the language you are using, it isn't magic.
IDK, for certain cases those fancy libraries are just handling the ugly marshal calls for you.
Wayyyy back in the day, before package managers were a thing, I had to write something to output a PDF via DLL calls and frankly it wasn't a bad experience. Possibly outside of what is in a 'modern' workflow but honestly wasn't too difficult. Just wrap it all in a class that only gives what you need and avoids potential footguns via validation.
Frankly it was easier than doing anything with Autocad's 'managed' libraries [0].
Maybe it's rose colored glasses for me, but .NET had fairly simple rules for most marshal bits so long as you knew them, although I will admit we didn't worry about 'performance' for the stuff I wrote and that can be a factor.
[0] - Microstation had a bunch of fancy COM hooks and exposed all of it to .NET in a nice way. AutoCAD 'managed' libs had all sorts of weird sorts of arcane rules and if you failed to follow them not only could you crash your .NET process but Autocad could remain unstable until you rebooted the PC... which is why I keep putting managed in air quotes.
I can confirm that (several years ago at least) free PDF libraries were lacking, and Telerik was always non-free.
However, aren't Moq, Avalonia and MassTransit free software?
As for Automapper and MediatR, their owner changed from a free software license to only an open source one (Reciprocal Public License), but these are probably the simplest libraries of the ones you mentioned and have either been forked (MagicMapper) or have alternatives.
Yeah pdf libraries are a bit of a mess, I work with a product that handles lots of PDF documents and I think we just recently added another PDF library dependency (I'm certain it's at least 3 now, but could be 4 or even 5 libraries loaded at startup).
Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Avalonia itself is opensource, but i'd put in in a fremium/shareware category since if you need to add an WebView or Media player you need to buy their commercial Accelarate additions.
> Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Well they pulled back but the trust was broken in a lot of cases. I am still fine with it 'for now' but IDK NSubstitute always feels weird to me, maybe that's just how I was taught to use it tho.
> Masstransit went commercial recently
I mean good for them but thankfully it's also giving attention to other projects that are FOSS or Open Core...
As far as the other stuff, I've never seen AutoMapper used in a way that couldn't literally be handled with a static/extension method in 'real' code. Yes it can be useful but it is often grossly overused.
MediatR is cool but TBH I'd rather just reach for Akka.NET or MessagePipe instead; If you're abstracting out to keep processing backend 'swappable' you should be able to handle any of the above for the choice you make anyway.
I created a Moq lookalike in an evening a few months back, it's not a hugely advanced project honestly (if you're used to working with the reflection system).
Just one example, but when I was running a .Net dev team we licensed the Telerik UI components. We ended up dropping them, but not until we had initiated a migration to Java/PG instead of C#/MSSQL. After we moved to Java everything standardized of a set of FOSS libraries for various things.
We use Telerik components at my current job. They're a solid library, IMO. I'm sure there's better out there, but we've been using them for nearly 15 years at this point and I feel like we get decent value for the money, and their developers get to draw a salary.
I'm not sure how that applies in this situation, since you're choosing to buy into a proprietary platform when plenty of open-source competitive options exist. That's the case for every language/tech stack.
That's a choice, there's lots of FLOSS alternatives... was this a desktop application? In that case, I can see wanting to chose a commercial library as it probably saves a lot of work with the floss/in-the-box alternative options.
That said, for a web cli, there are a ton of options out there without touching anything commercially licensed.
I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were:
1. The overall architecture (with the JVM) made it slower than the equivalent C# code.
2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then.
(Not OP, disclaimer, I work for Microsoft and this is only my opinion).
> I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were:
It's almost a shame. I am genuinely impressed with the gains the team has made in both, language aspects as well as JVM technology. They have some brilliant people working on it and I love to hear their talks (Brian Goetz and Mark Reinhold, mostly).
But I suppose I would say the same about .Net, it's just that you guys have much less public exposure of your internal reasoning.
I've seen the gains in Java; the main things that would close the gap are not yet there in Java. .NET code, especially when tuned, still has significantly more knobs in your code to tune and make faster. An example would be proper generics with value types together means less boxing in generic code in general overall but there's a lot more I can think of. I've seen almost 50% of gains, particuarly when doing math like code, of moving away from Java to .NET especially if the jump to C/C++/Rust is too much for the team in question due to other requirements.
There's more to developer experience than that. Your comment even demonstrates one of the differences: The .NET library compared to a bunch of different Java frameworks.
That is indeed a technical difference. But I don’t see much significance in it.
Spring is a de-facto extension of the core java libraries and alternatives like Quarkus follow the same mental model with a better technological foundation.
Maybe, but with all the modern .NET tooling I feel at least 2x productive in .NET than in Spring Boot. There are a lot of quality of life stuff in .NET/C# that really does add up and makes a substantial difference (DX-wise) in the long run.
C# 1.0 was pretty much Microsoft Java, but since then, C# has evolved into its own, more powerful thing, while Java has stayed much more conservative over the years.
I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.
What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.
I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.
> I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today.
Have you never written a plugin or a mod?
Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features.
As soon as you AOT compile CLR or JVM languages, you lose access to the stable, feature-complete ABI that bytecode provides. Heck, many languages built from the ground up for static compilation like Go and Rust still have dismal ABI stories. The only exception I can think of is Swift, and it didn't come by it easily. AOT also imposes limits on reflection and runtime codegen (often, to the point of totally removing them).
If your software exists only in a walled garden, only gets deployed to infrastructure you 100% control, can't be extended at all, and/or can only be extended by full recompilation, then bytecode may seem useless. But that isn't the whole world of software.
I agree that .NET uses bytecode and likely cannot practically remove it outside of narrow cases. My argument is, if .NET were a greenfield project, they likely would not use bytecode today.
I think this was a fair statement up until a couple years ago, but right now I am lamenting the actual progress in C# and CLR technology.
I think the progress on Java and the JVM has been nothing but impressive. Not only compared to the baseline to where things were 10/15 years ago, but simply how much stuff comes out each year and how well-thought it all is.
Frankly, it's an inspiration for my private and professional projects.
I wouldn't call this a silly question at all. But having recently converted my intro data structures course from Java to C#, I can talk about why C# might be better. I have programmed regularly in both languages for the last 15 or so years (in addition to regularly programming in TypeScript, Scala, and F#).
Java is fast and reasonably safe. It has a lot of software (especially OSS) software. Its package system (Maven and the like) is ok, but not great. The language occasionally gets new features, but change is slow.
To a first approximation, C# is a lot like Java, so it is relatively easy to switch. But C# is, hands down, a better language. The most obvious thing that a developer might notice that that C# does not force you to be extremely verbose like Java, although you can code in the Java style if you like.
Having switched my course from Java to C#, the most obvious "win" was the fact that, every lecture, I would delete some slides that explained painful Java corner cases to students. For example, Java's implementation of generics. Boxed types are necessary, and explaining them to students who have never seen any form of polymorphism before is difficult. After an entire semester of deleting a handful of slides each lecture, I have save _three entire lectures_ worth of corner cases!
Some C# niceties:
* Everything is an object, even value types! So our favorite `ToString` and `GetHashCode` methods, etc, are all there.
* Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object!
* The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool).
* By default, reference types are not nullable. This is a little bit of a pain for an intro data structures course (we turn them off), but it is a great idea for commercial programming.
* switch statements work the way you would expect a modern switch to work, and in some cases they even do exhaustiveness checking like a functional language.
* Speaking of... LINQ!
* In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>.
* Type inference is limited compared to a functional language, but it is dramatically better than Java. Being able to write `var` is wonderful.
* Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time.
* C# has a rich set of value types, including structs. Java may have added something like this, since I remember the Scala people hacking away on it, but it is used pervasively in C#, and you can make very fast data structures that take advantage of spatial locality. Rolling one's own hash table implementation in C# is actually kind of fun.
* .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things.
* NuGet is a million times easier to use than Maven.
The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually.
Anecdotally, my students this semester are demonstrably more capable programmers after a semester of C# than a semester of Java. It might just be that I got lucky with this group, but I have been teaching this same course (except in Java) for the last 7 years, and this feels like a real effect.
This is interesting. I've been away from the high-code world for a while and instead of going back to Java, I might try out c#. Thanks for the writeup.
I'm not new to C# myself and I have been writing a hobby game project in it for the better part of 2 years. I know the C# features pretty in-depth by now, and while you can definitely make an argument that C# has more and better features, I found that Java has greater synergies in its features.
Don't get me wrong, there are some features like "abstract static" in interfaces which give C# superpowers... until you realize that this only works one layer deep. Or the non-break switch expressions, which require a return type. Lack of an equivalent to Java's "Sealed Classes" (that you can switch over). Or that you can't validate primary constructors up until recently.
Lack of value objects are definitely hurting, but JEP401 addresses this and is available as preview as of now. I am absolutely blown away by the depth of their value-narrative and I think they uncovered something much deeper than "value or not" with gradual performance gains based on gradual constraints.
But I absolutely see the value of C# in teaching. Java works more via libraries and convention, whereas C# has ingrained many concepts directly into the syntax level.
But maybe I am a Java fanboy, haha. I even prefer the Erasure of Generics, the times it has complicated my code in C# is much higher by now than I ever thought it would be.
> Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object!
Took me a moment to realize you meant that 'Java has corner cases because everything is an object' but yes.
Will also add the 'advantage' that for value types (i.e. struct) the generics are 'specialized' for the type, in certain cases you can use that for performance optimizations. (although it can have downsides.)
> The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool)
And, fun side note, the generic arrays actually existed before real generics (and we get fun hacks in the VM as a result!)
.NET does still have funkiness around Array Covariance tho, which sometimes can be a pain.
> By default, reference types are not nullable.
This is a newer feature and great, however it requires people to (1) use libraries that properly do it and (2) requires you to have the right tag in the csproj to flag the NRT warnings as errors. I've yet to see a shop that has adopted (2) as a default.
> In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>
Yes and also the sugar around yield syntax to do generators.
> Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time.
I still remember getting called into a Dev Manager's office, he's a JVM guy and he's goes into this overview of Lombok and how the JVM folks want to use it and he asks what I think and I'm like "Gee wow give me a moment I thought Java had AutoProps by now". (I think it was the first time he was impressed with C# as a language lmao, He and later I were disappointed in .NET's lack of a good set of thread pool abstractions...)
> .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things.
That is so freaking cool and I love it. Profs like you made college fun back in the day.
> NuGet is a million times easier to use than Maven.
Truth; every time I have to do a thing in JVM dealing with maven feels like I need a goat or chicken to make anything work right.
> The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually.
We have AOT and R2R nowadays, I'm not sure if it's 'JVM Fast' for something like a webservice but unless you're pulling in something like an ORM it's typically fast enough I can't observe a difference as a user for utility apps/etc... Curious what examples you have in mind?
The thing that always turned me off about Java are the IDEs. Besides Java doesn’t have anything like LINQ. I would rather have an ecosystem backed by Microsoft than Oracle.
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).
C# is pretty popular in the US as well in certain spaces... especially Govt or Banking and adjacent environments. Mostly line of business applications. I'd say Java is slightly more popular, but I never really liked Java's ecosystem ergonomics, though they're better today it's just not for me.
Similarly, I'm not a fan of "Enterprise" development regardless... I find a lot of .Net shops, like Jave, just create a lot of layers of indirection and abstraction that only lead to excess complexity, cost and difficulty in both maintenance and enhancement. The older I get, the more my mindset shifts to make things that are easy to replace without adding undue complexity or patterns.
The problem with enterprise apps is that they're usually wide but shallow. Which means a ton of classes that don't do a lot and managing class complexity is actually the biggest challenge.
So it's just a very different type of code and you can point at the language, but the reality is that it's the domain.
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.
As someone who has written multiple Node and C# backends, Node isn't even close to the ecosystem quality. It's not in the same solar system.
Npm has tons of libraries, but they're mostly abandoned. Many barely worked in the first place. And if they're even a little out of date, there's a decent chance they're missing TypeScript types or they won't work with your module system. It's a nightmare.
Struggling with missing or broken dependencies is what made me swear off Node backends permanently.
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.
The Dallas area is a major tech hub. It’s just an older hub of major enterprisey type companies with major tech divisions there like Texas Instruments, AT&T, Bank of America, defense contractors like Lockheed, etc.
Office Space took place there before the dotcom bust.
Less enterprisey, but John Carmack and id Software also started there.
I lived and worked in Atlanta from 1996-2020. Those aren’t anymore tech companies than Delta, Home Depot or Coke by modern definitions. In all of the companies you named, software development is a cost center, not a profit center - follow the money. Who gets paid the most as a group at those companies? Those are enterprise companies.
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.
>> we use .NET for backend and React for frontend. You don't need anything else
...
>> sure maybe you have some data science people who need python,
This is how it happens though; it's not "let's form a company with 10 developers; don't worry what tools they use!". It's starting with a single problem using common tools, then adding specialized problems where you could still use the same tools but they are not optimized, then adding an acquisition product that uses different tech, then growing to 100 or 1000 developers and may all use React or C# (doubtful) but don't use it the same way...
>> If you're going to make a change then migrate everything
Have you ever worked for a software company before? THis is not how it goes.
No it isn't. This is not how you end up with 7 different frontend JS frameworks in 7 different web applications. Using python/matlab/r for data science is completely fair. These languages are standard in this field, they have the most tools and built-in functionality for this purpose.
I mean if you want to do ML and data science stuff in C# or whatever go right ahead. If you can make that work that's great. But I also think, as someone who aggressively promotes sticking to one language, that it's fair to use Python for data science.
What I don't condone, as I said, is using multiple tools for the same task. So for example, having one team/dev using Python while another uses Matlab and yet another uses R etc.
> Have you ever worked for a software company before? THis is not how it goes.
Yeah, I know. That's the problem. People just introduce new tech like it's nothing. That's why I'm saying it needs to be a big decision. So if it's really worth it okay let's go for it. But for the vast majority of cases it just isn't.
It's bad enough when you've got constantly changing "best practices" from MS so the thing you wrote last year doesn't look anything structurally like what you're doing now.
And all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.
So you don't like .NET, that's fine. I'm not saying everyone needs to use .NET. I'm saying pick one thing and stick with it.
That said I think you're exaggerating those complaints, the docs for C# are quite good imo and I've been working with ASP.NET web apps for half a decade so far and I'm not seeing any problems like you're describing.
Maybe you're miffed about the Framework to Core/.NET switch? That was a bit of a doozy but the ecosystem is so much better for it I'd say it was worth it.
> the thing you wrote last year doesn't look anything structurally like what you're doing now... all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.
I'm only now deprecating a netcore 2.2 API that used a 4.8 framework domain/repository layer. At the time it seems like a good idea and it received automatic security patches.
> People love to talk about the right tool for the job, it's all BS
This sounds very close minded to me. It is certainly true that there exist tasks if not subdomains where some ecosystems are better than others. Using a hammer for everything might work for you if all your problems are nails. But that doesn't mean that all problems out there are nails
If your organization has one API written in Node, another in Java and third in Python without any reason, then yes, all the problems are nails. And sadly, I've seen this a lot.
I've have limited success using codex to do code conversions for multiple projects into one standard team language. I suspect this will only improve and is how this "problem" gets solved soon'ish.
If you can justify with good reasons why you absolutely need this other tool then that's fair game - hence the data science example where I allow for specialists to use specialized languages for specialized tasks.
I'm talking about general software development and web dev in particular. There's a trend where you'll see one org has or web app using .net ad react, another using next.js, another using Java and Vue, one djnago and htmx, and so on.
And there is literally no reason for any of these choices, they're all fairly basic web applications that could have all been made in literally any half decent web stack. So whether the devs who made these choices knew or not, they made them based on preference not any kind of reason or need, they're all nails and any hammer would have done the job just fine.
>> And there is literally no reason for any of these choices
I'm a manager now but definitely held a variation on this "people are idiots" view when an IC and younger. Question: are all your coworkers idiots? No? then why would all the work done before you be the product of idiots?
I found it really valuable to approach scenarios where the initial response is "how could this possibly happen?" as a cultural anthropology question. It turns out there were many rational decisions made, most that I would have gone along with that brought us to what we see today. My coworkers are actually really good, some of them who manifested what we see today are amazing. Many are crafting code, making thousands of microdecisions without perfect information or 100% clarity across a large organization, reacting to changing markets and directions, client needs, shifting priorities, executive decisions, technology changes... the list goes on.
This is all my way of saying there might be many reasons for any of these choices, and you'll help your own cause - and happinness - if you step back from your zealotry and take an empathetic approach that's less binary.
Some of my coworkers are awesome. Super talented, super smart people.
But most developers are pretty bad. I see a lot of developers who hardly do any work at all, and many who do lots of work but it's all trash. Buggy, overcomplicated, untested, dumb pointless decisions.
Like my current project. Two guys started it - .NET backend, React frontend. Sure, fine. But let's use Azure functions for the backend instead of a regular web api. What. We asked them why, no reason. And their whole codebase was trash, I've deleted about 90% of the code that they had written and I'll delete the rest too.
I've also been in a team that had the problem I highlighted in the OP. 20 different apps, 10 different JS frameworks etc. Speaking as someone who worked on these apps, there was absolutely no reason to choose one JS framework over another. I could have made them all in React no problem, they're just websites, not much more than glorified PDFs. How you generate the html is irrelevant. And the code was mostly trash. Overcomplicated, buggy, untested etc.
I did struggle with this early in my career - am I just a narcissist? Everywhere I turn the code is just trash, maybe I'm the problem? But now I've worked with people who do good work. I've seen my own ideas work in practice. I know for a fact my judgement is good.
In university I was the one who helped everyone else. I was always ahead, while my peers could hardly keep up. When we graduated a lot of them would have struggled to solve fizzbuzz in 20 minutes, yet we all have the same degree. No wonder there's so much trash code around.
Using the right language for the problem domain is a good thing, but what I can't stand is when people self-identify as the one language they are proficient in. Like, "I'm Staff JavaScript developer" no buddy, you aren't "Staff" anything if you only know one language.
> Do you also make everyone wear the same clothes, drive the same vehicle, order the same food
I don't think this is an valid comparison. There's a problem called technology sprawl, which is characterized by needlessly increasing maintenance needs and cognitive load and lower development speeds caused by the need to juggle multiple programming languages or frameworks. There is a fixed cost in maintaining each tech stack and even development environment, and you multiply that cost each time you think it's a good idea to introduce yet another programming language or framework.
> Do you also make everyone drive the same vehicle
Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.
How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
> But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.
I think that question is more "how many different makes of van can your delivery company afford to maintain?"
Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"
The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.
The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.
Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that. Vehicle fleets are often aging out with these timelines.
So if we either stretch the fleet management analogy to 50 years, or software applications only lasted 3-5 years maybe it IS fair to say the both have either a lot (former) or very little (later) inconsistnency?
> Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that.
.NET gets refreshed annually. The last bigger change was nearly a decade ago. So not all that different.
But I don't think that the analogy stretches, really. e.g. where I am all .NET apps are .NET 8 LTS or 9, and will be all be .NET 10 LTS by middle of 2026. You can upgrade an app to a new model year much more easily than a vehicle. The "software application, on a SDK major version" only lasts 1-2 years.
Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks.
I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.
Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
I'm not a car guy but I most certainly a bicycle lover, so I will jump on you and say you often need more than one type of bicycle. Joan commutes to work? she wants a city ebike. Dan rides at the bike park? He wants a DH bike. Randy ride centuries on the weekend on his TDF road bike and Sally rides with her kids on a mountain bike.
So yeah, we can pick one bike type and force everyone to ride it, and the results will suck & everyone hate it. Your job can be to continually force everyone to follow this policy or you can stop and we'll get a lot of variation. THis is how it happens.
Well, they clearly all know how to ride bikes, so you offer to hire them to deliver using company bikes as a day job. And let them ride whatever they want on weekends.
The "force everyone to ride it" on the weekend part is where
I think the analogy has broken down irreparably. We're talking about cost of ownership of company equipment used during working hours for much more defined tasks. What flavour of bike you enjoy riding on weekends is not relevant.
Programming language are inherently flexible, especially those that aim to be "general purpose". Fine-grained distinction of road bike vs mountain bike apply more to the apps created than the coding tool.
> Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
Yes, this.
> I'm saying use one tool for one task.
I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.
I know one person who was good at python, and who looked at the "classic" .NET hello world app with usings, namespace, class, main method etc containing the "Console.Writeline" payload, and noped out immediately, saying "if it's that verbose that it takes 10 lines to do what's 1 line in python, imagine how terrible real code must be!"
Personally I think they were wrong about that - it was optimised for larger programs, not trivial ones.
But also it helps me understand the ongoing push towards the point now where "hello world" is is 1 line in 1 .cs file only. And `dotnet tool exec` means you don't even need to install a utility to use it, etc.
In other words, .NET started life as a truck, with many features to support large codebases - usings, namespace, class, method etc. but is also general purpose enough that you can now also write a "bicycle" program.
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)
No, we don't do any coding tests, just discussions of what you've done and how deep your knowledge of your tools goes. .NET folks are far less likely to understand much beyond the syntax, nevermind the "why" of things (even WHY you need StringBuilder) or what a database index is, etc.
Interesting. One would thing, "script kiddies" would be more common among Pythonistas. On the other hand, .NET might be more user-friendly, so that devs are productive even without the knowledge of what's going on under the hood. Kudos for the interview practices, that's similar to how I conduct as well :)
Mountaineering, climbing, bouldering, going to gigs, playing pool, running, music festivals, gaming, photography, watching F1, watching NBA, eating out with friends...
The reason I thought it was odd was that I've never seen any correlation between someones hobbies outside of work and what tech stack they use at work.
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.
Been awhile since I've worked at one but it is usually grounded in trying to achieve 100% MS usage.
It is rarish to find a partial MS shop. Most of this is how hard MS makes it to use other tools. Even in 2025 they have good interop with external tools hamstrung.
Example: SQL Servers JDBC driver will convert an entire table's of data from ASCII to UTF and a full table scan instead of convertering your UTF bind to ASCII and using the ASCII based index. This doesn't break interop but does make it painful to code and one more reason to just use .Net.
There is no way a reasonable person would not deploy to Linux and postgres for cost reasons alone. No one wants to pay Microsoft or Oracle money for databases, operating systems or frameworks nowadays.
All my .Net web apps are now deployed to Linux and Sqlite. Good riddance to Windows Server and IIS (which was dogshit from day one). With the tiny memory profile of .Net 10 it's crazy how small a VM you need to get good performance.
My biggest complaint would be a tendency to blindly use a "Microsoft first" approach to selecting tech rather than evaluating things on their own merits in the context of their own use cases.
Some Microsoft stuff is really good but it's not universally true. And in the worst cases you end up locked into some hard to migrate off platform that is withering on the vine.
I worked at a Microsoft shop, and this was my experience.
1. Process, process, and more process. Doing anything required layers of management approval. Trivial tasks become month long, or even years long, processes.
2. You have no power or agency. Something is broken? You're a developer, you should be able to fix it right? No. Broken things stay broken. You swim in your lane and keep your head down. Mediocrity is the goal.
3. Optimization doesn't exist. If a process is manual and takes you, a developer, 10 hours, then that's what it is. Nobody gives a flying fuck about tooling. Nobody cares if you spend 50% of your dev time doing random stuff. And if you even dare try to fix it, you will be told it's impossible and you're wasting your time.
4. Management is king. You will have to lie to them. You will have to spend time re-entering the same data in 5 different places so they can read it conveniently. You will have to make Excel workbooks. You will have to dumb things down, and then dumb them down again, and again. Everything is about Jira... Unless they're a really high up manager, in which case you have to take whatever is in Jira and put it in a word doc and send it to them, because they don't know how to open Jira.
Those things have nothing to do with C# though, rather than your personal experience with companies that were using it.
If I judged every single company i worked at/interacted with, that uses NodeJs, I'd think that every single Node dev is a 13 year old child with no real experience but who think's he's the hottest shit. That has nothing to do with Node and doesn't really describe _all_ the companies out there.
The problem is thats how a lot of .net shop operate. I say this as .net developer.
.NET gets selected because a lot of non tech companies need to do software things, and they pick the stack fits in with their current WinTel stack. The main concerns is having replaceable talent to reliably do x. They're not trying to innovate. They are often doing something like sending out insurance quotes by email. They do this by having strict processes, and having developers stay in their lane. Expect rigid scrum, using dependencies only supported by Microsoft etc, Locked down Dev machines with visual studio only, ask for microsoft dev certs, and expect pre-approved enterprise design patterns up the wazoo. They don't want innovative developers, they want you to fit into the pre existing framework designed by an architect. Your skills can die in such an environment.
There are companies that use .NET that aren't like this, but you have to go out your way to find them.
> And .NET is the language of choice for "Enterprise". So that's what the majority of jobs are.
Disagree. I would argue Java is more of a choice for "Enterprise".
Also, would you please define the scope of "enterprise".
If you mean "enterprise" as someone who want consistent and predictable management and productivity, then sure .NET is "enterprisy", because instead of a dragon they want a fossil.
But if you mean "enterprise" as they want to sell their core product, and sometimes that pushes to high developmental velocity with multiple development team to tackle on a feature, then .NET is evolving fast enough that it is not so considered "enterprisy".
Heck, even Ruby on Rails would replace .NET for that, especially when you consider the e-commerce scene that is either Ruby or PHP (Wordpress).
Just look at C# and its incredible language revision every year.
> I would argue Java is more of a choice for "Enterprise".
.NET was literally created to replace the Java enterprise ecosystem. It never managed to completely displace it, but effectively gained around half of the enterprise market - and it will take more and more, after Oracle started pulling their usual boa-constrictor moves. C# is as "enterprisey" as they come, and it went full-opensource only once it became a requirement even in the enterprise.
It is mostly an Enterprise Development complaint... that said, it's how most .Net shops are in my experience. I really like C#, I've been working on a project with FastEndpoints and the .Net 10 RC since April and been pretty happy with it. That said, I don't have to implement 10 layers of indirection/interfaces/patterns to get the job done either. I have in other places.
But I would levy the same complaint with most Java[1] usage as well.
What's skills? Pumping out code ala startup? Sounds like a stable environment. Someone with a good eye will still be able to pick out flaws in the processes/architecture and learn a thing or two.
"The main concern is having replaceable talent to reliably do X" as in every other company?
I swear you guys make having a regular job sound like being under slavery. It's just a job. Some companies are boring, that's just part of the job, and being able to adapt to different environments is what makes a good sde imo.
Lots of places are not like this. I work at a large tech company, at its not like this at all.
My machine is not locked down. I can use vim or whatever ide/editor I want. We don't use scrum/safe, we're expected to contribute to the actual system design. etc If I have a choice, i'm not working at a place like that.
However if you work in dotnet at a traditional "enterprise", it is highly likely to be like this. I have a choice, so i'm not going to choose that.
Wanting replaceable talent drives the tech decisions to only use the "standard" microsoft stack. Other companies value picking the right tool, then teaching people. The best companies don't even care what language you use, and are happy to bring you up speed.
I've found a position that uses dotnet which does not have this culture which is good. But i can totally imagine not picking dotnet to avoid this culture.
I agree, I'm just speaking to the culture and I DO think Microsoft has something to do with it.
Companies who choose Microsoft everything don't think much. They're not risk takers, and I don't even mean substantial risks. They're stubborn, old-school. But not in a charming way, in a 'grampa won't stop talking about how great it was before integration' way.
This is just the run of the mill politics you see at every big company (or mid sized one).
I worked at a PHP shop, it was pure mierda. Worst code I've ever seen in my life. Pure incompetency. Does that say anything about PHP shops as a whole?
And from the company's perspective, that's the right way to operate. Sure, it sucks for the individual hacker-type, but a big enterprise doesn't want "move fast, break things" they want the opposite. Rigidity, proven processes, stability and backwards compatibility.
Working there you aren't building the next Google, you're probably maintaining a some 20 year old order-to-cash ERP process that's boring, but critically important to the business, and is exactly the software you don't want to move fast and break.
Just don't go work for big enterprises if you don't want that environment. It won't matter what language/tech stack, it's just big non-tech company things.
But there's plenty of us out there that don't mind those jobs. Pay can be good enough, and usually offer great work-life balance. I work IT ops for one. I'm remote, I put in my 9 to 5 and I'm done. I'm (thankfully) not on call, I get unlimited PTO, and my personal time is 100% my own to go do non tech things with.
> And from the company's perspective, that's the right way to operate.
Oh absolutely. It's a business decision. It just so happens that it's framework that has been around awhile and has a decent bit of support. Give Node another 10 years and that landscape might start to change.
There is a trend amongst companies who use Microsoft everything.
It's not dotnet per se. But if we're deploying by spinning up windows server and clicking around, then I garuantee you, that job will have garbage politics.
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.
Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.
> Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.
I am pushing for Linux containers in the workplace... away from Windows, IIS, etc. I totally agree with you 100%. I'm also trying to push us away from SQL Server where possible.
My last comment, which you referenced... focused not just on C# or .NET.. but the focus of "you need Microsoft" in general.. this includes Windows, SQL Server, etc.
Again, my comment is focusing on someone on the outside looking in.. and WHY people end up making decisions away from C# in favour of (something like) Go.
However - if Java was Oracle to begin with (and as successful in the mid-90s) then might have done some marketing for the Java+Oracle mix.
Some people (ie Managers) if they decide on using Microsoft products will likely "encourage" the use of C# and .NET. -- That is an example of C# + Sql Server.
> 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.
> most decent C# devs already moved away from to JetBrains/vscode.
My comment is NOT talking about 'decent C# devs'
It is a RESPONSE as to why more people are not using C# for startups. For those who are not familiar with C# MAY be put off using it for those reasons... and why another language might be used.
What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
I do my hobby .NET development in Zed and my serious work in Rider. .NET is open source and MIT licences. I do most of my development on a ARM MacBook Pro, or using my workstation which runs Fedora.
We deploy our code on kubernetes clusters usually on AWS.
All of the tooling, compiler, libraries etc are open source and cross platform and free. Not a single one of the developers in my team uses Windows or Visual Studio.
You know there are people.. programmers.. who are not C# developers... and likely refuse C# because of various reasons.. right? It can be based on the fact its Microsoft. My comment is based on startups and, from my experience, people like go all in on C# because decisions have been made to go all-in Microsoft.
C# has come a long way in the last 10 years. This much is clear, providing better support outside of the Windows ecosystem. However, many outside of the Windows/Microsoft ways are likely to be using languages like Go.
> What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
There was no C# in 1995.
(See it's easy attacking a sentence)
Silly me, using Rider (and VS Code) on Linux with C# (FastEndpoints and Dapper) with PostgreSQL...
Now the above is personal preference, while my day job is on Windows (also FE/Dapper) but with MS-SQL, which is because another group does DBA. I'm using VS Code for the work stuff though.
> 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.
> 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.
People who already are familiar with C# know this. To programmers that do not, may prefer to stick with another language to keep away from Microsoft in general.
Again - my comment is a response about why C# is not used more for startups.
I am not suggesting it isn't, but there are plenty of reasons, and this is likely just one.
> 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.
It is ironic when companies like Microsoft and Google end up showing the sort of "permanent reimplentation" behaviour that used to be typical of opensource, whereas certain opensource projects persist seemingly forever. Python, Django, Emacs - these things will likely see the end of the galaxy; meanwhile, big companies now build and discard key projects every other year.
Blazor will produce super bloated web apps. I can see it being used for an in-house thing with captive users but for a real world product or a public app? It would be a terrible choice.
Also the DX is just not there. Hot reload is a mess. Even when it works it's too slow. Once you start using hot reload with Vite you can't go back to waiting seconds for every change and full page reloads.
> Compared to what?
Everything else?
Do you think it's acceptable that it took 4 years for Minimal APIs to get validation?
What about hot reload being broken for years and years?
>Do you think it's acceptable that it took 4 years for Minimal APIs to get validation?
Well thay don't call it Minimal API for nothing. Jokes aside, what stopped you from calling validation yourself explicitly?
>What about hot reload being broken for years and years?
Can't comment on this, because I have never needed it. I can work faster with writing tests, but I guess it's fair to assume there are some who would need it.
Which version worked flawlessly? And I guess blazor can work great but that's super specific to what you use it for. Much more so than most front end technologies/stacks. And both WASM and Server versions have a lot of compromises.
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 avoided Blazor, despite multiple people on my teams pushing for it. It always felt like it fit in the same space as web forms and silverlight. A product created to fill a gap of developers that wrote desktop apps and don't want to learn how to write front end code for the web. Plus it binds you to the product lifecycle of a .net side project that likely will be abandoned.
While Blazor has some cool stuff built in, the cool stuff never felt worth the risk of building a product around it.
Honestly, I was wishing that Blazor was in the same space as web forms.
There is a market for front-end development that isn't steeped in the hell of actual front-end development. Blazor is almost the right idea but I think this incarnation is a dead end. Somebody needs to gather up all the pieces and figure it out for real.
Blazor honestly is great for 'I need to write a simple backend control plane for whatever'. I.e. internal only stuff where you care about just shipping something functional and don't care too much how it all looks/etc.
Further you go away from that circle, the less enticing it is.
Why is that? Do you speak from real-world experience?
Not trying to push back. We're planning to use it for some new projects we have coming up on our team of .NET devs who can't seem to grok Angular or React and the entire ecosystem of tooling required, so I'm looking for reasons we shouldn't use it aside from Blazor being rather unpopular compared to Angular/React/other JS libs
As grandparent said, Blazor optimized for fast delivery. For public products you will have places where you should care about interactivity a lot. Their solution is interop with JS. You may try WASM but it’s definitely slow for UI.
WASM good for complicated tools, but you better probably with other language if you looking for next Figma.
Hybrid approach which is default have two issues.
- round trip to the server. That’s not nice for interactivity and responsiveness.
- hybrid hydration model is needlessly complicated. And again it will not fully solve your problem when you need to go extra mile.
Overall cold start for WASM require large payload, for Hybrid you need Websockets for updates. That sucks outside of cities or on junkie mobile. Not for public product.
Working with Blazor from Net Core 2.2
For internal tooling, or B2B where you don’t care that much is very efficient.
If youre intent on writing everything on the frontend in javascript then you can just have a frontend app and use webapi MVC on the backend. Personally, in my personal projects, I find I iterate faster if I dont't write any javascript. Every page is just static HTML and any interaction is done via CSS (which you can do perfectly well in razor pages) or html forms. Managing page state is a huge time sink and IMO not worth it, but it's what pays the bills lol
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?
It's mostly about pay too. And yeah some people want more exciting jobs and maybe even outlandish stuff like the ones you listed (regardless of the sarcasm!). Yes at the end of the day most software isn't super exciting, but it doesn't make a tech stack or platform where most of your job prospects would approximate to "working on some run of the mill, mega enterprise or SMB software project" any more attractive for devs.
Especially when even its advocates somehow use that as an "upside". It might very well be for a lot of people! But it's also a massive turn off for others. I have never worked in a startup or big tech, and work on very concrete and critical products yet I'd very much rather work on even outlandish SV stuff (at least the pay is usually great and the job environment could be good!) rather than on some SMB CRUD or some generic backend service. If I don't have a choice I could do it but it's not super enticing.
For all of the "SV startups" that are working on hard tech problems (new DBs, LLMs, etc.) there are thousands of SV startup CRUD apps.
Most SV tech stacks are romanticized when in reality they are just are all mostly some flavor of a MEAN stack that is building a CRUD. The allure is the lottery payout and a clean slate tech stack, not that the specific tech itself is used.
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.
Create a hello world dotnet container, then do the same in a modern language. Then compare image size and resource consumption. Then imagine you're running tens of thousands of containers in a proper SaaS microservices model, and it'll make sense :)
Enterprise doesn’t spawn 10,000 containers to perform a simple “hello world” operation. That’s not how it operates. You’d be amazed at how many concurrent requests a single service can handle. This capacity must align with the actual requirements of the companies involved, not some unrealistic scenario like “we need to emulate Google.”
While that is small for a container and modern binary, I recall C hello worlds being 17KiB -- if only AOT/Spans/interop be used more to drive down those filesizes further.
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#.
The runtime alone is a bit over 200mb, and that doesn't include additional packages you'll most likely need.
That being said, I'd much prefer to deploy a C# application over Node or Java, no argument there. But saying "I wish more startups were using C#" makes me wince. C# seems well-suited for the monolith-architected VM-image-deployed strategy of the early 2000s, but it's pretty close to being the exact opposite of modern best practices. And unfortunately it's kinda unfixable in a language that depends on a VM execution environment.
I'm sure all this is short-lived however -- I'm relatively confident we'll see deployment best practices converge down to "use whatever language you want but you must compile to WASM" in the next decade, so the warts of devs' chosen language aren't an ops problem anymore.
But the runtime is in the base image, so that is shared across all deployed services on the a single host system(s). So it's much less of an issue, also, the entire runtime isn't loaded into RAM for every application. From Task manager in windows, I'm running a local app in debug/dev mode and it's taking 226mb ram, which is a lot compared to IIRC well under 20mb for the last rust-axum project I wrote.
That said, you get a lot of functionality in the box and nearby out of that extra resource usage and it doesn't really grow by much under load.
Beyond that, there's nothing particularly wrong about having a mostly monolithic backend for a lot of things, I would say most applications are better served starting with a more monolithic backend in a mono-repo with the FE.
C#/dotNet has Ahead of Time compilation that works very well with containerization. Obviously there are still overheads for the AoT runtime, but it is pruned.
AOT would solve a lot of these problems if it didn't have show-stopping restrictions like "you can't use reflection" and "you can't use native sessions".
Reflection doesn't work with AOT because there is nothing left to reflect on... it's compiled away. You can't use reflection with C, C++ or Rust either, doesn't mean you can't use them for useful things.
> 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.
Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
There are quite a few gotchas for this, especially web apps. THis is understandable because it was added after the fact, vs. a first-party design requirement. It's cool and might work for you, but taking a non-trivial .net codebase to native AOT can be tough, and if you're starting greenfield, why go .net?
FWIW, the .net folks seem to have put a lot of effort into the native AOT pipeline in the last few releases. We have a large, non-trivial application with a fair amount of legacy code, and getting it AOT’d in .net 10 (targeting wasm, even!) was not an insane lift.
How is the WASM target looking nowadays? I tried it in 2023 and early 2024, and it was far from complete (JS interop, poor documentation scattered across GitHub issues, and so on). I still can't find a single trustworthy source of documentation on how to proceed. C# would look great at the edge (Cloudflare Workers).
Sure, legacy applications won't be easy to move over but Microsoft has been quite consistent in working towards making microservice applications easy to build and run with AOT by moving more and more components over to using source-generators and promoting minimal-API's.
Their target is probably not entirely greenfield projects (although I wouldn't mind it myself), but rather those with existing investments that start new projects that still want to share some parts.
These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.
Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.
They're self contained and native, but they're still massive.
There's been some work on CoreRT and a general thrust to remove all dependencies on any reflection (so that all metadata can be stripped) and to get tree-shaking working (e.g. in Blazor WASM).
It seems like in general they're going in this direction.
Not every library is capable of building to Native AOT, which means any app that depends on those libraries run into the same problem. If the library or app uses reflection, it likely isn't capable of Native AOT compilation.
Just an FYI, Go still bundles a runtime in its native binaries. C#'s AOT has restrictions on what works (largely reflection), but these same restrictions apply to Go (although Go applies these restrictions into how it's designed for the entire thing).
>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.
F# is less popular, but it’s a first class .Net language with full MS support and integration onto .Net (VM and ecosystem). C# has been tracking F# and aiming for language parity for years (ie all your modern C# devs should be learning the same language facilities). F# is multi-paradigm so C# devs can write idiomatic C# with minor forced changes. And as a .Net language you can always decompile it into C# and keep going from there.
That’s a radically different proposition than, say, raw OCaml and not particularly niche. It also impacts hiring pools differently since competent functional C# devs are viable, but it tends to appeal to a certain calibre of dev.
Moving faster with fewer errors and more talented candidate pool are relevant to repackaged SaaS startups too. Leaves more time for the other stuff and scales better.
don't get me wrong - i want F# features in C#! I like the ecosystem and both languages.
I'm just pointing out that no matter how cool the language is if it doesn't serve business needs(hiring, onboarding ,ease of replacing staff, target market) it won't be picked.
I've worked with a lot of junior devs/graduates on a large F# project, in that context hiring/onboarding for F# hasn't at all been a limiting factor. Ultimately F# is not a particularly difficult language to learn.
Last I knew, Rider was pretty much the only IDE available for a large codebase when you weren't on Windows. Much love for Ionide, but it was a serious struggle.
VS Code with Ionide is okay but has many limitations for example in debugging or lack of support for F# fsi scripts.
If you’re serious about F#, investing in Rider or Visual Studio makes a lot of sense.
Having said that I wrote a Neo4J data extraction tool a few months ago and chose to write it in F#. At one point I observed how funny it was that I was developing in a Microsoft language and yet my dev workstation runs Fedora and my IDE comes from JetBrains and my code is running in kubernetes on a Linux cluster and there is not a sight of a windows machine in this whole pipeline.
I remember the days when the language, linker, compiler, IDE, the GUI components, everything was tied together. If you wanted the next version of VB you had to buy the new version of Visual Studio!
It's good for, and I am not being sarcastic or snarky, justifying high pay and gate-keeping. Developers should set up more barriers for entry - look at doctors and lawyers.
I think I agree with you. When I was part of a growing F# team a number of years ago, everyone we hired was an enthusiast who just loved coding in F# and wanted an opportunity to do it professionally. It turned out that this love, combined with the constraints of the language, led to a super-clean and legible code base. The quality was (in my estimation) outstanding, and I was sad to leave it.
I'm at my current company (actually writing mostly typescript and node services now) because of a YC "who's hiring" post that mentioned F# positions (bait and switch /s, but my experience lined up heavily with the team I ended up joining which didn't use F#).
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?
How important is being a language expert in x vs all your other skills as a Software Engineer? My opinion is that "higher level" skills (like system design/architecture, product thinking/planning etc.) are so much more important than language minutia (outside of specialized fields).
If a business is turning away candidates because they "don't have n years of experience in x" that doesn't sound like a very dynamic/interesting place to work, it sounds like a code monkey job. AI is going to eat code monkey jobs.
Before you can demonstrate your skills on the job - you have to get the job.
Most of the 2.6 million+ developers in the US don’t have “interesting jobs” nor do they care if their jobs are “interesting”. They work to exchange labor for money to support their addiction to food and shelter.
If you look at the requirements for most jobs they want you to have $x number of years of technology $y. When every job application gets 100s of resumes, employees can be picky.
Besides, every technology has its foot guns, ecosystems, way of doing things and people who think they can just pattern match based on what they know are often the most dangerous.
One example is that I’ve seen people who know relational databases, optimization techniques and normalization try to pattern match their understanding of OLTP databases when using OLAP databases like Redshift and Snowflake and it being a complete disaster.
See also people who don’t understand how to do a single table design with DynamoDB.
In my particular niche (cloud + app dev + customer facing consulting) , I knows AWS inside and out and have used more AWS services than you can imagine in the past 7 years in a production capacity [1] and I’m currently a staff level developer at a consulting company (full time), the only company that would (has) looked seriously at me to do consulting outside of working with AWS is ironically enough - Google.
But they have the bandwidth to let me ramp up. When I have one open req, why would I hire someone who needs to ramp up on AWS when I have a dozen applicants with experience? Why would I put myself at a disadvantage?
A company would be absolutely insane to choose me over someone with experience with Azure, or GCP as a staff consultant over the probably dozens of applicants they have with that particular skill if they were an Azure or GCP shop.
When my current company hired me, they were short staffed and gave me a week to onboard and flew me out to a customer site to do support a large sales contract. They hired me because I could hit the ground running both technically and without “consulting training” like AWS had.
[1] seven years of experience between 2 working at a startup, 3 working directly at AWS (Professional Services) and two working as staff consultant at a third party company.
Similar for us in magnitude of sized company, maybe a bit bigger. Lots of services are F# (internal and main services), but we don't advertise it that much nor want to. Every time we consider switching (even to C#) the developers want to switch back even though C# is a fine language. Its not perfect, but its enjoyable to code in all the same. At this point the stack is battle tested.
Yea, but then the other end has to serialise the HTTP API stuf to a typed object on their end.
It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.
I don't know about you, but when I code-gen from an OpenAPI doc, I get strongly typed object interfaces, so the serialization is in the box. No need to have a client distribution specifically, unless you want to wrap the generated client to make it easier to implement security layers.
If I had to manually create a client, then I'd probably go back to WCF (CoreWCF) which, again makes it easy enough to publish a client. For WCF in particular, I used to have one project with all the interface definitions and a client-generator that would allow for an "easy" single connection string as opposed to the XML bloat that is typical for WCF defaults.
All the same, you can definitely generate strongly typed clients to OpenAPI, provided the interfaces are well defined in the doc/generator/api.
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.
I sometimes miss Spring magic when working with ASP.NET, and I worked 12+ years with C# and only a year with Spring. Not saying one is better than the other, it's always a choice, less magic = more boilerplate and less boilerplate = more magic.
> and most language features don't feel bolted on like with Java (anything from functional programming to extension methods to whatever)
Java doesn't have extension methods and while both are decent languages, C# is the one that likes implementing every conceivable language feature immediately, while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.
> while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.
Java is quite busy also implementing features that are small in other languages like text blocks.
And I wish Java would design bigger features that would replace several "smaller ones", but that is almost never the case. It's almost always just a new big feature bolted on to the language that is almost there, but not quite
There are many reasons for that, none of them simple, and it doesn't help that there's also the attitude of "those lesser languages cannot compare to the greatness that is Java" [1]
If we're talking about Java, somehow you're still required to do builder patterns and manually create `.of` constructors for everything. Where C# has had object initialisers and pervasive IEnumerable with a very simple interface that nearly everything uses. And that is only scratching the surface of DX.
Almost every feature bolted onto Java seems to take several times more code, and doesn't really work with the rest of the language.
Don't get me wrong, I quite like working with modern Java. But I had the chance to work at a company where micro services where developed in both Java and C#, and the difference is still light and day.
> Java is quite busy also implementing features that are small in other languages like text blocks.
It's a small feature which is immediately understandable by anyone coming straight from Java 1.2, it doesn't materially increase the complexity of the language and is arguably one of the best implementation among different languages. So not really sure if it's a good counterpoint.
Meanwhile records arrived several versions ago with sealed interfaces/classes on the horizon already, so now they together form a complete ADT feature. Pattern matching builds on top. And sure, these are no novel features, MLs had this decades ago, but the implementation is very nice, with minimal additional developer complexity and some small DX improvement (records replace the majority of Bean usages). In the future, withers may come that would help with both object initialization AND record "mutation". Where Java spends more development budget is on the runtime side, e.g. virtual threads can replace async code in many cases, so the language doesn't have to get all the complexity of an async feature.
Meanwhile C# has many many "one-off" features and they really can have unexpected interactions and make the language quite a bit harder to understand. Some of them are absolutely wonderful, but I am on a "the-smaller-the-merrier" language team.
> It's a small feature which is immediately understandable by anyone coming straight from Java 1.2
You literally started with "Java takes a while to design a bigger feature that will replace several smaller ones' use cases".
But look, this small feature is not a one-off, and is actually useful because <arbitrary arguments>
> Meanwhile records arrived several versions ago
> Meanwhile C# has many many "one-off" features
Such one-off features like records and pattern-matching that C# also has? Or multiline strings that C# also has?
Or any other useful features directly impacting developer experience that you just dismiss out of hand because for some arbitrary reason you deem them "one-off" or small. Until they finally make their way into Java of course.
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.
What was the last Java version you used? There has been a huge momentum in adding new features lately, granted, it is slower than in C# (Java's top priority is backwards compatibility, so it does not have the luxury of shedding old stuff or changing them once they are in), but in the last couple of years it has improved tremendously. The JVM (especially in the garbage collection front) but also the language - half of an ML-style language is there (for example, ADTs and pattern matching), the other half is coming soon!
currently according to techempower benchmarks ASP.net is 55th overall in minimal variant, while being 83 in normal one in Fortunes benchmark which is basically a normal usecase.
Look at plaintext results if you want to compare just servers. Fortunes benchmark has too many variables (including db queries etc) to say anything about server performance. As for fortunes benchmark, for more realistick Java performance numbers I would look at Spring. Also there are many shady things on those Java bencmarks.
I think saying that Spring is the representative of Java metrics is somewhat equivalent to saying that full aspnet mvc is the representative of dotnet metrics.
On the dotnet side, both Oxpecker and Giraffe (Giraffe being written by the author of that post) perform very well with simple code and from what I see, no "tricks". It's all standard "how the docs say to write it" code (muuuuch different than those platform benchmarks that were rightfully scrutinized in the referenced blog post).
On the jvm side, I started looking for a reference near the top without any targeted non-default optimizations (which is really what I personally look for in these). The inverno implementation has a few things that I'd call non-standard (any time I see a byte buffer I imagine that's not how most people are utilizing the framework), but otherwise looks normal. I recall an earlier quarkus implementation that I read through a couple years ago (same repo) that wasn't as optimized with small things like that and performed very well, but it seems they've since added some of those types of optimizations as well.
All to say: If you venture outside the standard of either platform (full fatty aspnet/ef or spring/hibernate) you can make the tradeoff of framework convenience for performance. However when it comes to the cost/benefit ratio, you're either going to be joining a company using the former, or writing your own thing using the latter (most likely).
I do not have any benchmarks other than this[1] to refer to, but I work with Quarkus[2] and Java 25 LTS (just recently released) services deployed on AWS EKS and we are very happy with the performance (for mobile game backends)
Quarkus does a lot of bytecode generation magic at build time, which will give it an "unfair" edge in some scenarious, like this simple serialization/deserialization case in this particular benchmark.
Look at plaintext benchmark, if you want to compare just servers. Also look at Spring score in fortunes, which is the more common Java stack and I think a more suitable comparison.
> Documentation is vastly better compared to Java ones, it's like day and night
This is absolutely not my experience, especially when it comes to the ecosystem and third-party libraries. Like Java is pretty much the best in this category.
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.
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 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.
Most of your electronic devices work with embedded software. Production lines, transport gates, cranes, computer hardware, ships, planes, rockets, cars, e-bikes, smart lights...
There is also scientific programming, that feeds research and analysis. Weather reports? Statistics, etc.
And there is gaming.
Devops, infrastructure? Databases? Tools for artists? Most of those aren't web. And yes I've heard of Figma.
There are probably tens of categories I'm missing.
Web is still bigger probably, but I have a problem with the saying "practically all other development is web".
I didn’t deduce it from the name. I deduced it from over a decade experience working primarily with .Net.
Since I can’t presume the reader has equivalent experience, especially in HN, pointing to the name, which should be a good signifier of what something does (to be fair, MS really, really sucks at naming), is a good shorthand.
The real reason .Net isn’t good for embedded devices is because MS didn’t develop it for embedded devices. They’ve only added low level memory management in the past few years.
Until recently you couldn’t even create a fully statically compiled executable.
Define “practically all”. I would accept “clear majority”.
But practically all? Nah. I mean the hot new areas for funding right now are AI and robotics neither of which are web!
I’m coming up on 20 years professional experience. Exactly none of it has been mobile or web! The programming field is so much bigger than HN likes to pretend.
>I mean the hot new areas for funding right now are AI and robotics
Most developers are not in such startups. There is a lot of boring software out there which is a website. Even for AI, the first company that comes to mind OpenAI is known for ChatGPT, a web product. Most of the AI companies are building web products.
It's web in a (limited) sense that there's probably a web frontend somewhere, but this "somewhere" is usually pretty far away from where most of the code is developed.
Most of the backend logic is not related to serving data for the browsers, it's doing actual backend stuff - communicating to databases, APIs, etc.
Is Google search backend a web app? I think it's really stretching the term.
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.
It really depends where you are. In the UK half the places seem to use .NET in some form or another.
I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days.
The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft.
The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET.
I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.
They don't even know Rider exists a lot of the time. It is also quite different visually compared to Visual Studio code.
A lot of places have never used Linux at all and if they have they have it would be WSL or some RHEL box. So if you are screen sharing Gnome and with a totally different IDE and Terminal the person assessing you might not actually understand what you are doing.
> At least you can run SQL Server easily on Linux using docker.
1) They normally want you to use something like SQL Server Compact or SQL Server Express and a specific version. TBH I just don't bother anymore with these interviews because it takes like a couple of hours to get all this stuff working on Windows.
2) SQL Server Projects can only be used on Windows with Visual Studio. Some places do a lot of stuff "old school" and they want you to use that.
> It's just .NET that's largely ignored for no real technical basis.
As someone who has been developing primarily on .Net for the past decade this is absolute bullshit.
1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging.
2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways.
3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes.
4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc.
5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement.
6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all.
There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.
By recently you mean a decade ago yeah? I mean it’s fair that it was only a half-decade (.NET 5) when it was genuinely complete enough, but lots of stuff was in good shape when it was called .NET Core.
It sounds like you’re projecting the problems of an existing .NET shop onto the shape of a startup without all that baggage. I can assure you, having worked with many customers running new business on newer .NET, it hasn’t been a legit technical concern since about .NET Core 3.
A decade ago is when they started the transition. It’s been painful.
If you’re a new shop that is making decisions without looking into how the company that pretty much runs the platform you’re basing your future on has acted in the past decade (we’ll ignore how they’ve acted beyond that because then it’s a no brainer) then you’re doing yourself a disservice.
I see that you’ve narrowed the goal posts to just technical concerns, which is fair, but isn’t sufficient to make a decision about what technology to choose.
Especially in a field where you have a similar alternative in Java where the sponsoring company doesn’t have half as much control, as well as several fully open source alternatives.
While suffering the performance loss of V8 versus CLR, JVM or any compiled language.
One of the reasons I am back to writing more C++ code is C++ addons for node.js, as several SaaS products now only care about Next.js as extension SDK.
I don't think it's about dreaming to be Google. K8s is pretty easy to set up now with a hosted cloud platform if you start with it, and helm takes care of pretty much all your infra needs. Migrating to K8s is what's awful. From there, the docs have most everything you need to know and there's an abundance of helpful information online that covers most problems you'll run into.
I would love this to be true, but it isn't. I've done generating types for the frontend multiple times, sometimes from C# (around 2016, using typelite), Java (openapi template generator) and most recently straight from OpenAPI spec files (.yaml) using Orval.
It always has been a shitshow. It works well for the 90% cases, but in the 10% edge cases, things break. It becomes impossible to fix generation issues, you will often resort in working around issues in your backend/openapi code. Sometimes you report bugs upstream and hope it gets fixed. In the current project we are stuck on a ~2year old Orval version (a typescript generator from openapi) because some features broke or were removed in the latest version, and the entire monorepo (15+ LoB apps) wouldn't compile and would require major changes. This simply because a never version of the generator was broken/removed features previously present.
No, that's not true. If you share code like this then you can do things like put the same validation code in the frontend and the backend: frontend to give a nice user experience, and backend to protect the endpoint.
OpenAPI does support patterns for fields and nullables/non-nullables - that already gets you very far regarding validation. A decently sophisticated generator (which don't exist IMHO) would generate the validation code for your respective language.
Still one lang on both ends is nice: there are some bits of code you want to run on both ends (like templating for SSR/SEO/caching; but also using them in the browser).
Not really? Having come deom a TS + Go startup it’s pretty trivial to wire up domain objects across each language and define a clean API boundary with some enforcement at build time. And Go was a far better choice for the backend than TS for some lower-level memory considerations.
With TS you don't have to "define a clean API boundary with some enforcement at build time". You can use the exact same types you're using to enforce endpoint schemas everywhere.
You don't need a middle man like OpenAPI (which I've used and it's a mediocre solution).
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.
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.
As much as I think C# at a platform level is a better tool for building backends, you'll get the better bang for the buck learning TypeScript if you don't already know TypeScript.
Then if you have the chance, you'll find C# an easy transition from TypeScript, IME. Learning C# first, on the other hand, will make you a better TS developer, in my opinion, because it will shape your approach to be more diligent about using types. This is something most JS/TS devs do very poorly and at scale, it's very hard to reason about code when it requires digging down several layers to find the actual types/shapes.
"Enterprise" frameworks like Nest.js are much more similar to ASP.NET or Spring Boot than they are to Express, Hono, or Elysia so once having experience with .NET Web APIs (or Spring Boot) will make Nest.js (for example) easier to pick up.
Not really, you should learn Typescript by learning JavaScript first. Then consider learning C#. Or if you want to focus on the back end side learn C# and skip TS/JS.
They are created by the same person but they are very different in my opinion.
TypeScript is "a tool" for JS, it is possible to compile without errors but still fail in runtime (e.g. wrong object type returned from API), on the other hand parsing JSON with C# will give you correct object type, it may fail if some properties are missing but it will fail at parsing call, not further down when you try to use missing property. In other words typing is not glued on top of the language it's core of the language.
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.
I have tried it recently. It felt like I was coding Java. I realize "feel" isn't very objective, but I don't really like C-like languages in general. I like Rust, but only because of it's heavier FP-influence. C# is one of those languages where you don't mean to, but you can't help just creating tons of files/boilerplate/etc., which feels just like Java. Just my perspective, others obviously feel differently.
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)
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>.
>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
As far as I remember, cloning the project, sprinkling in some printfs and running it. He didn't want to use an interactive debugger. He was used to using the likes of nvm, uv, rustup, etc.
"Just" is an incredibly obnoxious word when used in the way that you have.
> Just install
Not on Debian? Have fun with that. You'll also need the Azure SDK. And what about openssl-dev? Oh no, you installed dotnet on Windows instead of within WSL? Start again.
No, you don't "just install" the SDK. There is a lot that the IDEs set up for you.
> Local nuget.config
I don't see how adding a nuget config improves anything. You have completely omitted what you place inside of it to make it build and use a local clone of the package source.
> 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 use Rider† daily to write F# and C# on my Mac. It works great, I have no issues with it. It even handles the .NET Framework 4.8 code‡ that I maintain without any issues thanks to Mono.
† And Neovim occasionally, but I mostly use it for Typescript or anything that isn't F#/C#.
>- Less bugs (Visual Studio has been progressively getting worse).
Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy. (Although admittedly, I'm not really up-to-date on the current state of VS in day-to-day work)
But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
> Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy
Obviously. IME it is better than Visual Studio.
> But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
I rarely use any of these tools tbh. I just want Resharper and something that works reliably on Linux. I would transition to using vim entirely but half the vim stuff I like using I can't use with Windows (work is never not going to use Windows).
I switched over entirely to Rider as well, in my experience it's far more performant, has a far smoother UX, has a lot more functionality for power users, and includes Resharper by default, giving you access to a bunch more powerful inspections and refactoring.
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?
Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.
The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
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?
C# has incomplete and often compromised versions of the constructs F# mostly took from OCaml, and as you extend those exhaustive guarantees towards formal verification you bump into F*.
C#s adoption of language features shows their utility but they’re not a replacement, per se. Without a clear functional answer in certain language and parallel computing scenarios MS would be ignored. Scala and Kotlin are comparable answers to comparable pressures on the JVM, and even keeping pace there with new and exciting tools/libraries requires some proper functional representation on the .Net platform.
F# will disappear when/if those other languages do, and already has lots of what C# is chasing with a more elegant syntax. It inherits VM and project improvements from C#, so the biggest threat to long term investment is something like the crippling changes made to FSharp Interactive (FSI), during the .Net Core transition. Otherwise it seems to be in a safe place for the foreseeable future.
Supporting as in maintenance mode, at least VB.NET. Thankfully F# is more community driven, but the CLR ecosystem is definitely getting C#-centric in the use of idioms and features from newer C# versions, which increasingly affects F# interop while they catch up.
.NET has always been both the biggest blessing and the biggest curse for F#.
We have access to millions of libraries. I look at BEAM languages and OCaml every once in a while but can’t quite drag myself over there, knowing that in .NET, just as an example, I can choose between a dozen JSON serialisation libraries that have been optimised and tuned comprehensively for decades.
But then, those libraries are also our curse. If you consume them, everything is OO so you either give up on functional purity and start writing imperative F# code, or you have to spend time writing and maintaining a F# idiomatic wrapper around it.
Similarly I was working recently on project to develop a library which was going to have downstream consumers. The problem lent itself really well to domain modelling in F#. But I knew that my downstream users would be C# devs. I could invest the time and write my library as “functional core, imperative shell”. But then I decided that since the interface would be OO anyway, I might as well just write it in C#.
Thankfully what keeps F# going is the wonderful community around it, not Microsoft. I know some people (outside of Microsoft) have worked on a standalone F# compiler but it’s still very early stages. Maybe one day.
Although you inevitably end up writing some OOP code in F# when interacting with the dotnet ecosystem, F# is a really good OOP language. It's also concise, so I don't spend as much time jumping around files switching my visual context. Feels closer to writing python.
The C# team admits to looking at how F# features work, but also keeps trying to make it clear that C# doesn't have a goal of entire eating F#.
C# still doesn't see itself as a functional programming language, even as it has added so many features. It may never get first-class currying or the broader ideas like generalized computation expressions, for instance. It certainly won't get F#'s cleaner syntax with fewer mandatory semicolons and whitespace nesting rather than curly brackets.
F# probably isn't going to disappear for a lot of similar reasons that GHC (the Glasgow Haskell Compiler) didn't disappear when F# was started (nor when key contributors left Microsoft). F# often already sees more outside open source contributors than contributions from Microsoft employees.
They killed off VB, which if I recall the announcement correctly, noted that it statistically had a larger user base (by Microsoft metrics) than F#. There are a number of companies relying on F# for critical operations and MS has some use of F# internally which I understand has no plans of replacement, which helps balance out the fear.
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?
There's still a lot of folks who consider themselves .Net experts who don't know how to program with async/await, so knowing about a niche IDE (which I also exclusively use) is asking a lot for those people.
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.
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.
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.
I've come to really appreciate Typescripts structural typing, because it reduces some of the overhead & prevents the unnecessarily tight coupling that has often annoyed me in other languages.
The overhead argument seems fairly objective to me - clean code with low coupling in C# et al. requires separate definitions of interfaces and implementations, explicit conversion methods between compatible interfaces etc. This adds up over time and makes refactoring pretty annoying.
The tight coupling happens when people don't bother to define interfaces. Suddenly I have to couple class hierarchy to classes from unrelated modules, all so the compiler is happy when I pass structurally equivalent data. To keep my own modules clean I have to add yet more interfaces, conversion methods etc!
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.
That’s a good argument. I had not considered properties in those terms before, and have historically been skeptical of them in many languages.
I’m partly convinced now! I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
> I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
Definitely a problem when a developer goes rogue and breaks this rule. I'm not sure if there are linters that helper with this. I don't think either VS, Rider, or the .NET Compiler include any analyzers that complain about this. If they do, I haven't seen the warnings before. I generally tend to enforce this during code reviews with my team.
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..
Ah okay, yes, debugging tools are a bit more friendly with C# but it's again the nature of the beast of cpp, but to nitpick this is a compiler area moreso than a tooling issue . CPP will compile direct to binary, whereas C# will compile to machine Lang iirc, an intermediary step anyway, so you can imagine it makes debugging much easier.
> to nitpick this is a compiler area more so than a tooling issue
If there’s one thing c++ is good at it’s bikehsedding where the responsibility for fixing this stuff is. When I started programming in c++ 16 years ago, modules were “imminent” and reflection was coming soon.
Modules are still unusable because what we’ve standardised is insanity and the standards committee refuse to make a decision to support the backwards compatibility of tooling and code that will never be upgraded or even used in a modern setting.
The compiler vendors blame the standards committee, the committee say that tooling isn’t their problem,and standardise something that has no theoretical objections but in practice requires deep concessions to the spirit of the idea. At the same time, they’re perfectly content to assume that everything is developed the way they imagine - adding ranges to algorithm and forcing the compile time because modules technically exist.
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.
Especially with the recent extension of STS release support from 18 to 24 months [1]. Previously, upgrading from an LTS version to the next major (STS) version meant the support window decreased by half a year, while now it would stay the same.
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.
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.
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.
In my brief testing just now, both extensions seem to be purely synonyms. Microsoft's documentation suggests that .razor is for Blazor components and .cshtml is for Pages, but even Microsoft's own templates are inconsistent on this and seem to use them interchangeably. The view engine doesn't seem to care what you call it and doesn't really seem to change its behavior. It really mostly just seems to underscore the difference between Razor Pages and Blazor "Server-Side Only" is real blurry to nonexistent. Obviously Blazor Hybrid and Blazor WASM have very different behavior from just Razor Pages.
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.
> a. Data Collection. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the software documentation. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft�s privacy statement. Our privacy statement is located at https://aka.ms/privacy. You can learn more about data collection and its use in the software documentation and our privacy statement. Your use of the software operates as your consent to these practices.
> You may not work around any technical limitations in the software:
> * reverse engineer, decompile or disassemble the software, or otherwise to derive the source code for the software, except and only to the extent required by third party licensing terms governing use of certain open-source components that may be included with the software;
> ...
> * share, publish, rent, or lease the software; or
> * provide the software as a stand-alone offering or combine it with any of your applications for others to use, or transfer the software or this agreement to any third party.
So you are not, for example, allowed to ship this in your application's docker image, you are in fact not allowed to redistribute it at all. So if you wanted to get a .NET debugger into your staging environment, you are not actually allowed to, unless you directly install it then-and-there with nuget. (I'm assuming we're talking about any type of enterprise context, where any given application is touched by contractors or employees from n>1 legal entities, so you are always distributing/sharing/transferring/making available).
Ya ya, I know you shouldn't have debuggers near prod, chiseled images, living off the land, yaddayadda. Regardless, it's needed or at least the easiest way at times, to actually be able to debug an application in staging or similar scenarios.
Also I'm not sure if e.g. blocking outgoing connections of the telemetry (even if by blanket policy) would already technically violate the license.
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!
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.
System.Text.Json is out-of-the-box in .NET > 5. The NuGet package is primarily a compatibility layer for people still supporting .NET 4.x for whatever reason.
> Why is there so much difference in the NuGet downloads between both libraries tho?
Because there's a boatload of older .NET apps that have been using Newtonsoft for over a decade already and aren't in a rush to switch. Anything built on .NET Framework is likely to still use Newtonsoft.
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.
I haven't tried it because it has generally seemed easiest to use the new attributes. Though a large part of that is the shift from the WCF-era "opt-in" approach of DataContract/DataMember [0] versus the "opt-out" JsonIgnore approach where most of the transition is deleting lines because JsonIgnore is the exception rather than the rule. You could even keep DataContract/DataMember during the transition and just take an additive approach for JsonIgnore.
[0]: It was a good idea, in theory, but so annoying in practice.
For me it was less not really about the opt-in part (after all, Newtonsoft works the same way) and more about stupid things like setting a name (DataMember), Enums, and in fact opting out (IgnoreDataMember)
It's especially annoying in libraries because the consumer might not even be using System.Text.Json, but you have to pull in the library anyway to apply its own attributes if you want it to work right. Just an overall awful smell given the existence of first-class framework attributes to do the same thing to avoid just that problem
That library is also out-of-the-box in the BCL in .NET > 5, though. It's not an extra install (except for projects stuck in .NET 4.x).
I get the desire to avoid that sort of redundancy in the BCL itself, but also explicit is better than implicit, which was the baseline theory for why System.Runtime.Serialization was the way it was even as it added more and more implicit "conventions", and if System.Text.Json supported the SRS attributes out-of-the-box there would be just as many complaints about "implicit magic" or it not following WCF conventions hard enough and that making it harder to migrate things using SRS attributes when you wanted different behavior in JSON serialization than you would want in WCF SOAP serialization. SRS has too much WCF baggage, unfortunately for all of us.
Perhaps what's left of the disagreement here between us is if System.Text.Json counts as "first-class framework attributes" and it certainly seems that way to me in .NET 5+, and especially as we celebrate the release of .NET 10. It's a small redundancy in the BCL, but it's still just "as BCL" and "first-class".
.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".
Every company should give developers $100 per year to donate to the open source project of their choosing. Right now the conditions are such that maintainers are incentivized to rug pull.
I love this. I've also been bandying about the idea of an open source equivalent of a B Corp sort of accreditation where a company can essentially brag about auditably donating to the open source projects that it depends upon.
Have you heard of the Open Source Pledge? Not exactly what you're suggesting but in the ballpark: https://opensourcepledge.com/
We'd probably just end up in a place similar to carbon and offset credits.
Hmm. My company gives everyone a $500 a year allowance for training and/or tools that we can use through OneRange. It shouldn’t be that hard to get approval to donate to an open source project.
This is all hypothetical. There isn’t any open source project I depend on that isn’t backed by a large corporation.
I've tried that and got heavy push back from other developers funnily enough.
Why? How does it affect them if you decide to use your allowance to donate?
Not affect them personally but more around what value is the business getting. We agreed to disagree :(
The value the business gets is continued development of free resources that they depend on. Not very hard :)
every company must pay enough to allow developer to donate from his own pocket (and each state to allow vat free donations without paper work).
Surely you don't expect someonoe that uses a particular piece of software only during work to donate to that from their own salary.
Obviously that'd be completely unheard of.
It literally puts food on your table?
Does it? If it didnt exist my company would need to develop it which still puts food on my table.
In fact it probably would put more food on your table.
Developers can always contribute as well but the benefits aren't really accruing to them. If open source libraries didn't exist there would be commercial offerings or things would have to be built in house. Also, $100 / year / dev is a rounding error and would add to a company's engineering brand.
It seems like a win / win to me but, of course, no one has to do anything at all. Just don't get upset when maintainers pull the rug out from under you because that is the behavior that is being incentivized: 1) make your thing widely used and hard to replace, 2) get in to large companies that can afford to pay 3) change license, pull rug and get your legal team ready to fight.
One need to see how many developers are already getting paid enough and out of them how many actually donating to OSS projects.
AFAIK developers are full of excuses like "these trillion dollar companies need to pay fair share while my hundred thousand dollar salary in this big expensive city leaves me with nothing to donate.
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.
In the world of LLMs the new version of "open source" is LLM makers using prompts which are then used in training leaking your code into the next version of the model therefore distributing your code for "free" minus your payments to the LLM maker.
It's probably a good thing because far from your "secret sauce" so much programming work is companies doing the same very boring things over and over connecting pipes together and making extremely similar design decisions for mundane tasks.
Programming is just a means to a way and a waste of time if it can be automated. Making useful things is all that matters.
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).
[flagged]
Wix was open sourced in 2004 - https://www.computerworld.com/article/1580079/microsoft-goes...
Come on, it's clear he meant "commercial libraries not in the default Microsoft SDK".
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.
Moq, lots of PDF libraries, Avalonia, Automapper, MediatR, MassTransit,Telerik stuff,etc.
I'm not inherently against it, we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.
Avalonia is FOSS (MIT licensed). You only need Avalonia XPF if you are migrating legacy stuff.
Moq is largely unnecessary today with LLMs being able to easily generate mock classes. I personally prefer to hand-roll my mocks, but if you prefer the Moq-like approach, there's NSubstitute (3-BSD).
Automapper and MediatR are both libraries I avoided prior to the license change anyways, because I don't like runtime "magic" and not being able to trace dependency calls through my code. But, there is Mapster and Wolverine to fill those needs (both MIT). Wolverine can also replace much of MassTransit.
Telerik stuff - there are many good FOSS alternatives to these UI components; too many to list since it depends on which stack you're using.
PDF is indeed a sore spot. PdfPig is good, but limited in capability. I've started offloading PDF processing to a separate Python container with a simple, stateless Flask API with PyMuPdf.
> we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.
Completely agree with this, though. My company and myself personally contribute a lot of time back to OSS, and I feel like that is part of the social contract of OSS. To have these libraries rug-pulled feels like a slap in the face as a OSS contributor and maintainer.
PDF is an enormous festering wound in .Net. I've also been doing .Net since day one and never bought a single commercial component. Used it to build some massive commercial products all on OSS.
BUT. PDF has always been a nightmare. It's made a lot better in the last year since LLMs have vast knowledge of all the functions available in each of the .Net PDF OSS libraries and can usually find a way to do the thing I need now. (I've even had them just hack the PDF streams to do something when there is no library to do it as they know the whole spec)
I agree with almost all of this, especially MediatR being nonsense, but I would recommend against using a LLM to generate a mock. That’s just more code that you need to maintain and update on every interface change. NSubstitute is a fine library.
Another popular library that went commercial is FluentAssertions, Shouldly is a good open-source alternative.
Any recommendation of good alternatives to Telerik? We've been using it for years, but I'm open to considering alternatives even though it doesn't cost me anything to pay for the license.
Depends on what layer of Telerik [0]. Honestly of late since I'm extra rusty on frontend I just get Copilot with Claude to help generate UI widgets since that's allowed.
Before that, years ago, I just YOLOed with WebSharper and built composition helpers to make 'spartan but correct' UIs that could be prettied up with bootstrap if needed.
That said, alas, Bolero (what replaced WebSharper) is F# specific rather than also supporting C#.
I mostly bring those up because they have various libraries out there to work with different JS bits.
[0] - Cries in webforms
We're planning on using Blazor, so any Blazor UI components that you recommend?
MudBlazor is decent.
Wolverine replacing MassTransit yeah kind of works but just today I had to dive in and I did not like it.
“team decides” and I was busy with other stuff when they were doing evaluation.
But I would gladly pay the license there is just so much just working out of the box with mass transit you don’t realize until you miss it.
We use it with RabbitMQ.
There are a few non-paid PDF libraries, but that is the biggest pain point in .NET, anytime you need advanced features for PDF, you're better off paying for a license (it's just insanely expensive unless you're a large company).
Having worked on some basic parsing of metadata from PDF spec, I would rather pay than have to code something myself. PDF is such a PIA.
I've used libqpdf extensively from C++/CLI with excellent results, but since C++/CLI is deprecated-ish and Windows-only, I wouldn't disagree with PDF being a pain point, and if I get the time, a cross-platform open source .NET wrapper for libqpdf is at the top of my list of potential projects.
libqpdf also intentionally limits its scope to PDF structure, so doesn't address nontrivial content creation or manipulation (page content handling is pretty much limited to compressing/decompressing and parsing/unparsing the content stream).
AFAIK pinvoke (DllImport) works today just like it always has if you want to create FFI calls to C libraries. It's not windows only for sure.
That brings you back to managing memory though, C++/CLI having access to managed C# handles/references for GC'd objects (and finalization) would greatly simplify any memory management at the same time as having first class access to native libaries.
Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native interfaces.
I've used p/invoke extensively. You can easily make your own managed handles. It's not as easy as straight up calling c#, but it's not really that bad either.
It's not that hard to create a C# wrapper class if you need to hold on to pointers that need to be cleaned up by the C code... you can keep a private property reference and call the appropriate C code as part of your Destructor or IDisposable implementation.
If you're wanting to use a C library, yeah, you need to manage how you use that C library, this is true regardless of the language you are using, it isn't magic.
IDK, for certain cases those fancy libraries are just handling the ugly marshal calls for you.
Wayyyy back in the day, before package managers were a thing, I had to write something to output a PDF via DLL calls and frankly it wasn't a bad experience. Possibly outside of what is in a 'modern' workflow but honestly wasn't too difficult. Just wrap it all in a class that only gives what you need and avoids potential footguns via validation.
Frankly it was easier than doing anything with Autocad's 'managed' libraries [0].
Maybe it's rose colored glasses for me, but .NET had fairly simple rules for most marshal bits so long as you knew them, although I will admit we didn't worry about 'performance' for the stuff I wrote and that can be a factor.
[0] - Microstation had a bunch of fancy COM hooks and exposed all of it to .NET in a nice way. AutoCAD 'managed' libs had all sorts of weird sorts of arcane rules and if you failed to follow them not only could you crash your .NET process but Autocad could remain unstable until you rebooted the PC... which is why I keep putting managed in air quotes.
For pdfs render the, in html with razor and then print as;df with puppeteer. If you need custom headers/footers, add something like https://github.com/PejmanNik/puppeteer-report-csharp
Any PDF libraries in Java that would be free and having all the bang?
I just have PDF micro service where I use puppeteer. But I could swap it to Java micro service easily.
I can confirm that (several years ago at least) free PDF libraries were lacking, and Telerik was always non-free.
However, aren't Moq, Avalonia and MassTransit free software?
As for Automapper and MediatR, their owner changed from a free software license to only an open source one (Reciprocal Public License), but these are probably the simplest libraries of the ones you mentioned and have either been forked (MagicMapper) or have alternatives.
Yeah pdf libraries are a bit of a mess, I work with a product that handles lots of PDF documents and I think we just recently added another PDF library dependency (I'm certain it's at least 3 now, but could be 4 or even 5 libraries loaded at startup).
Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Masstransit went commercial recently, https://masstransit.io/introduction/v9-announcement
Avalonia itself is opensource, but i'd put in in a fremium/shareware category since if you need to add an WebView or Media player you need to buy their commercial Accelarate additions.
> Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Well they pulled back but the trust was broken in a lot of cases. I am still fine with it 'for now' but IDK NSubstitute always feels weird to me, maybe that's just how I was taught to use it tho.
> Masstransit went commercial recently
I mean good for them but thankfully it's also giving attention to other projects that are FOSS or Open Core...
As far as the other stuff, I've never seen AutoMapper used in a way that couldn't literally be handled with a static/extension method in 'real' code. Yes it can be useful but it is often grossly overused.
MediatR is cool but TBH I'd rather just reach for Akka.NET or MessagePipe instead; If you're abstracting out to keep processing backend 'swappable' you should be able to handle any of the above for the choice you make anyway.
I created a Moq lookalike in an evening a few months back, it's not a hugely advanced project honestly (if you're used to working with the reflection system).
Not OP but I still run into paid libraries (eg Telerik) all over the place in projects.
I never liked their stuff myself, and generally avoided them.
Same here, but "enterprise" dotnet developers generally seem to need "more help" and love this kind of stuff.
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?
Just one example, but when I was running a .Net dev team we licensed the Telerik UI components. We ended up dropping them, but not until we had initiated a migration to Java/PG instead of C#/MSSQL. After we moved to Java everything standardized of a set of FOSS libraries for various things.
We use Telerik components at my current job. They're a solid library, IMO. I'm sure there's better out there, but we've been using them for nearly 15 years at this point and I feel like we get decent value for the money, and their developers get to draw a salary.
I'm not sure how that applies in this situation, since you're choosing to buy into a proprietary platform when plenty of open-source competitive options exist. That's the case for every language/tech stack.
That's a choice, there's lots of FLOSS alternatives... was this a desktop application? In that case, I can see wanting to chose a commercial library as it probably saves a lot of work with the floss/in-the-box alternative options.
That said, for a web cli, there are a ton of options out there without touching anything commercially licensed.
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?
I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were:
1. The overall architecture (with the JVM) made it slower than the equivalent C# code.
2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then.
(Not OP, disclaimer, I work for Microsoft and this is only my opinion).
Ah, got you.
> I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were:
It's almost a shame. I am genuinely impressed with the gains the team has made in both, language aspects as well as JVM technology. They have some brilliant people working on it and I love to hear their talks (Brian Goetz and Mark Reinhold, mostly).
But I suppose I would say the same about .Net, it's just that you guys have much less public exposure of your internal reasoning.
I've seen the gains in Java; the main things that would close the gap are not yet there in Java. .NET code, especially when tuned, still has significantly more knobs in your code to tune and make faster. An example would be proper generics with value types together means less boxing in generic code in general overall but there's a lot more I can think of. I've seen almost 50% of gains, particuarly when doing math like code, of moving away from Java to .NET especially if the jump to C/C++/Rust is too much for the team in question due to other requirements.
C# and Java might be similar technologies at some level but they not similar developer experiences at all.
How so? It striked me that the .Net library and Java frameworks like Spring or Quarkus are virtually identical.
There's more to developer experience than that. Your comment even demonstrates one of the differences: The .NET library compared to a bunch of different Java frameworks.
That is indeed a technical difference. But I don’t see much significance in it.
Spring is a de-facto extension of the core java libraries and alternatives like Quarkus follow the same mental model with a better technological foundation.
Maybe, but with all the modern .NET tooling I feel at least 2x productive in .NET than in Spring Boot. There are a lot of quality of life stuff in .NET/C# that really does add up and makes a substantial difference (DX-wise) in the long run.
The culture around Java and C# are very different. I'm not sure I can explain it.
I could continue to point hundreds of technical differences but that's the trees and not the forest.
C# 1.0 was pretty much Microsoft Java, but since then, C# has evolved into its own, more powerful thing, while Java has stayed much more conservative over the years.
I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.
What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.
I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.
> I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today.
Have you never written a plugin or a mod?
Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features.
As soon as you AOT compile CLR or JVM languages, you lose access to the stable, feature-complete ABI that bytecode provides. Heck, many languages built from the ground up for static compilation like Go and Rust still have dismal ABI stories. The only exception I can think of is Swift, and it didn't come by it easily. AOT also imposes limits on reflection and runtime codegen (often, to the point of totally removing them).
If your software exists only in a walled garden, only gets deployed to infrastructure you 100% control, can't be extended at all, and/or can only be extended by full recompilation, then bytecode may seem useless. But that isn't the whole world of software.
.NET needs runtime code generation for some of its core features, like generics. Bytecode makes this much easier.
I agree that .NET uses bytecode and likely cannot practically remove it outside of narrow cases. My argument is, if .NET were a greenfield project, they likely would not use bytecode today.
I think this was a fair statement up until a couple years ago, but right now I am lamenting the actual progress in C# and CLR technology.
I think the progress on Java and the JVM has been nothing but impressive. Not only compared to the baseline to where things were 10/15 years ago, but simply how much stuff comes out each year and how well-thought it all is.
Frankly, it's an inspiration for my private and professional projects.
I wouldn't call this a silly question at all. But having recently converted my intro data structures course from Java to C#, I can talk about why C# might be better. I have programmed regularly in both languages for the last 15 or so years (in addition to regularly programming in TypeScript, Scala, and F#).
Java is fast and reasonably safe. It has a lot of software (especially OSS) software. Its package system (Maven and the like) is ok, but not great. The language occasionally gets new features, but change is slow.
To a first approximation, C# is a lot like Java, so it is relatively easy to switch. But C# is, hands down, a better language. The most obvious thing that a developer might notice that that C# does not force you to be extremely verbose like Java, although you can code in the Java style if you like.
Having switched my course from Java to C#, the most obvious "win" was the fact that, every lecture, I would delete some slides that explained painful Java corner cases to students. For example, Java's implementation of generics. Boxed types are necessary, and explaining them to students who have never seen any form of polymorphism before is difficult. After an entire semester of deleting a handful of slides each lecture, I have save _three entire lectures_ worth of corner cases!
Some C# niceties:
* Everything is an object, even value types! So our favorite `ToString` and `GetHashCode` methods, etc, are all there. * Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object! * The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool). * By default, reference types are not nullable. This is a little bit of a pain for an intro data structures course (we turn them off), but it is a great idea for commercial programming. * switch statements work the way you would expect a modern switch to work, and in some cases they even do exhaustiveness checking like a functional language. * Speaking of... LINQ! * In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>. * Type inference is limited compared to a functional language, but it is dramatically better than Java. Being able to write `var` is wonderful. * Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time. * C# has a rich set of value types, including structs. Java may have added something like this, since I remember the Scala people hacking away on it, but it is used pervasively in C#, and you can make very fast data structures that take advantage of spatial locality. Rolling one's own hash table implementation in C# is actually kind of fun. * .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things. * NuGet is a million times easier to use than Maven.
The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually.
Anecdotally, my students this semester are demonstrably more capable programmers after a semester of C# than a semester of Java. It might just be that I got lucky with this group, but I have been teaching this same course (except in Java) for the last 7 years, and this feels like a real effect.
This is interesting. I've been away from the high-code world for a while and instead of going back to Java, I might try out c#. Thanks for the writeup.
I'm not new to C# myself and I have been writing a hobby game project in it for the better part of 2 years. I know the C# features pretty in-depth by now, and while you can definitely make an argument that C# has more and better features, I found that Java has greater synergies in its features.
Don't get me wrong, there are some features like "abstract static" in interfaces which give C# superpowers... until you realize that this only works one layer deep. Or the non-break switch expressions, which require a return type. Lack of an equivalent to Java's "Sealed Classes" (that you can switch over). Or that you can't validate primary constructors up until recently.
Lack of value objects are definitely hurting, but JEP401 addresses this and is available as preview as of now. I am absolutely blown away by the depth of their value-narrative and I think they uncovered something much deeper than "value or not" with gradual performance gains based on gradual constraints.
But I absolutely see the value of C# in teaching. Java works more via libraries and convention, whereas C# has ingrained many concepts directly into the syntax level.
But maybe I am a Java fanboy, haha. I even prefer the Erasure of Generics, the times it has complicated my code in C# is much higher by now than I ever thought it would be.
> Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object!
Took me a moment to realize you meant that 'Java has corner cases because everything is an object' but yes.
Will also add the 'advantage' that for value types (i.e. struct) the generics are 'specialized' for the type, in certain cases you can use that for performance optimizations. (although it can have downsides.)
> The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool)
And, fun side note, the generic arrays actually existed before real generics (and we get fun hacks in the VM as a result!)
.NET does still have funkiness around Array Covariance tho, which sometimes can be a pain.
> By default, reference types are not nullable.
This is a newer feature and great, however it requires people to (1) use libraries that properly do it and (2) requires you to have the right tag in the csproj to flag the NRT warnings as errors. I've yet to see a shop that has adopted (2) as a default.
> In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>
Yes and also the sugar around yield syntax to do generators.
> Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time.
I still remember getting called into a Dev Manager's office, he's a JVM guy and he's goes into this overview of Lombok and how the JVM folks want to use it and he asks what I think and I'm like "Gee wow give me a moment I thought Java had AutoProps by now". (I think it was the first time he was impressed with C# as a language lmao, He and later I were disappointed in .NET's lack of a good set of thread pool abstractions...)
> .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things.
That is so freaking cool and I love it. Profs like you made college fun back in the day.
> NuGet is a million times easier to use than Maven.
Truth; every time I have to do a thing in JVM dealing with maven feels like I need a goat or chicken to make anything work right.
> The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually.
We have AOT and R2R nowadays, I'm not sure if it's 'JVM Fast' for something like a webservice but unless you're pulling in something like an ORM it's typically fast enough I can't observe a difference as a user for utility apps/etc... Curious what examples you have in mind?
The thing that always turned me off about Java are the IDEs. Besides Java doesn’t have anything like LINQ. I would rather have an ecosystem backed by Microsoft than Oracle.
Does Java have real generics yet?
[dead]
What is wrong with paying for something that is useful?
Seems like many people are just coding as a hobby? Idk. I want to make money writing software and so I pay for libraries that solve a problem for me.
I expect the baker who sells me his bread pays for the flour.
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).
C# is pretty popular in the US as well in certain spaces... especially Govt or Banking and adjacent environments. Mostly line of business applications. I'd say Java is slightly more popular, but I never really liked Java's ecosystem ergonomics, though they're better today it's just not for me.
Similarly, I'm not a fan of "Enterprise" development regardless... I find a lot of .Net shops, like Jave, just create a lot of layers of indirection and abstraction that only lead to excess complexity, cost and difficulty in both maintenance and enhancement. The older I get, the more my mindset shifts to make things that are easy to replace without adding undue complexity or patterns.
The problem with enterprise apps is that they're usually wide but shallow. Which means a ton of classes that don't do a lot and managing class complexity is actually the biggest challenge.
So it's just a very different type of code and you can point at the language, but the reality is that it's the domain.
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.
As someone who has written multiple Node and C# backends, Node isn't even close to the ecosystem quality. It's not in the same solar system.
Npm has tons of libraries, but they're mostly abandoned. Many barely worked in the first place. And if they're even a little out of date, there's a decent chance they're missing TypeScript types or they won't work with your module system. It's a nightmare.
Struggling with missing or broken dependencies is what made me swear off Node backends permanently.
Well yeah I like how they boast numbers of libraries and numbers of downloads but most is crap.
Sure, with quality libraries like "is-even", who can deny the supremacy of the JS ecosystem?
https://www.npmjs.com/package/is-even
Wow thanks, a perfect package, just what I was looking for. I needed something to determine is even values.
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.
The Dallas area is a major tech hub. It’s just an older hub of major enterprisey type companies with major tech divisions there like Texas Instruments, AT&T, Bank of America, defense contractors like Lockheed, etc.
Office Space took place there before the dotcom bust.
Less enterprisey, but John Carmack and id Software also started there.
I lived and worked in Atlanta from 1996-2020. Those aren’t anymore tech companies than Delta, Home Depot or Coke by modern definitions. In all of the companies you named, software development is a cost center, not a profit center - follow the money. Who gets paid the most as a group at those companies? Those are enterprise companies.
You’re saying the same thing I did yet somehow you’re trying to argue with me about it.
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.
>> we use .NET for backend and React for frontend. You don't need anything else
...
>> sure maybe you have some data science people who need python,
This is how it happens though; it's not "let's form a company with 10 developers; don't worry what tools they use!". It's starting with a single problem using common tools, then adding specialized problems where you could still use the same tools but they are not optimized, then adding an acquisition product that uses different tech, then growing to 100 or 1000 developers and may all use React or C# (doubtful) but don't use it the same way...
>> If you're going to make a change then migrate everything
Have you ever worked for a software company before? THis is not how it goes.
> This is how it happens though
No it isn't. This is not how you end up with 7 different frontend JS frameworks in 7 different web applications. Using python/matlab/r for data science is completely fair. These languages are standard in this field, they have the most tools and built-in functionality for this purpose.
I mean if you want to do ML and data science stuff in C# or whatever go right ahead. If you can make that work that's great. But I also think, as someone who aggressively promotes sticking to one language, that it's fair to use Python for data science.
What I don't condone, as I said, is using multiple tools for the same task. So for example, having one team/dev using Python while another uses Matlab and yet another uses R etc.
> Have you ever worked for a software company before? THis is not how it goes.
Yeah, I know. That's the problem. People just introduce new tech like it's nothing. That's why I'm saying it needs to be a big decision. So if it's really worth it okay let's go for it. But for the vast majority of cases it just isn't.
It's bad enough when you've got constantly changing "best practices" from MS so the thing you wrote last year doesn't look anything structurally like what you're doing now.
And all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.
So you don't like .NET, that's fine. I'm not saying everyone needs to use .NET. I'm saying pick one thing and stick with it.
That said I think you're exaggerating those complaints, the docs for C# are quite good imo and I've been working with ASP.NET web apps for half a decade so far and I'm not seeing any problems like you're describing.
Maybe you're miffed about the Framework to Core/.NET switch? That was a bit of a doozy but the ecosystem is so much better for it I'd say it was worth it.
> the thing you wrote last year doesn't look anything structurally like what you're doing now... all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.
This is indeed a complete exaggeration.
Sorry, I love .NET and have used it from it's rollout back in 2002.
I'm just fondly remembering the ASP.NET MVC churn or more recently, Azure API whiplash.
I get you actually.
MVC churn was real, EF Churn was real, heck NETCORE itself was a (at least warned about) churn, 3.1->6.0 was minor but still definitely a thing [0].
[0] - Now that I'm thinking it out loud, maybe that's why they changed the branding from .NET CORE to just .NET; The churn was more or less 'done'...
I'm only now deprecating a netcore 2.2 API that used a 4.8 framework domain/repository layer. At the time it seems like a good idea and it received automatic security patches.
Online forums often have people asking "hey I found this tutorial for learning c# but it's way way back for .NET 7 will it even work in .NET 9?"
The answer is always a variation of "yes, you'll be fine, but also look at a "what's new" summary for the new version.
> People love to talk about the right tool for the job, it's all BS
This sounds very close minded to me. It is certainly true that there exist tasks if not subdomains where some ecosystems are better than others. Using a hammer for everything might work for you if all your problems are nails. But that doesn't mean that all problems out there are nails
If your organization has one API written in Node, another in Java and third in Python without any reason, then yes, all the problems are nails. And sadly, I've seen this a lot.
I've have limited success using codex to do code conversions for multiple projects into one standard team language. I suspect this will only improve and is how this "problem" gets solved soon'ish.
If you can justify with good reasons why you absolutely need this other tool then that's fair game - hence the data science example where I allow for specialists to use specialized languages for specialized tasks.
I'm talking about general software development and web dev in particular. There's a trend where you'll see one org has or web app using .net ad react, another using next.js, another using Java and Vue, one djnago and htmx, and so on.
And there is literally no reason for any of these choices, they're all fairly basic web applications that could have all been made in literally any half decent web stack. So whether the devs who made these choices knew or not, they made them based on preference not any kind of reason or need, they're all nails and any hammer would have done the job just fine.
>> And there is literally no reason for any of these choices
I'm a manager now but definitely held a variation on this "people are idiots" view when an IC and younger. Question: are all your coworkers idiots? No? then why would all the work done before you be the product of idiots?
I found it really valuable to approach scenarios where the initial response is "how could this possibly happen?" as a cultural anthropology question. It turns out there were many rational decisions made, most that I would have gone along with that brought us to what we see today. My coworkers are actually really good, some of them who manifested what we see today are amazing. Many are crafting code, making thousands of microdecisions without perfect information or 100% clarity across a large organization, reacting to changing markets and directions, client needs, shifting priorities, executive decisions, technology changes... the list goes on.
This is all my way of saying there might be many reasons for any of these choices, and you'll help your own cause - and happinness - if you step back from your zealotry and take an empathetic approach that's less binary.
Some of my coworkers are awesome. Super talented, super smart people.
But most developers are pretty bad. I see a lot of developers who hardly do any work at all, and many who do lots of work but it's all trash. Buggy, overcomplicated, untested, dumb pointless decisions.
Like my current project. Two guys started it - .NET backend, React frontend. Sure, fine. But let's use Azure functions for the backend instead of a regular web api. What. We asked them why, no reason. And their whole codebase was trash, I've deleted about 90% of the code that they had written and I'll delete the rest too.
I've also been in a team that had the problem I highlighted in the OP. 20 different apps, 10 different JS frameworks etc. Speaking as someone who worked on these apps, there was absolutely no reason to choose one JS framework over another. I could have made them all in React no problem, they're just websites, not much more than glorified PDFs. How you generate the html is irrelevant. And the code was mostly trash. Overcomplicated, buggy, untested etc.
I did struggle with this early in my career - am I just a narcissist? Everywhere I turn the code is just trash, maybe I'm the problem? But now I've worked with people who do good work. I've seen my own ideas work in practice. I know for a fact my judgement is good.
In university I was the one who helped everyone else. I was always ahead, while my peers could hardly keep up. When we graduated a lot of them would have struggled to solve fizzbuzz in 20 minutes, yet we all have the same degree. No wonder there's so much trash code around.
Using the right language for the problem domain is a good thing, but what I can't stand is when people self-identify as the one language they are proficient in. Like, "I'm Staff JavaScript developer" no buddy, you aren't "Staff" anything if you only know one language.
Do you also make everyone wear the same clothes, drive the same vehicle, order the same food
> Do you also make everyone wear the same clothes, drive the same vehicle, order the same food
I don't think this is an valid comparison. There's a problem called technology sprawl, which is characterized by needlessly increasing maintenance needs and cognitive load and lower development speeds caused by the need to juggle multiple programming languages or frameworks. There is a fixed cost in maintaining each tech stack and even development environment, and you multiply that cost each time you think it's a good idea to introduce yet another programming language or framework.
> Do you also make everyone drive the same vehicle
Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.
How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
> But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.
I think that question is more "how many different makes of van can your delivery company afford to maintain?"
Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"
The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.
The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.
Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that. Vehicle fleets are often aging out with these timelines.
So if we either stretch the fleet management analogy to 50 years, or software applications only lasted 3-5 years maybe it IS fair to say the both have either a lot (former) or very little (later) inconsistnency?
> Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that.
.NET gets refreshed annually. The last bigger change was nearly a decade ago. So not all that different.
But I don't think that the analogy stretches, really. e.g. where I am all .NET apps are .NET 8 LTS or 9, and will be all be .NET 10 LTS by middle of 2026. You can upgrade an app to a new model year much more easily than a vehicle. The "software application, on a SDK major version" only lasts 1-2 years.
Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks.
I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.
Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
>> Yeah, .NET is a truck and React is a bicycle
I'm not a car guy but I most certainly a bicycle lover, so I will jump on you and say you often need more than one type of bicycle. Joan commutes to work? she wants a city ebike. Dan rides at the bike park? He wants a DH bike. Randy ride centuries on the weekend on his TDF road bike and Sally rides with her kids on a mountain bike.
So yeah, we can pick one bike type and force everyone to ride it, and the results will suck & everyone hate it. Your job can be to continually force everyone to follow this policy or you can stop and we'll get a lot of variation. THis is how it happens.
Eh, no, you don't hire those employees. You're stretching this analogy in some odd ways.
Well, they clearly all know how to ride bikes, so you offer to hire them to deliver using company bikes as a day job. And let them ride whatever they want on weekends.
The "force everyone to ride it" on the weekend part is where I think the analogy has broken down irreparably. We're talking about cost of ownership of company equipment used during working hours for much more defined tasks. What flavour of bike you enjoy riding on weekends is not relevant.
Programming language are inherently flexible, especially those that aim to be "general purpose". Fine-grained distinction of road bike vs mountain bike apply more to the apps created than the coding tool.
> Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
Yes, this.
> I'm saying use one tool for one task.
I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.
> Yeah, .NET is a truck
I know one person who was good at python, and who looked at the "classic" .NET hello world app with usings, namespace, class, main method etc containing the "Console.Writeline" payload, and noped out immediately, saying "if it's that verbose that it takes 10 lines to do what's 1 line in python, imagine how terrible real code must be!"
Personally I think they were wrong about that - it was optimised for larger programs, not trivial ones.
But also it helps me understand the ongoing push towards the point now where "hello world" is is 1 line in 1 .cs file only. And `dotnet tool exec` means you don't even need to install a utility to use it, etc.
In other words, .NET started life as a truck, with many features to support large codebases - usings, namespace, class, method etc. but is also general purpose enough that you can now also write a "bicycle" program.
but they all delivers, just that they don't suit your taste doesn't mean it can't
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)
Do you measure that standard by leetcode?
No, we don't do any coding tests, just discussions of what you've done and how deep your knowledge of your tools goes. .NET folks are far less likely to understand much beyond the syntax, nevermind the "why" of things (even WHY you need StringBuilder) or what a database index is, etc.
Interesting. One would thing, "script kiddies" would be more common among Pythonistas. On the other hand, .NET might be more user-friendly, so that devs are productive even without the knowledge of what's going on under the hood. Kudos for the interview practices, that's similar to how I conduct as well :)
[flagged]
> Apropos, what do they do for fun?
Odd question, but as a .NET developer myself
Mountaineering, climbing, bouldering, going to gigs, playing pool, running, music festivals, gaming, photography, watching F1, watching NBA, eating out with friends...
I'm not sure what the point of the question was ?
Ah, well, obviously the point of the question was to be odd for oddness's sake, as some form of bizarre, self-inflatory social ploy!
I couldn't possibly have intended my question as a straightforward request for information about something, now could I?
That would just be weirdy-weird, if people started asking each other questions for the purpose of receiving answers.
Thanks for answering though.
The reason I thought it was odd was that I've never seen any correlation between someones hobbies outside of work and what tech stack they use at work.
That's OK. I keep seeing a correlation between people's proneness to be like
>The reason I thought it was odd was that I've never seen [it]
and which tech stacks they feel more comfortable with.
> what do they do for fun?
Play in a band, ride bikes, play video games. Sample size of one.
>Play in a band
Cool, what genre?
Rock mostly covers. I play keyboard. Trying to learn to sing. Progress is mixed.
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?
Been awhile since I've worked at one but it is usually grounded in trying to achieve 100% MS usage.
It is rarish to find a partial MS shop. Most of this is how hard MS makes it to use other tools. Even in 2025 they have good interop with external tools hamstrung.
Example: SQL Servers JDBC driver will convert an entire table's of data from ASCII to UTF and a full table scan instead of convertering your UTF bind to ASCII and using the ASCII based index. This doesn't break interop but does make it painful to code and one more reason to just use .Net.
Not that rare, I work in one now and we use: .NET, Mongo, Postgres, SQL Server, Node, Python, etc.
There is no way a reasonable person would not deploy to Linux and postgres for cost reasons alone. No one wants to pay Microsoft or Oracle money for databases, operating systems or frameworks nowadays.
All my .Net web apps are now deployed to Linux and Sqlite. Good riddance to Windows Server and IIS (which was dogshit from day one). With the tiny memory profile of .Net 10 it's crazy how small a VM you need to get good performance.
I beg to differ. Every government agency I’ve worked at will gladly pay SQL server license fees.
I think the word government agency is key here :)
My biggest complaint would be a tendency to blindly use a "Microsoft first" approach to selecting tech rather than evaluating things on their own merits in the context of their own use cases.
Some Microsoft stuff is really good but it's not universally true. And in the worst cases you end up locked into some hard to migrate off platform that is withering on the vine.
I worked at a Microsoft shop, and this was my experience.
1. Process, process, and more process. Doing anything required layers of management approval. Trivial tasks become month long, or even years long, processes.
2. You have no power or agency. Something is broken? You're a developer, you should be able to fix it right? No. Broken things stay broken. You swim in your lane and keep your head down. Mediocrity is the goal.
3. Optimization doesn't exist. If a process is manual and takes you, a developer, 10 hours, then that's what it is. Nobody gives a flying fuck about tooling. Nobody cares if you spend 50% of your dev time doing random stuff. And if you even dare try to fix it, you will be told it's impossible and you're wasting your time.
4. Management is king. You will have to lie to them. You will have to spend time re-entering the same data in 5 different places so they can read it conveniently. You will have to make Excel workbooks. You will have to dumb things down, and then dumb them down again, and again. Everything is about Jira... Unless they're a really high up manager, in which case you have to take whatever is in Jira and put it in a word doc and send it to them, because they don't know how to open Jira.
Those things have nothing to do with C# though, rather than your personal experience with companies that were using it.
If I judged every single company i worked at/interacted with, that uses NodeJs, I'd think that every single Node dev is a 13 year old child with no real experience but who think's he's the hottest shit. That has nothing to do with Node and doesn't really describe _all_ the companies out there.
The problem is thats how a lot of .net shop operate. I say this as .net developer.
.NET gets selected because a lot of non tech companies need to do software things, and they pick the stack fits in with their current WinTel stack. The main concerns is having replaceable talent to reliably do x. They're not trying to innovate. They are often doing something like sending out insurance quotes by email. They do this by having strict processes, and having developers stay in their lane. Expect rigid scrum, using dependencies only supported by Microsoft etc, Locked down Dev machines with visual studio only, ask for microsoft dev certs, and expect pre-approved enterprise design patterns up the wazoo. They don't want innovative developers, they want you to fit into the pre existing framework designed by an architect. Your skills can die in such an environment.
There are companies that use .NET that aren't like this, but you have to go out your way to find them.
Imo, you're criticizing "enterprise" development, not .NET/C#.
And .NET is the language of choice for "Enterprise". So that's what the majority of jobs are.
Where as large 'tech' companies don't tend to be like this.
> And .NET is the language of choice for "Enterprise". So that's what the majority of jobs are.
Disagree. I would argue Java is more of a choice for "Enterprise".
Also, would you please define the scope of "enterprise".
If you mean "enterprise" as someone who want consistent and predictable management and productivity, then sure .NET is "enterprisy", because instead of a dragon they want a fossil.
But if you mean "enterprise" as they want to sell their core product, and sometimes that pushes to high developmental velocity with multiple development team to tackle on a feature, then .NET is evolving fast enough that it is not so considered "enterprisy".
Heck, even Ruby on Rails would replace .NET for that, especially when you consider the e-commerce scene that is either Ruby or PHP (Wordpress).
Just look at C# and its incredible language revision every year.
> I would argue Java is more of a choice for "Enterprise".
.NET was literally created to replace the Java enterprise ecosystem. It never managed to completely displace it, but effectively gained around half of the enterprise market - and it will take more and more, after Oracle started pulling their usual boa-constrictor moves. C# is as "enterprisey" as they come, and it went full-opensource only once it became a requirement even in the enterprise.
It is mostly an Enterprise Development complaint... that said, it's how most .Net shops are in my experience. I really like C#, I've been working on a project with FastEndpoints and the .Net 10 RC since April and been pretty happy with it. That said, I don't have to implement 10 layers of indirection/interfaces/patterns to get the job done either. I have in other places.
But I would levy the same complaint with most Java[1] usage as well.
1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
> And .NET is the language of choice for "Enterprise".
Yes, again, you're criticizing the practices of enterprises not dotnet. It has nothing to do with how "dotnet shops operate".
I'm at a dotnet shop who doesn't work anything like that. I've been at multiple of them. It has nothing to do with dotnet itself.
When a lot of dotnet shops operate this way the difference is negligible.
I'm not saying all dotnet places are like this, but they are common.
What's skills? Pumping out code ala startup? Sounds like a stable environment. Someone with a good eye will still be able to pick out flaws in the processes/architecture and learn a thing or two.
"The main concern is having replaceable talent to reliably do X" as in every other company?
I swear you guys make having a regular job sound like being under slavery. It's just a job. Some companies are boring, that's just part of the job, and being able to adapt to different environments is what makes a good sde imo.
Lots of places are not like this. I work at a large tech company, at its not like this at all.
My machine is not locked down. I can use vim or whatever ide/editor I want. We don't use scrum/safe, we're expected to contribute to the actual system design. etc If I have a choice, i'm not working at a place like that.
However if you work in dotnet at a traditional "enterprise", it is highly likely to be like this. I have a choice, so i'm not going to choose that.
Wanting replaceable talent drives the tech decisions to only use the "standard" microsoft stack. Other companies value picking the right tool, then teaching people. The best companies don't even care what language you use, and are happy to bring you up speed.
I've found a position that uses dotnet which does not have this culture which is good. But i can totally imagine not picking dotnet to avoid this culture.
I agree, I'm just speaking to the culture and I DO think Microsoft has something to do with it.
Companies who choose Microsoft everything don't think much. They're not risk takers, and I don't even mean substantial risks. They're stubborn, old-school. But not in a charming way, in a 'grampa won't stop talking about how great it was before integration' way.
This is just the run of the mill politics you see at every big company (or mid sized one).
I worked at a PHP shop, it was pure mierda. Worst code I've ever seen in my life. Pure incompetency. Does that say anything about PHP shops as a whole?
Congratulations, you worked at a huge company. Nothing to do with the tech stack.
Yea, this is "enterprise" development 101.
The fact that large companies pick an established tech over newer ones isn't about .NET/C# per se, it's about large companies and the way they work.
And from the company's perspective, that's the right way to operate. Sure, it sucks for the individual hacker-type, but a big enterprise doesn't want "move fast, break things" they want the opposite. Rigidity, proven processes, stability and backwards compatibility.
Working there you aren't building the next Google, you're probably maintaining a some 20 year old order-to-cash ERP process that's boring, but critically important to the business, and is exactly the software you don't want to move fast and break.
Just don't go work for big enterprises if you don't want that environment. It won't matter what language/tech stack, it's just big non-tech company things.
But there's plenty of us out there that don't mind those jobs. Pay can be good enough, and usually offer great work-life balance. I work IT ops for one. I'm remote, I put in my 9 to 5 and I'm done. I'm (thankfully) not on call, I get unlimited PTO, and my personal time is 100% my own to go do non tech things with.
> And from the company's perspective, that's the right way to operate.
Oh absolutely. It's a business decision. It just so happens that it's framework that has been around awhile and has a decent bit of support. Give Node another 10 years and that landscape might start to change.
There is a trend amongst companies who use Microsoft everything.
It's not dotnet per se. But if we're deploying by spinning up windows server and clicking around, then I garuantee you, that job will have garbage politics.
Don't forget all the $PATTERNS ... I mean, you can't possibly live without 15 layers of abstraction and indirection.
That just sounds like management issues and less tech. Granted maybe people who are bad at that select C#, or it's just size of company?
https://youtu.be/s4Cz49MLh4o?t=142
Size of the company, combined with wanting “vendor support” instead of going at it alone like a FAANG would.
All large organizations are like that even my n=1 experience at BigTech.
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.
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.
Totally agree.
Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.
> Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.
I am pushing for Linux containers in the workplace... away from Windows, IIS, etc. I totally agree with you 100%. I'm also trying to push us away from SQL Server where possible.
My last comment, which you referenced... focused not just on C# or .NET.. but the focus of "you need Microsoft" in general.. this includes Windows, SQL Server, etc.
Again, my comment is focusing on someone on the outside looking in.. and WHY people end up making decisions away from C# in favour of (something like) Go.
I am aware of deploying to Linux containers, etc.
Yes, I am very aware of this and have spent a lot of time/effort trying to dispel some of these myths and mis-understandings through writing.
- TypeScript is like C#: https://typescript-is-like-csharp.chrlschn.dev/
- 6 .NET Myths Dispelled: https://medium.com/dev-genius/6-net-myths-dispelled-celebrat...
- The Case for C# and .NET: https://itnext.io/the-case-for-c-and-net-72ee933da304
> 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.
???
Java was originally Sun Microsystems.
However - if Java was Oracle to begin with (and as successful in the mid-90s) then might have done some marketing for the Java+Oracle mix.
Some people (ie Managers) if they decide on using Microsoft products will likely "encourage" the use of C# and .NET. -- That is an example of C# + Sql Server.
> Java was originally Sun Microsystems.
I am well aware.
Anyway, for the sake of the argument: "I am using Java. Need a server machine - should it be SPARC?". It makes nearly as much sense.
> That is an example of C# + Sql Server.
I'm sorry but most of us use Npgsql now
Good -- so am i
> most decent C# devs already moved away from to JetBrains/vscode.
My comment is NOT talking about 'decent C# devs'
It is a RESPONSE as to why more people are not using C# for startups. For those who are not familiar with C# MAY be put off using it for those reasons... and why another language might be used.
What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
I do my hobby .NET development in Zed and my serious work in Rider. .NET is open source and MIT licences. I do most of my development on a ARM MacBook Pro, or using my workstation which runs Fedora.
We deploy our code on kubernetes clusters usually on AWS.
All of the tooling, compiler, libraries etc are open source and cross platform and free. Not a single one of the developers in my team uses Windows or Visual Studio.
You know there are people.. programmers.. who are not C# developers... and likely refuse C# because of various reasons.. right? It can be based on the fact its Microsoft. My comment is based on startups and, from my experience, people like go all in on C# because decisions have been made to go all-in Microsoft.
C# has come a long way in the last 10 years. This much is clear, providing better support outside of the Windows ecosystem. However, many outside of the Windows/Microsoft ways are likely to be using languages like Go.
> What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.
There was no C# in 1995. (See it's easy attacking a sentence)
> There was no C# in 1995
Delphi was the hit story then.
Correct.
I was using it in my college projects back in 2001.
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.
> 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.
People who already are familiar with C# know this. To programmers that do not, may prefer to stick with another language to keep away from Microsoft in general.
Again - my comment is a response about why C# is not used more for startups. I am not suggesting it isn't, but there are plenty of reasons, and this is likely just one.
> 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?
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.
It is ironic when companies like Microsoft and Google end up showing the sort of "permanent reimplentation" behaviour that used to be typical of opensource, whereas certain opensource projects persist seemingly forever. Python, Django, Emacs - these things will likely see the end of the galaxy; meanwhile, big companies now build and discard key projects every other year.
> 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?
>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?
Blazor will produce super bloated web apps. I can see it being used for an in-house thing with captive users but for a real world product or a public app? It would be a terrible choice.
Also the DX is just not there. Hot reload is a mess. Even when it works it's too slow. Once you start using hot reload with Vite you can't go back to waiting seconds for every change and full page reloads.
> Compared to what?
Everything else?
Do you think it's acceptable that it took 4 years for Minimal APIs to get validation?
What about hot reload being broken for years and years?
>Do you think it's acceptable that it took 4 years for Minimal APIs to get validation?
Well thay don't call it Minimal API for nothing. Jokes aside, what stopped you from calling validation yourself explicitly?
>What about hot reload being broken for years and years?
Can't comment on this, because I have never needed it. I can work faster with writing tests, but I guess it's fair to assume there are some who would need it.
Which version worked flawlessly? And I guess blazor can work great but that's super specific to what you use it for. Much more so than most front end technologies/stacks. And both WASM and Server versions have a lot of compromises.
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 avoided Blazor, despite multiple people on my teams pushing for it. It always felt like it fit in the same space as web forms and silverlight. A product created to fill a gap of developers that wrote desktop apps and don't want to learn how to write front end code for the web. Plus it binds you to the product lifecycle of a .net side project that likely will be abandoned.
While Blazor has some cool stuff built in, the cool stuff never felt worth the risk of building a product around it.
Honestly, I was wishing that Blazor was in the same space as web forms.
There is a market for front-end development that isn't steeped in the hell of actual front-end development. Blazor is almost the right idea but I think this incarnation is a dead end. Somebody needs to gather up all the pieces and figure it out for real.
Blazor honestly is great for 'I need to write a simple backend control plane for whatever'. I.e. internal only stuff where you care about just shipping something functional and don't care too much how it all looks/etc.
Further you go away from that circle, the less enticing it is.
Why is that? Do you speak from real-world experience?
Not trying to push back. We're planning to use it for some new projects we have coming up on our team of .NET devs who can't seem to grok Angular or React and the entire ecosystem of tooling required, so I'm looking for reasons we shouldn't use it aside from Blazor being rather unpopular compared to Angular/React/other JS libs
As grandparent said, Blazor optimized for fast delivery. For public products you will have places where you should care about interactivity a lot. Their solution is interop with JS. You may try WASM but it’s definitely slow for UI.
WASM good for complicated tools, but you better probably with other language if you looking for next Figma.
Hybrid approach which is default have two issues. - round trip to the server. That’s not nice for interactivity and responsiveness. - hybrid hydration model is needlessly complicated. And again it will not fully solve your problem when you need to go extra mile.
Overall cold start for WASM require large payload, for Hybrid you need Websockets for updates. That sucks outside of cities or on junkie mobile. Not for public product.
Working with Blazor from Net Core 2.2
For internal tooling, or B2B where you don’t care that much is very efficient.
Just stick with the classic frameworks. Razor works great as does MVC WebAPI
I tried Razor. It's mature, has tons of features, and it's very fast. But it only really solves rendering HTML.
You will still need to integrate Vite somehow to use modern CSS, TS, etc. And if you do that, why even use Razor to begin with?
Also, hot reload is garbage. C# will never get close in speed or features to something like Vite.
If youre intent on writing everything on the frontend in javascript then you can just have a frontend app and use webapi MVC on the backend. Personally, in my personal projects, I find I iterate faster if I dont't write any javascript. Every page is just static HTML and any interaction is done via CSS (which you can do perfectly well in razor pages) or html forms. Managing page state is a huge time sink and IMO not worth it, but it's what pays the bills lol
> If youre intent on writing everything on the frontend in javascript then you can just have a frontend app and use webapi MVC on the backend.
Yes, I'm aware. I've been doing web dev since the 90s.
> my personal projects, I find I iterate faster if I dont't write any javascript
It's expected you will iterate faster if you have less features, no?
> 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?
I've seen plenty of innovative .NET/C# shops. They just don't have the "hip" factor to them.
It's mostly about pay too. And yeah some people want more exciting jobs and maybe even outlandish stuff like the ones you listed (regardless of the sarcasm!). Yes at the end of the day most software isn't super exciting, but it doesn't make a tech stack or platform where most of your job prospects would approximate to "working on some run of the mill, mega enterprise or SMB software project" any more attractive for devs.
Especially when even its advocates somehow use that as an "upside". It might very well be for a lot of people! But it's also a massive turn off for others. I have never worked in a startup or big tech, and work on very concrete and critical products yet I'd very much rather work on even outlandish SV stuff (at least the pay is usually great and the job environment could be good!) rather than on some SMB CRUD or some generic backend service. If I don't have a choice I could do it but it's not super enticing.
For all of the "SV startups" that are working on hard tech problems (new DBs, LLMs, etc.) there are thousands of SV startup CRUD apps.
Most SV tech stacks are romanticized when in reality they are just are all mostly some flavor of a MEAN stack that is building a CRUD. The allure is the lottery payout and a clean slate tech stack, not that the specific tech itself is used.
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.
Create a hello world dotnet container, then do the same in a modern language. Then compare image size and resource consumption. Then imagine you're running tens of thousands of containers in a proper SaaS microservices model, and it'll make sense :)
Enterprise doesn’t spawn 10,000 containers to perform a simple “hello world” operation. That’s not how it operates. You’d be amazed at how many concurrent requests a single service can handle. This capacity must align with the actual requirements of the companies involved, not some unrealistic scenario like “we need to emulate Google.”
While that is small for a container and modern binary, I recall C hello worlds being 17KiB -- if only AOT/Spans/interop be used more to drive down those filesizes further.
Sounds like a problem with the "proper SaaS microservices model" more than .NET
If you have that many containers, you should be having the revenue to pay for that.
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#.
The runtime alone is a bit over 200mb, and that doesn't include additional packages you'll most likely need.
That being said, I'd much prefer to deploy a C# application over Node or Java, no argument there. But saying "I wish more startups were using C#" makes me wince. C# seems well-suited for the monolith-architected VM-image-deployed strategy of the early 2000s, but it's pretty close to being the exact opposite of modern best practices. And unfortunately it's kinda unfixable in a language that depends on a VM execution environment.
I'm sure all this is short-lived however -- I'm relatively confident we'll see deployment best practices converge down to "use whatever language you want but you must compile to WASM" in the next decade, so the warts of devs' chosen language aren't an ops problem anymore.
But the runtime is in the base image, so that is shared across all deployed services on the a single host system(s). So it's much less of an issue, also, the entire runtime isn't loaded into RAM for every application. From Task manager in windows, I'm running a local app in debug/dev mode and it's taking 226mb ram, which is a lot compared to IIRC well under 20mb for the last rust-axum project I wrote.
That said, you get a lot of functionality in the box and nearby out of that extra resource usage and it doesn't really grow by much under load.
Beyond that, there's nothing particularly wrong about having a mostly monolithic backend for a lot of things, I would say most applications are better served starting with a more monolithic backend in a mono-repo with the FE.
C#/dotNet has Ahead of Time compilation that works very well with containerization. Obviously there are still overheads for the AoT runtime, but it is pruned.
AOT would solve a lot of these problems if it didn't have show-stopping restrictions like "you can't use reflection" and "you can't use native sessions".
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/n...
Reflection doesn't work with AOT because there is nothing left to reflect on... it's compiled away. You can't use reflection with C, C++ or Rust either, doesn't mean you can't use them for useful things.
> 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.
You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
There are quite a few gotchas for this, especially web apps. THis is understandable because it was added after the fact, vs. a first-party design requirement. It's cool and might work for you, but taking a non-trivial .net codebase to native AOT can be tough, and if you're starting greenfield, why go .net?
FWIW, the .net folks seem to have put a lot of effort into the native AOT pipeline in the last few releases. We have a large, non-trivial application with a fair amount of legacy code, and getting it AOT’d in .net 10 (targeting wasm, even!) was not an insane lift.
How is the WASM target looking nowadays? I tried it in 2023 and early 2024, and it was far from complete (JS interop, poor documentation scattered across GitHub issues, and so on). I still can't find a single trustworthy source of documentation on how to proceed. C# would look great at the edge (Cloudflare Workers).
Sure, legacy applications won't be easy to move over but Microsoft has been quite consistent in working towards making microservice applications easy to build and run with AOT by moving more and more components over to using source-generators and promoting minimal-API's.
Their target is probably not entirely greenfield projects (although I wouldn't mind it myself), but rather those with existing investments that start new projects that still want to share some parts.
And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.
You can't use reflection with AOT compilation. That's what AOT compilation is. Java has the same limitation for AOT compilation, for example.
Most reflection usage is for JSON (de)serialization and for that you can use source generators, which also offer better performance.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.
Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.
[dead]
They're self contained and native, but they're still massive.
There's been some work on CoreRT and a general thrust to remove all dependencies on any reflection (so that all metadata can be stripped) and to get tree-shaking working (e.g. in Blazor WASM).
It seems like in general they're going in this direction.
Smaller is better, of course, but I've never found the size of .NET binaries to be an issue.
What problems does this cause?
If you're trying to pack hundreds of microservices into a cluster, having containers using 80MB of ram minimum instead of 500KB can become a big deal.
Not every library is capable of building to Native AOT, which means any app that depends on those libraries run into the same problem. If the library or app uses reflection, it likely isn't capable of Native AOT compilation.
Just an FYI, Go still bundles a runtime in its native binaries. C#'s AOT has restrictions on what works (largely reflection), but these same restrictions apply to Go (although Go applies these restrictions into how it's designed for the entire thing).
rust and go are only good at single binary. when you need a few their size adds up quickly, because they don't really do shared libs.
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.
F# is less popular, but it’s a first class .Net language with full MS support and integration onto .Net (VM and ecosystem). C# has been tracking F# and aiming for language parity for years (ie all your modern C# devs should be learning the same language facilities). F# is multi-paradigm so C# devs can write idiomatic C# with minor forced changes. And as a .Net language you can always decompile it into C# and keep going from there.
That’s a radically different proposition than, say, raw OCaml and not particularly niche. It also impacts hiring pools differently since competent functional C# devs are viable, but it tends to appeal to a certain calibre of dev.
Moving faster with fewer errors and more talented candidate pool are relevant to repackaged SaaS startups too. Leaves more time for the other stuff and scales better.
don't get me wrong - i want F# features in C#! I like the ecosystem and both languages.
I'm just pointing out that no matter how cool the language is if it doesn't serve business needs(hiring, onboarding ,ease of replacing staff, target market) it won't be picked.
I've worked with a lot of junior devs/graduates on a large F# project, in that context hiring/onboarding for F# hasn't at all been a limiting factor. Ultimately F# is not a particularly difficult language to learn.
Last I knew, Rider was pretty much the only IDE available for a large codebase when you weren't on Windows. Much love for Ionide, but it was a serious struggle.
Is this any better now?
No still the same.
VS Code with Ionide is okay but has many limitations for example in debugging or lack of support for F# fsi scripts.
If you’re serious about F#, investing in Rider or Visual Studio makes a lot of sense.
Having said that I wrote a Neo4J data extraction tool a few months ago and chose to write it in F#. At one point I observed how funny it was that I was developing in a Microsoft language and yet my dev workstation runs Fedora and my IDE comes from JetBrains and my code is running in kubernetes on a Linux cluster and there is not a sight of a windows machine in this whole pipeline.
I remember the days when the language, linker, compiler, IDE, the GUI components, everything was tied together. If you wanted the next version of VB you had to buy the new version of Visual Studio!
It's good for, and I am not being sarcastic or snarky, justifying high pay and gate-keeping. Developers should set up more barriers for entry - look at doctors and lawyers.
I think I agree with you. When I was part of a growing F# team a number of years ago, everyone we hired was an enthusiast who just loved coding in F# and wanted an opportunity to do it professionally. It turned out that this love, combined with the constraints of the language, led to a super-clean and legible code base. The quality was (in my estimation) outstanding, and I was sad to leave it.
I'm at my current company (actually writing mostly typescript and node services now) because of a YC "who's hiring" post that mentioned F# positions (bait and switch /s, but my experience lined up heavily with the team I ended up joining which didn't use F#).
As an F# lover my heart sank at that "it turned out" at first. I'm glad someone got to live the dream somewhere haha
Sure, but that's a 'need' from programmers side - not from business side.
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?
How important is being a language expert in x vs all your other skills as a Software Engineer? My opinion is that "higher level" skills (like system design/architecture, product thinking/planning etc.) are so much more important than language minutia (outside of specialized fields).
If a business is turning away candidates because they "don't have n years of experience in x" that doesn't sound like a very dynamic/interesting place to work, it sounds like a code monkey job. AI is going to eat code monkey jobs.
Before you can demonstrate your skills on the job - you have to get the job.
Most of the 2.6 million+ developers in the US don’t have “interesting jobs” nor do they care if their jobs are “interesting”. They work to exchange labor for money to support their addiction to food and shelter.
https://www.hanselman.com/blog/dark-matter-developers-the-un...
If you look at the requirements for most jobs they want you to have $x number of years of technology $y. When every job application gets 100s of resumes, employees can be picky.
Besides, every technology has its foot guns, ecosystems, way of doing things and people who think they can just pattern match based on what they know are often the most dangerous.
One example is that I’ve seen people who know relational databases, optimization techniques and normalization try to pattern match their understanding of OLTP databases when using OLAP databases like Redshift and Snowflake and it being a complete disaster.
See also people who don’t understand how to do a single table design with DynamoDB.
In my particular niche (cloud + app dev + customer facing consulting) , I knows AWS inside and out and have used more AWS services than you can imagine in the past 7 years in a production capacity [1] and I’m currently a staff level developer at a consulting company (full time), the only company that would (has) looked seriously at me to do consulting outside of working with AWS is ironically enough - Google.
But they have the bandwidth to let me ramp up. When I have one open req, why would I hire someone who needs to ramp up on AWS when I have a dozen applicants with experience? Why would I put myself at a disadvantage?
A company would be absolutely insane to choose me over someone with experience with Azure, or GCP as a staff consultant over the probably dozens of applicants they have with that particular skill if they were an Azure or GCP shop.
When my current company hired me, they were short staffed and gave me a week to onboard and flew me out to a customer site to do support a large sales contract. They hired me because I could hit the ground running both technically and without “consulting training” like AWS had.
[1] seven years of experience between 2 working at a startup, 3 working directly at AWS (Professional Services) and two working as staff consultant at a third party company.
F# seems really awesome. Used it briefly for an internal tool. Are you at a startup working with it?
I am working at a 2k fte company and we use F# for a lot, its very nice to work with, prefer Rider over Visual Studio though.
Similar for us in magnitude of sized company, maybe a bit bigger. Lots of services are F# (internal and main services), but we don't advertise it that much nor want to. Every time we consider switching (even to C#) the developers want to switch back even though C# is a fine language. Its not perfect, but its enjoyable to code in all the same. At this point the stack is battle tested.
Are you on (or would you mind adding your company to) the F# companies list?
https://github.com/fsprojects/fsharp-companies
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.
Yea, but then the other end has to serialise the HTTP API stuf to a typed object on their end.
It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.
I don't know about you, but when I code-gen from an OpenAPI doc, I get strongly typed object interfaces, so the serialization is in the box. No need to have a client distribution specifically, unless you want to wrap the generated client to make it easier to implement security layers.
If I had to manually create a client, then I'd probably go back to WCF (CoreWCF) which, again makes it easy enough to publish a client. For WCF in particular, I used to have one project with all the interface definitions and a client-generator that would allow for an "easy" single connection string as opposed to the XML bloat that is typical for WCF defaults.
All the same, you can definitely generate strongly typed clients to OpenAPI, provided the interfaces are well defined in the doc/generator/api.
> 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.
I sometimes miss Spring magic when working with ASP.NET, and I worked 12+ years with C# and only a year with Spring. Not saying one is better than the other, it's always a choice, less magic = more boilerplate and less boilerplate = more magic.
> and most language features don't feel bolted on like with Java (anything from functional programming to extension methods to whatever)
Java doesn't have extension methods and while both are decent languages, C# is the one that likes implementing every conceivable language feature immediately, while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.
> while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.
Java is quite busy also implementing features that are small in other languages like text blocks.
And I wish Java would design bigger features that would replace several "smaller ones", but that is almost never the case. It's almost always just a new big feature bolted on to the language that is almost there, but not quite
There are many reasons for that, none of them simple, and it doesn't help that there's also the attitude of "those lesser languages cannot compare to the greatness that is Java" [1]
If we're talking about Java, somehow you're still required to do builder patterns and manually create `.of` constructors for everything. Where C# has had object initialisers and pervasive IEnumerable with a very simple interface that nearly everything uses. And that is only scratching the surface of DX.
Almost every feature bolted onto Java seems to take several times more code, and doesn't really work with the rest of the language.
Don't get me wrong, I quite like working with modern Java. But I had the chance to work at a company where micro services where developed in both Java and C#, and the difference is still light and day.
[1] https://news.ycombinator.com/item?id=28985688 "our goal isn't to adopt the strategy of less successful products, but to forge our own"
> Java is quite busy also implementing features that are small in other languages like text blocks.
It's a small feature which is immediately understandable by anyone coming straight from Java 1.2, it doesn't materially increase the complexity of the language and is arguably one of the best implementation among different languages. So not really sure if it's a good counterpoint.
Meanwhile records arrived several versions ago with sealed interfaces/classes on the horizon already, so now they together form a complete ADT feature. Pattern matching builds on top. And sure, these are no novel features, MLs had this decades ago, but the implementation is very nice, with minimal additional developer complexity and some small DX improvement (records replace the majority of Bean usages). In the future, withers may come that would help with both object initialization AND record "mutation". Where Java spends more development budget is on the runtime side, e.g. virtual threads can replace async code in many cases, so the language doesn't have to get all the complexity of an async feature.
Meanwhile C# has many many "one-off" features and they really can have unexpected interactions and make the language quite a bit harder to understand. Some of them are absolutely wonderful, but I am on a "the-smaller-the-merrier" language team.
> It's a small feature which is immediately understandable by anyone coming straight from Java 1.2
You literally started with "Java takes a while to design a bigger feature that will replace several smaller ones' use cases".
But look, this small feature is not a one-off, and is actually useful because <arbitrary arguments>
> Meanwhile records arrived several versions ago
> Meanwhile C# has many many "one-off" features
Such one-off features like records and pattern-matching that C# also has? Or multiline strings that C# also has?
Or any other useful features directly impacting developer experience that you just dismiss out of hand because for some arbitrary reason you deem them "one-off" or small. Until they finally make their way into Java of course.
> Java is quite busy also implementing features that are small in other languages like text blocks.
Or named parameters or compile time null safety. Everyday I inch closer to moving over to C# from Java.
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.
> but i haven't used java in a very long time
What was the last Java version you used? There has been a huge momentum in adding new features lately, granted, it is slower than in C# (Java's top priority is backwards compatibility, so it does not have the luxury of shedding old stuff or changing them once they are in), but in the last couple of years it has improved tremendously. The JVM (especially in the garbage collection front) but also the language - half of an ML-style language is there (for example, ADTs and pattern matching), the other half is coming soon!
>If i remember right Java's webserver beats ASP.NET in performance benchmarks
That's not the case anymore. Kestrel is one of the fastest servers there is, and it beats every Java server out there.
the famous benchmark that put ASP.NET in #1 spot was hyperoptimzied to hell while competing with normal implementations of other systems. https://web.archive.org/web/20250330225652/https://dusted.co...
archived version becasue original one gives 404
currently according to techempower benchmarks ASP.net is 55th overall in minimal variant, while being 83 in normal one in Fortunes benchmark which is basically a normal usecase.
While most java framworks oscillate between 10-30
https://www.techempower.com/benchmarks/#section=data-r23
EDIT: there's also an entry for aspnetcore at 35th
> archived version becasue original one gives 404
Thanks, fixed now. I literally just migrated from GCP to Hetzner over the weekend and was about to finish the migration today :)
Look at plaintext results if you want to compare just servers. Fortunes benchmark has too many variables (including db queries etc) to say anything about server performance. As for fortunes benchmark, for more realistick Java performance numbers I would look at Spring. Also there are many shady things on those Java bencmarks.
I think saying that Spring is the representative of Java metrics is somewhat equivalent to saying that full aspnet mvc is the representative of dotnet metrics.
On the dotnet side, both Oxpecker and Giraffe (Giraffe being written by the author of that post) perform very well with simple code and from what I see, no "tricks". It's all standard "how the docs say to write it" code (muuuuch different than those platform benchmarks that were rightfully scrutinized in the referenced blog post).
On the jvm side, I started looking for a reference near the top without any targeted non-default optimizations (which is really what I personally look for in these). The inverno implementation has a few things that I'd call non-standard (any time I see a byte buffer I imagine that's not how most people are utilizing the framework), but otherwise looks normal. I recall an earlier quarkus implementation that I read through a couple years ago (same repo) that wasn't as optimized with small things like that and performed very well, but it seems they've since added some of those types of optimizations as well.
All to say: If you venture outside the standard of either platform (full fatty aspnet/ef or spring/hibernate) you can make the tradeoff of framework convenience for performance. However when it comes to the cost/benefit ratio, you're either going to be joining a company using the former, or writing your own thing using the latter (most likely).
It's no longer so hyper optimized and performs very well today in the metric compared to any other comparable framework.
I do not have any benchmarks other than this[1] to refer to, but I work with Quarkus[2] and Java 25 LTS (just recently released) services deployed on AWS EKS and we are very happy with the performance (for mobile game backends)
[1]: https://sharkbench.dev/web [2]: https://quarkus.io/
Quarkus does a lot of bytecode generation magic at build time, which will give it an "unfair" edge in some scenarious, like this simple serialization/deserialization case in this particular benchmark.
That's not what Microsoft's own sponsored benchmarks say:
https://www.techempower.com/benchmarks/#section=data-r23
Look at plaintext benchmark, if you want to compare just servers. Also look at Spring score in fortunes, which is the more common Java stack and I think a more suitable comparison.
> Documentation is vastly better compared to Java ones, it's like day and night
This is absolutely not my experience, especially when it comes to the ecosystem and third-party libraries. Like Java is pretty much the best in this category.
well you can't judge 3rd party libraries, can you? by that metric js/ts would be the worst thing in existence.
I've seen some great, some horrible 3rd party docs on .net side - same with java.
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.
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 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.
If you ignore Android / iPhone, where language choice is limited, practically all other development is web.
Most of your electronic devices work with embedded software. Production lines, transport gates, cranes, computer hardware, ships, planes, rockets, cars, e-bikes, smart lights...
There is also scientific programming, that feeds research and analysis. Weather reports? Statistics, etc.
And there is gaming.
Devops, infrastructure? Databases? Tools for artists? Most of those aren't web. And yes I've heard of Figma.
There are probably tens of categories I'm missing.
Web is still bigger probably, but I have a problem with the saying "practically all other development is web".
I really doubt you’re using .NET (it literally is named in the dotcom style and refers to the interNET) in embedded software.
In an article about .Net its fair to talk primarily about creating APIs and other internet focused uses.
And you just deduct that from the name? Was .NET created with a focus on web? It seems to me like a generic application framework.
ASP.NET is the web part, no?
I didn’t deduce it from the name. I deduced it from over a decade experience working primarily with .Net.
Since I can’t presume the reader has equivalent experience, especially in HN, pointing to the name, which should be a good signifier of what something does (to be fair, MS really, really sucks at naming), is a good shorthand.
The real reason .Net isn’t good for embedded devices is because MS didn’t develop it for embedded devices. They’ve only added low level memory management in the past few years.
Until recently you couldn’t even create a fully statically compiled executable.
[dead]
> practically all
Define “practically all”. I would accept “clear majority”.
But practically all? Nah. I mean the hot new areas for funding right now are AI and robotics neither of which are web!
I’m coming up on 20 years professional experience. Exactly none of it has been mobile or web! The programming field is so much bigger than HN likes to pretend.
The majority of software is probably Excel macros.
This probably isn't true but I want to read a super geeky dark sci-fi novel that explores this topic.
It's not obvious to me that it isn't true. The number of excel spreadsheets world-wide probably vastly outnumbers the number of software projects.
Excel spreadsheets with macros on the other hand aren't THAT many, no? :)
>I mean the hot new areas for funding right now are AI and robotics
Most developers are not in such startups. There is a lot of boring software out there which is a website. Even for AI, the first company that comes to mind OpenAI is known for ChatGPT, a web product. Most of the AI companies are building web products.
That is software with a web interface. Only a small part of OpenAI's work deals with web related things.
how dare you, i summon 10 js engineers from openai to downvote you (they have 6 only)
I won't fear them teaming up with their FastAPI Python team.
They are serious parts of chatgpt experience. But still not core of the work.
It's web in a (limited) sense that there's probably a web frontend somewhere, but this "somewhere" is usually pretty far away from where most of the code is developed.
Most of the backend logic is not related to serving data for the browsers, it's doing actual backend stuff - communicating to databases, APIs, etc.
Is Google search backend a web app? I think it's really stretching the term.
Sure isn’t.
> practically all other development is web
This is a pretty ignorant take.
Get out of your bubble.
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.
It really depends where you are. In the UK half the places seem to use .NET in some form or another.
I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days.
The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft.
The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET.
I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.
Why would they insist on using Visual Studio? At least you can run SQL Server easily on Linux using docker.
> Why would they insist on using Visual Studio?
They don't even know Rider exists a lot of the time. It is also quite different visually compared to Visual Studio code.
A lot of places have never used Linux at all and if they have they have it would be WSL or some RHEL box. So if you are screen sharing Gnome and with a totally different IDE and Terminal the person assessing you might not actually understand what you are doing.
> At least you can run SQL Server easily on Linux using docker.
1) They normally want you to use something like SQL Server Compact or SQL Server Express and a specific version. TBH I just don't bother anymore with these interviews because it takes like a couple of hours to get all this stuff working on Windows.
2) SQL Server Projects can only be used on Windows with Visual Studio. Some places do a lot of stuff "old school" and they want you to use that.
> It's just .NET that's largely ignored for no real technical basis.
As someone who has been developing primarily on .Net for the past decade this is absolute bullshit.
1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging. 2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways. 3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes. 4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc. 5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement. 6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all.
There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.
By recently you mean a decade ago yeah? I mean it’s fair that it was only a half-decade (.NET 5) when it was genuinely complete enough, but lots of stuff was in good shape when it was called .NET Core.
It sounds like you’re projecting the problems of an existing .NET shop onto the shape of a startup without all that baggage. I can assure you, having worked with many customers running new business on newer .NET, it hasn’t been a legit technical concern since about .NET Core 3.
A decade ago is when they started the transition. It’s been painful.
If you’re a new shop that is making decisions without looking into how the company that pretty much runs the platform you’re basing your future on has acted in the past decade (we’ll ignore how they’ve acted beyond that because then it’s a no brainer) then you’re doing yourself a disservice.
I see that you’ve narrowed the goal posts to just technical concerns, which is fair, but isn’t sufficient to make a decision about what technology to choose.
Especially in a field where you have a similar alternative in Java where the sponsoring company doesn’t have half as much control, as well as several fully open source alternatives.
[dead]
You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
While suffering the performance loss of V8 versus CLR, JVM or any compiled language.
One of the reasons I am back to writing more C++ code is C++ addons for node.js, as several SaaS products now only care about Next.js as extension SDK.
> While suffering the performance loss of V8 versus CLR, JVM or any compiled language
The number of startups for whom that performance differential matters more than developer output is tiny.
Yeah, except plenty of them are probably using Kubernetes and NoSQL, because everyone dreams to be Google.
I don't think it's about dreaming to be Google. K8s is pretty easy to set up now with a hosted cloud platform if you start with it, and helm takes care of pretty much all your infra needs. Migrating to K8s is what's awful. From there, the docs have most everything you need to know and there's an abundance of helpful information online that covers most problems you'll run into.
>You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
You can do that in .NET, too if you use Blazor for frontend.
OpenAPI and client generators solve this issue easily.
I would love this to be true, but it isn't. I've done generating types for the frontend multiple times, sometimes from C# (around 2016, using typelite), Java (openapi template generator) and most recently straight from OpenAPI spec files (.yaml) using Orval.
It always has been a shitshow. It works well for the 90% cases, but in the 10% edge cases, things break. It becomes impossible to fix generation issues, you will often resort in working around issues in your backend/openapi code. Sometimes you report bugs upstream and hope it gets fixed. In the current project we are stuck on a ~2year old Orval version (a typescript generator from openapi) because some features broke or were removed in the latest version, and the entire monorepo (15+ LoB apps) wouldn't compile and would require major changes. This simply because a never version of the generator was broken/removed features previously present.
No, that's not true. If you share code like this then you can do things like put the same validation code in the frontend and the backend: frontend to give a nice user experience, and backend to protect the endpoint.
OpenAPI does support patterns for fields and nullables/non-nullables - that already gets you very far regarding validation. A decently sophisticated generator (which don't exist IMHO) would generate the validation code for your respective language.
True, but you can get all the way to zero duplication if you write it directly and share that code.
Or GraphQL.
Still one lang on both ends is nice: there are some bits of code you want to run on both ends (like templating for SSR/SEO/caching; but also using them in the browser).
Still more work than just running the same code everywhere.
Still better than bringing JavaScript to the back end shudders
> Backends can be any language
In +90% of cases you will still need a frontend for that backend.
TS full stack is by far the best option for this.
Not really? Having come deom a TS + Go startup it’s pretty trivial to wire up domain objects across each language and define a clean API boundary with some enforcement at build time. And Go was a far better choice for the backend than TS for some lower-level memory considerations.
With TS you don't have to "define a clean API boundary with some enforcement at build time". You can use the exact same types you're using to enforce endpoint schemas everywhere.
You don't need a middle man like OpenAPI (which I've used and it's a mediocre solution).
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.
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.
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?
As much as I think C# at a platform level is a better tool for building backends, you'll get the better bang for the buck learning TypeScript if you don't already know TypeScript.
Then if you have the chance, you'll find C# an easy transition from TypeScript, IME. Learning C# first, on the other hand, will make you a better TS developer, in my opinion, because it will shape your approach to be more diligent about using types. This is something most JS/TS devs do very poorly and at scale, it's very hard to reason about code when it requires digging down several layers to find the actual types/shapes.
"Enterprise" frameworks like Nest.js are much more similar to ASP.NET or Spring Boot than they are to Express, Hono, or Elysia so once having experience with .NET Web APIs (or Spring Boot) will make Nest.js (for example) easier to pick up.
Not really, you should learn Typescript by learning JavaScript first. Then consider learning C#. Or if you want to focus on the back end side learn C# and skip TS/JS.
They are created by the same person but they are very different in my opinion.
TypeScript is "a tool" for JS, it is possible to compile without errors but still fail in runtime (e.g. wrong object type returned from API), on the other hand parsing JSON with C# will give you correct object type, it may fail if some properties are missing but it will fail at parsing call, not further down when you try to use missing property. In other words typing is not glued on top of the language it's core of the language.
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.
I have tried it recently. It felt like I was coding Java. I realize "feel" isn't very objective, but I don't really like C-like languages in general. I like Rust, but only because of it's heavier FP-influence. C# is one of those languages where you don't mean to, but you can't help just creating tons of files/boilerplate/etc., which feels just like Java. Just my perspective, others obviously feel differently.
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)
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>.
>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
As far as I remember, cloning the project, sprinkling in some printfs and running it. He didn't want to use an interactive debugger. He was used to using the likes of nvm, uv, rustup, etc.
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.
"Just" is an incredibly obnoxious word when used in the way that you have.
> Just install
Not on Debian? Have fun with that. You'll also need the Azure SDK. And what about openssl-dev? Oh no, you installed dotnet on Windows instead of within WSL? Start again.
No, you don't "just install" the SDK. There is a lot that the IDEs set up for you.
> Local nuget.config
I don't see how adding a nuget config improves anything. You have completely omitted what you place inside of it to make it build and use a local clone of the package source.
Look at all this nonsense that people have resorted to: https://stackoverflow.com/questions/32482746/how-to-temporar...
In my experience installing the .NET SDK is fairly simple in any platform, well documented and supported.
Nuget.config allows to configure your local feeds, this implies you have a local feed with the required packages.
Another option is to push the local build packages to you local NuGet cache.
Isn't it just a single file installation?
No. It's a tar + some config envars if you need to do it manually.
There is also the dotnet-install scripts https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-i...
[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.
I use Rider† daily to write F# and C# on my Mac. It works great, I have no issues with it. It even handles the .NET Framework 4.8 code‡ that I maintain without any issues thanks to Mono.
† And Neovim occasionally, but I mostly use it for Typescript or anything that isn't F#/C#.
‡ https://github.com/nozzlegear/shopifysharp
Rider is your option there, it's better than Visual Studio (I used to work on VS).
How is it so different than Visual Studio that you think it is "better"?
I've used Rider for several years now on and off. Generally I would put these at the top of the list.
- Integrated ReSharper.
- Far better performance (it isn't even close)
- Doesn't take 30GB of disc space up. Visual Studio has been a massive disc space hog since forever. Rider is a few hundred megabytes IIRC.
- Less bugs (Visual Studio has been progressively getting worse).
- There was better tooling IMO around NuGET.
>- Less bugs (Visual Studio has been progressively getting worse).
Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy. (Although admittedly, I'm not really up-to-date on the current state of VS in day-to-day work)
But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
> Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy
Obviously. IME it is better than Visual Studio.
> But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.
I rarely use any of these tools tbh. I just want Resharper and something that works reliably on Linux. I would transition to using vim entirely but half the vim stuff I like using I can't use with Windows (work is never not going to use Windows).
I switched over entirely to Rider as well, in my experience it's far more performant, has a far smoother UX, has a lot more functionality for power users, and includes Resharper by default, giving you access to a bunch more powerful inspections and refactoring.
Offers essentially everything VS does + everything ReSharper does. I switched after years of using VS + R#, and have never looked back.
Pick literally any Visual Studio feature. Rider does it better.
Much better UX and integrated ReSharper.
performance!
Yep.
VSCode gets you 90% there.
But IMO Rider gets you over 100%.
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.
They couldn't get it right because Visual Studio for Mac was actually a rebranded MonoDevelop, an entirely different IDE than Visual Studio.
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.
[dead]
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?
> "Legend has it that the name Rider comes from ReSharper IDE, but since Ride didn’t sound great, it became Rider.
— We haven’t found the source for this story yet."
From https://blog.jetbrains.com/dotnet/2022/08/03/happy-5th-birth...
I suppose it's word play, as usual in JetBrains product names. *(See) Sharp rider", that is, an expert rider (of a horse, or a bike).
Dotnet format is truly slow and bad. I wish the team focused on improving it, and working on better LSP support
Have you tried csharpier? It's got some wrinkles but kept things pretty consistent.
* 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?
Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.
The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
EF or EFCore? Specifically EFCore is highly regarded whereas legacy EF not so much.
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#.
What papercuts?
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.
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?
Doesn't it feel like the functional stuff is coming into C# so that F# can disappear? Pure speculation on my part but doesn't seem unreasonable.
C# has incomplete and often compromised versions of the constructs F# mostly took from OCaml, and as you extend those exhaustive guarantees towards formal verification you bump into F*.
C#s adoption of language features shows their utility but they’re not a replacement, per se. Without a clear functional answer in certain language and parallel computing scenarios MS would be ignored. Scala and Kotlin are comparable answers to comparable pressures on the JVM, and even keeping pace there with new and exciting tools/libraries requires some proper functional representation on the .Net platform.
F# will disappear when/if those other languages do, and already has lots of what C# is chasing with a more elegant syntax. It inherits VM and project improvements from C#, so the biggest threat to long term investment is something like the crippling changes made to FSharp Interactive (FSI), during the .Net Core transition. Otherwise it seems to be in a safe place for the foreseeable future.
Microsoft is still supporting VB.NET, Windows Forms/WPF, and to a lesser extent VBA. I doubt F# is going away anytime soon.
Supporting as in maintenance mode, at least VB.NET. Thankfully F# is more community driven, but the CLR ecosystem is definitely getting C#-centric in the use of idioms and features from newer C# versions, which increasingly affects F# interop while they catch up.
.NET has always been both the biggest blessing and the biggest curse for F#.
We have access to millions of libraries. I look at BEAM languages and OCaml every once in a while but can’t quite drag myself over there, knowing that in .NET, just as an example, I can choose between a dozen JSON serialisation libraries that have been optimised and tuned comprehensively for decades.
But then, those libraries are also our curse. If you consume them, everything is OO so you either give up on functional purity and start writing imperative F# code, or you have to spend time writing and maintaining a F# idiomatic wrapper around it.
Similarly I was working recently on project to develop a library which was going to have downstream consumers. The problem lent itself really well to domain modelling in F#. But I knew that my downstream users would be C# devs. I could invest the time and write my library as “functional core, imperative shell”. But then I decided that since the interface would be OO anyway, I might as well just write it in C#.
Thankfully what keeps F# going is the wonderful community around it, not Microsoft. I know some people (outside of Microsoft) have worked on a standalone F# compiler but it’s still very early stages. Maybe one day.
Although you inevitably end up writing some OOP code in F# when interacting with the dotnet ecosystem, F# is a really good OOP language. It's also concise, so I don't spend as much time jumping around files switching my visual context. Feels closer to writing python.
The C# team admits to looking at how F# features work, but also keeps trying to make it clear that C# doesn't have a goal of entire eating F#.
C# still doesn't see itself as a functional programming language, even as it has added so many features. It may never get first-class currying or the broader ideas like generalized computation expressions, for instance. It certainly won't get F#'s cleaner syntax with fewer mandatory semicolons and whitespace nesting rather than curly brackets.
F# probably isn't going to disappear for a lot of similar reasons that GHC (the Glasgow Haskell Compiler) didn't disappear when F# was started (nor when key contributors left Microsoft). F# often already sees more outside open source contributors than contributions from Microsoft employees.
They killed off VB, which if I recall the announcement correctly, noted that it statistically had a larger user base (by Microsoft metrics) than F#. There are a number of companies relying on F# for critical operations and MS has some use of F# internally which I understand has no plans of replacement, which helps balance out the fear.
I was curious so I googled. Best I can tell it is still supported, but perhaps stagnant?
Very little, as in fingers in hand, little in Azure
C# Dev Kit, which VSCode pressures you to install, is a core very non-free component.
Removing free omnisharp was the worst
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?
There's still a lot of folks who consider themselves .Net experts who don't know how to program with async/await, so knowing about a niche IDE (which I also exclusively use) is asking a lot for those people.
Rider might be a niche IDE. But ReSharper with Visual Studio was a mainstay for me from 2008-2020 when I was doing a lot of .Net
Yeah I usually introduce Rider to .Net developers by saying "it's by the folks who do ReSharper".
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...
Right, I think .Net 7 brought the top-level statements to Program.cs.
The oldest version of .Net I could find on Windows 11 was .Net 4, but it still compiles just great without a project file since it has since v1:
https://www.youtube.com/watch?v=KmIwGxcMOLg
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!
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.
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.
I've come to really appreciate Typescripts structural typing, because it reduces some of the overhead & prevents the unnecessarily tight coupling that has often annoyed me in other languages.
The overhead argument seems fairly objective to me - clean code with low coupling in C# et al. requires separate definitions of interfaces and implementations, explicit conversion methods between compatible interfaces etc. This adds up over time and makes refactoring pretty annoying.
The tight coupling happens when people don't bother to define interfaces. Suddenly I have to couple class hierarchy to classes from unrelated modules, all so the compiler is happy when I pass structurally equivalent data. To keep my own modules clean I have to add yet more interfaces, conversion methods etc!
It prefer static functions and stuff we can quickly understand, avoiding big objects or a great deal of indirection. Don't tell Uncle Bob!
Of course, you'd still need interfaces for DI, mocking etc, but that's pretty most of my interface usage.
[dead]
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
>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.
That’s a good argument. I had not considered properties in those terms before, and have historically been skeptical of them in many languages.
I’m partly convinced now! I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
> I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.
Definitely a problem when a developer goes rogue and breaks this rule. I'm not sure if there are linters that helper with this. I don't think either VS, Rider, or the .NET Compiler include any analyzers that complain about this. If they do, I haven't seen the warnings before. I generally tend to enforce this during code reviews with my team.
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.
Ah okay, yes, debugging tools are a bit more friendly with C# but it's again the nature of the beast of cpp, but to nitpick this is a compiler area moreso than a tooling issue . CPP will compile direct to binary, whereas C# will compile to machine Lang iirc, an intermediary step anyway, so you can imagine it makes debugging much easier.
> to nitpick this is a compiler area more so than a tooling issue
If there’s one thing c++ is good at it’s bikehsedding where the responsibility for fixing this stuff is. When I started programming in c++ 16 years ago, modules were “imminent” and reflection was coming soon.
Modules are still unusable because what we’ve standardised is insanity and the standards committee refuse to make a decision to support the backwards compatibility of tooling and code that will never be upgraded or even used in a modern setting.
The compiler vendors blame the standards committee, the committee say that tooling isn’t their problem,and standardise something that has no theoretical objections but in practice requires deep concessions to the spirit of the idea. At the same time, they’re perfectly content to assume that everything is developed the way they imagine - adding ranges to algorithm and forcing the compile time because modules technically exist.
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.
Especially with the recent extension of STS release support from 18 to 24 months [1]. Previously, upgrading from an LTS version to the next major (STS) version meant the support window decreased by half a year, while now it would stay the same.
[1] https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-su...
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.
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.
Well, besides webforms there is a lot of other stuff.
Rest web api will be migrated.
Razor — also.
> 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.
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
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
In my brief testing just now, both extensions seem to be purely synonyms. Microsoft's documentation suggests that .razor is for Blazor components and .cshtml is for Pages, but even Microsoft's own templates are inconsistent on this and seem to use them interchangeably. The view engine doesn't seem to care what you call it and doesn't really seem to change its behavior. It really mostly just seems to underscore the difference between Razor Pages and Blazor "Server-Side Only" is real blurry to nonexistent. Obviously Blazor Hybrid and Blazor WASM have very different behavior from just Razor Pages.
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.
> that is Windows only.
There are so many things that are like this in the .Net ecosystem.
Yeah, it runs on Linux. Kind of. Mostly.
As long as Microsoft is at the helm, I don't expect that to change.
The .NET debugging extension (SOS) is not Windows only, it supports LLDB on Linux in addition to WinDbg:
https://learn.microsoft.com/en-us/dotnet/core/diagnostics/de...
License: https://www.nuget.org/packages/dotnet-debugger-extensions/9....
> a. Data Collection. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the software documentation. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft�s privacy statement. Our privacy statement is located at https://aka.ms/privacy. You can learn more about data collection and its use in the software documentation and our privacy statement. Your use of the software operates as your consent to these practices.
> You may not work around any technical limitations in the software:
> * reverse engineer, decompile or disassemble the software, or otherwise to derive the source code for the software, except and only to the extent required by third party licensing terms governing use of certain open-source components that may be included with the software;
> ...
> * share, publish, rent, or lease the software; or
> * provide the software as a stand-alone offering or combine it with any of your applications for others to use, or transfer the software or this agreement to any third party.
So you are not, for example, allowed to ship this in your application's docker image, you are in fact not allowed to redistribute it at all. So if you wanted to get a .NET debugger into your staging environment, you are not actually allowed to, unless you directly install it then-and-there with nuget. (I'm assuming we're talking about any type of enterprise context, where any given application is touched by contractors or employees from n>1 legal entities, so you are always distributing/sharing/transferring/making available).
Ya ya, I know you shouldn't have debuggers near prod, chiseled images, living off the land, yaddayadda. Regardless, it's needed or at least the easiest way at times, to actually be able to debug an application in staging or similar scenarios.
Also I'm not sure if e.g. blocking outgoing connections of the telemetry (even if by blanket policy) would already technically violate the license.
Yes, the restrictive license they place on their debugging components is frankly bizarre.
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/...
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...
Actually, TypeScript's `Promise.all` can handle different types too.
I am talking about C# / F# context where the lists must have homogeneous types.
That TypeScript supports this is yet more complexity introduced to cover usages of an API not designed around types.
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?
No, not plenty: https://learn.microsoft.com/en-us/dotnet/standard/serializat...
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?
System.Text.Json isn't needed as a nuget library for newer development, the library is only needed for older stuff.
Those older stuff are likely running newtonsoft.Json anyway.
There's also a load of .NET Framework applications still running Newstonsoft.
System.Text.Json ships as part of the shared framework in recent versions of .NET so for most users it won't be restored from nuget.org
System.Text.Json is out-of-the-box in .NET > 5. The NuGet package is primarily a compatibility layer for people still supporting .NET 4.x for whatever reason.
> Why is there so much difference in the NuGet downloads between both libraries tho?
Because there's a boatload of older .NET apps that have been using Newtonsoft for over a decade already and aren't in a rush to switch. Anything built on .NET Framework is likely to still use Newtonsoft.
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.
There is a 3rd Party library for that now: https://github.com/zcsizmadia/ZCS.DataContractResolver
I haven't tried it because it has generally seemed easiest to use the new attributes. Though a large part of that is the shift from the WCF-era "opt-in" approach of DataContract/DataMember [0] versus the "opt-out" JsonIgnore approach where most of the transition is deleting lines because JsonIgnore is the exception rather than the rule. You could even keep DataContract/DataMember during the transition and just take an additive approach for JsonIgnore.
[0]: It was a good idea, in theory, but so annoying in practice.
For me it was less not really about the opt-in part (after all, Newtonsoft works the same way) and more about stupid things like setting a name (DataMember), Enums, and in fact opting out (IgnoreDataMember)
It's especially annoying in libraries because the consumer might not even be using System.Text.Json, but you have to pull in the library anyway to apply its own attributes if you want it to work right. Just an overall awful smell given the existence of first-class framework attributes to do the same thing to avoid just that problem
Case in point: https://github.com/dotnet/efcore/pull/28084/files
> but you have to pull in the library anyway
That library is also out-of-the-box in the BCL in .NET > 5, though. It's not an extra install (except for projects stuck in .NET 4.x).
I get the desire to avoid that sort of redundancy in the BCL itself, but also explicit is better than implicit, which was the baseline theory for why System.Runtime.Serialization was the way it was even as it added more and more implicit "conventions", and if System.Text.Json supported the SRS attributes out-of-the-box there would be just as many complaints about "implicit magic" or it not following WCF conventions hard enough and that making it harder to migrate things using SRS attributes when you wanted different behavior in JSON serialization than you would want in WCF SOAP serialization. SRS has too much WCF baggage, unfortunately for all of us.
Perhaps what's left of the disagreement here between us is if System.Text.Json counts as "first-class framework attributes" and it certainly seems that way to me in .NET 5+, and especially as we celebrate the release of .NET 10. It's a small redundancy in the BCL, but it's still just "as BCL" and "first-class".
Available on Heroku https://devcenter.heroku.com/changelog-items/3479
.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.
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.
They provide a bit more context around changes in their "What's new in C# 14" page:
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
This is great thank you.
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!