自分でコードを書いて動かしてみることが何よりも重要である。v)未解決mmap「ファイルを実メモリ空間として使うアイデア」という理解。アクセスするとファイルに読み書きする仕組み。メモリにおさまりきらない巨大な空間をファイルとして実現したり、ファイルストリームを操作するのでなくメモリ上をランダムアクセスするように扱ったりできる。値が安定ではない変数。別スレッドで変更されているかもしれない共有変数とか、ハードウェア的に値が変化してしまったりするとか、そういうの。レジスタに乗せた値を使い回すみたいな最適化ができないとか、そういう並列性を阻害する要因になったりする。動いたら勝手に動いて勝手に止まってくれるスレッドを放置するときにデタッチ。自炊の悩み(肉は良いのか悪いのか実験)Enumは直和、Structは直積(Atsukiさんの説明がGreat)Enumはそれぞれの値(Variant)が独立しているので直和的な感じで、Structは例えば、2つの属性をもつStructがとれる値の組み合わせは、総当たりだから、直積って感じ集合Aが{0,1,2}、集合Bが{a,b,c}のとき、直和は{0,1,2,a,b,c}だからenum。されるだろうが、今回はコンパイラによる最適化は行われないものとする。「文字集合」と「文字エンコード方式」を区別するのじゃ!ただ、文字コードについては、『文字集合』の話をしてるのか『エンコード方式』の話をしてるのかを意識する癖を付ければ(そのうち無意識になるはず)、そこまで混乱することはないかもです。バックスラッシュと円マーク問題などややこしい話もありますが、そのへんは枝葉の話なので。○○積シリーズ直積、デカルト積、アダマール積、外積、内積ラムダ計算ってなんだろう?いつか知りたいね。UTF32らしいです。そのままの表現とのこと。https://discord.com/channels/508093437187457045/882639711447961710/898180598529687593型安全って何よ?前述のように型安全性が具体的にどのようなものであるかはプログラミング言語や文脈に依存する。何」で考えると、「私の中の型安全の定義」がしやすそう。発音シリーズ『プログラミング言語Rust(オライリー)』によれは、"mut"は「ミュート」と発音するそうです。"let"は「れっと」でよかったはずです。"fn"は、「ふぁん」とのことです。式である嬉しさ文は命令なので結果を返さず、式は演算なので結果を返す、的な違いだったかなと。if文ではなくif式だと嬉しいのは、例えば分岐によって変数に入れる値が変わるときに、文だとと、一発で変数に代入できたりします。rubyのifは式なので、if自体が最終的に値を返します。3項演算子がなかったりしますね。if式で十分実現できちゃうので。if式は三項演算子の上位互換ですね。20}参照とポインタを区別する!Rustでは、参照とポインタは区別されており、参照は、後に述べる所有権やライフタイムによって安全性が保証されているが、ポインタはその限りではない。ポインタは何でもできる!何でもできるってことは危険なこともできたり、バグったりするわけで。いう背景からなのか、ポインタに制限をかけて安全に使えるようにしたのが「参照」という理解。いうか、区別したことなかった...他のメンバーも区別したことが少なかった印象。逆に言えば、厳密な(?)区別をしなくても"使う分には困らん"的な話かも。参照以上の機能を提供します。所有権と借用の概念を使うRustにおいて、参照とスマートポインタにはもう1つ違いがあります。参照はデータを借用するだけのポインタなのです。対照的に多くの場合、スマートポインタは指しているデータを所有します。以外でも、一般に「関数を渡す」というのは、関数の定義を指す参照なりポインタなりを渡すという挙動になっているんじゃないかしらと思います。それを言語がカバーしてくれているから、あたかも関数が数値や文字列と同じ値っぽく使えているだけで。いうか、関数を渡したときの挙動を調べる方法がわからないのだが?調べ方がわからん!デリファレンスメモGoだけど。符号無し整数なので、マイナスの範囲を取れないからというのもあるかと。結果がマイナスになる計算をすると実際マズイ、ということを確認・実証するためのコードでした。https://discord.com/channels/508093437187457045/882639711447961710/903252859137720350↓からhttps://discord.com/channels/508093437187457045/882639711447961710/903253988013662269の流れ。(とメッセージが出るが、正確にはアンダーフロー?)によってpanicが発生し、プログラムが停止してしまうことが確認できるかと。いうのはコンテナの一種で、ヒープ上にデータを配置したい場合に用いられる。bark()がCatのbark()なのか、Dogのbark()なのかを区別できないのであれば、このポリモーフィズムが実現できない。コンパイルの仕組みがみえてきそうかもコンパイラ内部では、所有権の移動を線形論理式に変換して、その式が成り立たなければエラーにするということをしてそうですね。get_opt(100).unwrap());}Rustの強力さがワクワクRust言語では同期処理で陥りがちなミスを型システムにより防ぐことができる。『わかりやすさの罪』アロマオイルをたきはじめる。第2版――料理の科学と実践レシピ』(https://www.oreilly.co.jp/books/9784873117874/)来年もベストバイやろう!アトミックはコンピュータのコア概念であって、DB特有の話題じゃないよ!せや!追記。前回(第9回)、「アトミック」について、「他からの可視性」か「トランザクション(ロールバック可能)」かで、低レイヤと高レイヤで認識の相違があるよね、という話がありましたが、これについて再考したところ、やはり「他からの可視性」が(アトミック性の)本質であり、トランザクション(ロールバック)はその1手段に過ぎないということに気付きました。「口座Aから口座Bへの100万円を送金する(が、失敗する)。」という以下のシナリオを考えてみます。1口座Aから100万円を引き落とす。2口座Bへ100万円入金しようとしたが、何らかのエラーが起きて、入金できない。3ロールバックして、口座Aからの引き落としもなかったことにする。「『口座Aから引き落としたが、口座Bへは入金していない。』という状態を誰にも観測させない。」ためのはずであり、「トランザクション(ロールバック)は、アトミック性(可視性)を保証するための手段であると言えます。(1993年)は、フェッチ・アンド・アッドがコンペア・アンド・スワップよりも劣っていることを証明した。LL/CSは「なんとなく3つくらい選んだ」というノリじゃない。3つ(+FetchAndなんとか)の4つ、アセンブラ命令として登録されている!アトミック操作の代表的な4命令。デザインパターン的な雰囲気。CPUアーキテクチャに依存しない話っぽい。アトミックという性質から導かれることで、「観測できるか」が重要な話!低レイヤだと、観測できるかどうかが重要で戻せるかどうかは考えないです。いうか、低レイヤレベルでは復元自体ができない。マルチコアのときに、他のコアから見えるかどうかも大事!この辺、仕事でも実際に「他コアから〇〇が観測できるようになる前に、△△が観測可能になっていること。」みたいな仕様は書きます。仕様として書くってのはなるほど感ある。Goのsync/atomicパッケージの命令の意味がだいぶつかめた説!https://pkg.go.dev/sync/atomicアセンブリの省略(?)用語x86-64のアセンブラ命令の末尾のlは32ビットで、q(quadの意)が64ビットです。longだと思います。longは操作対象のデータが32ビットという意味です。CPUは16ビットを基準と考えるので、4倍のquadです。理解の解像度が上がる!何の話かというと、「Cとかのソースコードの行」と「CPU命令」は1対1対応じゃない!ソースコードの1行分が、複数のCPU命令を実行することになる。ソースコードだけだと、理解が甘くなりがち。ソースコードから吐き出されたアセンブリを読むと、抽象度のレベル(というか、粒度?)が揃うので、より中身を理解しやすい。