It's a fair question! Go is certainly more widely used in web dev circles (e.g. esbuild) than C# is, that might go some way to answering the question.
I think folks want TypeScript to use C# because it's Microsoft, I'm glad they didn't just do that for corporate reasons. But I'm open to there being non-corporate reasons!
I agree that it's good they looked passed typical corporate reasons. I admit it's still strange to see.
At the end of the day, companies like Microsoft are in the business of making money and that's one of the reasons they made C#. If they don't see the profit in using one of their own products (and one that competes with Go) in their future products then why would I use them for mine?
It's like if they used Google Cloud instead of Azure, it'd be very weird.
Generally, I see Go replacing a lot of projects that would have previously been written in Java (namely network services/backends). Compiler is a bit of an exception, for sure.
Yes… there’s a lot of overlapping territory, for sure. Just like how Java relaces a lot of projects that would have previously been written in C++ or C.
Could you perhaps elucidate with a couple of bullet points? In my view Java / C# and Go are technically the same thing. There might be some cultural differences though, which honestly, people seem to care more about anyway.
On the technical side, Java and C# are OOP languages with nominal typing, compacting GCs (at least by default), objects are reference types, can't have a reference to a variable, strings are UTF-16, async is available via promises / tasks / futures, async scheduling is cooperative, and module boundaries are primarily type boundaries. Applications are typically shipped as platform-independent with a separate runtime. Interfaces are intrinsic to objects, from a runtime perspective. You can overload methods. Easy to dynamically load code at runtime.
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.
There are more overlaps with Java. It is gaining value types. Async is built into the runtime (see virtual threads), with preemptive scheduling. Its strings can be represented as bytes internally as well. It also has packages and modules for managing boundaries.
Java value types aren’t going to be even roughly comparable to what you can do in Go. It’s just gaining something with the name “value type”, don’t let the naming similarity lead you to believe that this is conceptually like how the same-named concept in Go works.
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.
I think whimsicalism's point may be that, if C# isn't the tool of choice for this port, then that's the death knell of C#. The death knell isn't what kills it; that's the death blow. The death knell is sounded after it's dead. If C# wasn't the choice here, then C# is already dead.
That may be overstating how dead C# is. But I think it is accurate to whimsicalism's point.
I don't think so. It isn't as if C# isn't competitive in many spaces. However, honestly, if you want to create a simple cli app, Go is a better choice than C#. With C#, you would either need to bundle .NET or try to use AOT features which will either make for a huge executable or development friction. With Go, that is just how it works out of the box so I get it from that standpoint.
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.
> Optimizing for similarity of codebases doesn't seem right imo,
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.
I don't think C# is being harmed by Typescript not being ported to it. There are a lot of companies that have used C# for years, and will continue to do so. They don't care if the TS compiler is not built with it.
There was a movement for C# to be a real developer language that is bonafide cross-platform. If Microsoft is citing cross-platform reasons to not dev with C#....
New companies aren't generally starting with Microsoft as their OS, these 'lots of companies' are legacy/enterprise stragglers and/or European.
There's an answer for that on the thread: they wanted to get as close to native code as they could while retaining GC, and Go is "native-native" (if you will), while C# is bytecode-native.
