but Go and C# are basically occupying the same space... if even MS isn't doing C# for a project like this, it's basically a death knell for C#.
This happens despite the checklist similarity between these languages.
hearing of this pains me
Go has structural typing, non-compacting GCs, allows you to freely choose value / reference types, can make references to variables, strings are bytes or UTF-8, async is built-in to the runtime, async scheduling is preemptive, and module boundaries are defined by the package you’re in. Applications are typically shipped as native code with a linked-in runtime. Interfaces are extrinsic to objects, from a runtime perspective. You cannot overload functions. Hard to dynamically load code at runtime.
When I write it down like this, they don’t seem all that similar to me. They’re all… garbage collected and imperative? Memory safe (or mostly) by default? That doesn’t seem like a lot of commonalities.
“They are all used for backend programming” isn’t really that interesting because backend is where you can choose whatever language you want. Facebook has a ton of Hack backend, Jane Street has OCaML, etc.
Virtual threads are not preemptive. Maybe you can point me to documentation that says otherwise, but my understanding is that virtual threads are scheduled at blocking IO points or places where the thread interacts with the runtime.
Strings can be represented internally as bytes in Java but this is kind of an optimization which happens behind the scenes under specific scenarios, and it’s not a part of the string API like it is with Go. What you’re saying is technically correct but it’s not relevant.
You can use package-private accessibility in Java but surely you can see the clear difference between the way Java and C# work, and the way that languages like Rust, Go, and Haskell work, where the module is the primary technique for modularization (rather than the class).
I’m really just trying to describe differences here, so I don’t think it’s really useful to fight over the technical details. Go doesn’t walk like Java, doesn’t quack like Java, it doesn’t look like Java when you squint your eyes.
That may be overstating how dead C# is. But I think it is accurate to whimsicalism's point.
I still don't understand their rationale for not using Rust however. This is going to be run millions of times a day by web devs - it makes sense to make it as fast as possible. Optimizing for similarity of codebases doesn't seem right imo, and a dubious position to begin with as Go and Typescript aren't that similar anyway.
It's simple, it's cheaper and faster (Time to market) to do Go than Rust. Rust has a pretty high learning curve, and there aren't many people writing it internally in MSFT I guess. Go's syntax is literally C + Python, from my previous experience, ramping up is a pretty fast affair as an experienced dev.
New companies aren't generally starting with Microsoft as their OS, these 'lots of companies' are legacy/enterprise stragglers and/or European.
That explains a lot then, because I see a lot of C# still around here. Even for new projects.