C#の現在地 進化の歴史と、AI時代の.NET Everywhere

C# Kaigi 2026
https://csharpkaigi.net/

Transcript

1. C#の現在地 進化の歴史と、AI時代の.NET Everywhere 2026-09-19 C# Kaigi 2026 Yoshifumi Kawai / Cysharp, Inc.
2. About Speaker 河合 宜文 / Kawai Yoshifumi / @neuecc Cysharp, Inc. - CEO/CTO 株式会社Cygamesの子会社として2018年9月19日設立 C#関連の研究開発/OSS/コンサルティングを行う Microsoft MVP for Developer Technologies(C#) since 2011 CEDEC AWARDS 2022エンジニアリング部門優秀賞 .NETのクラスライブラリ設計 改訂新版 監訳 50以上のOSSライブラリ開発(UniTask, R3, MessagePack for C#, etc..) C#では世界でもトップレベルのGitHub Star(合計70000+)を獲得
3. Origin of C#
4. C#の始まり 2002 C# 1.0正式リリース
5. C#の始まり Anders Hejlsberg(Creator of TypeScript)入社 1996 Visual J++(魔改造Java)の開発を始める 2002
6. C#の始まり 1996 1997 Sun Microsystems(当時のJava開発元)に 魔改造はライセンス違反だと怒られる 2002
7. C#の始まり 1996 1997 1999 COOL(C like Object Oriented Language)開発開始 2002
8. C#の始まり C#の名前が初めて世に出る C++++でC# 1996 1997 1999 2000 2002
9. C#の始まり C# 1.0正式リリース 誕生の経緯から特に影響ある言語がPascal, Java, C++ 1996 1997 1999 C#は命名規則にPascalCaseを採用 AndersがMicrosoft入社以前に作成していた言語 環境「Turbo Pascal, Delphi」の血を感じる (J++ではJava流儀のためcamelCaseだった) 2000 2002 // camelCase public void fooMethod() { } // PascalCase public void FooMethod() { }
10. Evolution of C#
11. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span<T> Source Generators Union
12. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 C# 1.0で何が最も大事だったかと考えると、値型に思える。当時のオ Source Generics async/await Span<T> Generators ブジェクト指向の風潮として邪道とされていたものが、「ゲーム」と いった高性能を要求するユースケースでの適用や、後のパフォーマン ス強化のキーとなっていった。とはいえ最初期はGenericsもないため、 そこまで有効活用できるわけではなかった。 2026 C# 15 Union
13. C#の進化 C#のGenerics導入はすごい。というのも1.0から2.0で、いき なりのランタイムごと作り直しでReified genericsを導入し た(JVMは互換性を重視しtype erasure)。これにより値型が 真価を発揮し、現在まで続くパフォーマンスの基盤となっ 2019 2025 2007 2015 C# 8.0 C# 14 た。なおGenericsの設計はDon Syme(Microsoft Research、 C# 3.0 C# 6.0 Nullable Extension 後にF#を設計する)が主導した。 2002 C# 1.0 ValueType LINQ Roslyn / Analyzer reference types members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span<T> Source Generators Union 値型は特殊化、参照型はコード共有という特性があ り、パフォーマンスチューニング(後述)で、その違 いを意識するのが非常に重要になる。
14. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Source Generics async/await Span<T> Union C# 1.0のデリゲート（これも当時、値型と並んで邪道とされて Generators いた）がラムダ式に進化し、オブジェクト指向と関数型の融 合を果たした。これが有用なことは現代では当たり前ですが、 当時の主要言語では大胆な導入であり、LINQはReactive Extensionsというバリエーションも生み様々な言語に移植され ていくなど、C#の先進性をこれでもかというほどに示した。
15. C#の進化 言わずもがなのasync/awaitの発祥はC#（それ以前にも同じような 挙動をする仕組みがないわけではないが、特性や、そのネーミン 2019 2025 グなど、以降への他言語への影響C#が大元になっている） 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer C# 8.0 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span<T> Source Generators Union 初期は非同期I/Oを実現はするものの、必ずしもパフォーマン スに優れていたわけではなかったが、度重なる改修で、どん どん性能は良くなっていった。最新のC# 15/.NET 11でも Runtime Asyncが導入され、更なる進化を果たしている。
16. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span<T> Source Generators Union 2012年 TypeScript生誕 Anders Hejlsberg離脱 (Roslynの設計までは関わる)
17. C#の進化 2002 C# 1.0 2007 C# 3.0 TypeScript生誕秘話2019 2015 C# 6.0 C# 8.0 2025 C# 14 Nullable Extension Andersのもとに、JavaScriptの開発環境が辛い、C#のツール類(高機能なIDE、デ ValueType LINQ Roslyn / Analyzer reference types members バッガー、型チェックなど)をJavaScript開発で使いたいからScript#というC# to JavaScriptトランスパイラを作っている、見てくれ。という相談が来た。それな 2005 2012 2017 2020 2026 ら、そもそもJavaScriptを直せばいいのでは？という発想になり、そこから C# 2.0 C# 5.0 C# 7.x C# 9.0 C# 15 TypeScriptが生まれた。つまり、ただたんに言語作者が同じというだけではなく、 Source Generics async/await Span<T> Union C#のお陰でTypeScriptが生まれたというっても過言ではない！！！（？） Generators 2012年 TypeScript生誕 Anders Hejlsberg離脱 (Roslynの設計までは関わる)
18. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 Source Generics async/await Span<T> C#コンパイラーがC#で書かれる（かなり難産で時間かかった模 Generators 様）。コンパイラーAPIが公開されて、コンパイルパイプライン に乗っかる形でユーザーが自由に構文木を解析して、アプリケー ション固有のLintが書ける基盤となるAnalyzerや、構文木から コードを生成するSource Generatorをもたらした。のちの NativeAOTや、AI時代にめちゃくちゃ意味のある超重要な一手。 2026 C# 15 Union
19. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span<T> Source Generators Union .NET Core(クロスプラットフォーム化)と連動して、 ここから怒涛のパフォーマンス強化が始まった。 その最も重要な基盤がSpan<T>
20. C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 Source null安全性を後付けで気合で追加しきった。型にせよnull安全性にせよ、 Generators Generics async/await Span<T> オプショナルな後付けは、付与されていないものがいると意味をなさなく なるが、.NETの場合は数年かけてランタイム内部の100%付与(2021 年, .NET 6)を実現した。3rd Party libもそれに引きずられて、付与率はとて も高いので、もう後付けでも違和感はない、はず。 2026 C# 15 Union
21. 番外編 C# 4.0 Dynamic、当時、時代は動的言語みたいな風潮 があったので追加されたけど、もはや負債。C#初期は 神がかった奇跡の連鎖で、現代でも成立する基盤が整 備されていますが、たまには失敗もある……！ 2019 2025 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer C# 8.0 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span<T> Source Generators Union 10~13、色々追加されてはいますが、そ こまで大きなものはないので割愛（言語 的には成熟している、ともいえる）
22. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR
23. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR Miguel de Icaza(Ximian)により2001年に始まったOSS Linux対応、後にXamarinとしてiOS/Android対応を支える 現在はWineの下でProton(SteamOS)の.NET Fx互換を支えている
24. ランタイムの進化 C#の一般層向けアプリケーションや、若年層ユー ザーを支えるゲームエンジン。特にモバイル向けで のシェアが高いがコンソール向けも頑張ってます。 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR
25. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 膨大なソースコード・ドキュメント公開だけでなく、 意思決定もGitHub上で行う/残すようになった。これ がAI時代に強力な武器となっていく……！
26. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 独自のAOT基盤、これが早期のiOS対応だけ でなくコンソールゲーム機対応などにも繋 がっていく。現在も(Unity 7 CoreCLRでも)使 われ続けている。
27. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR C#はWindowsだけじゃない！と堂々と言えるように なった基盤。パフォーマンス比較がLinuxの同一ハー ドウェア上で平等に行えることになったこともよし。 現代ではC#サーバーは普通にLinuxで動かしてます。
28. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 乱立するターゲットフレームワーク(netframework, netcore, netstandard, xamarin, etc...)がnet5.0に統一さ れた。大統一.NET時代の幕開け。ただし実行環境 (CoreCLR)はまだ統一されていない。
29. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 特にコールドスタートアップに効くので、アプリケーションや、そしてAI のためのCLIで活きる……！対応プラットフォーム増加速度は思ったよりも ゆったりだが、.NET 11でようやくモバイル対応が完全完了。なお、後付け のAOTは苦しいところもある、が、やれないことはない、はず……。
30. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR WASM(.NET 11ではMono、.NET 12で対応予定)とコンソールゲーム機 対応(公式では多分やらなさそう)まで行けばCoreCLRが完全制覇になる のだけれど……！
31. ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 長いことMonoのままだったランタイムがついにCoreCLRに 移行する……！CoreCLR Player(JIT: Desktop/Editor)とIL2CPP Player(AOT: Mobile/Console)になる模様。 フレームワークは.NET 10/C# 14予定。
32. AI時代のC#
33. AI時代に最適な言語は「***」です！！
34. AI時代に最適な言語は「***」です！！ と、自分の推し言語を好きに入れて語られがち
35. AI時代に最適な言語は「***」です！！ その発言が許されるのはRustとPythonとTypeScriptだけ！
36. C#とは エディターフレンドリーな 静的型付け言語 エディター支援を強く念頭においた言語仕様により 入力補完やリアルタイムエラー検出の精度が高い 型のメリット ・リアルタイムのコンパイルエラー検出 ・入力補完 ・リファクタリング支援(名前一括置換など)
37. でも、もう手書きしないよね？ C#はツールを重視してきた 言語レベルで意識されたIDEとの連携 今では(TypeScriptを経由して)LSPとして様々な言語にもたらせている ものも、源流はC#にあるといっても過言ではない しかし手でコードを書く時代ではない 使わないわけではないが、重要視するほどでもない というのが現実 その傾向はこの先もますます広がっていくだろう C#のエディターフレンドリーは強みと言えるのだろうか？
38. コードエディット 実行（テスト、デバッガー、ベン チマーク、プロファイラー）して 確認してコード編集に戻る これだけだと回転に時間かかる 実行
39. コードエディット Humanは静的型付けと強力なIDE連携 によるコードエディット時のリアル タイムエラーでループを回していた
40. 静的型付けだったらここでエラーが あったらエディットに戻れる＋解決 のための詳細な診断情報を渡せるの で、より正確に素早く解決しやすい コードエディット コンパイル 型はHumanのためだけでは なく、AIのためでもある 実行
41. AIのためのエディターフレンドリー エディターフレンドリー = 高速なLint リアルタイムに出せているぐらいだから、とても高速なのだよ！ Humanのための高速な仕様が、AIにとっても活きる！ 放置するから遅くてもいい、などということはなく、結局イテレー ション速度は大事、速ければ速いほど、より回転する Analyzer Driven Development C#にはコンパイルパイプラインと統合された、構文木を使ってアプ リケーション固有のLintを作るシステムが2015年に追加された Humanのための代物だったが、むしろAIに最適なシステム
42. AIのためのエディターフレンドリー エディターフレンドリー = 高速なLint 自然文の指示では従われないこともあるし、早 い段階でのループで誤りを検出できないが、 Analyzerによりロジックエラーがコンパイルエ リアルタイムに出せているぐらいだから、とても高速なのだよ！ ラーになることで確実に検出、かつ、修正のた Humanのための高速な仕様が、AIにとっても活きる！ めの適切なガイドも同時に出せる 放置するから遅くてもいい、などということはなく、結局イテレー ション速度は大事、速ければ速いほど、より回転する Analyzer Driven Development C#にはコンパイルパイプラインと統合された、構文木を使ってアプ リケーション固有のLintを作るシステムが2015年に追加された Humanのための代物だったが、むしろAIに最適なシステム
43. [MessagePackObject]には[Key]が public memberに必要だよエラー state.Enter()したらstate.Exit()もしない とダメだよ警告
44. 37個もAnalyzerが定義されている！
45. AI時代のAnalyzer AIにより量産が容易になった 構文木の解析は通常馴染みがない、かつ、言語構文を網羅しなけれ ばならないため漏れが出やすい、難易度だけではなく、慣れてる人 でも面倒くさい代物であった そのため、どうしても必要なところだけ最小限定義、になりがち ところがAIは構文木の解析がめちゃくちゃ得意 やりたいことを自然文で書くだけで一瞬で実装してくれる Analyzerの民主化時代到来 （同種のSource Generatorの実装もAIは非常に得意）
46. こういうの網羅できる気しないので、AIにやらせる よりほかはない、Analyzer(Source Generator)に関し ては、手書きすべきではない、とまで言える
47. ところでMessagePack for C# v4 超絶速くて安全でバージョニング耐性が高い • Performant by default • Secure by default • Version-tolerant by default MessagePack for C# v4、まもなく出ます！ (9月中にpreview出す予定) v3と比較しても2~10倍高速になる！ Human x AI AIは大局的なアーキテクチャ造りはまだ苦手 また、世の中にない新しいアーキテクチャを造るのも苦手 10年以上のシリアライザー造りの経験による、長年温めていた究極 の新アーキテクチャ＋AIによるブラッシュアップで性能が限界突破
48. array(default)で398.2nsで他の2倍以上と いう圧倒的パフォーマンス！ mapでも479.5nsと他を圧倒して速い！
49. パフォーマンスを生み出す新しいフォーマッター定義
50. Deserialize(int)の解析 最もミニマムな箇所を計測することで、エントリー ポイントの必要経費がどのぐらいかを明らかにする v3比で4.86倍の改善
51. Deserialize(int)の解析 BenchmarkDotNetでのmeanだけではなくて、JIT Disassembleも行うことで、機械語レベルでの徹底的 な分析と改善作業をする 全体構造に関わるので、Agent Loopだけの自律的な改善 は難しい。(v4の場合はv3との互換性のトレードオフなど、 重要な判断も多数含まれるので、より難しい）。中身を Humanが理解して読み取って、大局的な視点で最適な アーキテクチャを構築する必要がある
52. Deserialize(int)の解析 lastEntryキャッシュ(最後のDeserialize<T>のConverter<T>だけ フィールドに置いておく）はただのベンチマークハックで良くな い。実際の利用シーンでそんなことはほとんどないはず。同種の コードはSystem.Text.Jsonにもある(このasm解析で発覚した）が、 そういうのはやめるべきだ。また、分岐予測ミスのコストは無料 ではないので、一般的ケースでの性能悪化も招く。
53. ちょっとした単純な改善事例紹介 public static class MessagePackSerializer { static readonly ConcurrentDictionary<Type, NonGenericEntry> entries = new(); public static byte[] Serialize(Type type, object? value) { var entry = entries.TryGetValue(type, out var existingEntry) ? existingEntry : SlowPath(type); return entry.Serialize(value); Typeをキーにした辞書引き (NonGenericのSerialize/Deserializeに使う) [MethodImpl(MethodImplOptions.NoInlining)] static NonGenericEntry SlowPath(Type type) { return entries.GetOrAdd(type, new NonGenericEntry()); } } } Genericsの場合はもっと高速なパスを通るが、 NonGenericsも改善したい……！
54. ConcurrentDictionary<Type, NonGenericEntry> entries = new(); ConcurrentDictionary<Type, NonGenericEntry> entries = new(ReferenceEqualityComparer.Instance); Keyがstructの場合はGenericsの特殊化 により性能が改善する可能性がある // type.TypeHandleで取れるstruct ConcurrentDictionary<RuntimeTypeHandle, NonGenericEntry> entries = new(); 改善されたといえばそうだけど、もう少し行きたい
55. そもそも、この状況では、かなり実装内容が 絞られた状態なので、特化実装してもコンパ クトな内容に抑えられるはず 実装が複雑になる場 合は、たとえAIに実 装させるとしても、 多少の性能改善程度 では避けたほうがい い。今回は条件を絞 れているので実装も シンプルにできる見 込みがあるのでGo
56. sealed class TypeKeyHashTable<TValue> where TValue : class { struct Entry { public Type? Type; public TValue? Value; } Entry[] entries; int count; Fibonacci Hashing static int GetIndex(nint key, int mask) => unchecked((int)(((ulong)key * 0x9E3779B97F4A7C15UL) >> 32)) & mask; public bool TryGetValue(Type type, [NotNullWhen(true)] out TValue? value) { var key = type.TypeHandle.Value; キーはメソッドテーブルのアドレス var table = entries; var mask = table.Length - 1; for (var i = GetIndex(key, mask); ; i = (i + 1) & mask) { ref var slot = ref table[i]; var slotType = Volatile.Read(ref slot.Type); if (ReferenceEquals(slotType, type) { Type == Typeは内部でis RuntimeType value = slot.Value!; return true; が余計に含まれるので使わない } if (slotType is null) { value = null; return false; } } }
57. 素のConcurrentDictionaryと 比較して2.8倍高速
58. AIはC#をよく知っている！ 2014年OSS化、GitHub上での開発の効果 アルゴリズムの知識が（私よりも遥かに）ある アセンブラの知識が（私よりも遥かに）ある C#の知識がある（私ぐらいに←？） .NETの知識が（私よりも遥かに）ある なぜなら、C#はインターネットに膨大なコードが存在しているから 膨大なdotnet/runtimeの良質なコード ディスカッション過程が全て残っていることによる理屈付け MicrosoftのTier1言語であることによるプロダクションコード公開 Stackoverflow質問数言語#3 GitHubランキングでも(LLM以前の年代で)#5 • • • •
59. Humanの知識も大事 AIは出力をブーストする MessagePack for C# v4の圧倒的な 性能向上は、AIがあっても、私に しか作れなかっただろう AIは確かに自分より賢い、が、全体的視点は（まだ）ない コードの取捨や、さらに追及するかどうかの押し引きは、幅広いコ ンテキストを見ているHumanに委ねられている つまり、油断すればす 自身の力 x AIアシステッド力 = 出力 ぐに追いつかれる、先 ベースがなければ増幅される幅も限られてしまう 行者利益などない純粋 AIは知識をブーストする な実力の世界 無限に質問できる、最高のインタラクティブな教材がそこにある 新しい知識の習得速度が従来の比じゃないほど加速している つまり、やる気さえあれば、誰でもすぐに追いつくことができる
60. AI Optimization Optimized Architecture 自己改善のためのコンテキストを与える C#はIL、マイクロベンチマーク、そしてJIT Disassemblyを容易に出力 可能なAIにとって最適な環境がある AI自身の知識＋的確な情報を与えることで、改善ループが走る 知識と能力のないAIには、いくら情報を与えても無駄。 Fable以降の世代でようやく実用的になった（のでそれ以 前の世代にコードは書かせない） AIが最適かしやすいアーキテクチャにする コード上でも依存関係を切った最小限のコンテキストで済むもの つまり小さな静的メソッドの集合体が最も改善しやすい
61. public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(5), 42)); } 静的メソッドと、小さなインスタンスメソッドの集合体で構成 それぞれを切り離して最適化しやすい構造 つまり関数型スタイル が、めちゃくちゃ書きづらい！
62. Martin Odersky(Creator of Scala): すべてが本質的にオブジェクトである ということは、全体の構造に染み込ん でいます。得られるものの一つは、 Simon Peyton Jonesが「ドットの力」 と呼んだものだと思います。非常に便 利で、オブジェクトがあってドットを 打つと、環境がそのオブジェクトのメ ソッドやフィールドを即座に教えてく れて、使うことができる。 https://www.developing.dev/p/creatorof-scala-comparing-languages 関数型言語のえらい人たちいわく、オ ブジェクト指向とはドット記法のこと である。使いやすさは正義。 Simon Peyton Jones(Creator of Haskell, Creator of Verse) https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/ECOOP-July09.pdf
63. public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(5), 42)); } Bad Feeling public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.WriteInt32(42); } Good Feeling
64. public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(5), 42)); } extension<TWriteBuffer>(ref TWriteBuffer buffer) where TWriteBuffer : struct, IWriteBuffer, allows ref struct { /// <summary>Writes an int32 in the smallest msgpack format.</summary> [MethodImpl(MethodImplOptions.AggressiveInlining)] public void WriteInt32(int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(MaxInt32Length), value)); } extension(C# 14)で、AI向きの静的メソッドの集合体を、 public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) Human向きのドット記法スタイルに変換する { buffer.WriteInt32(42); }
65. Conclusion
66. .NET Everywhere? C#は器用貧乏、か とはいえ、大統一された場合のスムーズさも大き な利点。結合箇所は大きなコンテキストになりAI が把握しづらくなるので、その点では大統一化が 可能なC#の万能さは有利でもある。また、最終的 には人間の把握しやすさも重要なので、大量コー ド生産時代だからこそ、単一アーキテクチャが人 のために活きるともいえる。 何でもできる、は、何もできない AI時代は言語の乗り換え、アーキテクチャの同期が容易になった 求められているのは最高のパフォーマンス、最高のUX そこでC#は戦えるのか？ エコシステムは最高だけど性能面に過大(JavaScript) ネイティブを探そう 性能面は最高だけどエコシステムに過大(Rust) ConsoleApp <- C#のNativeAOTは十分戦える Web <- フレームワーク/エコシステム/性能、バランスは良い Game <- 現実的にはまだゲームエンジンが必須、Unityは強み Windows App <- 文句なしのネイティブ WASM/Mobile <- がんばれ！
67. C#はAI時代に最適な言語の一つ 自信をもって言い張ろう！ 型付き・高速なコンパイル・統合されたAnalyzerは圧倒的な強み そしてC#のパフォーマンスの高さは、ネイティブパワーが求められ るAI時代にといて大きな武器となる AIパワーとの掛け合わせで基盤ライブラリもますます強力になる 改めて、AIで自身をブーストしよう！ C#がAIに最適だというなら、そこには最高の教材がある 実際、私は今年、ものすごく成長した 必要なのはC#への情熱だけ！ この波乱の時代を最高の形で乗りこなしましょう！