People often say this, and I don't get it. What JS tests are you writing that become unnecessary in TypeScript? I've used a fair amount of TypeScript and plain JS, and end up with similar amounts of tests for each. With JS, I almost never want to verify only that a value is of a specific type; I want to look at its contents, which means I'd need to write the same test in TypeScript.

    function doSomething(thing) { ... }

You need integration-level tests around every method call to ensure that caller and callee agree what kind of 'thing' representation to use. Type systems can eliminate this class of bug entirely.

1. The library makes an assumption on a type (in the case of Python, that's typically "there's only one type of strings", "there's only one type of streams", sometimes "there's only one type of numbers", etc.). Since the language is loosely-typed, there's no API barrier that checks this, it's all duck-typing.

2. Tons of code is written based on this assumption.

3. Assumption changes. In this example, this happened with the Python 2 => Python 3 migration, but it also happens once in a while with smaller version increments of either Python itself or Python libraries.

4. Where is the assumption used in your code? Well, if you're lucky, you're going to find out once a piece of your code throws an error because it's attempting to use a method that doesn't exist anymore. If you're not lucky, the behavior of your code has changed subtly.

In the loosely-typed world, the only way to avoid this is to have very strict boundary checks. Which means basically manually implementing subpar type checking at the borders and unit tests and/or fuzzing just to ensure that your mock-type-checking actually does its jobs.

Of course, you can often get away without doing this as long as your code is for internal use only. But if you're writing a library and if you want your users to be able to troubleshoot problems without too many difficulties, you're doing manually what the compiler is doing for you in a statically-typed language.

Metric or imperial integers? Your unit tests failed to prevent this $300 million blunder:

https://www.wired.com/2010/11/1110mars-climate-observer-repo...

But more commonly what is going to happen is that someone (two years from now) is going to change a 'person' parameter from legacy SSN to database id and some users are going to get "you don't exist" when they show up at the hospital to get medical service.

You're right though, most folks in the JS/Ruby/Python ecosystems don't do this kind of testing. It's a recurring joke:

https://www.google.com/search?q=2+unit+tests+0+integration+t...

As for frameworks in the languages you listed...

Ruby and Python: https://github.com/HypothesisWorks/hypothesis

Elixir and Erlang: https://github.com/proper-testing/proper

Node and JS: https://jsverify.github.io/

As for real world use-cases, imagine you’re writing a program that accepts timestamps as input and has to implement branching, requirements-defined business logic based off of them. When you’re writing your unit tests you can use the requirements to select timestamps that are “known good” and “known bad”, but it’s hard to explore this state space on your own.

Same thing goes for handling unexpected inputs to certain functions. You probably don’t want to check _every_ type of input for _every_ dynamic function, but it might make sense to make sure that certain “entry points” to your program fail in the expected manner when they get poorly typed input.

Sure, but you need those tests anyway to verify that your code actually works. I agree that type systems reduce the occurrences of some classes of bugs; I'm only disagreeing with the claim that they reduce the amount of tests you need to write.

I recently ported some (quite complex) code I wrote from JavaScript to Typescript. The code has about a 2:1 test to code ratio, and a fuzzer for correctness. While porting, I ended up adding a couple “useless” assert(typeof x === ...) calls to quieten the compiler, which felt useless because my code was correct. Lo and behold, the assertion tripped in my test suite - apparently I was sometimes treating a string as an object and didn’t notice. Which was a serious issue; and could end up being a security problem for some people. My fuzzer didn’t find it because it never occurred to me to add string method names in my random data generator.

Generally I find that the bugs that are easy to find with tests and the bugs that are easy to find with static types are different. You can eventually find all bugs with a sufficiently large test suite; and with enough PhDs you can apparently formally prove everything. But you get the best bang for buck with a little of each. A few tests is much better than no tests. But in the same spirit, I find no matter how big my test suite, there’s a good chance static types will improve my code.

Typescript is far from perfect, but I sleep better at night with a type checker checking my code.

I don't think we disagree much. As your experience shows, trying to replicate type checking via unit tests is almost always impractical. Which means the tradeoff of not having static typing is not that you're writing more tests, but that there's an increased chance of bugs.

And I agree that once a JS project is large enough to have a build process, the benefits of TypeScript almost always outweigh the costs. I'd even like to see JS interpreters allow and ignore TypeScript types, so you could use it without a build step.

Why would you design a function in such a way that one of the arguments can represent so many different things? The problem here has nothing to do with testing. The problem is that the function itself is poorly designed.

If anything, the difficulty of writing a test for such a function would in itself be an indication that the function needs a refactoring.

We're pretty deep down in abstract discussions here and I have no idea what your code looks like or what it does, but I think it's helpful to point out that knowing the type means you already know the contents to some extent.

The way I see it, checking if a value is what you expect is always good, but if you additionally get an error automatically because your number is now suddenly an e-mail address, or the function you wrote that expects phone numbers suddenly gets a name instead, in my mind that's "built in testing". It doesn't make other testing unnecessary but it sure raises the bar for cleanliness -- which is especially useful when you're working with other components that aren't JS where types do really matter (like databases, for example).

Idk about you, but when I’m sussing out the behaviors of a complex application it can take numerous iterations over different possible types and shapes of the data in order to come up with something both robust and performant.

The single greatest benefit of languages that afford static analysis is that, when I change the shape of some piece of data where it is defined, my editor lights up like a Christmas tree and informs me of every place in my code that was just broken! This is extremely useful for being able to quickly iterate on features. I don’t have to remember all of the calls sites dependent on some API. It allows me to confidently make (sometimes large) changes to my domain and know for sure which pieces of code might also need to be refactored.

I’ve worked in codebases where the confidence I’m describing above does not exist, and what happens is a lot of defensive programming and wasted effort (and time!) dancing around new implementation because no one wants to change anything. Changes tend to become “append only” (we can only add to the interface) because it’s hard to know what’s going to break if you actually change it. This can be okay most of the time, but sometimes new requirements... well... require new approaches.

The above is related to “testing” insofar as I don’t need to test where pieces of code depend on one another in order to know when their contract breaks. But the benefit is not really about testing at all. It’s about work flow. It’s about velocity. And it’s about freedom.

If such (refactored) method is being called from code that's not covered by tests, the bug may not be discovered until it blows up in production. With static typing it would be caught at compile time.

Well there's your problem :p

I agree that if code has no tests, it's more likely to be correct if it's in TypeScript than JS. But I don't consider that an acceptable bar, so if I'm doing your code review I'm going to ask for tests in either case. And once you have tests that verify the behavior of the code, you're not getting much incremental benefit from type checking.

No unit tests needed to show that it is balanced :-)

Usually what I do is that once a project has reached a point of maturity and the requirements merit it I move parts of it to a typed language (go). That’s for things that need to be both performant and maintenable long term without much effort.

I actually benefit from that rewrite in that I have yet another chance to review assumptions and address higher order

I don't understand what that means. How is TypeScript removing friction between JavaScript and tooling? That doesn't make any sense. TypeScript is a typechecker and a language that compiles to JavaScript.

I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous to me and cumbersome and makes certain dynamic programming concepts difficult or impossible. I don’t want to give up power just because other developers are sloppy.

I want my code to be readable, and succinct. A lot of times that requires creating functions dynamically at runtime or some other such thing that would void the benefits of a typing system anyways.

I recognize that in working with a team where people have other styles, varying attention to detail levels and skill, they can’t all be trusted to produce bug-free code without the constant nagging and overhead of a pedantic type system.

My solution is not to employ another piece of technology to solve this problem, rather it’s just not to work with those people.

If you can’t write dynamic code without a bunch of type errors at runtime, learn to be a better programmer first before blaming the tools.

How many times has six-months-hence you cursed you for this attitude?

Be honest.

So you could be leaps and bounds better than me. Or you could be--let's be generous and call it "optimistic to a fault"--and retrofitting to a narrative about Good Programmers Don't Need Guardrails. And, TBH, I see a lot of people who are the latter and very few who are the former--and most of that very few tend towards statically or at least optionally typed languages by default. So forgive me if I don't believe you.

Will you in two years? Will your coworkers? Will the contractor who has no context for the code understand it?

Like variable names, types convey information that are crucial to the understanding of your application.

Under the hood, there are "types", even if they are weak, so you'll need to know about implicit typing anyway. Making them explicit is both a way to test correctness and a way to document your code.

Meanwhile: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

'Percentage of memory safety issues has been hovering at 70 percent for the past 12 years.'

And this is not just Microsoft–it's a pretty consistent finding across industry, that when programming in C/C++, memory safety issues make up around 65% to 70% of all issues.

What this tells us is that people in general can't guarantee the safety of their code, but an automated checker can.

And I suppose when those requirements never changed you never had to rewrite lots of these perfect functions or resort to “append only” programming in order to make sure regression was impossible instead of making large changes in place.

Forgive me, but it’s clear you have never worked on a program of any consequence, so it’s hard to read your comment and do anything but wish you the best while also completely ignoring its content.

It's like trying to convince experienced motorcyclists that you don't need a helmet because you're quite the driver. It's just defensive driving, people! That the helmet is some sort of crutch you've transcended, and maybe if everyone had a bit more skill -- like yourself -- they'd understand.

Yet it always seems to be half of the dynamically- vs statically-typed language debate.

That sounds fine, as long as no-one else will ever have to read or work on your code.

On these projects you often find yourself needing to work on higher levels of abstraction. Types help here by instantly telling you what the data is and providing hints.

Types take extra time to write and maintain, but they significantly reduce the difficulty of working on large projects.

Can you say the same about all your dependencies?

I and most people however are human and make mistakes sometimes. Worse, the bigger the project, the more you need to collaborate between people and sometimes teams. Types are almost like docs that check your code at compile time and reduce the chances of human error creating a production failure. Its not a panacea but its certainly nice to know that if I change a functions parameter, that the system breaks someone else's code depends on that function following a certain signature. At that point, I can either write a different function, message him to update his code or discuss how to make the changes together. All 3 cases are MASSIVE upgrades over fiding out shit broke in prod with some undefined behavior arising.

The only perfect decision I made is to accept that I make imperfect decisions, I wish I could attain the consistent perfection that you describe here.