Yoshifumi Kawai; Founder/CEO/CTO of Cysharp, Inc. Author of UniRx, UniTask, MessagePack-CSharp, MagicOnion, etc. Microsoft MVP for Developer Technologies(C#).

Roppongi, Tokyo
Joined November 2007
Pinned Tweet
MessagePack for C# v4、Draft Round7出しました!Source Generatorを強化し、様々な新機能(C# 15 union, unknown fields, surrogate, circular-reference, require/nullable validation)と、mapでのパフォーマンスの驚異的向上を実現しました! github.com/MessagePack-CShar…
7
1
69
13,997
ReadMeを手書きで書いてる時が一番のAPI調整時間かもしれない。説明しづらいというのは、きっと使いづらいということなので。まぁ、手触り調整してもHumanが使うわけでもないか、となると、そこに時間割いてるのは自己満足の世界になってしまった。
6
1,222
When I was writing Unreal Engine 1, my time was divided as follows: - Around 30% went to seriously deep coding on hard problems: assembly language texture mappers, C++ BSP trees, data persistence, object oriented systems design, and networking. - Around 70% was just typing and refactoring large bodies of code needed for a complete engine feature set. This was not hard, and while I was doing it my mind was mostly on the deeper coding topics, thinking and planning for what's next. It didn't feel much different from vibe coding today, except that it was just me typing code on an IBM Model M keyboard rather than prompting it and reviewing the results. So, it has always seemed perfectly logical that we would rely on AI for that 70%, once the AI could do it with a similar quality standard as we could, which has never been perfection. It came as no surprise that, after a few years of AI model evolution, it was able to take the reigns on that 70% and free up programmers' time for more valuable tasks. What's more of a surprise is the emergence of AI as a sort of insta-Carmack able to solve hard technical problems quite cleverly and often cleanly, and that it's able to reason about and work in complex 3D scenes both by operating the tools and by directly understanding the raw data files. I abandoned assembly language in 1998 when out-of-order CPUs made much simpler C/C++ code faster, and never I missed it. If prompting through architectural documents, concept art, and design plans can transcend typing code and tweaking vertices, that will enable developers to spend their time on higher-level, higher value technical and creative tasks. What matters is the end product, whether it's a game or an engine. Anything developers can do to try out more ideas and make better software and games faster is a win for everyone.
963
1,593
378
18,394
1,510,776
鰻すき焼き
8
1,202
Last year I thought Threads was an existential risk to X. When Meta puts its full weight behind something -- by injecting the app into Instagram, it’s DEFCON 5: You have to squeeze out every last drop of growth from all available surfaces to save the app. However, I started to realize that the opposite was happening: It was strengthening X. If you look at any announcement by Zuck, you will see the most rude & toxic comments on the internet. But when he makes those same announcements on X, people are thrilled about how he’s pushing humanity forward. X is a place where people are excited about the future, so it’s no surprise he and his top lieutenants are using it more than their own app. Threads — and Bluesky — have effectively quarantined some of the worst people on the internet. And so I had an epiphany: those apps are X’s anti-abuse systems.
1,075
1,176
328
23,191
1,065,406
C#大正本理論! > ブリッジのAPI定義はUnityのC#で一か所にだけ書く
モバイル開発における弊社の秘伝のタレを公開します・・・! UaaL(Unity as a Library)でUnityとネイティブをつなぐブリッジコードを自動生成する仕組みを自前で作っています。こうした事例はかなりユニークかと思うので、ぜひご覧ください! tech.anotherball.com/ja/2026…
7
46
4,340
初期にあまりにも塩対応すぎて、組織的にこういうの無理なんだな、と思っていたので。
1
2
3,501
ActiveRecord is dead、時代は生SQL。つまりC#でもEntityFrameworkは......
9
1
48
10,083
Excited to see DHH's keynote in Tokyo!
4
1,415
We at @Ahwoo_Official and @rocketwerkz have made the BRUTAL Framework, that Ludeon have used to make their engine, and us Kitten Space Agency, open source and free to use. Our industry is rotting from the core out. We plan to change it. reddit.com/r/gamedev/comment…
29
136
16
1,286
58,306
やっぱRustしか勝たんかもしらん
1
1
26
3,121
Windowsベースの出自と、良くも悪くも抽象層が厚くて、真の生々しいレイヤーが隠されてるからですねえ。
4
1,902
うーん、根本的なところでは、 .NETのSocket APIがepollと噛み合ってないので、完全な最適化は不可能ということになってそう。そしてこの辺が改善される見込みはなさそう。
3
1
38
5,745
待機が長すぎるとArrayPoolも機能しなくなって(キャッシュ上限を超えて普通に新規確保からのGCゴミになる)GC圧にも繋がるので、CPU利用率にも影響ありそう。
1
6
2,588
まぁ、ちゃんとやればちゃんとなるようにはなってるというのは良いことなんじゃあないでしょふか。
1,411
(私は今の今まで何も意識してませんでした!)
1
1,874
この問題意識に対する対応はKestrelが先行し、各種Streamへの実装、PipeReaderにはStreamPipeReaderOptions.UseZeroByteReadsが入って、 .NET 6 辺りで全面的に対応可能になった、みたいです。とはいえ明示的にやらなければいけないことなので生で触る場合は要意識。
1
12
2,059