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 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'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.
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.
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.
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.
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.
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.
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).
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".
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).
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.
So you used C# without any of the .Net runtime? I don't think Microsoft did open source in 2002...
Even Mono was only started in 2004.
Another popular library that went commercial is FluentAssertions, Shouldly is a good open-source alternative.
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.
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.
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.
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?
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
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.
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.
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.
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.
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).
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.