見出し画像

Rust学習 - 所有権の概念に入門(+α:Rustユーザのコミットメント事情をしりたい)

今日も空が青いです。画像はそのイメージ。今日はRustの所有権の概念に入門する日だった。

本題


所有権とは


さっそく、所有権の概念について学んでいく。昨日調べたいと言ってた概念。Rustの醍醐味の1つ。

オーソドックスに、公式サイトの解説を見ながら学んでいく。

↑読んだ。スタックとヒープを題材に説明されているのを確認。一般的なデータ構造(=スタックとヒープ)に着目した例で所有権を学んでいくスタイルらしい。いいな。

つまり

  • ヒープに格納された各値には「所有者」という変数というか属性みたいなものを、内部的にそれぞれの値に対応付けて管理していて、それを所有権の管理とよんでいる。

所有者という変数を対応付けて管理する理由は

  • 平たく言うと、ヒープに格納されたデータを随時把握し続けて、メモリ不足に陥らないようにするなどの管理をするため。あるいはその最適化のため。

だと理解した。

ヒープというのが、コンパイル時にサイズがわからなかったり、サイズが可変のデータを格納するための領域という概念だと知ってる前提のもと、完全に理解した

所有権のルール

  • 所有権にはルールが決まっており、このルールに基づいて所有者の対応付けを管理するらしい。覚えておこう。

    • 所有権のルール

      • いかなる時も所有者は一つ

      • 所有者がスコープから外れたら、値は破棄される(つまり、ヒープ上に格納された値の破棄)

      • Rustの各値(つまり、ヒープ上に格納された値)は、所有者と呼ばれる変数と対応している。

借用とは?

所有権の管理がされていることから、なんとなく推測はできる。一度定義された変数のアドレスを持ち回る仕組みだろう。たぶん、参照とセットで覚えるやつ。しっかりと借用の定義を確認していこう。

https://doc.rust-jp.rs/book-ja/ch04-02-references-and-borrowing.html

↑つまり、
所有権をもらうことなく値を関数の引数として渡すことが「参照」※所有権が渡らないので、関数の実行が終わっても「参照」を使って渡している場合、その値が所有権管理の仕組みによって破棄されてしまうということが起こらない。参照の概念のおかげ。

&s1

↑のように「&」から始まる記法により、s1の値を参照する参照を生成することができる。
関数の引数に参照を取ることを借用と呼


スライスとは?


こちらも昨日わからなかった問題。「文字列スライス」って何?所有権に続く形で説明されていたので合わせて確認していこう。

↑読んだ。聞いてたとおりだった。スライスの概念によって、コレクションの中の一連の要素を参照できるということらしい(全体ではなく一部の参照)

スライスは所有権のないデータ型とあるがこれはどういう意味か?

fn first_word(s: &String) -> &str {
  
}

本題+α


Rustのバージョン1.0が出たのは2015年(Rust 2015)で5年以上も前だ。最新のRustバージョンはRust2021。今更ではあるが少しずつ加速していくため、「Rustにコミットしている人がどんな方々」か、そして「Rustメリット・デメリット」を点検していく。

Rustにコミットしている人がどんな方々


Rustにコミットしている人がどんな方々なのか?という疑問から、企業内ソフトウェア開発、OSSコントリビュート、出版活動、教育機関について、それぞれ事情を調査。

企業内ソフトウェア開発については、Github上で、Rustを使ってる日本企業のリストがメンテされているのを目撃。出版活については入門用の書籍を出している方の経歴をさっと確認。OSSコントリビュートについては、GitHub Sponsorsによる支援をうけつつdenoのlinterなどRustで実装されたOSSにコントリビュートしてる日本人の方が一定いる。一部(おおく?)の大手はGithub Sponsorsを使ってOSSに寄付をするOSS推進活動を行っている。一部の大学教育ではRustの講義をしているらしい。2022年の新卒には大学でRustの講義を受けた人材が一定数いるという理解。

Rustメリット・デメリット


Rustの入門用の書籍を出版されている方々のブログを中心に拝読、Rustのメリット、デメリットの所感を考える。そして、箇条書きで整理。

結論としては、OSSの世界では処理速度と高い開発効率への期待からか、積極採用されているであろうことを理解。いっぽう、特定の企業でのサービス開発では関心が寄せられつつも適用できずにいる企業がほとんどと思って学習していく。自分でハンズオンで布教できるリーダー的存在がいて、表面的な言葉に留まらないある程度の裁量(そして実行力)がある組織といえば、ずいぶん範囲が限定されそう。
これは推測ですが、たぶんビルドには長い時間が掛かるはず。規模感にもよるし、問題が表面化するかはビルドの頻度次第。

--
それで、メリットはやはり処理速度。しかし、これを活かすには高いリテラシーとやりがいのあるテーマの両方が必要。データ分析、解析、AI/機械学習、検索、インメモリDB,コンパイラやリンターなど遅延が開発体験に直結するライブラリ。遅延が少ないことが評価に直結するソフトウェアを考えて積極的に適用していくことをイメージ。開発効率は、、理解はする。ただ、Rust単独での見立てができるのは暫く先か、自分の知見の問題。しかし、Rustの航続期間は他の言語よりも明らかに短い。エコシステムの成熟度は先行している言語のまだ高いはず。他の技術スタックも、年々改善されている。具体的には、Elixir/Phonenix(3年前にElixirを使っていた)や、先祖にも近い、Ruby/Rails(4年前に少し使っていた)も随分高い開発効率だと思う、あるいは、単に優れているとはいえない。もちろん、長く使われているから開発効率が高いという理屈はない。理解して信じたものが救われる世界か?要注目だ。
逆にデメリットは、所有権の概念は特殊さ、さらに、マルチパラダイムのコンパイル型言語は随分独特な印象を持たれるだろう。あえていうなら、Rustでなければならない大義名分を見つける敷居の高さは特に日本の社会ではデメリットといえる特徴。1社での経済合理性で判断すると、Rustでなければいけない理由など見つからないことも多いのでは?Rustを活用する機会にたどり着けない辛さというのでもいうのだろうか。学習コストをデメリットというが、主戦場にいる方々、つまり、普段C++などで実装している人は気にも止めないレベルだと思う。むしろ過去の体験から比べれば学習効率はプラスでしかないはず。JavascriptとかPythonとかと比べて?比べてはいけない。しかし、やってみれば大したことはない、無意識のレベルでの学習のハードル。

  • メリット

    • 処理速度

      • GC(ガベージコレクション)が無い。GCによるプログラムの停止を避ける。メモリは、コンパイル時にチェックする一定の規則とともに所有権システムを通じていつメモリ上からオブジェクトが解放されるか管理されているためGCが必要ない(所有権の概念)

      • 静的ディスパッチによるゼロコスト抽象化

    • 開発効率

      • rustupによる簡単な環境構築

      • エラーメッセージが親切

  • デメリット

    • 学習コスト

      • 借用(・所有権)・ライフタイムの概念は馴染みが薄い

        • 概念と基本文法を理解するためのハンズオンなどの取り組みでカバー


次は?


次は、OSSコントリビュートするというのは実際どのような体験なのか調べてみよう(既に調べはじめている)。当たり前だという感じもするが、実際しっかり調べたことはなかった。コミットの方向性としてきちんと理解しなおそうと思う。

ではまた次回!

この記事が気に入ったらサポートをしてみませんか?