.NET 10

.Net is also good as a platform for other languages. I recently started working with RemObjects, and you can compile languages like Java, Swift, Go and more (VB, Pascal) to .Net. Then, the whole framework and ecosystem is available. I'm liking it a lot.

They have customers who are startups and the 'got to have tools' folk like having lots of languages since they can onboard people who know anything-not-C# and benefit from the .Net library.

> they can onboard people who know anything-not-C# and benefit from the .Net library

I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone.

People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference.

And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.

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

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

If your organization has one API written in Node, another in Java and third in Python without any reason, then yes, all the problems are nails. And sadly, I've seen this a lot.

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

> Do you also make everyone drive the same vehicle

Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.

How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.

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.

If you can justify with good reasons why you absolutely need this other tool then that's fair game - hence the data science example where I allow for specialists to use specialized languages for specialized tasks.

I'm talking about general software development and web dev in particular. There's a trend where you'll see one org has or web app using .net ad react, another using next.js, another using Java and Vue, one djnago and htmx, and so on.

And there is literally no reason for any of these choices, they're all fairly basic web applications that could have all been made in literally any half decent web stack. So whether the devs who made these choices knew or not, they made them based on preference not any kind of reason or need, they're all nails and any hammer would have done the job just fine.

So you don't like .NET, that's fine. I'm not saying everyone needs to use .NET. I'm saying pick one thing and stick with it.

That said I think you're exaggerating those complaints, the docs for C# are quite good imo and I've been working with ASP.NET web apps for half a decade so far and I'm not seeing any problems like you're describing.

Maybe you're miffed about the Framework to Core/.NET switch? That was a bit of a doozy but the ecosystem is so much better for it I'd say it was worth it.

But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..

Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks.

I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.

Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.

> the thing you wrote last year doesn't look anything structurally like what you're doing now... all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.

This is indeed a complete exaggeration.

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

I don't think this is an valid comparison. There's a problem called technology sprawl, which is characterized by needlessly increasing maintenance needs and cognitive load and lower development speeds caused by the need to juggle multiple programming languages or frameworks. There is a fixed cost in maintaining each tech stack and even development environment, and you multiply that cost each time you think it's a good idea to introduce yet another programming language or framework.

Sorry, I love .NET and have used it from it's rollout back in 2002.

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

> But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..

No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.

I think that question is more "how many different makes of van can your delivery company afford to maintain?"

Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"

The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.

The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.

> Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.

Yes, this.

> I'm saying use one tool for one task.

I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.

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.

> Yeah, .NET is a truck

I know one person who was good at python, and who looked at the "classic" .NET hello world app with usings, namespace, class, main method etc containing the "Console.Writeline" payload, and noped out immediately, saying "if it's that verbose that it takes 10 lines to do what's 1 line in python, imagine how terrible real code must be!"

Personally I think they were wrong about that - it was optimised for larger programs, not trivial ones.

But also it helps me understand the ongoing push towards the point now where "hello world" is is 1 line in 1 .cs file only. And `dotnet tool exec` means you don't even need to install a utility to use it, etc.

In other words, .NET started life as a truck, with many features to support large codebases - usings, namespace, class, method etc. but is also general purpose enough that you can now also write a "bicycle" program.

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

>> And there is literally no reason for any of these choices

I'm a manager now but definitely held a variation on this "people are idiots" view when an IC and younger. Question: are all your coworkers idiots? No? then why would all the work done before you be the product of idiots?

I found it really valuable to approach scenarios where the initial response is "how could this possibly happen?" as a cultural anthropology question. It turns out there were many rational decisions made, most that I would have gone along with that brought us to what we see today. My coworkers are actually really good, some of them who manifested what we see today are amazing. Many are crafting code, making thousands of microdecisions without perfect information or 100% clarity across a large organization, reacting to changing markets and directions, client needs, shifting priorities, executive decisions, technology changes... the list goes on.

This is all my way of saying there might be many reasons for any of these choices, and you'll help your own cause - and happinness - if you step back from your zealotry and take an empathetic approach that's less binary.

Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that. Vehicle fleets are often aging out with these timelines.

So if we either stretch the fleet management analogy to 50 years, or software applications only lasted 3-5 years maybe it IS fair to say the both have either a lot (former) or very little (later) inconsistnency?

>> Yeah, .NET is a truck and React is a bicycle

I'm not a car guy but I most certainly a bicycle lover, so I will jump on you and say you often need more than one type of bicycle. Joan commutes to work? she wants a city ebike. Dan rides at the bike park? He wants a DH bike. Randy ride centuries on the weekend on his TDF road bike and Sally rides with her kids on a mountain bike.

So yeah, we can pick one bike type and force everyone to ride it, and the results will suck & everyone hate it. Your job can be to continually force everyone to follow this policy or you can stop and we'll get a lot of variation. THis is how it happens.

> Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that.

.NET gets refreshed annually. The last bigger change was nearly a decade ago. So not all that different.

But I don't think that the analogy stretches, really. e.g. where I am all .NET apps are .NET 8 LTS or 9, and will be all be .NET 10 LTS by middle of 2026. You can upgrade an app to a new model year much more easily than a vehicle. The "software application, on a SDK major version" only lasts 1-2 years.

Eh, no, you don't hire those employees. You're stretching this analogy in some odd ways.

Well, they clearly all know how to ride bikes, so you offer to hire them to deliver using company bikes as a day job. And let them ride whatever they want on weekends.

The "force everyone to ride it" on the weekend part is where I think the analogy has broken down irreparably. We're talking about cost of ownership of company equipment used during working hours for much more defined tasks. What flavour of bike you enjoy riding on weekends is not relevant.

Programming language are inherently flexible, especially those that aim to be "general purpose". Fine-grained distinction of road bike vs mountain bike apply more to the apps created than the coding tool.

Some of my coworkers are awesome. Super talented, super smart people.

But most developers are pretty bad. I see a lot of developers who hardly do any work at all, and many who do lots of work but it's all trash. Buggy, overcomplicated, untested, dumb pointless decisions.

Like my current project. Two guys started it - .NET backend, React frontend. Sure, fine. But let's use Azure functions for the backend instead of a regular web api. What. We asked them why, no reason. And their whole codebase was trash, I've deleted about 90% of the code that they had written and I'll delete the rest too.

I've also been in a team that had the problem I highlighted in the OP. 20 different apps, 10 different JS frameworks etc. Speaking as someone who worked on these apps, there was absolutely no reason to choose one JS framework over another. I could have made them all in React no problem, they're just websites, not much more than glorified PDFs. How you generate the html is irrelevant. And the code was mostly trash. Overcomplicated, buggy, untested etc.

I did struggle with this early in my career - am I just a narcissist? Everywhere I turn the code is just trash, maybe I'm the problem? But now I've worked with people who do good work. I've seen my own ideas work in practice. I know for a fact my judgement is good.

In university I was the one who helped everyone else. I was always ahead, while my peers could hardly keep up. When we graduated a lot of them would have struggled to solve fizzbuzz in 20 minutes, yet we all have the same degree. No wonder there's so much trash code around.

but they all delivers, just that they don't suit your taste doesn't mean it can't

> This is how it happens though

No it isn't. This is not how you end up with 7 different frontend JS frameworks in 7 different web applications. Using python/matlab/r for data science is completely fair. These languages are standard in this field, they have the most tools and built-in functionality for this purpose.

I mean if you want to do ML and data science stuff in C# or whatever go right ahead. If you can make that work that's great. But I also think, as someone who aggressively promotes sticking to one language, that it's fair to use Python for data science.

What I don't condone, as I said, is using multiple tools for the same task. So for example, having one team/dev using Python while another uses Matlab and yet another uses R etc.

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

Yeah, I know. That's the problem. People just introduce new tech like it's nothing. That's why I'm saying it needs to be a big decision. So if it's really worth it okay let's go for it. But for the vast majority of cases it just isn't.

Online forums often have people asking "hey I found this tutorial for learning c# but it's way way back for .NET 7 will it even work in .NET 9?"

The answer is always a variation of "yes, you'll be fine, but also look at a "what's new" summary for the new version.

I get you actually.

MVC churn was real, EF Churn was real, heck NETCORE itself was a (at least warned about) churn, 3.1->6.0 was minor but still definitely a thing [0].

[0] - Now that I'm thinking it out loud, maybe that's why they changed the branding from .NET CORE to just .NET; The churn was more or less 'done'...