News for hackers. Stuff that matters.

A comment on A 10x Faster TypeScript. Parent comment

Re:A 10x Faster TypeScript by Cthulhu_ on Tuesday March 11, 2025 @11:44AM (#43333620)
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.

[ Parent | on HN ]
Re:A 10x Faster TypeScript by rob74 on Tuesday March 11, 2025 @11:50AM (#43333678)
Yes, in fact that's one of the main reasons given in the two linked interviews: Go can generated "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.
[ Parent | on HN ]
Re:A 10x Faster TypeScript by jabart on Tuesday March 11, 2025 @12:01PM (#43333793)
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...

[ Parent | on HN ]
Re:A 10x Faster TypeScript by pjmlp on Tuesday March 11, 2025 @11:47AM (#43333644)
Native AOT exists, and C# has many C++ like capabilities, so not at all.
[ Parent | on HN ]
Re:A 10x Faster TypeScript by reactordev on Tuesday March 11, 2025 @12:04PM (#43333842)
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.
[ Parent | on HN ]
Re:A 10x Faster TypeScript by pjmlp on Tuesday March 11, 2025 @12:38PM (#43334260)
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.

[ Parent | on HN ]
Re:A 10x Faster TypeScript by reactordev on Tuesday March 11, 2025 @05:33PM (#43337249)
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.
[ Parent | on HN ]
Re:A 10x Faster TypeScript by metaltyphoon on Tuesday March 11, 2025 @08:16PM (#43338587)
This is flat out incorrect if you are doing AOT in C#
[ Parent | on HN ]
Re:A 10x Faster TypeScript by reactordev on Wednesday March 12, 2025 @09:17AM (#43342927)
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…
[ Parent | on HN ]
Re:A 10x Faster TypeScript by neonsunset on Tuesday March 11, 2025 @11:47AM (#43333640)
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).
[ Parent | on HN ]
Re:A 10x Faster TypeScript by kokada on Tuesday March 11, 2025 @03:46PM (#43336323)
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.
[ Parent | on HN ]
Re:A 10x Faster TypeScript by neonsunset on Tuesday March 11, 2025 @04:24PM (#43336627)
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.

[ Parent | on HN ]
Re:A 10x Faster TypeScript by kokada on Wednesday March 12, 2025 @05:49AM (#43341399)
> 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.

[ Parent | on HN ]
Re:A 10x Faster TypeScript by 9rx on Wednesday March 12, 2025 @03:22PM (#43346751)
> 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).

[ Parent | on HN ]