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.
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...
And in the 80s it was even more so due to CPU and RAM performance.
> TS is pretty dang popular, but what if something else comes along and scoops it?
Earth is rather small, type inferencing dynamic language is really hard. There is simply no other language or team that has achived anything like TS. It's very unlikely that anyone else will do it for JS again. You can just look at amount of work in TS already.
Only thing that can "scoop it" is another language entirely taking off and leaving JS developers in the history. In that case the point becomes useless, it can happen to any runtime for any given language.
The issue is that the TypeScript it loads today, it might not load in the future.
> 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.
That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.
TypeScript is just an extra.
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.
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
> 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.