自分で作る Build It Yourself プログラム

 (lucumr.pocoo.org)
2 ポイント 投稿者 GN⁺ 2025-01-26 | 1件のコメント | WhatsAppで共有

  • 依存関係についてのもうひとつの考え方

    • 依存関係に対する新しい見方を提案している。依存関係の過度な利用を減らし、自分でコードを書く方向へ切り替える必要がある。

  • 依存関係の問題

    • 「依存関係の消耗」とは、開発者が生産性のために導入する更新、パッチ、監査、推移的依存関係の終わりのない反復のこと。
    • JavaScript と Rust はとくに依存関係の問題に弱い。たとえば、新しい Tokio プロジェクトには 28 個のクレートが含まれ、Rocket プロジェクトでは 172 個にまで増える。

  • ターミナルサイズの問題

    • terminal_size クレートはターミナルのサイズを測定するシンプルな機能を提供するが、複数の追加クレートを必要とする。
    • その結果、何千もの別の機能をコンパイルしなければならない状況が発生する。

  • 依存関係の必要性

    • プラットフォーム抽象化ライブラリの上に構築されているため、コード重複を避けてコンパイル時間を減らすには更新が必要になる。
    • 依存関係はセキュリティ問題の主な原因になることが多い。

  • コードの目標

    • コードは更新が不要な形で書かれるべきである。Rust エコシステムでは、安定したコードが不利になる。

  • 自分でコードを書く利点

    • 自分でコードを書けば新しいクレートは不要で、メンテナンスの必要性も減る。
    • ChatGPT のようなツールを使えば、依存関係のない実装を素早く書ける。

  • オープンソースと企業文化

    • 企業のコードレビュー文化はオープンソースソフトウェアに影響を与える。
    • 新しいライブラリを使うことが肯定的に捉えられる。

  • 新しい視点の必要性

    • 小さな機能を自分で書くエンジニアを称賛すべきである。
    • 大きなクレートグラフには懐疑的であるべきだ。

  • 重要なライブラリ

    • 複雑な問題を解決する重要なライブラリも存在する。たとえば、グラフィックスライブラリやプロトコル実装など。

  • 自分で構築することの重要性

    • 適切な場面では自分で構築することを称えるべきだ。
    • 依存関係が少ない、またはないオープンソースライブラリを構築するライブラリ作者の功績を認めるべきである。

  • 結論

    • 依存関係を減らし、自分でコードを書く方向へ切り替えるべきである。
    • minijinja は依存関係を最小化した例であり、serde だけに依存している。

関連記事

1件のコメント

 
GN⁺ 2025-01-26
Hacker Newsのコメント

  • Rustという言語は好きだが、Rustの依存関係の問題は嫌いだ。C++のほうが依存関係の管理は優れている。C++では依存関係を自分で制御できるが、Rustでは依存関係が多すぎて諦めたくなる。セキュリティの面でも、自分が何を配布しているのか把握できない。RustにはABI互換性がなく、共有ライブラリ文化も乏しい。これはOSのパッケージ配布モデルを破壊する。

  • ターミナルAPIは安定していない。TIOCGWINSZ ioctlは標準化されておらず、POSIXにtcgetwinsize()関数が追加されたのは2024年になってからだ。Windows側はさらに複雑だ。

  • 2006年に作ったWebアプリを復活させた。新しいCI/CD技術を学ぶために、そのアプリのデプロイ工程を過剰に設計した。PHPとMySQLを使っており、コードの大半は自分で書いた。19年前のアプリを復活させるのに1時間しかかからなかった。一方、今の職場で使っているSpring Bootアプリは依存関係の問題で更新が難しい。

  • NodeJSはキャリアに大きな影響を与えたが、NPMは多くの問題を引き起こした。新しい依存関係を追加しようとすると、ほかの依存関係と衝突する。Expoでは、基本のReact NativeプロジェクトがAndroidでビルドできない問題がある。大規模プロジェクトでさえ機能しないテンプレートを配布し得るのだと知って、自信がついた。

  • Rustのエコシステムは、Goと比べると依存関係が多い。Goではインターフェースが暗黙的に満たされるため、追加の依存関係が必要ない。

  • ライブラリの抽象化には隠れたコストがある。パッケージが設計を変更すると不安定さが生まれる。シンプルなものほど最も長く生き残る。Rustだけでなく、ほかの言語でも同じような問題を見てきた。

  • ChatGPTやCursorが、依存関係のない実装を素早く作ってくれるほうが速い。多くのSaaS/3rd partyサービスへの依存は、すでに解決済みの問題だ。

  • FlaskとBottleは似たような機能を持っていたが、Flaskのほうが人気を集めた。Bottleは単一ファイルで依存関係がなく、プロジェクトに簡単にコピーできた。しかし、現代的なPythonの慣行に追随できず、時代遅れに感じられるようになった。

  • 自分でソリューションを開発できる有能なエンジニアが必要だ。既存のライブラリより良いソリューションを簡単に作れることもある。あるプロジェクトでMarkdown方言向けのパーサーを書いたが、チームメンバーは保守性を理由に採用しなかった。

  • 1つの関数しか使わないのに数百の関数をコンパイルするのは問題だ。3rd party依存関係を更新するプロジェクトで、数学ライブラリの1つのメソッドしか使っていなかった。エンジニアにはWikipediaのページを参考にして、そのメソッドを自分で実装するよう勧めた。問題は3rd party依存関係を使うこと自体ではなく、ライブラリの小さな一部だけを取り込むという考え方が必要なことだ。"マイクロフレームワーク"が解決策になり得る。