Programming Languages

概要 Vercel Labsは7月26日、TypeScriptをNode.jsやV8などのJavaScriptエンジンを一切バンドルせずにネイティブバイナリへ直接コンパイルするオープンソースコンパイラ「scriptc」を公開した。コンセプトは「Zero-runtime TypeScript」で、生成されるバイナリはわずか170〜200KB程度に収まる。Hacker Newsでも取り上げられ、注目を集めている。 scriptcは対応可能なコードを静的にネイティブコードへコンパイルすることを基本とし、それが不可能な構文については組み込みのJavaScriptエンジン（quickjs-ng、約620KB）で動的に実行する--dynamicフラグを用意している。逆にコンパイル不可能な構文には明示的なエラーコードを返して報告する仕組みで、静的コンパイルの適用範囲をscriptc coverageコマンドで事前に分析できる点も特徴だ。 技術的な詳細 言語機能としては、クラスと単一継承、動的ディスパッチ、クロージャ、ジェネリクス（単形化）、判別可能な共用体、async/await、例外処理といった標準的なTypeScriptの機能をサポートする。標準ライブラリはUTF-16完全互換の文字列やJSと同じ順序を保つArray/Map/Set、JSON、Math、型付き配列、Bufferなどを備え、ファイルシステムやパス操作、子プロセス、暗号化、圧縮、タイマーといったNode.js APIとの互換性も持たせている。さらにnet、http、https、tls、dgram、dnsなどのサーバースタックやfetch APIにも対応し、TLSはmbedTLSを内蔵する。 コード生成基盤にはLLVMをデフォルトで採用している。特筆すべき機能として、TypeScriptコードをビルド時に隔離されたVM内で実行し、その結果をリテラルとしてバイナリに埋め込む「comptime」や、C ABIを直接呼び出す「ネイティブFFI」（--ffiフラグ）がある。FFIでは署名のみのTypeScript宣言をC ABI呼び出しにバインドし、マニフェストで宣言したアーカイブやオブジェクト、システムライブラリをリンクできる。またJSON.parse(...) as Configのような型アサーションには実行時検証を挿入し、型不一致時に詳細なエラーを投げるオプションも用意されている。 パフォーマンス面では、Apple M系チップでの計測で起動時間が約2.4ミリ秒（Node.jsの約47ミリ秒に対して大幅に高速）、メモリ使用量は1〜4MB程度（RSS、Node.jsの67〜116MBと比較）とされている。バイナリサイズも静的コンパイル時で170〜200KB、動的実行を含めても約3MBとGo言語のバイナリ（約2MB）と比較しても遜色ない水準に収まる。 正確性の検証には、800件以上のコーパスを用いてNode.jsとネイティブ実行の出力を突き合わせる差分テストと、AddressSanitizerによるメモリ安全性検証の両方を用いている。プロジェクトはpackages/compiler（tsc APIを用いたフロントエンドとLLVM/Cバックエンド）、packages/runtime（参照カウントとサイクルコレクタ、スタックフルファイバ、イベントループを備えたCランタイム）、packages/cliの3パッケージで構成される。 制限事項と今後の展望 現時点ではmacOS arm64を主要プラットフォームとし、LinuxとWindowsはクロスコンパイルでビルドしつつ専用のテストレーンで検証している。npmの依存パッケージは--dynamicフラグ使用時のみ利用可能で、オプションパラメータを値として扱う関数や一部の非同期処理（Promise.rejectなど）は現状コンパイルできない制限がある。開発チームはロードマップとして整数型推論や所有権分析の追加を計画しているという。ライセンスはApache License 2.0で公開されている。

概要 Ruby on Railsチームは2026年7月29日、Active Storageの画像バリアント処理に起因する任意ファイル読み取りおよびリモートコード実行(RCE)の脆弱性(CVE-2026-66066)を修正するセキュリティリリースとして、Rails 7.2.3.2、8.0.5.1、8.1.3.1を公開した。この脆弱性はEthiack社のセキュリティ研究者らによって「KindaRails2Shell」と名付けられ、Critical(緊急)なRCEとして報告されている。Railsチームは全ユーザーに対し可能な限り速やかなアップグレードを強く推奨している。 技術的な詳細 Active Storageの画像処理バックエンドとして利用されるlibvipsは、“loaders"と"savers"と呼ばれるファイル形式の処理機能を持つが、その一部は信頼できない入力に対して安全性が検証されていない「unfuzzed」な操作としてマークされている。Active Storageはこれらの危険な操作を無効化しないままlibvipsを利用していたため、攻撃者が細工したファイルをアップロードし画像バリアントを生成させることで、任意ファイルの読み取りやリモートコード実行につなげられる状態にあった。この問題は、libvipsを使用し(デフォルト設定)、信頼できないユーザーからのファイルアップロードを許可しているアプリケーションが影響を受ける。バリアントの生成自体が不要な場合でも影響が及ぶ点が注意点として挙げられている。 影響を受けるのは、activestorage 7.2.3.2未満、8.0系で8.0.5.1未満、8.1系で8.1.3.1未満のバージョンだ。修正にはRails本体のアップデートに加え、libvips 8.13以上へのアップグレードが必須となる。libvipsが8.13未満の場合、unfuzzed操作を無効化できずRails起動時に例外が発生する仕様になっている。即座にlibvipsをアップグレードできない環境向けには、libvips 8.13以上であれば環境変数VIPS_BLOCK_UNTRUSTEDを設定する、あるいはruby-vips 2.2.1以上であれば初期化コードでVips.block_untrusted(true)を呼び出すという回避策も示されている。 対応の緊急性 この脆弱性は任意ファイル読み取りを許すため、secret_key_baseをはじめとする環境変数上のシークレットが露出するおそれがある。Railsチームは、パッチ適用と併せて、secret_key_base、マスターキーおよび暗号化認証情報、ストレージサービスの認証情報、データベース認証情報、外部サービスのトークンなど、環境変数に含まれる全てのシークレットをローテーションするよう強く推奨している。なお、脆弱性の技術的な詳細については、悪用の拡大を防ぐため2026年8月28日までに公開される予定だ。この脆弱性はEthiack社の0xacb、s3np41k1r1t0、castilho、およびGMO Flatt Security IncのRyotaKによって責任ある形で報告された。 古いバージョンのRailsはサポート対象外であり、Railsチームは少なくとも7.2系以上へのアップグレードを推奨している。Active Storageで信頼できないユーザーからのファイルアップロードを扱っているアプリケーションの運用者は、バージョン更新とlibvipsのアップグレード、シークレットのローテーションを速やかに実施する必要がある。

概要 Node.js公式は2026年7月27日（月曜日）以降に、現行の主要リリースラインである26.x、24.x、22.xすべてを対象としたセキュリティリリースを公開する予定であることを発表した。今回のリリースで修正される脆弱性のうち最も深刻度が高いものは「HIGH（高）」と評価されており、広く採用されているJavaScriptランタイムであるだけに、影響を受ける利用者の範囲の大きさが注目されている。 エンバーゴと今後の情報開示 Node.jsのセキュリティリリースでは、悪用リスクを抑えるため、修正対象となる脆弱性の具体的な内容（CVE番号、影響を受けるコンポーネント、攻撃条件など)はリリース当日までエンバーゴ（情報公開の一時差し止め）が敷かれるのが通例となっている。今回のアナウンスも例外ではなく、事前告知の時点では「深刻度「高」の脆弱性を含む修正がリリースされる」という情報のみが公開されており、CVE番号や技術的な詳細は明らかにされていない。詳細な情報は、リリース当日以降にNode.js公式のセキュリティリリースノートや、nodejs-secメーリングリストを通じて順次公開される見込みである。 対象バージョンと推奨される対応 今回のセキュリティリリースは、現在サポートされている22.x、24.x、26.xの3つのリリースラインすべてに影響する。Node.jsを本番環境や開発環境で利用しているユーザーは、CVEの詳細が公開され次第、各ラインの最新パッチバージョンへ速やかにアップグレードすることが推奨される。特に深刻度が「高」と評価されている脆弱性が含まれるため、影響評価とアップデート適用を優先度高く進める必要がある。 背景 Node.jsは月次または不定期でセキュリティリリースを実施しており、サポート対象の各メジャーバージョンラインに対して同時にパッチが適用される運用が取られている。今回のように複数のリリースラインにまたがって「高」深刻度の脆弱性が修正されるケースでは、影響を受けるシステムが多岐にわたる可能性があるため、Node.jsを利用するプロジェクトの管理者は、公式のセキュリティアドバイザリページやリリースノートを継続的に確認し、パッチ適用の計画を立てておくことが望ましい。

概要 Metaは、React Compiler（旧称React Forget）の実装言語をTypeScriptからRustへと移植し、メインリポジトリへのマージを完了した。React Compilerはコンポーネントの再レンダリングを自動的に最適化するビルド時ツールで、これまでTypeScriptで実装されてきたが、Rust版への刷新によりビルド速度とJavaScriptツールチェーンとの統合性が大きく向上した。パフォーマンス面では、Babelプラグインとして利用した場合でTypeScript版比で約3倍、単独の変換処理では最大10倍の高速化を達成している。さらにTurbopackへの統合テストでは、大規模アプリケーションにおいて40%以上のコンパイル高速化が確認され、Next.jsでの実測でもルートのコンパイルが20〜50%高速化したという結果が報告されている。 技術的な詳細 Rust移植版の実装では、arena allocation（アリーナアロケーション）とインデックスベースのデータ構造を活用することで、メモリ管理とパフォーマンスの両面を最適化している。移植にあたっては全1,725件のテスト項目がすべて成功しており、既存のTypeScript版と同等の互換性を保ちながら移行が行われたことがうかがえる。 この開発プロセスで注目されるのは、LLM（大規模言語モデル）を活用した開発手法だ。Metaのエンジニアは、機械的な変換作業をLLMに担当させ、アーキテクチャ設計とコードレビューは人間のエンジニアが担うという役割分担を採用した。一方でHacker News上のコメントでは、こうしたLLM生成コードが保守チームの認知負荷を高める可能性や、長期的な保守性に対する懸念も指摘されている。 業界トレンドとの関連 React CompilerのRust移植は、JavaScriptツールチェーン全体で進むRust化の潮流を象徴する動きといえる。SWC、Oxc、Rspackといった主要なビルドツールがすでにRustベースで実装されており、パフォーマンスを重視するフロントエンドエコシステムにおいて、Rustによる基盤ツールの刷新が一つの標準的な選択肢になりつつある。React Compilerという広く使われるコンポーネントがこの流れに加わったことで、今後さらに多くのJavaScript関連ツールがネイティブ言語への移行を検討する契機となる可能性がある。

概要 JetBrainsは2026年7月17日、Java/Kotlin向けIDE「IntelliJ IDEA」の最新版となる2026.2を公開した。今回の目玉は「GitHub Copilot out-of-the-box」で、追加のプラグインインストールなしにAIチャットのエージェントピッカーから直接GitHub Copilotを呼び出せるようになった点だ。認証はGitHubアカウントを使ったOAuthで完結し、利用にはアクティブなGitHub Copilotのサブスクリプションが必要となる。これまでサードパーティ拡張機能として提供されていたCopilot連携がIDE本体に標準搭載されたことで、セットアップの手間なくAIコーディング支援を利用できる環境が整った。 AIエージェント・デバッグ機能の強化 Copilot統合と並行して、IDEにはカスタムエージェントスキルを検出・インストール・管理する機能が組み込まれた。JetBrainsが提供する組み込みライブラリだけでなく、ローカルプロジェクトやGitHubリポジトリに存在するスキルも取り込めるようになり、開発者が自身のワークフローに合わせてAIエージェントの挙動を拡張しやすくなっている。デバッグ面では新機能「logpoints」が導入され、アプリケーションの実行を中断することなく内部状態を検査し、任意のカスタムメッセージを出力できるようになった。従来のブレークポイントによる実行停止を伴うデバッグに比べ、本番に近い環境でのトラブルシューティングがしやすくなる。 開発支援機能の改善 依存関係管理では、クラウドベースの検索機能によりビルドファイル内でライブラリ名を入力するだけでマッチする候補が表示されるようになり、依存関係の追加作業が簡素化された。またビルドツール面ではGradle 9.7以上との組み合わせでの同期がスムーズになるよう調整されており、今後リリースが予定されるGradle 10への対応準備も進められている。このほか、Git競合解決の自動化、Flyway・Liquibaseを用いたデータベースマイグレーションワークフローの改善、Spring Securityに関するインサイト表示の向上、Terraformテストフレームワークへのネイティブ対応など、開発ワークフロー全般にわたる改善が加えられている。 言語サポートの拡充 言語サポートも大きく強化された。Java 27に対応したほか、Kotlin 2.4.0の最新機能、TypeScript 7、Scala 3の新機能もサポート対象に加わった。AI機能とコア言語サポートの両輪で強化を図る姿勢は、JetBrainsが競合するAI搭載エディタやIDEに対して開発体験の完成度で対抗しようとしていることを示している。GitHub Copilotの標準搭載により、IntelliJ IDEAはAIコーディング支援ツールの選択肢を増やしつつ、既存のJetBrains AI Assistantと合わせて複数のAIエージェントを使い分けられる環境を提供する形となった。

概要 Rustチームは7月16日、Rust 1.97.0のリリースからわずか1週間というごく短い間隔でポイントリリース版の1.97.1を公開した。今回の修正の対象は、LLVMの最適化処理に起因する誤コンパイル(miscompilation)の問題で、正当なRustコードが最適化ビルド時に不正な機械語へとコンパイルされてしまう重大なバグだった。公式ブログでは「Rust 1.97.1 fixes a miscompilation in an LLVM optimization」と説明されており、開発チームはLLVM側の修正をバックポートするとともに、1.97.0で誤コンパイルの発生確率を高めていたRustのIR生成の変更を無効化する対応を取った。 技術的な詳細 問題はGitHub上のissueで報告されており、異なるサイズを持つバリアント(BigとSmall)を含む列挙型と構造体をネストさせ、map()を用いた複雑なパターンマッチ処理を行うコードで再現する。最適化フラグ-Oを有効にしたx86-64ターゲット向けビルドで発生し、本来Noneを返すはずの関数がセグメンテーションフォルトでクラッシュするという深刻な症状を引き起こしていた。この不具合はRust 1.97.0のほか、当時のベータ版1.98.0やナイトリー版1.99.0でも確認された一方、1.96.1では発生しない「回帰バグ」であることが判明し、Critical(重大)の優先度が付けられていた。 背景 チームの調査によれば、この誤コンパイルを引き起こす根本的な問題自体は少なくともRust 1.87の時点から存在していたという。しかし普段は表面化しない条件であったところ、Rust 1.97.0で行われたIR生成方法の変更によって、問題が顕在化する可能性が大幅に高まってしまった。これを受けてRustチームは通常のリリースサイクルを待たず、LLVM側の修正の取り込みと該当変更の無効化を行った緊急のポイントリリースとして1.97.1を送り出した。 今後の展望 Rustチームは今回のような回帰バグの早期発見のため、ユーザーに対してrustup default betaやrustup default nightlyによるベータ・ナイトリーチャネルでのテストへの協力を呼びかけている。問題を発見した場合はGitHub上でのバグ報告を推奨しており、今回のケースのようにリリース後短期間で重大な誤コンパイルバグが是正されたことは、リリースプロセスの検証体制が機能していることを示す事例といえる。

概要 マイクロソフトは、.NET 8と.NET 9が2026年11月10日に同時にサポート終了となることを発表した。この日はマイクロソフトの月例パッチ適用日（Patch Tuesday）にあたり、当日までに重大な既知の問題があれば最後の更新が配信される可能性があるという。両バージョンとも本来はリリース時期が異なるが、サポートモデルの違いにより終了日が偶然重なる形となった。 なぜ同時に終了するのか .NET 8は2023年11月にリリースされた長期サポート（LTS）版で、36ヶ月間のサポート期間が設けられている。一方の.NET 9は標準サポート（STS）版であり、以前は18ヶ月だったSTSのサポート期間が24ヶ月に延長された結果、.NET 8のLTSサポート終了と.NET 9のSTSサポート終了がほぼ同時期に到来することになった。LTSとSTSでリリース間隔もサポート期間も異なる両バージョンが同一の終了日を迎えるのは、こうしたサポートポリシー上の巡り合わせによるものだ。 移行への影響とセキュリティリスク サポート終了後、マイクロソフトは両バージョンに対してセキュリティ更新の発行、バグ修正、技術サポートの提供を一切行わなくなる。サポート切れの.NET上でアプリケーションを稼働させ続けると、新たに発見される脆弱性に対する修正が提供されないため、セキュリティリスクが高まる。特に.NET 8を採用している企業は多く、LTSという位置づけから長期利用を前提に導入したケースも多いため、想定より早い移行判断を迫られる可能性がある。 推奨される移行先と対応方法 マイクロソフトは、2028年11月までサポートが続くLTS版の.NET 10への移行を強く推奨している。移行作業自体は比較的シンプルで、プロジェクトファイルのTargetFrameworkプロパティをnet10.0に変更することで対応できるとしている。ただし、実際の移行では依存パッケージの互換性確認やAPIの非推奨対応など追加の検証も必要になるため、開発チームは2026年11月の期限を見据えて早めに移行計画を立てることが望ましい。

概要 Microsoftは2026年7月15日、Visual Studio Codeの最新版「1.129」をリリースした。目玉となるのは、CopilotやClaude、Codexといったエージェントハーネスを専用プロセス上で実行する新アーキテクチャ「Agent Host」の導入である。あわせて、チャットメッセージの先頭に!を付けることでその内容をターミナルコマンドとして直接実行できる機能や、Agentsウィンドウのレイアウト改善など、AIエージェントを軸とした開発体験の強化が図られている。 Agent Hostアーキテクチャの詳細 Agent Hostは、エージェントハーネスを動かすための専用プロセスであり、「Agent Host Protocol（AHP）」に基づいて動作する。セッションが独立したプロセス上に存在するため、「セッションは自身のプロセス内で稼働するため、同一セッションを複数のVS Codeウィンドウから同時に接続・描画できる」という特性を持つ。これにより、異なるワークスペースを開いた複数ウィンドウ間で同じエージェントセッションの進行状況を確認したり操作したりすることが可能になる。 この機能はchat.agentHost.enabledという組織レベルで管理される設定によって有効化され、エディタやAgentsウィンドウのハーネスドロップダウンから利用するエージェントを選択する形で使う。対応するハーネスとしてCopilot、Claude、Codexの3つが明示されており、Copilotエージェントは「Copilot SDK」によって動作し、Copilot CLIやスタンドアロン版のGitHub Copilotアプリと挙動を揃えているという。Claudeをエージェントハーネスとして使う場合は、chat.agents.claude.preferAgentHostという専用設定を有効にする必要がある。なお、Agent Hostは現時点でも開発が継続中であり、Microsoftは段階的にユーザーへの展開を進めている段階としている。新機能の一部は、エージェントがAgent Host上で動作している場合にのみ利用可能になる点にも注意が必要だ。 チャットからのターミナル操作 もう一つの主要な追加機能が、チャットメッセージに!を付けることでその内容をターミナルコマンドとして実行できる仕組みである。この機能はAgent Hostセッション上で動作し、エディタとAgentsウィンドウの両方で利用できる。これにより、エージェントとの対話の流れを崩さずに、コマンドの実行結果をその場で確認しながら作業を進めやすくなる。 その他の主要な変更点 このほか、Agentsウィンドウではsessions.layout.singlePaneDetailPanel設定により、チャットと編集パネルを1つのペインに統合した新しいレイアウトをプレビューできるようになった。エージェントが他のセッションを列挙・作成・監視・操作できるセッション管理ツールも追加され、複数タスクの並行処理がしやすくなっている。さらに、GitHub Enterprise環境でのCopilot利用対応、Agentsウィンドウでのカスタムモデル（BYOK）サポート、workbench.experimental.modernUI設定によるUI刷新版のプレビュー、workbench.diffEditorAssociationsによる差分エディタの割り当て設定に加え、ファイル・差分・マージエディタごとに優先度を指定できる提案API「customEditorPriority」など、エディタ全体にわたる改善が盛り込まれている。 今後の展望 Agent Hostはまだ開発途上の機能であり、対応ハーネスや利用可能な機能は今後のリリースを通じて拡充されていくとみられる。複数ウィンドウからの同一セッション接続という仕組みは、チーム開発や複数タスクの並行管理においてAIエージェントの活用範囲を広げるものであり、VS Codeにおけるエージェント統合の今後の方向性を示す重要な一歩といえる。

概要 Microsoftは7月8日、Visual Studio Codeの最新版となる「VS Code 1.128」をリリースした。目玉となるのは、1つの親セッションの中で複数の関連するチャットを並行して扱える「マルチチャットセッション」機能だ。Claudeなどのエージェントホストセッションにおいて、異なるアプローチを比較したり、途中のターンから分岐させたり、複数の作業を同時並行で進めたりできるようになった。各チャットはそれぞれ独立した履歴・タイトル・モデル選択を保持しつつ、一つのグループとしてまとめて管理されるため、作業がバラバラの独立セッションに分散してしまう問題を避けられる。あわせて、画像やPDFをチャットに添付できる「Copilot Vision」が正式にGA(一般提供)となったほか、VS Codeがフォーカスされていない状態でもコマンドを実行できる「OSレベルのキーボードショートカット」など、複数の機能強化が同時に投入された。 技術的な詳細 マルチチャットセッションでは、エージェントホストのセッション配下に複数の子チャットをぶら下げる形で管理する。各チャットは独自の会話履歴・タイトル・使用モデルを持てるため、たとえば同じタスクに対して異なるモデルやアプローチで並行して試行し、後から結果を比較するといった使い方が可能になる。セッション内の各チャットへは直接ディープリンクできるほか、複数チャット間を素早く移動するためのナビゲーションショートカットも用意された。 Copilot Visionは、チャットへの画像・PDFファイルの添付に対応する機能で、ペースト・ドラッグ&ドロップ・右クリックメニューのいずれからも添付でき、エージェントはツール呼び出しを通じてその内容を読み取れる。今回のリリースでプレビューを終え、正式に一般提供(GA)となった。 このほか、キーバインド設定にsystemWide: trueを指定することで、VS Codeがフォーカスを失っていてもコマンドを起動できる「OSレベルのキーボードショートカット」が導入され、Agentsウィンドウなどへの素早いアクセスに活用できる。ワークスペースに紐付かない「クイックチャット」も追加され、⌘K ⌘N(Linuxではcmd+K cmd+N)から起動可能で、特定プロジェクトに関係しない質問向けに、リロードをまたいで独立したセッションとして保持される。そのほか、カスタムエンドポイントに対する温度(temperature)やtop_pなどのサンプリングパラメータ設定、エージェントホストセッションでの実験的なBYOK(Bring Your Own Key)モデル対応、エンタープライズ向けのOpenTelemetryテレメトリ管理、ブラウザタブの配置先を選べるworkbench.browser.newTabPlacement設定なども今回のアップデートに含まれている。 今後の展望 マルチチャットセッションやBYOKモデル対応の実験的サポートは、複数のAIエージェントを組み合わせて開発を進める「マルチエージェントワークフロー」への対応を強化する動きの一環と見られる。Copilot VisionのGA化により、スクリーンショットや設計資料などの非テキスト情報を交えたやり取りがより日常的な開発フローに組み込まれていくことが期待される。

概要 元Heap CEOのMalcolm Matis氏は7月9日、個人プロジェクトとして開発しているPostgreSQLのRust書き直し「pgrust」が、PostgreSQL 18.3の回帰テスト4.6万件以上に全件パスし、さらに分離テストにも合格したことを発表した。pgrustはPostgres 18.3との完全互換を目標としており、既存のPostgres 18.3のデータディレクトリからそのまま起動できるディスク互換性も実現している。この発表はHacker Newsで740ポイント超・620件超のコメントを集める大きな反響を呼び、AIコーディングエージェントによる大規模ソフトウェアの書き換えがどこまで実用的かを示す事例として注目されている。 開発手法 pgrustの最大の特徴は、その開発プロセスにAIコーディングエージェントを大々的に活用していることだ。Matis氏はJason Seibel氏と共同で、8体の並列AIコーディングエージェント（Codex）を運用し、月額約1,600ドルのコストをかけて開発を進めた。並列セッションの調整には「Conductor」というツールを用い、10〜20個のセッションを同時に走らせることで、4月末までに45万行以上のRustコードを生成したという。 技術的な詳細 アーキテクチャ上の大きな変更点は、従来のPostgresが採用していたプロセス単位の接続モデルから、スレッド単位の接続モデルへの移行だ。これによりメモリ安全性の向上や接続数上限の問題解消が見込まれるが、Matis氏自身は「一つの接続でのクラッシュが他の接続に影響を及ぼす可能性がある」という新たなリスクも認めている。未発表のベンチマークでは、トランザクション処理でPostgres本体より約50%高速、分析ワークロードでは約300倍高速という主張もされているが、Matis氏は「v0.1は本番環境での使用には対応しておらず、パフォーマンス最適化も未実施」と明言しており、既存のPostgres拡張機能とも互換性がない段階にとどまる。ブラウザ上で動作を確認できるデモがpgrust.comで公開されており、ソースコードはGitHub上で公開されている。 反響と今後の展望 Hacker Newsでの反響は大きく、740ポイント超・620件超のコメントが寄せられた一方、fsyncの設定条件やClickHouseとの比較の妥当性について懐疑的な意見も多く出ている。OrioleDBの開発者であるBen Dicken氏は「まだ基準に達していない」と指摘するなど、成果の評価には慎重な声も少なくない。開発チームが掲げる目標は「Postgresの内部を変更しやすくすること」であり、Postgres本体の挙動を正解（oracle）としながらRustでコードベースの作業性を高め、AI支援プログラミングによってサーバーのより深い部分への変更を探求していく計画だとしている。