俺もそう感じるけど、ある意味でNixは他のOSよりも普通のプログラミングパラダイムに近いと思う。単に、そういうOSの考え方に慣れてないだけなんだよね。Nixの式は入力（パッケージリポ、たくさんのキーとバリューのペア）と出力（Linuxシステム）がある。数年後にはもっと普通になるかもね。つまり、AIが仕様通りのshell.nix（いくつかのPythonパッケージ、いくつかのLinuxパッケージ、いくつかの環境変数、いくつかのパスエントリなど）やconfiguration.nixを作るのはすごく簡単になると思う。このパラダイムのおかげで、完全にパッケージをサポートするリポと一緒に環境を含めることが多いんだ。フレークを使えばもっと再現性が高くなるだろうね（flake.nixはshell.nixのようなもので、バージョン固定がある…みたいな感じ、まだその学習の山を登ってるところ）。

「言語パッケージマネージャーが奨励する「特注バージョンスープ」的な考え方」って何を意味するのか、そしてその代替は何なのか詳しく教えてくれる？

実際、うまくやれば両方とも持てるよ。例えば、Cargo.lockファイルからNixでRustパッケージをビルドするのは簡単だし。Nixpkgsは特注のバージョンスープとは逆だけど、Nix自体はそれでも大丈夫だよ。

特注のバージョンスープは持続不可能だけど、みんながそれを続ける理由の一つは、うまくいくことが多いから。OSレベルのライブラリは、互換性を壊さないように気を使う保守的な世界から来ているから、安定した、よく管理されたOSをベースにして、miseやasdfみたいなツールを使って特注のバージョンスープを構築して、その上でアプリを動かすことができる。ほとんど壊れることはないし、壊れたらバージョンや小さな修正をいじってまた動くようにして、次に進む。壊れたことはイライラするけど、重要ではない。摩擦を生むもの、学ぶことが増えるもの、作業が増えるものは時間の無駄だと思う人が多い。逆に、壊れないようにする解決策を探す人もいるけど、その解決策は摩擦を生んだり、学ぶことが増えたり、作業が増えたりすることが許される。なぜなら、その問題が重要だと考えているから。そういう人たちはNixを求めてる。ほとんどの人は最初のグループにいるから、成長したい会社はそのグループに合った解決策を提供することになるんだよね。

VCを集めるのにどっちが良いか（多くの人にとってそれが目標） - Nixラッパーかデプロイメントプラットフォームか。

Nixを使わないのには賛成だけど、実際には問題じゃない理由で動作するシステムをゼロから再構築するのは根本的に狂ってると思う。ここで他の人が言ってるように、nix2containerやflakesは彼らの抱えている問題を解決すると思う。バージョン管理に関しては、3年前に書いたflakesが、最初に書いたときと全く同じバージョンと出力でビルドできるよ。市場に出てプラットフォームから資金を調達したいみたいだね :D 編集: さっきnixpacksのGitHubをチェックしたら、nixpkgsでrustPlatformを使っていることにすぐ気づいた。oxalicaのrust-overlayではなくて、これはRustの問題を調べる際にどんな軽い検索でも出てくるはずのものだし、私が使った中で最も便利で強力なオーバーレイの一つだよ。 [0] https://github.com/oxalica/rust-overlay

nixは、共有ライブラリの互換性の問題を非常に保守的に解決してる。何かが変わるたびに、重要かどうかに関わらず - コメントが変更されたり、ドキュメントが変わったり、テストケースが追加されたりすると - すべての依存関係を再ビルドするんだ。それだけじゃなくて、依存関係の依存関係、さらにそのまた依存関係まで、どんどん続いていく。これって、しばしば大規模な再ビルドを引き起こすことになるよ。確かに共有ライブラリの競合は避けられるけど、この解決策は非常に無駄だと思うし、開発も辛くなることがあるよ。nixpkgsのステージングプロセスを見てみて。

エッジケースがあると、悪い状況に陥ることになるよね。glibcの変更や、競合する共有ライブラリとか。Nixの価値は理解してるけど、「悪い状況」って言うのはちょっと大げさかな。せいぜい「Nixに比べてかなりの保証を失う」って感じ。とはいえ、95%のソフトウェアよりは「正しく動作する可能性が高い」ってことは間違いないよ。

正直、これはrail...自分たちのバージョンを作りたいみたいだから、新しいrailXだね、笑

私はNixを使ってないけど、これは軽視してるように見えるね：> Nixpkgsは素晴らしいリソースだけど、NixはNixpkgsじゃない。もしNixpkgsがデフォルトで、代替手段が追加の調査や努力を必要とするなら、ほとんどのユーザーにとってそれはNixなんだ。> これは意味がわからない。文字通り、好きなように別のレイヤーに分けることができるよ。NixpkgsのDockerツールには、これをサポートする機能もあるし。これは明らかで、簡単で、デフォルトの動作なの？

これはかなり上手く言われてると思う。nixpkgsはNixじゃないけど、nixpkgsは良い部分だと思う。私はNixOSを使っていて、人生で初めて、Linuxカーネルの最新バージョンをリリース日に使ってる。これは素晴らしいことだよ。年を取るにつれてDebian Stableには耐えられるようになったけど、いつも数年前に戻ったような気分になる ;) Nix言語については、何時間でも批判できるけど、仕方ないよね。古いし、彼らはできる限りのことをしたし、変える価値はないと思う。Nixのビルドシステムは、私には非常に原始的に感じるし、必要ないものを再ビルドすることが多い。例えば、私のNixOSインストーラーISOは、カーネルに渡すコマンドラインに依存している部分が多くて、[just console=ttyS2,1500000n8]、シリアルポートの速度を変えるには約3分のビルド時間がかかる。ちょっとおかしくて笑っちゃうけど、これでNixを使うのをやめるつもりはないよ…でも、私のビルドではこんなことは許さないかな。Dockerイメージに関しては、私の意見ではNixが最も苦手なところだと思う。ずっと前、Goでソフトウェアを書いていて、コンテナイメージにPostgresのpg_dumpバイナリを追加する必要があった。インフラチームがNixを使うことを提案したから、そうしたけど、私たちのイメージは圧縮されたGoバイナリの50MBから、何が入ってるかわからない1.5GBに膨れ上がった。pg_dumpは464Kなのに。結局、自分のやり方で、Bazelとrules_debianを使ってaptパッケージをインストールすることにしたら、結果（distrolessの上に）はずっとクリーンでコンパクトだった。実際のNixの経験から言うと、Nixシステムはいつも1.4GBになる。私のインストーラーISOは1.4GBだし、新しくインストールしたマシンも1.4GBだ。理由はわからないけど、そういうものなんだ。最後に、「大きなC++プロジェクトをビルドしたい」という状況は、よくある道だね。s/C++/Rustに変えても、特に何も変わらない。ライブラリの状況をもっと耐えやすくするためのビルドシステムが存在するけど、どれもNixと同じくらい複雑で、でもこのユースケースにはうまく機能するものもある。Nixは他の人のソフトウェアをビルドするためのビルドシステムを目指していて、nixpkgsをサポートしてるけど、非常に一般的な側面に落ち着いている。自分のソフトウェアをビルドするために設計されたビルドシステムは、その仕事をうまくやる傾向がある。個人的にはBazelに満足していて、他のものは使わないと思う（Go専用プロジェクトには「go build」を除いて）、でも他にもたくさんの選択肢があるよ。99%の確率で、Nixの代わりにそれを使うべきだし（そして、他の人がhome-managerで最新バージョンのあなたのものをインストールできるようにフレークを書いたり；もしかしたら、私は日常的に自分のソフトウェアを使う唯一の人で、実際にはそんなことをする必要はないのかもしれない…）

見逃しがちなのは、彼らのユーザーが自分の依存関係やバージョンを指定したい開発者だってことだと思う。nixの動き方とnixpkgsの構造上、任意のパッケージのバージョンを固定するってことは、nixpkgsツリー全体のコミットを固定することを意味する。node/python/rubyパッケージのビルドは、ツリーのパッケージディレクトリの外にあるものに依存しているから、バージョンとコミットのマッピングが必要なんだ。これは漏れがある抽象化でもあるから、ユーザーにそれを見せる必要がある。そうすると、彼らは「新しいファンシーなNode.jsパッケージをyarn addしたいだけなのに、nixpkgsリポジトリのさまざまな状態を合わせる必要がある」って状況に直面することになる。nixpkgsなしでnixを使うのは、より限定的な用途にはいいかもしれないけど、Railwayみたいなプラットフォームには正当化しにくい気がする。

Nix != Nixpkgs FreeBSDのportsに関してFreeBSDを試しているときにこれを言われたことがある。pkgは一般的に私にはうまくいくけど、ある日、道を外れてカスタムUSEフラグ（FreeBSDでは何て呼ぶか忘れた）を使ってvimをコンパイルしようとしたんだ。20以上の依存関係が引っ張られて、make menuconfigのたびに「これらのオプションが欲しいですか？」って聞かれて、合理的に見えるものをいくつか選んだら、23のうち16のパッケージが「これが必要で、あれが必要で、Fubar3はFubar4に非推奨」とかで失敗して、もう諦めた。Core OSの開発者が1万以上のパッケージをサポートできないのは理解できるけど、実際に使おうとすると（つまり、カスタム機能を有効にする、ただのストックコードをコンパイルするだけじゃない）高い確率で動かないってことははっきりさせるべきだと思う。もう一つの選択肢は、コンパイルできないものはportsリストから外して、portsnap fetchに現れる前に、少なくとも標準的な独立ビルドが成功する必要があるってことだね。

nix2containerに感謝したい！AWS（ECR）へのデプロイに使ってるんだけど、ビルド間の反復時間が1桁の秒数にまで短縮されたよ。

https://github.com/railwayapp/nixpacks