Programming Languages

概要 Racket言語コミュニティは8月13日、新バージョン「Racket v9.3」を公開した。今回のリリースには、racoツールへのMarkdown文書生成オプションの追加や、BSL・ISL+といった教育用言語のLanguageダイアログにおける機能パリティ達成、DrRacketの構文チェック高速化など、開発ツールの利便性と性能を高める変更が数多く盛り込まれている。リリースには28名の貢献者が参加しており、活発なコミュニティによる継続的な改善が続いている。ダウンロードは公式サイト（download.racket-lang.org）から可能だ。 開発ツールとドキュメントまわりの改善 今回の目玉の一つが、racoコマンドに追加された--doc-markdownオプションだ。これによりracoからMarkdown形式のドキュメントを直接生成できるようになり、GitHubなど外部プラットフォーム向けのドキュメント整備がしやすくなった。また教育用途で使われる#lang言語（BSL、ISL+など）は、DrRacketのLanguageダイアログにおいて他の選択肢と機能的に同等になり、推奨選択肢としての位置付けが明確化された。あわせてDrRacketでは、バックグラウンドでの式展開時にerrortrace注釈を無効化することで、構文チェックの速度が向上している。 パッケージ管理・ライブラリ・ランタイムの拡張 パッケージ管理面では、raco pkg installに--adjacent-deps、--destdir、--attachという新しいオプションが加わり、依存関係の配置やインストール先の制御が柔軟になった。ライブラリ面では、ffi/unsafe/runtime-libがソースファイルからの相対位置でライブラリを参照できる新しい仕組みを提供する。ネットワーク周りでは、tcp-listen 0が「address in use」エラー発生時に自動的にリトライするようになり、堅牢性が向上した。さらにfile/zipパッケージでは、メモリ内のファイルソースを扱えるようになったほか、ファイル単位で圧縮の有無を制御できるメカニズムが追加されている。継続処理（continuation）関連の複数の関数についても、プロンプトタグの扱いを中心に機能強化が行われた。 パフォーマンスと今後の展望 内部的な最適化として、racket/baseが必要とするモジュール数とそのインスタンス化数が削減され、起動時のオーバーヘッド軽減につながっている。今回のリリースは大きな目玉機能を一つ打ち出すというよりも、開発ツールの使い勝手・教育用途での一貫性・ランタイムの堅牢性といった多方面にわたる地道な改善を積み重ねた内容といえる。Racketは今後もコミュニティ主導での継続的な機能拡充が見込まれ、次期バージョンでも同様に幅広い改善が期待される。

概要 Googleは8月12日、クロスプラットフォームUIフレームワークFlutterの新バージョン3.47をリリースした。今回の目玉は、UIウィジェット群であるMaterial UIとCupertino UIパッケージが正式に1.0へ到達し、コアSDKから分離されたことだ。これにより開発者はFlutter SDK本体をアップグレードすることなく、最新のMaterialおよびCupertinoウィジェットのスタイルを個別に利用できるようになった。移行はdart fix --apply --code=migrate_design_widgetsコマンドで自動化されており、既存プロジェクトも比較的スムーズに対応可能だ。 デスクトップ向けレンダリングエンジンImpeller 次世代レンダリングエンジンImpellerが、macOS・Windows・Linuxのデスクトップ環境でデフォルトのレンダラーとなった。Impellerは実行時のシェーダーコンパイルを排除する設計になっており、アプリ起動直後の初フレームからシェーダーコンパイルに起因するカクつきがなく、滑らかなアニメーション体験を実現する。あわせてデスクトップでのテキストレンダリングにSignedDistanceFunction方式が採用され、より鮮明な文字表示が可能になった。 プラットフォーム別の変更 iOS/macOSでは対応バージョンの引き上げが行われ、iOSの最小対応バージョンは13から15へ、macOSは10.15から12へと変更された。あわせてiOS 27 SDK対応として、UISceneライフサイクルの採用が必須となる。macOSではApple Silicon移行の推進に伴い、Intel Macに対する自動テストが廃止された。またSwift Package Managerへの移行も進んでおり、利用の多いiOSプラグイン上位100件のうち92件が既に移行を完了しているという。 パフォーマンスと開発者体験の改善 WebAssembly対応では--wasmフラグによる有効化に加え、実験的機能として遅延ローディング(--enable-wasm-deferred-loading)がサポートされた。開発者向けにはWidget Previewにローカルキャッシング機能が導入され、.widget_preview/フォルダの活用によってセットアップ時のオーバーヘッドが削減されている。デスクトップでは複数ウィンドウ機能が強化され、ポップアップウィンドウのサポート、ウィンドウハンドルのクエリ機能、サイズ自動調整APIが新たに追加された。Androidでは仮想キーボードの修飾キーが固着する不具合も修正されている。 破壊的変更と今後の展望 一方で、flutter_localizationsパッケージがコアSDKからアンバンドルされ、GlobalMaterialLocalizations.delegatesを用いた新形式への移行が必要になる点には注意が必要だ。コアSDK内に残る設計ライブラリは11月予定のFall安定版で正式に廃止される見込みで、開発者は早めの移行が求められる。Googleは今後、WebAssemblyのデフォルト化やImpellerフォールバックの廃止、SwiftPMへの完全移行をさらに推進していく方針を示しており、Flutterのプラットフォーム基盤は今後も継続的に刷新されていく見通しだ。

概要 Microsoftは8月11日、Visual Studio 2026の最新アップデートとなるv18.9.0（August Update）をリリースした。今回の目玉はGit関連機能の大幅な強化で、開発者から特に要望の多かったワークツリー対応とサブモジュールのGUI管理がIDEに直接統合された。あわせてGitHub Copilotにも、モデルの思考量を調整できる機能や、GitHub組織単位でカスタムエージェントを配布できる機能などが追加され、AI支援開発とバージョン管理の両面でアップデートが行われた。 Gitワークツリーとサブモジュール管理のIDE統合 もっとも注目される変更は、Gitワークツリーのネイティブサポートだ。Git Repositoryウィンドウでブランチを右クリックし「New Worktree from」を選ぶことで、新規ブランチ・既存ブランチ・任意のコミット履歴のいずれからでもワークツリーを作成できる。作成したワークツリーは現在のウィンドウで開くほか、新しいVisual Studioインスタンスで開いてサイドバイサイド作業することも可能で、stashやリポジトリの再クローンなしに複数ブランチを並行して扱える。 サブモジュール対応も同様に「最も要求の多いGit機能の一つ」だったといい、Git Repositoryウィンドウ内に専用の「Submodules」セクションが新設された。ここからサブモジュールの追加・更新・削除が行え、ソリューションやフォルダを開いた際には自動的に検出・有効化される。デフォルトでは編集不可の読み取り専用として扱われ、編集を有効にするには「Tools → Options → Source Control → Git」から「Automatically activate multiple repositories」を「Yes, include submodules」に設定する必要がある。Microsoftはこれを最初のマイルストーンと位置づけており、今後のリリースでさらに機能を拡充する方針を示している。 このほか、複数ファイルにまたがる変更を単一のビューにまとめて表示する「マルチファイル統合差分表示」も追加され、Git Changesやコミット詳細、プルリクエストのビューでファイル間を行き来せずに変更範囲を素早く把握できるようになった。ファイルの過去バージョンと現在の作業ツリーを比較する「Compare with Working Tree」機能や、プルリクエストの必須承認・ポリシーチェック通過後に自動完了させる機能なども加わっている。 GitHub Copilotの機能拡充 GitHub Copilot側では、対応モデルに対して低・中・高の思考量（Thinking Effort）を選択できる機能が追加された。モデルピッカーやモデル管理ビューから設定でき、単純なコード提案には低負荷・低コストのLowを、複雑なアルゴリズムやアーキテクチャ判断が絡む場面では深い推論を行うHighを選ぶといった使い分けが可能になる。モデル管理ビューではコスト情報や機能仕様、コンテキストウィンドウサイズなどモデルごとの詳細も一元的に確認できる。 GitHub組織を保有するユーザー向けには、組織オーナーが組織全体に配布するカスタムエージェントをVisual Studioが自動検出し、エージェントピッカーに表示する機能が加わった。あわせて、Git Agentによる未コミット変更やコミット単位のコードレビュー機能も強化され、GitHubおよびAzure DevOpsの両リポジトリでインラインコメントによるレビューが行えるようになっている。プロンプトボックス右上のドーナツチャートからはCopilotのコンテキストウィンドウ使用量やプラン使用状況を確認でき、制限が近づいた際の通知も改善された。 セキュリティ更新とサポート終了情報 リリースノートでは、先行するv18.8.3で対応されたセキュリティアドバイザリも案内されている。QUICのUse After Freeによる情報開示(CVE-2026-62898)、HTTPリクエスト/レスポンススマグリング(CVE-2026-62899)、.NET Frameworkの整数オーバーフローに起因するリモートコード実行(CVE-2026-62897)、WindowsDesktop.AppのDirectWriteForwarder.dllに関するRCE(CVE-2026-70354)、Git for Windowsの脆弱性(CVE-2026-62960)など、計11件のCVEが修正されている。また、Git for WindowsがWindows 8.1のサポートを終了したことも告知されており、Windows 8.1環境ではGit for Windows単体コンポーネントが利用できなくなる。ただしVisual Studioインストールに組み込まれたGit機能自体への影響はないとされている。

概要 JetBrainsは2026年8月12日、Kotlin 2.4.20のリリース候補版（RC）を公開した。今回のRCでは、標準ライブラリへのコルーチン例外のスタックトレース復元機能やコレクションの要素チェック関数の追加に加え、Kotlin/NativeにおけるSwift Exportの強化、Kotlin/Wasmでの新たなランタイム対応、Kotlin/JSのブラウザテスト刷新など、プラットフォーム横断で多数の改善が盛り込まれている。正式版へ向けた最終確認段階の位置づけで、IntelliJ IDEAやAndroid Studioを最新版に更新した上で、ビルドスクリプトのKotlinバージョンを2.4.20-RCに変更することで試用できる。 標準ライブラリの改善 コルーチンのデバッグ性向上を目的として、新たにStackTraceRecoverableインターフェースが導入された。これは、コルーチンが例外をスローして再送出する際に、例外に紐づくスタックトレースの復元方法をカスタマイズできるようにするもので、copyForStackTraceRecovery()メソッドを実装することで、例外の再構築ロジックを定義できる。利用には@OptIn(ExperimentalStdlibCoroutineSupportApi::class)によるオプトインが必要で、全ターゲットで利用可能だが、JVM上のkotlinx.coroutinesではすでに活用されている。 また、コレクション要素の性質を検証する実験的な関数として、allDistinct()（全要素が一意かを確認）、allDistinctBy()（指定したプロパティが一意かを確認）、allEqual()（全要素が同一かを確認）、allEqualBy()（指定したプロパティが全て同一かを確認）の4関数が新たに追加された。こちらも@OptIn(ExperimentalStdlibApi::class)が必要な実験的APIとなっている。 Kotlin/Native・Wasm・JSの強化 Kotlin/NativeのSwift Exportでは、Kotlinのsealedクラス階層をSwiftのenumにマッピングし、Swift側で網羅的なswitch文を書けるようになったほか、Swift側で実装したKotlinインターフェースをKotlin関数に渡す「逆方向インポート」パターンもサポートされ、プラットフォーム固有実装の受け渡しが容易になった。さらにassembleSharedXCFrameworkタスクがSwiftPM依存関係向けのPackage.swiftを自動生成するようになり、XCFrameworkの配布が簡素化される。 Kotlin/Wasmでは、Node.jsに加えて選択できる新たなスタンドアロンWebAssemblyランタイムとして、wasmWasiターゲット向けにWasmtime対応が追加された。加えて、@JsFun宣言内でのトップレベルrequire()はコンパイルエラーとなり、@JsModuleアノテーションやimport()式への移行が求められるほか、コンパニオンオブジェクトの初期化順序がJVMと同様にスーパークラス優先へと変更され、プラットフォーム間の一貫性が向上した。Kotlin/JSでは非推奨となったKarmaに代わり、Mocha・Webpack・Playwrightを組み合わせた新しいブラウザテストDSLが実験的機能として導入され、Chromium・Firefox・WebKitでのテストに対応する。 その他の変更点 Build Tools API（BTA）の対応範囲がKotlin/JS、Kotlin/Wasm、Kotlinメタデータにも拡大され、gradle.propertiesでのオプトインを経てKotlin 2.5.0でのデフォルト化が予定されている。また、標準のkotlincより高速な起動とパフォーマンスを実現する、ネイティブコンパイライメージの初の実験的リリースも行われた。Serialization、Compose、All-openなど主要なコンパイラプラグインをバンドルしており、GitHub Releasesから入手できる。今回のRCは正式リリースに向けた最終検証段階であり、フィードバックを踏まえて安定版への反映が進められる見込みだ。

概要 Microsoftは8月11日、.NET 11の7番目のプレビュー版となる「.NET 11 Preview 7」を公開した。今回の目玉は、dotnet CLIにおけるNativeAOTのデフォルト有効化だ。NativeAOTはアプリケーションをネイティブコードへ事前コンパイルする仕組みで、これまではオプトインの機能だったが、Preview 7からはCLI経由での利用時に標準で有効になる。あわせてMSBuildサーバーもデフォルトで有効化され、ビルドのパフォーマンス向上が図られている。.NET 11の正式リリースは2026年11月を予定しており、SDKはdotnet.microsoft.comから、あるいはVisual Studio 2026 Insidersをインストールすることで試用できる。 C# 15の新機能 言語面ではC# 15に新しいパターンマッチング機能が加わった。「ユニオンパターン」はユニオン型そのもの、またはその値のいずれにもマッチできる「Try-Both」方式のマッチングアプローチを採用しており、より柔軟な条件分岐の記述が可能になる。また、ラベル付きbreak文とラベル付きcontinue文がサポートされ、ネストしたループの外側から直接抜け出したり、特定のループへ制御を戻したりできるようになった。型パラメータが閉じた型に制限されている場合の網羅性チェックも改善されており、パターンマッチングの安全性が高まっている。 ランタイムとツールチェーンの改善 ランタイム面では、非同期メソッドのコンパイル方式が刷新された。従来「ランタイム非同期」はコンパイル速度を優先したTier 0コードのみで実行されていたが、Preview 7からは段階的コンパイルパイプラインを通じてコンパイルされるようになり、実行時のパフォーマンス向上が期待できる。また、CoreCLRのWebAssembly対応も進展しており、Preview 6での起動成功に続き、Preview 7ではCoreCLRライブラリのテストスイートをエンドツーエンドで実行できるようになったと報告されている。 ツールチェーン面では、dotnet testコマンドに--timeoutと--maximum-failed-testsオプションが追加され、CI環境などでテスト実行を柔軟に制御できるようになった。MAUI、Android、iOS向けのテスト機能拡張や、Blazorアナライザーの5種類の追加、HTTPコンテンツの圧縮ラッパー(GZip、Brotli、Zstandard)対応なども盛り込まれている。このほか、ライブラリではIEEE 754準拠の10進浮動小数点型がサポートされ、ASP.NET CoreのBlazorでは回路の自動一時停止機能が、Entity Framework Coreではクエリ変換の改善が、Windows Formsでは視覚スタイルの改善が行われている。 今後の見通し .NET 11は2026年11月の正式リリースに向けて開発が進んでおり、今回のPreview 7はその重要なマイルストーンの一つとなる。NativeAOTのCLIデフォルト化は、起動速度やデプロイサイズを重視する開発者にとって特に注目される変更であり、正式版までにさらなる安定化や対応範囲の拡大が見込まれる。C# 15の新パターンマッチング機能についても、正式リリースまでにフィードバックを踏まえた調整が加えられる可能性がある。

概要 PHP開発チームは8月11日、次期メジャーバージョンとなるPHP 8.6.0のBeta 1をJoe Ferguson氏名義でタグ付け・公開した。PHP 8.5.0のリリースからおよそ9カ月というこれまで通りのリリースサイクルに沿ったもので、目玉となるのは部分関数適用(Partial Function Application)、ストリーム多重化を刷新するネイティブポーリングAPI「Io\Poll」、そしてナノ秒精度の時間間隔を扱うTime\\Durationクラスの3つの新機能だ。これに加えて、標準ライブラリ全体でエラー処理を厳格化する変更が数多く盛り込まれており、記事は今回のリリースを「PHPの厳格化時代の到来」と表現している。 主な新機能 部分関数適用は、引数の一部を?というプレースホルダーで残し、...で残余引数をまとめて受け取れるようにする機能で、部分的に適用した関数オブジェクトを生成できる。型ヒントや戻り値の型はリフレクションを通じて保持される仕組みで、対応するRFCは33対0という圧倒的多数で可決された。 Io\\Pollは、長らく使われてきたstream_select()を置き換えるネイティブI/O APIで、LinuxのepollやmacOS/BSDのkqueue、Solarisのevent ports、WindowsのWSAPollといった各プラットフォーム固有の仕組みを内部で使い分けて最適化を図る。あくまで「ポーリング機構であり、完全なイベントループではない」点が特徴だが、ReactPHPやAmpHP、Revoltといった非同期処理ライブラリがバックエンドとして採用していくとみられている。 もう一つの目玉であるTime\\Durationは、finalかつreadonlyなクラスとしてナノ秒精度の時間間隔を扱えるようにするもので、ISO 8601形式のパースに対応し、sleep()とも直接連携できる。 エラー処理の厳格化と非推奨機能 PHP 8.6では、これまで黙って処理を続けてきた挙動の多くが例外を投げるように変更される。たとえば文字列引数中のNULバイトはこれまで暗黙に切り詰められていたが、今後はValueErrorが送出される。array_filter()は不正なモード指定を拒否するようになり、pathinfo()やscandir()も失敗時に静かに処理を続けず明示的にエラーを出すようになった。sleep()やusleep()もプラットフォームの上限値でクランプされる。 セキュリティ関連のデフォルト設定も変更され、session.use_strict_mode、session.cookie_httponlyはいずれもデフォルトで1に、session.cookie_samesiteはデフォルトでLaxになる。このほか、戻り値を無視すると問題が起きうる関数に付与する#[\\NoDiscard]属性、スタンドアロン関数としてのclone()、クラス定数やenumケースにも対応した#[\\Override]属性の拡張、コンストラクタプロモートプロパティへのfinal修飾子の適用、参照返しに対応したパイプ演算子の強化なども追加される。 非推奨化の対象としては、MbregexおよびOnigurumaバックエンド、metaphone()、is_double()、doubleval()、spl_classes()やspl_object_hash()などのSPL関数が挙げられているほか、GMP演算子は暗黙の切り捨て挙動を失う。今回のBeta 1でAPIや挙動の変更点は概ね出そろった形であり、今後のリリース候補(RC)を経て正式版のリリースに向けて安定化が進む見通しだ。

概要 Node.js向けパッケージマネージャー「pnpm」の開発チームは8月9日、Rustによる全面リライト版となる「pnpm 12」のリリース候補版v12.0.0-rc.3を公開した。pnpm 12は2026年8月5日にRC0が公開されて以降、rc.1、rc.2と短い間隔で改善が重ねられており、rc.3では「シェバングを持たないバイナリやインタープリタなしで実行されるターゲット（マネージドNode.jsランタイムなど)に対し、コマンドシムがwaitではなくexecするよう修正され、SIGKILLなどのシグナルで終了したプロセスが誤った終了コード(137など)として報告される問題」が修正された。 技術的な詳細 pnpm 12はTypeScriptで書かれてきた従来のpnpmの内部実装をRustで刷新するプロジェクトで、コード名「Pacquet」として開発が進められてきた。メンテナーのzkochan氏によれば、v12における破壊的変更は最小限に抑えられており、v11と基本的に同じ挙動を維持しつつ、最大の変更点は内部実装のRustへの全面書き換えである点だとしている。実際、公式ブログ「What’s different in pnpm 12」でも、コマンド・フラグ・設定・ロックファイル形式はv11から引き継がれ、既存ドキュメントがそのまま両バージョンに適用できるとされている。 もっとも、いくつかの挙動の違いも明記されている。まず、グローバルにインストールされたNode・Deno・Bunを実行する際、常にグローバル版が使われるのではなく、プロジェクトがpin留めしたバージョンのランタイムが優先して使われるようになった。また、GitHubなどでホストされたGit依存関係の解決方法が変更され、指定子が単なる「選択肢」ではなく一意の「アイデンティティ」として扱われるようになった。さらに、pnpm install --resolution-onlyフラグは廃止され、代わりに新設されたpnpm peers checkコマンドを使う必要がある。開発チームの説明によれば、Rustエンジン(Pacquet)への切り替えにより、パッケージのフェッチとリンク処理などの内部処理がネイティブコードで実行されるようになり、体感速度の大幅な向上が見込まれている。 背景と今後の展望 pnpmは効率的なディスク容量管理とシンボリックリンクベースのnode_modules構造で知られ、npmやYarnと並ぶ主要なJavaScriptパッケージマネージャーの一つとして広く使われてきた。今回のRustリライトは、既存のCLI体験やロックファイル互換性を保ったまま、内部処理をよりパフォーマンスの高い言語基盤に置き換える試みであり、単なるメジャーバージョンアップというより実装基盤の刷新に近い。開発は8月上旬にベータ版からRC版へと移行しており、rc.3ではプロセス終了コードの報告に関する細かな不具合修正が中心となっている。互換性維持を優先する方針が明言されていることから、既存のpnpm 11ユーザーにとっては大きな移行コストなしに恩恵を受けられる可能性が高く、今後のRC版を経て正式版のリリースが待たれる。

概要 Modularは8月11日(米国時間)、Python風の高性能プログラミング言語「Mojo」の安定版1.0を正式リリースした。2023年の公開以来、初めての安定版リリースとなる。開発チームは「Mojoはもはや開発中の言語ではなく、我々が日々プロダクションで頼りにしている言語になった」と述べており、同社のMAXやModular Cloudといった商用インフラの基盤としてすでに実運用されていることを強調した。Mojoは、Pythonの読みやすさとアクセシビリティを保ちながら、Rustのようなメモリ安全性とC/C++レベルのシステムプログラミング機能を兼ね備えることを目指す言語で、CPU・GPU・ASICなど異種ハードウェアにまたがる高性能コードを単一の言語で記述できる「AI時代のシステム言語」と位置付けられている。開発をリードするのは、LLVM、Clangコンパイラ、Swift、MLIRの生みの親として知られるChris Lattner氏だ。 技術的な詳細 1.0リリースでは、これまで複数の書き方が併存していた言語仕様が整理・統一された。変数宣言はvarに一本化され、クロージャの表現も統合、ポインタ型も単一の形に整理された。新たにPython風の「lambda」構文によるインラインクロージャがサポートされたほか、List.appendが既存の参照を無効化するケースなどを検出するメモリセーフティ診断機能も追加された。開発体験の面では、VS Code連携を含む言語サーバープロトコル(LSP)の実装が大幅に改善されている。オープンソース化された標準ライブラリには、これまでに約190人のコントリビューターから1,100件を超えるプルリクエストが寄せられ、20万行以上のコードが変更されたという。Modularは「1.xの期間中、変更は基本的に追加的なものにとどめる」と表明しており、C++のような成熟した言語と同様、破壊的変更を慎重に管理する互換性方針を掲げている。同時にリリースされたMAXフレームワークのバージョン26.5では、必要な依存関係のみを選択インストールできるようインストール手順が簡素化されたほか、GLM-5.2やMamba-2ハイブリッドモデルのNemotron-Hへの対応も追加された。 背景と今後の展望 Mojoの核となる目標は、NvidiaのCUDAやAMDのROCmといったベンダー固有プラットフォームへの依存を減らし、異なるGPU・CPU・ASICなど異種システムを横断する統一的なAI開発環境を提供することにある。この文脈で注目されるのが、Modularが2026年6月にQualcommに買収された点だ。この買収を受けて、開発者コミュニティの一部からはMojoが「ベンダー中立的なAI開発プラットフォーム」であり続けられるのかという懸念の声が上がっていた。Modularはこうした懸念を払拭する動きとして、Mojoコンパイラとツールチェーンを2026年中に完全オープンソース化する方針を改めて明言している。標準ライブラリはすでにApache License 2.0(LLVM例外付き)で公開されており、Lattner氏は「Nvidiaをはじめとする各社がオープンソースコードに大規模に貢献しており、ベンダー間の干渉が働く余地は小さい」と述べ、中立性への懸念を否定した。今後の言語ロードマップとしては、堅牢な非同期プログラミングモデルや、パターンマッチング、ユニオン型といった機能の追加が予定されている。コンパイラのオープンソース化がいつ、どのような形で実現するかが、Mojoがベンダー中立なAI基盤言語としての信頼を維持できるかを占う重要な焦点となりそうだ。

概要 Rust開発チームは、次世代の借用チェッカー(borrow checker)「Polonius Alpha」をnightly版のコンパイラで有効化し、年内の安定化に向けたコミュニティによる実地テストを開始した。Rust開発者のJack Hueyによれば、現時点で既知の重大な性能低下やセキュリティ上の問題は確認されておらず、安定化を進めるのに十分な水準に達しているという。ユーザーはGitHubやZulip上のRustコミュニティを通じて問題を報告できる。 借用チェッカーとPoloniusの役割 借用チェッカーはRustコンパイラの中核をなすコンポーネントで、メモリ安全性をコンパイル時に保証するために参照に関する厳格なルールを強制する。具体的には、すべての変数が使用前に初期化されていることの確認、値の二重移動の防止、値が借用されている間の移動の禁止、可変借用中の他アクセスの制限、不変借用中の変更の防止といったチェックを行う。Poloniusはこの借用チェッカーを置き換える次世代実装であり、現行の非字句的ライフタイム(NLL: Non-Lexical Lifetimes)チェッカーでは借用エラーとして弾かれてしまう、実際には安全なコードパターンをより広く受理できるように設計されている。 開発の経緯と技術的な位置付け Polonius自体の開発は2018年から続く長期プロジェクトで、当初はDatalogベースの解析エンジンとして構想されていた。2023年になって新たな定式化が提案され、これによって既存のNLL実装を最小限に再構築するだけで実現できる見通しが立った。この新しいアプローチは拡張性を備えており、将来的にさらに多くの健全(sound)なコードパターンをコンパイル可能にする土台としても位置付けられている。今回nightly版で有効化されたのは、この再構築版の「Polonius Alpha」にあたる。 今後の見通し 安定化のスケジュールとしては2026年後半が見込まれている。従来のNLLチェッカーへの切り替え方法も引き続き提供されており、必要であれば設定ファイルでPoloniusを無効化することも可能だ。今回のnightly版での試験導入は、より広いユーザー層からのフィードバックを集め、安定版へのマージ前に潜在的な問題を洗い出すことを目的としている。

概要 GPU向けネイティブソフトウェアを手がけるVectorWareは8月10日、Rustの標準ライブラリが提供するポータブルSIMD(core::simd)をGPU上でそのまま実行できるようにしたと発表した。これにより、開発者はCPUとGPUの両方で修正なしに動作する、アーキテクチャに依存しない高性能なコードを記述できるようになる。VectorWareはこれまでRustのスレッドやasync/awaitをGPU環境に実装してきた実績を持ち、チームにはRustコンパイラチームのメンバーも参加している。 技術的な仕組み 今回の実装の核となる洞察は、GPUの実行単位である「warp」(32レーンで構成される並列実行グループ)が、本質的には単なるベクターユニットとみなせるという点だ。SIMT(Single Instruction Multiple Thread)の実行モデルはSIMDと本質的に同じであるとし、たとえば32個のf32を含むSimd<f32, 32>は、warpの32レーンそれぞれに1要素ずつ配置される。 要素ごとの加算・乗算といった操作は、Rust標準のAddなどのトレイト実装を通じて自動的にwarp命令へマッピングされる。reduce_sum()のようなリダクション処理はGPUのwarp shuffle命令でレーン間のデータ交換を行い、simd_swizzle!によるクロスレーンシャッフルも同じシャッフルプリミティブを利用する。またMask<T, N>はwarpレーン内の述語を表現し、vote/ballot命令に対応させることで、ループカウンターのようなスカラー値は全レーンで同一に計算される「uniform」として扱われる。これはISPCなど既存のデータ並列言語の概念を、Rustの型システムに組み込んだ格好だ。 VectorWareはwarpを独自の小さな「マシン」と捉え、Rustのジェネリクスやconst generics、トレイト境界を活用して中間表現(IR)を実装した。このIRはインタープリターを介さず、手書きPTXと同等のコストでネイティブ命令へ直接コンパイルされる点が特徴で、同じIRはCPU上でも実行可能であり、決定的な参照実装インタープリターとしても機能する。 対応アーキテクチャと制限事項 現時点ではNVIDIA GPUを主なターゲットとしているが、AMDのwavefrontやVulkanのsubgroupも同様のプリミティブを公開しており、この仕組みはCUDA固有のものではないとされる。IRはアーキテクチャに依存しない設計を志向している。 一方で、ポータブルSIMD自体がRustではまだ不安定な機能であり、利用には#![feature(portable_simd)]が必要となる。またwarp幅より狭いベクターを使うとレーンが遊んでしまい、逆に幅の広いベクターではより多くの命令が必要になる。任意の順列によるシャッフルは複数命令やshared memoryへのアクセスを要する場合があるなど、パフォーマンス面での制約も残る。「抽象化のコストはゼロ」とうたう一方で、warp幅に一致しない場合はコストが増加するとも注記されている。 今後の展望 VectorWareは、スレッド(warp間の並列性)、core::simd(レーン内の並列性)、非同期処理(並行性)を組み合わせた複合的な抽象化や、行列形状のSIMDを扱うテンソルコア対応、スカラーループを自動的にSimd操作へ変換する自動ベクトル化、CPU/GPUで共通のベクター表現の確立などを今後の課題として挙げている。将来的には複数のプログラミング言語やランタイムへの対応も視野に入れているが、高性能かつ信頼性の高いGPUネイティブアプリケーションの構築においてはRustが最適だとの見解を示している。