Also don't forget that .NET is much less portable than Go, using .NET would mean they would have to give up on *BSD for example.

Why perpetuate a lie?freshports.org/lang/dotnet

But yes, your reply demonstrates a larger problem faced by .NET - it is so unreasonably hated that choosing it, whenever it is the better product, comes with unsubstantiated criticism.

It's not because there is a package that it's supported or production ready :

FreeBSD is officiallynot supported as per the official documentation:https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md

dotnet/runtime#14537
dotnet/runtime#71338
and more issues if you search in the same repository, it's slowly getting better but I don't think it will be approved as official for quite some time for now.

Try to search a little bit next time.

I'm not a .NET hater I do use it and like it when it makes sense to use it (so not for this current usecase)

If not C#, I would have expected Rust, since that's where the rest of the ecosystem is. So, another surprise there.

not really, Go is plenty popular. software development is not a monolith, so painting it that way is a weird take. one language (Rust) does not have to rule everything, nor does it. also you don't code in Rust or Go, so it seems off that you would even have a concern on this:

https://github.com/EisenbergEffect?tab=repositories

Is it possible to extendstatic typescript and maketsc bootstrap itself?

1. writetsc in "static typescript"
2. compiletsc to wasm (using external compiler)
3. usetsc wasm to compiletsc

Let's be honest. If the reasoning from@ahejlsberg is really focusing one-to-one mapping of the current base, Go would obviously not that close to the best candidate.

@FrankHB You're not familiar enough with either codebase to say that. The Go code follows a similar shape and structure to the original ts codebase, to the point that the Go implementation feels familiar to me despite not knowing Go at all.

Yes, it seems the overriding goal was to have as close to a "copy/paste and fix" port as possible (maybe even something AI could do with high accuracy), to get to market as fast as possible. Performance, interoperability, unification of Microsoft's web development story, or any bigger picture vision, no matter how good, were never going to beat out that one deciding factor. I don't think maintainability or memory management really came into the choice either. C# does very well in that space. It really just came down to one thing.

This can’t be a surprise to anyone. “Inferior” products win out all the time. The iPhone and React are two examples that easily come to mind

Using the TS compiler in-browser certainly isn't niche. Major industry tech is built assuming that capability.

TinyGo can provide significant speed boost in certain cases but can also be much slower when using the runtime (GC or threads)https://github.com/tinygo-org/tinybench

@EisenbergEffect not being niche doesn't change the fact that Go can target wasm or wasi as output formats though. It's possible they could have to deal with a larger wasm binary in Go if the standard compiler is used instead of TinyGo, but it might have much better performance than a tsc in-browser experience which is probably worth it for most use cases

in his announcement video Anders explains that yes they are using parallelism already.

Would you consider a talk show

Good luck building self-referential types in Rust, and any parallel stuff without making everything an Arc.

I like theouroboros crate to build self-referential structs

Good luck building self-referential types in Rust, and any parallel stuff without making everything an Arc.

That's literally exactly what Go does to share pointers. Rust just makes it explicit.

if Rust then have make hair dye to bright colors yes?

i'm sorry for being 🤓🤓🤓
but here you got the answer:https://youtu.be/10qowKUW82U?t=13m19s

i'm pro-rust btw

did you even read the intro post?

Why else would I be asking for something more in depth?

It's time to give up on .NET. Even Microsoft has chosen Go for critical components like dapr framework and the TS compiler. Microsoft itself has abandoned its own product first.

.net is never can be a good option for develop any technology that'll run outside windows because it's designed and created for fundamentally windows, and it seems will never change. So microsoft being clever to not use .net unless simple things.

Tell me you don't what you are talking about without tell me you don't know what you are talking about.

"Whole infrastructure" has been seeing platform-agnostic development where Linux hosts are treated as often a primary target for 9 years already. I can see where you are coming from but the statements you make have not been true for almost a decade.

I'm trying to say .net's fundamentals are broken for other platforms and such as we saw in other languages(like in php, random function names, etc), fundamentals of a language don't change so easily in fact they don't significantly change most of the time. Even Microsoft uses Java on some of their software, which is direct replacement of c# / .net . So what we should say about that?

This is always your personal bias, contrary to reality, and you haven't even tried it yourself

Frankly, Microsoft’s neglect of C# is obvious now. It’s not technical—they just don’t use it in their key products anymore. 🤔

It's time to give up on .NET. Even Microsoft has chosen Go for critical components like dapr framework and the TS compiler. Microsoft itself has abandoned its own product first.

Don't use Dapr my friend, it is sub par in every aspect. Use Microsoft Orleans. Also, pair it with kubernetes.
FYI... There is another critical compiler out there called Roslyn which was build with C#.

Well, Microsoft implemented F#. If most of Microsoft software engineers had enough programming language fundamentals and paradigms experience, they would've used F# for almost all of their CLR-based codebase, and they would've evolved F# further, fixing the small things it lacks compared to OCaml/etc.

Since the reality is that they quickly abandoned F#, this gives you an idea of the kind of people Microsoft is having on their team. It is really hard to believe they start in the right direction (F#) and they quickly abandon one of their best projects.

It'll be helpful to know from the author if .NET was considered and why C# was not preferred over Go for rewriting the TS compiler!

Things like this make me ashamed to even build my career on C# .NET.

Microsoft doesn't use C# on any of their high impact, serious projects like Azure, Bing, Dapr, VS Code, Typescript etc. They overwhelmingly use tools outside of .NET ecosystem like Java, React, Go etc.

If they don't use their own tools in their flagship products, I have no confidence in their tools and it just signals the developer community that instead of focusing on learning, using and growing .NET, they should just focus their energy on learning Java, React, Go etc.

This attitude of Microsoft really hurts .NET community because for someone new to software development if they see Microsoft treating their own tools like second class citizens, they'll have no drive to learn .NET. And when more people do this over time, C# community will be pretty much gone.

Thanks Microsoft. I'll do my best to move my org away from C#/ Azure to Java, Go/ AWS etc.

Reference:

1. https://www.microsoft.com/openjdk
2. https://cdn.graph.office.net/prod/media/java/how-microsoft-applies-java.pdf
3. https://devblogs.microsoft.com/typescript/typescript-native-port/

dotnet/csharplang isn't microsoft/csharplang 🥠

it's hurting C# developer. In Indonesia 95% Big Company use Go rather than C#. Because microsoft history over this. Than you wonder why Go Community have more people?

it's hurting C# developer. In Indonesia 95% Big Company use Go rather than C#. Because microsoft history over this. Than you wonder why Go Community have more people?

Bro just a TSC 😂, C# is still the best

It'll be helpful to know from the author if .NET was considered and why C# was not preferred over Go for rewriting the TS compiler!

C# devs are crybabies. Its not a rewrite, its a port and Go was the best choice for this specific task after trying C#, Rust etc. If you dont respect their decision that produces 10x improve because of your personal attachment to C# thats a you problem. They didnt say C# or Rust are bad langs, they are just not the best choice in this task.

The temptation is real. Currently, vibe coding my own compiler rn. IT IS POSSIBLE.

Embrace the cursed grammar of next...

fr vibe() int {  // main    ngl i := 1    ngl {        lowkey i vibe 100 {  // i <= 100            ngl output = ""                        lowkey i based 3 == 0 {  // i % 3 == 0                output = output bussin "fr fr"  // "fr fr" = "Fizz"            }                        lowkey i based 5 == 0 {  // i % 5 == 0                output = output bussin "bussin"  // "bussin" = "Buzz"            }                        lowkey output == "" {                output = vibeIt(i)  // Convert int to string            }                        vibe(output)  // Print the result            i = i bussin 1        } highkey {            l  // break        }    }        yeet 0}// Helper function to convert int to stringfr vibeIt(n int) string {    ngl result = ""    ngl temp = n        lowkey temp == 0 {        yeet "0"    }        ngl {        lowkey temp highkey 0 {  // temp > 0            ngl digit = temp based 10  // temp % 10            result = string(digit bussin '0') bussin result            temp = temp ratio 10  // temp / 10        } highkey {            l        }    }        yeet result}

If anyone wants to do it - here's how...https://ghuntley.com/z80/ +https://ghuntley.com/stdlib

lowkey im bussin vibing ngl no cap frfr yeeeeeeeeeeeeet

...If the concern with migrating from a JavaScript runtime was avoiding manually managing memory...

After listening to an interview with Anders Hejlsberg, my understanding is that the concern was keeping memory usage low, to make better use of CPU caches.

...the actual gains in using Go is only when there is a plausible use case for concurrency...

In the interview it was mentioned that they actually made use of the concurrency and got ~3x speedup (on top of the ~3x speedup by switching to a compiled language).

What is missing from OP's statement is that there is still no technical justification to use Go.

My subjective take on this is that it's better if teams have the freedom to choose the technology they want to work with, even if there is no perfect technical justification for it. 🙂

That is the problem, they made a technical justification when it was mostly preference of Go vs C#.

That is the problem, they made a technical justification when it was mostly preference of Go vs C#.

Go syntaxe is closer to TypeScript. I Believe that's enough justification

Go syntaxe is closer to TypeScript. I Believe that's enough justification

This is nonsense, just look at some examples of TS, Go, Rust and C# code. Go is a complete alien among them.

have been many close comparisons of I/O-bound tasks

Heavily type checking compilers are CPU bound. Why do you think Rust is so slow?

How and why Roslyn is "one of the best"?

it is all business ;KPI win.

If Microsoft doesn't use c# for their flagship products then why should engineers buy into a pretty closed ecosystem? It makes zero sense.

@sergiotapia i'll just link to the response#411 (reply in thread)

to reiterate, this was a port not a rewrite. they autogenerated code from their existing ts codebase and choose the best tool for this specific goal. 10x typescript does not hurt C# devs just as google using react doesn't hurt angular devs

no sense buy .NET it free

Boosting GH profile? Is that a thing? Only posted what I think, summarized. Never bet against Anders Hejlsberg and the whole Rust discussion is so boring, same happened when TS was announced, people claiming it looks like C# until they realized it doesn't after several years and now everyone is using it. C# is amazing, TS is amazing. And most of the people still doesn't understand that TS is powering all the IDEs, as without it we would still have notepad like tooling.

"The question isn't whether JavaScript is broken, but whether it's broken enough." ~ Anders Hejlsberg

If you know the history the initial bet was that JavaScript sucks and will go away which was the opposite of TypeScript approach.

TBH Can't believe there's a discussion why the TS team went with GO and not C#. Like if someone knows C# that's Anders Hejlsberg.
Choosing Go was driven by engineering requirements of the TypeScript team.

On a related note, Mark Russinovich once highlighted the industry's broader move away from languages that pose security and reliability risks, stating:

"Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated."

Different scenarios, but both underscore choosing languages strategically rather than based solely on familiarity or historical preference.

Well before 'vibe' coding the goat Russinovich should try to release one thing on Windows 11 that isn't complete trash, it has gotten so terrible that windows is becoming unusable constantly crashing, updates that destroy your pc, and gigabytes of memory wasted on Spyware bloat. But I am sure c++ is the problem that search can't find ms teams when you type 'teams' rust fixing that for sure. Programming language is really the reason your software is bad.

Similarity to TS Code Style

This is the strongest technical argument I've heard so far...

Because this is what was said in this discussion post above and video explaining this. People are leading with their emotions to a lang, are mad and clearly didnt read, here's one of the quotes "Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable."

Why do you care if in the end you will still be using TS ? The language under the hood is still garbage hiding fake type safety, you just have faster tooling now.

Yeah. Microsoft devs using Go for their internal tools.. on their mac's... hum.

Why it is important for you?
It is just a layer that generates js. It was written in JS and nobody complained why not C#

Perhaps rewrite C# compiler with Go

Tbh, there's always going to be more Go devs than C#/.NET devs.
Also, it's far easier to get started with go, and you can literally learn it in a week. Which means it has the upside of more contributions. It has a really fast compile time, supports WASM* & is popular.
Also, as far as I C# compiles to bytecode to be executed by dotnet common language runtime. This is the norm in that ecosystem.
AOT compilation is not that common. But Go always compiles, it perfected its compilation strategy over the years. Go results in a marginally smaller binary than C# AOT binary. So less bandwidth usage in npm which is owned by Microsoft. In the end,

• Go is popular
• Easier and opens more contributions
• More platform support
• Fast compilation & Smaller binary size
• Reduces bandwidth

C# denies all those points. I don't know how C# would've been a better choice

Theyou can learn the language in a week and thengo and work on one of the most complex projects on GitHub justification is not something I will understand for a while.

Thank you for the valuable clarifiction!

There may be a logical mistake in the response:

1. The second and third paragraph say Go was chosen due to development speed on the existing codebase.

2. The fourth paragraph says C# is good. And the runtime performance is good.

3. The fifth paragraph says some words, and then says"10x outcome!". We know that '10x' comes from the comparison of the Go compiler vs. the TypeScript compiler, not C#.

The response explains why C# wasn't chosen but still says '10x outcome!'

I'm not a native English speaker. Is this a conventional expression in the English-speaking world, a logical mistake, or something else?

I was wondering if you could do something like what the Edge team did with Chromium.

Chromium wasn't perfect, had lots of unneeded features and was also missing lots of features the Edge team required. So, what they did was they made lots of important contributions to the Chromium source code that ultimately benefited not only the Edge users but also any other browser on Windows that uses Chromium engine.

So why couldn't the same thing be applied here? What if you selected C#/.NET, formed a special internal team that would focus on bringing any missing features to the C#/.NET or improve it so that it would meet your requirements and also benefit all of the C#/.NET developers. You'd have even more control over the compiler than Go because it would be the repository that Microsoft controls.