nuskey.mdWorksKo-fi

Go Conference 2026に参加した

先日開催されたGo Conference 2026に参加しました。Go Conferenceに参加するのはこれが初めてです。

Go Conference 2026Go Conference はプログラミング言語 ”Go” ユーザーのためのカンファレンスです。Go Conference 2026

普段は.NETやUnityのコミュニティに属しているのもあって、新しいコミュニティに飛び込んでいくのは新鮮で楽しかったです。日本のGoコミュニティは言語自体が比較的新しいこともあり、運営側・参加者共に若い世代の方も多く活気があって良きですね。(C#の勉強会に行くと同じ年代の方が少ないのが悲しくて...)

opening

オープニング

Open Source, Open World

@sanpo_shihoさんによる基調講演。KubernetesのメンテナーとしてOSS活動を続ける中で得られた経験のお話でした。

Open Source, Open World - タイムテーブル | Go Conference 2026「OSSをやっている人って、なんかかっこいい。」 そんな単純な憧れから始めたOSS活動。英語も得意ではなく、知り合いもいない状態からKubernetesへのコントリビューションを始め、気づけば数年間にわたって活動を続けてきました。 なぜOSSを続けてきたのか。OSSに時間を使うことで何が得られるのか。その先にどんな世界があったのか。自身の経験を振り返りながら、OSSに関わり続けることの価値について考えます。Go Conference 2026

私自身もささやかながらOSS活動を続けていることもあり、共感できる話が多くありました。なかなか実感が湧きにくいですが、やっぱりOSSって世界中の色々な人たちがいるからこそ成り立っていることなんですよね。AIがコーディングを行うようになって久しいこの時代に、改めて人との関わりの大切を実感できた素晴らしい基調講演でした。

When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go

自作のpacket capture toolを題材に、高スループットが求められるGoプログラムを改善していく話。

When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go - タイムテーブル | Go Conference 2026Goでは、goroutineによってOS threadやCPU coreをほとんど意識せずに並行処理を書けます。この実行場所を隠す抽象化は、Goの大きな強みです。 一方で、通信トラヒック、メトリクス、ログ、message queueのような高スループットなデータストリーム処理では、どのデータをどのqueueで受け、どのgoroutineが読み、どのCPU coreで実行されるかが性能差として現れることがあります。goroutineは並行性を表現する単位ですが、実行場所やローカリティを保証する単位ではないためです。 本発表では、自作のpacket capture toolを題材に、高スループットが求められるGoプログラムを改善していく過程を紹介します。このツールでは、Linuxのper-CPU BPF ring bufferからpacket eventを読み出します。BPF側ではCPUごとにqueueが分かれ、Go側ではreader goroutineが各queueを読みます。この構造では、reader goroutineを増やすだけでは性能が伸びず、queue、goroutine、OS thread、CPU coreの対応関係が性能に効くようになりました。 また、高負荷時にはpprof上でruntime.asyncPreemptが大きく目立つようになりました。本発表では、これを単にGo runtimeの遅さとして読むのではなく、hot loop、非同期プリエンプション、scheduler、CPU profileの見え方としてどう解釈するかを整理します。 この事例から持ち帰れるのは、runtime.LockOSThread()やCPU affinityの使い方そのものではありません。Goの抽象を通常の設計の前提としながら、どの条件で必要最小限だけ下の層を見るべきかを判断するための考え方です。pprofに現れるruntime関数の読み方や、データの分割単位がqueue、goroutine、CPU coreへどう対応しているかを、実測に基づいた学びを提供します。 ## 想定している話の流れ 0-4分: 問いの提示 goroutineは並行性の単位だが、ローカリティの単位ではない 4-8分: 普通のGo設計 flow、shard、partition、queueをgoroutineへ分散する設計 8-13分: 自作ツールの構造 per-CPU BPF ring bufferとreader goroutineの対応関係 13-20分: 最初の限界 reader goroutineを増やすだけでは性能が伸びない理由を、drop、latency、pprofから見る 20-27分: pprofとruntime.asyncPreemptの読み方 runtime関数が見えたときに、原因と現象をどう切り分けるか 27-35分: 実行場所を制御する LockOSThread、CPU affinity、same-CPU reader、split-coreの効果と副作用 35-40分: 一般化 metrics、logs、message queueなどのsharded consumerへ応用する ## 想定している聴講者 - Goで高スループットなサーバーやデータ処理基盤を書いているエンジニア - flow、shard、partition単位でgoroutineへ処理を分散している人 - pprofでruntimeやschedulerまわりの関数が目立ったとき、解釈に悩んだことがある人 - Go runtimeの抽象とOS scheduler、CPU coreの境界に興味がある人Go Conference 2026

情報量が多かったのもあり一度聞いただけで理解し切るのが難しかったですが、資料読み返してなんとなく把握できました。GoroutineのSchedulerは偉い。

株式会社ミラティブ: 動画配信サーバーにおけるGC負荷低減の取り組み

@kota_yataさんによる動画配信サーバーのGC負荷削減のお話。

mmap直確保でGoのGC負荷を低減する - Mirrativ Tech Blogインフラ・ストリーミングチーム インターンの八谷です。 本記事では、ガベージコレクション（GC）への負荷を低減することを目的として、Go言語でのメモリ確保時にOSから直接mmap領域を確保する手法と、make関数でランタイムから領域を確保する場合でのGC負荷などの比較を行います。結果としては、mmap領域を直接確保することでGCが走査するオブジェクト数を削減でき、それに伴ってアプリケーションの停止（Stop-The-World）時間を短縮できることがわかりました。 前提知識1: Goにおけるメモリ管理 Goのランタイムでは、起動時や必要に応じてOSから64MB単位の領域をあらかじめ確保し、それ…Mirrativ Tech Blog 株式会社ミラティブ: 動画配信サーバーにおけるGC負荷低減の取り組み - タイムテーブル | Go Conference 2026動画配信サーバーでは、動画セグメントの処理ごとに、大きく短命なメモリ領域の高頻度な割り当てが発生します。こういったワークロードにおいて、Goランタイムからのメモリ割り当てではオブジェクト数とサイズが爆発し、GCのスキャンやGCアシストによる負荷が激増、結果的にスループットが低下します。上記の問題に対応するためにとっている、mmapによる手動メモリ管理の手法と類似する手法、それによるアプリケーションの性能向上について紹介いたします。Go Conference 2026

Stop-the-WorldはGC言語につきものな課題。このセッションではmake()によるヒープメモリ確保をmmap領域で代替することによってSTWスパイクの削減を実現していました。

func Alloc(size int64) ([]byte, error) {
    data, err := unix.Mmap(-1, 0, int(size), mmapPerm, mmapFlag)
    if err != nil {
        return nil, errors.WithStack(err)
    }
    return data, nil
}

func Unmap(buffer []byte) error {
    if err := unix.Munmap(buffer); err != nil {
        return errors.WithStack(err)
    }
    return nil
}

近年のGoのGCパフォーマンスはかなり改善されていると聞いていましたが、やはり辛いところでは辛そう...という印象を受けました。そのような場面でmmapでGC管轄外へ逃してしまう手法はかなり応用が効きそうです。(Unityでも巨大バッファを扱う際にネイティブ側に逃してしまう手法を取ったことがあるので、発想自体は馴染みがありました)

株式会社エウレカ: Podは生きているのにGoだけが落ちる：GOGCとGOMEMLIMITで追うInvisible OOM Killの謎

@buzz_tkcさんによる、Go APIサーバーでtarget 5xxが発生しGoプロセスだけがpanic logなしに落ちる"Invisible OOM Kill"の原因と解決策のお話。

株式会社エウレカ: Podは生きているのにGoだけが落ちる：GOGCとGOMEMLIMITで追うInvisible OOM Killの謎 - タイムテーブル | Go Conference 2026【ショートセッション／中級者向け】 我々が提供するペアーズの本番運用中のGo APIサーバーで、まれにtarget 5xxが発生しGoプロセスだけがpanic logなしに落ちる事象が続いていました。一方で、PodはOOMKilledにならず、同じコンテナ内のNginxは生き続けており、Kubernetes上の状態や通常のアプリケーションログだけでは原因を特定しづらい、いわゆる“Invisible OOM Kill”と呼べる状態でした。 本セッションでは、この見えにくい障害を、Goランタイム・Kubernetes・コンテナ内の複数プロセスという複数のレイヤーから一つずつ紐解いていきます。なぜPodは生きているように見えたのか、なぜGoプロセスだけが落ちたのか、なぜメモリ使用量が少なく見えていたのにOOMが起きたのか。調査の過程で見えてきたGOGCとGOMEMLIMITの関係、Go以外のメモリを考慮した値決め、GCやレイテンシに与える影響について、実際のメトリクスと意思決定を交えて紹介します。 最終的には、本番APIサーバーの安定性を高めながらmemory limitを8GBから3GBへ削減しました。その過程で得られた、Goアプリケーションをコンテナ環境で安全かつ効率的に動かすための監視・設定・ロールアウトの考え方を共有します。Go Conference 2026

原因はGOGCで指定したと思っていた閾値が想定通りに機能しておらず、GCが動くより先にcontainer memory limitに引っかかっていたことでした。知らなかったら割と踏みそうな問題で怖い。ちゃんとGOMEMLIMITを設定しておきましょう。

エムスリー株式会社: 更なる可用性を求めて、5年間運用したKotlinのアプリケーションをGoでリプレイスする話

田口 健介さんによる、Kotlin製のマイクロサービスをGoでリプレイスしたお話。

エムスリー株式会社: 更なる可用性を求めて、5年間運用したKotlinのアプリケーションをGoでリプレイスする話 - タイムテーブル | Go Conference 2026クリニック向けの予約・受付・キャッシュレス決済サービス「デジスマ診療」では長らくKotlinのアプリケーションをKubernetes上で運用してきました。 デジスマ診療はクリニックの診療オペレーションに組み込まれており、高い水準のシステムの可用性が求められます。そこで更なる可用性の向上のため、KotlinのアプリケーションをGoでリプレイスする意思決定をしました。 本セッションでは、Kotlin（JVM）アプリケーションを運用して見つかった課題と、それをGoでリプレイスする意思決定に至った経緯や効果についてお話しします。Go Conference 2026

私はKotlinを触った経験がほとんどないので何とも言えませんが、SpringBootが辛い、みたいな話はちょいちょい聞くのでなるほどなーと。

あとやっぱり起動時に遅いのはJIT言語の宿命なので、その辺りはGoのようなAOT言語は強い。

Go におけるコンソールゲーム開発最前線 〜非対応環境でランタイムを動かす技術〜

Ebitengineの作者@hajimehoshiさんによる、Go製のEbitengineをどうにかしてコンソールで動作させるまでのお話。

Go におけるコンソールゲーム開発最前線 〜非対応環境でランタイムを動かす技術〜 - タイムテーブル | Go Conference 2026# 概要 Go はサーバーサイドや CLI ツールで広く使われています。しかし、 Nintendo Switch や Xbox などのゲームコンソールには対応していません。そんな中、 Go の 2D ゲームエンジン「Ebitengine [1]」は Nintendo Switch 及び Xbox への対応を果たしました。 2026 年 5 月時点で、発売予定を含め 10 本以上のコンソールゲームに採用されています [2]。 本セッションでは、本来非対応であるコンソール環境で、どのように Go ランタイムを動かしているのかを解説します。 Ebitengine の開発者であり、 Odencat 株式会社の CTO として実際にゲームをリリースし続けている立場から、その技術的な裏側と実装について詳しく説明します。 [1] https://ebitengine.org [2] https://ebitengine.org/ja/showcase.html # 主なトーク内容 * Go ランタイムの仕組みとコンソール対応の現実 * `-overlay` フラグを使ったシステムコールの書き換え * グラフィックスライブラリの対応 * プラットフォームごとの対応 * 開発からリリースまでの流れ * 今後の課題 # 対象聴衆 * Go のランタイムや低レイヤ、システムコールに関心がある方 * `-overlay` などのビルドオプションに興味がある方 * Go によるクロスプラットフォーム開発や、ゲーム開発の可能性を知りたい方Go Conference 2026

コンソールはSDKの情報がNDAにより外部に仕様が公開されていないため、Goを含む多くの言語のコンパイラは公式にサポートを行っていません。Rust製のネイティブプラグインをコンソールで動かすのが大変で断念した話は結構聞くので、Goを動かすのはなかなか大変そう...と思いながら聞いていました。

最初はGo->wasm->C++の変換(Wasm法)で動かしていたものの、パフォーマンス的に厳しかったため、今度は「秘伝のタレ(-overlay)」でランタイムそのものを書き換えてコンソールのSDKを叩いたりと、とにかく泥臭い努力によってコンソールでGoを動かしているのが印象的でした。すごい。

Goと一緒に育つCLI — 9年のOSS保守で見た標準ライブラリとtestingの進化

@catatsuyさんによる、Slack通知用のシンプルなCLInotify_slackを9年間保守していく過程で見えた標準ライブラリ・testingの進化についてのお話。

Goと一緒に育つCLI — 9年のOSS保守で見た標準ライブラリとtestingの進化 #gocon26Zenn Goと一緒に育つCLI — 9年のOSS保守で見た標準ライブラリとtestingの進化 - タイムテーブル | Go Conference 2026標準入力を受け取り、チャットサービスへ通知する小さなGo製CLIを、約9年にわたって保守してきました。 この発表では、そのCLIの実装と変更履歴を題材に、Go本体・標準ライブラリ・testingの進化が、小さなCLIの設計と保守をどのように変えてきたかを紹介します。 初期の実装では、goroutine、channel、timer、signal handlingを手組みし、非同期処理のテストも `runtime.GOMAXPROCS(1)` や短い `time.Sleep` に頼っていました。また、ホームディレクトリ取得やエラーのwrapなど、今では標準ライブラリで自然に書ける処理にも外部パッケージを使っていました。 そこから、`os.UserHomeDir`、Go 1.13のerror wrapping、`signal.NotifyContext`、`context.WithoutCancel`、`T.Setenv`、`T.Context()`、そして `testing/synctest` へと移り変わる中で、コードは少しずつ「外部依存や偶然に頼るもの」から「Goの標準機能で意図を表現できるもの」へ変わっていきました。 特に中心に置くのは、非同期処理のテストです。かつてはruntime schedulerの挙動に依存していたテストが、`testing/synctest` によって、goroutineの停止状態を明示的に待てるテストへ変わった過程を、実際のコードの変遷をもとに紹介します。 Goの互換性と標準ライブラリの継続的な進化は、大きなプロダクトだけでなく、個人が長く保守する小さなCLIにも届いています。この発表では、ひとつのツールを9年保守してきた経験を通じて、Goと一緒に遠くまで進むとはどういうことかを具体的に示します。 ## 参加者が得られるもの * goroutine / channel / timerを含むCLI処理のテスト設計 * `runtime.GOMAXPROCS(1)` や `time.Sleep` に頼る非同期テストの問題点 * `testing/synctest` による非同期テストの改善例 * `signal.NotifyContext` を使ったCLI shutdown設計 * `context.WithoutCancel` を使うべき場面と、timeoutを戻す注意点 * `os.UserHomeDir` やGo 1.13 error wrappingなど、標準ライブラリの進化による外部依存削減 * `T.Setenv` / `T.TempDir` / `T.Context()` などによるテスト保守性の改善 * 小さなOSSや社内ツールを、Goの進化に合わせて長く保守していく考え方 ## 対象者 * GoでCLIや小さなツールを書いている人 * goroutine / channel / context を使った処理のテストに悩んだことがある人 * 社内ツールやOSSを長く保守している、またはこれから保守していきたい人 * Goの標準ライブラリやtestingの進化を、実例ベースで知りたい人 ## 対象レベル **中級者** goroutine、channel、context、testingの基本を知っていると理解しやすい内容です。 ただし、個別のAPIは背景から説明するため、CLIやテスト改善に関心がある初級者にも役立つ構成にします。Go Conference 2026

synctestやhttptest、signal.NotifyContext()などの新しい機能の登場で、昔は手作りの処理に頼っていた部分をGo標準の機能に任せられるようになっていく様子が語られていて面白かったです。Goのこの辺りの充実っぷりは他の言語の追従を許さないものがあります。とても便利で良いですね。

synctest時代のhttptest: Go 1.27で変わるHTTPサーバテストの裏側

@budougumi0617さんによる、synctest/httptestを使ってHTTPサーバのテストを書くお話。

synctest時代のhttptest: Go 1.27で変わるHTTPサーバテストの裏側 - タイムテーブル | Go Conference 2026Go 1.25 で正式導入された `testing/synctest` は、並行処理コードのテストを決定的に扱うための仕組みです。`synctest` の bubble 内では goroutine の待機状態を観測でき、時間の経過も fake clock によって制御できます。 一方で Go 1.26 までの`net/http/httptest.Server` は通常のサーバと同じく OS のネットワークスタックを使うため、`synctest` と組み合わせにくい場面がありました。そのため、HTTP サーバや API クライアントのテストでタイムアウトやバックオフを扱いたくても、`synctest` による時間制御の恩恵を受けにくい問題がありました。 Go 1.27 では `net/http/httptest` の `synctest` 対応により、HTTP サーバや API クライアントのテストを `synctest` の bubble 内で扱いやすくなります。この変更を支えるのが、標準ライブラリ内部に追加された `internal/nettest` による in-memory fake networking 実装です。 https://github.com/golang/go/issues/76608 本発表では、まず `synctest` がどのように時刻とgoroutineの待機状態を扱うのか軽くおさらいします。そのうえで、従来の `httptest.Server` がなぜ `synctest` と組み合わせにくかったのかを確認し、Go 1.27 で追加される `httptest` の `synctest` 対応によって、Web サーバや API クライアントのテストをどのように書けるようになるのかを紹介します。 後半では `internal/nettest` の実装を読み解き、`internal/nettest`のインメモリネットワークがどのように `httptest` と `synctest` をつないでいるのかを解説します。 ### タイムライン この発表ではGo 1.27から変わる`synctest`を使ったHTTPサーバテストについて以下の順に話す予定です。 - synctestが何をしているのかおさらい - Go 1.26 以前の `httptest` がなぜ `synctest` と組み合わせにくかったのか - Go 1.27 の `httptest` の `synctest` 対応で書けるようになるテスト例 - `internal/nettest` deep dive: fake listener / fake connection の設計 - まとめ ### 本セッションで得られること このセッションでは、以下を持ち帰れます。 - `httptest` と `synctest` を使って、より速く安定した HTTP/API テストを書くための考え方 - OS の I/O wait を介さない in-memory なネットワークモデルの仕組み - `internal/nettest` が `httptest` と `synctest` をどのようにつないでいるのかGo Conference 2026

httptest.NewTestServer()全然追えてませんでした。synctestと組み合わせられるのもそうですが、これ単体でもかなり便利そう。Durably Blocked周りもちゃんと理解していなかったので、その辺りの解説もわかりやすく良かったです。

標準パッケージに uuid が追加された背景から見る Go らしい意思決定

@convtoさんによる、標準パッケージにuuidが導入された背景からGoらしい意思決定のアプローチを見るお話。

標準パッケージに uuid が追加された背景から見る Go らしい意思決定 - タイムテーブル | Go Conference 2026Go 1.27 からは標準パッケージに uuid 実装が追加されることが予定されています。 が、この uuid 実装の追加についてのプロポーザル自体は 2018 年ころから出ており、一度クローズされています。 https://github.com/golang/go/issues/23789 https://go.dev/doc/faq#x_in_std にもある通り、Go がある処理を標準パッケージとして実装するためには、それが標準パッケージたりうる理由を満たす必要があります。これらを説明しつつ、このプロポーザルがクローズされた理由に触れます。 しかし Go 1.27 でリリース予定なことからわかる通り、その後別の uuid 実装のプロポーザルが再提案され、そちらは議論を経て accept されています。 https://github.com/golang/go/issues/62026 時を経てどのように状況が変化し標準パッケージで実装するに足る価値を示したのか、またどのような議論を経て accept され実装につながったのかを解説します。 また、上記プロポーザルでは言及されていませんが、uuid に関するありがちな実装ミスとしては rand source の選択や利用方法の誤りがなど挙げられます。例えば著名なOSSである https://github.com/satori/go.uuid では過去に rand 処理の誤った利用に起因する CVE-2021-3538 が発生しました。この内容についても軽く触れ、セキュリティの目線でも標準ライブラリとして実装することの意義を補強することを試みます。 実際に実装された処理群なども非常に Go らしい特徴を備えていて、主に uuid v4 および uuid v7 のサポートのみとなっています。これらについては実際の利用傾向などを踏まえてメンテ可能な必要最小限の仕様を実装するような議論がありました。関連する議論の流れやどのように意思決定したのかをご紹介できればと思います。 総じて標準パッケージへの uuid の追加を例に取り上げながら、 Go が標準パッケージに価値ある処理群を実装していくための考え方などを紹介できればと思います。Go Conference 2026

C#やJSなどもそうですが、Goの互換性に対する姿勢は凄まじく、一度追加されたものを消すことはできません。この制約を踏まえた上で、それでもuuidパッケージを追加するメリットがあると判断された背景が説明されていました。いちユーザーとしても、uuidを標準で扱えるようになったのはやはり嬉しいですね。

OpenTelemetry eBPF Instrumentationの舞台裏

@ymotongpooさんによる、OBIがGoバイナリを計装するのがなぜ難しいかのお話。

OpenTelemetry eBPF Instrumentationの舞台裏 - タイムテーブル | Go Conference 2026OpenTelemetryの「ゼロコード計装」はeBPFを使えばアプリのコードを1行も変えずにHTTPやgRPCのトレースが取れる、と魔法のように語られます。ですが、その魔法をGoバイナリに対して実現するのは、他のどの言語よりも困難です。 本セッションでは、Grafana BeylaがOpenTelemetryプロジェクトへ寄贈され生まれた OpenTelemetry eBPF Instrumentation (OBI) を題材に、「GoバイナリにeBPFで計装する」という行為がGoランタイムのどんな性質と衝突するのかを詳細に解説します。 具体的には、(1) Goの可動スタックゆえにuretprobeが使えずクラッシュする問題と、関数内の全RET命令にuprobeを置く回避策、(2) Go 1.17以降のレジスタベース呼び出し規約（ABIInternal）と、現在のgoroutineを指すgポインタがレジスタに保持される仕組み、(3) Goのバージョンごとに変わる内部構造体のフィールドオフセットを、外部のオフセットテーブルで追従し続ける運用、(4) goroutineの親子関係を辿ってコンテキストを伝搬する手法とその制約、を順に見ていきます。 最後に、これらの困難に対してGo本体側（ランタイム）がどう向き合ってきた／こなかったのかを、flight recorderやgoroutine leak profileなど近年のオブザーバビリティ向上と対比して議論します。 Goとオブザーバビリティ製品に長らく関わってきた経験により、Go Conferenceであまり触れられてこなかったeBPFに関して、参加者の理解を高める発表にします。Go Conference 2026

初っ端の会場アンケートから難易度が高すぎて理解できるか不安でしたが、初歩からということでわかりやすく解説していただけてありがたかったです。本来の発表どれだけ高度な内容だったんだ...

Goのバージョンによって変わる仕様に追従しつつ計装を行うために、数々の難所を力技でねじ伏せていく感じが面白かったです。offsets.jsonあたりはパワーすぎてびっくりしましたが、そりゃそれ以外の方法ないよな...と。時間の都合でDeep Diveな内容はスキップされていたので、あとでちゃんと資料を読みつつ理解しておきたいです。

range over func 2年間の軌跡 — Issue #56413 はGoのエコシステムをどう変えたか

DMMから@_ryuji_cre8iveさんによるrange over funcのお話。

range over func 2年間の軌跡 — Issue #56413 はGoのエコシステムをどう変えたか - タイムテーブル | Go Conference 2026「コレクションを走査する」という、どのGoコードにも存在する処理。なのに、filepath.Walk・sync.Map.Range・flag.Visitはすべてシグネチャが異なります。なぜGoには長年、統一されたイテレーション方法がなかったのか。そして2022年にGitHubに立てられたDiscussion#56413から始まった議論が、Go 1.23の range over func として結実するまでに何が起きたのか。 本セッションでは、IssueとPRの議論を丹念に追うことで見えてくる「設計の決断」と、リリースから2年間でGo本体・標準ライブラリ・OSSエコシステムが実際にどう変化したかを、Before/Afterのコードで具体的に示します。 業務でまだ使えていない方にこそ聞いてほしいセッションです。 変化の全体像を知ることで、「自分のコードのどこに使えるか」が見えてくるはずです。 【扱う内容】 ・Before: なぜ統一されたイテレーション方法がなかったか ・設計の決断: なぜinterfaceではなく関数型になったのか ・After(1): 標準ライブラリに加わったiter.Seq対応API ・After(2): OSSエコシステムの2年間の変化と現在地 ・実践: []T返しとiter.Seqの使い分け判断基準Go Conference 2026

C#やRustなどの言語ではコレクションの列挙を行うイテレータの仕様が統一されていますが、Goでは長らく統一された手法がありませんでした。これはGoの思想的にわからなくもないんですが、実用上はかなり微妙なので、ちゃんと仕様として入ったのは良かったな、と。

とはいえ、決まったのが最近なせいでエコシステム側が追従できていない面もあり...なかなか難しいところですが、これからいい感じになっていくと良いですね。

まとめ

初めてのgocon参加でしたが、本当に色々なセッションがあって存分に楽しめました。After Partyでも普段関わりがないコミュニティの方々だけでなく、意外なところで繋がりのある方々ともお話できて良かったです。また来年も参加したいですね！