Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript is surprisingly ok for compilers

matklad.github.io

Post reply on HN
Print view View original

151–160 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#151

Post by madeofpalk »

sdflhasjd wrote: post #54
harrygeez wrote: post #35

Earlier quoted context omitted.

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.

it's easy to write a typed language compiler if you don't need to actually check types :)

Re: TypeScript is surprisingly ok for compilers

#152

Post by retrac »

lmm wrote: post #2

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.

Some crude snippets from a Pascal-C (I never could decide) self-educational compiler/toy I wrote a while ago (in Haskell):

    -- a parser function that matches on { ... } returning ... 
    -- can be combined with other parsers 
    braces = (symbol "{") `between` (symbol "}") 
    ...
    -- a statement is a controlFlow or a declaration or an assignment
    statement = controlFlow  declaration  assignment

    -- a block is either 1 or more statements surrounded by { ... }
    -- or a single statement.
    block = (braces $ many statement)  statement
    ...
    -- An expression is a number, or a variable, or a binary operation
    -- derive functionality to print and test equality of these values.
    data Expr = 
        Num Int
      | Var Variable
      | DualOp Op Expr Expr
      ...
      deriving (Show, Eq)
    ...
    foldConstants (DualOp Add (Num a) (Num b)) = Num (a + b)
    ...
Parser combinators (parser functions that take other parser functions and return more complex combined parser functions) with enough syntactic sugar can express BNF-like grammars directly as code. And ML-style list and pattern matching operations are very expressive for operating on the intermediate representation.

Re: TypeScript is surprisingly ok for compilers

#153

Post by austin-cheney »

afavour wrote: post #119
austin-cheney wrote: post #66

Earlier quoted context omitted.

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

> Also, try/catch will never compile in the JIT Changing the way you program to fit what a JS compiler does or doesn't do is a fool's errand, IMO. The performance benefits are likely to be minimal, confusion for anyone else who has to touch the codebase is high.

That depends on how many changes it requires. If its just a matter of don't do these 3 things and your code suddenly becomes more predictable its like being slapped with a magic wand. Everybody wins. All you have to do to ensure 100% of your code compiles in a JIT is be predictable. Predictable code is, on its face, always less confusing.

> The performance benefits are likely to be minimal

This makes me cry, but not a cry of joy or ecstasy. People guessing about performance is perhaps the most frequent anti-pattern in all programming. Please read the following document, you can skip to the end but it may not make much sense if you do.

https://github.com/prettydiff/wisdom/blob/master/JavaScript_...

When developers make random performance assumptions, defensive assumptions are worse, it immediately identifies a lack of professional maturity. Its like small children playing games that expand their imagination, which is great for small children but less great for developers pretending to be adults.

Re: TypeScript is surprisingly ok for compilers

#154

Post by sisypheanblithe »

grumblingdev wrote: post #116

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.

Everything is an object in Ruby as well

Re: TypeScript is surprisingly ok for compilers

#155

Post by austin-cheney »

raxxorraxor wrote: post #115
austin-cheney wrote: post #66

Earlier quoted context omitted.

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

For everything with the slightest bit of I/O it is quite practical if you have even the most trivial assumptions about its form. Sure, you can check for everything. It often is more effective, but not prettier or easier to read and of course you also will miss cases.

This sounds like some hyperbolic framework nonsense. First of all I/O just means access to an API. I am going to presume you mean messages from a network.

In that case a message from a network either sends or fails and in the case of sending try/catch does nothing for you but provide an error object, and you don't need try/catch to capture the error. In the case of receiving a network message the message comes in or it doesn't. If the message does come in and is malformed your application should be mature enough to handle that appropriately to the benefit of the user instead of crapping out some error messaging to the console. You don't need try/catch to do any of this. A simple if condition is more than sufficient.

> check for everything

You should check for everything. You only need to check for one thing and if you check for it you are already at 100% of everything. Did you get what you expected: Yes/No?

Re: TypeScript is surprisingly ok for compilers

#156

Post by eyelidlessness »

austin-cheney wrote: post #66
baq wrote: 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 { … }

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

> Also, try/catch will never compile in the JIT.

If this is an actual concern (as in you have measured and try/catch is actually affecting something performance sensitive): you can most likely mitigate the impact by isolating the try/catch bodies in separate functions.

I haven’t verified this in every JIT, but I saw meaningful perf improvement in V8 for real world degenerate cases where the performance did actually matter and make a significant difference. But seriously, as always, measure before optimizing stuff like this! It might matter, but it seldom will for anything more than academic curiosity.

Re: TypeScript is surprisingly ok for compilers

#158

Post by usrusr »

jakubmazanec wrote: post #118
usrusr wrote: post #103

Earlier quoted context omitted.

Yeah, having just jumped into ts after a long js hiatus since back when The Good Parts was still surprising, it's quite awesome to see how much of what I assumed to be "ts stuff" is actually just postdeluvian js. Makes ts more attractive, not less. I do wonder however of it was possible to identify parts of that language superset that are fully redundant (as in not even required for exotic edge cases) and let loose s…

You already can kinda do that using ESLint and rules like https://eslint.org/docs/latest/rules/no-restricted-syntax , https://eslint.org/docs/latest/rules/no-restricted-propertie... or https://eslint.org/docs/latest/rules/no-restricted-imports .

Sure, but that's still seems quite mix and match, anything goes, choose your own adventure. There are many positives about this approach, but as a learner a little more common ground between codebases would certainly be appreciated.

Re: TypeScript is surprisingly ok for compilers

#159

Post by dataangel »

c-hendricks wrote: post #144
_ZeD_ wrote: post #140

Earlier quoted context omitted.

>>> Are there other languages that do this so nicely? It's the perfect blend of OO and functional. Python, where everything is an object.

In Python, can typings define a property added to a function? Example, I have some Redux helpers that are functions, but those functions also define a `.actionType` property. TypeScript handles that. edit: accidentally wrote "object" instead of "function"

I believe you could have a Protocol that requires the property and that the object is Callable.

Re: TypeScript is surprisingly ok for compilers

#160

Post by hazebooth »

grumblingdev wrote: post #116

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…

I could be wrong, but can't Common Lisp do this?
Post reply on HN