Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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 part21
https://mevius.5ch.net/test/read.cgi/tech/1692105879/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/02/04(日) 23:24:52.22

rustとpythonではなく、tomlとpythonを比較すればいい
スクリプトを追放するたんびにマークアップ言語が増える歴史が繰り返される

**デフォルトの名無しさん** · 2024/02/04(日) 23:32:42.46

>>239
相手にしなかったら自演して自分に安価つけ始めるけどな

**デフォルトの名無しさん** · 2024/02/04(日) 23:55:39.05

>>241
tomlはマークアップ言語じゃなくてデータ記述言語
スクリプトうんぬんは知らんが、シリアライズ効率のより良いデータ記述言語を求めるのはいい事だよ
自分のところはjson+gzipで落ち着いてるけど、goでよく使われるprotobufにいずれ移行できればなって考えてる

**デフォルトの名無しさん** · 2024/02/05(月) 00:06:05.32

>>230
数値演算ライブラリはC言語で十分な気がする。理由を言語化するのは難しいけど

**デフォルトの名無しさん** · 2024/02/05(月) 00:06:28.07

オッやっとるな

**デフォルトの名無しさん** · 2024/02/05(月) 00:06:30.26

オッやっとるな

**デフォルトの名無しさん** · 2024/02/05(月) 00:11:45.07

一番向いてるのはミドルウェアとか少数のガチ勢が作ったらいいような部分なんだよな。
だから普及はしない。

**デフォルトの名無しさん** · 2024/02/05(月) 00:14:26.70

>>244
並列処理まわりの仕様をよく検討した上でRustかCかC++のどれを選択するべきとは思うな

**デフォルトの名無しさん** · 2024/02/05(月) 00:18:35.26

アルゴリズム周りなんて共有のオンパレードなのにrustが向いてると思ってるのはちょっと素人感がすごいね。

**デフォルトの名無しさん** · 2024/02/05(月) 00:25:50.11

日本語おかしくなった
並列処理まわりの仕様をよく検討した上でRust、C、C++のうちどれを使うか選ぶべき
個人的には並列処理の安全性の面でRustを使うべきだと思う

**デフォルトの名無しさん** · 2024/02/05(月) 00:31:12.78

まあ実情は演算処理にCUDAを使うだろうからC++で全部設計したほうが都合がいいのかな
難しい

**デフォルトの名無しさん** · 2024/02/05(月) 00:39:33.82

並列処理？tokioの出番だな

**デフォルトの名無しさん** · 2024/02/05(月) 00:52:01.28

機械学習はPython？Rust？いやいや争わずに両方使えばいいじゃん。

Rustを使って機械学習アルゴリズムを実装しPythonから呼び出す: k-meansクラスタリング
https://zenn.dev/skwbc/articles/rust_python_kmeans

**デフォルトの名無しさん** · 2024/02/05(月) 00:57:54.10

機械学習だの演算処理だの、いつまでそんなつまらない話をしてるの？
rustはゴミってことで結論が出てるんだけど

**デフォルトの名無しさん** · 2024/02/05(月) 01:03:32.12

荒らしに構うキチガイを追い出したいね
ID:gRgK5+vi　→　ID:Uc3vGql0　（違ったらごめんね）

**デフォルトの名無しさん** · 2024/02/05(月) 01:04:43.04

>>253
わざわざ生でunsafeなコードを書かなくてもPyO3とか使えば楽にできるよ

**デフォルトの名無しさん** · 2024/02/05(月) 03:14:48.13

>>243
Protocol Buffers古いし、MessagePack(古い)やCBORのほうがいいんじゃない？使ったことないけど。

**デフォルトの名無しさん** · 2024/02/05(月) 03:40:05.05

Protocol buffersは仕様変更に強いしフォーマットを別ファイルに定義出来るという特徴があるから、msgpackやcbor とは使うべきケースが違いそう

**デフォルトの名無しさん** · 2024/02/05(月) 06:01:25.37

>>247
もちろん少人数ガチ勢による開発もRustが向いてるのはおっしゃる通りだけど
大人数による開発もRust向いてるでしょう
特にC++で次から次に穴の発生が尽きない各大規模プロジェクトたちは作り直しや新規ならRust一択だね

**デフォルトの名無しさん** · 2024/02/05(月) 06:45:17.21

>>247
Rustはサーバーサイドで最もよく使われているっていう調査結果がすでに出ているが>>117,119

**デフォルトの名無しさん** · 2024/02/05(月) 06:55:14.99

>>253
どうでもいいがこの記事では非同期処理ライブラリにtokioじゃなくてrayonを使ってるんだな
気になってぐぐったら「rayonのスレッドプールは、CPU を集中的に使用する作業、つまり大規模なデータセットの大規模な並列処理向けに設計されています。」らしい
https://www.reddit.com/r/rust/comments/xec77k/rayon_or_tokio_for_heavy_filesystem_io_workloads/

**デフォルトの名無しさん** · 2024/02/05(月) 07:04:12.02

>>261
rayonは非同期を使わない並列に特化した時に速い
tokioは非同期で並行＆並列で万能

**デフォルトの名無しさん** · 2024/02/05(月) 08:21:40.19

>>227
なら言語的に優れていてPythonライブラリを使えるNim最強だな。

**デフォルトの名無しさん** · 2024/02/05(月) 08:36:20.41

Rust⇔PythonはPyO3で相互に呼び出せるのでRustだけあれば十分

**デフォルトの名無しさん** · 2024/02/05(月) 09:57:56.35

他の言語スレに乗り込んできて居座るとかやってる事ルビガイジとなんら変わらんっていう

**デフォルトの名無しさん** · 2024/02/05(月) 12:16:47.03

>>263
Nimは速いしCへのトランスパイルも賛否あれど個人的には好き

**デフォルトの名無しさん** · 2024/02/05(月) 12:56:18.45

>>211
お前や俺らがそのunsafe部分を書く。
で職場の他の今動きゃいいってコード書いてる奴らにはunsafe部分は利用させても書かせない。
そういう分け方できるのはメリットじゃないかね。

**デフォルトの名無しさん** · 2024/02/05(月) 13:02:02.94

>>266
同意

**デフォルトの名無しさん** · 2024/02/05(月) 22:28:07.58

>>259
もう5年くらいこんなこと言ってる人いるけど一向に普及してないよね。

**デフォルトの名無しさん** · 2024/02/05(月) 22:40:04.70

>>269
カーネルのRustへのマイグレーションの成果が各所で出てるの知らない？

**デフォルトの名無しさん** · 2024/02/05(月) 22:49:23.20

>>269
AWS SDKにRustが正式登場して、色んなところがRustを触りだしてるぞ

**デフォルトの名無しさん** · 2024/02/05(月) 23:29:16.62

AWSやCloudflareが大規模に使ってるからインターネットのトラフィックの結構な分量をRustが捌いてるはず
この5年でこういう人目には触れないけど基礎的な部分にずいぶん普及したよ

**デフォルトの名無しさん** · 2024/02/06(火) 00:09:13.25

Rust のユーザ規模はもはや小さくはないが仮に小さかったとしても、それが無用のものということを意味するわけではない。
Cobol や Fortran だって一般には化石のような印象を持たれつつも近年にも規格改定などの発展はあるし、それが求められる程度の利用シーンはある。
Lisp がインフラの中に潜んでいたりするし、Caml で書かれたプログラムがあなたがたのパソコンにインストールされていたりするのもそれなりに高い確率でありうる。
普及するっていうのはそれを不必要なところにまで押し付けたいわけじゃないだろう。

**デフォルトの名無しさん** · 2024/02/06(火) 00:25:40.67

物を作ってから普及するまでの時間で評価されれば
まだ作ってない物を売るようになったり、評価を信じなくなったりする

**デフォルトの名無しさん** · 2024/02/06(火) 00:35:44.14

>>271
あれすげー使いにくいよ
そもそもがAWSのAPI自体が非同期の作りですぐに返ってくるものばかりだから
ライブラリ側は同期的で良いのにtokio使っちゃってるし

**デフォルトの名無しさん** · 2024/02/06(火) 00:39:31.81

>>272
現在のネットのインフラであるクラウドとCDNがRust製になっていってるから
Rustがネットインフラを支えるようになって来たと言っても過言ではないんだね

**デフォルトの名無しさん** · 2024/02/06(火) 01:36:56.00

>>275
割と何言ってるかよくわからないので
どのあたりが使いにくいのか詳しく

**デフォルトの名無しさん** · 2024/02/06(火) 08:02:11.78

>>275
javascriptでただの同期functionだったものが非同期のasync awaitに変わった経緯がある
同期functionだとブラウザから呼び出した時に待ち状態がフリーズみたいになって不便だった

**デフォルトの名無しさん** · 2024/02/06(火) 08:41:24.69

>>275
それはキミの非同期処理に関する知識が欠如してるだけ

**デフォルトの名無しさん** · 2024/02/06(火) 10:42:58.91

まあわざわざライブラリ側で非同期にしなくても、必要ならユーザーが勝手に非同期にすればいいってのはあるかもな

**デフォルトの名無しさん** · 2024/02/06(火) 11:02:01.98

お前らはawait禁止縛りでもしてるの？

**デフォルトの名無しさん** · 2024/02/06(火) 11:12:37.31

tokioの非同期って
async fn、spawn、async、await
を最低限使えればなんも不自由なくね？
同期じゃないといけない理由あんの？

**デフォルトの名無しさん** · 2024/02/06(火) 11:17:49.52

同期的に使うだけの場合でも tokio をリンクするってのが気分よくないというのはわかる。

**デフォルトの名無しさん** · 2024/02/06(火) 11:19:55.73

>>282
同期じゃないといけない理由？非同期の使い方がわからないからじゃないか？
ちなみにRustがダメだとアンチが言うのはアンチがRustコードのコンパイルを成功できないから

**デフォルトの名無しさん** · 2024/02/06(火) 11:23:28.54

AWS SDKを同期的に使いたいってそれAWS CLIじゃだめなん？w

**デフォルトの名無しさん** · 2024/02/06(火) 11:25:05.20

>>280
そこの今まで独自にそれぞれが用意してた部分を async await 等のAPIとして整理されたことに意義があるんと思う。

**デフォルトの名無しさん** · 2024/02/06(火) 11:26:18.87

AWS CLIはcargo installで入ってこないから……

**デフォルトの名無しさん** · 2024/02/06(火) 11:28:28.70

そもそもRustを使う意味がないよね
AWS SDK for Pythonがあるんだから

**デフォルトの名無しさん** · 2024/02/06(火) 11:28:33.03

>>286
async awaitへの統合に意義があるのはわかるけど、tokioにまで限定されるのはダルイという気持ちがある

**デフォルトの名無しさん** · 2024/02/06(火) 11:33:54.88

>>289
そこはしょうがないでしょ
tokioはAWSが積極的に支援してるライブラリだからね
https://tokio.rs/
https://i.imgur.com/NSjb82s.png

**デフォルトの名無しさん** · 2024/02/06(火) 11:35:59.00

>>290
説教的に支援って資金的な支援じゃなくてAWSがtokioの営業することだったのか……

**デフォルトの名無しさん** · 2024/02/06(火) 11:38:49.18

あ、AWSがtokioを運営してんのか
単なるスポンサーだと思ってた

**デフォルトの名無しさん** · 2024/02/06(火) 11:40:13.71

マジか

**デフォルトの名無しさん** · 2024/02/06(火) 11:42:17.61

説教的な支援は5chの担当

**デフォルトの名無しさん** · 2024/02/06(火) 11:42:20.07

説教的な支援は5chの担当

**デフォルトの名無しさん** · 2024/02/06(火) 11:53:48.52

Rustで非同期やるライブラリって昔からたくさんあるけど最近はtokioしか使ってないや
すごく重い処理があるプロジェクトはtokioとrayonで使い分けてるけどそれでも両方のライブラリをプロジェクトで共存させてる

**デフォルトの名無しさん** · 2024/02/06(火) 12:09:35.30

非同期と言いつつ出来てない奴って8割いるよね

**デフォルトの名無しさん** · 2024/02/06(火) 13:54:11.58

非同期のそのデメリットを消す方法は
まだ作ってないことにしよう

**デフォルトの名無しさん** · 2024/02/06(火) 14:05:46.01

>>277
まずAWSのAPIってのは基本的にすぐ返ってるの
この辺はわかる？
例えばインスタンスを作るAPIってのはインスタンスを作り終わるまでブロックするんじゃなくてインスタンス生成命令を出してすぐに返ってくるわけ
実際にインスタンスが生成完了したかはインスタンスの状態取得APIを使って確認するわけ
だから常に同期的に呼び出しで問題ないの
pythonのboto3ってライブラリが1番使いやすい

**デフォルトの名無しさん** · 2024/02/06(火) 14:08:10.63

Boto3、あんま補完されなくて馬鹿にはキツい

**デフォルトの名無しさん** · 2024/02/06(火) 14:39:52.97

>>299
AWSが鯖落ちしてたらどーすんの？

**デフォルトの名無しさん** · 2024/02/06(火) 14:47:03.29

>>299
あなたが何言ってるかわかるけどnodejsでも
似たような使い方だしrust sdkの欠点と言われても
広く同意は得られないんじゃないかなあ

**デフォルトの名無しさん** · 2024/02/06(火) 14:52:06.28

>>302
欠点というか使い方を難しくしてるだけな気がするんだよな
普通にCLIでええやんって思う

**デフォルトの名無しさん** · 2024/02/06(火) 14:59:31.38

>>303
awsに限らずweb apiのライブラリは
非同期にするのが主流だから
頑張って勉強してねとしか…

**デフォルトの名無しさん** · 2024/02/06(火) 15:05:27.46

AWSのSDKは.NETのが1番だな

**デフォルトの名無しさん** · 2024/02/06(火) 16:38:39.75

AWS SDK for Rustはsend()がめちゃくちゃダサい
そのうち大幅に改修されるだろうけど

>>299
ネットワークI/Oを同期で書くのはさすがにどうかと

**デフォルトの名無しさん** · 2024/02/06(火) 16:55:31.82

>>300
今から見ると微妙だがCLIと対応がつけやすいし
余計なことはしなくて良いから楽だよ

**デフォルトの名無しさん** · 2024/02/06(火) 17:04:11.45

>>306
どう書くか？はユーザーのユースケースによるからそうとも言えないよ
例えばAzureのCLIは--no-waitというオプションがあり
処理が成功するまで待つか待たないかを決められる
これこそユーザー視点の設計だよ

**デフォルトの名無しさん** · 2024/02/06(火) 17:08:06.92

Google規模の会社が$1 million渡したくらいでわざわざアナウンスするなよな
タイトル詐欺じゃん

Improving Interoperability Between Rust and C++
https://security.googleblog.com/2024/02/improving-interoperability-between-rust-and-c.html

**デフォルトの名無しさん** · 2024/02/06(火) 17:08:19.95

非同期を押し付けることはユーザーのメリットにはならない
Rust SDKは作り直して欲しい

**デフォルトの名無しさん** · 2024/02/06(火) 17:21:49.29

prostもblocking版の関数ないのかよってびっくりした記憶があるわ
C#版もPython版もasyncとblockingの両方あるのにな

**デフォルトの名無しさん** · 2024/02/06(火) 17:23:58.68

>>299
>>まずAWSのAPIってのは基本的にすぐ返ってるの
>>この辺はわかる？

初心者でもそんなウソはつかないぞ
AWSに限らず任意のサービスに言えるが通信時間がかかる
さらに各サービス内で状態取得だけであっても実行時間がかかる

>>だから常に同期的に呼び出しで問題ないの

本気で言ってる？
通信時間と向こうでの実行時間の間こちらはずっと何もせずに待つわけ？
非同期プログラミングの意味すら理解できていてないのか？

**デフォルトの名無しさん** · 2024/02/06(火) 17:27:07.44

>>312
コンピューターにとって1秒待つって事がどれだけ長いかを理解してないんだろ

**デフォルトの名無しさん** · 2024/02/06(火) 17:28:50.84

非同期の方が良いことが多いのは同意するが、非同期を押し付けられると「こんなプログラムのためにTokio入れるのかよ」って思ってしまうケースは存在する

**デフォルトの名無しさん** · 2024/02/06(火) 17:48:41.35

API が非同期で設計されてるのに、それを呼び出す側もさらに非同期でハンドリングするのは正直無駄じゃない？
ってのはわりと自然な感想だと思うけどな。

AWS の API なんてクライアント側で並列に呼び出したいユースケースも無いだろ。
バカスカ叩いてもスロットリングされるだけだし。

**デフォルトの名無しさん** · 2024/02/06(火) 18:00:53.30

>>315
APIの向こう側で非同期なのとこちらの処理を
同期か非同期化は関係ないよね

**デフォルトの名無しさん** · 2024/02/06(火) 18:18:54.67

それな
無関係ではないけど分けて考えないと

**デフォルトの名無しさん** · 2024/02/06(火) 18:33:39.13

>>308
非同期APIが提供されてれば同期化は簡単にできるから必要ないんだよ

**デフォルトの名無しさん** · 2024/02/06(火) 18:36:16.19

同期化ってasyncでない関数から呼べるようにするって解釈で合ってるだろうか
もしそうだとしたらasyncでない関数の中でtokioランタイム作ってawsよんでruntime終わらせるみたいな処理になっちゃわないか

**デフォルトの名無しさん** · 2024/02/06(火) 19:56:13.91

AWSの同期的APIの機能リクエストあるのね
https://github.com/awslabs/aws-sdk-rust/issues/505

**デフォルトの名無しさん** · 2024/02/06(火) 20:03:24.75

AWSのAPIの呼び出しが非同期になるのはAPIの内部で効率化のために非同期処理をやってるからでしょ？

**デフォルトの名無しさん** · 2024/02/06(火) 20:17:12.09

うちはAWS SDK RustはAxumベースのWebアプリでDynamoDB接続に使ってるけど、みんなはなににAWS SDK使ってるん？

**デフォルトの名無しさん** · 2024/02/06(火) 20:38:04.56

>>312
だからーなーんにもわかってない発言丸出しはやめよ？
通信の時間なんてかからんのやって
すぐ返ってくるから
そこちゃんと読もう？

**デフォルトの名無しさん** · 2024/02/06(火) 20:44:38.46

AWS APIを生のRESTで実装してみろよ
すぐわかるぞ

**デフォルトの名無しさん** · 2024/02/06(火) 20:45:53.99

言っておくが俺は一般論として非同期がダメと言ってるわけじゃないぞ
もちろんその用途としての方が便利なことは多い
あくまでAWS SDKのRust版については不満があるということよ

**デフォルトの名無しさん** · 2024/02/06(火) 20:50:46.76

>>325
web apiの実装として相手側が非同期処理で
手元も非同期なんてのはawsだけじゃないというか
それが主流だけど他はいいの？

**デフォルトの名無しさん** · 2024/02/06(火) 20:50:52.38

このスレにはRust関連の悪い所の指摘を見ると自分が全否定されたように怒り出す人間がいるっぽいので

**デフォルトの名無しさん** · 2024/02/06(火) 20:57:52.50

tokioが素晴らしいのは間違いない
しかし今回のREST APIの呼び出しで程度で必要かな？と思う

非同期が必要ならtokio::process::commandでCLIを非同期で呼ぶ方が良くないか？とか色々考えてしまう

**デフォルトの名無しさん** · 2024/02/06(火) 21:04:51.51

>>323
>>通信の時間なんてかからんのやって
>>すぐ返ってくるから

呆れた
敢えてウソをついているのか？
それとも本当に無知な初心者なのか？

**デフォルトの名無しさん** · 2024/02/06(火) 21:08:56.44

Web通信ですぐ返ってくることなんかあるのか？　と思ったけど、AWSのAIPの中身知らんから何とも言えんくなってしまった

そういえばファイルIOはすぐ返ってくるって言って良いんだろうか

**デフォルトの名無しさん** · 2024/02/06(火) 21:12:11.34

>>330
サイズが小さいファイルに対して非同期呼び出しをするか？という話

**デフォルトの名無しさん** · 2024/02/06(火) 21:14:41.84

>>331
まあ「ファイルIOにTokioが必要です」って言われたらちょっと嫌な気分になるな

**デフォルトの名無しさん** · 2024/02/06(火) 21:15:39.21

>>330
Web通信は通信時間だけで大きく時間を要する
さらにWebサーバ側で処理時間がかかる

**デフォルトの名無しさん** · 2024/02/06(火) 21:56:45.71

>>323
cpuのナノ秒単位の処理速度に比べたら通信はとてつもなく遅いけど
レスポンスを受け取るまでの時間は処理を中断させたほうがコンピュータに優しい
tokioのグリーンスレッドを活かせ

**デフォルトの名無しさん** · 2024/02/06(火) 22:05:59.23

>>334
tokioのランタイムが裏で動くとか気持ち悪すぎだろ
同期でやらせろ

**デフォルトの名無しさん** · 2024/02/06(火) 22:13:28.77

他のSDKのようにv3くらいになれば使いやすくなってるかもね

**デフォルトの名無しさん** · 2024/02/06(火) 22:16:42.98

aws sdk for rust ってwebフレームワークでサーバーサイドやってる人向けだから当然のようにみんなtokioを既に組み込んでるもんじゃないの？なにがそんなに気に入らないのか理解ができない
まあtokio以外の非同期ランタイムを使わせろって人はドンマイだけど

**デフォルトの名無しさん** · 2024/02/06(火) 22:17:52.75

「rustのwebフレームワーク」が抜けてた

**デフォルトの名無しさん** · 2024/02/06(火) 22:21:16.54

>>337
そういう話じゃないけど

**デフォルトの名無しさん** · 2024/02/06(火) 22:24:12.00

>>337
実装の話に逸らさないで
AWSのAPIくらい同期で十分なのにわざわざ非同期にする理由を言えよ

**デフォルトの名無しさん** · 2024/02/06(火) 22:24:15.12

いくらすぐ返ってくるっていってもネットワーク通信なんだから
不通だったりレイテンシが長くなることはありうるし、
タイムアウトやリトライをtokioのエコシステムに乗っかってやれるメリットはあると思うけどな
そりゃ軽量な同期版があるに越したことはないけど、優先順位は落ちるだろう