Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

公式
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 part9
https://mevius.5ch.net/test/read.cgi/tech/1598112455/

**デフォルトの名無しさん** · 2021/05/31(月) 21:37:16.00

いやそこでソフトで頑張ってもほぼダメだろ。。アーキテクチャで分散化考えないとって話じゃないかね

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/01(火) 01:05:37.48

>>788
ハードウェアがもう伸びないってことではなくて、 CPU の速度が単純に速くなるという方向ではもう伸びにくいって話。
電子の大きさは変えられないから際限なく微細化できるわけではない。

わかりやすい例で言えば今のパソコンはマルチコアが当たり前になってて複数の CPU を載せる方向で性能を上げているが、
マルチコアを想定してないソフトをマルチコアパソコンで動かしてもひとつのコアしか使わないので性能が出ない。
高価な GPU を乗せても GPU を使うプログラムになってなきゃ意味がない。

ハードウェアの総合的な性能を上げるには色んな工夫があり得て、それらを実現すると同時に
ソフトウェアは「ハードウェアに合わせて」「ハードウェアの性能を引き出すように」工夫がいる。

これは今までにも普通にやってたことで、今になって必要になったわけじゃない。
小さな変化の積み重ねなこともあれば大きな変革を迫られることもあるってだけ。

**デフォルトの名無しさん** · 2021/06/01(火) 07:44:50.11

後藤弘茂のWeekly海外ニュース■ Prescott/Tejasは5GHz台、65nmのNehalemは10GHz以上に
ttps://pc.watch.impress.co.jp/docs/2003/0227/kaigai01.htm
当時は景気よかったっすね。すぐ後に爆熱で日和ったけど
そして今、300Wの時代・・・

てか並列化によるスループットの向上はこのあたりから検討されるようになっていた気が

**デフォルトの名無しさん** · 2021/06/01(火) 19:29:09.48

>>784 でも何故かcargoだけはcargo install cargo --forceとすれば自分でコンパイルしたもので上書きができる謎

**デフォルトの名無しさん** · 2021/06/04(金) 15:33:30.83

よくわからないんだけどこれ、C言語のポインタ渡しが諸悪の根源で、そこを断ちさえすればC言語も所有権概念を取り入れられるの？

**デフォルトの名無しさん** · 2021/06/04(金) 15:42:09.57

>>793
C言語において、ポインタは大発明で、それによってリンクリストやツリー構造
が簡単に実装に出来る様になった、大変重要なもの。
C言語からポインタを絶てば何も残らない。

**デフォルトの名無しさん** · 2021/06/04(金) 15:48:43.92

Javaキチガイはポインタ使いこなせない
日本のMSの社員がソレだった
破棄忘れてやんのw

**デフォルトの名無しさん** · 2021/06/04(金) 15:55:06.60

RAIIなしで良いなら多少の拡張で所有権の概念取り込めるかも知れないけど
絶対スマートポインタ欲しくなるしCの表現力だと使いづらい物になりそうな気がする

**デフォルトの名無しさん** · 2021/06/04(金) 16:03:03.62

>>794
>C言語において、ポインタは大発明
笑笑

**デフォルトの名無しさん** · 2021/06/04(金) 17:24:32.39

Cと比較するのは流石に乱暴だろ
C++と比較するべき
で、C++でできなくてRustでできるものというのは現状存在しない (今後その差も埋まっていくだろうが)

C++とRustの違いはひとえにスタンスの違いだよ
自由奔放なC++か良いコードにカッチリ導いてくれるRustか
意欲的に新機能取り込んで発展してるのは両者とも同じ

**デフォルトの名無しさん** · 2021/06/04(金) 17:31:18.17

>>798
>C++でできなくてRustでできるものというのは現状存在しない
こういう比べ方はアホ
チューリング完全ならなんでもできるじゃんみたいなことになる
できるできないの線引きが恣意的

**デフォルトの名無しさん** · 2021/06/04(金) 17:54:18.33

>>799
バカアホじゃなくて、Rustでしかできないものの例を挙げてください
そうすれば一単語で反論の余地なく終わるんで

**デフォルトの名無しさん** · 2021/06/04(金) 17:58:01.49

C++は奇麗に描くと言うのが出来ない

**デフォルトの名無しさん** · 2021/06/04(金) 18:03:48.84

>>800
C++でできなくてRustでできるもの
から
Rustでしかできないもの
への華麗な転身www

**デフォルトの名無しさん** · 2021/06/04(金) 18:16:57.72

C++はMemory Safetyをコンパイル時に担保できない
Rustを使う一番の動機

**デフォルトの名無しさん** · 2021/06/04(金) 18:53:59.58

>>802 C++とRustの比較において｢C++でできなくてRustでできるもの｣と｢Rustでしかできないもの｣は同じ意味だから転身でもなんでもない
https://i.imgur.com/3svkdus.png

**デフォルトの名無しさん** · 2021/06/04(金) 19:11:16.95

Cloudflareの画像処理責任者を名乗る人も、これ以上C++ライブラリを増やすのはイヤでござると発言してるな

**デフォルトの名無しさん** · 2021/06/04(金) 19:23:30.63

>>804
C++とRust以外にも言語はたくさんある

**デフォルトの名無しさん** · 2021/06/04(金) 19:29:23.53

Rustのモジュール（ファイル分割）の仕組みはC++のヘッダー＋ソース（＋名前空間）より扱いやすいと思う
C++は分割コンパイルが主流だった歴史的経緯があるから仕方ないけど事前の宣言が必要なのは地味に面倒くさい

**デフォルトの名無しさん** · 2021/06/04(金) 19:43:15.38

>>806 この会話の流れではC++とRustの比較をしていたから

**デフォルトの名無しさん** · 2021/06/04(金) 19:58:10.76

ライフタイムによるメモリ管理はRustオンリーだろ

**デフォルトの名無しさん** · 2021/06/04(金) 20:12:39.71

マイナーな環境だとC++プログラムは様々な理由でコンパイルが通らないことがよくある
Rustは基本的にはそういう事ないし、コンパイラ実装が一つしかないというのも利点に働く

**デフォルトの名無しさん** · 2021/06/04(金) 20:40:42.82

C++との比較を議論したいなら専用の隔離スレでどうぞ

**デフォルトの名無しさん** · 2021/06/04(金) 22:02:04.46

>>793は言語レベルのサポートがほしいんだろ？
substructural type systemがないと無理。

>>809
MLkit,RTSJ,cyclone,ATS/ATS2。学術的にはとっくの昔に廃れたぞ。

**デフォルトの名無しさん** · 2021/06/04(金) 22:04:58.58

WinUIとRustやってる人いる？
同じネイティブのMFCとかと比べて、やっぱり生産性は高いんかな

**デフォルトの名無しさん** · 2021/06/04(金) 22:26:52.09

メモリ関連って原因不明のバグ引き起こしやすいしトータルな目で見れば上がるんじゃないだろうか

**デフォルトの名無しさん** · 2021/06/04(金) 23:27:29.47

>>810
gcc-rsとかのプロジェクト始まってるけどそれはネガティブなことなのかね

**デフォルトの名無しさん** · 2021/06/05(土) 06:04:54.16

>>810
そういえば、C++のSTLは、VSでは動くが、BSD系のLLVM用のlibc++は、
なかなか上手く動いてくれない。理由は、libc++が、その
基礎関数として滅多に使われないようなMB・WC文字変換関連や、
NAN、INFINITYなどのfloat/double調査関数など、昔ながらのC環境では
定義されて無いような(新しい)Cの関数を大量に必要としているため。
その意味で、WasmのWASIなんかは、たとえCUIだけであっても
世界共通の関数群を整備してくれるのだとしたら有りがたいかも知れない。
でもWASI自体の移植作業が必要になるから一緒か。

**デフォルトの名無しさん** · 2021/06/05(土) 06:14:19.54

>>816
昔からCには文字種判別として、isalphaやisdigitなどがあるが、
libc++は、isalpha_l()などのlocale指定タイプを必要としていたりして
locale関連がやたらと複雑。また、その
isalpha_lなどを基礎にしてくれているならまだしも、isalpha_lが内部で使っている
文字種テーブル unsigned short _ctype[256]; も仮定していたりする。
このテーブルは、_CONTROL、_SPACE、_DIGIT、_ALPHAなどの
BIT定数とandを取ってBITが立っているかどうかで文字種を判定する。
それは環境依存なのだが、高速化のためか何故かそれを必要としている。
(C++のライブラリが欲しいのに、そのライブラリが、なぜか一般的ではない
大量のC関数や特殊なデータテーブルを必要としてしまっている。)
だから移植が進まない。
plain Cは、標準ライブラリが多くの環境である程度の互換性を持って整備されているが、
結果的にC++のSTLはなかなかそうではないようだ。

**デフォルトの名無しさん** · 2021/06/05(土) 06:17:47.83

C++ライブラリがisalpha_lなどを用いてしまったら、速度面でC#やJavaなど
に比べた優位性が少なくなってしまうからかも知れない。
つまり高速化のためにやたらと移植性の低い方法を使っているから、
スムーズに移植が進まない。
それか単純にC++ライブラリを作る人の技術力が低いからだろうか？

**デフォルトの名無しさん** · 2021/06/05(土) 06:20:08.28

>>801
すまんが、Rustはもっと出来ない気がする。

**デフォルトの名無しさん** · 2021/06/05(土) 09:02:04.60

RustスレでC++の話題が出てしまうのはもはや運命なのか

**デフォルトの名無しさん** · 2021/06/05(土) 09:20:03.77

>>820
そりゃ better C++言語として作られたんだから当たり前でしょう

**デフォルトの名無しさん** · 2021/06/05(土) 09:32:35.80

ライフラインの書き方がとにかく見づらい

**デフォルトの名無しさん** · 2021/06/05(土) 09:45:07.09

これヤバくない？
どうやって防いだらいいんだろう？

https://github.com/lucky/bad_actor_poc

**デフォルトの名無しさん** · 2021/06/05(土) 09:46:58.65

localhostに送るだけならいくないん？

**デフォルトの名無しさん** · 2021/06/05(土) 09:53:33.78

え、マジで言ってるの？

**デフォルトの名無しさん** · 2021/06/05(土) 10:04:24.16

あおられてもダメな理由がわかりまそん
びっくりはするけど

**デフォルトの名無しさん** · 2021/06/05(土) 11:21:46.59

悪意を持ったコードをビルドしない

**デフォルトの名無しさん** · 2021/06/05(土) 12:04:01.08

c++との比較はガファムが結論出してくれたからもう話すことなどない

**デフォルトの名無しさん** · 2021/06/05(土) 12:08:54.56

何をみて結論だと思ってんだか。短絡的だな。

**デフォルトの名無しさん** · 2021/06/05(土) 12:26:06.61

依存するクレートの依存するクレートの依存するクレートの以下無限ループまで全部チェックしないと駄目ー？(´・ω・｀)

**デフォルトの名無しさん** · 2021/06/05(土) 12:58:14.11

チェックするツールとか誰か作っていそうだね
バイナリを診断するよりは簡単だろうし

**デフォルトの名無しさん** · 2021/06/05(土) 13:57:18.40

>>826
念のためマジレスすると公開した人がいつでもlocalhostを〇国サーバーのアドレスに書き換えられるってこと
githubのオープンソースでそれやったらすぐにばれそうだけど

ビルド時ならともかくエディタ起動直後のコード解析でデータが送信されるのは盲点やね

**デフォルトの名無しさん** · 2021/06/05(土) 14:01:47.49

ビルドしなくてもファイルを開いたらコードが実行されるというのはよろしくないね

ファイルやネットワークならアクセスされる側でブロック可能だけど
メモリはサンドボックス内のみで展開・実行されるようにしないとブロックできない気がする

サンドボックス化できなければ
cargo auditやcargo crevを通して怪しいcrateだけ自分でチェックするとかかな

**デフォルトの名無しさん** · 2021/06/05(土) 14:06:05.14

vscodeやlspヤバイな

**デフォルトの名無しさん** · 2021/06/05(土) 14:13:31.58

解決方： vscode を使わない

**デフォルトの名無しさん** · 2021/06/05(土) 14:27:34.92

まったくだ

**デフォルトの名無しさん** · 2021/06/05(土) 14:48:29.61

見た感じVSCode以外でもマクロが実行されるようなことをすると駄目っぽいが

**デフォルトの名無しさん** · 2021/06/05(土) 14:52:35.33

MS自身がやりたい放題だからメンタルも伝播するだろうな

**デフォルトの名無しさん** · 2021/06/05(土) 15:03:58.08

>>835
それrust使わなけりゃでも良くね？

**デフォルトの名無しさん** · 2021/06/05(土) 15:09:20.73

そもそもこれ本質はライブラリの信頼性って問題だと思うんだよな
Rustだけじゃなく他の言語にも言える話

**デフォルトの名無しさん** · 2021/06/05(土) 15:22:11.73

お得意の静的チェックでなんとかしたら？

**デフォルトの名無しさん** · 2021/06/05(土) 15:29:47.09

中国のipアドレスは全部ブロックしておくのが正解だな

**デフォルトの名無しさん** · 2021/06/05(土) 15:51:07.65

IntelliJ/CLion でもproc_macro実行されちゃうの？

**デフォルトの名無しさん** · 2021/06/05(土) 16:11:56.77

LSPはクソ
vscodeありきの思想

**デフォルトの名無しさん** · 2021/06/05(土) 16:32:08.49

LSPってHSPの親戚ですか？

**デフォルトの名無しさん** · 2021/06/05(土) 16:43:48.73

long short play モードだよ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/05(土) 16:56:48.31

>>844
LSP はエディタとの連携を前提として明文化された規格にしたってだけで、
処理系にコンパイルさせた結果をエディタの表示に反映させるというのは昔から有ったんだぞ。

**デフォルトの名無しさん** · 2021/06/05(土) 17:38:04.49

>>847
> 処理系にコンパイルさせた結果をエディタの表示に反映させるというのは昔から有ったんだぞ。

いやそりゃそうだろ
その説明じゃ flycheck 等と差がない

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/05(土) 18:00:21.39

>>848
Rust のコードをビルドしないときでもエディタ経由で勝手にビルドする
(そのときに悪意のあるコードも走らせられるかもしれない)
という文脈の中で >>844 の発言があったので、
それは LSP が作られる前から同じような危険性はあっただろうという反論を私はしたつもり。

LSP のせいじゃなくてコンパイル時に出来ることが多い Rust のせいって話。

**デフォルトの名無しさん** · 2021/06/05(土) 18:09:21.84

はあ話になんね
こいつといいQZといい「何か物申したい」という気持ちだけで生きてるから常に空回ってんだよな

**デフォルトの名無しさん** · 2021/06/05(土) 18:52:13.97

proc-macroがwasm化されてサンドボックスで動くようになればマシになるのかね
そもそも怪しいコードが依存関係に混入しちゃう時点でcargo runなりtestなりしたらなにされるかわからん訳でproc-macroの件自体にどれくらいの影響度があるのかは分からんが

**デフォルトの名無しさん** · 2021/06/05(土) 19:44:30.63

crossでx86_64-unknown-linux-gnuをtargetにクロスコンパイルしたらいいんじゃないか?
あれ確かDockerで動いてたはず

**デフォルトの名無しさん** · 2021/06/05(土) 19:45:33.78

自分のPC向けにクロスコンパイル用ツールを使ってコンパイルするのがクロスコンパイルというかどうかは知らんけど

**デフォルトの名無しさん** · 2021/06/06(日) 08:03:37.51

>>823
特定のエディターの問題ではなく
特定のプログラミング言語の問題ではなく
自分が意図していない自動マクロ(プラグイン)を使えば自分が意図していない動作をするだけの話
大昔からあらゆる環境で起きていること

**デフォルトの名無しさん** · 2021/06/06(日) 09:39:11.50

コーディング時、ビルド時になんでもやらせようって発想が間違ってんだよ。

**デフォルトの名無しさん** · 2021/06/06(日) 10:03:07.57

マクロはやっぱ悪よな、無いと辛みが増すから仕方ないじゃなくて無くても何とか出来る仕様にすべき

**デフォルトの名無しさん** · 2021/06/06(日) 10:25:40.41

今回の>>823の問題に限っていえば
そもそもLSPを使う人のためのプラグインなのだからLSPのlocalhost:8080に接続に行くことは何の問題もないよね
問題としているのはSSHの秘密鍵をそこへ自動送付していること
LSPそこまで詳しくないのだけどそれはどうしても必要なことなの？

**デフォルトの名無しさん** · 2021/06/06(日) 10:32:40.20

LSPは、この騒動(？)と関係なくクソ

**デフォルトの名無しさん** · 2021/06/06(日) 10:33:23.63

快適なエディタと快適なIDEの区別がつかなくなったバカどもがゴリ押しで流行らせてる

**デフォルトの名無しさん** · 2021/06/06(日) 11:08:51.30

>>857
>LSPのlocalhost:8080に接続に行くことは何の問題もないよね

localhost:8080はLanguage Serverじゃないよ

**デフォルトの名無しさん** · 2021/06/06(日) 11:16:22.93

>>860
それはすまなんだ
じゃあ何が問題になってるのかな

**デフォルトの名無しさん** · 2021/06/06(日) 12:13:20.98

>>861
LSPをセットアップした状態だと「VSCodeを起動しただけで」自動ビルドが走ってしまって悪意あるprocedural macroが実行されてしまうこと
手動でビルドすれば同じことになるのでそこは問題の本質じゃなくね？とは思う

**デフォルトの名無しさん** · 2021/06/06(日) 12:48:13.98

LSPというよりrust-analyzerやrls、cargo/rustcの問題と言った方が正確かな

**デフォルトの名無しさん** · 2021/06/06(日) 14:24:19.60

では>>823で指摘されている問題点「自分のSSHの秘密鍵が勝手に読み出されて送信される」はどの部分がその動作を要求しているの？
本当に必要な動作なの？

**デフォルトの名無しさん** · 2021/06/06(日) 14:29:37.79

手続きマクロの展開なのでcargo checkでも起こり得る
言ってしまえばRustの言語仕様そのもの
解決策は>>851の言うようにサンドボックス化するみたいな方法しかなさそう

**デフォルトの名無しさん** · 2021/06/06(日) 14:35:16.58

>>861
macroをexpandする時に
macroの定義に書かれてる任意のコードを実行することができるって話

任意のコードの例としてSSHのキーをサーバーに送信する例が書かれてて
試す人に無害なように送信先サーバーはlocalhostになってるだけ

コード見たほうが早いかも
make_answer!がexpandされるときにread_ssh_keyが実行される
https://github.com/lucky/bad_actor_poc/blob/master/bad_actor/src/lib.rs

**デフォルトの名無しさん** · 2021/06/06(日) 14:40:17.63

このコード例はめちゃくちゃわかりやすい。問題は置いといてgoodなコードだ。

**デフォルトの名無しさん** · 2021/06/06(日) 15:22:49.77

crate-typeがproc-macroのときはffiを禁止して使用可能なextern crateを
安全性が保証されたものだけに制限するのがRustっぽいかな
proc-macro専用のstdが必要になるけどno_stdと同じ感覚でmacro_safe属性をつければいい

**デフォルトの名無しさん** · 2021/06/06(日) 16:06:34.14

そもそも普通はproc-macroなんか必要ないだろ
特殊用途以外では一律禁止してよいのでは？

**デフォルトの名無しさん** · 2021/06/06(日) 16:20:07.52

derive が使えなくなるのは結構困る

**デフォルトの名無しさん** · 2021/06/06(日) 23:45:39.31

>>843
マクロ展開すればどんな環境でもできるよ。
>>823はmulti-root workspaceの構成間違ってるから
IntelliJRustだとマクロ展開されないけど。

>>869
custom derive全部禁止だから当然thiserrorもserdeもdelegation系も禁止な。
ボイラープレート全部手書きしろよ。

**デフォルトの名無しさん** · 2021/06/07(月) 06:02:10.08

頭悪い奴らばかりで議論にならぬ
趣旨と仕組みはreadme書いてあるのに。。

**デフォルトの名無しさん** · 2021/06/07(月) 13:37:53.63

今勉強中なんだけど、Rustと合わせた時のgdbの使い方を教えてくれんかな
行指定でb main.rs:10みたいにブレイクポイントを指定するのってどうやるの？
＞No source file named main.rs.
みたいに言われてしまって、どうやって行指定でブレイクポイントを設定するのかよくわからん
ソースのあるディレクトリがわからないのかと思って指定しても結果は変わらず・・・・
あと、ソースを表示しながらステップ実行したりってどうやるの？

**デフォルトの名無しさん** · 2021/06/07(月) 13:52:39.17

vscodeでcodelldb使おう

**デフォルトの名無しさん** · 2021/06/07(月) 14:06:08.51

ああ、デフォルトで-gつかないのか・・・・
でもlldbが主流っぽいし、それ使うかな

**デフォルトの名無しさん** · 2021/06/07(月) 14:34:12.65

macのgdbだと今はまともに動かんぞ。

**デフォルトの名無しさん** · 2021/06/07(月) 14:45:09.07

M1になってmacの開発環境死んだ

**デフォルトの名無しさん** · 2021/06/07(月) 15:56:52.66

iPhone開発でMac必須になったことで強気に出すぎたか。
Macは滅びると思っていたらx86系になってからなぜかしぶとく生き残ってきたけど、
もうだめかもな。

**デフォルトの名無しさん** · 2021/06/07(月) 16:08:45.47

lldbを試しに使ってみてるんだけどさ
これって、ステップ実行するたびに自動で毎回「memory read --size 8 --format x $sp」をやってもらうことってできないの？
gdb-pedaを使っていたときはスタックの中身が自動で見れてたんだけど、なんか似たようなのないのかな？

**デフォルトの名無しさん** · 2021/06/07(月) 20:20:51.05

>>878
iphoneアプリ開発のためにmacが生き残ってるのは面白いと思ってる
元マカーだからほんと言うと寂しいし悲しいんだけど

**デフォルトの名無しさん** · 2021/06/07(月) 21:33:04.68

rustのlinux kernel対応の話ってどうなってゆの？なんだかずいぶんと作業が難航しているうだけど
それってrustのどのあたりの言語機能が悪さをしているのかね

**デフォルトの名無しさん** · 2021/06/07(月) 21:34:18.90

難航しているよう

**デフォルトの名無しさん** · 2021/06/07(月) 23:22:49.68

>>873
シンボリックデバッガはまだ有名どころのフロントエンドが
ステップ実行できる程度しか対応してないから、アブソリュートデバッガ併用になる。
シンボルでブレークポイント設定できないとか実行に問題あるとかまだ普通。
msvcツールチェインは特に。

>>877
ねねっち死んだなって思ってたけど現実もか。

>>878
世界シェア15%切ったし頼みの日本シェアすら50%切ったからもう
iPhone専用開発機も持たないだろう。
rustだとandroidほどバインディングが充実してないから開発やりずらいだろうし。

**デフォルトの名無しさん** · 2021/06/08(火) 13:22:42.82

>>881 大部分がRustで書かれたRedox OSっていうOSがあるからRustでカーネルやドライバが書けないというわけではないと思う
恐らくCで書かれた過去の遺産との連携で手こずってそう

**デフォルトの名無しさん** · 2021/06/08(火) 16:32:33.53

>>883
日本でのiPhoneのシェアは、どんどん減っているはずなのに、ググると、
増えているデータになっていて、増えているのに50%を切っているというわけの
わからなさ。
記憶では、70%くらいまでいって、下がった結果、49%くらいになったはずなのに。

**デフォルトの名無しさん** · 2021/06/08(火) 17:33:30.46

>>884
具体的には？

**デフォルトの名無しさん** · 2021/06/08(火) 20:08:36.67

いやメーリスみにいけよ。。。

**デフォルトの名無しさん** · 2021/06/08(火) 20:44:34.79

実際の開発状況はこっち見たほうがいいかな
https://github.com/Rust-for-Linux/linux
ざっと見た感じ難航してるっていうより単にやること多いってだけに見えるけど