Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 / unders...
Search
convto
June 07, 2024
Programming
6
2.2k
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 / understanding gob encoding
Go Conference 2024 の発表資料
Room1 15:50~
convto
June 07, 2024
Tweet
Share
More Decks by convto
See All by convto
gob バイナリが Go バージョンによって 出力が変わることについて調べてみた / Investigating How gob Binary Output Changes Across Go Versions
convto
0
68
Go 関連の個人的おもしろCVE 5選 / my favorite go cve
convto
3
350
みんなでたのしむ math/big / i love math big
convto
0
200
Go1.22からの疑似乱数生成器について/go-122-pseudo-random-generator
convto
2
530
Go1.20からサポートされるtree構造のerrの紹介と、treeを考慮した複数マッチができるライブラリを作った話/introduction of tree structure err added since go 1_20
convto
0
940
byte列のbit表現を得るencodingライブラリ作った
convto
1
1.1k
Go runtimeの歩き方/how to follow go runtime function
convto
1
920
入出金ドメインの苦労話と解決へのアプローチ/funds in/out difficulties and solutions
convto
2
1.3k
rsa_understanding_memo
convto
0
560
Other Decks in Programming
See All in Programming
これが俺の”自分戦略” プロセスを楽しんでいこう! - Developers CAREER Boost 2024
niftycorp
PRO
0
110
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
620
Vapor Revolution
kazupon
2
2.5k
デザインパターンで理解するLLMエージェントの作り方 / How to develop an LLM agent using agentic design patterns
rkaga
11
3.4k
第5回日本眼科AI学会総会_AIコンテスト_3位解法
neilsaw
0
140
The Efficiency Paradox and How to Save Yourself and the World
hollycummins
1
240
Leverage LLMs in Java with LangChain4j and Quarkus
hollycummins
0
180
複雑な仕様に立ち向かうアーキテクチャ
myohei
0
130
新規学習のハードルを下げる方法とは?/ How to Make Learning Something New Easier?
nobuoooo
1
130
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
3
400
Thoughts and experiences on Rust and TypeScript
unvalley
2
220
PaaSとSaaSの境目で信頼性と開発速度を両立する 〜TROCCO®︎のこれまでとこれから〜
gtnao
6
7.1k
Featured
See All Featured
The Invisible Side of Design
smashingmag
298
50k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
GraphQLとの向き合い方2022年版
quramy
44
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Building Your Own Lightsaber
phodgson
103
6.1k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
27
2.1k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Transcript
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 2024/06/08 Go Conference 2024
自己紹介 @convto 株式会社LayerX所属 レイヤ低めの技術などに興味がありま す (読みはこんぶとです)
はじめに - この発表は積極的に gob の採用を勧めているわけではありません! - ちゃんとシステム性質に合わせて判断できることが一番望ましく、そのた めに詳細な理解が必要!という主張です - この発表では、仕様を深掘りして性質を評価する過程をみんなで楽しめれ
ばと思っています - もちろん評価した上で用途に合うケースがあるなら、どんな技術であれ自 信を持って採用すると良いと思います
はなすこと - gobの概要, モチベーション紹介 - message encoding 評価の観点整理 - バイナリを見ながらgob仕様を深掘り
- gobの評価 - まとめ
gobの概要, モチベーション紹介
gob ってなに? - データのエンコーディングのひとつ! - 有名なのは json, xml, protobuf(wire), など...
- Go が標準パッケージで実装してる独自のエンコーディング!
gob ってなに? - データのエンコーディングのひとつ! - 有名なのは json, xml, protobuf(wire), など...
- Go が標準パッケージで実装してる独自のエンコーディング! なんで独自のものが 必要だったの?
https://go.dev/blog/gob go blog に詳しい
gob のモチベ - Go のプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - 自己言及的 (self-describing)
であること - Protobuf での学びを取り込むこと
gob で達成したかったこと - Go のプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - 自己言及的 (self-describing)
であること - Protobuf での学びを取り込むこと 少し解説
自己言及的 (self-describing) であるとは - メッセージ自身にどのような構造をしているかについての情報が含まれて いること - 構造を復元できるメタ情報を body に持っていると言い換えられる
自己言及的 簡易的な例 - 右のような構造は自己言及的 - type の解釈だけルールを決めてお けば、何が来ても値を受け取れる
自己言及的でなにがうれしいの? - メッセージ一つで構造が解釈可能 - 事前に準備するものも不要 - 埋め込む情報の量によっては高度 に元の状態を再現できる
Protobuf で学んだこととは? - Go では struct 定義でしか動作しないこと - proto2 required
は後方/前方互換担保を難しくした - required 実装を追加すると server/client 間で互換が壊れる - proto2 では default を設定できたが、実装や挙動が複雑になる - type ごとのゼロ値のような概念の方が取り回しやすい
Protobuf で学んだこととは? - Go では struct 定義でしか動作しないこと - proto2 required
は後方/前方互換担保を難しくした - required 実装を追加すると server/client 間で互換が壊れる - proto2 では default を設定できたが、実装や挙動が複雑になる - type ごとのゼロ値のような概念の方が取り回しやすい proto3 で解決されてるのでちょっと古い
現代的な観点でみたときの良いところ - Goのプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - self-describing であること - struct
必須など, 利用する encoding によって構造の持ち方が制限さ れない
現代的な観点でみたときの良いところ - Goのプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - self-describing であること - struct
必須など, 利用する encoding によって構造の持ち方が制限さ れない これらを全て満たすエンコーディングはない!ので作った
message encoding 評価の観点整理
メッセージエンコーディングの性質いろいろ - パフォーマンス - サイズ - 後方/前方互換性 - 自己言及的 (self-describing)
であるか - エコシステム - etc …
今回は以下の観点で gob を評価 - パフォーマンス - サイズ - 後方/前方互換性 -
自己言及的 (self-describing) であるか - エコシステム - etc …
バイナリを見ながら gob仕様を深掘り
ざっとバイナリをみてみる
ざっとバイナリをみてみる
ざっとバイナリをみてみる
型情報がそのまま埋められてそう ざっとバイナリをみてみる
型情報がそのまま埋められてそう 終端がありそう ざっとバイナリをみてみる
ざっとバイナリをみてみる 型情報がそのまま埋められてそう 終端がありそう このへんにメッセージ内容がいそう 型情報は最初の一回しか送らなそう
雰囲気で感じ取れること - ぱっとみ型情報をゴリっと送ってそう - 同一 stream 上だと最初の一回しか型を送ってなさそう - 明らかに終端っぽいやつがいそう -
フィールド名とかを構造としてベタっと送ってるので、Protobuf (wire) み たいに field num 同じなら名前変えても無問題!とはならなさそう
仕様をみてみる - https://pkg.go.dev/encoding/gob#hdr-Encoding_Details あたりを みてみる - ボトムアップで説明してるので、このドキュメントだけでは全体像はわから ない感じ。実装に眼を通す必要がありそう
いい感じの summary を発見 https://pkg.go.dev/encoding/gob#hdr-Encoding_Details
こんな感じそう
cnt: 36 こんな感じそう
cnt: 36 こんな感じそう
cnt: 36 id: -64 こんな感じそう
cnt: 36 id: -64 符号付き int は2の補数表現と 異なる形式で扱われています 取り扱いがすこし面倒なため ここでは飛ばします
(後ほど説明します) こんな感じそう
思い出そう https://pkg.go.dev/encoding/gob#hdr-Encoding_Details id が負数なら型情報了解!
cnt: 36 id: -64 wireType こんな感じそう
cnt: 14 cnt: 36 id: -64 wireType こんな感じそう
cnt: 14 cnt: 36 id: -64 wireType こんな感じそう
cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id:
64 こんな感じそう
思い出そう https://pkg.go.dev/encoding/gob#hdr-Encoding_Details id が正なら値了解!
cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id:
64 wireType value こんな感じそう
cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id:
64 wireType value cnt: 13 cnt: 1 id: 64 value こんな感じそう
こんな感じそう cnt: 14 cnt: 36 id: -64 wireType cnt: 1
id: 64 wireType value cnt: 13 cnt: 1 id: 64 wireType と value の詳細がわかれば勝てそう value
debug 用のよさげな内部実装を発見 - 構造をパースして良さげに出力する debug 用の実装を発見 - みるかぎり単純に端っこから consume していって解釈してるだ
けでとても読みやすい - この実装を追えば wireType と value の詳細がわかりそう!
cnt: 36 id: -64 wireType まずは wireType から読み取るぞ! この先スペースなさすぎに つきレイアウト変更
cnt: 36 id: -64 wireType id が負数なら type def と判断
debug 実装
cnt: 36 id: 64 wireType type def なら以下みたいな構造で パースされる(gob pkg
で定義)
cnt: 36 id: 64 wireType 初期値 -1 で delta encoding
されると 仕様で言及されてる debug 実装もそうなってる
cnt: 36 id: 64 wireType 0b11 = 3 delta encoding
初期値 -1 を考えて, field_number: 2 を表現 structType である! type def なら以下みたいな構造で パースされる(gob pkg で定義)
cnt: 36 id: 64 wireType 今回は StructT や! 0b11 =
3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である!
cnt: 36 id: 64 wireType 今回は StructT や! 0b11 =
3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である! debug 実装も 2 なら struct として食べ てる
cnt: 36 id: -64 wireType struct type はこんな感じ 0b11 =
3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である!
cnt: 36 id: -64 wireType 説明のために簡略化してまとめるとこ んな感じ! 0b11 = 3
delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である!
cnt: 36 id: -64 wireType 説明のために簡略化してまとめるとこ んな感じ! 0b11 = 3
delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である! いまここ!
cnt: 36 id: -64 wireType ← の 1byte から 大まかな構造が
わかる! 説明のために簡略化してまとめるとこ んな感じ! いまここ!
cnt: 36 id: -64 wireType 0b1 = 1 delta encoding
初期値 -1 を考えて, field_number: 0 説明のために簡略化してまとめるとこ んな感じ! いまここ!
cnt: 36 id: -64 wireType 0b1 = 1 delta encoding
初期値 -1 を考えて, field_number: 0 説明のために簡略化してまとめるとこ んな感じ! いまここ!
cnt: 36 id: -64 wireType 0b100 = 4 len: 4
string はよくある len が先に来て そのあと val があるパターン debug 実装
cnt: 36 id: -64 wireType 眼力で `item` とわかる string はよくある
len が先に来て そのあと val があるパターン debug 実装
cnt: 36 id: -64 wireType 眼力で `item` とわかる ほんとはこれがある →
string はよくある len が先に来て そのあと val があるパターン debug 実装
cnt: 36 id: -64 wireType = item ようはこう 眼力で `item`
とわかる
cnt: 36 id: -64 wireType 次は id 0b1 = 1
delta encoding 初期値 -1, 直前が0なので, field_number: 1
cnt: 36 id: -64 wireType 次は id いまここ! 0b1 =
1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
cnt: 36 id: -64 wireType 取り出して先頭bitが立ってなければ val 返す 立ってたら符号反転したものが len
数値も len のあと val っぽい ちょっと癖ある
cnt: 36 id: -64 wireType 取り出して先頭bitが立ってなければ val 返す 立ってたら符号反転したものが len
数値も len のあと val っぽい ちょっと癖ある 先頭bitが立ってるので len を表す int8(uint8(0xff)) = -1 反転して 1 len: 1
cnt: 36 id: -64 wireType とった len で値を読む (複数桁あったらいい感じに加算) int
だったら最下位bitが立ってたら反転 zigzag encoding ぽいかんじ
cnt: 36 id: -64 wireType 1bit 右shift 末尾が立ってないからそ のまま 0b01000000
= 64 id: 64 とった len で値を読む (複数桁あったらいい感じに加算) int だったら最下位bitが立ってたら反転 zigzag encoding ぽいかんじ
cnt: 36 id: -64 wireType 1bit 右shift 末尾が立ってないからそ のまま 0b01000000
= 64 id: 64 とった len で値を読む (複数桁あったらいい感じに加算) int だったら最下位bitが立ってたら反転 zigzag encoding ぽいかんじ gob の数値は全部これ これで飛ばしてた 箇所も読める
cnt: 36 id: -64 wireType つぎは終端!common type おわり!
cnt: 36 id: -64 wireType ようはこう Name = item Id
= 64
cnt: 36 id: -64 wireType ようはこう 解決ずみ ✅ Name =
item Id = 64
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0b1
= 1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0x10
= 2 先頭立ってないから そのまま値 len: 2
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0b1
= 1 delta encoding 初期値 -1 を考慮して field_number: 0
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0b100
= 4 len: 4
cnt: 36 id: -64 wireType つぎは field 眼力で `Name` 解決ずみ
✅
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 眼力で
`Name`
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 解決ずみ
✅ 0b1 = 1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 解決ずみ
✅ 0b1100 = 6 先頭立ってないから 値, 末尾0で反転なし val: 6
cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 解決ずみ
✅ 終端
cnt: 36 id: -64 wireType つまりひとつめの field は... 解決ずみ ✅
解決ずみ ✅ 終端 Name = Name Id = 6
cnt: 36 id: -64 wireType つまりひとつめの field は... 解決ずみ ✅
解決ずみ ✅ 終端 Name = Name Id = 6 👍
cnt: 36 id: -64 wireType ふたつめの field ! (サボります) 解決ずみ
✅ 解決ずみ ✅ Name = Price Id = 4 終端
cnt: 36 id: -64 wireType ふたつめの field ! (サボります) 解決ずみ
✅ 解決ずみ ✅ Name = Price Id = 4 終端 👍
cnt: 36 id: -64 wireType あとは終端! 解決ずみ ✅ 解決ずみ ✅
終端
cnt: 36 id: -64 wireType あとは終端! 🎉🎉🎉🎉 終端
つぎは value を! cnt: 14 cnt: 1 id: 64 value
cnt: 14 cnt: 1 id: 64 value 余談: さっき skip
したこまいところもいまは読める 先頭立ってるから len, 符号反転して len: 1
cnt: 14 cnt: 1 id: 64 value 1bit 右 shift
して 0b01000000 末尾0だから 64 余談: さっき skip したこまいところもいまは読める
cnt: 14 cnt: 1 id: 64 value id: 64 の構造は
これ 構造をみていく
cnt: 14 cnt: 1 id: 64 value id: 64 の構造は
これ 構造をみていく ようはこれがわかればよい
cnt: 14 cnt: 1 id: 64 value id: 64 の構造は
これ id が負数でないので val で解釈 debug 実装
cnt: 14 cnt: 1 id: 64 value id: 64 の構造は
これ wireType によってちょっと挙動がかわる debug 実装
cnt: 36 id: -64 wireType id: 64 はこんな感じの型だったのを思い出して 🎉🎉🎉🎉
cnt: 14 cnt: 1 id: 64 value id: 64 の構造は
これ wireType によってちょっと挙動がかわる こっちを通る
cnt: 14 cnt: 1 id: 64 value どんな感じで評価する? debug 実装
cnt: 14 cnt: 1 id: 64 value どんな感じで評価する? debug 実装
delta encoding field num
cnt: 14 cnt: 1 id: 64 value どんな感じで評価する? debug 実装
field num に登録された型でパース
cnt: 14 cnt: 1 id: 64 value Name field 0b1
= 1 delta encoding 初期値 -1 を考慮して field_number: 0
cnt: 14 cnt: 1 id: 64 value Name field len:
6
cnt: 14 cnt: 1 id: 64 value Name field Name:
banana
cnt: 14 cnt: 1 id: 64 value Name field Name:
banana 👍
cnt: 14 cnt: 1 id: 64 value Price field 0b1
= 1 delta encoding 初期値 -1, 直前0を考慮して field_number: 1
cnt: 14 cnt: 1 id: 64 value Price field 先頭bitが立ってるので
len を表す int8(uint8(0xff)) = -1 反転して 1 len: 1
cnt: 14 cnt: 1 id: 64 value Price field 1bit
右shift 末尾が立ってないからそ のまま 0b01100100 = 100 val: 100
cnt: 14 cnt: 1 id: 64 value Price field 1bit
右shift 末尾が立ってないからそ のまま 0b01100100 = 100 val: 100 👍
cnt: 14 cnt: 1 id: 64 value item type の値を読み切った!!
終端 🎉🎉🎉🎉
宿題: 2こめの val 自分で読んでみてね cnt: 13 cnt: 1 id: 64
value
gobの性質の評価
今回は以下の観点で gob を評価 - パフォーマンス - サイズ - 後方/前方互換性 -
自己言及的 (self-describing) であるか - エコシステム - etc …
今回は以下の観点で gob を評価 性質 \ encoding gob json protobuf (wire)
サイズ 前方/後方互換性 自己言及的か エコシステム
ざっくりこんなレイアウトだったのを思い出そう cnt: 14 cnt: 36 id: -64 wireType cnt: 1
id: 64 wireType value cnt: 13 cnt: 1 id: 64 value
型定義も含むため val 1こなら json の方が安い
val 単体なら gob の方が安い
単一 stream 内では型定義は 1つしか流れないの で stream で使おう!
サイズはこんな感じ 性質 \ encoding gob json protobuf (wire) サイズ 🔺
stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 自己言及的か エコシステム
cnt: 36 id: -64 wireType 眼力で `Name` フィールド名を含めた型情報を持っている ことを思い出そう
フィールド名を変えると値が取れなくなる - のでおおよそ互換性については json と同じ性質を持っていそう - ただ gob はアプリケーション側の型の差分についてはわりといい感じにし てくれる
- ポインタあるなしとか、フィールドなかったら単に無視とか - protobuf(wire) と違って具体的なフィールド名などが露出するので、命 名変えた時とかは気をつけないと過去のメッセージから値を取り出せない
互換性 性質 \ encoding gob json protobuf (wire) サイズ 🔺
stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か エコシステム
cnt: 36 id: -64 wireType 完全な型情報を持つことを思い出そう
自己言及的か 性質 \ encoding gob json protobuf (wire) サイズ 🔺
stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム
エコシステムは ...? - json はどこでも使える - protobuf(wire) は高度なエコシステムのサポートがある - 一方
gob は現時点で Go からしか使えない! - 言語埋め込みだから実現できる高度な機能とのトレードオフ - 理屈上他言語にも実装できるから、どうしても困ったら最悪そうすればえ えかくらい
こうなった! 性質 \ encoding gob json protobuf (wire) サイズ 🔺
stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる
性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream
で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる gob はどういうときに使えるか
性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream
で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる これが許容できて gob はどういうときに使えるか
性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream
で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる この性質を強く 求めていて gob はどういうときに使えるか
性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream
で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる かつ json, protobuf (wire) の中間みたいな バランスが噛み合う用途 gob はどういうときに使えるか
gob はどういうときに使えるか - Go でしか使えない制約を受け入れられるとき - 検証用途のコードで使うとか - データライフサイクルが短いもの -
キャッシュとか - RPC やりとりの encoding として - 後述するメリットとバランスがとれるとき
- Go でしか使えない制約を受け入れられるとき - 検証用途のコードで使うとか - データライフサイクルが短いもの - キャッシュとか -
RPC やりとりの encoding として - 後述するメリットとバランスがとれるとき gob はどういうときに使えるか じつは標準の net/rpc と かでも使われてる
gob の嬉しい性質 - Go で完結してすぐ使えて嬉しい - 大抵嬉しいと思う - Go でしか使えないこととのトレードオフという感じ
- そこそこ効率がよかったり、まあまあメッセージの互換性が取れることが嬉しい - デメリットとバランスするなら採用余地あり!
まとめ
まとめ - みんなでバイナリを読んで gob を完全理解しました - 大体どれもこんな感じなんで興味あったら protobuf (wire) の
spec も読ん でみてください - encoding 仕様からいくつかの性質について整理した - gob が使えそうなところや, 採用した時の嬉しさを整理した - キャッシュやRPCにおすすめ - Go から便利に使えること, その他の性質が程よいところがメリット - pros/cons 整理してバランスするならいい選択肢
みんなでバイナリを読もう!
完
ご清聴ありがとうございました