Live data from Hacker News

TypeScript is surprisingly ok for compilers

matklad.github.io

131–140 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#131
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 reason we need to buy new hardware every few years, and fill landfills with our old stuff, is because of ideas like “let’s use JavaScript to write a compiler!”

No lie, the M1 was a game changer for large Typescript projects.

Re: TypeScript is surprisingly ok for compilers

#132
post #84
post #69

Earlier quoted context omitted.

I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.

> aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.

There are a few very specific differences. In a subclass, 'this' doesn't exist until you call "super" for example, and the constructor will throw an error of invoked without the "new" keyword. [O]

These differences let you extend built-in things that simply can't be done with old prototype constructor syntax. [1]

[O] I should probably be using a more recent reference like MDN, but the 2ality series always sticks out in my mind whenever "just syntax sugar" comes up: https://2ality.com/2015/02/es6-classes-final.html#safety-che...

[1] https://2ality.com/2015/02/es6-classes-final.html#subclassin...

Re: TypeScript is surprisingly ok for compilers

#133
post #32
post #17

Earlier quoted context omitted.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

What does a try expression like this do? Returns null/undefined on a throw? I suspect you could do something like: const c = attempt(() => ... ); where attempt invokes the lambda, catches any exceptions, and does what you want

Kotlin has this feature (`try` and `if` are expressions not statements), and a good model for return values. https://kotlinlang.org/docs/exceptions.html#exception-classe...

Re: TypeScript is surprisingly ok for compilers

#135
post #22
post #17

Earlier quoted context omitted.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

With async code, there is const c = myAsyncFun() .catch(e => …)

That leaves c as Promise which was not the type they were looking for. You'd still have to unwrap the promise and deal with the result or rejection. The easiest way to do that is to use await, and if you are using await you'd be better off using try {} catch {} around the async function than .catch().

Re: TypeScript is surprisingly ok for compilers

#136
post #98

I'm sick of seeing overly complicated TypeScript code. Mainly overly complicated types.

compilers are really complicated pieces of software. There's a lot of complexity even in small routines. I would expect to encounter complicated types in there, they capture (while complex) intent and meaning.

It's not the frontend glue-code kind of code. The inherently hard problem makes is fun for people who like to solve small puzzles.

Re: TypeScript is surprisingly ok for compilers

#137
post #84
post #69

Earlier quoted context omitted.

I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.

> aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.

The result of `let x = Foo()` when Foo is defined as a function is whatever Foo's return value is. Trying `let y = Foo()` when Foo is defined as a class throws a TypeError.

Re: TypeScript is surprisingly ok for compilers

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

> part of me always wonders how much faster TS's compiler would be if it was written in a compiled language

TypeScript's compiler _is_ written in a compiled language.

(I think you are using "compiled" here as a euphemism—one that doesn't help anyone.)

Re: TypeScript is surprisingly ok for compilers

#139

Earlier quoted context omitted.

> 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. JavaScript and TypeScript are not "proper" languages? Different languages are powerful in different use case dimensions (tradeoffs), and the typical client-side web programming has a very very strong UI angle, which many "more p…

JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today

TypeScript is a pleasure to use. I have no desire to replace it with another language.

Re: TypeScript is surprisingly ok for compilers

#140

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…

>>> Are there other languages that do this so nicely? It's the perfect blend of OO and functional.

Python, where everything is an object.

Post reply on HN