Hacker News Reader

> If the object was 'any' at some point, if you make an invalid cast Typescript will trust you.

I believe any language that supports "any" allows this. Doesn't Kotlin? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/

> If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up.

Not if you set strict: true in your typescript options, or you can separately enable just strictNullChecks

> Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript.

Instead of casts that fail, typically you would use type guards to deal with this. That way you can isolate unsafe casting code to a single place.

> Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin.

DefinitelyTyped (http://definitelytyped.org/) has types for over 3500 popular libraries: https://www.npmjs.com/~types

> the runtime is about 10x faster.

Hmm. I see 1.5x-6x here, with average around 3-4x: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Fwiw, microbenchmarks are not a good indicator of application perf in general. That said, nodejs is pretty fast. Also a memory hog, and doesn't support parallelization.

I always have a chuckle when JS fanatics talk about Java's "huge runtime" when Node and webapps use stupid amounts of ram. Java's memory efficiency is stellar in comparison.

> I believe any language that supports "any" allows this. Doesn't Kotlin? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/

Kotlin's Any is pretty much the opposite of TypeScript's any. In TS it disables type checking completely (according to the docs). In Kotlin it's the top type (similar to Java's Object type), which anything conforms with, but doesn't expose any operations at all (except for the stuff that the JVM provides for free).

The closest match to TS' any would probably be C#'s dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g....

Yes, this is the effective difference between Typescript and typecasting in most other languages. Typescript, since it compiled to js, doesn't know the runtime type so it can't use reflection to make sure casts are valid. It just takes your word for it. If the cast isn't always correct prepare for a world of pain trying to track it down instead of getting an exception on casting failure

I encountered this the other day, while playing with typescript for the first time. Is there a good solution, such as a utility function that does a runtime check before casting? I suppose I could write one for each type cast, but it seems like I shouldn't need to.

Kind of maybe. See http://blog.wolksoftware.com/decorators-reflection-javascrip... for use of experimental reflection API.

Note that Typescript tries to follow JS to remain a superset that easily compiles down, and the metadata API is currently a stage II Ecma proposal so it's marked experimental.

It should be fairly easy to build a types casting method using that.

Yes, a runtime check in TypeScript is the same as a runtime check in JavaScript.

    function inc(n) {
      if (typeof n === 'number') { return n + 1 }
      throw new Error('Parameter n is not a number');
    }

If you wanted to actually runtime check all types (probably not advised) you could parse the type annotations.

Or you could define your types using something like JSON Schema and validate against that.

https://github.com/bcherny/json-schema-to-typescript

https://github.com/YousefED/typescript-json-schema

I'm sorry to say but... This check won't help with accidental incorrect casts. Typeof in typescript is a pass through for the JavaScript function, so it only returns what the JS version does.

A check for a string or number will work, but a check against a typescript object or something complex like a union type will just return 'Object'

You can use a tslint rule to block casts. That way you will only be able to use type guards to change the type of something.

> Kotlin's Any is pretty much the opposite of TypeScript's any. In TS it disables type checking completely (according to the docs). In Kotlin it's the top type (similar to Java's Object type), which anything conforms with, but doesn't expose any operations at all (except for the stuff that the JVM provides for free).

If you want top-type like behavior in TS, you want to use `{}` instead of any, since the language is structural. Anything satisfies it, but it exposes no members without a cast or guard to a more specific type.

Actually, the Kotlin equivalent to TS' any is 'dynamic': https://kotlinlang.org/docs/tutorials/javascript/working-wit...

You can declare a `dynamic` Kotlin variable like this:

   val myObject: dynamic = null

The myObject above is not type-safe. It seems that the reason for its existence is interop with existing JavaScript code.

The Kotlin `Any` class is actaully more related to Java's `Object` class. (It's the superclass of every Kotlin class.)

No, Swift requires "any as? Cast" which returns "Optional<Cast>" (or you can use "any as! Cast" which at least crashes instead of happily proceeding with the wrong type).

Your critique is about JavaScript, not about TypeScript.

Your argument is that TS blindly trusts 3rd party typings, but Kotlin has the same exact issue! In fact the Kotlin docs say to use TypeScript typings, or "dynamic" (read: unsafe) mode for 3rd party libs. So I would expect the same level of safety between TS and Kotlin when it comes to 3rd party libs.

I personally prefer TS because it's safer: with literal types and mapped types, my code is far safer than the equivalent Kotlin. It will surprise you how often you use these features.

To add to that, TypeScript is a superset of JavaScript, whereas Kotlin is a new language you'd have to learn.

> Since Java has always been strongly typed and has a ton of libraries available

Means nothing for alt-Java languages' JS target. While the host language gets the Java ecosystem for free, to replicate on the client every Java library needs to be cross compiled.

It's a non-trivial endeavor, one that ClojureScript and Scala.Js can largely avoid due to their already having a rich set of cross compiled frameworks and libraries in their respective ecosystems.

Not sure what the story is with Kotlin here, seems pretty tightly coupled to Java.

The Java classpath (built in API) will be an issue possibly. It's easy to compile third party libraries statically with your app. Just build a fatjar with maven shade and strip it with progaurd. You application will be only the Java runtime and code you're actually calling.

I've tested this with Java console apps and it makes them very small. I'm guessing you could get your app size under 50kb