「Rust、何もわからない... #9」のメモ

proc-macroの勉強してsqlxのバグを修正した話(Southballさん)
- マクロを触ってみる
- 抽象構文木(AST)から抽象構文木への変換を定義
- 3種類
- proc_macro
  - ソースコードを生成できる
  - そのままでは書きにくい
- proc_macro2、quoteを使うとシンプルに書ける
  - syn: Rustの構文解析ができる
- cargo expand: マクロの開発に便利。展開後のコードが見られる。
- sqlxのバグの修正
- エラーの型を指定していないのにエラーが出る
- cargo expandでチェック
Rustで始めるコードファーストなOpenAPI定義の生成(TaKO8Kiさん)
- Rust compilerのコントリビュータ
- Peppol: 受発注や請求に関する電子文書に関する規格
- SMP、Access Pointのラッパー、...を開発
- コードからOpen API docsを生成
- utoipaクレートが便利
- 注意点
- $ref
- 壊れにくい定義を作るために
- 存在しないスキーマを参照して壊れることを少なくしたい
- 定義していない型をコンパイルエラーにしたい
- inlineで対応できるが、なしでもできるように
- cargo expandでコードを見てみる
- bodyに定義されていない型が来たときに・・・
- openai.yamlと実装に差分が生じないように、テストを書いている
Rust製プロダクトを3年以上運用して得たノウハウ(山本一将さん)
- プロダクトで使えるか?
- 大変だが使える + 長期的には良い
- 苦労したこと
- 学習コストが高い << クレート
  - クレートが未成熟、ライブラリのPRが放置されている + 情報が少ない
  - 突然OSSが放棄される(ex: actix-web)
- 恩恵
- コンパイルが通ったときの安心感
  - モノリスからコードの分割
- メモリの使用量が少ない
  - AWS: 小さいインスタンスをスケールアウト
- 使い続けていくための努力
- どう書けるようになるか?
  - 社内で教育体制・ユーザグループ
チームの規模
- 4〜8人
言語の選択肢・基準
- 立ち上がりから。CTOの趣味。
- 好きだから使いたい。XMLが巨大 & サードパーティ製のクレートが使いやすい
- コンパイラが親切
- 参加した時点では採用されていた。RailsからRustに。
コードからOpenAPI定義を生成するアプローチを取った理由は?
- OpenAPIジェネータが壊れている
- 実装と対応させたい
チームで新しい言語を導入するときに最も気をつけることは?
- 完璧は目指さない
- cloneが乱用されがちだが、今は動くことを優先
- Rustがわかる人・詳しい人を1人置く
- プロダクトに言語が合ってるか?メンバーが使えるか?興味あるか?

KATO-Hiro / CodeReadingForMe

「Rust、何もわからない... #9」のメモ #205