Either it is only accepting a subset of TypeScript, or it is still interpreting the parts that don't have enough types. Given other comments here it sounds like the later.
What it can actually compile is a subset of well-behaved typescript. For anything else it bails out and asks you to ship a JS engine (albeit, not NodeJS) again.
Amen! Europe used to complain about the US stealing their intellectual property! The nuclear bomb would have been possible if not for Jewish scientists from Europe going to America! So until about 100 years ago, US was FAR behind Europe in technology and science.
It tends to be. While it does use a GC, it has both bytecode and native AOT compilers. When compiled to native, it's closer in performance to C++ and Rust than to C# or Java. It's a reasonable middle ground in PL design that Nim also tries to occupy. In recent years, OCaml's runtime also shed the GIL, making it a good solution for parallelizable, CPU-bound tasks. As a language, OCaml is one of the most impressive ones (in terms of features and capabilities), yet it still provides strong, practical tooling, good performance, and access to low-level-ish features.
TL;DR: OCaml is usually going to be a bit slower than C++, but faster than Java, while rivaling Rust and Haskell in terms of expressive power.
Caveat: a lot of the power comes from the tooling. Last I checked, syntax extensions were external preprocessors, just with standardized APIs. And you need those extensions for things that are handled by (in-language) macros in Rust (like deriving string representation for a record). Without the tooling, OCaml can get a bit tedious/boilerplate-y. OTOH, after a period of instability and competing solutions, the tooling mostly settled down, and enabling the important parts is often a single line in the config. It's not a situation unique to OCaml, but if you look at the language docs only, you'll miss half of what OCaml development normally offers.
reply