Skeptical of rewriting JavaScript tools in "faster" languages

What have static type systems ever done to you, that you avoid them so much?

most static type systems are verbose, probably due to linguistic verbosity, so one obvious thing that static type systems have probably done to a lot of people is given them pain from typing so much.

I don't feel it's so much typing. Especially for the clarity and, most importantly, safety and correctness I get back. I'd rather type 3 1/2 seconds more than debug a dumb type issue for half an hour.

It gets really old to get something like "NoneType does not have blah" in a deeply nested, complicated data structure in python, but obviously only at runtime and only in that hard to hit corner case, when all you did is forget to wrap something in the right number of square brackets in some other part of the code.

I haven't fully given up on python, but I only deal with it using mypy, which adds static typing, anymore.

Not the OP, but the appeal of languages like JS has a lot to do with developer productivity. I write gobs of JS and Python code and the finished programs and libraries can be strongly and statically typed end-to-end. I just don't want to be forced to do it in cases when it doesn't really make a difference, and I don't want to waste time on it when I'm still figuring out the design.

My hope is one of the Next Big Things in programming languages is the widespread adoption of incremental typing systems.

So during the early stages of dev you get the productivity benefits of dynamic and loose/duck typing as much as you want, and then as the code matures - as the design firms up - you begin layering in the type information on different parts of the program (and hopefully the toolset gives you a jump start by suggesting a lot of this type info for you, or maybe you specify it only in places where the type info can't be deduced).

Then those parts of the program (and hopefully eventually the entire program) are strongly and statically typed, and you get all of the associated goodies.

A bit of extra verbosity as added by static typing can also be immensely helpful for trawling through and/or learning an unfamiliar codebase, especially in the absence of an IDE or debugging environment (e.g. browsing code on GitHub or in a filemanager).

For instance, take function definitions. By just adding types to the function's arguments, you're potentially saving the reader a ton of time and mental overhead since they don't have to chase down the right the chain of function calls to figure out what it is exactly (or is supposed to be) that's getting passed in.

Not sure what languages you are thinking to with "most static type systems", but in languages like TypeScript or Rust (and I guess modern Java/C#, haven't touched those in a while), most of the types are inferred by the system such as you don't need to write them. You type your functions arguments (and return values in Rust) and that's about it.

Ok I was thinking Java / C# which I haven't touched in a while either and they were verbose, Typescript may be able to infer types but every place I've used it we write just everything out, and as such there is quite a lot of extra declaring of things that could be inferred, that may be cultural, but it seems pretty ingrained culture.

When it comes to static typing itself, I only have a minor philosophical objection to it and it's subtle enough that it wouldn't (on its own) prevent me from embracing it. The issue I have is that it generally doesn't align with my coding philosophy which resolves around simple function/method interfaces.

My focus is message-passing, as opposed to instance-passing. Passing around instances can lead to 'spooky action at a distance' if multiple parts of the code hold on to a reference of the same instance, so I avoid it as much as possible.

The main advantage of static typing is that it helps you to safely pass around complex instances, which I happen to avoid doing anyway. So while I don't see static typing as inherently harmful, it offers me diminishing returns as my coding style improves.

In JavaScript land though, TypeScript forces me to add a transpilation step which forces bundling of my code and adds complexity which causes a range of really annoying problems in various situations. As people like DHH (founder of Ruby on Rails) have shown, we have the opportunity to move away from bundling and it yields a lot of benefits... but it's not possible to do with TypeScript in its current form.

It's particularly difficult for me because I actually like the syntax of TypeScript and its concept of interfaces. Interfaces can be consistent with the idea of passing simple objects which serve as structured messages between functions/components; rather than live instances instantiated from a class. I can treat the object as named parameters and not hold on it.