純粋関数型システムプログラミング言語Cargryを開発しています
CargryがCodebergに移行した理由についてもう少し詳しく語ろうと思い、この記事を書いています
とある危機感
世の中、Claude Codeだったり、Codexだったり、バイブコーディングツールが揃っています
しかし、私はバイブコーディングに危機感を持っています
なにをもって「開発」か
AIコーディングはいいですよね。AIに作りたいものを言って、動作確認をするだけ
でも私は、「AIはどこにでもあるような情報からとってきた、どこにでもあるような設計で、どこにでもあるようなコードなら得意」と考えています
それが、意図的なものであればよいですが、何か尖ったものを作りたいときには合いません
私はいつも「新しく開発する意味とは何か」と考えてしまいます
じゃあCargryは？
Cargryは純粋関数型で、システムプログラミングをするという目的で開発しています
そのことをAIに伝えれば
「純粋関数型だったら、大抵GCが必要」
「システムプログラミングでは副作用が当たり前だが、どうするのか」
AIに設計させれば
「純粋関数型を取り入れ、GCと所有権のハイブリッドにする」
と、AIは妥協します
ですが、Cargryは「独占モデル」というメモリ管理モデルで突破します
独占モデル
CargryがRustと同じ領域を目指しているわけなので、独占モデルも所有権と同じことを目指します
しかし、私は思い切って
- ムーブなし（コードの意味が崩れないなら一部ある）
- 可変なし
- ライフタイムなし
としています
ここで言われそうなのが
「所有権で十分ではないか」
です
ですが、所有権は手続き型的で、私はもっと純粋関数型のためのものにしたいと考え、「独占モデル」を考えました
エントリポイントの副作用ハンドル問題
はじめに
Cargryは、ランタイムがありません。また、コンパイラが副作用の具体の知識をもつことを好みません
AIならどうするか試してみましたが、
「言語から副作用を追い出す（言語は純粋な計算しかしない）」
「OS、外部のCやRustがする」
それでも、結局コンパイラが副作用を知っていることに変わりはありませんし、他言語に依存し、表現の限界があります
本題
副作用はハンドルすれば良いだけと思っていても、エントリポイントは違います
誰もエントリポイントをハンドルできません
だから、コンパイラやランタイムが副作用を知ることになるのです
AIの回答では、その言語だけで文字の出力や、ファイルの読み書きができませんから、普段プログラムを書いている身としては、果たしてこれが言語と言えるのかは怪しいところです
対して、Cargryは「ライブラリが副作用の内容を書いて、コンパイラが繋げるだけ」とし、これを「デフォルトハンドラ」としています
言語に副作用を持ったまま、ハンドラを書かなくてもライブラリ標準のコードを挿入します
Cargryはこれによって、エントリポイントの副作用ハンドル問題を解決しています
で、結局
私は、AIに言語を作らせることにうんざりしています。GitHubがAIの利用を推進するのにもうんざりしています
また、どうにかしようと模索せずに、妥協を始めるAIにうんざりしています（個人的に）
何より、人間がAIを支配するところを、AIが人間を支配し始めているような気がしてやみません
だから、CargryをCodebergに移行させたのです