Comment by jitbit

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.

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.

[flagged]

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.

Not OP but I still run into paid libraries (eg Telerik) all over the place in projects.

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.

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

C# and Java might be similar technologies at some level but they not similar developer experiences at all.

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

The thing that always turned me off about Java are the IDEs. Besides Java doesn’t have anything like LINQ. I would rather have an ecosystem backed by Microsoft than Oracle.

Does Java have real generics yet?

[dead]

Seems like many people are just coding as a hobby? Idk. I want to make money writing software and so I pay for libraries that solve a problem for me.

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

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.

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.

Sure, with quality libraries like "is-even", who can deny the supremacy of the JS ecosystem?

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

The Dallas area is a major tech hub. It’s just an older hub of major enterprisey type companies with major tech divisions there like Texas Instruments, AT&T, Bank of America, defense contractors like Lockheed, etc.

Office Space took place there before the dotcom bust.

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

>> we use .NET for backend and React for frontend. You don't need anything else

...

>> sure maybe you have some data science people who need python,

This is how it happens though; it's not "let's form a company with 10 developers; don't worry what tools they use!". It's starting with a single problem using common tools, then adding specialized problems where you could still use the same tools but they are not optimized, then adding an acquisition product that uses different tech, then growing to 100 or 1000 developers and may all use React or C# (doubtful) but don't use it the same way...

>> If you're going to make a change then migrate everything

Have you ever worked for a software company before? THis is not how it goes.

It's bad enough when you've got constantly changing "best practices" from MS so the thing you wrote last year doesn't look anything structurally like what you're doing now.

And all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.

> People love to talk about the right tool for the job, it's all BS

This sounds very close minded to me. It is certainly true that there exist tasks if not subdomains where some ecosystems are better than others. Using a hammer for everything might work for you if all your problems are nails. But that doesn't mean that all problems out there are nails

Using the right language for the problem domain is a good thing, but what I can't stand is when people self-identify as the one language they are proficient in. Like, "I'm Staff JavaScript developer" no buddy, you aren't "Staff" anything if you only know one language.

Do you also make everyone wear the same clothes, drive the same vehicle, order the same food

Do you measure that standard by leetcode?

> Apropos, what do they do for fun?

Odd question, but as a .NET developer myself

Mountaineering, climbing, bouldering, going to gigs, playing pool, running, music festivals, gaming, photography, watching F1, watching NBA, eating out with friends...

I'm not sure what the point of the question was ?

> what do they do for fun?

Play in a band, ride bikes, play video games. Sample size of one.

Been awhile since I've worked at one but it is usually grounded in trying to achieve 100% MS usage.

It is rarish to find a partial MS shop. Most of this is how hard MS makes it to use other tools. Even in 2025 they have good interop with external tools hamstrung.

Example: SQL Servers JDBC driver will convert an entire table's of data from ASCII to UTF and a full table scan instead of convertering your UTF bind to ASCII and using the ASCII based index. This doesn't break interop but does make it painful to code and one more reason to just use .Net.

My biggest complaint would be a tendency to blindly use a "Microsoft first" approach to selecting tech rather than evaluating things on their own merits in the context of their own use cases.

Some Microsoft stuff is really good but it's not universally true. And in the worst cases you end up locked into some hard to migrate off platform that is withering on the vine.

I worked at a Microsoft shop, and this was my experience.

1. Process, process, and more process. Doing anything required layers of management approval. Trivial tasks become month long, or even years long, processes.

2. You have no power or agency. Something is broken? You're a developer, you should be able to fix it right? No. Broken things stay broken. You swim in your lane and keep your head down. Mediocrity is the goal.

3. Optimization doesn't exist. If a process is manual and takes you, a developer, 10 hours, then that's what it is. Nobody gives a flying fuck about tooling. Nobody cares if you spend 50% of your dev time doing random stuff. And if you even dare try to fix it, you will be told it's impossible and you're wasting your time.

4. Management is king. You will have to lie to them. You will have to spend time re-entering the same data in 5 different places so they can read it conveniently. You will have to make Excel workbooks. You will have to dumb things down, and then dumb them down again, and again. Everything is about Jira... Unless they're a really high up manager, in which case you have to take whatever is in Jira and put it in a word doc and send it to them, because they don't know how to open Jira.

Totally agree.

Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.

My last comment, which you referenced... focused not just on C# or .NET.. but the focus of "you need Microsoft" in general.. this includes Windows, SQL Server, etc.

Again, my comment is focusing on someone on the outside looking in.. and WHY people end up making decisions away from C# in favour of (something like) Go.

I am aware of deploying to Linux containers, etc.

???

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.

> most decent C# devs already moved away from to JetBrains/vscode.

My comment is NOT talking about 'decent C# devs'

It is a RESPONSE as to why more people are not using C# for startups. For those who are not familiar with C# MAY be put off using it for those reasons... and why another language might be used.

You know there are people.. programmers.. who are not C# developers... and likely refuse C# because of various reasons.. right? It can be based on the fact its Microsoft. My comment is based on startups and, from my experience, people like go all in on C# because decisions have been made to go all-in Microsoft.

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

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

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

> C# is not linked to IDE. You can do `dotnet build`? Can run on Linux if you will. Database choice? You are NOT limited to SQL Server or Windows server.

People who already are familiar with C# know this. To programmers that do not, may prefer to stick with another language to keep away from Microsoft in general.

Again - my comment is a response about why C# is not used more for startups. I am not suggesting it isn't, but there are plenty of reasons, and this is likely just one.

I've seen plenty of innovative .NET/C# shops. They just don't have the "hip" factor to them.

It's mostly about pay too. And yeah some people want more exciting jobs and maybe even outlandish stuff like the ones you listed (regardless of the sarcasm!). Yes at the end of the day most software isn't super exciting, but it doesn't make a tech stack or platform where most of your job prospects would approximate to "working on some run of the mill, mega enterprise or SMB software project" any more attractive for devs.

Especially when even its advocates somehow use that as an "upside". It might very well be for a lot of people! But it's also a massive turn off for others. I have never worked in a startup or big tech, and work on very concrete and critical products yet I'd very much rather work on even outlandish SV stuff (at least the pay is usually great and the job environment could be good!) rather than on some SMB CRUD or some generic backend service. If I don't have a choice I could do it but it's not super enticing.

It is ironic when companies like Microsoft and Google end up showing the sort of "permanent reimplentation" behaviour that used to be typical of opensource, whereas certain opensource projects persist seemingly forever. Python, Django, Emacs - these things will likely see the end of the galaxy; meanwhile, big companies now build and discard key projects every other year.

Blazor will produce super bloated web apps. I can see it being used for an in-house thing with captive users but for a real world product or a public app? It would be a terrible choice.

Also the DX is just not there. Hot reload is a mess. Even when it works it's too slow. Once you start using hot reload with Vite you can't go back to waiting seconds for every change and full page reloads.

> Compared to what?

Everything else?

Do you think it's acceptable that it took 4 years for Minimal APIs to get validation?

What about hot reload being broken for years and years?

Which version worked flawlessly? And I guess blazor can work great but that's super specific to what you use it for. Much more so than most front end technologies/stacks. And both WASM and Server versions have a lot of compromises.

I avoided Blazor, despite multiple people on my teams pushing for it. It always felt like it fit in the same space as web forms and silverlight. A product created to fill a gap of developers that wrote desktop apps and don't want to learn how to write front end code for the web. Plus it binds you to the product lifecycle of a .net side project that likely will be abandoned.

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

Blazor honestly is great for 'I need to write a simple backend control plane for whatever'. I.e. internal only stuff where you care about just shipping something functional and don't care too much how it all looks/etc.

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

I tried Razor. It's mature, has tons of features, and it's very fast. But it only really solves rendering HTML.

You will still need to integrate Vite somehow to use modern CSS, TS, etc. And if you do that, why even use Razor to begin with?

Also, hot reload is garbage. C# will never get close in speed or features to something like Vite.

Create a hello world dotnet container, then do the same in a modern language. Then compare image size and resource consumption. Then imagine you're running tens of thousands of containers in a proper SaaS microservices model, and it'll make sense :)

The runtime alone is a bit over 200mb, and that doesn't include additional packages you'll most likely need.

That being said, I'd much prefer to deploy a C# application over Node or Java, no argument there. But saying "I wish more startups were using C#" makes me wince. C# seems well-suited for the monolith-architected VM-image-deployed strategy of the early 2000s, but it's pretty close to being the exact opposite of modern best practices. And unfortunately it's kinda unfixable in a language that depends on a VM execution environment.

I'm sure all this is short-lived however -- I'm relatively confident we'll see deployment best practices converge down to "use whatever language you want but you must compile to WASM" in the next decade, so the warts of devs' chosen language aren't an ops problem anymore.

You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

Just an FYI, Go still bundles a runtime in its native binaries. C#'s AOT has restrictions on what works (largely reflection), but these same restrictions apply to Go (although Go applies these restrictions into how it's designed for the entire thing).

rust and go are only good at single binary. when you need a few their size adds up quickly, because they don't really do shared libs.

F# is less popular, but it’s a first class .Net language with full MS support and integration onto .Net (VM and ecosystem). C# has been tracking F# and aiming for language parity for years (ie all your modern C# devs should be learning the same language facilities). F# is multi-paradigm so C# devs can write idiomatic C# with minor forced changes. And as a .Net language you can always decompile it into C# and keep going from there.

That’s a radically different proposition than, say, raw OCaml and not particularly niche. It also impacts hiring pools differently since competent functional C# devs are viable, but it tends to appeal to a certain calibre of dev.

Moving faster with fewer errors and more talented candidate pool are relevant to repackaged SaaS startups too. Leaves more time for the other stuff and scales better.

It's good for, and I am not being sarcastic or snarky, justifying high pay and gate-keeping. Developers should set up more barriers for entry - look at doctors and lawyers.

How important is being a language expert in x vs all your other skills as a Software Engineer? My opinion is that "higher level" skills (like system design/architecture, product thinking/planning etc.) are so much more important than language minutia (outside of specialized fields).

If a business is turning away candidates because they "don't have n years of experience in x" that doesn't sound like a very dynamic/interesting place to work, it sounds like a code monkey job. AI is going to eat code monkey jobs.

I am working at a 2k fte company and we use F# for a lot, its very nice to work with, prefer Rider over Visual Studio though.

Yea, but then the other end has to serialise the HTTP API stuf to a typed object on their end.

It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.

I sometimes miss Spring magic when working with ASP.NET, and I worked 12+ years with C# and only a year with Spring. Not saying one is better than the other, it's always a choice, less magic = more boilerplate and less boilerplate = more magic.

> and most language features don't feel bolted on like with Java (anything from functional programming to extension methods to whatever)

Java doesn't have extension methods and while both are decent languages, C# is the one that likes implementing every conceivable language feature immediately, while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.

> but i haven't used java in a very long time

What was the last Java version you used? There has been a huge momentum in adding new features lately, granted, it is slower than in C# (Java's top priority is backwards compatibility, so it does not have the luxury of shedding old stuff or changing them once they are in), but in the last couple of years it has improved tremendously. The JVM (especially in the garbage collection front) but also the language - half of an ML-style language is there (for example, ADTs and pattern matching), the other half is coming soon!

>If i remember right Java's webserver beats ASP.NET in performance benchmarks

That's not the case anymore. Kestrel is one of the fastest servers there is, and it beats every Java server out there.

> Documentation is vastly better compared to Java ones, it's like day and night

This is absolutely not my experience, especially when it comes to the ecosystem and third-party libraries. Like Java is pretty much the best in this category.

If you ignore Android / iPhone, where language choice is limited, practically all other development is web.

It really depends where you are. In the UK half the places seem to use .NET in some form or another.

I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days.

The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft.

The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET.

I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.

> It's just .NET that's largely ignored for no real technical basis.

As someone who has been developing primarily on .Net for the past decade this is absolute bullshit.

1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging. 2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways. 3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes. 4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc. 5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement. 6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all.

There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.

You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.

> Backends can be any language

In +90% of cases you will still need a frontend for that backend.

TS full stack is by far the best option for this.

As much as I think C# at a platform level is a better tool for building backends, you'll get the better bang for the buck learning TypeScript if you don't already know TypeScript.

Then if you have the chance, you'll find C# an easy transition from TypeScript, IME. Learning C# first, on the other hand, will make you a better TS developer, in my opinion, because it will shape your approach to be more diligent about using types. This is something most JS/TS devs do very poorly and at scale, it's very hard to reason about code when it requires digging down several layers to find the actual types/shapes.

"Enterprise" frameworks like Nest.js are much more similar to ASP.NET or Spring Boot than they are to Express, Hono, or Elysia so once having experience with .NET Web APIs (or Spring Boot) will make Nest.js (for example) easier to pick up.

Not really, you should learn Typescript by learning JavaScript first. Then consider learning C#. Or if you want to focus on the back end side learn C# and skip TS/JS.

They are created by the same person but they are very different in my opinion.

TypeScript is "a tool" for JS, it is possible to compile without errors but still fail in runtime (e.g. wrong object type returned from API), on the other hand parsing JSON with C# will give you correct object type, it may fail if some properties are missing but it will fail at parsing call, not further down when you try to use missing property. In other words typing is not glued on top of the language it's core of the language.

I have tried it recently. It felt like I was coding Java. I realize "feel" isn't very objective, but I don't really like C-like languages in general. I like Rust, but only because of it's heavier FP-influence. C# is one of those languages where you don't mean to, but you can't help just creating tons of files/boilerplate/etc., which feels just like Java. Just my perspective, others obviously feel differently.

As far as I remember, cloning the project, sprinkling in some printfs and running it. He didn't want to use an interactive debugger. He was used to using the likes of nvm, uv, rustup, etc.

"Just" is an incredibly obnoxious word when used in the way that you have.

> Just install

Not on Debian? Have fun with that. You'll also need the Azure SDK. And what about openssl-dev? Oh no, you installed dotnet on Windows instead of within WSL? Start again.

No, you don't "just install" the SDK. There is a lot that the IDEs set up for you.

> Local nuget.config

I don't see how adding a nuget config improves anything. You have completely omitted what you place inside of it to make it build and use a local clone of the package source.

Look at all this nonsense that people have resorted to: https://stackoverflow.com/questions/32482746/how-to-temporar...

No. It's a tar + some config envars if you need to do it manually.

I use Rider† daily to write F# and C# on my Mac. It works great, I have no issues with it. It even handles the .NET Framework 4.8 code‡ that I maintain without any issues thanks to Mono.

† And Neovim occasionally, but I mostly use it for Typescript or anything that isn't F#/C#.

‡ https://github.com/nozzlegear/shopifysharp

How is it so different than Visual Studio that you think it is "better"?

Yep.

VSCode gets you 90% there.

But IMO Rider gets you over 100%.

They couldn't get it right because Visual Studio for Mac was actually a rebranded MonoDevelop, an entirely different IDE than Visual Studio.

[dead]