Hacker News new | ask | show | jobs
by joobus 3293 days ago
Note they are type annotations. They are for tooling/development only; the runtime doesn't care about the types at all.
5 comments

> Note they are type annotations. They are for tooling/development only; the runtime doesn't care about the types at all.

Neither does, say, Haskell's runtime.

You say that like it's a bad thing, but that's what a static language is - types are checked at compile time and, hopefully, forgotten about at runtime.
That's not entirely true. The information from the type annotations is available at runtime. ApiStar takes advantage of this, for example.
The information from annotations is exposed to the runtime, but nothing in the runtime treats them as types or performs any type checking. The feature was introduced as a generic way to annotate functions, without being constrained to a single use case (type checking), and all the tools which actually do type-checking based on annotations are third-party.
C++ also does do any type checking at runtime. Compile time checking is all that really matters.
The CPython implementation does have a "compile" step (to produce bytecode, which is what actually gets executed, by a simple stack-based virtual machine), and does not do any type checking in that step no matter how many annotations you give it.
Hmm, Perl6 has real types, although they're completely optional.
which language's run time cares about types?
Any dynamic language - by definition, they check types at runtime.

Or, unfortunately, a lot of static languages. Any static language that allows type casting, for instance - that's the only way they can check whether a cast from a type to one of its descendants is valid (eg, in Java, casting an Object to a, say, URL).

Type information is used in JS engines to compile into native code. If type information is too vague or change you can have deoptimization[0]

[0]http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op...