4 ms·

I really like the idea of static type checking, but I'm not convinced about the usefulness of runtime checking. It will introduce a performance penalty and it w

I really like the idea of static type checking, but I'm not convinced about the usefulness of runtime checking. It will introduce a performance penalty and it will go against duck typing, which is one of the coolest features of languages like JS. It seems that this project is trying to build something in between of TypeScript and Dart: they want the optional runtime type checking of Dart vs the good interoperability with JS of TypeScript. In this interview [1] Anders Hejlsberg and Lars Bak (from TypeScript and Dart) discuss the idea of runtime type checking. They don't seem very convinced of the idea either. [1] https://www.youtube.com/watch?v=5AqbCQuK0gM https://www.youtube.com/watch?v=5AqbCQuK0gM

grandalf 12y ago
Everything quacks like an object!
nawitus 12y ago
The link states that you can "disable" the type checking for production use. I wonder if there's still a slight performance penalty. Atleast my "toy" project for runtime type checking has that slight performance penalty even when it's disabled: https://github.com/panuhorsmalahti/typed-javascript https://github.com/panuhorsmalahti/typed-javascript
- malandrew 12y ago
  Thanks for the link. That's an interesting approach that I hadn't considered. Would be nice to see it also support checking the return types and higher-order functions.
zackbrown 12y ago
As I understand it, there is a 'production mode' that disables the runtime type checking. This way developers can gain the development-time benefits of type safety without sacrificing performance where it counts. As for the benefits of duck typing, also as I understand it, the key point of runtime vs static checking is that it eases interoperation with non-annotated and non-typed code. So duck-type if and when you want; reap the benefits of types when you want. For a much better explanation, watch Misko Hevery's keynote about Angular 2 and AtScript from NgEurope yesterday: http://youtu.be/S8fE-w2DL8U?t=21m5s http://youtu.be/S8fE-w2DL8U?t=21m5s
- malandrew 12y ago
  Yup. Plus it should also be possible to only turn on type checking selectively for some functions in production. This way to you can implement it on functions that are executed infrequently and don't have a material impact on performance, but leave it off for those code paths that are critical for performance.

grandalf 12y ago

Everything quacks like an object!

nawitus 12y ago

The link states that you can "disable" the type checking for production use. I wonder if there's still a slight performance penalty. Atleast my "toy" project for runtime type checking has that slight performance penalty even when it's disabled: https://github.com/panuhorsmalahti/typed-javascript https://github.com/panuhorsmalahti/typed-javascript

malandrew 12y ago
Thanks for the link. That's an interesting approach that I hadn't considered. Would be nice to see it also support checking the return types and higher-order functions.

zackbrown 12y ago

As I understand it, there is a 'production mode' that disables the runtime type checking. This way developers can gain the development-time benefits of type safety without sacrificing performance where it counts. As for the benefits of duck typing, also as I understand it, the key point of runtime vs static checking is that it eases interoperation with non-annotated and non-typed code. So duck-type if and when you want; reap the benefits of types when you want. For a much better explanation, watch Misko Hevery's keynote about Angular 2 and AtScript from NgEurope yesterday: http://youtu.be/S8fE-w2DL8U?t=21m5s http://youtu.be/S8fE-w2DL8U?t=21m5s

malandrew 12y ago
Yup. Plus it should also be possible to only turn on type checking selectively for some functions in production. This way to you can implement it on functions that are executed infrequently and don't have a material impact on performance, but leave it off for those code paths that are critical for performance.