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

241–250 of 252 posts

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

#241

Post by msoad »

constexpr wrote: post #234
jpochtar wrote: post #225

Earlier quoted context omitted.

node.js Workers + SharedArrayBuffers? I'm not sure how well supported they are / haven't used them, but I think they enable this?

Yes that allows for shared memory. But the TypeScript compiler is written in TypeScript, and you can't put JavaScript objects (such as the TypeScript AST) in a SharedArrayBuffer. So you'd have to port the TypeScript compiler to another language that can target multithreaded WASM to do this. You could also try sending JS objects between workers instead of using SharedArrayBuffer. But that copies the memory, which can…

Folks at Parcel wrote serializers that uses SharedArrayBuffer for their core stuff like graph[1]. I agree with parent comment that this didn't have to happen in Go, JS would've been fine if they were willing to depart from the source enough.

[1] https://github.com/parcel-bundler/parcel/tree/v2/packages/co...

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

#242

Post by throw10920 »

cztomsik wrote: post #239
throw10920 wrote: post #231

Earlier quoted context omitted.

Thank you for explaining - now that you've pointed it out, I can see that this is just another form of the "graphs are hard in Rust" problem that I've encountered before. However, I still stand by my point - Rust might be bad at graphs, but I believe that a well-designed language with a borrow checker (maybe something closer to Lobster, which automatically inserts RC cells when you try to multiply mutable borrow[1] -…

The problem is that Rc is not replacement for GC, in GC language you just don't care about having multiple mutable references at all because it's mem-safe (so you don't need to panic). The only thing you can get is concurrency issue but that's often fine for isolated algorithms (where you do mutex at the top and don't care from there or you just send the whole thing to the worker using channel). Rust is placing restr…

Do you mean a Rust Rc or a generic "borrow-checked language" Rc? In the former case, yes, I absolutely agree that Rust is not ideal. However, my argument is about a theoretical language with a borrow-checker, in which case - why isn't something like Lobster sufficient, which automatically detects when you have multiple owners and inserts reference counting under the hood?

https://aardappel.github.io/lobster/memory_management.html

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

#243

Post by cztomsik »

throw10920 wrote: post #242
cztomsik wrote: post #239

Earlier quoted context omitted.

The problem is that Rc is not replacement for GC, in GC language you just don't care about having multiple mutable references at all because it's mem-safe (so you don't need to panic). The only thing you can get is concurrency issue but that's often fine for isolated algorithms (where you do mutex at the top and don't care from there or you just send the whole thing to the worker using channel). Rust is placing restr…

Do you mean a Rust Rc or a generic "borrow-checked language" Rc ? In the former case, yes, I absolutely agree that Rust is not ideal. However, my argument is about a theoretical language with a borrow-checker, in which case - why isn't something like Lobster sufficient, which automatically detects when you have multiple owners and inserts reference counting under the hood? https://aardappel.github.io/lobster/memory_m…

yeah I mean rust Rc, I don't have experience with lobster, does it allow mutation from multiple places or does it panic just like rust?

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

#244

Post by klodolph »

throw10920 wrote: post #242
cztomsik wrote: post #239

Earlier quoted context omitted.

The problem is that Rc is not replacement for GC, in GC language you just don't care about having multiple mutable references at all because it's mem-safe (so you don't need to panic). The only thing you can get is concurrency issue but that's often fine for isolated algorithms (where you do mutex at the top and don't care from there or you just send the whole thing to the worker using channel). Rust is placing restr…

Do you mean a Rust Rc or a generic "borrow-checked language" Rc ? In the former case, yes, I absolutely agree that Rust is not ideal. However, my argument is about a theoretical language with a borrow-checker, in which case - why isn't something like Lobster sufficient, which automatically detects when you have multiple owners and inserts reference counting under the hood? https://aardappel.github.io/lobster/memory_m…

Among other things, the article you linked explicitly mentions that it does not solve one of the major problems with using Rc, which is that it does not handle cycles.

It sounds like a more ergonomic system that has the same technical shortcomings.

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

#245

Post by danielearwicker »

exdsq wrote: post #189
epolanski wrote: post #104

Earlier quoted context omitted.

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…

Just a note that TypeScripts type checking & compilation are two separate systems. It's never a compilation error because it always compiles.

In TS this is controllable. If noEmitOnError is true, then any error (including type errors) will stop it emitting JS output.

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

#246

Post by Yoric »

anderskaseorg wrote: post #17
Yoric wrote: post #11

Earlier quoted context omitted.

You can define two `*mut`, though, in unsafe code.

A better option is to use Cell or RefCell; they allow completely safe shared mutability in single-threaded code. https://doc.rust-lang.org/std/cell/

I'm aware of that :)

I'm just trying to decypher that cryptic sentence from the OP.

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

#248

Post by throw10920 »

cztomsik wrote: post #243
throw10920 wrote: post #242

Earlier quoted context omitted.

Do you mean a Rust Rc or a generic "borrow-checked language" Rc ? In the former case, yes, I absolutely agree that Rust is not ideal. However, my argument is about a theoretical language with a borrow-checker, in which case - why isn't something like Lobster sufficient, which automatically detects when you have multiple owners and inserts reference counting under the hood? https://aardappel.github.io/lobster/memory_m…

yeah I mean rust Rc , I don't have experience with lobster, does it allow mutation from multiple places or does it panic just like rust?

The latter - although as a sibling commentator pointed out, it doesn't do cycles - so it's better, but not a panacea.

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

#249

Post by kunley »

sam0x17 wrote: post #86

Oof trust me from experience you do _not_ want to write a compiler or parser or anything like that in Go. The string support is so limited -- for example you have to implement basic things like reverse string from scratch instead of them (and much more) being in the standard library. Much better to use something like Crystal or Rust.

Sounds strange. Where do you reserve strings in the compiler?

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

#250

Post by cztomsik »

throw10920 wrote: post #248
cztomsik wrote: post #243

Earlier quoted context omitted.

yeah I mean rust Rc , I don't have experience with lobster, does it allow mutation from multiple places or does it panic just like rust?

The latter - although as a sibling commentator pointed out, it doesn't do cycles - so it's better, but not a panacea.

Ah, ok, having cycles is another problem, also hard, but my point was about multiple mutable references which is not a safety problem if you have GC. You only get race conditions.

And I think it could/should work also with Rc but for some reason, rust authors decided it's important to write everything as if it was multi-threaded even if it's single-threaded now (so it can be easily turned to multi-threaded later).

And that's cool but it adds a lot of burden to developers. I am probably missing something, there is likely a good reason for this, as always, but it doesn't change the point, rust is super-complicated for hobby stuff and you have to think about irrelevant things, hence for me, it is low-level language (with generics and macros and very cool builtin unit testing but it's still low-level)

And by irrelevant I don't mean mem-safety, that IS important for me, I rather mean worrying about race-conditions in a single-threaded code :)

Post reply on HN