(Cross-posting my HN comment at http://news.ycombinator.com/item?id=4598036.)

This looks nice.

It'd be 100% more useful if it was more aware of nullable types -- as it is, it appears that null * 7 compiles without any error messages. If you guys add a "nullable number" type distinct from "number", I'll be a lot more likely to use it.

It also appears that some other things compile that perhaps shouldn't, such as 7[2] and 7["a"] even though (7).a is equivalent and (correctly) fails to compile.

Nice work. :)

Thanks! Great suggestions!

Non-nullable types: There's a delicate balance we have to strike where the type system needs to be useful but not too complex. One guiding light for us here has been that toolability is more important than type safety. As non-nullness does little for e.g. auto-completion and comes with quite a lot of user-facing complexity, we've decided - for now! - not to track it. We note your feedback though; if this becomes a common request we'll take another look at it.

As for the typing of e.g. "null * 7" we can look at that separately from the above question. We do have a null type and could choose to reject this expression. A tradeoff with operators in general is that JavaScript is awash with operator-based idioms that are concise and useful but inherently "badly" typed. We don't want to police these too strongly so there needs to be some wiggle room. That said, we'll look at this case and see if there's some tightening up we can do without breaking idiomatic scenarios.

Finally, indexers: I am convinced we could have stronger typing here. In particular, since "dotting" in JavaScript is little more than syntactic sugar over indexing with constant strings, the type system could probably do a better job recognizing that and typingthose two syntaxes in a more similar fashion.

Thanks again for the great feedback!

Agree with this.  Given that TS is adding a level of verifiability to the code at compile time it would be great to replace those asserts with something that the compiler can understand. 

In the same way I think adding an immutable decorator would also be useful.  Like C++ const, this could help verify the code - even if no javaScript was emitted.