Go Conference 2025
#Go_Conference
day 1
サプライチェーン攻撃に学ぶmoduleの仕組みとセキュリティ対策
サプライチェーン攻撃に学ぶModuleの仕組みと セキュリティ対策 - Speaker Deck
あなたの隣で、あなたと共に = セキュリティ
タイポスワッティングによるサプライチェーン攻撃
GOPROXY
Module Proxyの不変性
一度キャッシュされたら、オリジナルの変更は反映されない
GitHub上のコードを元に戻しつつModule Proxy上には悪意のあるコードが残るようにした
Minimal Version Selection
勝手にバージョンアップされない
タイポスクワッティングには無力
go.sum
Merkle Treeによる改竄検出
依存パッケージを手書きしない
govulncheck
nancy
Deep Dive Into testing/synctest
deep dive into testing/synctest - Speaker Deck
同期テストの典型例
非同期テストの課題
flakyになりがち
tick
goroutineの完了を待つ
testing/synctest
Go 1.24時点では実験的パッケージだった
bubble
bubbleの中のgoroutineは仮想時間を使う
durably blocked
encoding/json/v2で何が変わる? - v1からv2への変化を徹底比較
encoding/json/v2で何が変わるか - Speaker Deck
従来のencoding/jsonの課題
jsontext
json/v2
変わらないもの
APIの手触り
新しいもの
struct tagが増えた
v2への移行検証
GraphQL APIサーバー
GOEXPERIMENT=jsonv2
公式ベンチマーク
marshal
まちまち
interfaceはjsontextへの分離が効いていそう
内部的に2回scanしていたのが1回で済むようになった
rawValue 圧倒的に高速
unmarshal
速い
Go で WebAssembly を利用した実用的なプラグインシステムの構築方法
Go で WebAssembly を利用した 実用的なプラグインシステムの構築方法 - Speaker Deck
プラグインシステムにおけるWASMのメリット
Guestの動作を制限できる
一度ビルドしたらどこでも動く
WASI
GoのWASI対応状況
P1まで
Network SocketやThreadなどが未対応
TinyGo
wazero
pure Goで実装されている唯一のWASMランタイム
WASMの壁
並行処理の壁
Guest関数を呼び出した場合、関数を抜けると非同期処理も停止
Guest内でHTTP listenできない
メモリ管理の壁
インスタンスを作りまくるとメモリ使用量が爆発
Network Socketの壁
sock_recv/sock_sendの実装が存在しない
wasmimportでHost関数を経由することはできるが
呼び出し箇所を全て書き換える必要がある
TLSの壁
システム証明書ストアを用意していない
コマンド実行の壁
dispatchrun/wasi-goとdispatchrun/netを組み合わせることでNetwork Socket対応の実装を利用できる
プラグインビルド時に標準ライブラリの実装を置き換える
go build -overlay
go:linkname
ファイルをパースして元の関数名が衝突しないように書き換える
linknameを使うことで循環参照を回避
TLS / exec.Commandの壁
Hostに処理を移譲する
プラグインの非同期処理をサポートする
wasmexportは使わない
ゲスト側でmainloopでリクエストを処理する
STDINを使ってHostからのリクエストを受ける
レスポンスはHost関数を使ってHostに伝える
STDOUTを占有しない
メモリ使用量を考慮
インスタンスをあらかじめ任意の数起動しておいてロードバランスする
HostとGuestのメモリ管理は別
GOMAXPROCSに2以上を指定するとpanicする
mTLSまわりの処理を無効化する
全てGoで作るP2P対戦ゲーム入門
全てGoで作るP2P対戦ゲーム入門 - Speaker Deck
Hit & Blow
プレイヤー同士が交互にクライアント・サーバーをやるとよさそう
Ebitengine
マッチング
キュー
WebSocket
P2P通信
WebRTC
signalingサーバー
Ayame
Ebitengineとゲームロジックの橋渡しにchannelを使う
レーティングサーバ
analysis パッケージの仕組みの上でMulti linter with configを実現する
analysis パッケージの仕組みの上でMulti linter with configを実現する / Go Conference 2025 - Speaker Deck
前処理Analyzer
Requiresフィールドを使う
day 2
Go1.25新機能 testing/synctest で高速&確実な並列テストを実現する方法
Go1.25新機能 testing/synctest で高速&確実な並行テストを実現する方法 - Google スライド
背景と課題提起
Test関数のgodocには時刻に関する記述がない
別のgoroutineからTTLになったらキャッシュを消す例
synctest.Testで囲むだけではflaky testのまま
Go 1.24からの差分
今後の展望
Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する
Go Conference 2025: Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する - Speaker Deck
Go 1.24からはTCP Listenすると自動的にMPTCPになる
モバイル端末は接続が切れやすい
MPTCPにすることでストリーミングが止まりにくいように
複数のTCPコネクションを束ねる
subflow
Middleboxとの相性がよくない
Go 1.21からMPTCPサポートが入った
明示的に有効にする
特殊なsocket optionに注意
任意のソフトウェアを強制的にMPTCP対応させる
https://github.com/takehaya/mptcp_playground
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast / Go Conference 2025 - Speaker Deck
modernize package
goplsに入っている
内部実装を見る
温度感高く動いてくれていそう
公式singleflightを約2倍高速化したGenerics対応実装と最適化
公式singleflightを約2倍高速化したGenerics対応実装と最適化 #gocon
https://github.com/catatsuy/cache
公式版の問題点
型安全でない
any
Lockが多い
mutexのlock/unlockは遅い
設計方針
panicは扱わない
mapの初期化をconstructorで行う
goroutineを使って削除処理を非同期化
公式にフィードバックしてみたがあんまりやる気なさそうだった
カリカリなMutexを作る / "Crispifying" Go's Mutex
"Crispifying" Go's Mutex - Slidev
状態が多い
mutexの中にセマフォがある
version 1
セマフォをそのままmutexとして使う
SPIN
時間様相論理
Promela
version 2
ランタイムのセマフォはけっこう重たいのでなるべくアクセスしないようにする
unlockされていたら runtime_SemacquireMutex を呼ばないようにする
version 3
unlock時にwaiterがいなかったら runtime_Semrelease を呼ばないようにする
version 4
起きているGの数を数える
version 5
ある程度待っているGがあればstarvation modeに入る
割り込みは一切禁止になる
panicと向き合うGo開発 - nilawayで探る見逃されるnil参照とその対策
panicと向き合うGo開発 - nilawayで探る見逃されるnil参照とその対策 - Speaker Deck
return nil, nil
静的解析で防ぎたい
nilness
nilaway
2-SAT
誤検知
パッケージをまたいだnil
なぜGoのジェネリクスはこの形なのか? - Featherweight Goが明かす設計の核心
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心 - Speaker Deck
ジェネリクスが導入されるまでの歴史
contracts
撤回された
Featherweight Go
https://arxiv.org/abs/2005.11710
ジェネリックなコードをどうやって変換するか定式化
構造的サブタイピングとジェネリクスの組み合わせ
モノモーフィゼーションにコンパイルする
FG
ジェネリクスなしのGoのサブセットを定式化
型安全でないコードが書ける
FGG
型パラメータを導入
制約にinterfaceを使う
共変レシーバ
型アサーションなしで安全なメソッドを定義できる
コンパイル戦略
FJとは戦略が異なる
イレイジャ
型削除
モノモーフィゼーション
型ごとに専用のコードを生成
FGG→FG
ダミーメソッドを追加する
多相再帰ではない
ダミーメソッド
ダミーメソッドがないと
メソッドが使われていないと判定される
全ての型が空のインタフェースを満たす
式問題
共変レシーバによって安全性を保ったまま拡張性を上げる
Goでは共変レシーバが実装されていない
これによってメソッドのジェネリクスの制約が強くなっている
型安全性か冗長性のトレードオフになる
Green Tea Garbage Collector の今:Go言語のコアチームによる試行錯誤の過程と共にメモリ管理最適化の実装を読み解く
Green Tea Garbage Collector の今 - Speaker Deck
Go 1.25から実験的機能として
なぜGreen Tea GCになったのか
Tri-color Parallel Marking
局所性の欠如
現行の並列GCアルゴリズムはプロセッサ中心の思想で設計されている
プロセッサ中心 vs メモリ中心
ハーフォウェアの進化によって優位性とトレードオフが逆転
まったく新しいGCを短期間で実装したわけではない
スパンがdequeueされる際の最大局所性を検証し、最も効率がよいものを採用
Go 1.26に向けて開発が進行中
コード生成なしでモック処理を実現!ovechkin-dm/mockioで学ぶメタプログラミング
コード生成なしでモック処理を実現! ovenchkin-dm/mockio,go-dynoで学ぶメタプログラミング - Speaker Deck
mockio内でgo-dynoを使っている
メソッドはreflectパッケージだけでは動的に生成できない
関数はreflectで動的に生成できる
メモリ領域をハック
関数を呼び出すことはできるが引数は渡せない
スタックを16byte飛ばすために [2]int を余分に渡す
10年もののAPIサーバーにおけるCI/CDの改善の奮闘
10年もののAPIサーバーにおけるCI/CDの改善の奮闘 - Speaker Deck
デリッシュキッチン
CI/CDに16分
16分→10分
deadcodeというツールでデッドコードを調査・削除
偽陽性あり
テスト時間にはあまり効かなかった
テストの並列化を徹底
グローバルに現在時刻を管理しているところを置き換える必要が出てきた
t.Parallel() を呼んでないテストがあったらlint落ちるようにする
差分テスト
安全に運用できるラインを考える
go mod download
パッケージのキャッシュ
goplsの拡張によるマイクロサービス間の実装ジャンプ改善
gRPCメソッドで呼び出される先のマイクロサービスの実装に飛びたい
gopls拡張
拡張したgoplsを配布する方法
必要なところだけ拡張goplsに移譲する
vscode-goも拡張
Go Conference 2026