(完全な開示、私は Perl プログラマーです)
Ruby C APIは確かにPerlのものよりもはるかに見栄えがします。Ruby コードに対応する関数を備えた通常の C ライブラリのように見えます。Perl の API は、マクロ内のマクロ内のマクロとマジック スレッド フラグの混乱です。Perl コアの外で Perl API を使用することは、確かに二次的な問題です。ルビーは、腸を食いしばるほど恐ろしいものではないことで間違いなく勝ちます.
Ruby にはより優れた C API がありますが、Perl にはそれを使って何かを行う方法に関するより優れたチュートリアルがあります。生成された Ruby ドキュメントには、まとまりのあるチュートリアルや、多くの場合、説明テキストがまったくありません。間違った場所を探している可能性がありますが、提供されたのはそれだけです。対照的に、Perl API ドキュメントは手書きの散文であり、各関数が何をするかについての有用な情報が含まれています。さらに、Perl と C の使用に関するコア ドキュメントには、12 以上のドキュメントがあります。ドキュメントでは Perl が勝っていると思います。
FFIは非常に印象的です。Perl が FFI に最も近いものはInline::Cで、これは XS の混乱のラッパーです。主な用途は、C コードを Perl プログラムにインライン化することですが、 C ライブラリ関数にアクセスするためにも使用できます。
nash の getpid の例に似た簡単な例を次に示します。
use Inline
C => Config =>
ENABLE => "AUTOWRAP";
use Inline C => q{ int getpid(); };
print getpid();
技術的には getpid が私のシステムで pid_t を返すため、私は不正行為をしていますが、それは単なる整数です。FFI には getpid 用の特別なケース コードが非常に多くあるようです。そのため、使いやすさは、FFI が既にそれを処理しているかどうかに直接関係しているのではないかと思います。些細な例は些細なことです。事前に割り当てられたメモリを返し、奇数の型を持ち、構造体をスローする関数など、典型的な複雑さが発生したときに何が起こるかを見るのは興味深いでしょう。
FFI と Inline::C を使用して同じことを行うことができますが、その方法は非常に大きく異なります。Inline::C は、実際には C コードをコンパイルしてキャッシュしています。FFIはどういうわけかコンパイルを行っていません。それが本当に本当なのか、それとも共通ライブラリのインストール時にコンパイルが行われるのかはわかりません。
さらに、FFI は、さまざまな Ruby 実装間での移植性の問題と、ネイティブ API を呼び出すさまざまな方法をスムーズにします。これは Inline::C が行う必要のないことであり、率直に言って、実際に機能する場合は驚くべきことです。利点の 1 つは、FFI インターフェイスが Inline::C よりもはるかにスムーズであることです。Inline::C を使用すると、C コンパイラのラッパーを作成していることは明らかです。