Meanwhile .NET developers are still waiting for Microsoft to use their own "inventions" like Blazor, .NET MAUI, Aspire, etc. for anything meaningful. Bless them.
A 10x Faster TypeScript
371–380 of 943 posts
Re: A 10x Faster TypeScript
#372For previous attempts at a faster tsc, but in rust, see:
1. https://github.com/dudykr/stc - Abandoned (https://github.com/swc-project/swc/issues/571#issuecomment-1...)
2. https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.
Re: A 10x Faster TypeScript
#373Hi folks, Daniel Rosenwasser from the TypeScript team here. We're obviously very excited to announce this! RyanCavanaugh (our dev lead) and I are around to answer any quick questions you might have. You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.
[flagged]
> inexpressive type system
Simplicity is a feature, not a bug. Overly expressive languages become nightmares to work with and reason about (see: C++ templates)
Go's compilation times are also extremely fast compared to Rust, which is a non-negligible cost when iterating on large projects.
Re: A 10x Faster TypeScript
#374Earlier quoted context omitted.
I don't think c or rust are really 'closer to the metal' than golang (what they're using)
Considering Go is the only language with a garbage collector out of the three languages you mentioned, I'm not sure how you reach the conclusion they're all as close to the metal. C and Rust both have predictable memory behaviour, Go does not.
When I read the article it was very clear, due to the compiler's in-memory graphs, that they needed a GC.
(IE, as opposed to reference counting, where if you have cyclic loops, you need to manually go in and "break" the loop so memory gets reclaimed.)
Re: A 10x Faster TypeScript
#375People seem very hurt that the creator of C# didn't pick C# for this very public project from a multi-trillion-dollar corp. I find it very refreshing, they defined logical requirements for what they wanted to do and chose Golang because it ticked more boxes than C#. This doesn't mean that C# sucks or that every C# project should switch to Golang, but there seems to be a very vocal minority affected by this logical de…
[deleted]
Re: A 10x Faster TypeScript
#376yes, this will definitely vastly increase the Doom fps, haha (I’m the guy that did that project). But I think there’s a lot more to it than that. tl;dr — Rust would be great for a rewrite, but Go makes way more sense for a port. After the dust settles, I hope people focus on the outcomes, not the language choice. I was very surprised to see that the TypeScript team didn’t choose Rust, not just because it seemed like…
> Go and Rust are both memory safe. Go doesn't seem to be memory safe, see https://www.reddit.com/r/rust/comments/wbejky/comment/ii7ak8... and https://go.dev/play/p/3PBAfWkSue3
That is not a violation of memory safety, that's a violation of concurrency safety, which Go doesn't promise (and of course, Rust does.)
Re: A 10x Faster TypeScript
#377Hi folks, Daniel Rosenwasser from the TypeScript team here. We're obviously very excited to announce this! RyanCavanaugh (our dev lead) and I are around to answer any quick questions you might have. You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.
[flagged]
[deleted]
Re: A 10x Faster TypeScript
#378Hi folks, Daniel Rosenwasser from the TypeScript team here. We're obviously very excited to announce this! RyanCavanaugh (our dev lead) and I are around to answer any quick questions you might have. You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.
Go is quite difficult to embed in other applications due to the runtime. What do you see as the future for use cases where the typescript compiler is embedded in other projects? (Eg. Deno, Jupyter kernels, etc.) There’s some talk of an inter process api, but vague hand waving here about technical details . What’s the vision ? In TS7 will you be able to embed the compiler? Or is that not supported?
Why embed it if you can run a process alongside yours and use efficient IPC? I suppose the compiler code should not be in some tight loop where an IPC boundary would be a noticeable slowdown. Compilation occurs relatively rarely, compared to running the compiled code, in things like Node / Deno / Bun / Jupyter. LSPs use this model with a pretty wasteful XML IPC, and they don't seem to feel slow.
Re: A 10x Faster TypeScript
#379Earlier quoted context omitted.
> Because of its truly primitive type system That is the main reason they gave for why they those chose Go. The parent asked "Why _not_ use Go?"
So they like having all the footguns?
It was stated from the angle of wanting to ship software sometime this century.
But there is probably some truth in what you say as well. Footguns are no doubt refreshing after being engrossed in Typescript (and C#) for decades. At some point you start to notice that your tests end up covering all the same cases as your advanced types, and you begin question why you are putting in so much work repeating yourself, which ultimately sees you want to look for better.
Which, I suppose, is why industry itself keeps ending up taking that to the extreme, cycling between static and dynamic typing over and over again.
Re: A 10x Faster TypeScript
#380Earlier quoted context omitted.
Reading the article, it looks like they are writing go, so will probably be distributing go binaries.
Maybe they'll also be distributed in WASM too, which is easier to be integrated with JavaScript codebases.
Would running WASM be any faster than running JS in V8?