[no_wizard]

Like others I'm curious about the choice of technology here. I see you went with Go, which is great! I know Go is fast! But its also a more 'primitive' language (for lack of a better way of putting it) with no frills.

Why not something like Rust? Most of the JS ecosystem that is moving toward faster tools seem to be going straight to Rust (Rolldown, rspack (the webpack successor) SWC, OXC, Lightning CSS / Parcel etc) and one of the reasons given is it has really great language constructs for parsers and traversing ASTs (I think largely due to the existence of `match` but i'm not entirely sure)

Was any thought given to this? And if so what was the deciding factors for Go vs something like Rust or another language entirely?

[emseetech]

| with no frills.

People say this like it's a bad thing. It's not, it's Go's primary strength.

[whattidywhat]

I can see the appeal. Not having to write C# style oop probably gave the team a huge productivity boost. I bet it compiles hundreds of times faster making the team, cicd, and dev efforts substantially more productive. Cohesive integrated modern tooling is also a huge plus. Project structure is considerably simpler... I am not really a go fan but I would chose it over c# in a majority of cases as well.

I think they missed out by not going with Rust. It seems like the social factors weighed out. Probably hard to quickly assemble a rust team within msft. Again though that makes Go a practical choice. I don't see why people are so confused by it. Go is a pretty widely used and solid choice to get things done reliably and quickly these days.

[commandersaki]

The reason they didn't do Rust is because it was faster and more reliable to port the compiler and Go was a strong match particularly because of struct layout, types, concurrency, etc. but most importantly because it was native code with automatic garbage collection which Rust simply doesn't have. There's a video of Anders talking specifically about this.

[whattidywhat]

The automatic gc doesn't seem like an actual deal breaker though. They probably just didn't want to redesign a bunch of data types that assumed one existed.

I'm not arguing saying they made a bad call. I think what they did was smart with the options in front of them and whatever budget they have. The world isn't good for idealism, but it ideally could have been written in rust in my opinion.

[commandersaki]

> it ideally could have been written in rust in my opinion

What exactly would that buy and would the outcome matter much?

In my opinion: pragmatism > idealism.

[Imustaskforhelp]

exactly , it sounds as if he is entitled to rust software.

Golang is generally very fast and simple as well , the only problem is of memory allocation / garbage collector overhead but the benefits outweigh the loss.

[zveyaeyv3sfye]

> They probably just didn't want to redesign a bunch of data types that assumed one existed.

Dude, just read the article being discussed, this is addressed so you can just stop making shit up.

The audacity of people like you to just keep adding speculations upon speculations on a subject without even bothering to learn what is being discussed.

[whattidywhat]

Yes they said there were issues with cyclic data structures. Not really speculating just wrote it funny. I get why they chose what they did and even said I agree with it.

[zveyaeyv3sfye]

> I think they missed out by not going with Rust. It seems like the social factors weighed out.

They absolutely address this in the linked article, so why are we even speculating here?

> Probably hard to quickly assemble a rust team within msft.

The same MSFT that is rewriting their Windows OS in rust as we speak? I think you should stop commenting when you don't know anything about the subject.

[oldmanhorton]

Saying that Microsoft is "Rewriting Windows in rust" suggests you might not be as informed as you think... Very specific components with history of performance or security issues are getting ported in a very uncoordinated effort. Windows will be primarily C, C++, and C# for a very long time to come

[whattidywhat]

Also those are two different skill sets. Writing critical sections of an OS is not the same thing as writing a compiler. And completely agree, windows to what I have read, is being deliberate and isn't doing a total rewrite at all. Thanks for chiming in so I could type less.

[za3faran]

> Not having to write C# style oop probably gave the team a huge productivity boost.

I wrote a lot of Go code as well as Java. When people say things like this, I'm not quite sure what exactly they are referring to. No one is forcing you to write mutli-level deep inheritance hierarchies in Java/C#, and Go itself is OOP. Structural typing has its issues as well. Where does this supposed inherent productivity boost lie?

[Imustaskforhelp]

Dude not all things have to be written in rust just for the sake of it.

Rust is really hard , compared to golang. This can increase outside contributors as well.

Golang is love , Golang is life.

[selfmodruntime]

Yes. For Webservers. Not for compilers. I wrote a bunch of compilers, and Go is not a language I would choose for this.

[bilekas]

Go is exceptionally fast for a transpiler. Esbuild is a great example.. Rust would offer any significant gains vs adoption for support.

[9rx]

Unless, of course, you are not working on a greenfield project and instead are porting an existing compiler from Typescript, in which case Go is the language you would choose as it is the language that most closely resembles Typescript, allowing ease of bulk conversion by script. The same reason why it was chosen for Typescript.

[selfmodruntime]

I read that response and I agree entirely! Porting Js to Rust isn’t feasible. I love Rust but it’s good to know your constraints.

[DanRosenwasser]

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I'll post the response below. https://github.com/microsoft/typescript-go/discussions/411.

____

Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript. We wrote multiple prototypes experimenting with different data representations in different languages, and did deep investigations into the approaches used by existing native TypeScript parsers like swc, oxc, and esbuild. To be clear, many languages would be suitable in a ground-up rewrite situation. Go did the best when considering multiple criteria that are particular to this situation, and it's worth explaining a few of them.

By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management. While this implies a garbage collector, the downsides of a GC aren't particularly salient in our codebase. We don't have any strong latency constraints that would suffer from GC pauses/slowdowns. Batch compilations can effectively forego garbage collection entirely, since the process terminates at the end. In non-batch scenarios, most of our up-front allocations (ASTs, etc.) live for the entire life of the program, and we have strong domain information about when "logical" times to run the GC will be. Go's model therefore nets us a very big win in reducing codebase complexity, while paying very little actual runtime cost for garbage collection.

We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code.

Acknowledging some weak spots, Go's in-proc JS interop story is not as good as some of its alternatives. We have upcoming plans to mitigate this, and are committed to offering a performant and ergonomic JS API. We've been constrained in certain possible optimizations due to the current API model where consumers can access (or worse, modify) practically anything, and want to ensure that the new codebase keeps the door open for more freedom to change internal representations without having to worry about breaking all API users. Moving to a more intentional API design that also takes interop into account will let us move the ecosystem forward while still delivering these huge performance wins.

[electroly]

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C#, given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?"

C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed.

C# has all that stuff that the FAQ mentions about Go while also having an obvious political benefit. I'd hope the creator of said language who also made the decision not to use it would have an interesting opinion on the topic! I really hope we find out the real story.

As a C# developer I don't want to be offended but, like, I thought we were friends? What did we do wrong???

[fixprix]

Anders answers that question here - https://www.youtube.com/watch?v=10qowKUW82U&t=1154s

Transcript: "But I will say that I think Go definitely is much more low-level. I'd say it's the lowest level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In contrast, C# is sort of bytecode-first, if you will. There are some ahead-of-time compilation options available, but they're not on all platforms and don't really have a decade or more of hardening. They weren't engineered that way to begin with. I think Go also has a little more expressiveness when it comes to data structure layout, inline structs, and so forth."

[electroly]

This is a great link, thank you!

For anyone who can't watch the video, he mentions a few things (summarizing briefly just the linked time code, it's worth a watch):

- Go being the lowest level language that still has garbage collection

- Inline structs and other data structure expressiveness features

- Existing JS code is in a C-like function+data structure style and not an OOP style, this is easier to translate directly to Go while C# would require OOPifying it.

[WuxiFingerHold]

Thanks for the link. I'm not fully convinced by Anders answer. C# has records, first class functions, structs, span. Much control and I'd say more than Go. I'd even say C# is much closer to TS than Go is. You can use records for the data structures. The only little annoyance is that you need to write the functions as static methods. So an argument for easy translation would lead to C#. Also, C# has advantages over Go, e.g. null safety.

Sure, AOT is not as mature in C# but is this reason enough to be a show stopper? It seems there're other reasons Anders don't want to address publicly. Maybe as simple reasons as "Go is 10 times easier to pick up than C#" and "language features don't matter when the project matters". Those would indeed hurt the image of C# and Anders obviously don't want that.

But I don't see it as big drama.

[mexicocitinluez]

I dont think there are other reasons.

The side-by-sides that show how Go code is closer to the current TS code (visually) than C# would be are pretty compelling. He made it pretty clear they're "porting" not rewriting.

[WuxiFingerHold]

After reading the long Github thread, I think you're right. It's probably just as simple as "what is the easiest way to copy our TS code 1:1 to a faster language". And this case Go wins due to its simplicity.

[saturn_vk]

> You can use records for the data structures. The only little annoyance is that you need to write the functions as static methods. So an argument for easy translation would lead to C#. Also, C# has advantages over Go, e.g. null safety.

Wouldn't these things be useful if you are making an actual compiler, that would run TS? Since in this case, the runtime is JS, I don't think any of these things would get any usage, unless they are used in the existing transpiler.

[vips7L]

An unpopular pick that is probably more low level than Go but also still has a GC: D. Understandable why you wouldn't pick D though. Its ecosystem is extremely small.

[999900000999]

I think you D fans need to dogfood a startup based around it.

It's a fascinating language, but it lacks a flagship product.

I feel the same way about Haxe. Someone created an amazing language, but it lacks a big enough community.

Realistically languages need 2 things for adoption. Momentum and ease of use. Rust has more momentum than ease, but arguably can solve problems higher level languages can't.

I'm half imagining a hackathon like format where teams are challenged to use niche languages. The foundations behind these languages can fund prizes.

[vips7L]

Did my post come off as a fan? I directly criticized its ecosystem. It wouldn't be my first pick either. I was just making conversation that there are other options.

And AFAIK Symmetry Investments is that dogfood startup.

[polskibus]

A missed opportunity to improve c# by dogfooding it with TS compiler rewrite.

[geodel]

They are trying to finish their current project and not redo all the projects which their current project may depend upon.

[cxr]

"Finish"?

[mohsen1]

C# is too old to change that drastically, just like me

[Rapzid]

Sounds like C# was too late with dictionary collection expressions.

[jodrellblank]

> "given that C# was famously created by the guy writing the blog post"

What is this logic? "You worked on C# years ago so you must use C# for everything"?

"You must dictate C# to every team you lead forever, no matter what skills they have"?

"You must uphold a dogma that C# is the best language for everything, because you touched it last"?

Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those? Because there is no logic; the person who created hammers doesn't have to use hammers to solve every problem.

[uticus]

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course).

So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages.

If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?

[_bin_]

funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.

[nindalf]

Could you give some examples of both? Also, why did they choose to do this?

[jodrellblank]

> "So it's not just that the lead architect of C# is involved in the TypeScript changes."

Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is:

https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - "I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And then when he and I had a little side project with others to do TypeScript, he stayed over there. And I got to take over as lead designer C#. So for the last, I don’t know, nearly a decade, that’s been my job at Microsoft to, to take care of the evolution of the C# programming language"

Years later, "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird; he's a person with a job, not a religious cult leader.

> "If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?"

Like these? https://www.slashgear.com/1642034/fords-powered-by-non-ford-...

[cxr]

> "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird

It's also not what anyone said.

> It's best not to use quotation marks to make it look like you're quoting someone when you're not. <https://news.ycombinator.com/item?id=21643562>

[uticus]

> Like these...

Nope. None of those are even close to Ford + Chevy. (Ford + Mazda is well known of course).

I chose the analogy carefully.

[andy81]

F# isn't in the running for third either.

Maybe top ten behind MSSQL, Powershell, Excel Formulae, DAX etc.

[sterlind]

hey, there are dozens of us F# users! dozens!

I do love F#, but its compiler is a rusty set of monkey bars. It's somehow single pass, meaning the type checker will struggle if you don't reorder certain expressions - but also dog slow, especially for `inline` definitions (which work more like templates or hygienic macros than .net generics, and are far more powerful.) File order matters, bafflingly! Newer .net features like spans and ref structs are missing with no clear path to implementation. Doing moderately clever things can cause the compiler to throw weird, opaque, internal errors. F# is built around immutability but there's no integration with the modern .net immutable collections.

It's clearly languishing and being kept alive by a skeleton crew, which is sad, because it deserves better, but I've used research prototypes less clunky than what ought to be a flagship.

[jay_kyburz]

It's a bad look for both C# and TypeScript. Anybody starting a new code base now would be looking for ways to avoid both and jump right to Go.

[sethaurus]

I'm struggling to understand how this is a bad look for Typescript. Do you mean that the specific choice of Go reflects poorly on Typescript, or just the decision to rewrite the compiler in a different non-TS language?

If it's the latter, I think the pitch of TS remains the same — it's a better way of writing JS, not the best language for all contexts.

[bdangubic]

if I had to use Go I’d change my career and go do some gardening :)

[moogly]

If they're writing (actually porting) a _compiler_, perhaps.

[osigurdson]

Go doesn't run in the browser however (except WASM but that is different).

[Hello71]

> Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those?

as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.

[whattidywhat]

I'm not saying this to start a language war but. Look at the cognitive complexity and tooling complexity involved in a c# project. Seriously, every speed bump you hit in your ide think about how many pieces of knowledge you assemble to solve it. Similarly think about the overhead in designing both the software and tests. Think about cross platform builds and the tooling required to stand up ops infrastructure. Measure the compilation time. Think about the impedance mismatch between ts and c#.

Compare that to go. It's not even close. I see comments bickering about the size of executable files... Almost no major product cares about that within order of magnitude.

Go is a wild choice to write a compiler in. Literally in my top 10 things I never want to do. Everything else about it drove them to do it.

[cryptonector]

GP's answer is a great answer to why Go instead of Rust, which u/no_wizard asked about. And the answer to that boils down to the need to traverse data structures in ways which Rust makes difficult, and the simplicity of a GC.

[almosthere]

.NET executables requires a runtime environment to be installed.

Go executables do not.

TSC is installed in too many places for that burden to be placed all of a sudden. It is the same reason why Java has had a complicated acceptance history too. It's fine in the places that it is pre-installed, but no where else.

Node/React/Typescript developers do not want to install .net all of a sudden. If you react that poorly, pretend they decided they decided to write it in Java and ask if you think Node/React/Typescript developers WANT to install Java.

[afavour]

FYI this hasn’t been the case with C# for a very long time now.

[vips7L]

.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.

[mytec]

Yes, but they may not always work. While generally true there are still some edge cases.

SQL Server connections are one example where I do get .exe with the .pdb in the publish directory but the .exe won't run correctly without the "Microsoft.Data.SqlClient.SNI.dll" file.

Another example are any libraries that have "RequiresDynamicCodeAttribute" requirements.

[yakz]

Maybe some other runtimes do this or it has been changed, but in the past self-contained singe-file .NET deployment just meant that it rolled all the files up during publishing and when you run it, it extracted them to a folder. Not really like a single statically linked executable.

[webprofusion]

You can indeed produce a compiled native executable with minimal bloat: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

[vips7L]

It hasn't done that in years.

[estebarb]

C# AOT filesizes are huge compared to Go.

[MStrehovsky]

Do you have data backing that up? Per https://github.com/MichalStrehovsky/sizegame:

C#: 945 kB Go: 2174 kB

Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.

[vessenes]

It’s a political anti-benefit in most of the open-source world. And C# is not considered a high quality runtime once you leave Windows.

[electroly]

This is Anders Hejlsberg, the creator of C#, working on a politically important project at Microsoft. That's what I mean by political benefit. The larger open source world doesn't matter for this decision which is why this is a simple announcement of an internal Microsoft decision rather than an invitation for comments ahead of time.

[vessenes]

I’m sure Microsoft’s strategy department would disagree with you. As a c# devotee - I get that you’re upset. And you may want to update your priors on where c# sits in Microsoft’s current world. But I think it’s a mistake to imagine this isn’t a well reasoned decision.

[electroly]

They can disagree if they want but as a career-long Microsoft developer they can't fool me that easily. I'm not even complaining, I'm just stating a fact that high-level steering decisions like this are made in Teams meetings between Microsoft employees, not in open discussion with the community. It's the same in .NET, which is a very open source project whose highest-level decisions are, nonetheless, made in Teams meetings between Microsoft employees and then announced to the public. I'm fine with this but let's not kid ourselves about it.

That said, I must have misstated my opinion if it seems like I didn't think they have a good reason. This is Anders Hejlsberg. The guy is a genius; he definitely has a good reason. They just didn't say what it is in this blog post (but did elsewhere in a podcast video linked in the HN thread).

[IshKebab]

> The larger open source world doesn't matter for this decision

It obviously does because the larger open source world are huge users of Typescript. This isn't some business-only Excel / PowerBI type product.

To put it another way, I think a lot of people would get quite pissed if tsc was going to be rewritten in C# because of the obvious headaches that's going to cause to users. Go is pretty much the perfect option from a user's point of view - it generates self-contained statically linked binaries.

[dlahoda]

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

[thayne]

It would have a substantial risk for the typescript project. Many people would see it as an unwanted and hostile push of a Microsoft technology on the typescript community.

And there would be logistical problems. With go, you just need to distribute the executable, but with c#, you also need a .net runtime, and on any platform that isn't Windows that almost certainly isn't already installed. And even if it is, you have to worry if the runtime is sufficiently up to date.

If they used c# there is a chance the community might fork typescript, or switch to something else, and that might not be a gamble MS would want to take just to get more exposure for c#.

[dlahoda]

csharp single file for a while https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

[smooth_criminal]

Okay, not to be petty here but, it's important to note that on his GitHub he did not star the dotnet repository but has starred multiple go repos and multiple other c++ and TS repos

[fabian2k]

Modern C# (.NET Core and newer) works perfectly fine on Linux.

[naasking]

> And C# is not considered a high quality runtime once you leave Windows.

By who?

[cyral]

Usually by someone who hasn't used C# since 2015 (when this opinion was fairly valid)

[WD-42]

It’s always the same response, c# was crappy but it’s not crappy anymore. Well guess what, Go has been not crappy for a lot longer than C# has been not crappy, maybe that’s part of the reason people like it more.

[999900000999]

I personally find Go miles easier than Rust.

Is this the ultimate reason,Go is fast enough without being overally difficult. I'm humbly open to being wrong.

While I'm here, any reason Microsoft isn't sponsoring a solid open source game engine.

Even a bit of support for Godot's C#( help them get it working on web), would be great.

Even better would be a full C# engine with support for web assembly.

https://github.com/godotengine/godot/issues/70796

[cardanome]

> Even a bit of support for Godot's C#( help them get it working on web), would be great.

They did that. https://godotengine.org/article/introducing-csharp-godot/

At least some initial grant to get it started.

Getting C# working on web would be an amazing. It is already on the roadmap but some sponsorship would help tremendously for sure.

[999900000999]

Ok. Credit where credit is due, but considering the sheer value of having the next general of programmers comfortable with .net, Microsoft *should* chip in more.

[9rx]

Hasn't Microsoft largely hitched their horse to Go these days, though (not just this project)? They even maintain their own Go compiler: https://github.com/microsoft/go

It is a huge company. They can do more than one thing. C#/.NET certainly isn't dead, but I'm not sure they really care if you do use it like they once did. It's there if you find it useful. If not, that's cool too.

[999900000999]

We're talking about a nominal amount of funding to effectively train 10s of thousands of developers.

I think Microsoft can find the money if they wanted to.

[Ray20]

It seems Microsoft is not betting on C# and I think the main reason for this is that C# isn't futureproof because of it's ugliness.

It is a powerful and robust language with great standard library, but you just cant be comfortable with it. All those boilerplate, all those sealed override virtual public protected or whatnot before each statement, those curly braces everywhere. You are always inside classes that are inside namespace, and even then you need to go deeper and have curly braces with properties and arrows in random places. Delegates and Events are ugly and unintuitive, two set of syntax for linq (and honestly for almost any somewhat new feature of the language), ref in out, you name it. It is hard to push something so inelegant.

[WorldMaker]

A lot of the last few C# compiler versions have been about "boiler-plate" reduction. Namespaces don't need curly braces any more and are just a single line at the top. You can write some top-level code inside a namespace without it needing to be in a class. More of the properties and method bodies that are simple can also be written entirely with arrows without curly braces.

Delegates and Events were a mistake, but that's a low-level .NET mistake that a lot of modern code can easily ignore, with Action<> and Func<> now reliably almost everywhere and WinForms easy to write off as "dead". (You can especially eliminate the need for the ugliness of Delegates and Events with System.Reactive.Linq.)

Records and Primary Constructors remove a ton of the boiler-plate of writing basic "DTOs" and/or dependency injection.

C# is pretty elegant, and a nicely evolving language. Microsoft isn't any longer trying to bet on C# as a "systems programming language" because too many people see JIT support and VMs as "not low level enough" (including apparently also Anders Hejlsberg), but that doesn't mean C# isn't "future proof".

[reactordev]

History has shown Microsoft abandoning any gamedev toolkit or sdk they “support”. Managed DirectX, XNA, etc.

Personally, I would like them to never touch the game dev side of the market.

[WorldMaker]

> Getting C# working on web would be an amazing.

People have been using Blazor WASM in Production for more than a year now. It's been stable since .NET 8.

[tonyhart7]

"any reason Microsoft isn't sponsoring a solid open source game engine"

I can see they do this in the future tbh, given how large their xbox gaming ecosystem, this path is very make sense since they can cut cost while giving option to their studios or indie developers

[999900000999]

While I'm dreaming of things that will never ever happen, I would absolutely love for them to buy the game engine side of Unity and open source it.

[runevault]

Unless I missed Unity sorting a ton of stuff out, I assume they're going to have to sell themselves off for parts at some point after the runtime fee fiasco that was supposed to make them profitable lead to developers being angry or outright leaving the ecosystem. My assumption if that happens unless the DOJ gets involved for some reason is MS buys it for this reason.

[999900000999]

Unity isn't really worth 9 billion imo.

I would like MS to buy them out and FOSS the engine. Maybe if they split the ad business off into its own thing.

Unity feels like a bizarre almost abusing business relationship. They can change the terms of service at will.

The licensing is confusing. Billy is a freelancer. He makes a small game for his friend company. His friends company raises a funding round.

Depending on how much money is raised, Unity is going to call Billy up and extort him to upgrade to a higher license tier.

I don't particularly like Godot, but every few months I try and learn it again.

The game engine landscape is like picking the least worst option.

All that to be fair, Unity provided a high quality game engine for effectively nothing for over a decade to the vast majority of its users. It's time to pay the piper.

[pjmlp]

They do, Unreal and Unity tooling for Visual Studio, it is even part of the installer.

Also some of the low level improvements on C# have been done with collaboration with Unity team's requirements, regarding their Burst use cases.

[sime2009]

> we're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

Cool. Can you tell us a bit more about the technical process of porting the TS code over to Go? Are you using any kind of automation or translation?

Personally, I've found Copilot to be surprisingly effective at translating Python code over to structurally similar Go code.

[skybrian]

It seems like, without mentioning any language by name, this answers "why not Rust" better than "why not C#."

I don't think Go is a bad choice, though!

[fabian2k]

I find the discussion about the choice quite interesting, and many points are very convincing (like the GC one). But I am a bit confused about the comparison between Go and C#. Both should meet most of the criteria like GC, control over memory layout/allocation and good support for concurrency. I'm curious what the weaknesses of C# for this particular use case were that lead to the decision for Go.

[zeroc8]

Anders is answering this in the Video. Go is the lower level and also closer to Javascript's programming style. They didn't want to fully object oriented for this project.

[typ]

C# is fine. But last I checked, the AOT compilation generates a bunch of .dll files, which are not suitable for a CLI program like Go's zero dependencies binary.

[fabian2k]

C# can create single-binary executables, even without native AOT.

[cardanome]

They are still going to significant bigger than the equivalent golang binary because of the huge .NET runtime, no?

[zigzag312]

https://github.com/MichalStrehovsky/sizegame

C#: 945 kB

Go: 2174 kB

[fabian2k]

Depends on how well trimming works. It's probably still larger than Go even with trimming, but Go also has a runtime and won't produce tiny binaries.

[pjmlp]

You can choose how the linking process is done, just like you can chose to have a a Go binary with dependencies.

[SkiFire13]

C# has an option to publish to a single self-contained file.

[osigurdson]

It would be big enough that people would find it annoying (unless using AOT which is hard).

[acomagu]

Personally, I want to know why Go was chosen instead of Zig. I think Zig is really more WASM-friendly than Go, and it's much more similar to JavaScript than Rust is.

Memory management? Or a stricter type system?

[throw16180339]

Zig isn't memory safe, has regular breaking changes, and doesn't have a garbage collector.

[commandersaki]

First reason in my mind is there isn't an abundance of Zig programmers internally in Microsoft, in the job market, and in open source. It's probably a fine choice if you're using it for your passion project e.g. Hashimoto.

[smarx007]

For being production-ready?

[pjmlp]

Zig still isn't production ready and isn't memory safe as Go, most likely.

[breadwinner]

So when can we expect Go support in Visual Studio? I am sold by Anders' explanation that Go is the lowest language you can use that has garbage collection!

[pjmlp]

It is already there, kind of, the original Visual Studio Code plugin was actually done by Microsoft, and at a later point given to Google for further development.

"VS Code Go Language Extension Goes from Microsoft to Google"

https://visualstudiomagazine.com/articles/2020/06/10/go-goes...

[pebal]

You can also have GC in C++ and generate even faster code.

[mavelikara]

Thanks for the thoughtful response!