Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

811–820 of 943 posts

Re: A 10x Faster TypeScript

#811

Post by commandersaki »

acomagu wrote: post #545
DanRosenwasser wrote: post #59

Earlier quoted context omitted.

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I'll post the response below. https://github.com/microsoft/typescript-go/discussions/411 . ____ Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a nativ…

Personally, I want to know why Go was chosen instead of Zig. I think Zig is really more WASM-friendly than Go, and it's much more similar to JavaScript than Rust is. Memory management? Or a stricter type system?

First reason in my mind is there isn't an abundance of Zig programmers internally in Microsoft, in the job market, and in open source. It's probably a fine choice if you're using it for your passion project e.g. Hashimoto.

Re: A 10x Faster TypeScript

#812

Post by neonsunset »

osigurdson wrote: post #810
neonsunset wrote: post #782

Earlier quoted context omitted.

A “step out” is a single flag passed to “dotnet publish” or set in the project manifest.

That, and then deal with all the gotchas.

There are none in new projects. There are few in existing ones. I guess it is difficult to have a conversation with someone who is committed to looking for the aforementioned "gotchas".

Re: A 10x Faster TypeScript

#813

Post by commandersaki »

neonsunset wrote: post #781
Cthulhu_ wrote: post #780

Earlier quoted context omitted.

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.

Go is a step back in key areas: generics, nullability, functional constructs, concurrency. The praise of the latter in particular is egregious. Surely we can do better than having to wire the transfer of data and forking/joining the logical flows manually in 2025? The concept of virtual threading in Go, despite having nice implementation, did not progress much from what we’ve had 10 or even 20 years ago either. It ca…

Communicating Sequential Processes (CSP) makes it a lot easier to reason about concurrency. It may be old (1978) but is foundational.

Re: A 10x Faster TypeScript

#814

Post by commandersaki »

tialaramex wrote: post #191
dimitropoulos wrote: post #2

yes, 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…

A tiny thing that's not relevant to this particular piece of work but is worth having in background when thinking about Go is that while Go would like Python typically be described as "memory safe" unlike Java (or more remarkably, Rust) it is very possible for naive programmers to cause undefined behaviour in this language without realising it. Specifically if you race any non-trivial Go object (say, a hash table, or…

I'm confused what you ascribe to as undefined behaviour. What does that mean in the Go context? There is no mention of what UB is in Go at https://go.dev/ref/spec .

Re: A 10x Faster TypeScript

#815

Post by commandersaki »

whattidywhat wrote: post #809
commandersaki wrote: post #808

Earlier quoted context omitted.

The reason they didn't do Rust is because it was faster and more reliable to port the compiler and Go was a strong match particularly because of struct layout, types, concurrency, etc. but most importantly because it was native code with automatic garbage collection which Rust simply doesn't have. There's a video of Anders talking specifically about this.

The automatic gc doesn't seem like an actual deal breaker though. They probably just didn't want to redesign a bunch of data types that assumed one existed. I'm not arguing saying they made a bad call. I think what they did was smart with the options in front of them and whatever budget they have. The world isn't good for idealism, but it ideally could have been written in rust in my opinion.

> it ideally could have been written in rust in my opinion

What exactly would that buy and would the outcome matter much?

In my opinion: pragmatism > idealism.

Re: A 10x Faster TypeScript

#816

Post by ragnese »

wiseowise wrote: post #588
ragnese wrote: post #291

Earlier quoted context omitted.

Can you imagine the progress we could've made by now if people just tried to use the right tool for the job instead of trying to make the wrong tool good enough? All the time spent trying to optimize JITs for JavaScript engines, or alternative Python implementations (e.g., PyPy), and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications. Ugh...

> and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications This is how we got Graal, why would you call it "fruitless effort"?

Okay, so "fruitless" wasn't the right word. If you try to build an actual house out of LEGO bricks, you can eventually succeed and therefore the endeavor was technically "fruitful." I think I should've described it as "wasteful" effort, or as an inefficient use of brilliant minds' time.

For my specific example of JVMs on lambdas, I wasn't really thinking about GraalVM. I was more thinking of all the hacky, fiddly, things that people were doing to "warm up" their JVM-based lambdas. Like some of the stuff described in this article I just randomly grabbed from a web search: https://medium.com/@marcos.duarte242/keeping-your-aws-lambda...

The reality is that JVM languages were just the wrong tool for the job of writing short-lived applications.

Even though I wasn't really thinking about GraalVM, it might not be shocking that I don't really like it either- for the same kind of reason(s). Java was designed as a fairly dynamic language: you have runtime reflection, dynamic class loading (hot swapping), and various other (admittedly niche) features. So, Java code destined for GraalVM has to be written differently than Java code destined for a standard JVM runtime, which is an inverted way of saying that the nominal goal of GraalVM is technically impossible (you can't, generally, write a native compiler for the Java programming language). So, again, we're taking a language that was designed and optimized for specific runtime properties and we're forcing that square peg into the round hole of AOT compilation. You want native performance? Use a native language!

It feels like someone trying to design a hammer to also be a really shitty screwdriver. Why not just use a hammer sometimes and a screwdriver other times?

Re: A 10x Faster TypeScript

#817

Post by ragnese »

nipah wrote: post #554
ragnese wrote: post #80

But, I was told that programming language choice doesn't matter and that I can write slow/bad code in any language... /s

Many people say this, but it is obviously bullshit. But most things people say all the time is bullshit, so I would not bother with it that much, it's not like people are saying "Programming languages don't matter, see here my affirmation is backed by a hundred statistics and data heavily reviewed and strong literature", it is more like "Programming languages don't matter, well at least I feel like it, the same way f…

No doubt! I just like to point out the bullshit when I can. :)

Re: A 10x Faster TypeScript

#818

Post by uticus »

jodrellblank wrote: post #615
uticus wrote: post #453

Earlier quoted context omitted.

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course). So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages. If Ford made a car and powered it with a Chevy e…

> " So it's not just that the lead architect of C# is involved in the TypeScript changes. " Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is: https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - " I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And…

> Like these...

Nope. None of those are even close to Ford + Chevy. (Ford + Mazda is well known of course).

I chose the analogy carefully.

Re: A 10x Faster TypeScript

#819

Post by commandersaki »

DeathArrow wrote: post #721

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.

I know a few teams in Azure Networking teams that use Go. I don't think it's uncommon.

Re: A 10x Faster TypeScript

#820

Post by pebal »

vips7L wrote: post #805
pebal wrote: post #762

Earlier quoted context omitted.

Where performance is paramount, developer convenience takes a backseat. Moreover, C++ has evolved significantly in recent years and is now quite enjoyable to use. We’re also discussing a tool in this thread whose performance is critical for developers. Over-simplifying code will ultimately lead to programmers using such solutions being replaced by AI, while the software itself will demand enormous computational power…

We’re talking about a tool whose performance profile with a managed language is perfectly acceptable as deemed by the choice to use Go. Let alone the fact that this thread you’ve been replying in has never been about achieving the utmost performance. You’re absolutely delusional if you think C++ is enjoyable compared to any managed language or if you think AI is capable of replacing anything. You’ve moved this conver…

I assume that the original performance profile of these tools was satisfactory to their creators, yet they still decided to rewrite them. I admire programmers who claim that their tools don't need to be maximally optimized. This is likely an attempt to justify the fact that their products aren't exceptionally performant either. Just take a look at the TIOBE rankings, and you'll see how many programmers hold a different view than you.
Post reply on HN