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

I’m porting the TypeScript type checker tsc to Go

kdy1.dev

Post reply on HN
Print view View original

221–230 of 252 posts

Re: I’m porting the TypeScript type checker tsc to Go

#221

Post by vips7L »

constexpr wrote: post #159
vips7L wrote: post #156

Earlier quoted context omitted.

> the ability to easily add shared-memory parallelism I’m honestly not sure if there is any popular language where this isn’t true?

The problem is that you can't use shared-memory parallelism in TypeScript. If you could, then the most straightforward way of speeding up the TypeScript compiler would be to parallelize the compiler, not to port it.

I just don’t see how Go is more uniquely suited to do this than any other language with the same feature and admittedly I may have read too much into your comment.

Re: I’m porting the TypeScript type checker tsc to Go

#222

Post by davidmdm »

constexpr wrote: post #148
sam0x17 wrote: post #110

Earlier quoted context omitted.

And then you face Go's usual awkward issues with having a lack of generics which becomes important when, say, traversing a tree.

I'm the author of esbuild. I hadn't written Go before I started esbuild and I thought I would miss generics more, but I didn't. There is literally only one situation in the whole esbuild code base where I've found myself wishing for generics: sorting an array. The workaround is easy and involves implementing an interface with three methods, each of which is typically a single line: https://pkg.go.dev/sort#Interface .…

I agree. I haven't missed generics at all since switching to Go. However that being said, do you think that the upcoming Go 1.18 with generic support is going to increase performance in Esbuild? Just from not having to Unbox every interface{}, or by writing less to the heap? Have you experimented with generics and esbuild?

Re: I’m porting the TypeScript type checker tsc to Go

#223

Post by pwdisswordfish9 »

wizzwizz4 wrote: post #9
Yoric wrote: post #8

Earlier quoted context omitted.

(er, some text in the parent seems to have vanished) Sure, if you absolutely wish it to, in an `unsafe` block, you can define two writeable pointers to the same piece of data. I don't think I've ever seen anybody write such code in Rust (except perhaps when linking to a C library that required it?), nor have I ever felt the need to do so. Now, it is true that Rust is designed to discourage writing cyclic data structu…

You actually can't define two `&mut` references to the same data in Rust. It's invalid Rust code; if the compiler notices, it'll refuse to compile, and if it doesn't notice, your code will randomly break.

You can, just not at the same time.

Re: I’m porting the TypeScript type checker tsc to Go

#224

Post by kaba0 »

Mawr wrote: post #186
kaba0 wrote: post #180

Slightly off topic, but do I not get something about Go? It comes up waay to often nowadays here, perhaps even more than LISPs - last time Rust was the hyped one, but it seemed to have decreased a bit. But at least rust is an interesting language with some novel features, adding new value to the low level PL domain. I fail to see what is unique about Go, other than the perhaps least known non-blocking concurrency (ba…

> I fail to see what is unique about Go That's because you're looking at it purely from only one point of view - the number of available features in the language itself. What's unique about Go is not so much about the language itself as the approach of its authors to creating it. Go hasn't meaningfully changed in the 10 years of its existence. That's not an accident - the bar to add anything is extremely high. A feat…

> If you look around the programming language space, you'll see the exact opposite attitudes, features get added into languages willy-nilly

Java has been going with the last-mover advantage of only ever incorporating a new feature when it proved to be useful by other languages. That has been going on for 25 years, so it is definitely queen of this category. Not sure why it is seldom appreciated, but it is also a very small language (compare the number of keywords it has by c# for example), and it was even named “blue-collar” for a reason. So I still don’t see Go anything new even from this perspective.

Re: I’m porting the TypeScript type checker tsc to Go

#225

Post by jpochtar »

constexpr wrote: post #159
vips7L wrote: post #156

Earlier quoted context omitted.

> the ability to easily add shared-memory parallelism I’m honestly not sure if there is any popular language where this isn’t true?

The problem is that you can't use shared-memory parallelism in TypeScript. If you could, then the most straightforward way of speeding up the TypeScript compiler would be to parallelize the compiler, not to port it.

node.js Workers + SharedArrayBuffers?

I'm not sure how well supported they are / haven't used them, but I think they enable this?

Re: I’m porting the TypeScript type checker tsc to Go

#226

Post by TheCoelacanth »

epolanski wrote: post #104
dmitriid wrote: post #87

Earlier quoted context omitted.

However, more than once I've also yelled "HOW DO YOU NOT KNOW THIS?!" at something or other :)

Just today I was triggered that this compiles. declare foo: never[] // it can only be an empty array foo[1] // compiles TypeScript is a nice type system, it's surprisingly expressive and flexible, like e.g. in Haskell I was surprised that there's this strange notion that for a given type you can only have one `Eq` or `Ord` instance for some type A. But in TypeScript you can have as many Ord interfaces as you want. I…

> But in TypeScript you can have as many Ord interfaces as you want. I may want to order some `User` type by last login, first login or whatever I want, but in Haskell you need to overcomplicate it and create a newtype.

I don't think that's accurate. Typescript only has one instance of Ord per type and it's inconveniently implemented through the method toString.

To usefully sort anything other than strings in Typescript, you are using a function where you provide your own comparator at runtime. That's more analogous to Haskell's `sortBy :: (a -> a -> Ordering) -> [a] -> [a]` or `sortOn :: Ord b => (a -> b) -> [a] -> [a]` which don't put any type bounds on the type you're sorting.

Re: I’m porting the TypeScript type checker tsc to Go

#228

Post by pawelmurias »

hardwaregeek wrote: post #32

This reminds me of when people try to make a new Ruby implementation. They get the basics down and think "this isn't so bad! I can do this!". Fast forward a few months and they're stuck on some nasty little edge case around eval and method_missing that they need to run Rails. Or some weird aspect of C extensions. TypeScript's compiler is an unholy, unsound mess, because JavaScript is an unholy, unsound mess. Sure the…

> It's also a mess that does not have a spec. Even if you somehow manage to make a type checker that implements most of the features, there's no way to ensure it has 1 to 1 parity with TypeScript. Plus that parity can be broken at any point.

You need a test suit for this not a spec.

Re: I’m porting the TypeScript type checker tsc to Go

#229

Post by strager »

eyelidlessness wrote: post #77
nevir wrote: post #71

Super skeptical that porting this to a new language is going to have the kind of performance gains they expect ... assuming they want to replicate all of tsc's functionality

It’s already proven (esbuild, SWC, Bun) to drastically improve performance of TypeScript’s other responsibility: compilation (tsc doesn’t offer an option for this, but ts-node does, for comparison). And while the type checker is certainly more complex, I have a hard time imagining it won’t show similar improvements in a native language.

esbuild, SWC, and Bun are not ports of existing programs.

Re: I’m porting the TypeScript type checker tsc to Go

#230

Post by throw10920 »

adamnemecek wrote: post #120
throw10920 wrote: post #34

Earlier quoted context omitted.

I'm not a Rust fanboy (in fact, I rather despise the RESF, especially given Rust's mediocre tooling), but: I think that "You have to tease out the implicit ownership model and one may not even exist" suggests a problem with the program itself . I can't think of any reason why a program must have an ill-formed ownership model (unlike, say, the fact that many interesting programs must have an embedded dynamic type syst…

> I rather despise the RESF, especially given Rust's mediocre tooling Which tooling are you talking about?

Copying from a previous comment[1]:

The Rust compiler is both dog-slow and massive (both from a source and binaries perspective), and doesn't have a working incremental compilation mode yet, or support in-process hot-patching. There's no Rust REPL (hacks like papyrus don't count). Poor structural editing support. Integration with various editors/IDEs is lacking (e.g. there's no support for reporting possible performance issues with code constructs in any editor that I'm aware of, nor is there in-editor per-function disassembly or LLVM IR inspection, or borrow-checker lifetime annotation, no extract-function refactoring).

[1] https://news.ycombinator.com/item?id=29925783

Post reply on HN