> Being a Microsoft product is such a heavy baggage
JavaScript is one of the most common compile targets. "Who's the better JavaScript" was the most contested field a decade ago. These are not just toy languages - Facebook has Flow and Google has Dart. Both companies are far more web-adjacent than Microsoft. Yet Typescript won.
edit: I think it was considered, but go was a better fit
I guess I... just got bored of it, and fed up of Microsoft. I came to hate Windows and having to work on Windows so much that it sort of tainted C# for me. I'm not saying I'd never use it again but, whilst it will run cross-platform nowadays, so will loads of other languages and frameworks, so it's never at the top of the list when it comes to choosing something for a new project.
As for TypeScript? Absolutely loathe it. I'll use it professionally when I have to, but I'd never use it for one of my own projects. It's just so ugly I don't even like looking at it. I get why people like it but, for me, it's not enough. If I'm staring at something all day then, I'm sorry, it can't be ugly.
But, strangely, I still use and enjoy VS Code from Microsoft, and have no plans to switch to anything else.
(I also still have an Office subscription - or whatever it is Microsoft are calling that suite nowadays, I don't care - because I still use both Excel and Word fairly frequently. I could probably get by without, but I actually quite like Office - even on the Mac.)
The thing is, now most things I do target some flavour of Linux - and although I could write C# and target Linux with absolutely no problem - there are a lot of other options that C# has to complete with. Granted those options would also, at least in theory, have been viable options on Windows but it definitely would have felt a bit like paddling against the flow to host Ruby on Rails or Python or whatever on Windows.
And if I want to target command line or desktop with something cross-platform I'm going to compile to a native binary that requires minimal dependencies, so Rust feels like a more natural fit than C#, especially with Microsoft's desktop UI story being such a dog's breakfast (and even more-so when you account for cross-platform).
Again, in a commercial environment, I could imagine using Electron for that sort of thing because that's what most companies do (but because everything I do nowadays is backend, web, or systems integration, I haven't written a desktop app in a commercial context in 13 years, and I haven't written a command line app in that context since just before the pandemic). However, for my own projects I want to hew as closely as possible to my own principles and ideals and, for them, it'll be a cold day in hell before I ship a desktop or command line app that needs some giant runtime like Electron as a dependency.
Again, the point is that C#, whilst in many ways a great language, doesn't come out as the frontrunner.
> As for TypeScript? Absolutely loathe it.
The main things I don't like about TS are the volatile tooling, bad habits from other devs (not declaring types), compromised ORMs, require lots of package hunting, and module system.
Language is fine, tho.
It was pretty impressive work to scale PostgreSQL.
I got so worked up by it I built my own TyepScript compiler with my clankers in C# to prove that it can be done, my revival of the Common Language Runtime concept, project Copeland:
https://github.com/yuechen-li-dev/copeland
Currently, Copeland compiles a dialect of TypeScript to JavaScript, C#, WASM via Blazor WebAssembly, and NativeAOT, runs in csproj, and uses xUnit.NET for testing framework.
(The other reason is that Microsoft still refuses to do the obvious thing in .NET 11 and take the best part of Rust and let enums be `match`ed, despite the fact that both TypeScript and C# have weak enums historically, so I added payload enums to my TypeScript dialect because Microsoft won't.)
Pattern matching is in C# unless I misunderstood you.
https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html
Instead of .NET 11's more awkward (imo) `union` form.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
On the historical (And semi-current-ish) downside we had/have;
- lots of 'flash in the pan' stuff between 2008-2012ish (Silverlight comes to mind here)
- Anemic Entity Framework in pre-core, and the weird stuff EF Core had going on early in it's life.
- That constant worry as to whether you need to add .ConfigureAwait(false) to every async call in a library you want to open source.
- The thing where trying to do 'traits' in NetCore (Now that you can mostly mimic the behavior) has had some side-effects on performance, mostly resolved but still something you have to consider as far as impact. (To be clear tho, thank god, needed that...)
- WTF was that UWP workflow?
- Why can't we get a proper designer? I don't think it would be that hard especially given I can do nice things around workflow designers today. Speaking of workflows...
- The complete (what I probably guess was MS groups eating their own tail) thing where Workflow Foundation was almost truly productive, SSMS had a thing based on it that was surprisingly productive, and it has been murdered instead of getting the TLC it needed to really disrupt. This one is extra loud because it is so similar to the 'low code' platforms so many orgs have sank money into.
- Less impactful as far as people eating the lunch microsoft left on the table, but WCF.
The upshot is;
- If you're willing to do some looking there are great options out there. lazy example, linq2db is basically a DSL that is close enough to EFCore as far as 'how you compose' that you can teach it to a group of WITCH devs in 30 minutes or less.
- It really is easy to do all sorts of stuff. It's just productive.
And I am still not over the many breaking changes when they dumped full framework. Have to support a large code base, I think only now with AI will it be economical to redevelop it for .net core.
EF Core now is very, very good with only one minor gap with respect to migration merging (long migration history causes build times to explode).