5 ms·
> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very s
by threatofrain 7y ago
> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow.
> Early on in the project we had hoped that "V8 Snapshots" would provide significant improvements here. Snapshots have certainly helped but it's still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust.
> This will be a massive undertaking and will not happen any time soon; but it would provide order of magnitude performance improvements in a critical path experienced by developers. TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch.
- deleted 7y ago[deleted]
- rvz 7y agoA note on Deno and the safety of its V8 bindings: > All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It's not yet 100% safe, but we're getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself. We'll also have to wait on who will be the first to have a production ready Javascript Engine written in Rust that could replace V8, if you're talking about safety. Even with the "safe" bindings, you will still get the same C and C++ vulnerabilities found in V8 that will also be present in Deno.
- ahupp 7y agoFor this sort of problem Rust's safety guarantees don't buy you all that much. If you're generating machine code and implementing a GC that's not the sort of thing that Rust's typesystem can prove correct. That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.
- klodolph 7y agoWell, sure, but a big chunk of the bugs in JRE were in the library, not the code generation or GC.
- ahupp 7y agoSpeaking of: Neon, a system for writing Node libraries in Rust is pretty cool: https://neon-bindings.com/ https://neon-bindings.com/
- jchw 7y agoNot sure exactly how much it buys you but I suspect there’s still room for research especially since Mozilla themselves has interest in a Rust JS JIT. I am curious to see if HolyJIT goes anywhere and what kinds of safety improvements it could potentially offer.
- afiori 7y agoDeno plans to not expose V8 internals, unlike node. I do not know where the V8 vulnerabilities came from, but it should decrease the attack surface.
- seleniumBubbles 7y agoWhat is the ongoing performance cost of using the official TypeScript compiler for long-running applications? Or is this primarily a concern of startup time for scripts and short-lived programs like CLIs?
- williamdclt 7y agoAFAIK, tsc is just a compiler, not a runtime. Once you compiled, you're just executing javascript so it only impacts startup time. ts-node is a runtime able to run TypeScript. It is definitely much much slower at execution, not just at startup time. It's useful for hacking around, I use it as a REPL but even for a dev environment it's faster to use tsc's incremental compilation with a file watcher, and execute the resulting JS
- hayd 7y agoIt's purely in the compilation step, V8 executes javascript.
- k__ 7y agoBut we have to admit, that most people will be happy enough with a Node.js with browser APIs. TypeScript is just an extra.
- spankalee 7y agoDeno really shouldn't run TypeScript files directly. Not only is TypeScript too slow for this, it receives far too many breaking changes. How will Deno decide when to upgrade its TypeScript compiler version? Will Deno have to have breaking changes every three months or so? Also, Deno appears to allow import TypeScript files with .ts extensions while tsc doesn't. This alone means the same code won't run in Deno and compile with tsc. JavaScript at Stage 3 and above is a stable compile target, and Deno should just run that.
- mrkurt 7y agoIt's just compiling TypeScript into JS when you import it, and uses tsc to do it. It can load JS just fine as well if you want to use Babel or similar.
- spankalee 7y agoI realize that it loads JS. The issue is that the TypeScript it loads today, it might not load in the future.
- TypeCaste 7y agoMy workaround is to use //@ts-ignore above the import, but this is clunky. I just tried Deno and found that TypeScript doesn't support .ts extensions yet.
- Roboprog 7y agoI would rather have Clojurescript than Typescript, but absolutely, less is more, and it feels like a bad idea to tie implementation of this runtime to another dependency. My love of the C++, Java, C#, ad nauseum, lineage of Enterprisey OOP languages turned to hate about 15 years ago, though, so take my assessment with a grain of salt. “C with classes” seemed like a good idea, we were told back in the 80s in school, since garbage collection is impractical. Er, yeah. Worse is better...
- jfkebwjsbx 7y agoGC is impractical in many domains. And in the 80s it was even more so due to CPU and RAM performance.
- leeoniya 7y agoesbuild can compile typescript a couple orders of magnitude faster: https://github.com/evanw/esbuild/issues/81#issuecomment-625083418 https://github.com/evanw/esbuild/issues/81#issuecomment-6250... though i think it just strips the typescript annotations. but this may be workable if during dev there's some kind of guarantee that the typechecking has already been done.
- xixixao 7y agoMassive undertaking is a big understatement. It would be better to not tie into TS/Flow and let one of the two biggest tech companies implement the best, fastest typechecker.