[Cthulhu_]

I'm not involved in the decisions, but don't C# applications have a higher startup time and memory usage? These are important considerations for a compiler like this that needs to start up and run fast in e.g. new CI/CD boxes.

For a daemon like an LSP I reckon C# would've worked.

[rob74]

Yes, in fact that's one of the main reasons given in the two linked interviews: Go can generate "real" native executables for all the platforms they want to support. One of the other reasons is (paraphrasing) that it's easier to port the existing mostly functional JS code to Go than to C#, which has a much more OOP style.

[jabart]

The C# compiler is written in C# and distributed to multiple platforms. Along with the JIT that runs on all kinds of devices.

Graph for the differences in Runtime, Runtime Trimmed, and AOT .NET.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/n...

[neonsunset]

Not when compiled by NativeAOT. It also produces smaller binaries than Go and has better per-dependency scalability (due to metadata compression, pointer-rich section dehydration and stronger reachability analysis). This also means you can use F# too for this instead, which is excellent for langdev (provided you don't use printf "%A" which is incompatible which is a small sacrifice).

[kokada]

What is the cross compilation support for NativeAOT though? This is one of the things that Go shines (as long as you don't use CGO, that seems perfectly plausible in this project), and while I don't think it would be a deal breaker it probably makes things a lot easier.

[neonsunset]

What is the state of WASM support in Go though? :)

I doubt the ability to cross-compile TSC would have been a major factor. These artifacts are always produced on dedicated platforms via separate build stages before publishing and sign-off. Indeed, Go is better at native cross-compilation where-as .NET NativeAOT can do only do cross-arch and limited cross-OS by tapping into Zig toolchain.

[9rx]

> What is the state of WASM support in Go though? :)

The gc compiler considers it a first-class build target.

Like C#, the binary tends to be on the larger side[1], which makes it less than ideal for driving a marketing website, but that's not really a problem here. Installation of tools before use is already the norm.

[1] The tinygo compiler can produce very small WASM binaries, comparable to C, albeit with some caveats (surprisingly, the extra data gc produces isn't just noise).

[kokada]

> What is the state of WASM support in Go though? :)

I am sure it is good enough that the team decided to choose Go either way OR it is not important for this project.

> I doubt the ability to cross-compile TSC would have been a major factor.

I never said it was a major factor (I even said "I don't think it would be a deal breaker"), but it is a factor nonetheless. It definitely helps a lot during cross-platform debugging since you don't need to setup a whole toolchain just to test a bug in another platform, instead you can simple build a binary on your development machine and send it to the other machine.

But the only reason I asked this is because I was curious really, no need to be so defensive.

[pjmlp]

Native AOT exists, and C# has many C++ like capabilities, so not at all.

[reactordev]

It exists but isn’t the same as a natively compiled binary. A lot gets packed into an AOT binary for it to work. Longer startup times, more memory, etc.

[pjmlp]

Just like Go, there is no magic here.

Where do you think Go gets those chubby static linked executables from?

That people have to apply UPX on top.

[reactordev]

Go’s static binaries are orders of magnitude smaller than .Net’s static binaries. However, you are right, all binaries have some bloat in order to make them executable.

[metaltyphoon]

This is flat out incorrect if you are doing AOT in C#

[reactordev]

How? What I said was fact. All executables have some bloat that makes them executables. Golang’s being the smaller. Whether it’s shared lib pointer or static…