Hey look, another thing Uncle Bob was completely wrong about. It's telling that after using "we" to set up the initial question, literally every pronoun in the article where he waxes on about testing is a personal pronoun. He never mentions "...And my colleagues found it easier to understand my code", or "and people found my library more inviting".
As TIOBE uses averaged, relative search engine hits for "[programming language name] programming" as its source, it's a significantly lagging indicator, since it counts all pages on the internet equally, regardless of their age. I'm also unsure of the precision of the search "C programming". I suspect that it's catching "C++" in some search engines.
Stack Overflow's annual survey puts JavaScript, SQL, and Python at the top, with C at 12th [0]. RedMonk's Top 20 puts JavaScript, Python, and Java at the top, with C in 10th [1]. ITJobsWatch puts JavaScript, SQL, and C# at top, with C at 9th [2]. Dice puts SQL, Java, and Python as its top 3, with C not even ranking in their top 12 [3]. All of those put JavaScript, Java, and Python in the top 5.
I broadly prefer JavaScript to TypeScript. TypeScript has it's place and is certainly useful in some scenarios (it's union type is so powerful) but I don't think I'd ever plan on coding exclusively in it. I've written code in OCaml and Rust too so I know what a good type system can do.
I think at least for UI work there is a lot of space for dynamic plumbing together of well typed components. Components in this case meaning actual UI components as well as modules of business logic or state management.
It's pretty strange that articles comparing static vs dynamic rarely mention team work. For example, we work on a feature, several engineers, everyone in their own branch, with always changing requirements and a lot of experimentation of course. From time to time I have to merge their work to the main branch. In PHP it was always an adventure because merge errors and conflicts (including some very silly ones) are often caught too late at runtime after the whole CI/CD cycle, and then you have to go again. Sure there are tests but they don't cover everything (and it's a nuisance to cover 100% including infrastructure layers if you are in the experimentation phase). PHP has linters but they're very slow and complicate the process. Now that we've switched to Go, merging (and generally team work) is a breeze. The compiler catches all problems immediately, our development time is much shorter now as we don't have to go back and forth with runtime errors.
This has never been an issur for me in my 13 years as a professional programmer, most of those in static languages. I prefer static typing due how it encourages good design and how in good static typed languages like Rust it id almodt always true that if something compiles then it also runs. But, no, merge errors have never been an issue for me with either dynamic or static.
I don't know why but I almost never experienced this as a big problem, especially with the current fashion of building independent services that don't grow too big. Maybe you guys are all working on the same files at the same time which is never fun?
I'm not saying what you're describing can't happen I'm just saying to me it's rare and I work with Ruby and plain JS.
