I'm struggling to understand how this is a bad look for Typescript. Do you mean that the specific choice of Go reflects poorly on Typescript, or just the decision to rewrite the compiler in a different non-TS language?

If it's the latter, I think the pitch of TS remains the same — it's a better way of writing JS, not the best language for all contexts.

I think a lot of folks downplay the performance costs for the convenience of a shared code-base between the front and backend.

If the TS team is getting a 10x improvement moving from TS to Go, you might imagine you could save about 10x on your server cpu. Or that your backend would be 10x more responsive.

If you have dedicated team for front and back anyhow, is a 10x slow down really worth a shared codebase?

if I had to use Go I’d change my career and go do some gardening :)

I actually really enjoy Go. Sure it has a type system I wish was more powerful with lots of weird corners ( https://100go.co/ ), but it also has REALLY GOOD tooling- lots of nice libraries, the compiler is fast, the editor tooling is rock solid, it's easy to add linters to warn you about many issues (golangci-lint), and releasing binaries and updating package repositories is super nice (Goreleaser).

I'd probably have said the same 5 years ago, it's surprising how easy you change sides once you actually use it in a team.

I was mostly joking… some of the most amazing shit code-wise I have seen in “non-mainstream” languages (fortran leads the way here)

I had to, and I do think a lot about gardening these days...

I like Anders'answer there. "But you can achieve pretty great things with it".

Because it's so easy that you'd have a lot more time for gardening?

If they're writing (actually porting) a _compiler_, perhaps.

Go doesn't run in the browser however (except WASM but that is different).