Sessions & Speakers

タクシーアプリ『GO』は、タクシー車両とのリアルタイムな位置情報連携と高度な配車ロジックによって、アプリユーザーと近くのタクシーを呼べるアプリです。 そのコアとなる、タクシーとユーザーとのマッチングアルゴリズムの処理を、より全体最適を実現できるアーキテクチャーとするために、マイクロサービスとして切り出しました。 このサービスではアルゴリズムの実現だけではなく、これまでのサービス品質を損なわないように、低レイテンシと高可用化を目指して多くのチューニングを行いました。 それらの取り組みを紹介します。 セッションで話すこと - 高速マッチングシステムのアーキテクチャー - ボトルネック調査の取り組み - 低レイテンシのための並列・非同期化と、そのエラーハンドリングなどの実装方法 - 高可用化のための取り組み セッションで話さないこと - マッチングアルゴリズムの詳細

テストの並列実行によって、テストにかかる時間の削減が期待できます。標準パッケージのtestingには、並列実行をサポートする仕組みが用意されていますが、その導入や適切な使い方には課題があります。 例としては、以下のようなトピックです。 ・一定規模以上のアプリケーションのテストをすべて対応させるのが大変なこと ・テストを並列実行することで新たなバグが発生すること ・データベースと接続するテストの並行化 このセッションでは、これらの問題を解消するために作成したツールや私が所属しているチームでの事例の紹介を交え、テストの並行化を無理なく導入・運用する方法についてお話しします。

[アウトライン] - 並行処理の難しさと逐次一貫モデルの破綻 - 観測可能性とhappens-before関係 - Go1.19メモリーモデルとsync/atomicパッケージ [セッション紹介文] The Go Memory Modelというドキュメントを知っていますか？これはGo言語で並行処理を行ったときにどのようなことが保証され、または保証されないかを記述したものです。広い意味ではGo言語仕様書の一部ともいえる、基本的で重要なドキュメントです。 しかし、The Go Memory Modelはごく短いドキュメントであるにも関わらず、Go言語仕様書よりも読解が難しいドキュメントです。それはメモリーモデルという分野のもつ複雑な文脈によります。この分野は複数のプログラム言語に跨って発展してきました。必要な知識のある場所もGoのドキュメントに閉じていません。 このような文脈がThe Go Memory Modelの中では説明しきれないため、行間が広くてハイコンテキストな、「わかる人が読めばわかる」ドキュメントになっているのです。 一方で、The Go Memory Modelの内容はグラフによる図示に非常に適しています。そのため、The Go Memory Modelを読解するには、具体的なプログラムを考え、たくさんの図を描きながら広い行間を埋めていくことが有効です。 このセッションでは、そのたくさんの図をお見せしながら、The Go Memory Modelが何を言っているのかを具体的なプログラムに即して解説します。Go1.19でThe Go Memory Modelに追加されたsync/atomicの仕様記述についてもスッキリ理解できるようになるでしょう。

Slices can be seen in almost every Go program, but many developers are still unware of how they exactly work. On the surface we might think they are simple constructs that allows us to handle multiple elements of a single type, but they are more than just a collection. Specially for people new to Go, slices can be a source of pain because of the behaviors it possess that you wouldn't expect from a traditional dynamic array or list. In this session we are going to do a deep dive on the slice type, starting from arrays and slice declaration syntax, slicing operations, copying, resizing and its surprising (or not) side effects. The session will be composed most of code examples using the playground, with an eventual dive into the compiler source code to see the relevant bits of slice implementation.

みなさん、Googleが公開したGo Style Guideは読みましたか？ ソフトウェア開発は継続的な活動であり、一般的に複数人で行うことが多いです。 継続的に複数人で開発を行う場合、自分が書いたコードを他人が読んだり修正したりすることが非常に多いです。 そのため可読性の高いコードを書くことは開発効率やメンテナンス性の向上に役立ちます。 Goはシンプルな言語ですが、どのように書くべきか悩むことが全くないわけではなく、そのような時従来はEffective Go/Uber Go Style Guide/OSSコード等を参考にどのように書くか決めていたと思います。 これらに加え、昨年末にGoogleからGo Style Guideが公開されました。GO Style Guide では従来よりも幅広い範囲について解説がされています。(例えば、テストの書き方については非常に詳しく記載されています) このトークでは「実際に開発しているプロダクトではどのように書いていたか」や「読んだ内容を元に現在はどう書いているか」を交えつつ「Go Style Guide」の内容から学んだことをご紹介します。

Go言語を使ったプロジェクトにおいて、開発生産性を上げていくためにコード生成の仕組みに取り組んでいる組織は少なくないと思います。実際に、例えばREST APIであればswaggerなどのスキーマファイルからoapi-codegen[1]などを使用してGoのhttpハンドラー周りのコードを生成したり、DBのスキーマ定義をもとにxo[2]などを使用してGoのDB操作周りのコードを生成するケースをよく見ることがあります。また、より簡易的にはgotests[3]などを使用して、スニペットのようにGoのテストの枠組みを生成するケースもあると思います。 しかし、静的解析だけによるコード生成は基本的には何らかの決まりきったルールによってのみコードが生成されていくモノだと考えています。 今回の発表では、jennifer[4]を用いたAST構築による静的解析ベースのコード生成をまずは出発点として、そこに大規模言語モデルのような機械学習を活用し、より柔軟性を持たせた形でのコード生成の仕組みを作ろうと思います。 そうすることで、usecaseやentityといった事業ドメインに近くほとんどのケースでコード生成を適用できないような領域に対しても、少しずつコード生成が適用されていく様子をお伝えできたらと考えています。また、ルールベースでは生成することが難しい、ユニットテストにおけるテストケース自体についてもコード生成がどこまで適用出来るのかをお伝えすることができたらと思います。 また、そういったコード生成の仕組みをどのように普段の開発プロジェクトに投入して行って、チームとしての開発生産性を高めているかという話にも触れようと考えています。 jenniferやGoのコードの静的解析の中身や仕組み自体についてはこの発表ではあまり触れず、そちらについては既に素晴らしい発表等[5]があるので参照していただく形にして、 この発表では 1. 静的解析を使ったコード生成のおさらい (20%) 2. AI/機械学習を使ったコード生成の方法・仕組みと、実際にどこまで適用できるのか (60%) 3. 実際の開発プロジェクトに投入する上で、工夫している点（20%) のような構成にして、静的解析のみによるコードの生成から一歩進んだ部分に焦点を当てたものにすることで、この発表内で収まるものと考えています。 大規模言語モデル周りの技術がまさに日進月歩なため、発表時点までに実装内容の方針が変更されることが想定されますが、現段階ではGPTモデルに対して既存の実装をもとにAPIを通して生成したいコードを複数パターン要求し、それを開発者が適宜選択しつつ、エラーを修正したり細かい調整をするようなやり方がプロジェクトに適切にフィットしていると感じています。 [1] https://github.com/deepmap/oapi-codegen [2] https://github.com/xo/xo [3] https://github.com/cweill/gotests [4] https://github.com/dave/jennifer [5] GoConference 2022 であれば https://gocon.jp/2022spring/ja/sessions/b8-sや https://gocon.jp/2022spring/ja/sessions/b3-lなど

Goで書かれたIoTゲートウェイを提供・運用し続けて得られた知見を紹介していきたいと思います。 MODE はエンタープライズ向けのクラウド型の IoT プラットフォームを提供しています。多くあるクラウドサービスとすこし違い、ソフトウェアが動く場所としてふたつの主要な場所があります。一般的なクラウドのサーバ上と、もうひとつは実際の現場で動くデータを収集したり機器を制御する IoT ゲートウェイ上です。 IoTゲートウェイが収集するデータは、様々なタイプの駆動モデルや通信プロトコルを利用する機器から収集されることが想定されます。例えばプロトコルだけでも EnOcean, BLE, Serial, TCP/UDP, OBD-II, BACNet, NMEA など様々です。また、各機器の駆動モデルも同期的・非同期的、状態を持つもの・持たないものなど多様にあります。 IoTゲートウェイをひとつのコード基盤上でいかに低コストで安定的に開発していくか・運用していくかはプラットフォーム提供者として大きな課題となります。本セッションでは汎用 IoT ゲートウェイ開発と運用を通じて得られた Go の知見を紹介していきたいと考えています。

先日Goの軽量routerの代表格であるgorilla/mux擁するGorilla Web Toolkitがアーカイブされました。 私たちのチームで開発しているGoのWeb APIはすべてgorilla/muxに依存しており、対応を迫られました。 フォークしてチーム内でメンテナンスを行うことも考えられましたが、チームの規模的に無理があり他のパッケージへ移行する必要がありました。 そこで今回の発表では移行時に行った他のパッケージの比較検討や最終的な決断の意思決定について話します。 この発表を通してパッケージの選定基準などについて、同じくrouterや外部パッケージを移行したい方の手助けになれば幸いです。

Goでマルチメディアのデータをリアルタイムに処理したい場合に、標準パッケージを使用したプログラムにおいて十分なパフォーマンス目標に到達するにはなかなか困難な道のりがあります 例えば画像データ処理における行列演算のCPU命令はGoから直接実行することはできず、Cgoを利用することになります Cgoを経由してC/C++で書かれたCPU命令を多用するコードは可読性/保守性の面からも品質の維持が難しいものがあります 本セッションでは、私の所属する会社でストリーミングサーバ上でリアルタイムに映像/音声処理を行うために、Goのエコシステムを活かしつつ高速な処理を実現するために行ってきたこと、どういった変遷を経てCgoを用いながら保守性の高いコードを維持できるようにしたか、halide-langとGoの連携など、リアルタイム処理を実現するまでの過程と手法を紹介します

"Cgo is not Go"という格言があるように、C/C++の資源をGoから呼び出す行為というのは、シンプルなビルドや優れたパフォーマンスといったGoの良さを殺してしまうため基本的には避けるのが主流です。Goコンパイラ・ランタイム自身もバージョン1.4を最後にC言語への依存を撤廃しており、なるべくpure Goで実装しようという潮流は今後も変わることはないでしょう。 しかし、世の中から「C言語で作られたリソースをGoで作ったアプリケーション内で利用しなければいけない」という場面が完全になくなることはありません。筆者もそのような要件からどうしても逃げられなかった経験を持つ一人です。 繰り返しになりますが、cgoをあえて使うという選択肢は一般的なものではありません。それゆえに、"Hello, World!"程度の小規模な利用の仕方であればThe Go Blog等に情報がありますが、ある程度の規模のC/C++ライブラリをcgoを用いてGoのコードから呼び出せるようにするためのノウハウはウェブ上には現状皆無といって良いかと思います。 本セッションでは、「C言語は学生時代に少しだけ触ったことがある、C++は一切経験なし」というバックグラウンドから、C/C++製の静的ライブラリを組み込んでGoのプロダクトを作ることになったときの筆者の試行錯誤の体験をお話しようかと思います。

去年Go Conference mini 2022 Autumn IN SENDAIでgo testとtestingパッケージの仕組みについて発表しました。 このセッションではtesting packageはtesting.Tの*testing.T.Logや*testing.T.ParallelなどUnit Testで共通して使われる内容に絞り、Goにおけるtestの全体像とその仕組みを追うようなセッションでした。 本セッションではGo Conference mini 2022 Autumn IN SENDAIの発展編としてGo1.18から登場したFuzzing Testの仕組みや内部実装について深掘ります。Fuzzing Testは機能としてもまだGoの公式から出ているチュートリアルのようにどのように動かすかについての詳細は日本語、英語含めて多くありますが、Goが提供するFuzzin Testの内部的な実装や仕組みに踏み込んでいる内容は少ないです。そのため、今後Fuzzing Testの仕組みを知りたい方や、興味はあるがまだソースコードリーディングできていない方に向けて発表します。 まずFuzzing Testを読むにあたり必要なtesting packageとgo testの仕組みについて知ることから始めます。これにより今後ご自身でtesting packageのFuzzing Test以外の仕組みを見たい際に1人でソースコードリーディングができるようになります。 その後主題でもあるFuzzing Testについて発表します。Fuzzingで与えられるCorpusは内部でどのように処理が行われているのか、go testで渡されたoptionがFuzzing Testにどのような影響を与えているかについてGoの公式から出ているFuzzingのチュートリアルを基に1つずつ見ていきます。 本セッションを通して視聴者の方はGoのFuzzing Testの仕組みはもちろんのこと、go testやtesting packageについても理解を深めることができます。

今回は主にパフォーマンスの観点から高速なHTTP routerを作るに当たっての紹介をする予定です。 ここでのHTTP routerは、static routing/path param routingの2つの機能を提供することを前提とします。 セッションの構成は以下の4つになります。 - 高機能なHTTP routerを提供する際に、なぜsync.Poolを使うのか - path params routingにおいて文字列を高速で扱う - 関数呼び出しの回数を減らすことでの高速化 - 上の3つを踏まえて、有名なOSSのHTTP routerが速い理由をまとめます 時間が余れば、sync.Poolを使う/使わないときや、文字列をナイーブに扱ったときのベンチマーク比較を紹介しようと思います。

Proposal Title: "Escape Analysis in Go: Understanding and Optimizing Memory Allocation" Abstract: Go is a popular programming language known for its performance and efficiency. However, in order to achieve maximum performance, it's important to understand how Go manages memory. One of the key concepts in this area is escape analysis, a technique used by the Go runtime to determine when and where to allocate memory on the heap. In this talk, we will cover the basics of escape analysis in Go, including how it works, common pitfalls to watch out for, and techniques for optimizing memory allocation in your Go programs. Outline: [20 minutes talk] Introduction to escape analysis in Go [8 minutes] Recap of memory allocation (stack/heap) and pointers Experiments to prove why escape analysis is important Explanation of what escape analysis is and how it works in Go How does escape analysis affect memory allocation Common pitfalls to watch out for [4 minutes] How to avoid unnecessary heap allocation Some special cases for escape analysis Techniques for optimizing memory allocation in Go programs [5 minutes] How to use the "go build" flag to check for escape analysis Best practices for variable declaration Measuring the performance improvements Conclusion [3 minutes] Summary of key takeaways Additional resources for further learning Originality: The Go documentation provides some information about what escape analysis is and a general overview of how that works. This talk will extend those ideas and discuss why it is important to know about this optimization and the cases where it works/not works. The talk will also include some major guidelines about how to use it for the general audience to consider. Target Audience: This talk is aimed at Go developers of all levels who are interested in improving the performance of their applications. Whether you are a beginner just starting out with Go or an experienced developer looking to optimize your code, this talk will provide valuable insights and information. The following groups will particularly benefit from this talk: Beginner Go developers: This talk will provide a comprehensive introduction to escape analysis and its benefits, making it an excellent starting point for those new to the language. Experienced Go developers: For those familiar with Go, this talk will provide a deeper understanding of escape analysis and its implementation, as well as best practices for applying it in real-world projects. Performance-focused developers: This talk will provide valuable information for developers who are focused on optimizing the performance of their applications. Attendees will learn about escape analysis and how it can be used to reduce the number of heap allocations and improve the performance of their applications. Background: I am a software engineer with a year of experience in developing Go-based applications. I have experience in Go memory management and optimization, and I am passionate about helping developers write more efficient Go code. I got introduced to this topic while finding ways to optimize the Go code. I was curious about how the memory allocations in Go work and found something related to Escape Analysis for the first time. As I learned more, I found this optimization beneficial and could be utilized more. I am confident that this talk would be of great interest to the attendees of Go Conference 2023 as I will be sharing my knowledge on a topic that is crucial for developers who want to achieve maximum performance in their Go-based applications.

Go1.19のリリースにより新しくGOMEMLIMITという設定値が増えました。GOMEMLIMITが導入されたことによりヒープメモリ量の上限をユーザー側から制御できるようになりました。Go1.19以前のGCのチューニング方法はGOGCだけでしたが、GOMEMLIMITが導入されたことによりGCのチューニング方法の幅が広がりました。 しかしGoは設定値を細かくいじらなくてもランタイムがある程度の最適化を行ってくれるため、一般的なAPIサーバーの開発等ではGOGCやGOMEMLIMITを意識することは少ないかと思います。そのため、これらの知見は中々溜まっておらず参考にする資料等も少ないのが現状です。 そこで本セッションではGOGC・GOMEMLIMITはどんな役割かについて発表します。また内部実装を見ることで仕組みから理解することを目的に発表したいと思います。また僕自身が経験した内容を基にGCチューニングの事例から活用方法についてもお伝えします。視聴者は本セッションを見ることでGOGC・GOMEMLIMITについての知見を深めることができます。また活用事例を通してご自身のプロダクトでGCチューニングをするべきかどうかを判断することもできるようになります。

Go1.20からはtree構造のエラーがサポートされることになりました。 詳細は以下のrelease noteでも言及されています。 https://tip.golang.org/doc/go1.20#errors もともとのproposalである https://github.com/golang/go/issues/53435 での議論をふまえ、Go1.20時点では、標準errors.Is/Asは以下のデザインとなっています。 - treeを深さ優先探索する - マッチしたものがあればそこで探索を打ち切り結果を返す - tree上のすべての枝がIs/Asにマッチすることを保証しない ですが、tree構造とのマッチ判定はユースケースによってはさらにいくつかの要求が考えられます。たとえば - 分岐した全枝についての一致を確認するより厳密な同一性判定 - treeのなかで一致した要素をすべて取り出す などです。このようなより柔軟な要求に対して、現状の標準errors.Is/Asを利用することはできません。 今回は元となった "errors: add support for wrapping multiple errors" proposalでの議論をおさらいしつつ、標準errorsでは実現できないいくつかの要求についてマッチ処理を実装したので紹介します。 また、実装中に感じた課題などについても触れれればと思います。 実装したレポジトリは以下です。 https://github.com/convto/errortree tree構造のerrはGo1.20から追加された新しい概念であり、整理のために多くの実験や議論が必要だと思っています。 この発表で該当の議論に関心を持つ方が増えれば嬉しいです。

Goのtestingパッケージにコミットした体験記とその際に学んだ並列テストの振る舞いの解説。 コミット内容： T.SetenvとT.Parallelの組み合わせを禁止する処理の考慮漏れの対応。 並列テストの振る舞いの解説： なぜ並列テストで環境変数の利用を禁止する必要があるのかを説明するために並列テストがどのような振る舞いをしているのかを解説します。 より具体的には以下のテックブログにまとめてある内容のお話をしたいと思っております。 https://tech.mirrativ.stream/entry/2022/12/22/171137 #チャレンジセッションを選択した理由 Goでの登壇が初めての方 → 初めてです Goに関連したプロジェクトに貢献した方 → testingパッケージにコミットしました # 言語 日本語

[Elevator Pitch] Goでデバッグをする場合, 基本的にはDelve, GDB, ロギングの3択になります. DelveやGDBによるデバッグは便利ですが複数の変数情報を高速に得ることは困難であり, この用途にはロギングが適しています. しかし, デバッグ用に追加したロギング用のコードを消し忘れ, 実行速度の低下や業務用のコードにおける機密情報のログ出力等の問題を引き起こす可能性があります. これらの問題に対処するべく, 私はGoの静的解析および動的解析によって変数情報等を表示可能で, コミット時に自動的に削除されるデバッグ用のロガーdlを開発しました. 本セッションでは, 前述したGoにおける3種類のデバッグ方法の利点および欠点ならびにdlの開発を通して得たgo/ast等のgoパッケージに関する知見をご紹介します. [Main Description] 開発において, 想定外の挙動をした際にデバッグをした経験がある方は多いのではないでしょうか? Goでデバッグをする場合, 基本的にはDelve[1], GDB[2], ロギングの3択になります. Delve[1]はサードパーティー製のGo用デバッガであり, 実行時の変数やスタック情報の表示や上書き, goroutineの情報取得等ができます. また, リモードデバッグを有効にすることで, VS CodeやGoLandなどのエディタやIDEに組み込んでGUI上でデバッグすることもできるため, 開発時に重宝します. GDB[2]はDelve[1]と似たデバッガで, gef[5]やpeda[4], pwndbg[6]等のGDBスクリプトにより, 低レイヤを対象としたデバッグを円滑に行うことができます. しかし, Go Blogの記事[3]に記載されているように, Goプログラムの構造を理解していないため誤った結果を表示する場合もあります. また, Delve[1]やGDB[2]はある1点の状態を詳しく得ることは得意ですが, 複数の変数情報等をまとめて高速に得ることは不得手です. したがって, 手軽に複数の変数情報等をまとめて高速に得る用途にはロギングが適しています. Goのロギングには, builtinパッケージのpanic, print, println, fmtパッケージやlogパッケージの各種関数およびメソッド, サードパーティー製のglog[7], Logrus[8], zap[9]等のロガーが利用できます. また, logr[10]が提供するinterfaceを満たすロガーを利用することで, それぞれのロガーを手軽に切り替えることもできます. これにより, Delve[1]やGDB[2]と違い, 複数の変数情報等をまとめて高速に得ることができます. しかし, デバッグ用に追加したロギング用のコードを消し忘れ, 実行速度の低下や業務用のコードにおける機密情報のログ出力等の問題を引き起こす可能性があります. 実際に, 私もインターンシップ先のリポジトリに対して余分なロギング用のコードを追加し, レビュー漏れで本番コードに紛れ込んでしまった経験があります． そこで, 私はGoの静的解析と動的解析によって変数情報等を表示でき，コミット時に自動的に削除されるデバッグ用のロガーdl( https://github.com/task4233/dl )を開発しました. Design Docsはこちら( http://bit.ly/3XGdtyF )です. dlは変数とその型情報, 変数が利用されているコードの行数を表示する機能とコミット時に自動的に削除される機能を提供します. これらの機能は, Goのgo/token, go/parser, go/astパッケージ等を用いた静的解析やruntimeパッケージを用いた動的解析を活用することで実現しています. また, dlは前述したlogrのinterfaceを満たしているロガーであればラップすることができ, 既存のロガーを変更することなく容易に導入することができます. 私が調査した中では, これらの機能を全て備えたロガーは他に存在しませんでした(2023/01/30現在). 本セッションでは, 前述したGoにおける3種類のデバッグ方法の利点および欠点ならびにdlの開発を通して得たgo/ast等のgoパッケージに関する知見をご紹介します. 過去のGo ConferenceでGDB[2]に関する講演[11]がありましたが, これとは異なる切り口の内容なので差分はあると考えています. [1] go-delve/delve: https://github.com/go-delve/delve [2] GDB: The GNU Project Debugger: https://www.sourceware.org/gdb/ [3] Debugging Go Code with GDB: https://go.dev/doc/gdb [4] hugsy/gef: https://github.com/hugsy/gef [5] longld/peda: https://github.com/longld/peda [6] pwndbg/pwndbg: https://github.com/pwndbg/pwndbg [7] golang/glog: https://github.com/golang/glog [8] Sirupsen/logrus: https://github.com/Sirupsen/logrus [9] uber-go/zap: https://github.com/uber-go/zap/ [10] go-logr/logr: https://github.com/go-logr/logr [11] Debugging Go Code with GDB:https://speakerdeck.com/kaneshin/debugging-go-code-with-gdb

Goはいまや多くのシステムクリティカルな製品を支える言語として広く採用されていますが、その内部構造に関する理解はまだ広く認識されているとはいえません。 本セッションでは、Goランタイムがどのようにメモリ管理を実現しているかをランタイムレベルから解説します。それを踏まえて、その仕組み故に気をつけなければいけないユースケースなどを深堀りし、実際にどのように解決するかを解説していきます。 本セッションはLinuxの知識なども必要となりますが、セッションを終える頃にはGoのメモリ管理について大まかな理解が得られることでしょう。

ブロックチェーンの領域では、分散型金融システムEthereumをはじめ、多くの場面でGo言語が活躍しています。 このセッションでは、ブロックチェーン領域でGoがなぜ利用されるのかを解説し、具体的にどのようにブロックチェーンの技術を支えているのかを実際のコードを見ながら紹介します。 ブロックチェーン領域でのGoの使われ方を学ぶことで、Goの特性を知り、分野を問わずGoを活用する際の知見となることを想定しています。また、このセッションがGoを通してブロックチェーンの技術を学ぶきっかけとなり、聴講者にブロックチェーン技術へ興味を持ってもらうことを期待しています。 対象とする聴講者 ・Goの強みや活用事例に興味がある人 ・ブロックチェーンの仕組みやこの領域での技術選定に興味がある人 セッションの目的 ・ブロックチェーン領域でのGoの利用事例から、Goがもつ強みを知り、Goによる技術選定全般に役立ててもらう ・Goを通してブロックチェーンの技術を学ぶ足がかりを提供する 扱うトピック ・ブロックチェーンの概要について 　・ブロックチェーンがあつかう課題や、P2P通信や暗号技術などブロックチェーンを支える技術の概要を説明します ・ブロックチェーンで活躍するプログラミング言語 　・ブロックチェーンにはどのような要件があり、なぜGoが選ばれるのかを解説します 　・近年、Rustの採用事例も増えており、GoとRustの比較についても触れられればと思います ・どのようにGoが使われているのか 　・Ethereumなどの有名OSSでの活用事例を紹介し、具体的にどのように(どのようなコードで、何のパッケージを使って)ブロックチェーンの技術を実現しているかを解説します

Go’s regexp package works great for most use cases but performance drops for complex expressions such as those in security firewalls. This presentation will show how go-re2 uses RE2, a C++ library, and wazero to improve performance of regex for any Go app, even where cgo is not available.

net/http/httptest.Serverは、 `go test` 実行時に実際にHTTPサーバを起動することでクライアント-サーバ間のテストをシンプルに実現します。 このnet/http/httptest.Serverのアプローチは、WebアプリケーションのテストであればWebアプリケーションを構成するレイヤーの外側からHTTPリクエストを送信するテストができますし、HTTPクライアントのテストであればHTTPクライアントを構成するレイヤーの外側にスタブサーバを簡単に用意できます。しかも `go test` の中で完結しており、テストサイズによる分類における他のミディアムテストと比べても安定しているといえるアプローチです。 発表者は、プロダクトの新規開発時のアーキテクチャの未完状態に対抗する手段として、net/http/httptest.Serverのアプローチをより広くテストに活用する方針を取りました。 これは、アプリケーションの外側を活用したのテストを厚くすることで、アプリケーション内部のアーキテクチャ変更に強くすることを目的としています。 本発表では、「net/http/httptest.Server のアプローチ」のメリットやデメリット、そのデメリットの緩和策、実際の効果などを紹介したいと思います。

近年、Go界隈でモノレポの需要は増えています。Goでモノレポのビルド環境を構築するといえば、まずBazelを連想すると思いますが、Bazelは学習コストが高さが難点です。ただ、ビルドタスクの依存関係の解決、リモートキャッシュ、分散ビルド、といったBazelの機能はモノレポを構築するにあたって魅力的です。そこで、Bazelと類似の機能を備えつつも扱いが楽なNxを紹介します。ある程度の規模のモノレポでも通用するタスクランナーを利用したいがBazelは難しいという方々には、Nxは一考に値します。

syncパッケージとは相互排他ロックなどの基本的な同期プリミティブを提供するパッケージです。 その中の一つにsync.Mutexというものが存在します。 sync.Mutexはgoroutineの排他制御を行うための機能です。 sync.Mutexの使い方やごく簡単なサンプルコードは数多く存在しますが、sync.Mutexの内部的な実装を解説した記事は現時点では2桁もありません。 そこで、本セッションでは、排他制御の定義、sync packageの概要について説明した後に、sync.Mutexおよび、Lock、Unlockメソッドに着目し内部実装レベルでコードリーディングし、理解を深めていきます。 理解を深めていくにあたって、次世代UNIXとして開発されていた分散OSであるPlan 9の存在は欠かせません。 そこで、ベル研究所の元メンバーであり、Plan 9に携わったのち、現Goチームで開発を行うRuss Cox氏の書いたSemaphore in Plan 9の論文を参考にします。 上記の論文を引用しながら、sync.Mutexの仕組みを原理原則から整理して話します。 セッションの聴講者は、sync.Mutexの理解および、実装を読むにあたり必要なGoのランタイムパッケージ、スケジューラ、go:linkname ディレクティブといったGoのエコシステムの仕組みについても学ぶことができます。

Goは並行処理を簡単に実現可能な強みを持つため、複数のクライアントと同時並行かつ中央集権的に情報を交換するサーバシステムを、コードの可読性を保ったまま実装することが可能な言語です。我々は、ネットワーク分野でもこの強みを活かすことができないか試行錯誤しています。 クライアントサーバシステムの例として、ネットワーク機器のパス管理を行うPCEという仕組みがあります。キャリアのように多くのルータで構成される大規模ネットワークにおいてパス管理は重要な要素ですが、誰もが手軽に試験・運用できるPCEはありませんでした。そこで我々は、Goの特性を活かしてPCEをOSSとして実装しました。その結果、誰でも手軽に試験できるようになりました。 本セッションでは、Go初学者であった我々がネットワークプロトコルやサーバ機能をOSSとして実装する中で理解したことについて、公開済のコードを用いて紹介します。 具体的には、 - goroutine と channel を用いたサーバのセッション管理 - gRPC によるサーバ情報取得/更新のためのAPI提供 - interface の定義・実装による標準ライブラリ有効活用や実装の隠蔽 について説明します。 本セッションの内容を取り込み開発することで、Go らしいネットワークプロトコルやサーバの実装が可能になります！

日に2億件をさばくGoで書かれた広告配信サーバーにおいて Goのversionを1.17から1.19に上げた際にレイテンシとCPUを増加させることなく、3〜4割のメモリ使用量を抑えることに成功しました。 そこで本セッションでは、実際の計測値を交えながらhttps://go.dev/doc/gc-guide をベースにGoのGCのしくみについて説明いたします。

Goで不足している画像処理を実装しました。 その際に並行処理を用いることによるパフォーマンス改善の検証を行いました。 Goには他の言語と同様にオープンソースの画像処理ライブラリがあります。しかし主要な画像処理手法は用意されていますが、Pythonと比較すると機能が充実していません。そのため実務で画像解析の処理を書く際に既存のライブラリにない手法は自分で実装を行いました。 実装した処理は画像内で指定した任意の４点を囲う領域に対してモザイク処理を行う処理です。 実装の際に画像内の各ピクセルにアクセスする部分に対し並行処理を用いました。並行処理によりどれくらいパフォーマンスが改善されるかを検証し、画像処理に並行処理を用いることの有用性を確認します。

Goの標準パッケージである`os`を用いたgoroutineの管理、プロセスが停止される際のシグナルのハンドリングについて具体例とともに紹介します。 特にコンテナで稼働しているWebサーバにおいてはシグナルを考慮した上で実装を行う必要があります。シグナルについて全く考慮していない場合、コンテナが終了するタイミングで同時に内部で動いているプロセスもキルされてしまい、中途半端な状態で処理が終了してしまうことがあります。 実際の発表の際は、弊社のコーディング試験サービスを例に挙げ、考慮しない場合にどのような問題が生じるのか、とともに紹介します。 このLTを通して、Goにおけるシグナルのハンドリングに関する基本について学ぶことができます。

GoでRDBを使う際には標準のdatabase/sqlがありますが、ORMを使用することもあります。 MySQLやPostgreSQLのような広く普及したDBにはSQLドライバが存在したり、対応したORMが多数存在します。 しかしNewSQLのような新しいDBにはそれらが存在しないことも多いです。 またGoはパターン化されたコードを自動生成する機構を言語の標準機能だけで作りやすい特徴があります。 特にORMの領域では近年有名なEntというパッケージがあります。 EntではGoでテーブル定義を行い、各テーブル・カラムに対応した型付きのコードを自動生成する特徴があります。 自動生成されたコードは基本的にメソッドチェーンで記述することができます。また マイグレーション機能も存在するため、Goのテーブル定義をDBに反映することもできます。 Gormや他の自動生成ではないORMと比較し、存在するテーブル・カラム名や型がコード上に定義されているため、DDLを参考せずともGo上だけでテーブル定義が把握できることや、名前や型を間違えにくいことが利点です。 しかしEntも対応したNewSQLの種類は少ないです。 そこで今回はNewSQLの一種であるGoogle Cloud SpannerのORMを自動生成しました。 生成されるコードは上述の利点からEntを参考にしています。 また最小限の機能を持つORMとしたかったため、マイグレーション機能は持たせていません。 そのためテーブル定義はGoで定義するのではなく、Information Schemaから読み取ることで、実際のDBのテーブル定義との同期を図っています。 本セッションを聴くことで、Spanner以外にもORMをGoで作成する際の実装ヒントを得ることができます。 例えばチームによってSnowflakeやBigQueryのORMを作成したいモチベーションがある場合、参考にすることができます。 またORMに限らずテーブル定義所の生成やテストコードの生成等のGoで自動生成する強みとアイデアを知ることが可能です。

私の所属する会社のSREチームは多くがインフラ系出身のメンバーとなっています。サービス運用に関するツールは各メンバーが得意の言語で実装されており知識の共有が行えなかったり得意言語以外のコードレビューや修正に時間がかかってしまうという課題がありました。そういった課題を解決すべく我々はチームの共通言語としてGoを選択しました。本LTでは「共通言語になぜGoを選択したのか」や「どのようにしてGoを学習し共通化していったのか」「Goを選んでよかったこと」といった内容についてお話しします。

プログラムを書くにはキーボードがほぼ必須となります。 自分好みのキーボードを探す時、キーボード自体を自作するという選択肢があります。 しかし現状の自作キーボードのファームウェアの多くは C 言語で作成されています。 Go Conference に参加されている人は Go で自作キーボードのファームウェアが書けると嬉しいのではないでしょうか？ このトークでは、 TinyGo を使って自作キーボードを作った記録を共有します。 TinyGo を使うと Go の文法で自作キーボードのファームウェアを書くことができます。 C 言語製のメジャーなファームウェアのように機能は多くないですが、欲しい機能は自分で追加することができます。 TinyGo で楽しい自作キーボードライフを。

本セッションではGoにおけるゲームの抽選ロジック紹介と、対象ロジックへのGenerics導入事例について紹介します。 ゲーム開発ではランダムドロップやガチャといった抽選を必要とする機能が多く存在するため、Interfaceを利用し各抽選ロジックの共通化を行ったのでその設計について紹介します。 また、Go1.18でGenericsが導入された後は、上記ロジックにGenericsを適用することで開発効率が向上したため、Generics導入前後の事例についても共有します。 本セッションを通じて、Goにおけるゲーム開発やGenerics活用の手助けになれば幸いです。

公式ドキュメントのEffective Goで推奨されているように、iotaを使ったやり方で列挙型と列挙子を表現すると、 - 列挙型が一つ存在し - その列挙型を持つ定数が複数存在する というような構成になる。 列挙子の一覧を出すだけならこのやり方は確かに手軽だが、それぞれの列挙子に更に何らかの挙動を定義するとなると、 メソッドごとに「既知のこの列挙子についてはこういった処理を行う」という形の条件分岐が登場することになり、 これはすなわち、列挙子を追加することになったら、そのたびにすべてのメソッドが影響を受けてしまう、ということを意味する。 このような問題点を受け、 - 列挙型を表すインターフェイスを一つ定義し - 列挙子ごとに、列挙型のインターフェイスを実装した型を定義する というような構成にしてみると、 - 特定の列挙子が持つ挙動はその列挙子の周りに集まり（凝集度の向上） - ポリモーフィズムで条件分岐を消すことができ - 既存のコードに触らずに列挙子を新たに追加することができる（Open-Closed Principleの体現） といったメリットが得られるのである。 という内容を、コードを持って説明します。