core.async は Lamina の代替品ですか、それとも Lamina の代替品になる予定ですか?
そうでない場合、一方が他方よりも好ましいという明確な状況はありますか?
core.async は Lamina の代替品ですか、それとも Lamina の代替品になる予定ですか?
そうでない場合、一方が他方よりも好ましいという明確な状況はありますか?
ラミナの作者です。core.async はよくできたライブラリで、Lamina よりもデザインが明確になっていると思います。Lamina の方が優れていると思う点がいくつかありますが、主にイントロスペクション、パフォーマンス、および拡張性に関連しています。
私が core.async で抱えている大きな問題は、ストリームの抽象化に加えて、実行モデル (すべてが core.async スレッド プールで発生する) をもたらすことです。コードベースの他のすべての実装。
ストリームを core.async チャネルとして公開する「非同期」ライブラリが多数作成されているのを見てきました。これは、core.async 実行モデルの使用に慣れている場合にのみライブラリを使用できることを意味します。
Core.async、Lamina、Java ブロッキング キューなどの代わりに使用できる「最小限の」ストリーム表現を試みるライブラリをリリースしようとしています。 Manifoldと呼ばれます。Manifold ストリームは、core.async チャネル、Lamina チャネルなどに強制することができ、これらのいずれも Manifold ストリームに強制的に戻すことができます。
「非同期」の世界はまだ始まったばかりで、抽象化がどれだけうまくスケーリングできるか、本番環境でどれだけ簡単にデバッグできるかなど、未踏の問題がたくさんあると思います。JVM はイントロスペクションのための多くのツールを提供しますが、非同期メカニズムはまったく異なる実行モデルを使用するため、基本的に最初からやり直すことになります。core.async よりも Lamina を使用するようにとは言いませんが、core.async はアプリケーション レベルの抽象化であり、ライブラリ レベルの抽象化ではないことに注意してください。
core.async
とLamina
は 2 つの異なるプロジェクトであり、互いを置き換えることは意図されていません。実際、彼らはうまく一緒に遊ぶことができます - あなたが望むなら -.
Lamina
はストリーム指向のアプローチですが、core.async
はメッセージ指向です。
どちらを使用するかはあなた次第です。Lamina で重要なのは、チャネルに対して定義するコールバックですが、core.async ではチャネルとgo
ブロックが分離されており、より柔軟でモジュール化されています。