For .Net, there's an established pattern of careless deprecation that produced enough frameworks to date codebases like tree rings:
- this year's correct way to access your database is...
- this year's correct way to serve dynamic web pages is...
- this year's correct way to make a Windows GUI is...
This pattern exists in all languages. I’d argue more so in fragmented community driven projects/languages/tools.
Except in the case of languages/tools like python, node, neovim etc. Everytime I touch one of these there is always a new better way of accessing DBs, making a web server, making a client side render, no a server side render, async library, configuration system, build system, runtime, GUI patterns etc.
There is a marked difference between a third party releasing some new library and obtaining (to some extent, demanding) community mindshare, without taking away anything, and the official platform maintainer suddenly replacing practically mandatory parts of what is perceived as the standard library. Javascript churn is fast, .Net churn is deep.
That's not really true. .NET Framework is still around. Even .NET core 3.x which is EOL a while ago, is still widely used with active stackoverflow and if you're loud enough with the .NET team at Microsoft they will help you there too.
The only difference I see between both is that there is an authoritative opinion when it comes to .NET (Microsoft) while there is no authority figure when it comes to node/Javascript. Even the actual runtime, package manager, module resolution, build tools etc get forked and replaced but since there is no authority, everyone is like "lets wait and see who wins". While with a language like .NET (or Go for that matter) you know that whatever comes from Microsoft (or Google) is the authoritative answer and people are more likely to jump to it right away.
The "authoritative opinion" is indecisive. Microsoft frameworks tend to be high quality, but there are too many. ASP? ASP.Net? ASP.Net Core? ASP.Net MVC? Razor? Blazor?
Well, you’re covering about 23 years of development there between ASP and ASP.NET Core.
Don’t get me wrong, the naming sucks. Microsoft is far more likely to recycle names for marketing reasons than just introduce a new name for plethora of stupid reasons.
But Active Server Pages means nothing anymore. It stopped meaning anything since 2003 but they use it as a brand name than anything. It’s no less stupid than gulp, bower, webpack, bun, deno, express, koa, next, vite, etc.
yet they still support it all.
also, you dont want them to stick to some old tech. you want them to evolve and take the best from industry. imho, they are doing just that and they are very good at it.
But why can't you fork it and take it in the direction you want? The situation is literally no different from Python or Node or Ruby, the people running the most popular distribution could take it in a direction you don't like and the power you have (or the only option you have) is forking.
Infront of the public, yes, but it says you need to be invited by someone from their team to participate yourself, compare that with the python process.
There's a distinction to be made between doing something in public and something being done by the public.
I would just like to understand specific threats or issues with using C# as a language. I've used it for 20 years at this point without issue and the latest IEEE language survey shows that it remains one of the top languages[0]; I'm wondering if you have some insight into why .NET and C# are a bad choice for engineering teams that I've somehow overlooked in my 20 years of working with it.
It sounds like your argument is "because Microsoft".
If you are using VS Code, GitHub, or TypeScript -- well, all those are also controlled by Microsoft, aren't they? Microsoft is the biggest investor in OpenAI and in fact offers their own Azure labeled OpenAI -- are you going to give up on OpenAI because it's Microsoft controlled? React is controlled by Facebook. Go is controlled by Google. So what?
Why use C#?
- It's a very small step from TypeScript to C# if a team needs higher throughput on the backend[1][2]
- `System.Linq` provides a superset of JS Array methods and is easy to map from one to the other.
- It's performance is on par or superior to Go[3] and competitive with Rust[4] while being much easier to adopt because of the language similarity to JS and TS.
- It is an object-functional hybrid language owing to its influence from F#[5]; discriminated unions are on the roadmap and available today with packages like Dunet and OneOf, it has pattern matching like Rust, extension methods provide flexibility in modelling, named tuples in C# 12 converge even more with TS, it supports destructuring record types and classes, it has immutable record types
- Minimal APIs are very familiar for teams using Express but need more performance. I'd actually say that it's a bit simpler than Express on Node for common use cases since there's nothing to import when setting up minimal APIs since it's all first-party Microsoft.
- Platform support for source generators are a revelation; it removes a lot of boilerplate code while actually improving performance over reflection.
- Many of the things teams love about modern JS actually have influence from C#. Lambda expressions in JavaScript, `async/await`, and more. In fact, C# and JS/TS have been converging (see the linked repo).
- It's relatively easy to write high throughput code in C# with support for both concurrency (Tasks + Channels) and high level abstractions for parallelism (Task Parallel Library) as well as full access to threading.
- C# allows easy access to underlying low-level primitives; you can program with high level abstractions for productivity but still have access to call `unsafe` code if needed.
- EF Core is possibly the best ORM on the market right now in terms of performance, ease of use, maturity, and database engine support.
- A benefit of a language and runtime backed by Microsoft and used in the enterprise is that security issues get addressed by a team of professional engineers; you don't see the same types of security issues that pop up in the Node/NPM ecosystem.
- This is a big boon particularly because of the broad standard libraries and first-party libraries for many use cases. Rather than importing unknown dependencies for common use cases, you end up with a baseline of professionally maintained, OSS code.
- GitHub's State of the Octoverse report in 2020[6] showed that C# had the least Dependabot alerts and has the least transitive dependencies (less prone to security issues via package managers).
- As a general purpose language, it can be used in many domains from desktop to devices to web to gaming (both Godot and Unity; RyujinX).
- It's also quite mature and stable while languages like Rust are still ironing out async and Go just released generics. C# has been there; done that.
My personal opinion is that C# is the language that most teams want but don't know enough about it or have a bad taste from the .NET Framework days. While the runtime is more complex than Node, the language is very similar to TypeScript owing to its lineage from Anders Hejlsberg. C# and .NET in its current form is a great language and platform to build on.
Besides, if a team is already using VS Code, GitHub, and TypeScript, they're already in the Microsoft controlled ecosystem.
This is a good list. I really feel it's a very good platform and just a very pleasant environment to work with. I guess I'm a "fanboy" as someone else on this thread said, but I became one because I had to use it for a job and I found out how solid it was and how much I enjoyed tinkering with it.
I really appreciate what I can do with .NET and I don’t do much care for the language that I need to use. Yes C# is nicer compared to Java and C++, but after many years with Haskell they all are nowhere nearly as ergonomic and expressive, which is fine. I’ve tried F# a couple of times but couldn’t get used to the OCaml like syntax.
Anyway, I favor productivity way over ergonomics. And my .NET apps are very robust and very easily deployed. Everything is perfectly well integrated. No surprises. Almost no sharp corners left. The DX is superb. The performance is great. It’s so easy to run. Time to delivery is good. And the most important bit - I don’t need to keep all the hidden Java traps in mind. JVM with its many implementations is an amazing piece of tech, but in my experience it appears as something overengineered and requires too much maintenance and fine tuning. Just like Spring, Hibernate, and many other components of a typical Java app.
What risk do you see here?