24/01/21 21:33:08.24 LhOQKlqN.net
>>5
refはbind by reference
左辺(相当)でのみ使う(binding生成時のみ)
右辺で&を使うのと同じだけど右辺で&を指定できない場面で使う
&を左辺で使うとパターンマッチでデリファレンス
右辺で*を使うのと基本同じ
10:デフォルトの名無しさん
24/01/21 22:36:05.82 /n8yifEU.net
>>ｽﾚﾘﾝｸ(tech板:990番)
一応知らない人のために書いておくけど
「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない
>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ
最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ
URLﾘﾝｸ(github.com)
11:デフォルトの名無しさん
24/01/21 22:51:42.90 w4jDa8WO.net
>>9
無意味な揚げ足取りをしてRustを叩きたい人はアンチスレへ
棲み分けしてください
Rustアンチスレ
ｽﾚﾘﾝｸ(tech板)
12:デフォルトの名無しさん
24/01/22 00:47:14.54 jqH5vdYX.net
仕様バグだから直せないじゃなくて
厳密なチェックをする実装は0から作ったほうが早いから
今使ってる確率的(笑)な実装は変更しないんだよね？
13:デフォルトの名無しさん
24/01/22 03:17:34.54 laN06gwL.net
これマジ？ どれくらいの確率で踏むんけ？ コンパイルのバクはケアしたくないなあ
14:デフォルトの名無しさん
24/01/22 04:28:43.80 DrvqbiCd.net
>>12
意図的にvarianceの穴を突く無意味なコードを書かないと発生しないため>>9は無害
15:デフォルトの名無しさん
24/01/22 09:21:43.10 k43UrEGh.net
>>9
こんなコンパイラの脆弱性を突くようなコードを普通なら書かない定期
16:デフォルトの名無しさん
24/01/22 21:22:44.12 m6FRVxec.net
>>9は9年前の2015年から既知の有名なパターン
意味のあるプログラミングで絶対に踏むことはないため害はない
その特殊ケースに対応するデメリットの方が大きいため対策されていない
それらを踏まえたうえでIT大手が揃ってRustを採用しRust Foundationも設立された
17:デフォルトの名無しさん
24/01/22 21:31:04.02 l2He84BH.net
9のコードの意味が理解できないんだが何が問題なのか説明してくれ
18:デフォルトの名無しさん
24/01/22 22:53:37.35 6ImN7JeY.net
c++のテンプレートはチューリングマシンだから
無限ループを起こせるのは仕様の欠陥がどうか聞きたい
19:デフォルトの名無しさん
24/01/22 23:05:33.08 YajFhzWL.net
f: impl for<'s> FnOnce(&'s str) -> (&'static str, [&'static &'s (); 0]) の説明だけ。
ライフタイム 's の str を引数にして、&'static str 型と、[&'static &'s (); 0] 型のタプルを返すクロージャが f ということ。
[&'static &'s (); 0] は &'static &'s () 型の長さ 0 の配列。
&'static &'s () は、ユニット型() のライフタイム 's の参照のライフタイム 'static の参照。
この &'static &'s () の部分で変なことが起きてそうと言っとるな。
20:デフォルトの名無しさん
24/01/22 23:14:04.77 T1sqP3ZB.net
>>17
C++ の仕様ではテンプレートの展開深度に上限を設定することを認めているのでチューリングマシンではない。
非現実的な回数のループが起こるのならそれは処理系の欠陥。
21:デフォルトの名無しさん
24/01/22 23:41:39.76 NA4FP1NO.net
>>15
1.65.0で新しく導入された回帰バグですって書いてあるし
2015年の#25860とも別だねってコメントも付いてますやん
22:デフォルトの名無しさん
24/01/23 00:35:34.27 AizsfBYE.net
>>18
文脈無視してその引用だけで言えそうなことは
&'static &'s T 型が存在するならば 's も 'static でなければならない
このルールに反しない限り &'s str を &'static str に変換してよい
23:デフォルトの名無しさん
24/01/25 23:09:32.35 iPN7/qe+.net
安全にこれで&'staticへ変換できる
fn to_static_str(s: &str) -> &'static str {
s.to_owned().leak()
}
24:デフォルトの名無しさん
24/01/26 23:31:43.19 ZBdWgzp4.net
最後までずっと使うものやあるいは
あるメモリ限度内に収まる使い方ならば
リークさせて扱いが楽になるメリット享受を選ぶのもありかもな
25:デフォルトの名無しさん
24/01/27 23:34:17.17 kvD8ZR3g.net
>>22
それ&'static strではなく&'static mut strを返してもええねんで
26:デフォルトの名無しさん
24/01/28 02:18:12.19 tZGISO28.net
>>22
leakって安全なの？
27:デフォルトの名無しさん
24/01/28 04:27:59.88 2343IlJN.net
leakは安全
そのプログラム終了まではその部分のメモリを解放しないだけ
28:デフォルトの名無しさん
24/01/28 08:32:52.16 hRRbWEE/.net
>>25
Rust の定義ではメモリリークは安全性を損なわないことになってる。
言語の機能として積極的に阻止しなければならないような動作ではないが、
だからといってむやみにリークさせていいわけでもないのは当然なので
そこらへんはロジック上の必要性を鑑みて「正しく」運用するのはプログラマの責任だよ。
29:デフォルトの名無しさん
24/01/28 12:34:08.20 tZGISO28.net
leakは参照を削除するとメモリリークになると書いてあった（機械翻訳）けど参照って削除できるの
30:デフォルトの名無しさん
24/01/28 13:17:17.43 lA5rY1V0.net
>>28
原文は何て書いてるのさ
31:デフォルトの名無しさん
24/01/28 14:30:03.90 WlHw4mUK.net
期待した通りの結果になるのは危険ではないという知見は合理的だ
期待や願望よりも地獄のような厳しい現実にこだわるバイアスがかかってない
32:デフォルトの名無しさん
24/01/28 15:17:37.40 2343IlJN.net
>>28
leak()は所有者がいなくなるだけ
つまりそのメモリ領域が解放されなくなるだけで安全な行為
そこを指す参照だけになる
一般的に参照は指しているだけ
その参照を表す変数もしくは一時的な値が消えればその参照は消えたことになる
参照が消えても実体には何ら影響なく解放なども生じない
33:デフォルトの名無しさん
24/01/28 18:26:28.82 WlHw4mUK.net
メモリリークにならない＝参照がデストラクタを呼び出せる
ではなく
参照はデストラクタを呼べないが、参照が永久に残ればメモリリークにならない
34:デフォルトの名無しさん
24/01/29 23:08:47.69 GnLHDaEQ.net
メモリリークは多義なので
GC言語でも、今後は使わないオブジェクト等をどこが参照しているため解放されない、これもメモリリークと言う
つまり参照が残っているからメモリリークじゃないとは言えない
逆にRustの場合は、leak()を適用した時点でそこは永久に解放されないのだから、既にメモリリークとも言える
もちろんそれで困らない時に意図的にリークを可能とするものなので、その機能や行為自体に問題はなく、そのプログラムの性質や環境や方針次第
35:デフォルトの名無しさん
24/01/30 02:10:08.22 gYzmItMj.net
多義である事実に人間が従うのではなく、定義を変えたいので変えまくった人間に事実が従う
利己主義の結果を予想するのではなく結果を予想できる範囲内で利己的になる
36:デフォルトの名無しさん
24/01/30 06:01:38.95 lXERqUpG.net
きちんとメモリ確保・解放する
ただそれだけのことだけどうまく行かないものだね
37:デフォルトの名無しさん
24/01/30 07:11:49.27 g++Pj77W.net
>>35
Rustならそれができるし保証される
ただしその基本に加えて融通を利かせることもできる
意図的にリークさせる(解放しない)こともできるしそれを使わないこともできる
意図的に循環参照を作ってリークさせることもできるしそれを避けるための手段も用意している
38:デフォルトの名無しさん
24/01/30 11:19:29.95 LgX6lgq1.net
それくらいできてくれないと習得に対して割に合わない
39:デフォルトの名無しさん
24/01/30 23:08:46.90 shd55QRp.net
>>35
二回以上解放しない保証は大成功した
一回以上解放する保証をやる気がない
与えられた問題を勝手に分割してやりたい部分だけやってる
40:デフォルトの名無しさん
24/01/31 05:41:08.45 XSmS7DeM.net
Rustでは意図的にリークもしくは意図的に循環参照作成の場合を除いて必ず解放される
41:デフォルトの名無しさん
24/01/31 22:24:17.87 rU+aRD+l.net
スポーツでも五輪だけが目的のプロがいたら割に合わないが
なんか目的をあやふやにすれば五輪に出ても破産しないよね
42:デフォルトの名無しさん
24/02/01 16:48:45.42 ernnY6oF.net
Microsoft seeks Rust developers to rewrite core C# code
URLﾘﾝｸ(www.theregister.com)
でかいところのバックエンドRust化が増えてきたな
43:デフォルトの名無しさん
24/02/01 17:28:29.31 xcOmoIH1.net
しかしRust流行らんな
44:デフォルトの名無しさん
24/02/01 19:27:48.94 6WtKOSai.net
Pythonやkotlinみたいな手軽さで堅牢で高いパフォーマンスが出れば最高なんだけどなかなかね
45:デフォルトの名無しさん
24/02/01 20:38:04.52 XOfXRWXD.net
from C to Rust へのマイグレーションは時間がかかるからしゃあない
46:デフォルトの名無しさん
24/02/01 21:16:53.56 E1I2Gvr8.net
>>43
Pythonはスクリプトを書く程度ならいいけどプログラミングには不向き
47:デフォルトの名無しさん
24/02/01 21:44:37.29 Nzd8TkB/.net
きちんとガベコレしてるのに見下されてるなあPythonは
きちんとしても割に合わない
48:デフォルトの名無しさん
24/02/01 21:53:27.11 7aZ9tAiW.net
動的型は堅牢とかきちんとやるみたいなのと相反するんだよな
書き捨てならいいけど長期的にメンテするやつには向いてない
49:デフォルトの名無しさん
24/02/01 21:55:25.71 9CL84hYM.net
Rust、言うほどPythonと比べて手軽でないか？
50:デフォルトの名無しさん
24/02/01 22:17:59.13 B5mxz6YT.net
プログラマの意図を書かないと、意図を表せる言語じゃないと「正しい」かどうかは検証しようがない。
だから意図の表現方法として型やライフタイム注釈やらの形を確立したのであって、お手軽に柔軟に動かす言語では実行時に不都合があれば止まるという形にならざるを得ない。
静的型があれば全部が解決ってわけではないけどごく基本的な整合性検査すらせずに実行するまでわからんというのはメンタル的にきつい。動的型はきつい。
自分で把握できる程度の小さな規模なら動的型のほうが楽ってこともあるといえばあるけど、人類は駄目なのでちゃんと把握できる規模は自分で思っているよりだいぶん小さい。
51:デフォルトの名無しさん
24/02/01 22:29:20.68 wp2DoW25.net
Pythonはやっぱり行列を扱うのに長けてる気がするな
ただ静的には何の変数を見ても(Variable)xxx: Anyみたいな型推定しかされていなくて、自分の書いたコードですら訳がわからなくなる
他人の書いたライブラリを使うときはまるで魔法を使ってるかのようだ
52:デフォルトの名無しさん
24/02/01 22:40:37.81 Nzd8TkB/.net
Pythonというかインタプリタは部分的にCを使うことを認めざるをえない
それを大多数に納得させるコストが激安
53:デフォルトの名無しさん
24/02/01 22:42:10.75 tu2Yd+rZ.net
>Pythonはやっぱり行列を扱うのに長けてる気がするな
pythonのどこが？numpyがあるだけじゃね。
54:デフォルトの名無しさん
24/02/01 22:45:58.52 E1I2Gvr8.net
PythonはC/C++/Rustで書いたライブラリを呼び出すスクリプト言語として使っている限りは問題ない
プログラミング言語としては不向きで使うべきではない
55:デフォルトの名無しさん
24/02/01 22:54:05.96 Nzd8TkB/.net
OSのカーネルにはPythonは不向きだからクソどうでもいい生存競争をしなくてすむ
56:デフォルトの名無しさん
24/02/01 23:06:17.91 0Yigz0zQ.net
使い分けが出来ない人はスキルが低いだけ
言語に限らずどの技術でも同じこと
57:デフォルトの名無しさん
24/02/01 23:13:02.07 iVey9ypb.net
各種カーネルのRust移植に時間かかってるけどC/C++からRustへの書き直しってそんなに大変なの？
58:デフォルトの名無しさん
24/02/01 23:14:24.05 h0D2/F6d.net
Pythonもプログラミング言語だしシェルスクリプトも立派なプログラミング言語だよ
59:デフォルトの名無しさん
24/02/01 23:23:51.23 itS/z8tN.net
プログラミング言語はそれに付随するフレームワークの質で需要が変わってくるけど、
C/C++/Rust/アセンブラなど低水準言語はガべコレのランタイムが不要というアドバンテージがある
だからカーネル用途での需要が高い
60:デフォルトの名無しさん
24/02/01 23:26:15.91 B5mxz6YT.net
Ruby もだいぶん長いことバイトコード化すらせずに木を辿るクソ遅い設計だったんだぞ。
でもなあ、使い分けといってもやっぱり慣れたらもうちょっと他の場所でも使いたくなるし、速度の要求も静的検証の要求も出てくる。
今の Ruby は Jit で速くなったし型チェックのサポートも本格的になった。
使い分けは要るがせずにすむならそれに越したこともないんよ。
61:デフォルトの名無しさん
24/02/01 23:26:33.20 8nChHaP8.net
>>56
そのまま移植はほぼ不可能でしょ
データ構造から設計しなおさらないと
クソコードになりがち
62:デフォルトの名無しさん
24/02/01 23:33:40.62 B5mxz6YT.net
C の世界の文字列はゼロ終端やんか。
カーネルのインターフェイスにもその規約がそのまま現れてる。
内部的な設計は Rust 的にしつつも外向きのインターフェイスは変えないように置き換えるなら微妙な変換があらゆるところに出てくるよ。
まあそのへんは適当な専用フレームワークを確立させればたいしたことでもないが、そういう地味なことの積み重ねがいっぱい要るよ。
63:デフォルトの名無しさん
24/02/02 00:29:39.63 wYh3cvfE.net
C/C++からJavaってのはすげー移植しやすかったのよ
その利点はほとんどないと多くの人が気がつくのに20年もかかってしまったけど
64:デフォルトの名無しさん
24/02/02 00:36:47.62 iO9F+zBT.net
>>56
書き直しさえすれば何でもいいというのは大変だろうね
何でもいいというのは嘘で
本当は好き嫌いがあるから
65:デフォルトの名無しさん
24/02/02 01:16:00.31 fEMhv+T7.net
コード移植なんてつまらなくて言語差で面倒なだけ
守るべき仕様さえはっきりしてるならゼロから書いたほうが結果的に早くて質も良くて楽しい
66:デフォルトの名無しさん
24/02/02 01:28:41.76 iO9F+zBT.net
仕様とか契約とか目的とかは未来を予測する根拠としてはイマイチ科学的でない
67:デフォルトの名無しさん
24/02/02 01:38:03.89 ZFQgO+dm.net
Linux だとバイナリ互換性もかなり大事にしてる。
(Windows ほどじゃないが。)
仕様として明文化してない挙動に依存するアプリケーションであっても今まで動いていたものが動かなくなるのは良くないという方針。
「守るべき仕様がはっきりしていれば」という前提がなりたたないから困るんだよ。
そしてそれはよくあること。
68:デフォルトの名無しさん
24/02/02 01:40:32.02 fEMhv+T7.net
ときどき仕様も要件定義もはっきりせず発注者が把握できていないものの言語移植ケースがあるがその仕事を引き受けないほうがいい
バグらしきもの含めて現存コードと同じ動作をするよう求めてくるためムダな面倒に精神力が奪われる
69:デフォルトの名無しさん
24/02/02 11:04:47.16 VI0tbigR.net
仕様さえ守っていればいいみたいな考えに従うと最近はお役所系でもちらほら見るクローム以外を
排除する極右Webサイトが出来上がったりするんだろうな。発注側でも受注側でもね
70:デフォルトの名無しさん
24/02/02 11:10:52.47 BQKaaqcl.net
ちゃんと充分な調査費用も出るならやらんでもないけどな。
大きなシステムの一部をリライトする場合には一から作る場合より数倍のコストがかかっても
全体をやり直すよりはマシだから「同じもの」を求めるのはそれなりに合理性がある。
全部をリプレイスするのに前と同じという要求するやつがいたら、
前と同じがいいならそのまま使っとけやという気持ちになる。
71:デフォルトの名無しさん
24/02/02 11:38:15.79 cSpiCBqt.net
C/C++→Rust 安全化とそのデバッグ開発効率化
C/C++以外→Rust 高速化と省メモリ化
これらの恩恵があるため
安全でないことによるバグ発生で困っているならC/C++→Rustを
CPUメモリリソース削減が求められてあるならC/C++以外→Rustを
たとえ同じ仕様のままでもやる意味が生じる
72:デフォルトの名無しさん
24/02/02 12:27:55.82 ndCfDt6c.net
>>70
費用対効果考えると厳しいな。
c++のプロジェクトをRustに切り替えるよりか、コーティング規約組んでlint用意して強制したほうが効果高そう。
既存コードの扱いが難しいけど。
73:デフォルトの名無しさん
24/02/02 13:20:50.14 ujySZ5KU.net
Webアプリ用途でもAxumやActixがフレームワークとして十分使いやすいから、もっとRustは普及していい
74:デフォルトの名無しさん
24/02/02 13:32:21.68 gukHO/4I.net
c++ から rust に移すなら、その前に c++ コードのリファクタリングとしてmove使用コードに直すだろうし、
それやったらもうそれで良くね？ってなると思うわな。
75:デフォルトの名無しさん
24/02/02 15:02:39.89 SOk2CQ22.net
言語移植はそのうちAIがなんとかしてくれるんじゃなかろうか
76:デフォルトの名無しさん
24/02/02 17:43:40.65 wsXMOW5f.net
所有権があるから GC 言語からの移行でも安全になる恩恵はあるんだよなぁ。
ほんとエポックメイキングな言語だよ。
77:デフォルトの名無しさん
24/02/02 19:12:44.91 6TGLHO8E.net
rustの最大のメリットは、絶対では無いけどコンパイルさえ通ってれば他人のクソコードに悩まされずに済む点じゃないかね。
78:デフォルトの名無しさん
24/02/02 21:11:58.02 K0BmHg5g.net
>>76
なんで悩まされないの？
79:デフォルトの名無しさん
24/02/02 21:33:43.48 ya0nDY0I.net
Rustでも糞コード見かける
たとえば非常に単純な例でいうと元の部分strを返せば済むのにString作っちゃうなど無駄にヒープ使ってしまうケース
でも見抜きやすく手直しもしやすい
80:デフォルトの名無しさん
24/02/02 21:34:56.76 ya0nDY0I.net
Rust以外でよく見かけるのはど
こで書き換わっているかわかりにくく副作用や競合が心配なケース
Rustではデータ競合が起きないしグローバル変数も制限があるためこの手の類には悩まされない
81:デフォルトの名無しさん
24/02/02 22:24:30.77 BZlEVlBD.net
メリットが欲しいと思ったことはないな
新しいジャンルで唯一の選択肢なのでメリットの大きさを比較する必要がない
異なるジャンルでは比較する意味がわからない
82:デフォルトの名無しさん
24/02/02 22:27:27.20 ASeaHMD6.net
>>78
1周回ってString返したほうが良くなる状況もあるからそんなに単純じゃないよ
83:デフォルトの名無しさん
24/02/02 22:29:00.17 ASeaHMD6.net
>メリットが欲しいと思ったことはないな
誰もメリットが欲しいかどうかについては話してないよｗ
84:デフォルトの名無しさん
24/02/02 22:34:00.04 ya0nDY0I.net
>>81
それは絶対にない
部分str返しで済むなら必ずそうすべき
それを返された側がString化が必要な時のみ行なう
85:デフォルトの名無しさん
24/02/02 22:36:34.16 BZlEVlBD.net
欲しくないものを供給している可能性を誰も想定していないのか
86:デフォルトの名無しさん
24/02/02 22:47:15.09 P1ceRtbI.net
わかりやすいのがstr.trim()かな
前後のスペースを取り除く関数だけど当然Stringではなくstrの一部分を返す
Stringがほしい人はstr.trim().to_string()
87:デフォルトの名無しさん
24/02/02 22:52:35.98 SRUTe3RO.net
>>85
欲しい人にもそうでない人にも対応できるように&strがベストとは思わんか？
88:デフォルトの名無しさん
24/02/02 22:55:20.18 P1ceRtbI.net
>>86
同じ主張だよ
str返しが可能ならStringを返してはいけない
slice返しが可能ならVecを返してはいけない
89:デフォルトの名無しさん
24/02/02 23:19:45.92 BZlEVlBD.net
上書きされる前に別の場所にコピーした方が比較的安全というメリットが消えた
Rustが消した
90:デフォルトの名無しさん
24/02/02 23:26:54.37 ya0nDY0I.net
>>88
Rust以外ではいつ書き換えられたりor解放されたりするかわからないから
安全なプログラミングということで(無駄になる恐れもあるけど)コピーしておく安全策をとることがあった
Rustでは知らぬ間に書き換えられたりor解放されたりすることはないので
安全策を保ったままで無駄なコピーが不要となった
91:デフォルトの名無しさん
24/02/02 23:26:59.82 9Dc3A0qD.net
Stringを使うことで無駄に専有されるヒープメモリはそこまで悪に感じないわ
カーネル作ってるわけでも競技やってるわけでもないんだったらね
可読性のために型を統一させるほうを優先する
92:デフォルトの名無しさん
24/02/02 23:34:55.21 v5+jJWMk.net
>>90
主張がよくわかりません
&strを渡せば済むところをString渡しで統一したりしてるのですか？
それで可読性が上がるとは思えません
93:デフォルトの名無しさん
24/02/03 00:06:15.17 zqTPQxFe.net
>>90
そのためにムダにto_string()やそのclone()をするのは間違い
他の言語やスクリプト言語ですらそんな酷いことは行われずにコピーオンライトやインターン化でムダを防いでいる
Rustではまずは&strで行ける範囲は&strで行き次にCow併用そして同じ中身のStringが複数できるならstring_cacheなどでインターン化など
94:デフォルトの名無しさん
24/02/03 00:06:54.99 26gTKyDM.net
C++でもstring_viewとstringは使い分けるぞ
95:デフォルトの名無しさん
24/02/03 00:39:47.95 x4y7pcy2.net
&strでいいなら&strで返すのが基本だけどプログラム全体を見たときにStringで返したほうがものすごくコードを単純にできる場合がある
アロケーションコストが全く問題にならない状況であれば&strに固執する必要はない
無駄なヒープアロケーションは増えるけど違う観点の無駄を削減してる
トレードオフだよ
型を統一するって話はよくわからんけど
96:デフォルトの名無しさん
24/02/03 00:41:39.18 26gTKyDM.net
そこ気にしないなら普通にスクリプト言語でも使っとけば良いと思うよ
97:デフォルトの名無しさん
24/02/03 00:44:03.79 zqTPQxFe.net
>>94
そんな例は起きない
strを返された側でString化が必要な時のみするのがベスト
98:デフォルトの名無しさん
24/02/03 05:44:40.82 /t14gmUC.net
>>96
そりゃベストはそうだろうけどさ…
c++で言うchar型で良いところをわざわざstdのStringを使うなって話でしょ？
動的メモリ確保になってようがその程度の誤差くらい動けばどっちでもいいわ…
99:デフォルトの名無しさん
24/02/03 06:03:57.16 HSW3HPjS.net
>>95
Rustから一気にスクリプト言語は飛躍しすぎだからスクリプト言語より先にガべコレ付き言語を薦めてくれ
ガべコレ付き言語はヒープメモリを気にしない人にはおすすめだよ
100:デフォルトの名無しさん
24/02/03 06:28:46.54 zqTPQxFe.net
>>97
文字列だけでなく一般的な話
部分スライスを返せば済むところをわざわざVecにして返すことが許されるのか？という話だぞ
これを誤差だと言い張るならRustを使う資格はない
101:デフォルトの名無しさん
24/02/03 06:58:55.64 SxNvW1DJ.net
こだわりの強い人がおるなあ
102:デフォルトの名無しさん
24/02/03 07:31:56.62 0zMBHAmc.net
sliceやstrですむのにVecやStringを使ってしまう人はlifetime parameterを習得できていなくて使えこなせないからだと思うよ
structやfnでlifetime parameterを付けたことのない初心者に多いね
103:デフォルトの名無しさん
24/02/03 07:36:46.05 Sa0HPxlU.net
こういうふうに面倒くさい人がRust使いには多いから普及しないんだろうなあ
アルゴリズムとデータ構造の分野からみてもクッソどうでもいい議論だよ
104:デフォルトの名無しさん
24/02/03 07:41:20.05 0zMBHAmc.net
>>102
アルゴリズムとデータ構造の一番の基本が無駄なコピーをしないこと
105:デフォルトの名無しさん
24/02/03 09:16:17.07 EvhZrc0+.net
strで返せるがあえてStringで返すと良い具体例を出せばいいのではと思った。
106:デフォルトの名無しさん
24/02/03 11:13:51.22 26gTKyDM.net
富豪的プログラミングしたいならrustは向いてないよ
普通にpythonで十分
107:デフォルトの名無しさん
24/02/03 11:17:22.51 3G/0wdmC.net
でもPythonのDjangoは遅くてゴミじゃん
省メモリ最速のWebアプリ作るならRust一択だわ
108:デフォルトの名無しさん
24/02/03 11:17:53.18 JbxU5Bja.net
例えばsplitみたいなのはstrで返せるけど、それを大量に呼んで受け側でto_stringをつける場合、
コードがto_stringだらけで見づらくなるとかはあるかな
そういう時にsplit_to_stringみたいな名前でString返すようにしたりはするけど
自分の場合、どっちかっていうとパフォーマンス云々より関数名から内部でアロケーションが連想されるかどうかを重視してる気はする
109:デフォルトの名無しさん
24/02/03 11:24:32.59 e0i4PPZm.net
rustでwebアプリなんてコストかかりすぎでは？ふつーにgoかjava/kotlinかc#で作ればいいじゃん
110:デフォルトの名無しさん
24/02/03 11:28:03.29 26gTKyDM.net
>>104
ないでしょ
少なくともその関数側で判断できるものではない
帰ってきた文字列をどうするかは使う側が決める
これはrustに限った話ではなくプログラミングのお作法の話
文字列を変更したいという意図で所有権を持った文字列を作りたいならto_ownedすべきだし
そうでないならライフタイムを意識してそのまま使えばよろしい
C/C++でも全く同じ話よ
C++ならstring_viewを返す
そこであえてstringを返す意味はライブラリ提供者側にはない
例えば10000回のループの中でそのような関数が呼ばれたらどうなるか？
恐ろしいことになる
C/C++だと常にそういうことを考えてる
pythonとかだと全部stringだから意識してないのだろうけどさ
本来は意味のないアロケーションであることが多い
111:デフォルトの名無しさん
24/02/03 11:32:33.77 XsYnyWq4.net
>>107
大量であっても&strのままでよいものはString化しない
String化が避けられない場合でも大量ならばイテレータで処理してるはずなので.into()の数は少ないはず
いずれの場合でも関数は&strを返せばすむ
112:デフォルトの名無しさん
24/02/03 11:33:55.72 AHA4uyfa.net
正しいことが必ずしも正義とはならない、とだけ言っとくわ
113:デフォルトの名無しさん
24/02/03 11:36:04.38 XsYnyWq4.net
>>108
RustでWebは容易かつ向いている
Rustの公式アンケート世界調査でも最多利用はWeb分野
114:デフォルトの名無しさん
24/02/03 11:47:22.41 TZcb9n30.net
rustあんま使ってない人だけど、strはImmutableでstringはMutableなんでしょ？
文字列配列を柔軟に扱いたいときだけstringで色々して、データを受け渡しするときは当然strを使うのがモラルってもんでしょ
immutable_stringはよく知らん
115:デフォルトの名無しさん
24/02/03 11:50:08.77 3gDommQf.net
今現在Rustが実際に多く使われてる分野って、スクリプト言語の下まわり、ライブラリ高速化だよね
だからそれはWeb用だと言われたらまぁそう
116:デフォルトの名無しさん
24/02/03 11:51:38.36 gN1hlXLs.net
>>112
108だけどそれはasm.jsの代替のwebアセンブリってやつをrustでやってるんでしょ
webアプリとは違うねん
117:デフォルトの名無しさん
24/02/03 11:53:33.66 gN1hlXLs.net
単なるWebサイトの演算処理の補助用途とWebアプリ用途を一緒にしてほしくない
全然違うねん
118:デフォルトの名無しさん
24/02/03 12:03:32.16 XsYnyWq4.net
>>115
Rustの利用で最も多いのは
Webサーバーサイド・バックエンド・クラウド
URLﾘﾝｸ(gihyo.jp)
>>116
Webアプリのサーバーサイドとして使われています
119:名無しさん
24/02/03 12:09:03.48 3gDommQf.net
>>117
スクリプト言語のライブラリとしてRust使ってる人はそんなアンケートに答えないし
自分がRust使ってる自覚もないよ
120:デフォルトの名無しさん
24/02/03 12:13:31.67 KLdOqrmk.net
rust開発チーム直々の調査結果なんね
ちゃんとぎひょう記事urlも貼ってくれ
URLﾘﾝｸ(gihyo.jp)
121:デフォルトの名無しさん
24/02/03 12:17:34.02 XsYnyWq4.net
>>118
Rustで何を開発しているか？だからそれら別言語の人は関係ない
PythonやJavaScriptなどのライブラリが最近はRustで書かれることが増えたが
その開発者たちもRust利用者全体から見れば少数
一番多いのはWebのサーバーサイド・バックエンド・クラウド
122:デフォルトの名無しさん
24/02/03 12:35:09.79 VMbwu+xF.net
WASMはRustに限らずそんなに大っぴらに普及しないと思う
ゲームエンジンかエンコーダーデコーダーくらいにしか需要がない
GUIとしてのWASMはDOM操作を直接できない時点でゲーム操作用途にしか使えないゴミ、終わっとる
123:デフォルトの名無しさん
24/02/03 12:55:06.68 S1lIKTmM.net
wasmは触ってみりゃ分かるけどjavascriptの演算処理を単にrustで書いてコンパイルしてみると、rustのstdがバイナリに同梱されるせいで移植前のスクリプト状態よりファイルサイズが増加するんだよね
wasmテキスト形式で書くかstdレスなrustで書かなくちゃ本末転倒になる
まあファイルサイズが増加してでも演算処理を高速化したいならいいんだろうけど俺は吐いた
124:デフォルトの名無しさん
24/02/03 13:12:09.54 py1fYTT7.net
>>117
組み込みシステム開発者なんていう有能が溢れるほどいるわけないし妥当な結果ね
にしてもRustがサーバー開発でこんなに占めてるんだねえ
125:デフォルトの名無しさん
24/02/03 13:17:12.24 5inMqUOs.net
>>121
WASMはWebブラウ�
126:U内用途だけではないよ CDNエッジでの利用も増えているね WASIなどによる拡張でできることは無数に増えてく >>122 stdは無くてもRustは機能するようにできているよ 例えばスライスやstrはcoreにあるし VecやStringはallocにあるよ
127:デフォルトの名無しさん
24/02/03 13:45:54.96 KLdOqrmk.net
WASIはモバイルOSあるいはデスクトップOS業界がどう動くかだね
wasmerみたいなWASIランタイムをOSが標準装備してくれるなら、WASIの注目度が上がるし、OSに依らないアプリを手軽に作れる
特にモバイルOSではランタイム同梱によるアプリの肥大化を阻止できる
WASIは今のままではJVMのようにマルチプラットフォームなランタイムの上で動くアプリでしかないから、どっかの有名なプラットフォームが積極的に土台として採用しないと忘れ去られる
UnityでもAndroidでもどこでもいい
128:デフォルトの名無しさん
24/02/03 14:00:52.18 KLdOqrmk.net
まあ数日前にWASI 0.2.0の仕様が確定したばっかだから時期尚早と言われればそのとおりなんだが
WebAssemblyを進化させる「WASI Preview 2」が安定版に到達。OSや言語に依存しないコンポーネントモデルを実現
URLﾘﾝｸ(www.publickey1.jp)
129:デフォルトの名無しさん
24/02/03 14:54:43.97 Xm89AN74.net
wasm,wasiはコンテナ界隈とかも期待はしてるようだけど確かにまだ早い。
130:デフォルトの名無しさん
24/02/03 15:14:19.35 nibYeb0/.net
あ、俺みたいに用意されたものを使う的な人間の場合ね。
131:デフォルトの名無しさん
24/02/03 15:32:51.57 8/wI1v6d.net
重さが気になるほどの人気サイト作ってから言えよな。。クソしょーもねーわ。
132:デフォルトの名無しさん
24/02/03 18:14:49.92 X6BgdPzu.net
wasmはブラウザでffmpeg動かすときに使ったことある
133:デフォルトの名無しさん
24/02/03 20:39:34.60 em0HMTKL.net
rustはもっとC#みたいなクラスの書き方が出来れば最高なのになー
134:デフォルトの名無しさん
24/02/03 20:58:14.42 JrVgBiwL.net
>>131
クラスはプログラミング言語の歴史では大失敗作と言われていて
モダンな新言語(Rust, Go, Zig, Nim, etc.)ではいずれもクラスを排除している
既存のクラスのある言語でもカプセル化以外のクラスの機能は使わずにインターフェース等を使うことが推奨されている
Rustのtraitはその中でも最も優れたものなのでRustで困ることはないよ
135:デフォルトの名無しさん
24/02/03 21:06:51.84 93RdYvh2.net
Rustはtraitのドキュメント見た時に
とっ散らかって見えるんだよなぁ
136:デフォルトの名無しさん
24/02/03 21:20:55.82 Uoo5j+2b.net
何事もタダでは手に入らない
良い面だけしか見ない人はいつまで経っても素人
137:デフォルトの名無しさん
24/02/03 21:29:31.74 W4j87Z5e.net
本当にいいの？僕は…黒人だよ？
138:デフォルトの名無しさん
24/02/03 22:04:08.76 OoEMTWx+.net
クラス排除はJavaの生みの親ですら主張しているほどプログラミング言語界での共通認識
＞以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
＞すばらしいQ&Aセッションの途中に、こんな質問が出ました。
＞「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
＞答えは「クラスを除外するでしょうね」というものでした。
＞笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく�
139:ﾀ装継承(extendsの関係)なのだということでした。 ＞インターフェースによる継承（implementsの関係）のほうが望ましいのです。 ＞できる限り実装継承は避けたほうがよいでしょう。
140:デフォルトの名無しさん
24/02/03 23:17:23.21 g7D12qls.net
クラスを排除した代わりにRustでは実装継承の実現に4種類もの異なる方法が導入されている
もちろんGoでもNimでもクラスとは違う形で実装継承が実現されている
にもかかわらず物事の表面しか見ない人はそれに気づけないし今でも実装継承が絶対悪だと信じて疑わない
これが所謂バカの壁
141:デフォルトの名無しさん
24/02/03 23:26:38.80 9NPgrYKr.net
>>137
Rustに実装継承はないよ
どのやり方でも必ず委譲が発生する健全な方法を採っていて実装継承の問題を排除している
142:デフォルトの名無しさん
24/02/03 23:35:45.23 EvhZrc0+.net
クラスが悪いのか継承とかの機能が悪いのか
143:デフォルトの名無しさん
24/02/03 23:45:39.46 1FnNRIIs.net
大雑把に クラス＝カプセル化＋実装継承
よくないのは実装継承
カプセル化だけなら構造体の範囲内
つまり実装継承を伴うクラス自体が要らないというのがモダン言語
144:デフォルトの名無しさん
24/02/04 00:25:24.84 gRgK5+vi.net
Kotlinのsealed interfaceはマジで超使いやすい
145:デフォルトの名無しさん
24/02/04 00:27:54.98 woXOEkq4.net
Rocketってフレームワーク試してみたんだけどこれホストを127.0.0.1以外にできないんかな
なんかハードコーディングでlocalhost指定になってる気がしないでもない
146:デフォルトの名無しさん
24/02/04 00:33:31.21 iIxOCdCp.net
そのRocketというフレームワークは使ったことないが、GitHubレポジトリで「127.0.0.1」で検索したら、
URLﾘﾝｸ(github.com)
exampleでなんか設定ファイルでadressを指定してるけどこれは違うの？
URLﾘﾝｸ(github.com)
繰り返すがRocketというフレームワークは使ったことないので悪しからず
147:デフォルトの名無しさん
24/02/04 00:59:56.12 woXOEkq4.net
その辺grep置換で全部置き換えたけどダメだった
core\lib\src\listener\endpoint.rs にある
Endpoint::Tcp(TcpAddr::new(Ipv4Addr::LOCALHOST.into(), 8000))
がそれっぽくはあるけどどう書き換えたもんか
148:デフォルトの名無しさん
24/02/04 02:04:25.32 1c78Jpm9.net
URLﾘﾝｸ(rocket.rs)
読んだ感じだとRocket.tomlって設定ファイルで指定するのが簡単みたい
下の方にプログラムで設定する方法も書いてあるけど
こういうフレームワーク系はプロキシサーバーの裏側で動かすのが理想かもしれない
149:デフォルトの名無しさん
24/02/04 03:52:57.49 58NiwoAK.net
Rustを書けるようになると、C/C++でも行儀よく実装できるようになるから
するとドキュメントの充実しているC/ C++でいいかとなりそう
150:デフォルトの名無しさん
24/02/04 05:28:12.54 Qwt1SmMN.net
>>105
Python信者か？ 富豪プログラミングでもRustの方が書きやすいが
151:デフォルトの名無しさん
24/02/04 07:20:12.68 IOFBpciC.net
動的型付けのPythonは論外でプログラミングには向いておらずスクリプトを書く程度に使う言語
静的型付けの言語の中では過去の様々な問題点を踏まえて洗練された設計となっているRustがプログラミングに最適
>>146
それはない
例えば今では必須な非同期プログラミングでもC++は出遅れていて使いにくいだけでなくRustのtokioに相当する基盤もない
152:デフォルトの名無しさん
24/02/04 08:23:06.79 Iky4lKs4.net
>>146
ドキュメントの数は多いけど、自動生成もない時代のが多くてソースコードと乖離してたり
古いLinuxディストリ前提だったりして役に立たない率がめちゃ高いんだよな
ドキュメンテーションテストとかdocs.rsとかそういう仕組がちゃんとしてるのに慣れると
わざわざ古代の遺物的なのを発掘しに行く気にはなれない
153:デフォルトの名無しさん
24/02/04 08:29:53.11 qR3d7cra.net
Cは構わないけど、C++はあり得ない
絶対に二度と触りたくないし、積極的に見たくもない
154:デフォルトの名無しさん
24/02/04 08:46:56.47 gRgK5+vi.net
Cにdeferが来たら、もうC++を触らなくてよくなるんだ🥰
…C23でのdeferの実装、見送られたけどね
155:デフォルトの名無しさん
24/02/04 09:04:42.24 gRgK5+vi.net
ああ、zigを本番環境で使いたいなあ
156:デフォルトの名無しさん
24/02/04 10:02:40.29 woXOEkq4.net
>>145
それもやったけど変わらなかった
まぁver0.xだし正式リリースになったらもうちょいマシになるんだろうから
今はまだ使い時じゃないって事で
157:デフォルトの名無しさん
24/02/04 10:56:28.64 Iky4lKs4.net
>>153
これでなんの問題もなく動いたけど…
#[launch]
fn rocket() -> _ {
let config = rocket::Config {
port: 7777,
address: std::net::Ipv4Addr::new(0, 0, 0, 0).into(),
..rocket::Config::default()
};
rocket::custom(&config).mount("/", routes![index])
}
158:デフォルトの名無しさん
24/02/04 11:21:21.48 lyxub88e.net
>>146
自分で書く分ではどっちでも。
でもお前の職場のプログラミングセンス無いやつにもc/c++で書いてて欲しいと思う？
159:デフォルトの名無しさん
24/02/04 11:36:41.94 BT7dzCU3.net
>>153
rocketを使う理由が特にあるわけではないならば
一番ダウンロード数も多くRustで本流のaxumを使うといいよ
URLﾘﾝｸ(github.com)
このURLを見てもわかるようにtokio開発チームが直接手掛けているWebアプリフレームワーク
160:デフォルトの名無しさん
24/02/04 12:24:56.19 RfkvOVf2.net
>>148
それはあなたの主観だよ
世界中で流行っているpythonをそのように評価をすること自体がナンセンスだとは思わないか？
161:デフォルトの名無しさん
24/02/04 12:55:23.59 twXVw8X/.net
>>157
前にも書いたけど例えばPythonのDjangoは遅い
PythonがRustに勝ってる点はローコストでコーディングできる、それのみ
学習コスト、開発時間などを投資できるならRustのようなlow-levelな言語を用いた製品のほうがコンピュータに優しいのは既知の事実
162:デフォルトの名無しさん
24/02/04 13:07:03.82 BT7dzCU3.net
>>157
Pythonでプログラミングを実際にすればわかるけど
ある程度の大きさのものを作るには開発デバッグ効率が非常に悪いね
数ある諸言語と比べてもPythonのメリットは普及していること以外には何も無いかと
163:デフォルトの名無しさん
24/02/04 13:22:50.87 RfkvOVf2.net
>>158
つまりpythonはプログラミングに向いていないというのは間違いということで良い？
>>159
そうは思わないな
開発ツールやエディタが進化してるから差は感じない
164:デフォルトの名無しさん
24/02/04 13:45:38.68 gf/EWl58.net
インタプリタ言語はプログラミングに値しないってか？流石に言いすぎだぞ
うちの小学生の子どもにScratchをプログラミング学習として遊ばせてるけど、そのScratchもれっきとしたプログラミング言語だし
165:デフォルトの名無しさん
24/02/04 13:54:00.15 qLwuX6da.net
>>147
メモリ管理をランタイムに任せることを富豪的プログラミングというのでは？書き易さなんて単に個人の言語の習得度の差でしかない
166:デフォルトの名無しさん
24/02/04 14:07:26.71 vIcGZtFX.net
お前のDjangoは遅い？ならサーバーのスペックを10倍にしろやゴラァ
ってのが富豪的プログラミングの理念ね
167:デフォルトの名無しさん
24/02/04 16:31:03.43 ZDSbtwdo.net
Rustと比べるとPythonはプログラミングに向いていない
スクリプト程度ではなく普通にある程度の規模があるプログラムを対象とする
168:デフォルトの名無しさん
24/02/04 16:54:18.26 lyxub88e.net
特定領域の話と一般論をごっちゃにしてるやつ多いな。
169:デフォルトの名無しさん
24/02/04 16:54:55.07 RSs6aSR/.net
実際にPythonで書くと実行時デバッグがどうしても多くなるね
後から機能追加したりリファクタリングしたりする時も再び実行時デバッグに陥りやすいね
その点Rustは静的型付けであるだけでなくデータ競合もコンパイル時点で防いでくれるから優れているね
170:デフォルトの名無しさん
24/02/04 16:55:36.99 3vZBpwTn.net
>>162
文脈的に文字列を無駄にヒープに置いただけで富豪扱いなんだよな
あと習熟度に依存するのはそれはそうなんだけど、Pythonに習熟した人間ほどRustの方が書きやすいという傾向がある気がする
少なくとも俺の身の回りではそう
171:デフォルトの名無しさん
24/02/04 17:00:11.71 p+8ZNFQ1.net
書きやすかろうが何だろうがユーザ数が全てやろ
Rustは流行ってない それだけは確か
172:デフォルトの名無しさん
24/02/04 17:01:42.98 3vZBpwTn.net
ユーザー数が全てはまあそれはそう
173:デフォルトの名無しさん
24/02/04 17:06:47.57 ktccjMxJ.net
そこは単純な話だろう
PythonとRustの両方をそこそこ使いこなせる人たちに
どちらの言語でも開発可能な領域の案件をどちらで開発したいか尋ねる
100%の人たちがRustで開発したいと答える
つまりPythonは劣った言語
174:デフォルトの名無しさん
24/02/04 17:07:47.85 3vZBpwTn.net
Pythonにも確かに良い所があって、Qiitaの記事が多いから入門が簡単
175:デフォルトの名無しさん
24/02/04 17:11:51.24 p+8ZNFQ1.net
そもそもお前らの勘違いはpythonを取り上げてること
寧ろ比較するというかライバルはJavaScriptだぞ
バックグラウンドや速度求められる所でも使われてる
実際にJavaScriptは以外とは失礼かもだけど高速だしな
176:デフォルトの名無しさん
24/02/04 17:14:25.77 RfkvOVf2.net
>>172
ライバルがJavaScript()
177:デフォルトの名無しさん
24/02/04 17:15:47.77 p+8ZNFQ1.net
>>170
何でワザと複雑化させるの？
ユーザ数って言う最もシンプルなので良い
いざ開発で人集めたらRust出来る人が居ませんでした
居ても単価がバカ高い人でした
pythonならこちらが選び放題で報酬も安く済みます
どう考えてもpython優位だよね
言語が劣ってるとか優秀とか関係無い
目的のシステムが短期間で安く作れるかどうか
でもってそれが出来るのが優秀な言語
178:デフォルトの名無しさん
24/02/04 17:20:38.23 ktccjMxJ.net
>>172
バックエンドではJavaScriptは遅い
フロントエンドのDOMアクセスはJavaScriptでしかできないため使わざるをえない
DOMアクセスを頻繁に伴わない処理ならばWasmが圧倒的に速くJavaScriptは遅い
179:デフォルトの名無しさん
24/02/04 17:26:06.18 ZDSbtwdo.net
>>174
それはPythonしか知らないプログラマーが多いだけでどうでもいい話だな
両方を使えるプログラマーはRustを選ぶからプログラミング言語の優劣ははっきりしている
180:デフォルトの名無しさん
24/02/04 17:32:07.47 3vZBpwTn.net
単価の話し始めたらまだPythonよりJavaの方が優位そう
181:デフォルトの名無しさん
24/02/04 17:33:28.37 p+8ZNFQ1.net
>>176
両方というかRustのユーザ数が少ないから人が集まらないって話してるのにバカなのかなw
182:デフォルトの名無しさん
24/02/04 17:35:51.36 3vZBpwTn.net
目的の設定からコーティングまで自分でやらないといけない局面があって、そういう時に良いんだよな。Rust。
仕事が定型化されていたり、専門知識が要らなかったりして外注出来るならJavaで良さそう
183:デフォルトの名無しさん
24/02/04 17:44:55.37 kqDQxPDl.net
開発保守効率の良さ Rust＞Python
実行速度や省メモリ Rust＞Python
この状況でPythonの方が優れてると主張してるやつはスレ荒らししたいだけだろうからここから出ていきなさい
専用スレへどうぞ
Rustアンチスレ
ｽﾚﾘﾝｸ(tech板)
184:デフォルトの名無しさん
24/02/04 18:05:48.16 gRgK5+vi.net
ユーザー数が全てと言うならJavaが最強って話をしたくなってくる
185:デフォルトの名無しさん
24/02/04 18:27:51.72 p+8ZNFQ1.net
そういう話じゃ無いんだよなぁ
Rust使いたいなら流行らせてユーザ数増やすしか無い
他の言語と比較して云々を語る暇があるならライブラリ作って充実させて流行らせる努力すれば良い
186:デフォルトの名無しさん
24/02/04 18:38:38.86 JoIfCUOf.net
>>180
分野によって変わるし一概にそうとは言えんよ
例えば機械学習の分野でRustを使うメリットはゼロ
開発保守性に関しても速度的にも利便性的にもツールチェインの連携にしても
今や汎用言語は以前に比べると遥かに有用性は低くなってる
だからrustが流行り切らないのだと分析してる
一昔前なら一斉に移ってたと思うよ
187:デフォルトの名無しさん
24/02/04 18:55:04.87 h39TGQDK.net
>>183
本気で言ってるなら常識を疑う
機械学習分野は各社の競争が激しくて記述言語はC/C++/Rust
Pythonはライブラリ呼び出しスクリプトに使われることがあるだけの存在
188:デフォルトの名無しさん
24/02/04 18:55:55.93 gRgK5+vi.net
>>183
あの、機械学習はプログラミングじゃないとは言わないけど分類としてはデータサイエンスだからな？😅数学系だからな？あんだすたん？
機械学習は理論がメイン、プログラミングはただの手段
189:デフォルトの名無しさん
24/02/04 18:59:22.83 gRgK5+vi.net
libtorchとかてんさーふろーの実装の話ならオープンソースを見ればわかるがC/C++やで
演算処理がメイン機能なんだから当たり前だよね
190:デフォルトの名無しさん
24/02/04 19:01:58.80 gRgK5+vi.net
Rustはサーバー系、組み込み系が用途なのに、
Pythonのが優秀だのなんだの言うのいい加減に鬱陶しいぞ
191:デフォルトの名無しさん
24/02/04 19:04:22.03 woXOEkq4.net
Pythonとか他の言語が分かれば数時間の勉強であとか感覚で読み書きできる言語だけど
Rustはそうはいかんと思うし
優れた言語と手軽に習得できる言語って比べても仕方ないと思う
192:デフォルトの名無しさん
24/02/04 19:13:30.94 gRgK5+vi.net
言い方が悪かったかな
Pythonはさ、演算結果を得るために使うものであって、サーバーや組み込みのような常時駆動するようなものには向かないんですよ
考えてみなよ、お手軽さを求めるときは大抵は結果を求めたいときだろ？
numpyの行列計算がお手軽で便利～ってのと一緒だろ？
193:デフォルトの名無しさん
24/02/04 19:17:47.24 JoIfCUOf.net
>>184
それを言えばpytorchのラッパーがrustにあるから同じ存在だよ
194:デフォルトの名無しさん
24/02/04 19:18:07.74 VbPJH2i6.net
Pythonにキレててｸｶ
195:デフォルトの名無しさん
24/02/04 19:18:31.47 JoIfCUOf.net
>>189
じゃあrustじゃなくCで良いって話になるけど
196:デフォルトの名無しさん
24/02/04 19:24:46.98 gRgK5+vi.net
>>192
俺、1度目もRustじゃないとダメだとか言ったか？
俺の意見はちゃんとサーバー、組み込みに適した言語、Java、Kotlin（大好き）、C#、Go、C、C++（きらい）、Rust、Zig（流行ってほしい）を使えってこと
PythonやRubyをサーバーや組み込みに使ってほしくない
197:デフォルトの名無しさん
24/02/04 19:30:56.06 gRgK5+vi.net
あと機械学習の話が出てきたから追加で言うけど、演算処理するなら、極力オーバーヘッドを減らしたいわけで、ガべコレなんていう敵はいないほうがいいわけだから、C/C++/Rustを実装言語に使う
俺ら末端ユーザーが演算処理装置の実装なんてする機会がないからどうでもいい話だけど
198:デフォルトの名無しさん
24/02/04 19:37:05.95 3vZBpwTn.net
機械学習でガベコレが気になるってかなりアプリケーションよりっぽい感じがするな
実装コストとかより推論速度が重要という人間が出てきたのを見ると、機械学習もここまで来たんだなあって感慨深くなる
199:デフォルトの名無しさん
24/02/04 19:42:57.90 ccceg+j6.net
pythonの使われ方は1番にデータサイエンスとして、2番にプログラミング学習のお手本言語として、3番にシェルスクリプトの代替として。
実装言語としては使われてないよ。
200:デフォルトの名無しさん
24/02/04 19:46:45.59 gRgK5+vi.net
>>195
逆に聞きたいんだけど、ただ単に線形代数の計算がしたいだけなのに、ガべコレいるの？
201:デフォルトの名無しさん
24/02/04 19:49:37.34 gRgK5+vi.net
昔からあるeigen使っても機械学習できるし
202:デフォルトの名無しさん
24/02/04 19:53:25.16 woXOEkq4.net
言語として普及させるならやっぱ母数的にはまずWebのバックエンドだろうけど
それならそれでフルスタックフレームワーク欲しいところなんだよなあ
MoonZoonってのがヒットするけどあんまドキュメントが充実してないな
203:デフォルトの名無しさん
24/02/04 19:54:33.10 3vZBpwTn.net
>>197
いるかいらないかで言えばいらないけど、実行時間のほとんどは線形代数演算だからガベコレの時間は誤差だし、高速化したいならモデルをチューニングする方がはるかに効果が大きいので誰もガベコレなんか気にしていないという時代が長かった印象
204:デフォルトの名無しさん
24/02/04 19:55:05.28 JoIfCUOf.net
いつのまにか実装言語の話に流れてるけど
そういう議論はしてないからな
205:デフォルトの名無しさん
24/02/04 19:55:34.23 yS+PPAz5.net
ここはRustのスレです
開発プログラミング言語として劣っているPythonの話題は他所でしてください
206:デフォルトの名無しさん
24/02/04 19:56:07.95 JoIfCUOf.net
機械学習で得たモデルを組み込みデバイスで使いたいってことなんじゃない？
それもう機械学習を終えて、ただのアプリの設計と実装な気がするけど笑
207:デフォルトの名無しさん
24/02/04 19:59:28.23 JoIfCUOf.net
どれもダメ
pythonに勝てる理由にはなってない
実装言語の話をしたいならC/C++で良いし現状そうなってる事実は覆らない
速度だけ欲しいならrustはいらない
208:デフォルトの名無しさん
24/02/04 20:00:34.78 gRgK5+vi.net
>>200
それはそう
行列演算ライブラリがC/C++ばっかなのはたまたまだとも言える
209:デフォルトの名無しさん
24/02/04 20:02:02.46 gRgK5+vi.net
>>201
このスレはRustスレなんだから実装の話になるのは当たり前だろ
データサイエンスの話がしたいなら他所に行ってくれ
210:デフォルトの名無しさん
24/02/04 20:03:49.73 woXOEkq4.net
MoonZoonってfront/backを一括で開発するBlazorみたいな感じか
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(zenn.dev)
211:デフォルトの名無しさん
24/02/04 20:06:59.78 uCVo+TKx.net
>>206
じゃあこういう視点から聞くが下回りがrustの機械学習ライブラリはありますか？
212:デフォルトの名無しさん
24/02/04 20:11:29.25 gRgK5+vi.net
>>204
Rustを組み込み業界が推してる理由はセキュリティ、メモリ安全の観点でRustがC/C++より優秀っていう理由
実際にカーネルはRustにマイグレーションされはじめてるでしょ
Rustがサーバー用途で使われだしてるのはtokio等のRustライブラリ、Webフレームワークが優秀なおかげでJavaのSpringBootのような有名どころに機能面でそこまで劣らず使えて、省メモリ高速に使えるから
213:デフォルトの名無しさん
24/02/04 20:16:35.93 woXOEkq4.net
>>209
そういやJVM使うから同じゲーム動かすにしてもAndroidはｉPhoneよりメモリとかのハード要件上がるとか言われてたな
214:デフォルトの名無しさん
24/02/04 20:16:54.38 JoIfCUOf.net
>>209
少なくとも下回り使う分にはそのような要求は必要ないと思うが
rustであってもunsafeだらけになるよ
非同期ライブラリに関してはpythonもasyncioというtokioに勝るとも劣らないつよつよライブラリがある
よってその点でも不足はない
Webフレームワークに関しては言わずもがな
215:デフォルトの名無しさん
24/02/04 20:17:19.77 gRgK5+vi.net
>>208
だからなんでそんなにデータサイエンスの話をしたがるの？
ライブラリ？libtorchのrustラッパーでコード書いてコンパイルすりゃいいだけやんか頭悪すぎでは？
機械学習は演算処理して類似度を求める作業なんだからコンパイルなんて手間かけずにスクリプト言語でやったほうが手軽だろうが
長時間動作させたいサーバーや組み込みとはわけが違う
インタプリタ言語とコンパイル言語の使い分けもできないの？
216:デフォルトの名無しさん
24/02/04 20:22:45.50 woXOEkq4.net
負けず嫌いが多いのか知らんが相手にするから居付くんやで
217:デフォルトの名無しさん
24/02/04 20:24:07.63 gRgK5+vi.net
>>211
システムコール書くんだからそらunsafeだらけになるわな
逆に言えばそのシステムコールまわりの部分さえ厳重に書けばいいじゃんか
Webフレームワークでインタプリタ言語を使うのは、上で言われてた典型的な富豪的プログラミングだよね>>163
サーバーに重課金できるならPythonでどうぞ実装やってください
ふつうの神経を持ってたら少なくともJavaとかC#とかGoとかをサーバーに使うと思う
218:デフォルトの名無しさん
24/02/04 20:24:27.23 JoIfCUOf.net
>>212
いやそもそもの議論の出発点が「機械学習においてはpythonがrustより優れている」というところだからでしょ
219:デフォルトの名無しさん
24/02/04 20:28:31.70 gRgK5+vi.net
>>215
機械学習はプログラミングじゃないとは言わないがデータサイエンスの分野だよ（2回目）
だから「機械学習においてPythonがRustより優れてる」がそもそもおかしい
Rustはデータサイエンスをやる言語ではない
220:デフォルトの名無しさん
24/02/04 20:28:47.77 tlFdYVQb.net
>>208
【機械学習 by Rust】
・autumnai/leaf — Open Machine Intelligence framework.. Abandoned project. The most updated fork is spearow/juice.
・burn - A Flexible and Comprehensive Deep Learning Framework in Rust.
・coreylowman/dfdx — CUDA accelearted machine learning framework that leverages many of Rust's unique features. Crates.io
・huggingface/candle - a minimalist ML framework with a focus on easiness of use and on performance (including GPU support)
・huggingface/tokenizers - Hugging Face's tokenizers for modern NLP pipelines written in Rust (original implementation) with bindings for Python. Build Status
・LaurentMazare/tch-rs — Rust language bindings for PyTorch.
・maciejkula/rustlearn — Machine learning crate for Rust. Circle CI
・rust-ml/linfa — Machine learning framework.
・smartcorelib/smartcore — Machine Learning Library In Rust Build Status
・tensorflow/rust — Rust language bindings for TensorFlow.
221:デフォルトの名無しさん
24/02/04 20:31:39.88 JoIfCUOf.net
>>217
いや一覧を出せって意味じゃないぞw
python以上に使われてる例を出せって意味だよ
222:デフォルトの名無しさん
24/02/04 20:32:36.67 JoIfCUOf.net
>>216
そういう逃げはいいから
データサイエンスも普通にプログラミングです
223:デフォルトの名無しさん
24/02/04 20:33:09.36 gRgK5+vi.net
>>219
違います、数学です
224:デフォルトの名無しさん
24/02/04 20:34:08.77 woXOEkq4.net
データサイエンスやるならPythonよりJuliaの方がいいな
225:デフォルトの名無しさん
24/02/04 20:34:15.03 JoIfCUOf.net
結局論破できないんか
じゃあ絡んでくるなよ
機械学習においてはpythonに負けていますでいいだろ
そしてそれはrustがダメということにはならん
何と戦ってるのか
226:デフォルトの名無しさん
24/02/04 20:36:35.51 gRgK5+vi.net
>>222
機械学習の論文読んだことある？プログラミングなんてどうでもいいことは「～のPCスペックでPytorchを用いて実装しました」くらいしか書かれないぞ
227:デフォルトの名無しさん
24/02/04 20:36:58.01 tlFdYVQb.net
>>222
Rustは機械学習のライブラリもRustで書かれているものも多いです
PythonはC/C++依存だから同じ土俵にすら立てないと思います
228:デフォルトの名無しさん
24/02/04 20:37:34.97 JoIfCUOf.net
>>223
いやそれは今関係ないでしょ
229:デフォルトの名無しさん
24/02/04 20:39:06.92 gRgK5+vi.net
>>225
機械学習は理論が大事ということを語る上で関係大アリ�
230:ﾈんだが…
231:デフォルトの名無しさん
24/02/04 20:41:07.00 wL3YnJ62.net
元々学生の勉強用としてPythonが利用されてて、
その学生が勉強の一環で機械学習したことで機械学習用のライブラリが増えた
その過去の資産(遺産？)の上に乗っかって今のAIブームがあるだけ
言語的な優位なんてものはPythonになくて
ただライブラリが充実してるだけの話
232:デフォルトの名無しさん
24/02/04 20:46:55.32 7/eIVGRy.net
機械学習なら†darknet†だよね
233:デフォルトの名無しさん
24/02/04 20:48:06.01 tlFdYVQb.net
Rustで機械学習はRustだけで完結できるアドバンテージもありあります
新たに出て来て必要となる実装ライブラリもRustだけ習得すれば作れます
234:デフォルトの名無しさん
24/02/04 20:56:21.39 gRgK5+vi.net
うーん、機械学習する上で必須となる行列演算ライブラリの実装の話こそRustでやるかやらないかで盛り上がるところなのに、なぜ頑なに機械学習自体を取り上げて話をしてきたのか
理解不能だ
235:デフォルトの名無しさん
24/02/04 21:15:10.60 woXOEkq4.net
そういやJuliaだと行列演算言語単位でサポートしてたな
236:デフォルトの名無しさん
24/02/04 21:22:05.81 wL3YnJ62.net
そもそもの話になるけども
なんでPythonが教育目的で使われたのかって話になる
Pythonはキレイに書くことを強制されるってのもあるけど
電池内蔵とか言われるぐらい標準ライブラリが充実していた
だから学習に利用されやすかった
行列計算も然り
結局ライブラリが充実してたって話に帰結するよ
尤もライブラリの大半はCで書かれてるがね
237:デフォルトの名無しさん
24/02/04 21:24:14.42 wL3YnJ62.net
ちなみにnumpyの開発者も大学生だったんじゃないかな
とにかく欧米の学生はPythonで勉強してたから
Pythonのライブラリは大学生が作ったものが多いよ
238:デフォルトの名無しさん
24/02/04 21:33:51.15 7hkEeikC.net
その昔は perl もライブラリが豊富といわれていたんだがな
perl, ruby, python の中ではオフサイドルールがある分だけ
python の方がプログラムがごちゃごちゃになりにくい
もっとも今となっては自動フォーマッターがあるので
どれで書いてもあまり変わらないが
239:デフォルトの名無しさん
24/02/04 21:44:00.36 MUvkIiW8.net
>>233
>>234
ここはRustスレ
Rustがらみの話以外は別スレでしろ
240:デフォルトの名無しさん
24/02/04 22:16:24.24 3vZBpwTn.net
Rustはプログラム言語の王なのでRustスレではどの言語の話をしても良い
241:デフォルトの名無しさん
24/02/04 22:24:24.75 gRgK5+vi.net
他の言語を知ることでRustの良し悪しが分かる、他の言語を学ぶことは巡り回ってRustの勉強になるって寸法よ
もちろんRustの文法やフレームワークの話題や議論があればそちらを優先すべきね
242:デフォルトの名無しさん
24/02/04 23:02:06.01 FrLSpZU4.net
Rustが『いま』流行ってなくても、Rustの協賛企業らが『無理やり』流行らすから5-10年後には日本でもサーバーサイドにRustを使う企業が増えている
20年後にはLinuxカーネルのRust化がほぼ完了してるだろうよ
243:デフォルトの名無しさん
24/02/04 23:16:12.06 woXOEkq4.net
結局相手にするヤツがいるから居付くわけで
244:デフォルトの名無しさん
24/02/04 23:21:49.89 MUvkIiW8.net
>>238
Rustは「安全かつエコ」という流れが生じつつあるから日本でもそうなる
エコとは他の言語より消費電力を減らしCo2排出量も減ること
245:デフォルトの名無しさん
24/02/04 23:24:52.22 X8VPJ+Rl.net
rustとpythonではなく、tomlとpythonを比較すればいい
スクリプトを追放するたんびにマークアップ言語が増える歴史が繰り返される
246:デフォルトの名無しさん
24/02/04 23:32:42.46 srfzNHU5.net
>>239
相手にしなかったら自演して自分に安価つけ始めるけどな
247:デフォルトの名無しさん
24/02/04 23:55:39.05 gRgK5+vi.net
>>241
tomlはマークアップ言語じゃなくてデータ記述言語
スクリプトうんぬんは知らんが、シリアライズ効率のより良いデータ記述言語を求めるのはいい事だよ
自分のところはjson+gzipで落ち着いてるけど、goでよく使われるprotobufにいずれ移行できればなって考えてる
248:デフォルトの名無しさん
24/02/05 00:06:05.32 xY09uWcV.net
>>230
数値演算ライブラリはC言語で十分な気がする。理由を言語化するのは難しいけど
249:デフォルトの名無しさん
24/02/05 00:06:28.07 8h9X84j9.net
オッやっとるな
250:デフォルトの名無しさん
24/02/05 00:06:30.26 8h9X84j9.net
オッやっとるな
251:デフォルトの名無しさん
24/02/05 00:11:45.07 qpTlAoHG.net
一番向いてるのはミドルウェアとか少数のガチ勢が作ったらいいような部分なんだよな。
だから普及はしない。
252:デフォルトの名無しさん
24/02/05 00:14:26.70 Uc3vGql0.net
>>244
並列処理まわりの仕様をよく検討した上でRustかCかC++のどれを選択するべきとは思うな
253:デフォルトの名無しさん
24/02/05 00:18:35.26 qpTlAoHG.net
アルゴリズム周りなんて共有のオンパレードなのにrustが向いてると思ってるのはちょっと素人感がすごいね。
254:デフォルトの名無しさん
24/02/05 00:25:50.11 Uc3vGql0.net
日本語おかしくなった
並列処理まわりの仕様をよく検討した上でRust、C、C++のうちどれを使うか選ぶべき
個人的には並列処理の安全性の面でRustを使うべきだと思う
255:デフォルトの名無しさん
24/02/05 00:31:12.78 Uc3vGql0.net
まあ実情は演算処理にCUDAを使うだろうからC++で全部設計したほうが都合がいいのかな
難しい
256:デフォルトの名無しさん
24/02/05 00:39:33.82 xSwz3MFP.net
並列処理？tokioの出番だな
257:デフォルトの名無しさん
24/02/05 00:52:01.28 i8NFM5TB.net
機械学習はPython？Rust？いやいや争わずに両方使えばいいじゃん。
Rustを使って機械学習アルゴリズムを実装しPythonから呼び出す: k-meansクラスタリング
URLﾘﾝｸ(zenn.dev)
258:デフォルトの名無しさん
24/02/05 00:57:54.10 Ml8drJRq.net
機械学習だの演算処理だの、いつまでそんなつまらない話をしてるの？
rustはゴミってことで結論が出てるんだけど
259:デフォルトの名無しさん
24/02/05 01:03:32.12 l3kMSpNc.net
荒らしに構うキチガイを追い出したいね
ID:gRgK5+vi → ID:Uc3vGql0 （違ったらごめんね）
260:デフォルトの名無しさん
24/02/05 01:04:43.04 4uXpM/Ax.net
>>253
わざわざ生でunsafeなコードを書かなくてもPyO3とか使えば楽にできるよ
261:デフォルトの名無しさん
24/02/05 03:14:48.13 6VJ4TLXv.net
>>243
Protocol Buffers古いし、MessagePack(古い)やCBORのほうがいいんじゃない？ 使ったことないけど。
262:デフォルトの名無しさん
24/02/05 03:40:05.05 d3c/QlU3.net
Protocol buffersは仕様変更に強いしフォーマットを別ファイルに定義出来るという特徴があるから、msgpackやcbor とは使うべきケースが違いそう
263:デフォルトの名無しさん
24/02/05 06:01:25.37 ip7v+BR3.net
>>247
もちろん少人数ガチ勢による開発もRustが向いてるのはおっしゃる通りだけど
大人数による開発もRust向いてるでしょう
特にC++で次から次に穴の発生が尽きない各大規模プロジェクトたちは作り直しや新規ならRust一択だね
264:デフォルトの名無しさん
24/02/05 06:45:17.21 bXI/bbyn.net
>>247
Rustはサーバーサイドで最もよく使われているっていう調査結果がすでに出ているが>>117,119
265:デフォルトの名無しさん
24/02/05 06:55:14.99 qjaRN2nq.net
>>253
どうでもいいがこの記事では非同期処理ライブラリにtokioじゃなくてrayonを使ってるんだな
気になってぐぐったら「rayonのスレッド プールは、CPU を集中的に使用する作業、つまり大規模なデータ セットの大規模な並列処理向けに設計されています。」らしい
URLﾘﾝｸ(www.reddit.com)
266:デフォルトの名無しさん
24/02/05 07:04:12.02 ip7v+BR3.net
>>261
rayonは非同期を使わない並列に特化した時に速い
tokioは非同期で並行＆並列で万能
267:デフォルトの名無しさん
24/02/05 08:21:40.19 kahA1Glb.net
>>227
なら言語的に優れていてPythonライブラリを使えるNim最強だな。
268:デフォルトの名無しさん
24/02/05 08:36:20.41 ip7v+BR3.net
Rust⇔PythonはPyO3で相互に呼び出せるのでRustだけあれば十分
269:デフォルトの名無しさん
24/02/05 09:57:56.35 3fgxGQeI.net
他の言語スレに乗り込んできて居座るとかやってる事ルビガイジとなんら変わらんっていう
270:デフォルトの名無しさん
24/02/05 12:16:47.03 Uc3vGql0.net
>>263
Nimは速いしCへのトランスパイルも賛否あれど個人的には好き
271:デフォルトの名無しさん
24/02/05 12:56:18.45 WdhGREbJ.net
>>211
お前や俺らがそのunsafe部分を書く。
で職場の他の今動きゃいいってコード書いてる奴らにはunsafe部分は利用させても書かせない。
そういう分け方できるのはメリットじゃないかね。
272:デフォルトの名無しさん
24/02/05 13:02:02.94 WdhGREbJ.net
>>266
同意
273:デフォルトの名無しさん
24/02/05 22:28:07.58 UHwE0rib.net
>>259
もう5年くらいこんなこと言ってる人いるけど一向に普及してないよね。
274:デフォルトの名無しさん
24/02/05 22:40:04.70 5g9amV19.net
>>269
カーネルのRustへのマイグレーションの成果が各所で出てるの知らない？
275:デフォルトの名無しさん
24/02/05 22:49:23.20 dxOzlQzX.net
>>269
AWS SDKにRustが正式登場して、色んなところがRustを触りだしてるぞ
276:デフォルトの名無しさん
24/02/05 23:29:16.62 bm3rzOD2.net
AWSやCloudflareが大規模に使ってるからインターネットのトラフィックの結構な分量をRustが捌いてるはず
この5年でこういう人目には触れないけど基礎的な部分にずいぶん普及したよ
277:デフォルトの名無しさん
24/02/06 00:09:13.25 gR/xoQQt.net
Rust のユーザ規模はもはや小さくはないが仮に小さかったとしても、それが無用のものということを意味するわけではない。
Cobol や Fortran だって一般には化石のような印象を持たれつつも近年にも規格改定などの発展はあるし、それが求められる程度の利用シーンはある。
Lisp がインフラの中に潜んでいたりするし、Caml で書かれたプログラムがあなたがたのパソコンにインストールされていたりするのもそれなりに高い確率でありうる。
普及するっていうのはそれを不必要なところにまで押し付けたいわけじゃないだろう。
278:デフォルトの名無しさん
24/02/06 00:25:40.67 oam+zbbU.net
物を作ってから普及するまでの時間で評価されれば
まだ作ってない物を売るようになったり、評価を信じなくなったりする
279:デフォルトの名無しさん
24/02/06 00:35:44.14 QhlaBKsr.net
>>271
あれすげー使いにくいよ
そもそもがAWSのAPI自体が非同期の作りですぐに返ってくるものばかりだから
ライブラリ側は同期的で良いのにtokio使っちゃってるし
280:デフォルトの名無しさん
24/02/06 00:39:31.81 OWeq/GHS.net
>>272
現在のネットのインフラであるクラウドとCDNがRust製になっていってるから
Rustがネットインフラを支えるようになって来たと言っても過言ではないんだね
281:デフォルトの名無しさん
24/02/06 01:36:56.00 bbDh9Fvv.net
>>275
割と何言ってるかよくわからないので
どのあたりが使いにくいのか詳しく
282:デフォルトの名無しさん
24/02/06 08:02:11.78 TiTcC6K4.net
>>275
javascriptでただの同期functionだったものが非同期のasync awaitに変わった経緯がある
同期functionだとブラウザから呼び出した時に待ち状態がフリーズみたいになって不便だった
283:デフォルトの名無しさん
24/02/06 08:41:24.69 Lhg6cl8R.net
>>275
それはキミの非同期処理に関する知識が欠如してるだけ
284:デフォルトの名無しさん
24/02/06 10:42:58.91 rmP9tpon.net
まあわざわざライブラリ側で非同期にしなくても、必要ならユーザーが勝手に非同期にすればいいってのはあるかもな
285:デフォルトの名無しさん
24/02/06 11:02:01.98 viYUZILO.net
お前らはawait禁止縛りでもしてるの？
286:デフォルトの名無しさん
24/02/06 11:12:37.31 tyBWuvJT.net
tokioの非同期って
async fn、spawn、async、await
を最低限使えればなんも不自由なくね？
同期じゃないといけない理由あんの？
287:デフォルトの名無しさん
24/02/06 11:17:49.52 gR/xoQQt.net
同期的に使うだけの場合でも tokio をリンクするってのが気分よくないというのはわかる。
288:デフォルトの名無しさん
24/02/06 11:19:55.73 g9hJ5hPW.net
>>282
同期じゃないといけない理由？非同期の使い方がわからないからじゃないか？
ちなみにRustがダメだとアンチが言うのはアンチがRustコードのコンパイルを成功できないから
289:デフォルトの名無しさん
24/02/06 11:23:28.54 YZW9kbIH.net
AWS SDKを同期的に使いたいってそれAWS CLIじゃだめなん？w
290:デフォルトの名無しさん
24/02/06 11:25:05.20 BOUvQi0K.net
>>280
そこの今まで独自にそれぞれが用意してた部分を async await 等のAPIとして整理されたことに意義があるんと思う。
291:デフォルトの名無しさん
24/02/06 11:26:18.87 J68o5uRN.net
AWS CLIはcargo installで入ってこないから……
292:デフォルトの名無しさん
24/02/06 11:28:28.70 DRX9b4l9.net
そもそもRustを使う意味がないよね
AWS SDK for Pythonがあるんだから
293:デフォルトの名無しさん
24/02/06 11:28:33.03 J68o5uRN.net
>>286
async awaitへの統合に意義があるのはわかるけど、tokioにまで限定されるのはダルイという気持ちがある
294:デフォルトの名無しさん
24/02/06 11:33:54.88 GPQIFWbx.net
>>289
そこはしょうがないでしょ
tokioはAWSが積極的に支援してるライブラリだからね
URLﾘﾝｸ(tokio.rs)
URLﾘﾝｸ(i.imgur.com)
295:デフォルトの名無しさん
24/02/06 11:35:59.00 J68o5uRN.net
>>290
説教的に支援って資金的な支援じゃなくてAWSがtokioの営業することだったのか……
296:デフォルトの名無しさん
24/02/06 11:38:49.18 GPQIFWbx.net
あ、AWSがtokioを運営してんのか
単なるスポンサーだと思ってた
297:デフォルトの名無しさん
24/02/06 11:40:13.71 J68o5uRN.net
マジか
298:デフォルトの名無しさん
24/02/06 11:42:17.61 4dmbx6OY.net
説教的な支援は5chの担当
299:デフォルトの名無しさん
24/02/06 11:42:20.07 4dmbx6OY.net
説教的な支援は5chの担当
300:デフォルトの名無しさん
24/02/06 11:53:48.52 9gL8Mjmo.net
Rustで非同期やるライブラリって昔からたくさんあるけど最近はtokioしか使ってないや
すごく重い処理があるプロジェクトはtokioとrayonで使い分けてるけどそれでも両方のライブラリをプロジェクトで共存させてる
301:デフォルトの名無しさん
24/02/06 12:09:35.30 eJTRS9Cw.net
非同期と言いつつ出来てない奴って8割いるよね
302:デフォルトの名無しさん
24/02/06 13:54:11.58 oam+zbbU.net
非同期のそのデメリットを消す方法は
まだ作ってないことにしよう
303:デフォルトの名無しさん
24/02/06 14:05:46.01 QhlaBKsr.net
>>277
まずAWSのAPIってのは基本的にすぐ返ってるの
この辺はわかる？
例えばインスタンスを作るAPIってのはインスタンスを作り終わるまでブロックするんじゃなくてインスタンス生成命令を出してすぐに返ってくるわけ
実際にインスタンスが生成完了したかはインスタンスの状態取得APIを使って確認するわけ
だから常に同期的に呼び出しで問題ないの
pythonのboto3ってライブラリが1番使いやすい
304:デフォルトの名無しさん
24/02/06 14:08:10.63 9MgF8+tA.net
Boto3、あんま補完され�
305:ﾈくて馬鹿にはキツい
306:デフォルトの名無しさん
24/02/06 14:39:52.97 HfVCyUAp.net
>>299
AWSが鯖落ちしてたらどーすんの？
307:デフォルトの名無しさん
24/02/06 14:47:03.29 bbDh9Fvv.net
>>299
あなたが何言ってるかわかるけどnodejsでも
似たような使い方だしrust sdkの欠点と言われても
広く同意は得られないんじゃないかなあ
308:デフォルトの名無しさん
24/02/06 14:52:06.28 QhlaBKsr.net
>>302
欠点というか使い方を難しくしてるだけな気がするんだよな
普通にCLIでええやんって思う
309:デフォルトの名無しさん
24/02/06 14:59:31.38 bbDh9Fvv.net
>>303
awsに限らずweb apiのライブラリは
非同期にするのが主流だから
頑張って勉強してねとしか…
310:デフォルトの名無しさん
24/02/06 15:05:27.46 eJTRS9Cw.net
AWSのSDKは.NETのが1番だな
311:デフォルトの名無しさん
24/02/06 16:38:39.75 m1uPeMIU.net
AWS SDK for Rustはsend()がめちゃくちゃダサい
そのうち大幅に改修されるだろうけど
>>299
ネットワークI/Oを同期で書くのはさすがにどうかと
312:デフォルトの名無しさん
24/02/06 16:55:31.82 /Z6uowCt.net
>>300
今から見ると微妙だがCLIと対応がつけやすいし
余計なことはしなくて良いから楽だよ
313:デフォルトの名無しさん
24/02/06 17:04:11.45 /Z6uowCt.net
>>306
どう書くか？はユーザーのユースケースによるからそうとも言えないよ
例えばAzureのCLIは--no-waitというオプションがあり
処理が成功するまで待つか待たないかを決められる
これこそユーザー視点の設計だよ
314:デフォルトの名無しさん
24/02/06 17:08:06.92 8tVnzyvy.net
Google規模の会社が$1 million渡したくらいでわざわざアナウンスするなよな
タイトル詐欺じゃん
Improving Interoperability Between Rust and C++
URLﾘﾝｸ(security.googleblog.com)
315:デフォルトの名無しさん
24/02/06 17:08:19.95 /Z6uowCt.net
非同期を押し付けることはユーザーのメリットにはならない
Rust SDKは作り直して欲しい
316:デフォルトの名無しさん
24/02/06 17:21:49.29 HJO9dxnA.net
prostもblocking版の関数ないのかよってびっくりした記憶があるわ
C#版もPython版もasyncとblockingの両方あるのにな
317:デフォルトの名無しさん
24/02/06 17:23:58.68 pGyPKkef.net
>>299
>>まずAWSのAPIってのは基本的にすぐ返ってるの
>>この辺はわかる？
初心者でもそんなウソはつかないぞ
AWSに限らず任意のサービスに言えるが通信時間がかかる
さらに各サービス内で状態取得だけであっても実行時間がかかる
>>だから常に同期的に呼び出しで問題ないの
本気で言ってる？
通信時間と向こうでの実行時間の間こちらはずっと何もせずに待つわけ？
非同期プログラミングの意味すら理解できていてないのか？
318:デフォルトの名無しさん
24/02/06 17:27:07.44 eJTRS9Cw.net
>>312
コンピューターにとって1秒待つって事がどれだけ長いかを理解してないんだろ
319:デフォルトの名無しさん
24/02/06 17:28:50.84 2AaBK8OM.net
非同期の方が良いことが多いのは同意するが、非同期を押し付けられると「こんなプログラムのためにTokio入れるのかよ」って思ってしまうケースは存在する
320:デフォルトの名無しさん
24/02/06 17:48:41.35 Izyc/wZS.net
API が非同期で設計されてるのに、それを呼び出す側もさらに非同期でハンドリングするのは正直無駄じゃない？
ってのはわりと自然な感想だと思うけどな。
AWS の API なんてクライアント側で並列に呼び出したいユースケースも無いだろ。
バカスカ叩いてもスロットリングされるだけだし。
321:デフォルトの名無しさん
24/02/06 18:00:53.30 eyCZAgqI.net
>>315
APIの向こう側で非同期なのとこちらの処理を
同期か非同期化は関係ないよね
322:デフォルトの名無しさん
24/02/06 18:18:54.67 w99V6zNl.net
それな
無関係ではないけど分けて考えないと
323:デフォルトの名無しさん
24/02/06 18:33:39.13 nmitk2Uo.net
>>308
非同期APIが提供されてれば同期化は簡単にできるから必要ないんだよ
324:デフォルトの名無しさん
24/02/06 18:36:16.19 2AaBK8OM.net
同期化ってasyncでない関数から呼べるようにするって解釈で合ってるだろうか
もしそうだとしたらasyncでない関数の中でtokioランタイム作ってawsよんでruntime終わらせるみたいな処理になっちゃわないか
325:デフォルトの名無しさん
24/02/06 19:56:13.91 kbEH5D0U.net
AWSの同期的APIの機能リクエストあるのね
URLﾘﾝｸ(github.com)
326:デフォルトの名無しさん
24/02/06 20:03:24.75 Dpp0fICO.net
AWSのAPIの呼び出しが非同期になるのはAPIの内部で効率化のために非同期処理をやってるからでしょ？
327:デフォルトの名無しさん
24/02/06 20:17:12.09 7oKTbIPT.net
うちはAWS SDK RustはAxumベースのWebアプリでDynamoDB接続に使ってるけど、みんなはなににAWS SDK使ってるん？
328:デフォルトの名無しさん
24/02/06 20:38:04.56 NQvIuvVx.net
>>312
だからーなーんにもわかってない発言丸出しはやめよ？
通信の時間なんてかからんのやって
すぐ返ってくるから
そこちゃんと読もう？
329:デフォルトの名無しさん
24/02/06 20:44:38.46 NQvIuvVx.net
AWS APIを生のRESTで実装してみろよ
すぐわかるぞ
330:デフォルトの名無しさん
24/02/06 20:45:53.99 NQvIuvVx.net
言っておくが俺は一般論として非同期がダメと言ってるわけじゃないぞ
もちろんその用途としての方が便利なことは多い
あくまでAWS SDKのRust版については不満があるということよ
331:デフォルトの名無しさん
24/02/06 20:50:46.76 dKDdJveN.net
>>325
web apiの実装として相手側が非同期処理で
手元も非同期なんてのはawsだけじゃないというか
それが主流だけど他はいいの？
332:デフォルトの名無しさん
24/02/06 20:50:52.38 2AaBK8OM.net
このスレにはRust関連の悪い所の指摘を見ると自分が全否定されたように怒り出す人間がいるっぽいので
333:デフォルトの名無しさん
24/02/06 20:57:52.50 NQvIuvVx.net
tokioが素晴らしいのは間違いない
しかし今回のREST APIの呼び出しで程度で必要かな？と思う
非同期が必要ならtokio::process::commandでCLIを非同期で呼ぶ方が良くないか？とか色々考えてしまう
334:デフォルトの名無しさん
24/02/06 21:04:51.51 pGyPKkef.net
>>323
>>通信の時間なんてかからんのやって
>>すぐ返ってくるから
呆れた
敢えてウソをついているのか？
それとも本当に無知な初心者なのか？
335:デフォルトの名無しさん
24/02/06 21:08:56.44 rmP9tpon.net
Web通信ですぐ返ってくることなんかあるのか？ と思ったけど、AWSのAIPの中身知らんから何とも言えんくなってしまった
そういえばファイルIOはすぐ返ってくるって言って良いんだろうか
336:デフォルトの名無しさん
24/02/06 21:12:11.34 NQvIuvVx.net
>>330
サイズが小さいファイルに対して非同期呼び出しをするか？という話
337:デフォルトの名無しさん
24/02/06 21:14:41.84 rmP9tpon.net
>>331
まあ「ファイルIOにTokioが必要です」って言われたらちょっと嫌な気分になるな
338:デフォルトの名無しさん
24/02/06 21:15:39.21 pGyPKkef.net
>>330
Web通信は通信時間だけで大きく時間を要する
さらにWebサーバ側で処理時間がかかる
339:デフォルトの名無しさん
24/02/06 21:56:45.71 Z39zy7L3.net
>>323
cpuのナノ秒単位の処理速度に比べたら通信はとてつもなく遅いけど
レスポンスを受け取るまでの時間は処理を中断させたほうがコンピュータに優しい
tokioのグリーンスレッドを活かせ
340:デフォルトの名無しさん
24/02/06 22:05:59.23 wkt5OFgc.net
>>334
tokioのランタイムが裏で動くとか気持ち悪すぎだろ
同期でやらせろ
341:デフォルトの名無しさん
24/02/06 22:13:28.77 IqTcjswh.net
他のSDKのようにv3くらいになれば使いやすくなってるかもね
342:デフォルトの名無しさん
24/02/06 22:16:42.98 GPQIFWbx.net
aws sdk for rust ってwebフレームワークでサーバーサイドやってる人向けだから当然のようにみんなtokioを既に組み込んでるもんじゃないの？なにがそんなに気に入らないのか理解ができない
まあtokio以外の非同期ランタイムを使わせろって人はドンマイだけど
343:デフォルトの名無しさん
24/02/06 22:17:52.75 GPQIFWbx.net
「rustのwebフレームワーク」が抜けてた
344:デフォルトの名無しさん
24/02/06 22:21:16.54 1nslx8NY.net
>>337
そういう話じゃないけど
345:デフォルトの名無しさん
24/02/06 22:24:12.00 DARHuXMe.net
>>337
実装の話に逸らさないで
AWSのAPIくらい同期で十分なのにわざわざ非同期にする理由を言えよ
346:デフォルトの名無しさん
24/02/06 22:24:15.12 UMLcFsAo.net
いくらすぐ返ってくるっていってもネットワーク通信なんだから
不通だったりレイテンシが長くなることはありうるし、
タイムアウトやリトライをtokioのエコシステムに乗っかってやれるメリットはあると思うけどな
そりゃ軽量な同期版があるに越したことはないけど、優先順位は落ちるだろう
347:デフォルトの名無しさん
24/02/06 22:27:24.19 QhlaBKsr.net
JavaScript SDKも内部は非同期だけど使いやすいよ
単なるコールバックで同期的に書けるし
348:デフォルトの名無しさん
24/02/06 22:33:38.08 QhlaBKsr.net
どうも最近tokioがでしゃばってきて気持ちが悪い
ここまできたらもうコアをtokioに入れてWeb用の専用言語としてフォークしたほうがよいのでは？
349:デフォルトの名無しさん
24/02/06 22:35:03.21 GPQIFWbx.net
>>340
はぁ？そんなに同期でやりたいなら同期のある言語のSDKを使うかAWS CLIでコマンド実行しててくれよ
同期同期言ってるやつはRustでAWS触るアプリ作ってねえだろ
こちとらつい先日ようやく待ちに詫びたAWS SDK for Rustが正式版になって、ようやく、ようやくこれを本番投入できるって喜んだのによ
350:デフォルトの名無しさん
24/02/06 22:36:26.88 QhlaBKsr.net
まあ俺はCLI使ってるw
ぶっちゃけコードで書くメリットがわからない
351:デフォルトの名無しさん
24/02/06 22:36:30.11 UMLcFsAo.net
というか同期版もランタイム切り替えも別にissueとしては却下されてるわけじゃないんだし
欲しい人は実装してPR出せばいいんだよ
それがされてないってことは結局需要がないんでは？
352:デフォルトの名無しさん
24/02/06 22:38:18.90 YgjIpfMr.net
>>344
はい、じゃあお前の負けね
もう二度と口答えすんなよ
353:デフォルトの名無しさん
24/02/06 22:40:20.30 QhlaBKsr.net
>>341
不通だろうが普通はソケットのタイムアウト値設定するから許容できる範囲内の値を設定すればよろしい
どちらにしろリトライすることになるのだ
354:デフォルトの名無しさん
24/02/06 22:44:11.89 oodj9UUv.net
「そんなに××したいなら○○使えば良いんじゃないの？ 」→をはい○○使っています」っていう流れ、最強言語たるRustのスレの流れとしてはあまりにも敗北感がある
355:デフォルトの名無しさん
24/02/06 22:50:36.48 QhlaBKsr.net
まとめると
tokio使わない同期API作れ
非同期版はランタイム切り替えできるようにしろ
ってことでオッケー？
356:デフォルトの名無しさん
24/02/06 22:53:13.82 j3cHqQGJ.net
>>340
コンマ1秒～1秒の頻度でデータベースクエリするWebアプリとかだったら非同期のが次々に処理できると思うけど
357:デフォルトの名無しさん
24/02/06 22:56:34.96 LdUhtiaW.net
>>351
なんだそれ？
お前そんなにバカみたいな頻度でAWS APIを使うの？笑うわ
358:デフォルトの名無しさん
24/02/06 22:57:34.03 MUGS3GDn.net
>>351
クエックエッ
笑笑
359:デフォルトの名無しさん
24/02/06 22:58:56.15 QhlaBKsr.net
>>352
それくらいの頻度で呼び出す可能性があるのってGAFAMクラスの会社ぐらいじゃね？w
360:デフォルトの名無しさん
24/02/06 23:04:22.29 JKYjZJJo.net
>>351
ゲームサーバーとかかな？
361:デフォルトの名無しさん
24/02/06 23:06:26.14 6KaTvZBM.net
>>354
それな笑笑
>>351は負けず嫌いの単発の敗者笑笑
362:デフォルトの名無しさん
24/02/06 23:08:14.09 IqTcjswh.net
使ってる用途が違うから噛み合わないんだな
CLIで十分な用途とAPIが必要な用途くらいは区別しようぜ
363:デフォルトの名無しさん
24/02/06 23:08:21.31 1CYgky+r.net
あ、もしかしてガーファ勤めなんかな笑笑？
なわけねえだろ笑笑
364:デフォルトの名無しさん
24/02/06 23:09:19.34 nVMpMpiW.net
ガーファ最強笑笑
365:デフォルトの名無しさん
24/02/06 23:10:22.99 fZ7dPHD5.net
>>351はバカです
366:デフォルトの名無しさん
24/02/06 23:12:04.80 N6+r1oq4.net
>>355
ゲームサーバーってなに？マインクラフトでもやってるの？ガキんちょか？
367:デフォルトの名無しさん
24/02/06 23:15:06.92 aJWngw7a.net
>>357
うるさいな
非同期じゃないといけない理由を具体的に言ってみろよ？あ？
368:デフォルトの名無しさん
24/02/06 23:16:25.72 QhlaBKsr.net
>>351
GAFAM社員age
369:デフォルトの名無しさん
24/02/06 23:26:25.88 qbDsNmRG.net
自分用のツールなら一々tokioとかめんどくさいとか
わからんでもないけどそういう人をターゲットに
してないからなあ
370:デフォルトの名無しさん
24/02/06 23:26:55.98 IqTcjswh.net
GAFAMの規模を舐めすぎだろ
10リクエスト/秒程度なら中堅企業の社内向けシステムでも普通にあるレベル
371:デフォルトの名無しさん
24/02/06 23:35:03.14 O9rpVDxS.net
実際ゲームサーバーって大変そうよね
最近話題になったパルワールドってやつもサーバー要素があるけど、ゲームデータをどこかしらのクラウドサービスをレンタルしてやってるわけで、>>351よりもすごいレベルで行われてそう
パルワールドのサーバーはどの言語のWebフレームワークでやってるのか知らんがJavaとかC#、GoあたりならRustのが高速、省メモリでサーバー代を節約できただろうな
372:デフォルトの名無しさん
24/02/06 23:43:25.52 ZEorkRES.net
ゲームサーバーってプログラミング関係あるの？サーバーを借りてるだけなんじゃないの？
373:デフォルトの名無しさん
24/02/06 23:56:44.33 7jT2HGcX.net
無知は恥ってよくわかるね
374:デフォルトの名無しさん
24/02/07 00:00:36.36 /3r7f4vo.net
>>366
人気ゲームだと桁が3つ4つ違う
375:デフォルトの名無しさん
24/02/07 00:02:07.90 HSCt9mfq.net
>>368
無知自体は何も恥じることではない
376:デフォルトの名無しさん
24/02/07 00:25:18.71 ZYweHa7T.net
まさかゲームサーバーがなんなのかわからない人がこのスレにいるとは