ニコニコ大百科

「もしC++11を一から設計したら」という印象なんだがどうなんだろう。

速度が必要なことやりたいんでちょっと調べたけど
配列にいちいち境界チェックが入るという事実に驚いた
境界チェックしないアクセス法と[]演算子オーバーロードはあるみたいだから
ごにょごにょすればいいのかもしれんが
本当にC++と同等まで最適化されるのだろうか

>>2
ソースコード上の見かけが同じかどうかではなく、
機械語レベルでやってる事が同じなら同等になるというだけのことですね
結局LLVM optに突っ込んでるだけなので……

境界チェックに関しては自明なものは最適化で消えますし
実装前から心配する部分ではない気がします
自分は計測しながらパフォーマンスに寄与する箇所だけget_uncheckedに置き換える感じでしたね
デフォルトで安全側に倒してある言語なので、まあその辺の調整は必要です

最近名前を聞くようになったので、ドキュメントをちょっとだけ読んだけど、所有権のところでスタックとヒープの話に突っ込んでいったのでそっ閉じした。
所有権が書き込む権利の独占であり、読む権利は誰にもあるという仕様からして、おそらく並行処理のメモリの書き込みロックの問題を言語仕様に取り込んだのだと思う。
確かに、並行処理のミスをコンパイル段階で指摘してくれるのは魅力的だけれど、並行処理を主目的にしない限りは、スタックとかヒープとか考えながらプログラミングしたくない。
そっ閉じした。

安全性に絶対的価値があって、高速性を両立させることが主目的な場合最も有効な選択肢だよね

みんな大好きオライリー本の内容がCやPythonの低レベル階層の知識前提で書かれてて完全に初心者お断り感がスゴイ。それでもamazonのレビュー高評価(.comの方)なのは相応の人だけが読んでるってことか...

オライリー本は程度の差こそあれ基本的に初心者にはちとキツイ内容が多いからなぁ
というかいつの間にかトレイトオブジェクトが&traitからdyn traitになったりimplトレイトが追加されたり初心者へのハードルあげまくるねぇ!

なんか名前がカッコいいからいつかやって見たいとは思っている

Option<T>とResult<T, E>の扱いを丁寧に練習したら、ようやく一歩前進できた気がする。
わかってしまえば単純で、エラーになりうる箇所は手抜きせず場合分けして全パターンの処理書いとけって思想なのね。

新参言語としては有名だと思ってたけど身の回りだと結構知らない人多い
知ってるけど使えない、じゃなくて名前も聞いたことないって人多いんだよね

普通のwebアプリケーション作りたい！みたいなのには向かない言語だからね
省メモリで高性能なアプリをメモリ安全に作りたいみたいなどちらかというとニッチ向け言語

またはミドルウェア向けかな
そういえばlinux開発にRustをとりれたいみたいな話があった
linusもc++の時ほどRustに拒否反応はないっぽい

C++は熟練しても正しいコードを書くことが異常に難しい上に、(だいたいテンプレートのせいで)正しいコードを書く&理解するために言語自体をハックする時間がやたら長いからlinusが嫌うのはよく分かる。
Rustは難しいことは難しいが、それは対象とする概念のややこしさに起因するもので言語自体は割と素直だよね。GNU主義である「取り敢えずCにしとけ」をベターな形でやれるのかなと。

難しいところ主に所有権と借用と参照周りだからね
ユーザーが明確に指定しない限り余計な事をなるべくしないって感じは低レイヤ書く上で良い

生まれてくる時代を40年間違えた言語
1980年代にRustあったら今頃Cは過去の遺産みたいな扱いになってそう

Rustは1980年代以降の関数型プログラミング言語のエッセンスを取り込んでいるのでまぁ多少（の登場の遅さ）はね？

40年前に生まれてたらCと大して変わらずに見向きもされずに終わってそう
今急速にC++のシェアを奪ってるから生まれる時代は正しかった

Adaというものがありまして、ってAda登場が約40年前なのか

時代というか、明らかにRustは近代C++と関数型の土壌があって初めてできた言語だよ。
あとボーランドのTurboシリーズ速くてサイコー！みたいな時代にRustの仕様がマトモに動かせたとは思えない。だってrustcって8MBぐらいあるんだぜw
今はコンパイル速度はそこまで問題じゃないし、LLVMがあるからバックエンドは考えなくていいし、言語の素性が素直に評価しやすくなってるんだけども。

独立非営利団体Rust Foundation発足
https://foundation.rust-lang.org/posts/2021-02-08-hello-world/
設立メンバーはAWS, Huawei, Google, Microsoft, Mozilla
https://aws.amazon.com/jp/blogs/opensource/congratulations-rustaceans-on-the-creation-of-the-rust-foundation/
https://trusted-programming.github.io/2021-02-07/index.html
https://opensource.googleblog.com/2021/02/google-joins-rust-foundation.html
https://cloudblogs.microsoft.com/opensource/2021/02/08/microsoft-joins-rust-foundation/
https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-the-rust-foundation/

Rustで書かれたKubernetesのためのWASM実行環境Krustletとは
https://thinkit.co.jp/article/17560
Deno が Node.js に依存しなくなった
https://qiita.com/kt3k/items/74cb8fef07f9a47e53f7
[忙しい人向け] 100行から始めるWebGPU（WGSL対応版）
https://qiita.com/cx20/items/1f2dcfe0e7ac60fc8ce9
>WGSL は WebGPU Shading Language の略で、その名の通り WebGPU 用のシェーダです。
>GLSL では C言語ライクな構文でしたが WGSL では Rust に似た構文が採用されています。

Rust包囲網が逼ってきている(勉強的な意味で)
Linuxカーネルへの導入が始動したら本気出す！

理論面は80年代の時点でけっこう揃ってるけど（MLやPrologが70年代だし）
ちょうどその頃から始まったオブジェクト指向の隆盛の功罪への反動から生まれた言語だから、登場するならこの10年しかなかったんじゃないかな

cpuの高速化の進化が鈍り言語の速度が比較的重要になった
やっぱ型って大事だね
GCの限界
C/C++のメモリ安全性、未定義動作辛い

あたりの事情だから昔だと出ないんだよね
初期は軽量スレッド用にruntimeある想定だったらしいけどruntimeありだったらここまで流行らなかっただろうなー

Rustの筋の良さって「命令型ベースで関数型のパワーを持つ」ってとこだと思うから、関数型の理論だけじゃダメなんよ。
関数型の何が嬉しいかというとオブジェクトに状態がないことだよね。9割まではそれで幸せなんだけど、
残りの１割に副作用とかI/Oとかの現実では重要な問題が含まれてるという弱点がある。

で、Rustがなぜそのギャップを埋められたかというと、moveの発見によるのではないかと思う。つまりオブジェクトが全部ユニークで所有権を言語レベルで管理できることと、オブジェクトに状態がないことはほとんど一緒なんだと。
moveはスマートポインタの闇の底から出てきたような概念で、これなくしてRustが成立するとは思えないので、やっぱC++11以降の言語ってことになるはず。

>残りの１割に副作用とかI/Oとかの現実では重要な問題が含まれてるという弱点がある。

殆どの非純粋な関数型プログラミング言語はI/Oなどの副作用を普通に行うのだから弱点と言われるとハテナ
純粋な関数型プログラミング言語は副作用と純粋な関数が強制的に分離されているから合成可能性とテスタブルの面で手続き型よりより扱いやすくなっているのだし

>つまりオブジェクトが全部ユニークで所有権を言語レベルで管理できることと、オブジェクトに状態がないことはほとんど一緒なんだと。

よく分からん

>殆どの非純粋な関数型プログラミング言語はI/Oなどの副作用を普通に行うのだから弱点と言われるとハテナ
それは関数型の理論的な部分に非純粋な妥協を持ち込んで解決するという話であって、関数型それ自体で解決しているわけではない。Haskellとかは得るものは確かにあるが、実用として書きやすいかといわれると。

>>つまりオブジェクトが全部ユニークで所有権を言語レベルで管理できることと、オブジェクトに状態がないことはほとんど一緒なんだと。
>よく分からん
手続き型で具体的に何が問題なのかというと、オブジェクトの状態を変更できるやつが複数いるからあるときは正しくあるときは正しくない競合コードを書きがちという点。Rustは記述方式としては手続き的であることを捨てていないが、オーナーシップを強制しているためにそのような競合問題は起こらない。

>>26
>それは関数型の理論的な部分に非純粋な妥協を持ち込んで解決するという話であって
せやね
>Haskellとかは得るものは確かにあるが、実用として書きやすいかといわれると。
そうかな　書きにくいと思うのは普段意識していない事を明示的に書かせるからで（OptionやMaybeと同じ）読みやすさ、テスタブル、保守性などを考えるとモナドベースの副作用の扱いは悪くないと思うが
複数の副作用、Monadが重なった時の問題は確かにあるがそれは別にRustも解決しているわけではないし(モナトラやらeffやら)

所有権と借用は未定義動作とリソース安全性、スレッド安全性に対して有用だがI/Oに対しては特に解決策を提供しているわけではないと思う
(例えばRustはunsafe以外ではnull安全だけどそれはRustのオーナーシップのおかげというよりRustがOptionを持っているからだし)

Rustのクレートって無駄に抽象化されてて型パズルにうんざりすることが多いな
ゼロコスト抽象化なんて実際には存在しないのに

ゼロコスト抽象化はランタイムのコストが（理想的には）ゼロであって
（抽象化によるプログラマが払うコストは）ありますねぇ！

最近rustの財団がトレードマーク周りで某魔剤みたいな事やり始めてて草