101–110 of 245 posts
To OP: You could avoid the visitor by using an IIFE style switch using the run utility fn: export const run = (f: () => T): T => f(); Now you can go: const inferred_type = run(() => { switch(blah) { ... } })
Exactly! I wrote a post about this pattern: https://maxgreenwald.me/blog/do-more-with-run
Earlier quoted context omitted.
I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that different and you can transition from one to the other pretty easily. I have my preferences (kotlin) but I can work with both. IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascrip…
> IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript? My fantasy for the past year has been, if I could magically program anything, bringing a compiler and spec wholesale into the world out of the void, I would create a new language (call it WebScript as a placeholder) that - featured an ML style type system, ADTs, a type syntax n…
Earlier quoted context omitted.
I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that different and you can transition from one to the other pretty easily. I have my preferences (kotlin) but I can work with both. IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascrip…
"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).
Earlier quoted context omitted.
That's some very high level view - in reality even tough those languages are in similar categories the experience would be vastly different : TypeScript - powerful type system but shit underlying stdlib and language (no pattern matching/switch expressions) Dart - worse than TS because the object model is closed - so no dynamic freedom, but the type system and expressions are weaker then the rest. Also 0 meta programm…
If you’re going to use C# for a compiler, why not go the whole hog & use F#?
You'll probably have similar overlap between C# and F# implementations as you would with say TypeScript - they are just that different in practice IMO.
Earlier quoted context omitted.
I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that different and you can transition from one to the other pretty easily. I have my preferences (kotlin) but I can work with both. IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascrip…
I'm afraid that's wishful thinking. JS compatibility is core to the TypeScript ethos, regardless of TypeScript's own popularity. Besides, enums (?) aside, and ignoring typechecking, compiling TS is really easy right now. Switching to WASM is a high ask.
Earlier quoted context omitted.
There’s https://swc.rs/ , a Rust implementation (albeit without type checking at this time).
Not really a fair comparison. Stripping out types is trivially fast regardless of the implementation language. The _vast_ majority of the time taken in tsc is because of the type checking
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?
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.
The book is split into two parts. The first implements a language interpreter in Java, and the second implements the same language by building a compiler to byte-code and also implements a byte-code VM in C. Every line of code in the implementation is referenced in the book.
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)…
I'm sick of seeing overly complicated TypeScript code. Mainly overly complicated types.