Why Asana Is Switching to TypeScript | Hacker News Reader

Why Asana Is Switching to TypeScript

eng.asana.com

101 pointspspeter325 comments

"The Surprising Benefits of Static Typing"

It's actually "gradual typing", which among many benefits shared with full static typing has one very important of its own: it gets out of your way when you want to ignore the types. The approach itself is old(EDIT: Common Lisp and Dylan), the research and theory behind it is a decade old at this point, this shouldn't be very surprising anymore :)

Decade-old PLT is still generally 'zomg super new' for industry languages, though. It's one area of computer science where industry really trends far behind research.

I wish TypeScript checked types at runtime.... boo...

The only language that I've seen in JS land that is trying to get this right is AtScript from the Angular team.

https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...

Looks interesting so far.

Dart can as well. In fact, I think that the whole type spec in AtScript is based on Dart.

Edit: Quote from the doc you linked: "This runtime type system is modeled after Dart’s runtime type assertion. Dart users working on large scale applications point out that optional types and runtime type assertions work well in practice."

Why do you want TypeScript to check types at run time? Integration with other JavaScript code?

Validation of JSON responses is the big win.

Ah that would be cool. We actually code generate interfaces for our responses which is really helpful.

Typelite is good for this.

I am a big fan of design by contract. (http://retromocha.com/obvious/) I don't trust user input in any form, including the database.

So, while a system like TypeScript that checks types in the code is fantastic, it doesn't check types in the input, which is how a lot of problems happen in the first place.

Seriously, just import one legacy dataset into your system or have to work with some JSON api, and all of a sudden you can't trust that the data is valid, correctly typed, or even sane.

Doing proper validation of types and data integrity at any input point can save you a whole category of sadly common bugs. That includes data coming out of any data source you use, like a database.

Runtime type checking is another tool to make validated data a common, sane thing.

why do you want that? The rationale given in the AtScript presentation seemed pretty weak to me.

Type checking at runtime allows for runtime data contracts. There are a lot of benefits to that, largely in being able to enforce stronger boundaries in your code.

Strong boundaries allow for potentially better code reuse, fewer bugs, and a more confident style. Once you setup a type or validation boundary, you know that you no longer need to check for type errors and so forth elsewhere in the code, if only for the fact that the code will blow up before it even gets there.

That means you write less code, have fewer bugs, and can spend more time doing important things, like playing Quake 2.

You can have type checking - or even much stronger validation - on runtime with contracts. Racket and TypedRacked are an example of how well contracts and static typing can work together, providing both compile-time and runtime guarantees. I'm sure something like this will come to "idustrial grade" languages in a decade or so...

Contracts.js [1] has been actively developed for quite a while. It uses Sweet.js "macros" to provide runtime type-checking. Also usable in CoffeeScript.

It doesn't get much hype because it's not new, but that's why I like it. Reliable and stable.

[1] http://disnetdev.com/contracts.js/

[EDIT: Contracts.js is based off Racket, advantages pointed out by another commenter.]

I don't want to keep adding to the comments about why not X so I'll ask a more generalized question, what other options did you consider and why did you abandon them?

We looked at PureScript, ClojureScript, LiveScript, CoffeeScript, Dart, and compile language X to JS tools. We wanted static typing for run time correctness with respect to accessing data loaded from a server so that ruled out the dynamically typed variants like CoffeeScript. We also did not want to force our developers to learn a new language so that really only left TypeScript. At the time we were investigating, Flow by Facebook and AtScript by Google were not out yet. It seems like TypeScript will play well with Flow which is nice.

About the React post mentioning improvements from types: React wanted to use Typescript (see http://youtu.be/M8x0bc81smU?t=37m57s), but they created Flow instead because Typescript didn't fit them, so the performance improvements the post mentions came from Flow instead.

I came from requirejs code base into new typescript based with rjs used to load modules. I found many small nuances I had to fight about the way typescript generates and uses rjs modules. With browserify-type of modules that should not be a problem tho.

Why not purescript?

Largely because of the difference from vanilla JavaScript syntax. PureScript looks great but would be asking for a lot of change just like Scala.js. We also looked at ClojureScript and LiveScript

I may be wrong but didn't they write their own language that compiles to javascript?

It appears that they did. It was called LunaScript.

We did long ago, but ditched that idea because we get to use the tools of JS and we realised that effectively using a DSL embedded in another language allows the developer to break the rules of the DSL.

Surely those points apply to TypeScript.

Lunascript was very different from JavaScript, partly because it had automatic support for our reactivity system. As a result it compiled to JavaScript that looked nothing like the original code (even the control flow was different). Reading this code was very difficult.

The IDE support for TypeScript is actually pretty great; building our own tooling support for LunaScript felt like something we didn't really want to have to do.

Reply on news.ycombinator.com