> 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.
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.
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)
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.
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.