Different tools serve different purposes, yes. However, some tools have much narrower uses than others. For instance, most developers agree that writing program

Different tools serve different purposes, yes. However, some tools have much narrower uses than others. For instance, most developers agree that writing programs in assembly language is a very bad idea for about 99.9% of programs (1 out of 1000 - which is generous). And, from both empirical evidence, and reasoning from first principles (stringly-typed, quoting and escaping issues, lack of tooling, low performance, implementation-defined behaviors, poor ecosystem, try-to-continue instead of fail-quick design), we can see that shell is entirely unsuited for everything except interactive use. Moreover, "time to write script" by itself is a bad metric, for several reasons: (1) the cost of understanding and maintaining the script is ignored (and obviously higher for bash than Python) (2) you're not including the higher likelihood of bugs in your bash programs (and all it takes is a single bug that requires 20 minutes to find and fix...) (3) if you had more experience with Python (or with specific libraries useful for writing shell-script-like things - this often goes overlooked) then your development time would probably be shorter and (4) the pool of Python devs is far greater than the pool of bash devs. > Passing around strings...[is] extremely flexible when you need flexibility This isn't accurate. Passing around typed data is just as flexible as strings - except that it adds a bunch of extra safety and type-checks. All data in "string" format, with the singular exception of actual English text that is being passed to an NLP system or something, is actually in a structured text format (the operations that you perform on which are merely isomorphic to existing operations on structured data)...that is very likely under-specified relative and more brittle than actual typed data. All that using a string representation does is make errors easier to make and harder to find. > And fwiw I'd bet a majority of the software you listed uses bash somewhere in either their build process or SAAS stack. Yes, because bash is a (bad) habit for tooling devs, not because it scales well or adds safety/performance/maintainability - as evidenced by the fact that there aren't any large pieces of software written in it. That is - bash is used "somewhere" and not "everywhere" because you can only get away with it at small scales - at large scales, it just falls apart.