Live data from Hacker News

TypeScript is surprisingly ok for compilers

matklad.github.io

221–230 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#221
post #77

Earlier quoted context omitted.

var something = (() => { try { return mayThrow() } catch(SomeException ex) { log.Info(ex); return null; } catch(Exception ex) { log.Fatal(ex); throw; } })(); Close enough?

not really; can't immediately return from the lambda caller without throwing, always have to either try/catch anyway or if/else the return value of the lambda. (also, it's rather ugly to read and inconvenient to write.)

> can't immediately return from the lambda caller without throwing

You want to immediately return in the middle of something that was supposed to simulate just evaluating an expression?

You can't immediately return in the middle of 2+2 as well because return is a statement and can't be a part of expression.

Re: TypeScript is surprisingly ok for compilers

#222

Earlier quoted context omitted.

FP in python is painful without tail call elimination and the higher-order function syntax is so clunky

JS also doesn't have TCE, but for Python even just the lambda limitations are surprisingly annoying. I can't tell you how many times i've been frustrated because it's nearly impossible to put a print statement into a python lambda

lambda x: print(x) or x

Re: TypeScript is surprisingly ok for compilers

#223
post #94

Earlier quoted context omitted.

Typescript is defined to run exactly as the equivalent Javascript you get when all the type declarations are stripped out of the source. There's no benefit in compiling it to WASM unless you had a WASM JS engine (or JS->WASM converter) that executed the JS faster than the browser's built-in JS engine (or created WASM binaries that were smaller than compressed minified JS, which seems extra unlikely when you'd have to…

Your parent suggested to make changes to TS so that TS is no longer compatible with JS (in the sense you described). Once that happens, compiling to WASM instead of transpiling to JS is a very valid design choice.

That's fair, though there have been several projects that have attempted to be "JS-ish but with some behavior changes with strict type handling sprinkled in for optimizations" like the Strong types proposal (cancelled) and Dart (which switched to being a compile to JS language just like Typescript), so I'm currently convinced that the trade-offs aren't obviously worth it and that it's unlikely Typescript will change its priorities in that direction in the near future.

Re: TypeScript is surprisingly ok for compilers

#225
post #4

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!)

The type system is fun right up until you are using it to its full ability in generics..then you look at the 5 lines of 'type logic' you spent the last day debugging and ask yourself how you got here.

Pretty true lol chaining something together that ends up looking like this:

>>>>>>>

Is basically a guaranteed headache

Re: TypeScript is surprisingly ok for compilers

#226
post #142
post #109

Earlier quoted context omitted.

I mean I get what Daniel's saying, but I kinda doubt there wouldn't be _some_ speedup. And hey, what if type checking for small programs went from half a second to 100 ms? That would be nice!

That's a five times speedup. I wouldn't expect a typical 'compiled' language to run five times faster than JavaScript on the kind of code you find in a compiler.

You are excluding startup time. Loading the interpreter/runtime and initial JIT pass is slow. For many codebases, the compilation time is actually dominated by the time it takes the interpreter to get going.

Re: TypeScript is surprisingly ok for compilers

#227
post #142

Earlier quoted context omitted.

That's a five times speedup. I wouldn't expect a typical 'compiled' language to run five times faster than JavaScript on the kind of code you find in a compiler.

You are excluding startup time. Loading the interpreter/runtime and initial JIT pass is slow . For many codebases, the compilation time is actually dominated by the time it takes the interpreter to get going.

[deleted]

Re: TypeScript is surprisingly ok for compilers

#228
post #127

Earlier quoted context omitted.

The properties don't have to be 'state' per se; they can also be used to store metadata about the function. e.g. you could have a function with 'domain' and 'range' on it, or an 'integrate' method.

If the result of `integrate(...)` depend on `domain` and/or `range`, what would you call that other than 'state'? Or if `integrate(...)` doesn't reference `domain`/`range` what's the use of it being there? Or as I'm interpreting this, is sort of like documentation or information that could be used at runtime for code generation. Basically a shorthand for composing the function with its metadata. The nice thing about…

Avoiding this type of state is essentially impossible in FP, as captured bindings of closures have the same properties

Re: TypeScript is surprisingly ok for compilers

#230

TypeScript is an incredible language in general. The fact that Functions are Objects that can have properties/methods is supremely undervalued. Are there other languages that do this so nicely? It's the perfect blend of OO and functional. Programming is mostly about gradually figuring out the right design I find. JS/TS let's me evolve things naturally without big rewrites. function foo() {} function bar() {} function…

This blend of functional and oo programming was pioneered by scala.

Wasn’t it Scheme?
Post reply on HN