2019-11-10

Rust 入門の思い出

Rust

Rust は the book も core documentation も公式ダークモードが用意されてるのがマジで助かる
— pione30 (@pione30) 2019年8月13日

所有権システム完全に理解した
— pione30 (@pione30) 2019年8月31日

Rust the book を読みながら Rust いい言語だな…って 2 億回言ってる
— pione30 (@pione30) 2019年9月1日

Rust the book の 6 章を読んだ
— pione30 (@pione30) 2019年9月7日

the book 7 章読み
— pione30 (@pione30) 2019年9月8日

Rust の the book 第 8 章の exercise 1 個目をやった.
コンパイラの圧倒的な正しさが僕に何回も殴りかかってきたが, ついにコードが書けた.
— pione30 (@pione30) 2019年9月14日

the book 8 章の exercise を 3 つともやった.
まだ lifetime を解説されていないので borrow がうまくできず move しまくるコードしか書けない
— pione30 (@pione30) 2019年9月16日

the book 10 章をやっていきたいが SP (Suimin Point) が足りない
— pione30 (@pione30) 2019年9月23日

the book 10.1 まで読み
— pione30 (@pione30) 2019年9月25日

the book 10 章をやって lifetime 完全に理解した
— pione30 (@pione30) 2019年9月28日

the book 11 章が終わった. テストの章なので GitHub Actions を試してみた (rust:1.38-slim の docker image を引っ張ってきて `cargo test` するだけやが)
— pione30 (@pione30) 2019年10月4日

the book 12 章をやって grep できるようになった
— pione30 (@pione30) 2019年10月12日

the book 13 章よみ
— pione30 (@pione30) 2019年10月14日

TRPL 14 章を読んだ (Rust の the book の正式名称は "The Rust Programming Language" なので TRPL とも略されることを最近知った)
— pione30 (@pione30) 2019年10月19日

TRPL 15 章をやった. RefCell てやつがプログラマの警戒心を呼び起こすサインとしての型になるんだとわかった.
— pione30 (@pione30) 2019年10月23日

TRPL 16 章を読んで並行プログラミング完全に理解した
— pione30 (@pione30) 2019年10月27日

TRPL 17 章, 有益 of 有益な章だったな...
— pione30 (@pione30) 2019年11月1日

TRPL 18 章を流し読み
— pione30 (@pione30) 2019年11月2日

TRPL 19 章を読んだ. 常に覚えておくべき内容ではないが, リファレンスとして役立つ章だ.
— pione30 (@pione30) 2019年11月4日

TRPL 20.2 章の「もし意気込みがあるならこの要件を満たすコードを後ろの答えを見ずに実装してみなさい」ってやつが一発で書けたので気分が良い
— pione30 (@pione30) 2019年11月8日

TRPL 20 章を読んで Web サーバを作り, TRPL 読破したので Rust 入門完了しましたhttps://t.co/dJUOIzUitB
— pione30 (@pione30) 2019年11月10日

記録してた

第 4 章あたりから TRPL の読んだ記録を Twitter に残していこうと思い始めたのがわかる. (前回どこまで読んだっけという記憶が消滅しても大丈夫なようにしたかったのだと思う.)

標準ライブラリのドキュメントを眺めたり集中力が切れて Twitter をダラダラ見たり, そもそもがズボラな私なので読み切るのに丸 3 ヶ月くらいかかっていることもわかる. これからもマイペースでやっていきたいと思う.

感想

それにしても Rust は良い言語ですね. システムプログラミング用途という側面もよく引き合いに出されるけれどとにかく安全性 (所有権と借用ルール, ライフタイムによるメモリ安全性, etc.) を重視した言語デザインに強く惹きつけられました. 強力な型システム, ADT とパターンマッチ, struct と trait の分離といった便利な概念・道具もあり, cargo もあり. 私にもっとコンパイラや型システムの理論の知識があればより深い洞察が得られたのではないかという部分だけが心残りです (やっていけやという話でもある).

2019-07-16

bash から zsh に乗り換えた

かれこれ 5 年くらいログインシェルを bash のままで生活していたけど, ふと思い立って zsh に乗り換えて見ようかなと思った.

zsh のほうが色々と高機能で便利ということはぼんやり把握していたけれど, 今までは自分の脳と運用を過信していたので (またそれでどうにかなっていたので) bash からエイヤと乗り換えるほどの気力が湧かなかった.

しかし最近は仕事も忙しくなってきて, bash から要求される分まで脳の負荷を割ける余裕がなくなってきて, zsh でできることを bash で実現させる方法も (調べれば) あるのだろうけどそこまでするならもう楽して zsh におんぶにだっこで良くない？という気持ちになったのがきっかけといえばきっかけかもしれない.

fish を試してみようかなとも一瞬思ったけれど POSIX 非互換らしいということで, そこで何かしらハマったりしたときに労力を割くのは本質的ではないなと思ったので zsh を選んだ.

.zshrc の設定をいくつかググって好みのものをピックアップしたほか, もともと .bashrc の設定をカテゴリ別にいくつかのファイルに分割していて, alias の設定や nvm や rbenv の initialization 等は bash でも zsh でも共通だったので, それらは sh-commonrc という名前のディレクトリを作ってその下にまるごと移動させた. そして sh-commonrc/.commonrc というファイルを作ってそれらの設定ファイルたちを source するようにした. これで .bashrc と .zshrc で source sh-commonrc/.commonrc しておけば今後も alias の管理とかを共通化できて幸せになれるんじゃないかと思う.

github.com

逆に言うと何か共通で使えそうっぽい設定を追加するときはそれが共通で使えるかどうかを逐一調べるというコストが発生することになるけど, それがどの程度の負担なのかはまだわからないので, とりあえずある程度の期間運用してみてから考えようと思う.

zsh 固有の設定はだいたいはググった記事を読んでなるほどそうすかという感じで追加していったけど, git の情報をプロンプトに表示させる設定は少々独特だったので man zshcontrib して vcs_info のマニュアルを読んだりもした.

そういう感じで zsh に乗り換えた. 現時点での感想は補完が便利すね〜というところです. そんな感じの日記です.