Panic を恐れるべからず Rust で panic! や assert! の利用を躊躇うべきでないという話。 個人の見解マシマシでお送りします。 この記事は Rustその3 Advent Calendar 2019 の18日目の記事である[0]。 TL;DR 不正な値の存在の存在を許してはいけない。 不正な値が存在できてしまう時点で、未定義動作を覚悟するくらいのつもりでいるべきである。 満たされるべき条件を満たさない時点で、プログラムの内部的な整合性は既に破綻しており、未定義動作も同然の状態である。 これ以上余計なことをする前にさっさとクラッシュせよ。 整合性破壊バグから「うまく復帰」できると思うのは甘え (極論)。 もうちょっと詳しくは 本題、大雑把な指針、まとめ を参照。 いろいろな panic Rust で panic させるにも様々な方法がある。 まずはそれらを見ていこう。 O
RealWorld 業務 Rust 実際に Rust 1.0 の頃から業務で Rust を使ってコードを保守してきてハマった落とし穴についての 知見 恨み言です Rustが素晴らしい言語であるというあたりまえのことにはこの文書では触れません 気が向いたら追加します 開発環境編 ビルドマシンを買ってもらえ ノートパソコンのCPUとメモリでは限界がある CPU 二桁コアのマシンを何人かで共有して使え VSCode の Remote SSH でがんばれ vim でもいいぞ ストレージは可能な限りデカくしろ target はブラックホール 10GB 超はあたりまえ、中には 100GB 超も sccache、 cargo cache 、 cargo sweep などを駆使してがんばれ docker も使うので大容量ストレージだけが正義だ sccache 使用例
これは何? RealWorld 業務 Rust に乗っかって普段から考えているなんやかんやを参照可能にしておく. 主に情報の補足と極論の補正 1. 但し業務というコンテキストは外してだいたいいつでも適用できるようにする. legokichi さんの考えには少なからず影響されていることに注意. 皆も自分なりの考えを書こう! (これ とかもどこかにまとめたいわね...) Re: docker でビルドできるようにしとけ docker でビルドできるようにしておくこと自体は大事なんだけど, 最近は Asahi Linux (aarch64) があり docker が絶対とは言えなくなってきた. そんなマイナー環境使う方が悪い? それはそう... (なので x86_64 環境も持っている.) なお今年の ISUCON14 では cross を使った. メンバーが Linux (x86_64), M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
