Programming Languages

概要 CPythonへのRust統合を進めるコミュニティが2026年4月8日に進捗レポートを公開した。最大の変更点は、当初のターゲットだったPython 3.15からPython 3.16へとマイルストーンを後ろ倒しにしたことだ。これにより開発・議論のための時間を十分に確保し、3.16のベータ1が予定される2027年5月までに、コミュニティが変更内容を十分に議論できる体制を整えるという。 達成済みのマイルストーン 最も大きな成果はビルドシステムの完成だ。フォーク上のCPython CIで、全テスト対象プラットフォームにわたってRustを含むクロスプラットフォームコンパイルが正常に動作することを確認した。また、Rustチームとの協力体制を構築し、統合上の技術的課題への対処を進めている。さらに、GitHubのIssueに「api-design」ラベルを付けてRust向け内部APIの設計議論を開始しており、将来のPEP提案の基礎固めが着実に進んでいる。 今後のロードマップ プロジェクトは2026年3月から7月にかけてのロードマップを示している。4月以降はRust API設計の計画立案と拡張モジュールの実装対象の選定を行い、5月にはAPIの設計を固めて実装に着手するとともに、PyConUS スプリントでの活動を予定している。6月からはPEP草稿の作成を始め、7月中に草稿を完成させてコミュニティに提出する計画だ。コミュニティへの参加は公式Discordで受け付けており、毎週月曜日12:00 PDTに定例ミーティングを開催している。 今後の展望 Python 3.16への組み込みが実現すれば、CPythonの内部実装にRustが正式採用される初のケースとなる。ビルドシステムの整備完了という基盤を踏まえ、今後数ヶ月のAPI設計とPEP策定が統合の成否を大きく左右する局面に入る。Pythonコアチームとの連携を深めながら、段階的かつ慎重に統合を進める方針が明確にされており、大規模言語実装へのRust採用という前例のない取り組みに注目が集まっている。

概要 Rustプロジェクトは2026年4月30日、Google Summer of Code（GSoC）2026の採択プロジェクトを発表した。今年は96件の応募が集まり、前年比50%増という記録的な数字を達成。その中から13件のプロジェクトが採択された。応募増加の一方でAI生成による低品質な提案も増加しており、メンター陣は応募者との事前のやり取り・過去の貢献実績・提案の質・プロジェクトへの重要性・メンターのキャパシティといった複数の基準で選考を行った。 採択された13プロジェクト 採択プロジェクトはコンパイラ、標準ライブラリ、ツールチェーンにまたがる多岐にわたる領域をカバーしている。 A Frontend for Safe GPU Offloading in Rust（Marcelo Domínguez、メンター: Manuel Drehwald） Adding WebAssembly Linking Support to Wild（Kei Akiyama、メンター: David Lattimore） Bringing autodiff and offload into Rust CI（Shota Sugano、メンター: Manuel Drehwald） Debugger for Miri（Mohamed Ali Mohamed、メンター: Oli Scherer） Implementing impl and mut restrictions（Ryosuke Yamano、メンター: Jacob Pratt・Urgau） Improving Ergonomics and Safety of serialport-rs（Tanmay、メンター: Christian Meusel） libc: transition differing bit-width time and offset variants（Adam Martinez、メンター: Trevor Gross） Link Linux kernel and its Modules with Wild（Vishruth Thimmaiah、メンター: David Lattimore） Migrating rust-analyzer assists to SyntaxEditor（Shourya Sharma、メンター: Chayim Refael Friedman・Lukas Wirth） Port std::arch test suite to rust-lang/rust（Sumit Kumar、メンター: Jakub Beránek・Folkert de Vries） Reorganizing tests/ui/issues（zedddie、メンター: Teapot・Kivooeo） Utilize debugger APIs to improve debug info（Anthony Bolden、メンター: Jakub Beránek・Jieyou Xu） XDG path support for rustup（Guicheng Liu、メンター: rami3l） GPU オフロードや WebAssembly リンク、自動微分（autodiff）、デバッガ改善、rust-analyzerのリファクタリングなど、Rustエコシステムの実用性と品質向上を目指すテーマが並んでいる。 ...

概要 Rubyコミッターとして知られる遠藤侑介氏が、13のプログラミング言語を対象にClaude Codeのコーディング効率を比較する大規模ベンチマークを実施し、その結果を公表した。600回以上の実行からなる本研究では、「簡略化されたGitの実装」という共通タスクを各言語で20回ずつ実行し、生成コストと処理時間を計測した。結果として、Ruby・Python・JavaScriptなどの動的言語が静的型付き言語より1.4〜2.6倍速く、かつ低コストであることが示された。AIによるコーディング補助において、言語の選択がパフォーマンスとコストに定量的な影響を与えることを示した注目の研究となっている。 ベンチマーク結果 各言語の1回あたりのコストと平均実行時間の上位・下位は以下の通り。 動的言語がトップ3を占めた： Ruby: $0.36/回、73.1秒、分散低、成功率100% Python: $0.38/回、74.6秒、分散低、成功率100% JavaScript: $0.39/回、81.1秒、分散低、成功率100% 一方で静的型付き言語は相対的に低い効率を示した： Go: $0.50/回、101.6秒（標準偏差37秒と高いばらつき） Rust: $0.54/回、分散大、テスト失敗あり C: $0.74/回、生成コード517行（Rubyの219行に対して） 型チェックのオーバーヘッドも計測されており、PythonにMyPy strict検査を適用すると1.6〜1.7倍、RubyにSteep型チェックを適用すると2.0〜3.2倍遅くなった。TypeScriptはJavaScriptと生成行数が近いにもかかわらず、コストはJavaScriptの$0.39に対して$0.62と約1.6倍高かった。 考察と限界 遠藤氏自身も認めているように、このベンチマークが測定しているのは「生成コストと速度」であり、コード品質・保守性・ランタイム性能は対象外である。またタスク規模は約200行程度のプロトタイプ開発に相当するものであり、大規模な本番コードベースでの結論を直接導くものではない。 コミュニティからも批判的な意見が寄せられており、各言語のエコシステムの充実度や標準ライブラリの豊富さといった利点が考慮されていない点や、プロトタイピングレベルの知見が大規模開発にそのまま適用できるかどうかについて疑問視する声がある。動的言語の生成コードが短くなりやすい一方で、実務上は型情報が長期保守において重要な役割を果たすという観点も見逃せない。 今後の展望 本研究は、AIコーディングツールの普及とともに「どの言語でAIに書かせるか」という問いが現実的な意味を持ち始めていることを示している。特に速度やコストを重視するプロトタイピングや自動生成パイプラインにおいては、言語選択の戦略的重要性が増すだろう。今後は、より大規模・複雑なタスクや複数のAIモデルを対象にした追加検証が待たれる。

概要 Java 26が2026年3月17日にリリースされ、Spring Boot開発者にとって実用的な改善が複数導入された。主な変更点はG1ガベージコレクターのパフォーマンス向上、標準ライブラリへのHTTP/3サポート追加、ファイナルフィールドへの不正な反射的変更への警告導入、そしてUUIDv7の標準APIサポートである。同時期にはSpring Boot 4.1.0-RC1をはじめとするSpringエコシステムの複数プロジェクトもリリースを迎えている。 Java 26の主要な新機能 G1 GCの大幅なスループット向上（JEP 522） G1ガベージコレクターが参照オブジェクトの追跡方式をデュアルカードテーブル方式へと刷新した。これにより、参照オブジェクトを多用するワークロードで5〜15%のスループット改善が見込める。設定変更は不要で、JDKをアップグレードするだけで自動的に恩恵を受けられる。 標準ライブラリへのHTTP/3対応 JDK付属のHttpClientがQUICプロトコル上のHTTP/3に対応した。利用するにはHttpClient.Version.HTTP_3を指定するだけでよく、HTTP/3が利用できない場合はHTTP/2へ自動的にフォールバックする。これまで外部ライブラリが必要だったHTTP/3通信が標準APIで実現できるようになった。 ファイナルフィールド変更への警告（JEP 500） フィールドの不変性の強制が始まった。Java 26ではリフレクションによるファイナルフィールドへの変更に対して警告が出力され、将来のリリースではエラーとなる予定だ。HibernateやMockitoなど一部のライブラリが影響を受ける可能性があるため、依存関係の互換性確認が推奨される。 UUIDv7の標準サポート UUID.ofEpochMillis()メソッドが新たに追加され、時刻順に並んだUUIDv7を生成できるようになった。ランダムなUUID v4と比べてデータベースのインデックス性能が向上し、挿入時のページ分裂を抑えられるため、主キーや連番IDの用途で有効に活用できる。 Springエコシステムのリリース動向 Java 26のリリースと前後して、Springエコシステムでも多くのプロジェクトが新バージョンを公開した。 Spring Bootではバグ修正版の3.5.14・4.0.6に加え、次世代版となる4.1.0-RC1がリリース候補として公開された。Spring for Apache Kafkaも4.1.0-RC1・4.0.5・3.3.15の3バージョンを同時リリースし、Spring AIでは1.0.6・1.1.5・2.0.0-M5と幅広いバージョン帯をカバーするリリースが行われた。そのほか、Spring Modulith 2.1 RC1・2.0.6・1.4.11、Spring Shell 4.0.2、Spring for Apache Pulsar 1.2.17・2.0.5、Spring Authorization Server 1.5.7も相次いで公開されている。 移行に関する考慮事項 Java 26はサポート期間が6ヶ月の非LTSリリースであるため、本番環境への採用にはJava 25 LTSをそのまま使い続けることが推奨される。一方で、CIパイプラインにJava 26を加えて依存ライブラリの互換性を今から確認しておくことは、将来のアップグレードをスムーズに進めるうえで有益だ。特にファイナルフィールド変更への警告は将来的にエラーとなるため、HibernateやMockitoなどリフレクションを多用するライブラリのアップデート対応状況を早めに把握しておくとよい。

概要 Microsoftは2026年4月30日、Visual Studio 2026 18.6 Insiders 3にてTypeScript 7 Betaをデフォルトの組み込みSDKとして有効化したことを発表した。これは、TypeScriptコンパイラをJavaScriptからGo言語でネイティブ実装し直す大規模なアーキテクチャ刷新の成果であり、IDEから直接その恩恵を受けられるようになる重要なマイルストーンである。独自のTypeScriptバージョンを指定していないすべてのTypeScript/JavaScriptプロジェクトがこの新しいネイティブコンパイラを使用するようになる。 パフォーマンスの大幅な向上 新しいネイティブコンパイラは、従来のJavaScript実装と比較して顕著なパフォーマンス改善をもたらす。大規模コードベースにおけるコンパイル時間は最大10倍短縮され、メモリ消費量も削減される。また、プロジェクトの読み込み時間は約8倍高速化された。 IDE上での体験においても、IntelliSenseや補完候補の表示が特に大規模プロジェクトで迅速になり、ソリューション全体を対象とした「すべての参照を検索」や「定義へ移動」のナビゲーションもより高速に動作する。コードを入力しながらリアルタイムにエラー診断が更新されるため、開発者の生産性が全体的に向上する。 バージョン管理と既知の制限 従来のTypeScript 6.xを引き続き使用したい場合は、npmでtypescriptパッケージをインストールするか、特定のネイティブバージョンには@typescript/native-previewパッケージを利用できる。機能を無効化する場合は、「ツール > オプション > プレビュー機能」から「Enable JavaScript/TypeScript Native Language Service Preview」をオフにすることで切り替え可能だ。 現時点ではプレビュー段階であるため、いくつかの既知の問題がある。.cshtmlのスクリプトタグ内でのIntelliSense補完が機能しない場合があること、クイックフィックスやコードリファクタリング機能が未実装であること、ナビゲーションバーにドキュメントシンボルが表示されないこと、CodeLensの参照カウントが宣言の上に表示されないこと、JSDoc自動生成が動作しないこと、ファイル・フォルダのリネーム時にimportが一貫して更新されないことなどが挙げられる。問題に遭遇した場合は、typescript-go GitHubリポジトリまたはVisual StudioのDeveloper Communityプラットフォームへのフィードバックが推奨されている。

概要 NestJS の作者 Kamil Myśliwiec 氏は、メジャーバージョン v12 のロードマップをドラフトプルリクエスト（PR #16391）として公開した。リリース目標は2026年Q3初頭とされており、CommonJS（CJS）から ECMAScript Modules（ESM）への完全移行を中心に、テストフレームワーク・リンター・バンドラーの全面刷新、そしてモダンなバリデーションライブラリのネイティブサポートなど、エコシステム全体に及ぶ大規模な変更が含まれる。この発表はX（旧Twitter）で800件を超えるいいねを集めるなど、コミュニティから大きな注目を浴びた。 ESM完全移行——Node.jsの「require(esm)」が後押し v12 最大の変更は、全公式パッケージを CommonJS から ESM へ移行することだ。Myśliwiec 氏は「Node.js の require(esm) サポートが、この移行に必要な最後のピースだった」と述べており、CJS コードから ESM モジュールを require() で読み込める Node.js の新機能が実現の鍵となった。これにより、既存の CJS ベースのプロジェクトは大幅な書き換えなしに v12 へ移行できる見込みで、互換性への懸念を最小限に抑えながら段階的な採用が可能になる。 新機能——Standard Schema によるネイティブバリデーション v12 では @Body・@Query・@Param などのルートデコレータに schema オプションが追加され、Standard Schema に準拠したバリデーションライブラリを直接利用できるようになる。これにより、従来の class-validator に代わって Zod・Valibot・ArkType といったモダンなライブラリを公式にサポートする。型安全なスキーマ定義ライブラリが急速に普及している近年のトレンドに対応した機能追加であり、既存の NestJS プロジェクトにおけるバリデーション層の柔軟性が大幅に向上する。 ツールチェーンの刷新——Vitest・Oxlint・Rspack テスト・リンティング・バンドリングの各レイヤーでデフォルトツールが入れ替わる。ESM プロジェクトではテストフレームワークが Jest から Vitest に切り替わる（既存の CJS プロジェクトは Jest を継続利用できる）。Vitest は TypeScript デコレータの処理に OXC を採用しており、ESM 環境との親和性が高い。リンターは Rust 製の高速ツールである Oxlint が ESLint に取って代わり、バンドラーは Webpack から Rspack へ移行してビルド速度の大幅な向上が見込まれる。コミュニティからは Bun や Biome の CLI オプションへの追加を求める声も上がっており、今後の検討が期待される。 ...

概要 JavaScriptテストフレームワークVitest 4.1が2026年5月1日にリリースされた。今回のリリースは「テスト整理」「ネイティブ実行」「AIエージェント最適化」の3つを主要テーマとして掲げており、Vite 8への完全対応も同時に提供される。VoidZeroがメンテナンスするVitestは、Jestと互換性のあるAPIを維持しながら、大規模プロジェクトでのパフォーマンスや開発者体験の向上を継続的に進めている。5万件のテストを持つプロダクションモノレポを対象にしたSitePointのベンチマークでは、コールドスタート・ウォッチモードの再実行・ピークメモリ使用量のいずれにおいてもJestを上回る結果が示されている。 テストタグとライフサイクルフックの強化 2025年10月から要望が挙がっていた機能として、Pythonのpytestマーカーに着想を得たテストタグ機能が搭載された。各テストにラベルを付与し、論理演算子やワイルドカードを用いて実行対象を柔軟に絞り込める。たとえば vitest --tags-filter='frontend && !flaky' と指定することで、フロントエンド向けテストのうち不安定なものを除外して実行できる。大規模コードベースでのテスト管理に大きく貢献する機能だ。 ライフサイクルフック面では、テストをコンテキストでラップするための aroundEach と aroundAll が新たに追加された。また test.extend ビルダーパターンの型推論が改善され、カスタムフィクスチャを利用する際の型安全性が向上している。CIとの連携を強化する github-actions レポーターも導入され、テスト統計やフレイキーテストのハイライトを含むJobサマリーをGitHub Actions上で自動生成できるようになった。 ネイティブNode.js実行モード（実験的） 実験的機能として、Viteのモジュールランナーサンドボックスをバイパスする viteModuleRunner: false オプションが追加された。これを有効にすると、Node.jsのネイティブインポートが使用されるため、起動速度の向上と本番環境により近い挙動が期待できる。Node.js 22.18以降または23.6以降を使用している場合、ネイティブのTypeScriptストリッピングが追加設定なしで利用可能となる。Bunとも動作するが、現時点ではモジュールモックとカバレッジ機能はサポートされておらず、今後の対応が見込まれる。 AIエージェント向けのagentレポーター AIコーディングエージェントによる開発ワークフローへの統合を意識した専用レポーター agent が追加された。AIエージェントがテスト実行結果を解析する際に消費するトークン数を削減することを目的に設計されており、LLMベースのコーディング支援ツール内でVitestを活用するユースケースを直接サポートする。 リリース後に確認された不具合 リリース直後に2件の問題が報告されている。1つ目は、カバレッジの無視ヒントに関するリグレッションで、@preserve アノテーションが必要となる挙動が確認された。2つ目は、更新されたViteのピア依存関係の記法によってYarn Classic（v1.x）での導入が壊れる問題だ。いずれも既知の問題として追跡されており、修正が進められている。

概要 GCC 16.1が2026年4月30日に正式リリースされた。今回のメジャーリリースで最も影響の大きい変更は、C++コンパイルのデフォルト言語標準がGNU++17からGNU++20へ引き上げられたことだ。これにより、-std=オプションを明示せずにコンパイルした場合、C++20の機能セットが自動的に適用される。既存のコードベースでC++17以前の動作に依存している場合は、-std=gnu++17などのオプション指定か、コード側の修正が必要になる。 C++26の先進機能についても実験的サポートが追加されており、リフレクション（Reflection）・契約システム（Contracts）・構造化バインディングの拡張・constexpr例外処理など、次世代標準の機能を先行して試せる環境が整った。 エラーメッセージと診断機能の大幅改善 GCC 16では、開発者体験を向上させる診断機能の強化が目立つ。これまで実験的オプションとして提供されていた階層的エラーメッセージ表示がデフォルト動作となった。テンプレートを多用するC++コードでよく発生する複雑なエラーが、インデントと箇条書きによるネスト構造で表示されるようになり、問題箇所の特定が格段に容易になった。従来の表示形式に戻す場合は-fno-diagnostics-show-nestingオプションを使用できる。 診断出力の形式も拡充されており、実験的機能としてHTML形式の出力（-fdiagnostics-add-output=experimental-html）が追加された。ブラウザで視覚的に制御フローや状態遷移を確認できるため、静的解析器のデバッグ作業などで効果を発揮する。また、機械可読なJSON形式のSARIF出力も強化され、名前空間・クラスの階層関係を保持する論理的ロケーション構造や、例外処理・longjmpを含む制御フロー情報の表現が追加されてSARIF 2.2標準に対応した。 静的解析器とその他の変更 静的解析器（-fanalyzer）では、C++言語のサポートが進み、例外処理とNRVO（Named Return Value Optimization）への対応が加わった。内部データ構造であるsupergraphの再設計やメモリバッファ追跡の改善も行われ、Rangerとの統合による値の範囲追跡機能の活用も開始している。ただし、複雑なC++コードに対するスケーリング問題は依然として残存しており、本番環境での使用はまだ推奨されていない段階だ。 互換性に関しては、Solaris環境でint8_t等がsigned charとなりC99標準準拠となったものの、非互換変更として注意が必要だ。C++20デフォルト化とあわせて、既存プロジェクトをGCC 16に移行する際には事前の動作確認を推奨する。

概要 Spring Modulithは2026年4月24日、バージョン2.1のリリース候補1（RC1）を公開した。2.1 RC1は最終GA（一般提供）リリースに向けた候補版であり、最近追加された機能の改良、バグ修正、プラットフォームのアップグレードに重点を置いている。同時に、現行安定ブランチの2.0.6および旧バージョンの1.4.11も、依存関係のアップグレードを中心としたバグフィックスリリースとして公開された。 2.1 RC1の主な変更点 2.1 RC1では複数の改善が施されている。 モジュールスライシングの強化（GH-1644）：@ModuleSlicingアノテーションが、明示的に宣言されたクラスの@SpringBootApplicationを優先するよう改善された。これにより、スライス境界の検出がより正確になり、テスト時のモジュール分離が意図どおりに機能しやすくなる。 JobRunrインテグレーションの改善（GH-1655）：JobRunrを利用した非同期ジョブ処理において、トランザクション処理が改善された。イベント駆動のバックグラウンドジョブとトランザクション境界の整合性が向上している。 イベントパブリケーションレジストリの改善（GH-1652, GH-1650, GH-1647）：イベント処理に関連する複数のissueが修正され、より堅牢なイベントパブリッシュ・受信の仕組みが実現された。 バグフィックスリリース（2.0.6・1.4.11） 安定版の2.0.6と旧安定版の1.4.11は、主に依存関係のアップグレードを含むバグフィックスリリースとして提供される。新機能は含まれていないが、セキュリティや互換性の観点から既存ユーザーへのアップグレードが推奨される。 今後の展望 2.1 RC1は最終的な2.1 GAリリースに向けた候補版であり、今後はコミュニティからのフィードバックを取り込みながら安定化が進められる見通しだ。各バージョンの詳細なチェンジログはGitHubのリリースページで確認できる。

概要 Astral社が開発するRustベースのPythonパッケージマネージャー「uv」は2026年4月27日、バージョン0.11.8をリリースした。本リリースでは、Astralミラーを介したself-updateサポートや、任意のミラーからPythonをダウンロード可能にする新フラグの追加など、使い勝手を向上させる複数の機能強化が含まれている。また、環境変数による設定オプションの拡充や、細かなバグ修正も行われた。 新機能と機能強化 最大の目玉の一つは、python pinコマンドへの--python-downloads-json-urlフラグの追加だ。これにより、デフォルト以外の任意のミラーから特定のPythonバージョンをダウンロードできるようになり、ネットワーク制限のある環境や社内ミラーを利用する場面での柔軟性が高まった。また、uv self updateがAstralミラーからuvそのものを取得する仕組みに対応し、更新の信頼性と速度が改善されている。 その他の機能強化としては、pip uninstall -y構文のサポート追加、uv self version --shortでバージョン番号のみを表示するオプションの追加、空のSSL_CERT_DIRディレクトリに対する不要な警告の抑制、exclude-newer-spanが存在する場合にexclude-newerの省略を許容するロックファイル処理の改善などがある。相対的なexclude-newer/exclude-newer-package値に対してはセンチネルタイムスタンプが使用されるようになった。 環境変数と設定の拡充 設定面では、新しい環境変数が3つ追加された。UV_PYTHON_NO_REGISTRYはWindowsレジストリを通じたPythonの自動検出を無効化し、UV_NO_PROJECTはプロジェクトファイルの探索を無効化する。さらにUV_PYTHON_SEARCH_PATHを使うことで、Pythonインタープリタの探索パスをカスタマイズできるようになった。これらの環境変数は、CI環境での動作の予測可能性を高めたい場合や、特定のPythonバイナリを確実に指定したいケースで役立つ。 バグ修正 バグ修正では、uv-buildのソースディストリビューションにrust-toolchain.tomlが含まれていなかった問題が修正された。uvからgitコマンドを呼び出す際にリポジトリの環境変数を引き継いでしまう問題も解消された。また、詳細ログに事前署名済みアップロードURLが平文で表示される問題が修正され、セキュリティが向上している。その他、PEP 517ビルド要件における推移的なURL依存関係の処理の修正、dependency-groupsのみを持つpyproject.tomlでのuv lockの動作改善、パッチバージョン指定時のPython自動アップグレードの無効化なども含まれる。なお、uv-buildのパッケージメタデータにPython 3.14のclassifierが追加され、PyTorchドキュメントもバージョン2.11向けに更新された。