The focus of industrial development for a long time has been focussed on the processes, or the verbs, not the things, or the nouns.
Focusing on the Nouns and the types of those Nouns lets you understand what states they can be in and more importantly, the ones they cannot be in. By using types as much as possible to express those invariants and constraints, you can make sure that the processes don't do something that they shouldn't.
Proving software correct is a very complicated and, as yet, unsolved in most practical cases. Strong typing and strong type systems are a step in that direction.
If a compiler ensures that a sum type's possible values are always exhaustively matched, then you can be sure that the processing at least considers all of the possible values.
That leads to positive results when programming.
If you use Option types and then ensure that the None type is handled, the possiblity of nulls is dramatically reduced, if not eliminated.
If immutability is enforced, that removes the possibility of inadvertent modification, especially somewhere deep in a call stack. That leads to safer concurrency, which is an absolute requirement for using the compute capacity to its fullest extent.
Strong typing like this isn't "overwrought", it's making sure that your code doesn't do something to a thing that it shouldn't do.
As long we can both agree, that at an elementary level, it's faster to write code in a dynamic language, than it is with a strongly typed one, then there will always be a trade-off to consider. Like the trade-off between using glue and nails.
Being able to change things quickly, or describe things creatively is occasionally going to be more helpful than immutability guarantees in some product domains.
That practical focus is the very reason why dynamic languages are so popular. They facilitate rapid iteration, which is a quality which also certainly can lead to positive results when programming.
A focus on 'process' is really an understanding that the 'noun' is subject to change, as requirements so often do in engineering and product development.
I suspect the modern dynamic languages are a response to this focus on practicality, with Ruby probably being one of the bests illustrations of this idiom (I don't write much Ruby at all, but respect it for what it is).
However, this purely practical focus is not always the most desirable quality in a programming language, and in those domains where you know your requirements are written in stone, then an effort should be made to describe requirements as formally as possible.
But a myopic preference for only one approach to writing software, will probably introduce some flaw into your program, no matter what language you are using.
Every single language is an abstraction after all.
We moved away from Assembler in an effort to focus attention on expressing what tasks computers should perform. Dynamic languages are a logical result of that focus.
Type hype is real. It almost seems like job-creation propaganda at this stage.
When I judge things, I look at practical outcomes; and the fact is that I produce better software with more features within the same timeframe if I use JavaScript rather than TypeScript and the product in both cases is equally robust. This has been true for me both independently and as part of a team.
With JS, I can write more code and more tests within the same amount of time and there is no drop in quality.
I'm very surprised that nobody else seems to be experiencing the same thing. I've been back and forth many times between the two paradigms and for me it's clear as day.
Sorry anecdata isn't data. You might be able to write more code in terms of LOC but you're also writing tests that a strongly typed system wouldn't need.
You don't know that your code is "equally robust". You don't know what sort of "drop in quality" you have because you're not using strong types.
You are making a judgement that isn't backed by anything other than intuition.
I switched my Javascript code base to Typescript a few months ago. There is a productivity cost that is declining over time as I get more used to Typescript. But the conversion also flushed out some significant bugs in the JavaScript base.
And I only get to work on this code once a week. So when I come back to it I’ve found it’s much clearer how it works and I get productive much faster.
I will bet any coworkers who have to work on your code wish it was in Typescript.
This doesn't conform with any of my experiences in non-trivial JS codebases. Migrating to TS tends to reveal previously overlooked implicit typing issues. Also, I find the "upfront productivity loss" of TS to be overstated: adding in annotations here and there doesn't take much time at all, and pays dividends quickly. Many hours have been lost tracking down some elusive runtime bug stemming from a typo in a vanilla JS property access.
Programming languages and their type systems are tools, at the end of the day.
Occasionally, an overwrought system of types will slow you down, or quite possibly make simple changes impossible.
On another day, some other type declaration could save you hours of debugging, or speed up your program by orders of magnitude...
Simply put, I feel that many Java programs probably could happily be replaced by Python or Node JS.
On the other hand, some safety critical UI projects (or at least, some key portions of them) absolutely would benefit from Typescript or Elm.
I wish there was more discussion about when each is a better fit, rather than talking about how much worse A is than B.