4 ms·

The "why not port to Rust" part boils down to these paragraphs: > tsc uses a lot of shared mutability and many parts depend on garbage collection. Even though

The "why not port to Rust" part boils down to these paragraphs: > tsc uses a lot of shared mutability and many parts depend on garbage collection. Even though I’m an advocate and believer in Rust, it doesn’t feel like the right tool for the job here. Using Rust required me to use unsafe too much for this specific project. > tsc depends on shared mutability and has a cyclical mutable reference. Rust is designed to prevent this behavior. Having two references to the same data (shared mutability) is undefined behavior in Rust. I'd be curious to hear more. In particular: * Two references to the same data: were cells too awkward? * Actual garbage collection: my first instinct would be to use an arena for each compilation, destroying the whole thing at once rather than doing reference counting or garbage collection. I gather that's not cool in the age of language servers and incremental compilation, though. Does tsc support those?

yazaddaruvala 5y ago
All of that is valid for a rewrite, but not efficient if you’re porting the current implementation. As I understand it, in this case, Rust would be able to have a line to line port from JavaScript. I do still think your overall point holds. Why not use a library in the Rust ecosystem to help with this problem e.g. some GC<T> type.
- scottlamb 5y ago
  > All of that is valid for a rewrite, but not efficient if you’re porting the current implementation. Help me see it? I can easily see how getting rid of the cyclical structure crosses from "line-to-line port" into "rewrite" territory. I'm not saying you're wrong, but I'm having more trouble seeing how "wrap some types in cells and pass along a lifetime and arena parameter" crosses that threshold. It might not be feasible at all, though, if tsc compilations are long-lived for language server + incremental compilation support. > Why not use a library in the Rust ecosystem to help with this problem e.g. some GC<T> type. iirc I've seen some experimental GC library mentioned. I think something like that is at least off the beaten path enough that I can see how the author might decide it's better to just use Go instead.
  - sealeck 5y ago
    It used to be in std.
  - charrondev 5y ago
    TSC supports both a watch mode and is used heavily as a language server.

yazaddaruvala 5y ago

All of that is valid for a rewrite, but not efficient if you’re porting the current implementation. As I understand it, in this case, Rust would be able to have a line to line port from JavaScript. I do still think your overall point holds. Why not use a library in the Rust ecosystem to help with this problem e.g. some GC<T> type.

scottlamb 5y ago
> All of that is valid for a rewrite, but not efficient if you’re porting the current implementation. Help me see it? I can easily see how getting rid of the cyclical structure crosses from "line-to-line port" into "rewrite" territory. I'm not saying you're wrong, but I'm having more trouble seeing how "wrap some types in cells and pass along a lifetime and arena parameter" crosses that threshold. It might not be feasible at all, though, if tsc compilations are long-lived for language server + incremental compilation support. > Why not use a library in the Rust ecosystem to help with this problem e.g. some GC<T> type. iirc I've seen some experimental GC library mentioned. I think something like that is at least off the beaten path enough that I can see how the author might decide it's better to just use Go instead.
- sealeck 5y ago
  It used to be in std.
- charrondev 5y ago
  TSC supports both a watch mode and is used heavily as a language server.