Borrow-checking without type-checking

> Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

No, the real actual problem is with invisibility aka: the absence of readability:

In a "dynamic typing" program the interpreter knows what `a` is but YOU not.

In very strong sense. You can imagine that `a` is a `int` because, well, you write the program, right? But in fact, is only probabilistic assumption.

Some day, `a` will be a program that delete the files of your computer.

There is no consistent definition of the term "weak typing". Do you mean implicit coercion?

> Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

Ironically, I would counter that, in my experience, most people who have a problem with static typing actually have a problem with verbose type systems, like Java's or C++'s — or Rust's. (Rust is at least gaining something for its verbosity.)

Type inference is a neat way to bridge the gap. OCaml, Haskell, and Swift (to name a few) all feature distinct type inferencing that give you the benefits of static types without as much syntactic overhead.

The standard complaint of pointless type errors that static type analysis would catch has nothing to do with weak typing, nor does the other one about unreliable listing of available ops in your editor by pressing `.` and looking at the autocomplete list. If you think the only thing people think is wrong about dynamic typing is JS `==` then you are swinging at a strawman from a decade ago.

Dynamic typing doesn't scale in large teams, it is however great in small projects, or if optional typing is supported, which took a long time to learn from languages like structured BASIC dialects.

It is no accident that all mainstream dynamic languages now have optional typing support, either in the language directly or via linters.

Sorta? Python has fairly strong types but it's no fun debugging a `None has no attribute foo` error deep inside some library function with a call site 1000 LoC away from the actual place where the erroneous None originally arose, due to a typo.

It's not just Python too, I've hit the same issue in Common Lisp.

Yes one can run contracts and unit tests and static analysis, but what's a type checker anyway other than a very strict static analysis tool?

Yes to dynamic typing. Yes to static analysis.

Technically, in a type theory context, there’s no such thing as “dynamic typing”. Types are a static, syntactic property of programs.

The correct term for languages that don’t have syntactic types is “untyped”.

> Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

All people who say things like this have never studied computer science.

Dynamic typing is no typing.

The point of types is to prove the absence of errors. Dynamic typing just has these errors well-structured and early, but they're still errors.