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 agree that the commercial library offerings seem much more "in your face" with .NET but I don't find the actual breadth and depth of the free and open source library situation to be that troubling. It certainly continues to get better every year.

.NET is very "batteries included" as well so you don't need a huge base-line of competing open source packages just to do "hello world".

This is all hypothetical. There isn’t any open source project I depend on that isn’t backed by a large corporation.

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.

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.

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.

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.

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.

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.

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)

Another popular library that went commercial is FluentAssertions, Shouldly is a good open-source alternative.

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

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

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.

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

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.

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.

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 just have PDF micro service where I use puppeteer. But I could swap it to Java micro service easily.

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

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.

Are you looking at older materials?

That said, for a web cli, there are a ton of options out there without touching anything commercially licensed.

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.

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.

I could continue to point hundreds of technical differences but that's the trees and not the forest.

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.

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.

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.

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?

Does Java have real generics yet?

I expect the baker who sells me his bread pays for the flour.

And in 20 years I've personally never needed a paid library. Maybe one company had bought Telerik back in the day? I've now built up multiple startups, some with millions of users.

The only thing I ever plugin that's not a MS library really are serilog, validation with FluentValidation, and a job server, usually Hangfire just because it's easy. Other than that, most people have good C# API clients. Oh and OAuth, though the popular one got baited and switched like you said.

The key difference is that the core libraries cover much more for .Net than most other languages. I'm constantly adding npm modules, but rarely nuget packages.

But the opensource/closed source bait and switch has happened a lot recently it does seem. Someone was blaming it on some failure of an open source initiative MS were running.

But one of the big frustrations sometimes is dealing with some American Koolaid company who thinks Erlang support is a priority but .Net isn't. No code examples, no officially supported library. Most recent example, IBM of all people (C-level insisting we use their cloud, ugh).

Similarly, I'm not a fan of "Enterprise" development regardless... I find a lot of .Net shops, like Jave, just create a lot of layers of indirection and abstraction that only lead to excess complexity, cost and difficulty in both maintenance and enhancement. The older I get, the more my mindset shifts to make things that are easy to replace without adding undue complexity or patterns.

So it's just a very different type of code and you can point at the language, but the reality is that it's the domain.

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.

What are free PDF generation/handling libraries in Java ecosystem what is their performance are they up to date and which licenses?

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.

https://www.npmjs.com/package/is-even

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.

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.

Office Space took place there before the dotcom bust.

Less enterprisey, but John Carmack and id Software also started there.

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

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.

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.

...

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

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.

This is indeed a complete exaggeration.

I'm just fondly remembering the ASP.NET MVC churn or more recently, Azure API whiplash.

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

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.

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

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.

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.

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.

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.

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.

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.

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?

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

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.

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.

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.

What do you mean?

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.

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.

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.

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.

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

Where as large 'tech' companies don't tend to be like this.

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.

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

But I would levy the same complaint with most Java[1] usage as well.

1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

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.

I'm not saying all dotnet places are like this, but they are common.

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

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.

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.

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?

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.

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.

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.

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.

https://youtu.be/s4Cz49MLh4o?t=142

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.

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.

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.

- 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

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

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.

I'm sorry but most of us use Npgsql now

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

  > Need a database - should it be SQL Server? Should it be Windows Servers? etc.

  > there are many smaller companies (and startups) that may have concern paying for such tools.

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.

I do my hobby .NET development in Zed and my serious work in Rider. .NET is open source and MIT licences. I do most of my development on a ARM MacBook Pro, or using my workstation which runs Fedora.

We deploy our code on kubernetes clusters usually on AWS.

All of the tooling, compiler, libraries etc are open source and cross platform and free. Not a single one of the developers in my team uses Windows or Visual Studio.

C# has come a long way in the last 10 years. This much is clear, providing better support outside of the Windows ecosystem. However, many outside of the Windows/Microsoft ways are likely to be using languages like Go.

> What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.

There was no C# in 1995. (See it's easy attacking a sentence)

Delphi was the hit story then.

I was using it in my college projects back in 2001.

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.

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.

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.

Genuinely curious, why?

Then there's Django. Rarely changes, only for the better. Upgrading Django versions is usually painless too. The ORM is fine enough.

Hmm...there appears to be an interesting story and/or reason there...care to share?

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?

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?

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.

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.

While Blazor has some cool stuff built in, the cool stuff never felt worth the risk of building a product around it.

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.

Further you go away from that circle, the less enticing it is.

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

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.

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?

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

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.

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.

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.

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