Rust part17

**デフォルトの名無しさん** · 2022/10/06(木) 22:43:13.96

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part16

**デフォルトの名無しさん** · 2022/11/09(水) 08:49:14.30

別に操作でもなんでもなく前から人が選んでるって言ってたじゃん。
だからそういうのを過剰反応って言うんだよ。

**デフォルトの名無しさん** · 2022/11/09(水) 09:39:55.00

>>301
ナイーブなやっちゃなぁ
どの国でも底辺ほど極右化しちゃうのは物事が見えてないからなんやな

**デフォルトの名無しさん** · 2022/11/09(水) 09:48:57.31

貧困老人って左傾化してるイメージある

**デフォルトの名無しさん** · 2022/11/09(水) 12:28:40.18

>>302
トレンドはどのように決定されますか？
トレンドはアルゴリズムによって決定され、初期設定では、フォローしているアカウント、興味関心、位置情報をもとにカスタマイズされています。

こういうAI系にRustが使われる可能性ありそうかな？

**デフォルトの名無しさん** · 2022/11/09(水) 12:56:20.73

>>305
コア部分がC++、FortranからRustに変わるとかはありそう

**デフォルトの名無しさん** · 2022/11/09(水) 13:03:43.26

>>304
それもまたナイーブな見方やなぁ
反自民党なら左、親自民党なら右やと思ってるんやろ？

**デフォルトの名無しさん** · 2022/11/09(水) 14:25:41.02

>>306
rustのGPU周りのツールチェインは整備進んでるの？

**デフォルトの名無しさん** · 2022/11/09(水) 19:49:39.97

>>308
GPGPU系は普通に使えそうな感じはしてるけどdeep learning周りはNvidiaが乗り気になるまで無理かもしれないと思えてきた

**デフォルトの名無しさん** · 2022/11/12(土) 21:53:46.90

eguiつよそうだけどみんな興味ないの？

**デフォルトの名無しさん** · 2022/11/13(日) 01:00:16.84

guiはeguiとtauriの2強になりそう

**デフォルトの名無しさん** · 2022/11/13(日) 02:09:24.41

eguiはエグイ

**デフォルトの名無しさん** · 2022/11/13(日) 02:33:53.13

言うほど2強か？
https://www.publickey1.jp/blog/22/electrontauriguitauri-egui_010.html

**デフォルトの名無しさん** · 2022/11/13(日) 21:44:40.30

丸の内線ってマジでいらんよな

**デフォルトの名無しさん** · 2022/11/13(日) 22:06:12.87

脱Electronした純Rust製コードエディタが出ないことには評価し辛いな。

**デフォルトの名無しさん** · 2022/11/13(日) 22:58:55.78

そんなんLapceがあるだろ

**デフォルトの名無しさん** · 2022/11/15(火) 00:12:55.17

Bevyの変更量エグいな。1.0到達まで様子見するわ
https://bevyengine.org/news/bevy-0-9/

**デフォルトの名無しさん** · 2022/11/15(火) 00:20:45.30

米国家安全保障局、CやC＋＋からメモリー安全性の高いJavaなどへの移行を推奨
https://japan.zdnet.com/article/35195997/

ハッカーらによるリモートコード実行（RCE）をはじめとするさまざまな攻撃からコードを保護するために、C＃やGo、Java、Ruby、Swift、Rustといったメモリー安全性の高い言語に移行するよう推奨している。

**デフォルトの名無しさん** · 2022/11/15(火) 00:37:48.72

CやC++で書かれているライブラリに依存するのもやめた方が良いのかね

**デフォルトの名無しさん** · 2022/11/15(火) 01:26:07.72

実績というのは何にも代えがたい証明だからね。
十分に広く長く使われて枯れたライブラリをすぐさま使用停止するほどではないと思う。
長期的には移行せざるを得ないと思うが。

**デフォルトの名無しさん** · 2022/11/15(火) 02:05:15.69

＞プログラマー側での実行に大きく依存している
言語の問題ではなくて、処理系と設計の問題だろうけど
C/C++と同程度の注意力であっても、
比較的楽に安全な実装が可能という話か

**デフォルトの名無しさん** · 2022/11/15(火) 05:58:46.96

RubyはRustの誤植な気がする

**デフォルトの名無しさん** · 2022/11/15(火) 06:20:05.09

Javaもnull非安全クソ言語じゃんぬるぽ

**デフォルトの名無しさん** · 2022/11/15(火) 07:20:48.25

>>322
元の記事でも
The National Security Agency (NSA) is urging developers to shift to memory safe languages – such as C#, Go, Java, Ruby, Rust, and Swift
って書いてあるから誤植とかでは無いと思うがNSAのソースを示してほしいね
https://www.zdnet.com/article/programming-languages-these-top-four-rule-and-developers-are-happy-for-now/

**デフォルトの名無しさん** · 2022/11/15(火) 08:46:43.91

メモリ安全という意味ではRubyは条件満たしてはいるのでは
Pythonがないのは気になるが

**デフォルトの名無しさん** · 2022/11/15(火) 08:47:01.64

ソース
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

**デフォルトの名無しさん** · 2022/11/15(火) 09:09:11.17

人工衛星イザナミ・イザナギでも、mruby を使っている

C はポインターでバグるから、
文字列処理などはポインターを使わない、安全なmrubyが良い

それで、mrubyから、Cのライブラリを呼び出せば安全

**デフォルトの名無しさん** · 2022/11/15(火) 11:32:13.77

文字列処理でポインタを使わないってどうやんの？

**デフォルトの名無しさん** · 2022/11/15(火) 11:45:11.75

陽に使わないって事だろ

**デフォルトの名無しさん** · 2022/11/15(火) 12:05:46.25

言わんとすることは分かるけど人工衛星と文字列処理はあんまり関係なさそう

**デフォルトの名無しさん** · 2022/11/15(火) 12:16:51.72

>>326
これからメモリーセーフな言語が沢山出てきそうだな

**デフォルトの名無しさん** · 2022/11/15(火) 12:57:18.27

メモリセーフかつGC無しの言語ってRust以外に増える気配ないよな
需要あるのに

**デフォルトの名無しさん** · 2022/11/15(火) 13:11:29.50

C++ は安全な言語に混ぜてもらえなかったんだな。
C++はCに寄せられてしまったのかと。

**デフォルトの名無しさん** · 2022/11/15(火) 13:50:50.90

「生ポインタを使わずスマートポインタを使う」
「オブジェクトのコピーはすべてムーブを使う」
を徹底すればそこまで危険ではないんだけどね

**デフォルトの名無しさん** · 2022/11/15(火) 13:53:08.34

>>333
まあやろうと思えばCと同じことができちゃうからね

**デフォルトの名無しさん** · 2022/11/15(火) 14:25:30.22

>>334
知っててもクソみたいな誤りをするのが人だからな。

**デフォルトの名無しさん** · 2022/11/15(火) 15:49:10.51

Google Chromeのバグの7割がメモリ安全関連というし、
C++で安全性を保ちつつ大規模複雑なアプリケーションを作るのは難しいのでは

**デフォルトの名無しさん** · 2022/11/15(火) 16:00:29.49

そりゃ「〇〇するよう気をつければ良い」が通るんならそもそもバグらないよう気をつけられるはずだしな
人間が気をつけるのと機械的にチェックできることの間には大きな差がある

**デフォルトの名無しさん** · 2022/11/15(火) 21:18:52.91

>「オブジェクトのコピーはすべてムーブを使う」

微妙に意味が分からん

**デフォルトの名無しさん** · 2022/11/16(水) 03:16:38.83

>>339
クラスにムーブコンストラクタとムーブ代入演算子を必ず実装して
それが呼び出されように書くということね
ゼロから書く場合は可能
つまりRustっぽく書く
しかし外部ライブラリを使う場合は破綻するので無理なのだが

**デフォルトの名無しさん** · 2022/11/16(水) 07:33:54.12

F#をトライしていたのですが、VSは重いし、VScodeは動かすことができず
Sublimeは何とか動くが、ライブラリをうまくアクセスできず図を出力できず
コマンドラインでの実行もバージョンが古いせいかこれもライブラリにアクセスできず
で、似ているというRUSTをテストしてみました

インストールも簡単、クレートの設定も簡単
コンソールでコンパイル、実行も簡単
webにあるサンプルをテスト、５つほどwarningがでていましたが図を出力できました
F#では実行環境を作るのに四苦八苦しましたが、RUSTはあっというま
感激してここにアップしました
今から勉強します

**デフォルトの名無しさん** · 2022/11/16(水) 07:35:45.01

「コピーは使わないでムーブする」なら意味が通じたが

**デフォルトの名無しさん** · 2022/11/16(水) 12:12:43.09

>>342
そのつもりで書いてた。
推敲不足だったな。回線ケーブルで首釣るかもしれん。

**デフォルトの名無しさん** · 2022/11/16(水) 18:02:22.96

一部のアスペ以外はそれぐらいの推論はできるからあまり気にしなくていいよ

**デフォルトの名無しさん** · 2022/11/16(水) 18:02:43.41

そういうのは吊るを使う

**デフォルトの名無しさん** · 2022/11/16(水) 18:29:22.77

>>343
お前は誰だよw
俺を語ってんじゃねー

**デフォルトの名無しさん** · 2022/11/16(水) 20:20:41.18

.netでrustが使えれば無敵なのに

**デフォルトの名無しさん** · 2022/11/16(水) 21:13:44.67

GCのランタイム環境でRUSTは意味ないんじゃ？

**デフォルトの名無しさん** · 2022/11/16(水) 21:37:10.96

ML 系言語が Rust を高水準にした感じじゃない？
(というか ML の研究からリージョン推論が生まれて Rust に繋がっていったのだが……。)
.NET 用だと F# があるから使ってみても面白いかもね。

**デフォルトの名無しさん** · 2022/11/16(水) 21:59:45.42

.NETのライブラリが使いたいとかでは

**デフォルトの名無しさん** · 2022/11/17(木) 00:08:08.45

rust難しすぎません？
僕はまだまだ、たぶん無理だけど、そこそこできるようになったとしても、全体の底上げがなければ普及が難しいのではという自己弁護

**デフォルトの名無しさん** · 2022/11/17(木) 00:34:44.66

既存のC/C++のコードをRustに書き直すのは
頑張らなくても良いですと言われていても
世界に一人ぐらい頑張る人がいて
再実装しましたみたいなのが時々出てくるな

**デフォルトの名無しさん** · 2022/11/17(木) 00:48:28.80

C++ 何となく使っているけど、Rust って難しいの？
C++ より難しいなら、先に勉強しようかな

**デフォルトの名無しさん** · 2022/11/17(木) 01:00:11.07

>>353 とりあえず動かすのはRustのが難しい
正しく動かすのはC++のが難しい

**デフォルトの名無しさん** · 2022/11/17(木) 01:28:33.22

C++ は未定義を踏むのがさすがに簡単すぎるのがいけない。

**デフォルトの名無しさん** · 2022/11/17(木) 01:54:53.99

>>340
これを徹底すればC++も問題ないよ

**デフォルトの名無しさん** · 2022/11/17(木) 03:15:48.27

>>354
Rustは安全性と処理効率を保ったままさらに高みに登ろうとすると、C++では
可能だったことが不可能なことがある。

**デフォルトの名無しさん** · 2022/11/17(木) 05:38:42.23

>>356
徹底するのが難しい、って話だろ

**デフォルトの名無しさん** · 2022/11/17(木) 05:39:00.42

>>356
「〇〇を徹底します」みたいな精神論が再発防止にならないのは業界の常識

**デフォルトの名無しさん** · 2022/11/17(木) 05:39:30.88

>>357
具体的にはどういうケース？

**デフォルトの名無しさん** · 2022/11/17(木) 07:38:31.41

>>360
大規模なマルチスレッドとかじゃない？
それこそ「共有メモリは排他制御を徹底すべし」ってだけの話だけど
数百万行のコードベース全体に対して常時気をつけ続けるというのは人間には無理だろう

**デフォルトの名無しさん** · 2022/11/17(木) 07:44:38.30

>>361 マルチスレッドこそRustの得意分野だと思うんだけど

**デフォルトの名無しさん** · 2022/11/17(木) 07:48:15.39

rustは所有権とかライフタイムとかなければ簡単で使いやすそうって印象

**デフォルトの名無しさん** · 2022/11/17(木) 07:53:43.04

所有権やライフタイムがいらないならrustである必要ないのでは

**デフォルトの名無しさん** · 2022/11/17(木) 08:37:34.35

>>362
あ、逆の話か
C++だと不可能なことがRustだと可能になるって読んでた
357のは思いつかんね

**デフォルトの名無しさん** · 2022/11/17(木) 08:42:54.13

複雑なマルチスレッドのアプリで俺にしか直せないバグを故意に仕込むことならC++でしかできないかな

**デフォルトの名無しさん** · 2022/11/17(木) 09:56:45.90

>>364
プログラマが全知全能でメモリ関係のバグを踏まないって仮定したら所有権やライフタイムがなくてもrustはc++以上の優れた型システムを持ってる

**デフォルトの名無しさん** · 2022/11/17(木) 10:21:30.69

>>367
Haskellの方が優れてるよ

**デフォルトの名無しさん** · 2022/11/18(金) 17:50:50.73

米GitHubは11月18日までに、2022年にGitHub上で多く使用されたプログラミング言語ランキングを発表した。

その結果、1位は「JavaScript」だった。以降、2位「Python」、3位「Java」、4位「Typescript」、5位「C#」、
6位「C++」、7位「PHP」、8位「Shell」、9位「C」、10位「Ruby」と続いた。

Rubyに負けたらいけないだろｗ

**デフォルトの名無しさん** · 2022/11/18(金) 17:57:22.15

企業の人ってGitHub使えるのかな?
企業が使い始めたら増えると思うけど。

**デフォルトの名無しさん** · 2022/11/18(金) 18:25:40.22

真の意味でホビーユーザーに支持されなきゃだめだよ

**デフォルトの名無しさん** · 2022/11/18(金) 18:31:52.75

ゆきひろにより開発されたオブジェクト指向スクリプト言語か

**デフォルトの名無しさん** · 2022/11/18(金) 18:55:51.18

このグラフ、Typescriptの躍進とRubyの凋落が対照的で興味深かった。

**デフォルトの名無しさん** · 2022/11/18(金) 19:00:57.54

これか
https://i.imgur.com/QE0WMb7.jpg

**デフォルトの名無しさん** · 2022/11/18(金) 21:08:51.27

C/C++の減少分がRustじゃね

**デフォルトの名無しさん** · 2022/11/18(金) 21:48:16.28

その説が正しい使い方気がした

**デフォルトの名無しさん** · 2022/11/19(土) 00:42:59.64

>>360
効率よくリンクリストやグラフ構造を使うこと。
この(前?)スレで散々議論されていた。

**デフォルトの名無しさん** · 2022/11/19(土) 00:49:11.67

いい加減スレ違いはやめろって

**デフォルトの名無しさん** · 2022/11/19(土) 04:53:18.01

>>377
全然具体的でなくて草
そりゃ散々議論（のつもりw）になるわ
コードで示すとか出来ないの？

**デフォルトの名無しさん** · 2022/11/19(土) 09:49:20.36

tscがRustだと書き直すのが難しいとか聞いたが

**デフォルトの名無しさん** · 2022/11/19(土) 10:48:30.65

>>380
tscをRustに一部移植
元のコードがGC前提だから全体の移植は大変なのでGoに変更
GoはGoで無駄な作業が多くて大変。やっぱりRustのほうが良かったのでRustに戻す

というのが今の状況
来年あたりまたGoに戻ってる可能性はあるが

**デフォルトの名無しさん** · 2022/11/19(土) 14:18:44.14

>>381
移植とか考えずに仕様だけ洗い出してからRustで実装するのがベストでしょうね
仕様解析チーム(tscを読み込んでドキュメント化する)
とRust実装チーム(Rustのエキスパートたち)
この2チームがいれば十分だし

**デフォルトの名無しさん** · 2022/11/19(土) 20:51:33.06

Rustで実装が難しいようなアルゴリズムは不安全で時代遅れだ説

**デフォルトの名無しさん** · 2022/11/19(土) 20:55:58.15

解析してる間にどんどんtscの仕様は変わっていくよ

**デフォルトの名無しさん** · 2022/11/19(土) 21:07:54.54

Rustってお互いに参照し合うようなグラフ構造を表現しにくいイメージある

**デフォルトの名無しさん** · 2022/11/19(土) 22:17:39.01

し難いのか不可能なのかどっちよ

**デフォルトの名無しさん** · 2022/11/19(土) 22:23:36.77

rustcでグラフ構造扱ってるよ
ポインタではなくインデックスでアクセする実装

**デフォルトの名無しさん** · 2022/11/19(土) 22:41:12.16

>>387
なるほどなあ

**デフォルトの名無しさん** · 2022/11/19(土) 23:28:51.73

>>387
前スレ読んでもわかるが、それでやれば出来るのは分かってるんだけど、
効率が落ちるから「ゼロコスト安全性」ではない。

**デフォルトの名無しさん** · 2022/11/19(土) 23:29:54.28

>>383
リンク構造を持つデータ構造は今も発展途上中で今後も開発されていくが、
Rustでは取り扱いにくく、むしろRustこそ時代遅れ。

**デフォルトの名無しさん** · 2022/11/19(土) 23:31:24.06

ポインタが理解できない人は、ポインタが中心に居るところのリンク構造を全て
無視するから、Rustの欠点が理解できないだけ。

**デフォルトの名無しさん** · 2022/11/19(土) 23:32:17.52

>>386
しにくいだけ
>>1のHow to not learn RustとかオライリーのProgramming Rustでも指摘されてたはず

**デフォルトの名無しさん** · 2022/11/19(土) 23:44:21.19

>>386
不可能ではないが、C言語のように参照やポインタでダイレクトに取り扱うのが
不可能なので、インデックスを介してアクセスした、非常に複雑な仕組みで
アクセスしたりする必要があり、効率が落ちる。
マシン語レベルで見ると、アクセスすすために必要なコードが増えるから。

**デフォルトの名無しさん** · 2022/11/19(土) 23:44:57.71

誤：インデックスを介してアクセスした、非常に複雑な仕組みで
正：インデックスを介してアクセスしたり、あるいは、非常に複雑な仕組みで

**デフォルトの名無しさん** · 2022/11/20(日) 00:54:20.94

窮屈だからとか言って車に乗るときにシートベルトを付けないタイプの人かな

**デフォルトの名無しさん** · 2022/11/20(日) 01:12:16.21

見かけ上はインデックスアクセスでも最適化がかかると途中のアドレス計算はほとんど消滅してポインタでやるのとそんなに差はなくなるよ。
ポインタを露骨に使うのはコンパイラ技術の未熟さをプログラマに補わせてただけ。
十分に高い能力のコンパイラにとってはプログラマが細々とした効率のための指示をするのはむしろ最適化の邪魔になる。

全体の構成やアルゴリズムの話ならともかく、細々とした部分はコンパイラのほうが人間よりよっぽど賢いんやぞ。

**デフォルトの名無しさん** · 2022/11/20(日) 01:28:00.24

ahoの「アルゴリズムの設計と解析」という古い本で木構造をインデックスアクセスで実装していたけど
rustにふさわしい実装だったんだな
この本はポインタがない言語を想定していたのだろうけど

**デフォルトの名無しさん** · 2022/11/20(日) 01:29:41.16

ポインタで書いた方が速いじゃんて事は現にあったし
昔だと、それでも遅いからってアセンブリ言語で関数書いて呼んだりしたが
今なら、そこまでやらなくてもいいだろう
これは、コンパイラの進化もあるだろうが、CPUの進化の恩恵が大きい

**デフォルトの名無しさん** · 2022/11/20(日) 01:32:00.55

脱ポインタの流れは変わらないと思うけどね
安全性とは程遠いからこれを無くさない限り絶対にメモリ安全性は守られない

**デフォルトの名無しさん** · 2022/11/20(日) 09:27:21.62

unsafeつかえばいいじゃん

**デフォルトの名無しさん** · 2022/11/20(日) 13:59:12.71

>>396
インデックスを使おうとすると、1つのオブジェクトを作成する際にヒープから確保できず、
同じ集約(コンテナ)に属する全オブジェクトが入っている配列をreallocするような
動作が必要となり、スプリアス的に「停止時間」が入る。
また、その際キャッシュが大規模クリアされてしまう。

**デフォルトの名無しさん** · 2022/11/20(日) 14:00:19.95

>>400
前スレ(?)で、それでは済まないことが指摘済み。