News for hackers. Stuff that matters.
Re:How porting to TypeScript solved our API woes by Arnavion on Wednesday April 08, 2020 @05:09PM (#22817164)
Strong typing means that at runtime dynamic behaviors don't need to be accounted for.

For a compiled language, the compiler could know that `foo` and `bar` are 32-bit integers, and thus compile `foo + bar` to call the addition function for 32-bit integers. In an interpreted language, the interpreter could do the same thing.

Without that typing information, both would have to invoke a generic addition function that detects the types of its arguments at runtime, notices they're both 32-bit integers, and delegates to the corresponding addition function.

Of course there are tricks that can be played in the weakly-typed case, like assuming the same call site will always have the same types, so that there can be a short path that assumes that and only branches rarely. That way the first or first few executions might be slow, but eventually they get almost as fast as the statically-typed case. JS engines in particular and JITted runtimes in general usually do this.

>I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types.

Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints, and is distinct from the addition function for 64-bit ints.

Re:How porting to TypeScript solved our API woes by mr_toad on Wednesday April 08, 2020 @10:06PM (#22819156)
> Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints

You can add any bits that will fit in the relevant registers. Assembly cares not whether the programmer thinks they are ints.

Re:How porting to TypeScript solved our API woes by Arnavion on Thursday April 09, 2020 @03:21AM (#22820499)
You should read the part of the sentence you cut off in your quote.