Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

771–780 of 943 posts

Re: A 10x Faster TypeScript

#771

The news for me is Microsoft teams relying on Go. Strange choice to use Go for the compiler instead of C# or F#. Now if they will have problems, they will depend on the Go team at Google to fix them.

That's not how open source works / should work though. If the Go maintainers (that happen to work at Go) ignore problems that the MS teams flag up, they can fork the language.

The opposite would be true as well, teams at Google using Typescript or C# would rely on Microsoft to fix any issues.

Re: A 10x Faster TypeScript

#772
post #138

I'm really surprised by this visceral reaction to not choosing Rust. Go is a great language and I'd choose it for a majority of projects over Rust just based off of the simplicity of the language and the ability to spin up developers on it quickly. Microsoft is a big corporation. Why _not_ use Go?

> Why _not_ use Go? Because of its truly primitive type system, and because Microsoft already has a much better language — C#, which is both faster and can be more high level and more low-level at the same time, depending on your needs. I am a complete nobody to argue with the likes of Hejlsberg, but it feels like AOT performance problems could be solved if tsc needed it, and tsc adoption of C# would also help push C…

"depending on your needs" indeed - does the TSC compiler need a stronger type system?

Advanced type systems are guard rails to spot and avoid issues early on, but that role can be fulfilled by tests as well, and Typescript has a LOT of tests and use cases that will be flagged up. Does it need a strong type system for the internal tooling on top of that?

I'm not an authority on the matter and know nothing about the compiler's internals, but I'm confident in saying that the type system is good enough for this use case.

Re: A 10x Faster TypeScript

#773
post #461

Earlier quoted context omitted.

Is this visceral reaction in the room with us now? Edit: I have reached the bottom of the thread and still have not seen this visceral reaction mentioned by the OP.

https://github.com/microsoft/typescript-go/discussions/411 There's more reactions here. I think devs have lost the plot, tbh.

I closed that thread, the maturity level in there is... highly variable. There's a lot of kneejerk statements in there.

Meanwhile, this decision was made or led by one of the few people that developed multiple popular programming languages. I trust his opinion / decision more than internet commenters, including my own.

Re: A 10x Faster TypeScript

#774

Earlier quoted context omitted.

I am not sure if we see the same thread. There is one reaction from "Rust" dev (who seems have a very new account on github) on why not rust. Most of the others seem to be from C# side. The pattern also seems to be the same on reddit thread. There is one post about why not rust, equally (or more depending how you weigh) is how other people react to this news. What is weird is how much people talk about how other peop…

There's at least 3 top-level threads criticizing the decision not to rewrite in Rust. Including a RIR banner ad posted in the replies. Holy Language Wars are a spectator sport as old as the internet itself. It's normal to comment on one side fighting another. What's weird is pretending not to see the fighting

I do like seeing there's threads (on here and in the github page) advocating for or asking about C#, it's healthy to bring up different languages.

But, advocates for language X need to make sure they read and understand the requirements and tradeoffs, which could probably have been communicated better.

Re: A 10x Faster TypeScript

#775

Meanwhile .NET developers are still waiting for Microsoft to use their own "inventions" like Blazor, .NET MAUI, Aspire, etc. for anything meaningful. Bless them.

"anything meaningful"? Does this mean that those technologies aren't used for anything meaningful, or that you're simply not aware of them?

(I'm simply not aware of them but that also means I won't make any statements about these)

Re: A 10x Faster TypeScript

#776
post #731

Just tried it on our codebase. Getting over a thousand errors, a good portion of which seem to be: ../../../tmp/typescript-go/built/local/lib.dom.d.ts:27982:6 - error TS2300: Duplicate identifier 'KeyType'. 27982 type KeyType = "private" | "public" | "secret"; ~~~~~~~ ../../../tmp/typescript-go/built/local/lib.webworker.d.ts:9370:6 - 'KeyType' was also declared here. 9370 type KeyType = "private" | "public" | "secret…

It's very early days (perhaps too early?); running into issues caused by what very well may be an automated conversion is to be expected, and not down to the language choice.

Why not find out what's going wrong and submit a bug report / merge request instead of immediately dismissing a choice made by one of the leading authorities in programming languages in the world?

Re: A 10x Faster TypeScript

#777
post #499

Earlier quoted context omitted.

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.

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.

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

Re: A 10x Faster TypeScript

#778

That's a pretty misleading clickbait title. TypeScript isn't getting 10x faster; the TypeScript compiler is getting 10x faster. I would argue it needs editing, as it violates the HN guideline: > use the original title, unless it is misleading or linkbait; don't editorialize.

Yeah, it's a bit linkbaity as it implies that the runtime is 10x faster; just adding the word 'compiler' or 'type checker' to the title would fix it.

Re: A 10x Faster TypeScript

#779
post #421

I'd like to see if it makes a difference to the version of DOOM that runs in the TypeScript type system. https://news.ycombinator.com/item?id=43184291 https://www.youtube.com/watch?v=0mCsluv5FXA

hi! author of the Doom thing, here. while I won't be the one to try, my answer is "absolutely yes, it will make a massive difference". Sub-1-day Doom-first-frame is probably a possibility now, if not much more because actually the thing that was the largest bottleneck for Doom-in-TypeScript-types was serializing the type to a string, which may well be considerably more than 10x faster. Hopefully someone will try some…

> Sub-1-day Doom-first-frame

Love it :D

Re: A 10x Faster TypeScript

#780
post #76

Earlier quoted context omitted.

TL:DR; - Native executable support on all major platforms - He doesn't seen to believe that AOT compiled C# can give the best possible performance on all major platforms - Good control of the layout of data structures - Had to have garbage collection - Great concurrency support - Simple, easy to approach, and great tooling

So wild that most of these points were something C# was supposed to be good at, and they all boil down to "its just not as good in C# as in Go"

I'm happy to see it to be honest; at this point C# is 25 years old, and since then there's been a lot of innovation and development in programming languages and ecosystems (as well as 10x more software developers, at least - I am guessing at this number). Current-day programming languages, including Go and Typescript, will have had a lot of learnings from C#, including in things like generics and the like.
Post reply on HN