Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

901–910 of 943 posts

Re: A 10x Faster TypeScript

#901

Earlier quoted context omitted.

I think Deno and Bun are the two successful attempts at a faster tsc :)

Those are runtimes primarily, not compilers/type checkers. Likewise, TSC is not a TS runtime.

Well, of course. But TSC output (transpiled JS source code) is then run by a JS runtime like Node that has a VM like V8 that makes an internal representation for the JS code. Using Bun or Deno allows you to go to a VM IR from the TypeScript directly without a need for TSC transpilation into JS first.

But as @keturakis pointed out (thanks!), Deno/Bun still rely on TSC, which I was not aware of.

Re: A 10x Faster TypeScript

#902
post #601

Earlier quoted context omitted.

Go exposes raw pointers to the programmer, so from your description i think those semantics are too rudimentary to implement Go's semantics, there would need to be a WasmGC 2.0 to make this work. It sounds like it would be a great fit for e.g. Lua though.

I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.

It also has an address-of operator, you can take the address of the middle of a large array.

I suppose that would be possible with fat-pointers that are reference+offset.

Re: A 10x Faster TypeScript

#903

Earlier quoted context omitted.

> There are more elements to a compiler than determinism. Yes, but determinism is the factor that allows me to treat compilers as a black box without verifying their output. LLMs do not share this specific property, which is why I have to verify their output, and easily verifiable software is what I call "maintainable".

An interesting question you might want to ask yourself, related to this idea: what would you do if your compiler wasn't deterministic? Would you go back to writing assembly? Would you diligently work to make the compiler "more" deterministic. Would you engineer your systems around potential failures? How do industries like the medical or aviation deal with imperfect humans? Are there lessons we can learn from those d…

> How do industries like the medical or aviation deal with imperfect humans?

We have a system in science for verifying shoddy human output, it's called peer review. And it's easier for your peers to review your code when it's maintainable. We're back in the loop.

Re: A 10x Faster TypeScript

#904

Earlier quoted context omitted.

An interesting question you might want to ask yourself, related to this idea: what would you do if your compiler wasn't deterministic? Would you go back to writing assembly? Would you diligently work to make the compiler "more" deterministic. Would you engineer your systems around potential failures? How do industries like the medical or aviation deal with imperfect humans? Are there lessons we can learn from those d…

> How do industries like the medical or aviation deal with imperfect humans? We have a system in science for verifying shoddy human output, it's called peer review. And it's easier for your peers to review your code when it's maintainable. We're back in the loop.

That is one system. Are there zero others?

Funny thing about this thread and black and white thinking. I feel a different kind of loop.

Re: A 10x Faster TypeScript

#905
post #740
post #470

Earlier quoted context omitted.

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

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.

> 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.

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.

Re: A 10x Faster TypeScript

#906
post #247

Earlier quoted context omitted.

More like compiler assisted management, with compiler errors when the developer doesn't follow the teacher.

The compiler ensures you are writing memory safe code. Otherwise it rejects that code and helps you see the mistake you made. Why people are so upset when the compiler prevents them from building and shipping unusable code will always baffle me.

Theres a huge gap between inefficient and unusable. There’s a lot of usable code out there that leaks memory. I’d argue compilers are hardly pressed by memory usage given the transient nature of their execution.

Re: A 10x Faster TypeScript

#907

Earlier quoted context omitted.

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 stuf…

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…

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

Re: A 10x Faster TypeScript

#908

Earlier quoted context omitted.

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

https://github.com/MichalStrehovsky/sizegame C#: 945 kB Go: 2174 kB

Yeah and I doubt many people care if the TS compiler is 200MB anyway LOL. It's 2025.

Re: A 10x Faster TypeScript

#909

Earlier quoted context omitted.

Is this a fair comparison, won't doing anything more significant than `print` in C# require a .NET framework to be installed (200MB+)?

No. This is normal native compilation mode. As you reference more features from either the standard library or the dependencies, the size of the binary will grow (sometimes marginally, sometimes substantially if you are heavily using struct generics with virtual members), but on average it should be more scalable than Go’s compilation model. Even JIT-based single-file binaries, with trimming, take about ~13-40 MB dep…

[deleted]

Re: A 10x Faster TypeScript

#910
post #483

Earlier quoted context omitted.

F# isn't in the running for third either. Maybe top ten behind MSSQL, Powershell, Excel Formulae, DAX etc.

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 feature…

There's more than a dozen - I should know. I've seen quite a few large systems built in it. Most of the time however it isn't well advertised (finance, insurance, etc).

- 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.

Post reply on HN