TypeScript and Python 3 support gradual typing, so code can be optionally annotated with types. This makes refactoring easier, while still benefitting from how you can quickly sketch out new code dynamically and only annotate it once things start to solidify.

Personally, I'm a fan of very strong, static type systems, so I would prefer to annotate all the things, but I understand other people have different views.

TypeScript probably wouldn't call itself a dynamic language.

From what I understand, everywhere that you would need to write a type, TypeScript allows you to either not declare a type at all, or put "Any" and avoid declaring a specific type. I think you can even go so far as to rename a ".js" file as ".ts", and it's fine, which is a great example of "gradual typing", and I think this all makes TypeScript a dynamic language.

It's statically typed with opt-in dynamic (which is opt-out implicit). Sans the implicit opt-out, this is identical to C#.

If you don't specify types at all, is that really opting out? This is valid TypeScript code:

  function foo(a, b) {
      if (a != 3) {
          return a + b
      } else {
          return "hello"
      }
  }
  
  console.log(foo(2, 5)); //prints 7
  
  console.log(foo(3, 5)); //prints "hello"

You can compile it and run it on the typescript playground: https://www.typescriptlang.org/play/

This is not like C#, where would be required to specify that every type is "dynamic". Here, you can optionally choose to specify that the types are "Any", but it's still gradual typing.

EDIT: you said "implicit opt-out"... which sounds like a synonym for "opt-in". I don't think "implicit opt-out" is a term.

The "implicit opt-out" is noImplicitAny[1]. That code of yours won't compile with this opt-out enabled. Edit: the "dynamic opt-in" is `any` (and is `dynamic` in C#).

[1]: https://www.typescriptlang.org/docs/handbook/compiler-option...

If it was really not a statically typed language, I'd expect this code to at least run. But it detects a type failure at compilation time despite the lack of any declarations.

    function foo() {
        return 1;
    }

    let x = foo().substring(1, 2);

> I'd expect this code to at least run

It still compiles the code to JavaScript even with the error, and you can still run it, which makes this more of a warning than anything else.

That warning based on type inference seems like a positive feature... because there's no situation in which that code is right. You can add `: any` to the function declaration and it will stop complaining, but I wouldn't contend that the language is not dynamic because it encourages you not to make a mistake.

The distinction between "warning" and "error" is highly arbitrary anyway. In C++, you also get a warning rather than an error if you, say, return a reference to a local, or read from an uninitialized local. You still get a binary, and it still runs. But these are 100% bugs, which is why most projects enable treat-warnings-as-errors for a lot of that stuff in C++. I'd imagine it's common with TypeScript, as well.

Clojure ain't too bad.. example: https://circleci.com/blog/rewriting-your-test-suite-in-cloju...

How about Smalltalk?

nowadays it’s quite good situation with php refactoring, given that php now allows type-hinting and if you keep type-hinting variables with phpdoc-style comments, IDE refactors code really well.