Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
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
フロントエンドのディレクトリ構成どうしてる? Feature-Sliced Design 導入体験談
osakatechlab
7
3.7k
Haze - Real time background blurring
chrisbanes
1
440
React への依存を最小にするフロントエンド設計
takonda
21
8.9k
あれやってみてー駆動から成長を加速させる / areyattemite-driven
nashiusagi
1
160
14 Years of iOS: Lessons and Key Points
seyfoyun
1
690
Missing parts when designing and implementing Android UI
ericksli
0
390
TypeScript でバックもやるって実際どう? 実運用で困ったこと3選
yuichiro_serita
17
7.6k
CSC509 Lecture 14
javiergs
PRO
0
100
layerx_20241129.pdf
kyoheig3
2
260
The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | droidcon Italy
prof18
0
140
Keeping it Ruby: Why Your Product Needs a Ruby SDK - RubyWorld 2024
envek
0
110
これが俺の”自分戦略” プロセスを楽しんでいこう! - Developers CAREER Boost 2024
niftycorp
PRO
0
110
Featured
See All Featured
A Tale of Four Properties
chriscoyier
157
23k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
We Have a Design System, Now What?
morganepeng
51
7.3k
Bash Introduction
62gerente
608
210k
A Philosophy of Restraint
colly
203
16k
How GitHub (no longer) Works
holman
310
140k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Unsuck your backbone
ammeep
669
57k
Facilitating Awesome Meetings
lara
50
6.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
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 整理してバランスするならいい選択肢
みんなでバイナリを読もう!
完
ご清聴ありがとうございました