This is just cargo-culting static typing: "If I avoid dynamic typing at all cost, the cargo crates will surely rain on down!"
You'll find that picking a language is more of a business decision than the sort of technical static-vs-dynamic checkbox test you might use to pick the language of your next weekendware.
This kind of absolutist rule of thumb is more flame bait than morsel of wisdom.
If a company is small and/or has to rely on freelancers it goes with dynamically typed languages (PHP, Node, Ruby, Python and Elixir) because that's what the bulk of freelancers use.
If they have many internal developers or use big consultancy firms they go with Java or C#.
Of course there are exceptions (I know a few of them) and my point of view can be biased because I use to see projects and developers of dynamically typed languages.
But I know a few small companies with a code base in Java that had a hard time at finding Java freelancers. Almost all of them are employees, unreachable for them.
Want an easy concrete example? You and your cofounder have 10 years of Ruby experience and investors/customers who want a product yesterday. Or the deliverable that makes most sense is a PHP script that users can drag into CPanel because that's your customer base.
The tinkerer inside you always wants to try new things and convince you that some greener tech on the other side of the fence are going to make the difference. It's usually just procrastination from the actual hard stuff: building things people want, today.
True but facile. Sure, for every imaginable technology, there is a conceivable scenario in which that technology is the right choice. Doesn't mean there's no such thing as a good or bad technology.
> The tinkerer inside you always wants to try new things and convince you that some greener tech on the other side of the fence are going to make the difference. It's usually just procrastination from the actual hard stuff: building things people want, today.
That's actually an argument for being more absolutist about the technical side: you're unlikely to be in the obscure circumstances where a dynamic language would actually be helpful, and even more unlikely to have that be more important than your business decision. So rather than carefully considering your circumstances and weighing up the tradeoffs, it's better to follow the consensus for what's a good general-purpose language (which these days means a statically typed language) and get on with building your business.
I'm sorry, but cleaning your windows with Windex instead of tap water is then "not any better if business trade-offs make tap water better". I am just not sure what you are arguing for: Static typing is better, except for when you don't have static typing?
Some folks here are in the position to choose their current, or shape a collective future landscape, and for those static typing is a consideration.
You mention PHP a few times, but I think this is actually a good example for something that has been pushed away in favor of better things. My impression is that at least the bigger software corporations have moved away from PHP if they ever used it to begin with. Even Facebook, one of PHP's biggest users, replaced it with their own so-named "Hack" eventually, which is apparently a PHP-derivate with "both dynamic typing and static typing" according to Wikipedia.
This is a forum for engineers (not only, I know), who collectively will at least have a large part in steering what languages are considered common in future.
Here is a comment from 9 years ago. It sounds like parody to me and demonstrates how echo chambers eventually deviate from reality. HN can often be an echo chamber
> A good programmer should wake up at 6 am in the morning get a solid 2.5hrs of coding done by 8:30 am, at 8:30 leave for work, work till 6 (it goes without saying that the lunchbreak must be spent trying to learn the Haskell or if you are feeling lazy answering questions on stackoverflow). Commute from 6 to 6:30 (it's a bonus if you listen to a technical podcast during this time and no stuff like TWIT does not count, perhaps audio lectures from the Advanced Algorithms course on MIT OCW). 6:30 to 7:00 time for supper and excellent time to catchup on r/programming and hackernews. 7-8:30pm is the time for relaxation by doing some recreational mathematics, doing problems from project Euler and that proof from The Art of Computer Programming excercises which you have been itching to get a go at! 8:30pm to 1 am code contribute to that open-source project, write patches for the Linux kernal and continue working on your startup.
> Anyone who does less programming that what is mentioned above cannot call himself a "good programmer", I would have serious reservations in calling that person even a mediocre programmer.
--
It is a parody, isn't it?
I don't use technical recommendations from HN users because they consistently underestimate pragmatic concerns because the HN echo chamber overvalues technical virtuosity so real world pragmatic concerns get drowned out by other voices.
I was a diehard fan of dynamic languages for a decade, but eventually I saw the light.
I still use dynamic languages daily, but the bigger the project the more I want proper static typing. None of that mypy stuff, the real deal.
I have a 20k LOC distributed system, 40k if you include all the libraries I've written for it, running in prod, written in a (typechecked) dynamic language, and it's fine. I had very few typing errors in dev, and one typing error that I pushed to prod. Even this had no discernible customer effect. I discovered it months later when I was checking over my logs understand logical errors. Currently all of the reported errors are race conditions on startup (and sporadic network errors). But it's fine. The system tolerates it, and restarts the failing modules, instead of being pedantic, and so instead of spending weeks debugging concurrent startup, I get a no-hassle fast booting system (which also means nonblocking bootup and thus higher customer availability during failure and restart). The other nice thing about dynamic systems, is that if they're not otherwise terrible, (logical) debugging is a breeze, because all types are inspectable and I don't have to worry about implementing observerability hooks for every single datatype. I can just look at the data as it moves through my system. And that also means that telemetry and logging with structured metadata just "happens", and is highly composable with no hassle.
I guess my biggest problem with static typing absolutism is that it leads to this attitude that code can be correct. It can't. Even if it's provably correct (in the mathematical sense), if your axioms are violated by your system then your system can wind up in an undefined state. You must plan for failure. And sometimes the most efficent/effective plan is "do nothing".
Yes, and if your hardware is broken or a cosmic ray hits your system in just a bad way, then all the static type checking in the world won't help against that. But that's a different problem to solve, isn't it?
I'd postulate that for most applications, you'd usually be happy to have a software stack that's less likely to contain programming bugs in the first place. It's also true that you don't want faulty Airbag software in your car to affect your steering, but don't you want non-faulty Airbag software as well?
You still drive value based on how much of the correctness checking you can offload to the compiler.
I don't really get why programmers better than anyone understand the value of automating work with a computer, but fail to grasp that value applied to their own craft. Let the computer do more of the work in making sure your program is correct.
After seeing how much I got wrong in Python (but apparently worked) I realized I couldn’t really trust myself (even after a decade in Python!)
I will say from exp. that @anyfoo has a point. In the end, even webapp backends are clients, worker nodes within a much larger system infra. Anything that has to do with data that isn't a pass-through entity ideally should be both strongly and statically typed.