地味な技術は古いのではなく、成熟している！その理由とは？
引用元：https://news.ycombinator.com/item?id=43012862
個人的には、退屈な技術って素晴らしいと思うんだ。自分が作ってるSaaSアプリでは、実際のプロダクトに関する先進的なことに集中できるから。データベースやバックエンドフレームワークみたいな裏方の部分は退屈で安定している方がいい。時間が限られているから、興味深い新機能に集中したいんだ。結局、顧客はNodeとDenoの違いや最新のバージョンについて知らないけど、アプリがどう動くかや機能についてはすごく気にするから。
その通り。これを知っているのは年配者だけで、若者はあまり意識してない。何度も同じ車輪を再発明してきたから、もう車輪のことは忘れて、ユーザーの問題解決やお金を稼ぐことに専念したい。一方で、新しくてすぐに廃れる技術を使う同僚がいて、プロジェクトに苦労をもたらすんだよね。
個人的に好きなのが、数十年の古いアプリを年以内の新技術で完全に書き直そうとする人たち。新しい技術は必ずしも生き残らないし、問題点やトレードオフもわからないまま。製品に使われてないときは、すべてが完璧でバグなしに見えるけど、実際には後で破滅を見ちゃうことが多い。
これは、>「すべての新しいソースコード！まるでソースコードが錆びるかのようだ。」を思い出させる。
Joelが完全に書き直してブログに載せたことを思い出してほしい。>「新しい言語で書き直せないわけじゃなくて、少しずつ進めるのが良い。」というのが本質。大きな変更を一気にやるのはダメだよ。
25年前の記事なのに、今の時代とまるで変わらない内容で、時間の試練に耐えたって感じだね。
ただ、やっぱり技術は周りの変化に影響されて劣化するんだよ。
だから、もう誰かのプラットフォームには乗らないことにしてる。これからは、自分がデプロイできる退屈な技術だけを使うよ。
皮肉なことに、Joelの”FogBugz”は後で再作成されているから面白いよね。
それは皮肉じゃないよ。能力のある人は制約を知ってて、ルールを破るタイミングもわかってる。良いエンジニアリングは、適切な妥協をすることだから。
数年前に経験したことがある。データが数週間ごとにランダムに消えるシステムでコンサルタントとして雇われたんだけど、エンジニアチームが古いJavaアプリをAWS Amplifyで再構築しようとしていたんだ。テストもパイプラインもなく、環境変数を間違えて開発することもあった。結局、データを消してしまう原因は、debuggingで本番環境にアクセスしたエンジニアが切り替え忘れたことだった。全くの悪夢だった。
新しい技術が成熟して退屈になるには、そういう人たちが使う必要があるのは、寛容に考えると理解できるよ。その尖ったところに捕まっちゃうのは、後のためなんだから。その犠牲に感謝しなきゃね。
新しい技術が本当に価値を加えるなら、古い技術を置き換えるべきだと思う。でも、過去に「クラウド」に飛び込んで、ただ古いものをそのまま移した会社が多かったのを見てきてるから。技術的負債に苦しむ人が多いんだ。>「ブロックチェーンをどこかに使いたがる人が多い」みたいな話も多かった。
完全に同意だけど、クラウドを退屈じゃない例に使うのが面白いよね。HNの人々は、EC2に直接ホスティングするのは冒険者だけだと考えていると思う。
確かに、そのくらい流行ってた頃の例だったね。
あの動画、懐かしいね。Low code fallacyやクラウドに関する良いコンテンツってあるかな？
そうだよ、誰かが最初にならないといけないんだ。でも、それはあなたじゃなくてもいい！新しい大きなプロジェクトを任されたら、試したことのあるツールを使ってどうにかするべきだよ。他の変数がたくさんあるんだから、リスクを増やす必要はないよね。でも、そういう挑戦者がいるのは嬉しいけど、私も一緒に働きたくはないな。
理想的には、フレームワークのコードは既存の動作する製品から派生して、役立つから分離されたものであるべきだよ。フレームワークのために作られたフレームワークは、最初のアプリ開発者を引き寄せることを期待している。
確かに、Symfonyは1.xの頃からすごく良かった。昔のPHPがそれほど嫌ではなくなるきっかけだったし、どの製品から生まれたかは覚えてないな。
＞あなたの持っている、試したことのあるツールを使ってどうにかするべきだよ
ハハ、そうだね。でも、上層部がS&P 500から追い出されたトップマネジメントで構成されていると、彼らはいつも別の会社の試したことのあるツールを前提に決めるんだ。今のエンジニアリングスタッフが持っているハンマーじゃないんだから…。ビジネススクールの卒業生には拍手を送ってるよ。
もっとコメントを表示
＞多世代古いアプリのグリーンフィールド再構築について
「多世代古いアプリ」とはどういう意味かによるね。ExcelもWindowsも多世代古いアプリだ。でも、どちらもまだ開発が続いていて、新しい機能が追加されている。それが新鮮さを保っている要因なんだ。20年間放置された多世代アプリは、再構築が必要だね。おそらく、あなたが言いたかったのはそういうことじゃないかな。
Excelを書き直すっていうプロジェクト、たまに見かけるよ。”ExcelはXで書かれているからクソだ、俺は賢いから、ブラウザ専用で新しいフレームワークを使って書き直す、マイクロサービスでKotlin/Rust/新しい流行の技術を使って、AWSのベータ版を利用する！”って感じだね。で、Excelの新機能の開発を止めるから、開発チームの80％をくれって言うの。ところが、彼らは俺が決めた技術の使い方を理解してないから、彼らも解雇しなきゃならなくなる。特別なスキルを持った人を雇わなきゃいけないし。
最終的にはCOBOLは死んだと認めて再構築する必要があるけど、いろんな選択肢があって、コアロジックを変えずに少しずつレガシーコードを取り除いていくのが一番かも。UIのリニューアルももっと頻繁に必要になってくるよ。
COBOL2023がリリースされて、クールなツールVisual COBOLも出たんだ。LLMが実行可能ファイルを直接生成できるようになったら、プログラミング言語の価値は薄れるだろう、それが新しいアセンブリ言語になるから。
＞最終的にはCOBOLは死んだと認めて再構築する必要があるけど。
それってどういう意味？TIOBEはCOBOLを19位にランクしてるよ、Rubyよりも上に。
TIOBEはプログラミング言語がr/programmerhumorのミームに出てくる回数を数えているのと同じくらい無意味だよ。これよりいいリストがあって、COBOLはトップ20にも入ってない、Rubyは9位だ。
人気があるからといって生きているとは限らない。COBOLは昔は革新的だったが、今となっては悪いアイデアも多い。別の言語に切り替えるのは非常に困難で高いコストがかかるから、使われ続ける。
それに、COBOLはSwiftやKotlinよりも人気があるからね。
ハハ、Steve。これは痛々しいほど正確だね。ミーティングにいる気分だよ。
今やWindowsがその良い例とは思わないな。むしろ、新しいフレームワークでUIを再構築することで、機能を失ってしまったから、それこそが言いたかったんだ。
自分の知識で、何人かの関係者のその後を語れるよ。特に、80％の売上を上げてたクライアントが別の会社を見つけたせいで、約100人が職を失った事件もあったし。
君の言い回しだと、Greenfieldの書き換えは常に間違いみたいに聞こえるけど、プロジェクトによってはそれが唯一の現実的選択肢になることもある。例えば、Angularのアプリケーションが技術的負債のせいで小さな変更も数日かかる場合なんてそう。
うちの会社、数年前にコア商品の書き換えに数十億円かけたけど、振り返るとそのままリファクタリングしてもよかった気がする。結局、新しいコードを書いたのに、予測できなかった問題が出て、また書き換えるか、直接リファクタリングが必要になった。
数年後、書き換えたコードベースは元の質に戻ると思うよ。書き換えが必要になるのは、チームの能力が変わる時か、新しい技術でチームが能力を発揮できる場合。本来なら、アプリを細かく分けて進めるべきだと思う。
コードが始まった時から書き換えをした時まで、私たちの会社は成長してきた。書き換えはC++98から始まったけど、今はC++23があるし、新しい可能性がある。
昔、Perl/C++/CORBAからJavaへの大きな書き換えをしたことがあった。3年かけて結局何も生まれなかったけど、あの古いコードを掃除しておくのが良かったと思う。
別の例もそうだけど、2年の書き換えだったと言えるね。全体が終わるまで待たずに、新しいプロジェクトを使い始めるのはボーナスポイントだ。
これが正しいやり方だと思う。だけど、やる人は少なくて難しいから。旧システムと新システムをつなぐ橋を作りながら、徐々に置き換えていくことが大事。
橋を作ることを意識した設計が大事だ。マイクロサービスの大きな利点は、そこに架け橋があることだと思う。モノリスでは、物事を分けるのが難しいし、いつも他の悩みが出てくる。
賛成だよ。でも、若い同僚が流行りの言語を使っている理由は、就職のために学ぶように言われたからなんじゃないかな。面白いのは、こういった古めかしいインフラが、CIOのキャリア向上のために壊されることだよね。
こういうことをしている人には多くの敬意を表するよ。安定を求める人にも同じく。管理者がこういう選択をするのが仕事なんだから。
そういう管理者たちは、成功したらすぐ次の仕事に移るのが賢いんだろうね。成功したと思ったら、すぐに次のところに行く。
ウォール街のテクノロジーでは、2年ごとにリーダーシップの役割を替えるのは普通だよ。世界を約束して、構築して、結果を出せずに次の仕事に移る、そういう感じ。
そうだね。でも、彼らがゲームをやっている限りは、それでいいんじゃない？自己の利益を優先するのは尊敬に値する。
モダナイゼーションって、50年前の技術を’20年前’の技術に置き換えることもあるよね。’古い’と思われる技術はアクティブに開発されてて、実はモダンで退屈なんだよね。
50年前の技術には色々あるよ。Fortranは古いけどニッチで活躍中。COBOLも古いのに今は置き換えられてる。Cは50年以上経ったけどまだ今も使われてるし、C++も進化中。Rustは最新だけど、30年後にはどうなってるかわからないな。
中堅の人たちが知らないか、意識してないことが多いのが見受けられる。新卒が複雑なプロジェクトを引っ張るわけじゃないからね。
自分も中堅だけど、競争が激しいから苦労してる。周りのリクルーターや管理者はあまり分かってないみたいだし。
10年のJavaと5年のC#が必須って求人を見たことがある。当時Javaは8年、C#は3年だったのに、そんな要件で採用された人がいたんじゃないかな。
残念ながら履歴書ドリブン開発が主流で、企業もメンテナンスより新しい技術を優先する傾向があるね。
これは誤った二分法だよ。’最新技術’対’メンテナンス作業’じゃないんだ。Javaで新しいプロジェクトを作ることもできるし、最新技術でもちょっとした改良ができるんだよ。
“若者たち”が金儲けについて気にしてないと思うのは間違い。でも、最近はお金を稼ぐためだけにプログラミングしてる人が多くて、あまり良い結果になってないね。
最近のインセンティブは新技術を学ぶことに向いてるから、FANG企業がそれを作ってるから、みんなこういう技術を学びたがるんだ。
MongoDBやElasticacheをメインのデータストアに使うことには反対してきたけど、結局リレーショナルデータベースに落ち着いたよ。MongoはPostgresに移行できたけど、Elasticacheはもう無理。
ノンリレーショナルDBを使う理由は主にスケーラビリティとパフォーマンス。分散システムでの結合やトランザクションは難しいから、データが大きいときに役立つかな。
大企業はデータを過大評価してることが多くて、実際は何十年前のサーバーで余裕で扱える量だったりするんだよね。
ノンリレーショナルDBを使う唯一の理由はスケーラビリティとパフォーマンスだけじゃないよ。リレーショナルDBが手に入らなくて、自分で作るのもリスキーだから。ただ、タブラー形式のDBが大多数のユースケースに適してるし、理解しやすいのにも理由があるんだ。
再発明するのは学習目的であればいいけど、SQLiteの代わりに提案するのは相当大胆だと思うよ。新しいプロジェクトの中でやってみる分には面白いかもね。
多くの人は面白い新機能に取り組めないことが多くて、顧客に関心を持つ仕事でもない。ほとんどの仕事が退屈だから、少しでも技術的に面白くないと気が狂いそうになる。退屈な技術で素早く仕事を終わらせるのが一番楽しい。
普通の技術ってJava 8や.NET 2.0じゃなくて、新しいJavaや.NETこそが面白いけど安定してるよ。Angularのv17やv18も興味深いけど、地味で安定した技術だね。信号やスタンドアロンコンポーネントへの移行はちょっと面倒だけど、そんなに難しくないよ。
長いことやってきた私たちには、無駄話をする気がない。仕事をさっさと終わらせて、次に進むだけなんだ。それに、要求の変化にも対応しなきゃいけないし。
新しい技術は若い開発者たちの願望にすぎない。彼らは長年の経験を積んだ人たちの知識に追いつくのに何年もかかるんだ。それでも、新しい技術には似たような問題が出てくることに気づくよ。
Linuxの知識は基本的なcd/cp/chmoxを超えていらないかもしれない。Dockerで置き換わるから、init.dやSystemDを選ぶ必要もない。
私はコンテナが壊れている理由を探るのに時間をかけすぎた。一般的なUnixの知識は必要だけど、Linuxの知識はそれほど求められない時代が来るかもしれない。
AWSでサポートエンジニアとして働いてた時、容赦なくコンテナチームに投げ込まれた。顧客のアプリが100％CPU使用率になって、健康チェックに失敗して再起動していたけど、下層のインフラに関心を持たないチームとのやり取りは辛かった。Linuxの知識が不必要なんて、無知すぎる。
彼らは本当に新しいものを再発明しているだけだと理解していない。でも、時には本当に革新的なものもあるから、新しい技術をちゃんと評価することも大事だよ。
再発明は大事じゃなくて、問題を解決するかどうかが重要。以前に放棄されたものが再び放棄されるのはよくあること。
SQLやリレーショナルDBに取って代わろうとする流行に似たものは多い。結局、SQLはまだ良く機能しているよ。
ハイパースケーラーパソコンラックは再発明されたスーパコンピュータであり、クラウドソフトウェアは90年代の機能を再現している。考えてみて。
結局、私の顧客はNodeかDeno、最新のNodeやPostgresのバージョンに関心がない。彼らはただ機能するものを求めてるだけなんだ。
エンジニアは、自分の作ったものがどれだけ素晴らしいかを誇示したがるけど、実際には顧客への説明が重要だと思う。
このような absurdity にこだわっていると、自分のやっていることがどうでもよくなり、本来の目的を忘れがちだ。要は、ツールよりも結果が重要だよ。
昔、エレキギターに夢中だった頃、機材ばかり気になって実際には練習を怠ってたことを思い出す。
趣味には、実際の活動よりも機材に夢中になる人がいるよね。
自分の周りにもいるけど、ギターを集めたり、取引したりしてる人って、結構自分の腕前をわかってるんだよね。俺も色んな機材に憧れるけど、結局プレイすることが大事だから、手持ちのもので頑張ることにしてる。時々道具が悪いせいで上手くいかないこともあるけど、自分の問題が大きいのもわかってる。
ああ、所謂Gear Acquisition Syndromeだね。
これ、いろんな趣味で見てきた現象だよ。機材に気を取られるほうが、お金を使いやすいし、難しいことをやるより簡単だからね。
お前のドリルは時間とコストに追われたエンジニアが設計したものだろうね。組み立てたのは、工場でそれを気にしない人だよ。
でも、しっかり設計された製品は、気にしない人が作れることがあるんだよね。ソフトウェアはそれが可能かは疑問だけど。
でも、ドリルが壊れると物理的に怪我する可能性はあるよね。ユーザーは道具の作り方より、ちゃんと動くことを気にするだけだよ。
正直、そんなに違わないと思う。エンジニアも、ユーザーが技術じゃなくて結果を気にするってことを忘れがちなんだよ。
＞なぜソフトウェアが特別なのか？
それはソフトウェアが生きてるし、色んな人の個人情報があったり、他のことにも使われるデバイスで動くからなんだ。攻撃面が膨大で、アクセスしやすい。もし銀行のサイトが古いJavaフレームワーク使ってるのは気にしないけど、詐欺に合ったら大変だもん。
俺は「Stackoverflowability」って呼んでるよ。成熟した技術についての質問が多いほど、参考になる質問がSOにあるから。
SOの質問が多くて、ユーザーが少ないと、そのプラットフォームは成熟してないってことだ。
それは間違ってると思う。質問が多い言語はPythonやJavaScriptとかで、これらは新しいわけじゃないから。
「総ユーザー数」とは、単に普及を指してるんだと思う。あまり使われてない技術で質問が多いのは、未成熟を示すかもしれないね。
気持ち分かるわ。次のサイドプロジェクトを考えてて、Djangoを使うことにした。ゼロから作ることもできるけど、無駄に時間を使う意味ないし、アイデアを特別にするための重要な部分にもっと時間をかけたい。
依存関係が古いのは、成熟した技術を使っているのとは違うよ。少なくともバグやセキュリティの修正のために定期的にアップデートしてるよね？
アップデートはバグやセキュリティの問題を増やすこともあるから、これが議論になるのは微妙だよ。システムがしっかりしてれば、セキュリティの問題には耐えられる。
新しいバージョンは、まだ誰も知らない新しいバグをもたらす。古いバージョンには広く知られた古いバグがある。安定性の観点からは古い方が良いかも。でも古いのはセキュリティの観点からは割と危険。
免疫システムはあるよ。脆弱性に繋がる部分を外部と接続しなければ安全だし、Hacker Newsのコメント欄でPCが乗っ取られることはない。
画像ライブラリに脆弱性があった場合、画像をアップロードすることで攻撃されることがある。解決策はライブラリを更新すること。OpenSSLのバグでサーバーの公開鍵が危険にさらされた事例もあるよ。
Stuxnetの事例を知ってる？全く隔離されたシステムも感染することがあるから、甘く見ない方がいい。
例え話を理解してるよね？その人が言ったのは免疫システムのこと。私はそんなのはもう信じてない。
依存関係を最新の状態に保つ（既知の脆弱性を更新すること）は、ただの怠慢な「アドバイス」ではないし、契約を取るためのチェックリスト的なセキュリティソフトはただのマルウェアであることが多い。
安全なシステムを作るには、システムを壊す可能性のある依存関係はなくすべき。
お前はその安全なシステム用に何のウェブサーバー書いた？どのOSで動かしてる？どのファームウェアを書いたの？全て依存関係の積み重ねだ。
ウチは数年前からアップデートしてないオペレーティングシステムとウェブサーバーを使ってる。サーバーが機密情報にアクセスすることは無いし、客の注文を受けるだけなら万が一サーバーが壊れてもバックアップから10分で復旧できる。
最悪の場合、攻撃者は顧客の注文情報にアクセスできるだけだよ。それが問題だと思わない？
最悪の場合、攻撃者が意味不明な顧客注文を送ってスタッフが見ると削除されるだけ。年に2回くらい起こるけど、顧客注文なんてサーバーには保存されてないしな。
支払いが通らないのに注文が完了するシナリオなんて考えられないの？それこそ大損失だし、GDPR後の時代にプライベートデータ漏洩も重大問題だぞ。
注文、請求、配送が分かれてるから、そんなことは起きない。プライベートデータ漏洩はRAMにアクセスされるハッカーの話になるし、全てのビジネスが心配する必要はない。地元の自動車ディーラーに電話して全車両が欲しいと言ったら、そんな簡単には全車送ってこないだろ。
新しいスタックやフレームワーク、派手な新しいライブラリはユーザー体験にはあまり寄与してないと思う。Reactは良いけど、そのせいでグチャグチャになってる。
Reactも11歳だよ。ウェブUIの世界では“退屈な技術”なんだ。
退屈な技術は素晴らしい。筋肉記憶ができて、面白い問題を考える邪魔にならないから。
pnpmは今やかなり退屈な存在。Turborepoと使い始めたら、npmよりずっと楽になった。
今週npmが10年ぶりにキーを回して、pnpmでデプロイしたサイトが全部壊れた。Digital Oceanの3つのサイトを修正するためにnpmに戻さなきゃならなかった。エコシステム全体が全然退屈じゃないし。
退屈な技術は素晴らしい。製品の実際の技術に集中できるから。ただし、時代遅れにならないようにしないと。5年以上の経験があるCTOがアイデアもブログすら書かないのは、そもそもSaaSスタートアップなのか？
君の見解は分かるけど、反論もある。自分の好みに合うソフトを選んで“退屈”と言うことで、他を軽視するのは危険。退屈だから当然良いわけではないし、ちゃんとした議論が必要だ。
そうそう、この話題で多くの人がそうやってる。お金を生むものは退屈、好きなものは退屈って。明日には退屈な技術が世界平和をもたらすなんて言う人も出てくるんじゃない？“退屈”って言葉は話を終わらせるだけだ。
＞“退屈だから当然良い”って考えには注意が必要。新しいから当然良いって言うのも危険。昔は俺もそう思ってたけど、新しいものを盲目的に指示するのは悪手。ソフトウェアの比較は難しいし、個人の好みもある。でも議論して明らかにどちらかが優れてないなら、古くて確立された技術を選ぶ方がいいね。
デマゴーグは本物の議論より圧倒的に良い。ほとんどの人は後者を理解するのが難しいし、時間もないから。彼らに「正しい選択をしてる」って安心感を与えるのが支援を得る方法だ。
エンジニアの視点からは明らかな冗談なのか、組織リーダーの視点からは真面目なのか、見極めが難しいね。
みんな、クラスタのオーケストレーションシステムとかレンダラーの中のレンダラーが必要って主張する人と議論するのに疲れたんだと思う。やっぱり”つまらない技術”を使えって言う方が楽だよね。分かる人には分かるって感じ。
例えば、Javaはつまらない。でもKotlinはJavaの”つまらない利点”を活かしつつ新機能を追加してるから、そっちの方がオススメ。
”つまらない”技術には”安定してる”って付け加えたい。ここで言う安定は、”壊れない”という意味じゃなく、”変わらない”ってこと。そういう技術は通常、古くて確立されたもので見られるけど、何も保証されていない。
すべてのつまらない技術が変わらないわけじゃない。Railsは20年間続いてて、実際新しい解決策が毎回出てくる。
定義を議論するのは無意味だと思う。”つまらない”は単に誰かが好きなものって意味になっちゃってるから。この用語は、具体的な議論を避けるための言い訳として使われがち。
昨日の話を逃してしまったけど、”つまらない”ってのは”安定してる”ってことでもある。去年学んだことが今も通用する信頼感を持てるから。
Railsは定義上、つまらなくはない。驚きやメタプログラミングの魔法があって、毎年ベストプラクティスが変わるコミュニティがあるから。つまらないを”好きなもの”に再定義すべきじゃない。
それが絶対的ではないのは公平だけど、完全に静的だとは主張してない。
永遠の議論は古いか新しいか、つまらないか刺激的かじゃない。成熟してるかどうかが重要で、安定性やシンプルさが成熟の指標。Pythonが成熟してるかは疑問。依存関係の更新で壊れるシステムは成熟してるとは言えない。
GoやRustが”つまらしい”のは、0.x.yバージョンの依存関係を使ったときだけ。すべての更新を丁寧にチェックしておかないと、壊れる可能性がある。
Rustの0.x依存関係は、成熟したJavaの35.x依存よりも問題が少なかった経験があるよ。
Goの良いところは、たくさんのライブラリが標準ライブラリのためのすごく良いAPIってこと。最小限のサポートコストでフォークしたりベンダーできる。
（本当に質問）たまにPythonを書くけど、venvを使ってrequirementsファイルをインストールするだけ。Pythonにはどんなツールチェーンの問題があるの？
大きなプロジェクトだと依存関係の競合がほんとにイライラするよね。セキュリティ上の理由で依存関係をアップグレードしたいのに、別の依存関係がそのバージョンを固定しちゃってるとか。
言語に関係なく、大きなプロジェクトでは依存関係の競合は問題になるよね。動的なランタイムでは、ライブラリがサードパーティのHTTPクライアントを使わないことも多いから、マシだと思うけど。ライブラリの数を減らす選択肢もあるけど、結局最終的にモノレポに入れることになると、アップグレードが大変なんだ。
それは悪夢だね。でも、NPMみたいに同じライブラリの複数のバージョンを読み込めるダイナミックなランタイム以外は、全てのパッケージシステムで問題になるんじゃないかな？
どの言語でも問題だけど、解決の仕方が異なるんだよね。NPMのやり方は一つの問題を解決するけど、他の問題を生むこともある。インタプリタ言語を扱うとき、ランタイム前に問題を特定するのが難しいのが大きな問題だね。コンパイル済みまたは静的型付けの言語の方が、問題を早く把握しやすいよ。証明書の問題を解決するためにrequestsを更新したけど、ランタイムまでその効果がわからないんだ。
賛成だよ。NPMが良いとは言わないけど、ランタイムを通じて依存関係の解決問題を回避してるのは確かだね。だけど、同じライブラリが20個もプロセスにあったらいやだよ。
どこで働いても、依存関係を更新したら、Aのマシンで問題なく動くのに、Bのマシンだと全部壊れることがあったよ。特にnumpyやscipyの環境でね。1回その修正に数日かかったのは信じられない。この経験は他の言語ではしたことがない。しかも、当時は数値ライブラリをインストールするのにanacondaが推奨されていたんだ。他のパッケージマネージャーの方が良いかも。
ネイティブな依存関係は、その特性とプラットフォーム間の互換性の欠如によって、非常に手間がかかることがある。これってCIでも問題になるよ。
まぁ、半年ごとに誰かがPythonの配布問題を解決してるみたいだね。
Rustは実際には成熟してないと思う。言語が成熟してても、使う開発者のスタイルがそれに見合ってないとダメだよ。古い・新しいの影響もあって、Rustは進化が速すぎて、ほんの3ヶ月前のrustcじゃ新しい機能を使ったプログラムをコンパイルできないことがあった。Rustがもっと一般的に人気になれば、状況が改善されるとは思うけど。
プロジェクトに合ったRustのバージョンをそのまま使わない理由があるの？最新の21バージョンを使ってるJavaプロジェクトもあれば、古い8のもあるし。
システムライブラリとプログラムがインストールされたOSで、rustcをcurl|shからインストールするのは避けてるよ。他の言語の場合、アプリごとにカスタムインストールを設定しなくても済むのが普通なのに、Rustだけはそれが不合理で問題を招くから、できるだけ避けたいね。コンテナ設定も解決策にはならないと思う。
rustupはシステムのパッケージマネージャーからインストールできるよ。手順を守らないと’退屈’な道を外れることになるけどね。どの言語を使ってるの？バージョン管理を使うことで多くの問題が解決するとは思うけど。Rustに公式のバージョン管理があるのはありがたいことだ。
rustupのダウンロード方法自体は簡単だけど、コンパイラやツールチェーンとして使うには不安だね。古いCやPerlを使ってると、今日書いたperl+inline Cのプログラムが昔のシステムでも動くのが嬉しいよ。RustやPythonの進化が早すぎて新機能の採用がすぐに影響を出すことに比べて、CやPerlは安定してると思う。
退屈な技術を使っても誰も昇進しないし、雇われないんだ。退屈な作業をしてきたから、仕事の応募に満足な返信が来ない気がする。オープンソースならシェルスクリプトを書いてきたけど、これは全くセクシーじゃないから無視されがちだと思う。要するに、もし私の履歴書がPythonとShellじゃなくて、GoやRustだらけだったら、もっと簡単に雇われるだろうね。
