4 ms·
"Most" isn't necessarily a good thing, because it can lead to a false sense of security. For example, if you start thinking, "no need to check for null here, be
by acjohnson55 9y ago
"Most" isn't necessarily a good thing, because it can lead to a false sense of security. For example, if you start thinking, "no need to check for null here, because the types won't allow it", you're open to being surprised when a null sneaks in at run-time. So you have to deal with the overhead of both types and run-time guards.
- RyanCavanaugh 9y agoIt's not like it fails on a 1d20 roll. Most unsound languages will only cause runtime problems if you are proactively trying to construct things which defeat the type system.
- jeremyjh 9y agoThis is the sort of thought people have when they haven't actually used the language much. It is also an example of something Typescript is really good at. If you try to use an `any` value - or any nullable typed value - that hasn't been checked for null, it is a type error. Sure you could write a type definition for a Javascript function that is a lie and say that it cannot return a null when it can, and then guess what? You'll get a runtime error and debugging it is identical to Javascript. In fact I do not know of any language that is actually safe at it's FFI boundaries. Rust isn't, Haskell isn't. You could get a value back from a C function that you were told would be allocated 64-bytes and actually it was only 32, so you'll have an overflow somewhere later. The Typescript / Javascript boundary is similar, though obviously not as dangerous.
- acjohnson55 9y agoThe problem is in just how much boundary there tends to be, since many TypeScript programs are heavily mixed with ordinary JS. I would agree with you for programs that exclusively use TS for application code.