歴史的に古くて小さいリソースでしか動かない、逆に時代が下ってふんだんなリソースをフル活用できるようになったおかげで新しく作られた、という発生時の環境によってできること、やらなきゃいけないことが増えたから。
なら、古くて小さいリソースのプログラムなんていらんだろうって?
蚊を殺すのに、ツァーリーボンバーを持ち出すアホウはおらんのだよ。
あとは、同時代に生まれても、必要な、と言うか中心的な抽象レベルが異なるために、「理解できないエンジニアには使えない」って言語もある。
適切に抽象化ができるエンジニアは、リーナストーバルスもいうように、エレガントに問題を解決できるし、そのために都合がいい機能を持った言語を使う。そうでなければ物量(if文満載の)で一旦動くものを作ろうとして、自分の理解が及ぶ範囲でできることが用意されている言語を使う。
例えばオブジェクト指向プログラミングとか理解できない使えないエンジニアは意外と存在する、とかね。
ワンフィッツオール、なんてありえないくらい裾野というか、版図が広がったシステムの世界だから、プログラム言語の種類は多い。
プレゼンテーション(表示/UI/UX)や構造(ネットワーク、サーバサイド)のような対象によって、規模や(ビジネス)ロジックの複雑度の大中小で使い分けるのが普通だから。
Rustもいい言語だし、でも複雑でデカいビジネスロジックのシステムだったら、複数人で回すのちょっときついな、と思うし。仕様駆動開発で、ってのは、CRUD的で単純なサービス、あるいは初期段階ならいけると思うけど、成長に耐えられる気がしない。かなりのプロダクトで、作って動いてるところは変更するな、ってなりそう。
PHPは、言語自体は軽量で悪くはないんだけど、toBサービスでこれを育ててデカくする、のは限りなく不可能だと思う。デカくなる前に言語を移行するとか考えないと(やり方はある。けど、多分PHP使いはそれを思いつかないし、やり通すことができない)。
golangは……、使い方、使い手による……。
スマホなどのネイティブアプリは選択肢がない。
全部の端末を1ソースで対応可能! みたいなのもあるけど、当然失うものもあるし、それはデカかったりする。
おいらは嫌だ。
いままでどれほど騙されてきたか w
スタート時はね、いい感じに動くんだよ。
そう作られてるから。
でも1年、2年と経ってくると、それぞれの環境間の差が広がりまくりすぎて、辻褄合わせの時間が50%を超えてくる。
それを見越した設計実装ができる人もいるけど、むちゃくちゃ少ない。
どんなプログラムも、デカくしすぎないで、移行可能に作っておくしか、時代の変化についていけない。
それは工学の基本中の基本である「分割統治」の考え方そのものなんだよね。