The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbitrary inflexibility which ends up rippling through a code base.
And the little problems are better solved in other ways. E.g., unit tests and the like catch type errors on the way to validating that your code actually does what you think it should do.
Static typing also isn't useful when dealing with data that moves through distributed systems. You know, like pretty much all the data. The static types you had at compile time are fundamentally not related to the data you are processing at run time and static types don't equip you to deal with that very well. Systems map "wild" incoming data to the internal static types but the static type environments strongly encourage this to happen early, which is often not the right place.
Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.
This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
if true then 1 else "one"
As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.
It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true.
Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc.
protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system.
But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data.
Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools.
Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.
To put it another way, it's like throwing a frontend developer into the world of C. Suddenly you have to be aware of and correctly manage your memory explicitly, whereas before you were safely protected from having to think about it.
Lastly, not everyone can voice their opinions so well. Communication is a difficult thing, and understanding what you're trying to communicate more so. If someone says they hate something, it's not always baseless. Instead of jumping to name-calling, have more patience in trying to understand why.
the second point about being more understanding surely applies more to the person proudly hating a language with no constructive support about why, and little evidence of an effort to overcome the language's obstacles. sure, i dont know everything about this person, but i take the comment at face value, which seems to be the norm. maybe calling them out on it isnt helpful? i dont know, but it didn't seem that bad.
and yes, people being "forced" to use js is surely contributing to the hate, probably the same way people hate having to use css. they look at them as afterthoughts, but its funny because in a lot of cases, its like the main thing that needs work. i just wonder why people cling to the idea that "real programming" has a certain look, when being good at js and css is super helpful and important to good web projects.
i suppose we are arguing for the same thing- basically open-mindedness and willingness to learn.
The analogy of musical instruments may be appropriate here; I feel that my ability or failure to be productive with a particular set of tools to be an aspect of my identity.
Set me to debugging a C++ or Java class library and I can get to work, but these may not be the tools I would prefer to start with.
Am I a bad programmer? Hmm. Identity can be a fragile thing.
Why would anyone have the motivation to do that? Either it has given them reasons to dislike it, or it hasn't. Why do you think anyone is predisposed to looking for those reasons?
By placing big keywords in your bio like "Serial enterpreneur, haskeller, programming languages design freak, former senior R&D technical director in the biggest film studios in Europe" + "hates java script" and keeping your flag up here makes it look very unprofessional. Of course, who are we to judge if not...your target audience for a "functional programming language", visual or not.
I remember when RoR came out and some  "cool dudes" decided to mock everything else on the planet. RoR vs php, RoR vs this and that. It made me feel sick even though RoR was a big step up from everything else back then. It took me 2 - 3 years to even consider it because of that.