OpenBSDにRust使わんの？への返答

要約

我々がＣで書いた grep は1秒未満でコンパイルできるけど「新しい言語」はどうなの？

code:theo-en.txt

As a response to this, Theo asked rhetorically "Where's ls, where's cat, where's grep, and where's sort?", implying that noone so far bothered to write implementations of even the basic unix utilities in such a language.

I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities.

As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.

Right now, there are zero usage cases in the source tree to require those compiler tools. We won't put a horse into the source tree when society lacks cart builders.

This brings me to the question, what if someone actually bothered?

So rather than bothering to begin, you wrote an email.

Awesome.

Yes, now I am implying something: you won't bother to rewrite the utilities.

And I understand, why would anyone bother? It took about 10 years for gnu grep to be replaced sufficiently well in our tree. This stuff doesn't happen overnight.

However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 10 years for adoption, let people should switch languages? DELUSION.

Under what conditions would you consider replacing one of the current C implementations with an implementation written in another, "safer" language?

In OpenBSD there is a strict requirement that base builds base.

So we cannot replace any base utility, unless the toolchain to build it is in the base. Adding such a toolchain would take make build time from 40 minutes to hours. I don't see how that would happen.

Note that with Cgrep and haskell-ls, there do in fact exist implementations/analogues of two of the mentioned utilities in a memory safe language (Haskell).

Are they POSIX compliant? No. They are completely different programs that have borrowed the names.

By the way, this is how long it takes to compile our grep:

0m00.62s real 0m00.63s user 0m00.53s system

Does Cgrep compile in less than 10 minutes?

Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

Consider me a skeptic -- I think these compiler ecosystems face a grim bloaty future.

code:theo-deepl.txt

これに対する回答として、Theo氏は "Where's ls, where's cat, where's grep, and where's sort? "という修辞的な質問をしましたが、これは今までのところ、誰も基本的なunixユーティリティーの実装をそのような言語で書こうとはしていないということを意味しています。

仄めかしているのではありません。 事実を述べているのです。 基本的なPOSIXユーティリティの代替品を提供するために、エコシステムの最小部分を移動させようという試みはありませんでした。

一般的な傾向として、これらの新言語で書かれているものは、新たなウェブ向けアプリケーションであり、しばしば独自のものや特定の役割にカスタマイズされたものです。UNIXのパーツではありません。

今のところ、ソースツリーにそれらのコンパイラツールを必要とする使用ケースはゼロです。馬車を作る人がいない社会に馬をソースツリーに入れることはありません。

ここで、実際に誰かが面倒を見るとしたら、どうなるのかという問いが浮かびます。

つまり、実際に始めるのではなく、わざわざメールを書いたということですね。

すごいですね。

そう、私が言いたいのは、「あなたはユーティリティーをわざわざ書き換えることはない」ということです。

分かっています、なぜ誰もが面倒を見るべきなのでしょうか？ gnu grepが私たちのツリーで十分に置き換えられるようになるまで、約10年かかりました。 このようなことは一夜にして起こるものではありません。

しかし、新しい安全な方法を提供すれば、誰もがそれを使うだろうというフィクションが横行しています。ああ神様、最もシンプルな概念であるスタックプロテクターの採用にもほぼ10年かかったのに、さらに人々に言語を変えることを求められるというのですか？ 幻想です。

どのような条件で、現在の C の実装のひとつを、他の「より安全な」言語で書かれた実装に置き換えることを考えるのでしょうか。

OpenBSD では、ベースがベースをビルドするという厳格な要件があります。

ですから、ベースユーティリティを構築するためのツールチェーンがベースに含まれていない限り、ベースユーティリティを置き換えることはできません。 そのようなツールチェインを追加すると、ビルド時間が40分から数時間になってしまいます。 そんなことが起こるとは思えませんが。

Cgrepとhaskell-lsについては、メモリセーフな言語（Haskell）で、前述の2つのユーティリティの実装/アナログが実際に存在します。

これらはPOSIXに準拠していますか？ いいえ、名前を借りただけの全く別のプログラムです。

ところで、私たちの grep をコンパイルするのにかかる時間は次のとおりです。

0m00.62s real 0m00.63s user 0m00.53s system

Cgrepは10分以内にコンパイルできますか？

そのようなエコシステムには信じられないほどのコストがかかります。 例えば、現時点では i386 では rust はアドレス空間を使い切ってしまうため、自分をコンパイルすることさえできません。

私を懐疑的な人間だと思ってください。 私はこれらのコンパイラのエコシステムは肥大化した厳しい未来を迎えると思うからです。

www.DeepL.com/Translator（無料版）で翻訳しました。