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.
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.
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.
I think Microsoft can find the money if they wanted to.
Personally, I would like them to never touch the game dev side of the market.
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.
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".
People have been using Blazor WASM in Production for more than a year now. It's been stable since .NET 8.
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
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.
Also some of the low level improvements on C# have been done with collaboration with Unity team's requirements, regarding their Burst use cases.
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???
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."
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.
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.
And AFAIK Symmetry Investments is that dogfood startup.
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.
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.
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.
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).
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.
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#.
By who?
Nobody said anything about who likes what more, nor does that even matter in the context of the original claim that .NET doesn't have a good runtime outside of Windows.
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.
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?
Maybe top ten behind MSSQL, Powershell, Excel Formulae, DAX etc.
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.
Huh? They're already implemented! It took years and they've still got some rough edges, yes, but they've been implemented for a few years now.
Agreed with the rest, though. As much as I love working with F#, I've jumped ship.
- I don't think the compiler is actually that bad, and yes - inline definitions I think once you are going on the "templating route" are going to be slower. Spans and ref structs are there - I think the design of them is more intuitive actually - the C# "ref struct" at first glance sounds like an oxymoron to me.
- modern .net immutable collections - in testing these are significantly slower than some of the F# options especially when you go away from the standard lib and use some of the other collection libraries. The algorithms within the C# immutable libs were not as optimal for some common collection types. They didn't feel modern last time I used them and I was forced to switch to the F# ones and/or others in the F# ecosystem to get the performance I needed. Immutable code felt MUCH more idiomatic with F#.
- "Doing moderately clever things can cause the compiler to throw weird, opaque, internal errors" - happened with init fields for me; can't recall another time.
Don't mind the file order bit - I thought OCAml and a few other languages also do this. Apps still scale OK, and when I was coding in it got me out of a few spaghetti code issues as the code scaled up to about the 500,000+ LOC mark.
However I do agree with you on it being kept alive by skeleton crew - I think the creators and tooling staff have moved on to the next big thing (AI and specifically Github Copilot). Which the way things are moving will raise some interesting questions about all coding languages in general potentially.
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.
If the TS team is getting a 10x improvement moving from TS to Go, you might imagine you could save about 10x on your server cpu. Or that your backend would be 10x more responsive.
If you have dedicated team for front and back anyhow, is a 10x slow down really worth a shared codebase?
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-...
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>
> "An indirect quote lets you capture or summarize what someone said or wrote without using their exact words. It helps to convey the tone or meaning of your source without quoting them directly." - https://www.grammarly.com/blog/punctuation-capitalization/qu...
I'm distilling and exaggerating multiple the comments to convey the tone and meaning of the bit I want to focus on. Asking "why not C#?" has the implicit framing "it should be C# by default and you have to justify why not" and calling out that bias to show it to be unreasonable is the intent.
Nope. None of those are even close to Ford + Chevy. (Ford + Mazda is well known of course).
I chose the analogy carefully.
It’s probably most common when an automaker introduces a new make and wants to save time and capital on developing and getting into production a new engine.
The Toyota matrix and Pontiac vibe used a lot of the same parts shared an engine and drivetrains if I'm not mistaken.
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.
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.
C#: 945 kB Go: 2174 kB
Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.
But in either case binary sizes are smaller and more scalable than what Go produces. The assumption that Go is good at compact binaries just does not replicate in reality. Obviously it’s nice to be able not touch it at all and opting into Rust for distributing native SDKs. Go is completely unfit for this as it has even more invasive VM interaction when you use it as dynamically linked library. NativeAOT is “just ok” at this and Go is “way more underwhelming than you think”.
I think if you're in domain of using SIMD, besides base RAM usage of 2-5MB you should not see drastic difference unless you have a lot of allocation traffic. But I guess Rust solved most of this, just wanted to note that specific memory and deployment requirements are usually solvable by changing build and GC settings.
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.
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.
then when you find the correct version but you then have to install both the x86 and x64 version because the first one you installed doesn't work
yeh, great ecosystem
at least a Go binary runs 99.99999% of the time when you start it.
I don't think Go is a bad choice, though!
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.
Memory management? Or a stricter type system?
"VS Code Go Language Extension Goes from Microsoft to Google"
https://visualstudiomagazine.com/articles/2020/06/10/go-goes...
____
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.