Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.
C# and Swift have pattern matching.
It's more limited than what you'd ideally want: pattern matching in function definitions. This makes walking ASTs a breeze.
Edit: And inline pattern matching for values returned from expressions and function calls (similar to destructuring, but more powerful).
Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.
The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }
Would you not just move that `try { ... }` block into a separate function or method?
TS's type system is fun but a part of me always wonders how much faster TS's compiler would be if it was written in a compiled language (assuming "good implementation", which is a big assumption!)
I haven't used it in a couple of years (tbh I may have to remove "full stack" and "Angular" from my CV...) but I don't recall TS compilation being particularly slow. Are people not happy with how quick it is, or do you have a particularly big/complex application you're working with?
TS's type system is fun but a part of me always wonders how much faster TS's compiler would be if it was written in a compiled language (assuming "good implementation", which is a big assumption!)
There's an answer from TypeScript team for your question :) https://twitter.com/drosenwasser/status/1260723846534979584 Basically, > Let's say TypeScript takes over 20 seconds to type-check a medium-sized program. That's not usually because it's JS, it's often because of types that cause a combinatorial explosion. Also > A different runtime can afford a lot (it sounds like parallelism and start-up time in this case)…
Both swc and esbuild claim to be much faster typescript compilers in part because they're written natively, but are actually just "cheating" and not doing any type-checking at all.
That's not to say they're useless though, they're good for fast hot-reload as you can have type-checking running in parallel.
As the post nicely demonstrates, TypeScript is definitely not OK for compilers (and not surprising at all!) It doesn't even have destructuring pattern matching! At this point, even Java is better [1]. [1] https://github.com/tomprimozic/caya/blob/master/src/caya/Int...
Pattern matching is definitely not a requirement for a language to be good for writing compilers in.
It sure is. For anyone looking into Compilers and just starting out, I recommend this book: https://keleshev.com/compiling-to-assembly-from-scratch/ The author uses a TypeScript subset to write a compiler to 32bit ARM assembly and explains that it almost looks like Pseudocode, so it is very accessible. A sentiment I can get behind, despite avoiding it in any case possible.
Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.
This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.
You mean, like C and its derivatives became obsolete once successors to PDP machines were built? ;-)
Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.
This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.
Any non-toy WASM application running in browsers will almost certainly end up as a hybrid WASM/JS application, just because you can't call directly from WASM into browser APIs, and even if the JS shim is "hidden from view", sometimes it's either more convenient or even more performant to write more than just a thin API shim in Javascript, especially for asynchronous code or to avoid redundant copying of large data blobs in and out of the WASM heap.