a16zとMove言語の父の対話：プログラミング言語から始まり、なぜMoveがスマートコントラクトの将来における重要な方向性なのか？
TechFlow厳選深潮セレクト
a16zとMove言語の父の対話：プログラミング言語から始まり、なぜMoveがスマートコントラクトの将来における重要な方向性なのか？
昨年、a16zなど多くの機関がSuiを代表とするMoveベースのパブリックチェーンを積極的に支援したことで、Move言語はMeta Diemの瓦礫から蘇り、大きな注目を集めるようになった。
Web3業界の深掘り報道に専念し潮流を洞察整理翻訳：Sui World
昨年、a16zなど多くの機関がSuiを代表とするMove系パブリックチェーンを強く推奨し、Move言語はMeta Diemの瓦礫から再び脚光を浴びた。一方で、Sui Moveが登場した瞬間から、否定的な声も常に存在してきた。
もしMove言語がSolidityや他の開発言語よりも優れている可能性があるというだけの理由で、本当に新しいスマートコントラクト言語が必要であり、新規Layer1の構築に没頭する必要があるのだろうか？
最近、a16z CryptoチームはMystenLabsの共同設立者兼CTOで「Move言語の父」とも呼ばれるSam Blackshear氏と、「プログラミング言語と暗号（Programming Languages & Crypto）」をテーマにポッドキャスト対談を行い、なぜMoveが将来のスマートコントラクトの重要な方向性なのかについて議論した。
このポッドキャストでは、a16z CryptoとSam Blackshear氏が、従来のプログラミング言語とスマートコントラクト言語の類似点・相違点、ブロックチェーン特有の制約とチャンスについて議論し、Move言語の設計思想、オブジェクト指向および資産中心のプログラミング、セキュリティ、さらに形式的検証、ガバナンス、コミュニティツール、クロスプラットフォーム適応性などの話題についても共有している。
主な内容まとめ：
1. プログラミング言語とスマートコントラクトの歴史
従来のプログラミングからスマートコントラクトのプログラミングへ、そしてMoveへの進化。Moveは、型システム、静的型付け、コンパイル時チェックといった課題に言語設計の面からアプローチした最初の言語の一つである。
2. Moveスマートコントラクトの革新
EVMはイーサリアム向けに設計された実装の詳細に過剰に適合しており、開発者はその多くの設計意思決定を受け継ぐことになり、拡張性の妨げとなる誤りも含まれている。
Moveは設計段階で、特定のブロックチェーンに関連する要素を一切コア言語に組み込まなかった。ソースコードレベルでの革新が極めて重要であり、最終的にMoveはコード検証器とVMレベルの保護機能を提供することで、他者の攻撃から守ることができる。
3. Sui Moveの設計思想
Moveはユーザー取引やスマートコントラクトを実行するための実行可能なバイトコード言語である。Sui Moveでは、バリデータがより効率的に並列処理を行うことができ、ストレージや実行が容易になる。これらの処理をプロトコルレベルにコーディングせず、ユーザーとプログラマーが考慮する必要もない。
4. セキュリティ
スマートコントラクトの世界では、非常に少量のコードを完璧に書く必要があり、セキュリティが最優先事項である。Moveのセキュリティとは、プログラマー自身によるミスを防ぎ、正しく防御できるプリミティブを提供することである。
5. オブジェクト指向と資産
Moveは、オブジェクト指向かつ資産中心のスマートコントラクト言語として設計された。これは、大多数のWeb2オブジェクト指向言語と同じ考え方だからだ。Sui Moveでは、物事をオブジェクトを中心に据えることで、細かい粒度でのアクセス制御を正確に表現できるよう促している。Sui Moveのグローバルストレージ構造は、オブジェクトIDからオブジェクトIDへのマッピングである。
6. セキュリティ比較
Moveは、リエントランシー攻撃や権限チェック漏れといったスマートコントラクトの問題を設計上排除している。オブジェクトの所有権情報はオブジェクトのメタデータ内に格納されており、プログラマーが操作できない。Move Proverは、言語によるスマートコントラクトの記述ミスを防ぐために設計されており、開発者が多くの基本的なミスを犯すことを回避できる。
7. スマートコントラクト言語のガバナンス
当初、MoveはFacebookで開発され、正式なガバナンスは存在しなかった。言語の拡張には非常に慎重であり、簡潔さを最も重視しているが、積極的に拡張も進めている。Sam Blackshear氏は、Moveがマルチプラットフォームに対応する言語として設計されていることに強い願いを持っている。これにより、EDMの基本機能も引き続き適用でき、スマートコントラクトの達人とWeb2の初心者双方をカバーでき、極めて柔軟である。
8. 開発者への学習アドバイス
大量のコードを読むことが、言語を理解する最良の方法である。共有すること、深く議論することを喜ぶ人々を見つけて、共にオープンソースコミュニティを築こう。自分の作業を楽にするあらゆるツールの仕組みを学ぶべきだ。
以下はポッドキャスト全文（約25,000字、読了時間約30分）。
司会者 Sonal Chokshi による紹介
ウェブ3.0へようこそ。ここは、次世代インターネットの構築に関するa16z Cryptoチームが制作する番組です。私は司会のSonal Chokshiです。
本番組は、開発者、クリエイター、建築家、企業リーダー、政策立案者など、暗号通貨とWeb3.0について理解し、深く掘り下げたいすべての人に役立ちます。今シーズンのスタートです。今日のテーマは「プログラミング言語と暗号通貨」。既存のスマートコントラクト開発者だけでなく、この分野に参入したい他の開発者にもおすすめです。また、プログラミング言語の進化と出現に興味を持つ方にとっても良い内容です。
本日の特別ゲストはMystenLabs共同設立者兼CTOのSam Blackshear氏。彼はWeb3.0の分散型未来の基盤を築いています。Sam氏は、博士号取得からFacebook勤務、さらにはMove言語およびスマートコントラクト構築用のオープンソース言語の創設者として、長年にわたりプログラミング言語の分野で活躍してきました。後ほど詳しく触れていきます。
本番組では、a16z Cryptoのスマートコントラクト研究エンジニアNoah氏もお迎えしています。彼は最近、イーサリアム向けに軽量クライアント「Helios」を開発し、困難なガス最適化に成功しました。
また、a16z Cryptoのエンジニアリング責任者Eddy Lazzarin氏も参加しています。彼はNetflixでソフトウェアエンジニアとして、Facebookではデータエンジニアとデータサイエンティストとして勤務していました。なお、以下の内容は投資、ビジネス、法務、税務に関する助言ではありません。
1. プログラミングとスマートコントラクトの歴史
司会者 Sonal Chokshi：
伝統的なプログラミングの歴史から始めましょう。まずNoah氏、続いてSam Blackshear氏とEddy氏にお話し頂きます。
a16z Crypto Noah：
プログラミングの歴史がスマートコントラクトの歴史にどう影響したか知りたいです。なぜなら、三つのもの——伝統的プログラミング、スマートコントラクトプログラミング、Move言語——があり、それぞれ独自の歴史があると考えます。いかがでしょうか？
Sui CTO Sam Blackshear：
その枠組みはとても好きです。言語を使って文法をデザインしたり人を喜ばせたりするのは正しいですが、それだけではない。だからこのような大局観の枠組みは大変好ましいです。
a16z Crypto Eddy Lazzarin：
伝統的プログラミングは過去20〜30年の間にさまざまなトレンドがありました。動的プログラミング言語や緩い型チェックが長い間流行していた時期もありました。タイプや技術的詳細を気にせず、とにかくコードを書くのが人間工学的に優れていると一般的に考えられていました。
Sui CTO Sam Blackshear：
しかし近年、型システム、静的型付け、コンパイル時チェックなどを深く考える傾向があります。プログラム実行前に可能な限り詳細を把握しようとするのです。こうしたトレンドは移り変わりますが、スマートコントラクトプログラミングに関しては、あまりに新しく、まだこのような歴史的変遷が見られません。これは大きく異なります。
Move言語は、まさに型システム、静的型付け、コンパイル時チェックといった要件に言語設計を合わせようとした最初の明確な証拠だと考えています。静的型付けと動的型付けなど、スマートコントラクトプログラミングにおいて今後どのような変化が起こるのか、非常に興味深いです。現時点ではSolidityという言語しかありませんので、そういった議論はまだ始まっていない状況です。
司会者 Sonal Chokshi：では、それがスマートコントラクトプログラミングとの関係はどうなるのでしょうか？もう一度Sam氏にお願いします。
Sui CTO Sam Blackshear：
スマートコントラクト領域では、EVMが最初期のスマートコントラクト言語として登場し、異なるトレンドがありました。人々はスマートコントラクトで何をしたいのか、どう書けばよいのか分からなかった。そのため、柔軟性がより重要だったのです。専門家のユースケースを探るために必要なことです。しかし現在では、少なくともビルドブロックについてはある程度理解できたと考えます。
スマートコントラクトのトレンドは極めてドメイン特化されており、資産のテンプレート定義、資産移転戦略の定義、アクセス制御と権限の確認などが中心です。
これらが基本であり、スマートコントラクト言語でコンパイラやOSなどを書くことはありません。そのため、汎用プログラミング言語とは比較にならないほど適していると言えます。
ERC-20標準がEVMのプログラミング可能になってからずっと後に生まれたことさえ、人々は見落としていると思います。EVMはイーサリアムプログラムの基本ビルディングブロックの一つとされていたにもかかわらず、その前に基本的なものが明確に定義された証拠はほとんどありませんでした。
したがって、あなたが仰るように、現在では型を当然のこととして扱えるようになりました。型の回避は一定の技術的負債を許容するものです。規模が小さく、迅速に進められ、コードを破棄してもよい場合は、そのような技術的負債は十分に許容できます。しかし、それを企業やスタートアップの規模に当てはめると、急速に成長する小規模企業では全員がコードベースを理解でき、技術的負債は許容されます。
しかし、非常に大規模になり、多数の人がコードを変更する場合、彼らが構築する新たなオブジェクトやシステムの結果を理解していない可能性があります。型システムに組み込むことで、明示的かつ直接的にコードを書く際の障壁を作り、後から誰かが衝突するガラスのフェンスを意図せず作成してしまうことを防げるのです。
例えば、コピー防止、供給上限の設定など、プロジェクト規模に関わらず維持すべき重要な制約があります。これらはプロジェクトの健全性と安全性を保つために不可欠です。これらの境界線を理解することで、強制的に実施できるプログラミング言語を作成できます。これが私のMove言語に対する捉え方です。
必要なことを正しく行うために必要な制約の種類が分かってきた今、それらを言語自体に組み込む能力があります。したがって、あなたが仰った通り、型との類似性があると考えます。
型がプログラムの健全性と安全性に非常に重要であるとおっしゃっています。動的型付けは小規模プロジェクトには適しているかもしれませんが、プロジェクトが大きくなるにつれて静的型付けを使用すべきだと。私は少し異なり、完全静的型付けの方が適していると考えます。これは新鮮な見解かもしれません。プログラマーの健全性のためです。Pythonを書いているときに、ショートカットキー「control k」を押すと関数シグネチャが表示されますが、引数名しか見えず、「一体何をさせたいのか？」と恐怖を感じたことがあります。
a16z Noah：コードを書いた後、二度と見ないという態度を受け入れる人がいるなんて信じられない。
a16z Eddy Lazzarin：彼らは心の中でシステムの要件を記憶できるという前提を受け入れているのです。
a16z Noah：でも100行程度のプログラムでも、その前提は受け入れにくいです。
Sam Blackshear ：動作はしますが、完璧ではありません。
a16z Eddy Lazzarin：
おっしゃる通りだと思います。そして、そのような考え方は進化してきたと考えます。以前は型システムは同僚からの保護のために使われていました。起業が大きくなりすぎたとき、それが役立ちます。しかし今は、自分自身を守るために使われるのです。
スマートコントラクトの文脈では、それは攻撃者からの保護です。ここが大きな違いです。通常のプログラムでは、攻撃者が型システムの制約下でデプロイされることはありません。攻撃者は他の言語でマシンコードを書けます。自分のファイアウォールだけを守ればよいのです。しかし、ここで私は良い型オブジェクトを書き、それが攻撃者のコードに流れ込み、その整合性を保ちます。型システムは私の安全を保証しなければなりません。
おっしゃったように、それは素晴らしいツールであり、異なるニーズを生み出します。コピー防止など、通常の型システムでは考慮しない制約を強制しなければなりません。削除防止や特定の方法での値の使用・破棄の保証など、これらはスマートコントラクトを研究し、これらのユースケースに意味のある型システムを提供しようとした結果、Moveや将来的なスマートコントラクト言語に取り入れられたものです。
司会者 Sonal Chokshi：
実際、皆さん、伝統的プログラミングとスマートコントラクトプログラミングの他の相違点についてもっと話しましょう。ただし、その前に、スマートコントラクトプログラマーが使える言語について簡単に紹介していただけますか？大局を理解したいです。Solidity、Viperなど、現状を把握することで、より早く入り込めます。
Sui CTO Sam Blackshear ：
基本的に、スマートコントラクトを書く場合、ほぼ常にSolidityを使います。少数の他のエコシステムに属している場合を除いてです。
Polkadotエコシステムにいる場合はink!（Sui World注：ink!はParityが開発したRustでスマートコントラクトを書きWasmコードにコンパイルする言語）を使います。StarkNetエコシステムにいる場合はCairo（Sui World注：CairoはSTARK証明システムのプログラミング言語の一つ）を使います。
しかし大部分の場合、もし私がスマートコントラクトの書き方を学びたい人にアドバイスするなら、SolidityとEVMを学ぶよう勧めます。Viperを使うこともできますが、唯一の欠点はViperが比較的新しく、脆弱性が多い可能性があることです。数年前、預金契約の検証中にViperコンパイラに多数のバグが見つかりました。その発見者は現在16zで働いており、Day Juneという形式検証の専門家です。
Day Juneは形式検証の専門家なので、現在a16zで働いています。現実には、何かを学ぶ必要があり、ある言語を学ぶ必要があります。
さらにEVMを深く理解する必要があります。本当に優れたスマートコントラクトエンジニアになるには、EVMを馬鹿げたほど深く理解しなければなりません。各操作のガスコストを言い当てられ、ガスコストに関連する正確なコードを提示できるまでです。これが私たちが生きる世界です。
a16z Eddy Lazzarin：おそらく指摘しておくべきは、ソフトウェアエンジニアとして、自分が実行しているコードのマシンを常に理解できるということです。プログラミング環境について理解すべきことはたくさんあります。しかし、スマートコントラクトプログラミングでは、環境が非常に豊かで複雑です。言語自体とはほとんど関係のない多くのコンテキストを理解する必要があります。周囲で何が起こっているのか、どのようなオブジェクトがあるのか、異なるコードがどのように呼び出されるのか。これは非常に奇妙なことです。
司会者 Sonal Chokshi：Solidityを学ぶのに最も近いのはJavaScript使いですか？
Sui CTO Sam Blackshear ：皆さんはJavaScriptだと言いますが、「function」というキーワードを使っているからです。残念ながら、それほど似ていません。
a16z Eddy Lazzarin：文法的には、Solidityは確かにJavaScriptの特性を多く継承しています。目を細めたり気分が悪くなったりすれば似ていると思うかもしれませんが、実際にはまったく異なります。仮想マシン環境が大きく異なるため、共通点はほとんどありません。
司会者 Sonal Chokshi：似ているプログラミング言語はありますか？
a16z Noah：直接似ている言語はないと思います。Was（Sui World 注：WebAssembly Studio。C/C++ やRustコードをWASM形式にコンパイルするオンラインツール）に慣れ、高度な分離環境（Surplusなど）でコードを書こうとしている場合が最も近いかもしれません。これらのコードは独立して実行され、一定程度の通信が必要です。しかし、それでもあまり似ておらず、表面的な類似性は危険です。
a16z Eddy Lazzarin：おそらく関連するのは、プログラミング言語史上の重大な失敗です。ブロックチェーン分野で、ひどい道を歩んできたというような悪い歴史はあるでしょうか？恐ろしい道を歩いてしまったのでしょうか？
司会者 Sonal Chokshi：良い質問ですね。
Sui CTO Sam Blackshear ：
良い質問です。1977年、C言語がリリースされ、Standard MLも同じ年にリリースされました。Standard MLは非常に大きな影響を与えました。現在、OCamlやRust言語もその影響を強く受けており、Move言語も同様です。しかし、これらの考え方は長い間存在しています。多くの人がC言語が主流にならず、Standard MLの思想——強力な型付け、組み込みの安全性——が広く受け入れられる別の未来を考えています。
司会者 Sonal Chokshi：では、コンピュータ技術の発展トレンドは何でしょうか？間違いだとは言いませんが、Standard MLのような言語は現代でも非常にモダンに見えると思います。その代替宇宙を想像するのは面白いことで、初めて知ったときは感動しました。
a16z Eddy Lazzarin：好奇心ですが、なぜC言語のような言語が、直感的で命令型なのでしょうか？コンピュータを低レベルで考えており、プログラミング言語としてはあまり機能しません。これが私のC言語に対する見解ですが、なぜ私たちはこの道を歩んだのでしょうか？
Sui CTO Sam Blackshear ：
当時のハードウェア制限が原因で、効率的なプログラムを書きたければ、またはコンピュータの限界を押し上げたければ、C言語を使う必要がありました。ハードウェアを前進させるなら、別の道を選んでいたでしょう。しかし、関数型プログラミングは難しく、多くの面で反直感的です。C言語が簡単だとは言いませんが、入門しやすいです。その後、非常に複雑なことをやってきたり、推論が難しいことに気づきますが、手遅れです。良いポイントです。関数型言語は確かに学習曲線が急ですが、一度マスターすれば、コードを独立してよく考えることができ、うまく解決できると気づきます。
a16z Eddy Lazzarin：コンピュータがハードウェアレベルでどのように動作するかを深く考えれば、C言語のような言語はより直接的です。しかし、プログラミング言語に詳しくなければ、C言語は入門しやすいです。しかし、プログラミング言語に精通していれば、MLや関数型プログラミングのような言語に探求すべき価値があると考えます。
Sui CTO Sam Blackshear ：
大局観の答えですね。しかし、小規模な「コンピュータ言語の失敗」についても言及したいです。
a16z Noah：
関数型プログラミングがどれほど優れているかずっと聞いてきましたが、少し理解しにくかったです。ずっと疑問に思っていたのは、関数型プログラミングが本当にそれほど優れているなら、なぜ現在のプログラミング言語のネットワーク効果を打ち破れないのか？この状況に驚いています。
しかし、補足すると、関数型プログラミングが私たちに与えた大きな貢献は、私たちが使うすべての命令型言語が借りている点です。特に、先ほどおっしゃったように、RustはStandard MLの影響を大きく受けていますが、Rustは基本的に命令型言語ですよね？しかし、そこには魅惑的な魔法が詰まっています。
Sui CTO Sam Blackshear ：
全体的に見て、真の問題は1977年から命令型言語の影響力が大きすぎたことです。PRFPも同様ですが、最高とは言えません。孤立して見ればそれぞれ独自の問題があります。現在、Rustのような真のハイブリッドがそれらを美しく融合させ、風景を変えているのを見ています。
私が言及したいのは、Tony Hoareが「十億ドルの誤り」と呼んだヌル参照です。彼は誇張したかもしれませんが、明らかにこの誤りがもたらしたコストは、回避できた場合よりも高額です。
a16z Eddy Lazzarin：いや、これは下限かもしれません。
2. スマートコントラクトの革新発展
a16z Noah：実は、仮想マシン層とプログラミング言語層の革新、そしてそれがスマートコントラクトの発展に与える影響についてあまり語っていませんでした。
Sui CTO Sam Blackshear ：
良い質問です。人々は仮想マシン層とプログラミング言語層の違いを十分に考慮していません。実際にEVM以外にも多くの革新があります。例えばViperなどのソースコード言語です。これらは多くの面でSolidityよりも優れており、非常に興味深いです。
Moveが望むWeb3.0の法的標準になれるなら、仮想マシン層の革新は緩やかで漸進的になると考えます。コアは固定され、新しいものを追加するだけで、根本的な再設計は行われません。
しかし、ソースコード言語層の革新は非常に重要になると考えます。現在、ソースコード言語は一種類しかなく、バイトコード形式と密接に結びついています。しかし、ますます多くの顧客がスマートコントラクトを利用し、セキュリティを重視する中で、さまざまなソースコード言語が試みられるでしょう。これは興味深い研究分野です。例えば、事前の事実を書き、プログラム内で情報を合成したり、制限の提案を行ったりできるかもしれません。
例えば、Moveの事前の事実から始め、プログラム合成によってコードを埋めたり、制限を提案したりできます。
例えば、特定のゲーム文脈でMoveを書く場合、シーン階層構造のように見えるかもしれません。Pythonライブラリで書かれているかもしれませんが、Moveのバイトコードにコンパイルされます。あるいは、SolanaなどのプラットフォームでMoveを統合しようとしているが、VMは統合せず、MoveのバイトコードをSalinaのバイトコード形式にコンパイルし、開発者レベルでMoveのソースコード言語を使うことも可能です。
JVM（Java Virtual Machine）のように、さまざまなアプローチがあると考えます。JVMは優れた汎用仮想マシンで、当初はJavaのみをサポートしていました。しかし、時代を超えて、Scala、Groovyなど、異なるプログラミング体験を提供する多くの方法が生まれました。人々がやりたいことに非常に合致しています。
したがって、Viperはソースコード言語層で実験するスペースを多く提供できるという偏見を持っています。
a16z Eddy Lazzarin：EVMバイトコード言語の代替品、FE、Iron、Viperなど、EVM向けにより賢く複雑な言語を構築しようとする試みについてどう思いますか？それらに対して楽観的ですか？
Sui CTO Sam Blackshear ：これらはすべてEVMバイトコードにコンパイルされる異なるソースコード言語です。
a16z Eddy Lazzarin：はい、EVMバイトコードにコンパイルされます。
Sui CTO Sam Blackshear ：FacebookでMoveの設計を始めたとき、EVM上に構築された他のソースコード言語を見て、SolidityとViperを調査しました。結局、安全なスマートコントラクトを書く上で最も困難な問題はEVMの根本的な性質にあると結論づけました。つまり、型付き値が信頼境界を越えて流れる方法や、動的決定など、これらはすべてEVMの特性です。
より良いソースコード言語を構築すれば、開発者がミスを犯しにくくできます。より高度な検証も可能かもしれません。しかし最終的に、Moveが提供できること、そして私たちが重要だと考えるのは、コード検証器とVMレベルの保護であり、他のプログラマーからの攻撃から守ることです。
ソースコード言語はこれを提供できません。VMに組み込む必要があります。EVM上で完璧なソースコード言語を何度繰り返しても、Solidityは素晴らしいですが、さらに良くできますが、VMにこれらの基本的な保護が組み込まれていない限り、得られる結果は他の道よりも劣ると考えます。Halfがカッコいいからではなく、最終状態が他の道ほど魅力的でないと感じるからです。
初期のスマートコントラクト言語、特にEVMは、イーサリアム向けに設計されたプラットフォームの実装詳細に過剰に適合しています。取引構造、アカウント構造、特定の暗号方式などに関する命令を内部に含んでいます。
そのため、イーサリアムとは異なるチェーンでEVMを使うのは非常に難しく、最終的にイーサリアムが行った多くの設計意思決定を受け継ぐことになります。場合によっては、イーサリアムの拡張性を妨げる誤りさえ受け継いでしまうかもしれません。
Moveを設計する際、特定のブロックチェーンに関連する要素をコア言語に組み込まないことを非常に意識しました。可能な限り、具体的なブロックチェーンに依存しないようにしました。これにより、スウェーデンで特定の取引構造を持つPoWチェーンでMoveを使ったり、オーストラリアで別のチェーンで使うことができます。
これにより、特定のチェーンに賭けることなくMove開発者になれます。スキルをさまざまなチェーン、将来のチェーンに渡って利用できます。これはスマートコントラクト言語の生存にとって極めて重要です。なぜなら、言語の最大の資産はコミュニティだからです。スキルをクロスプラットフォームにすることで、言語に過剰に適合させず、コミュニティの規模を拡大し、成功をより確実にできます。大きなコミュニティがあれば、ツールや公開ライブラリへの多額の投資、言語が一流になり成功するために必要なすべてのものが可能になります。
これは私たちが最初から取り組んできたことであり、現在、言語の統合方法が大きく異なる複数の真に異なるMoveチェーンが存在することを目の当たりにしています。
a16z Eddy Lazzarin：私にはnode.jsの底流のテーマのように思えますよね？
司会者 Sonal Chokshi：はい。
a16z Eddy Lazzarin：JavaScriptを知る人が多く、さまざまなことをしたいと思っています。さまざまなライブラリを共有したい。既存のコードでサーバーサイドのJavaScriptインスタンスを起動でき、これがnode.jsの有用性を生み出しました。これにより、バックエンドプログラミングをしないさまざまな開発者が、この分野に入り始めることができます。
Sui CTO Sam Blackshear ：
この比較はとても良いです。また、プログラミング言語のガバナンスについても話したいです。Node.jsは非常に注目すべきガ
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
