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
まさかゲームサーバーがなんなのかわからない人がこのスレにいるとは
377:デフォルトの名無しさん
24/02/07 00:29:20.89 HhW4UiiT.net
AWSはCLIでいい、非同期はゴミって結論出たね
378:デフォルトの名無しさん
24/02/07 00:41:54.53 O61WTlOm.net
通信時間＋向こうでの処理時間はCPUにとって莫大な待ち時間
async/awaitによる非同期プログラミングをすれば同期と同じようにプログラムを組めつつその莫大な待ち時間を有効活用できる
これは特定のプログラミング言語に関係なく対応しているすべての言語で成り立つ話
もちろんRustでも同じ
379:デフォルトの名無しさん
24/02/07 00:51:24.66 EnTbeTL9.net
AWS Lambdaだと同時実行数の制限があるから、同期処理をするのは犯罪的。
380:デフォルトの名無しさん
24/02/07 00:58:32.65 p1o31ALH.net
現状のasync/awaitの使いやすさは
Swift > C# > JavaScript >>> Rust
381:デフォルトの名無しさん
24/02/07 00:59:45.05 p1o31ALH.net
KotlinやF#は使ったこと無いのでわからない
382:デフォルトの名無しさん
24/02/07 01:07:53.33 p1o31ALH.net
>>375
Python忘れてたわ
Swift > C# > JavaScript/Python >>> Rust
383:デフォルトの名無しさん
24/02/07 01:10:26.42 O61WTlOm.net
>>375
Rustが最もきめ細かく扱えて便利
384:デフォルトの名無しさん
24/02/07 01:13:21.82 O61WTlOm.net
もちろん性能面でもRustが最も有利
だからインフラに至るまで採用されている
385:デフォルトの名無しさん
24/02/07 01:20:07.41 R4SwjTOT.net
>>377
c++は？
386:デフォルトの名無しさん
24/02/07 02:44:08.20 7skGlnTk.net
>>377
swiftってそんなに書きやすいんか？
387:デフォルトの名無しさん
24/02/07 04:57:14.90 uDrK2oQi.net
>>375
asyncもRxもC#が発祥だけどこの言語だけ異常だよな
388:デフォルトの名無しさん
24/02/07 06:30:56.86 EnTbeTL9.net
Pythonはスレッドが擬似的なので並行処理の性能が低い。
389:デフォルトの名無しさん
24/02/07 06:35:55.67 5V24VW//.net
>>375
Kotlinが抜けてる
Kotlin>（越えられない壁）>Swift > C# > JavaScript/Python >>> Rust
390:デフォルトの名無しさん
24/02/07 06:52:43.34 r0kpHnB4.net
Rustを叩きたいだけのアンチさんだから無茶苦茶や
391:デフォルトの名無しさん
24/02/07 07:15:51.00 Z0+c6VxI.net
>>380
C++は論外
アンチではなく本当に書きにくい
さらにtokioのような高性能な基盤も整備されていない
392:デフォルトの名無しさん
24/02/07 07:16:35.05 0B0Tt2Zv.net
非同期はC#GoKotlinRustのどれも同等に使いやすいと感じる
JavaはSpringありき、Swiftはつかったことない、C/C++は考えたくない
393:デフォルトの名無しさん
24/02/07 07:25:44.75 qmafesNd.net
swiftやdartはモバイルアプリ開発以外で全く使われてない
394:デフォルトの名無しさん
24/02/07 07:30:51.78 KVAhvvz+.net
SwiftはApple製ってだけで使う価値なし
開発環境の依存があまりに高すぎる
395:デフォルトの名無しさん
24/02/07 07:38:16.28 2LChEtDL.net
出来ればJVMも使わずに済みたい
なんとなく
396:デフォルトの名無しさん
24/02/07 07:40:43.27 lxo2szIV.net
>>375,377,384
なんか言語のラインナップ見るにバリバリのフロントエンド開発屋さんかな？
そらRustを使うことなんてないわな
なんでこのスレにいるのか
397:デフォルトの名無しさん
24/02/07 07:53:07.34 q5vZGjA+.net
Rustはフロントエンドも取り込むのでRustスレはフロントエンド屋も書き込んで良い
398:デフォルトの名無しさん
24/02/07 08:12:27.93 gKkOyEKn.net
まぁRustの非同期の良いところはランタイムを言語から切り離したので
Webでも組み込みベアメタルでも非同期が使えるところなんだけど
使い勝手としてWebのユースケースに特化した他言語に負けるのはしょうがない
これは時間がたっても根本的には改善されないから
不満があるなら早く他言語に移ったほうがいいよ
399:デフォルトの名無しさん
24/02/07 08:15:11.44 0B0Tt2Zv.net
>>390
ならGoかC#のASP.NETでいんじゃね？
さまざまな導入コストを払えるなら事実上クラウドネイティブ言語のRust一択
それとJVMがダメという理由が、Oracle JVMのLTSサポート期間が短縮されJVMのイメージが悪化したってことに依るものなら、
Kotlin/JVMだとJDK8をベースに、どのJDKバージョンでも動くようにサポートされ続けられるから、JDK8から最新のJDK21までのLTSバージョンで難なく動く
URLﾘﾝｸ(kotlinlang.org)
OracleのJavaは終わってるがJetBrainsのKotlinは無限に始まってる
400:デフォルトの名無しさん
24/02/07 09:03:48.96 7skGlnTk.net
静的言語ではkotlinが個人的には1番かな
コルーチンスコープを作れるから既存の処理の中に非同期を唐突に入れられる
これが理想
ただしクラスありきなのが微妙なところ
クラスなしでkotlinのような使い心地がある言語が欲しい
401:デフォルトの名無しさん
24/02/07 09:09:08.81 oJ2HGwP7.net
>>373
その時間有効に使えるのかって話なんだよ。
例えばRDSを休止したい場合に、休止するAPIを呼んで、状態を確認するAPIで休止を確認してすると思うけど、
そういう処理を自動化する時に非同期でハンドリングする意味あるかっていう。
DynamoDB のデータ操作とか業務トランザクション扱う系は非同期あっていいとは思うけどね。
402:デフォルトの名無しさん
24/02/07 09:21:27.90 +r3v4OXU.net
既存の処理の中に非同期を唐突に入れられるのってランタイムがグローバルで一意じゃないと出来なそう
ランタイムいくらでも作れるし複数種類存在しうるRustでは無理そうね
403:デフォルトの名無しさん
24/02/07 09:33:38.70 3p2K3Rhv.net
>>395
それはRustも同じ
Rustのasyncもコルーチンでありtrait Futureに
404:よって抽象化されている Future::pollの引数であるContextがKotlinでのコルーチンコンテキストに相当する >>397 Rustでも既存の処理に唐突に非同期を取り扱える Rustでtokioのようなランタイムが必要になるのはspawnして完全に制御外へ切り離すときのみ 制御内ならば複数のFutureを取り扱う場合でもjoinなど様々な方法で取り扱うことができる もちろんtokioランタイムは必要ない
405:デフォルトの名無しさん
24/02/07 09:42:26.35 x+YpU8Xz.net
async{}.await
406:デフォルトの名無しさん
24/02/07 09:45:13.70 kuiQPbhX.net
>>380
C++ はその性質上、システムとの連携が必要な標準ライブラリは薄い。
幅広いシステムで実現可能なように配慮するから。
必要ならサードパーティライブラリでやれというスタンス。
ただそこで強力な誰もが認めるサードパーティライブラリが結局は現れなかったというのが C++ のあかんかったところなんやわ。
個人的には C++/WinRT の非同期処理は好きなんだがね。
407:デフォルトの名無しさん
24/02/07 10:36:03.38 0B0Tt2Zv.net
>>395
KotlinはデフォルトでclassがJavaでいうfinal classで定義されてて
・クラス継承禁止
・やってることはCの構造体と同じ
だから、自分はclassであるデメリットを感じてないかな
Kotlinでクラス継承するにはご存知の通りclassをopen classやabstract classと書くから見て分かるのがヨシ
408:デフォルトの名無しさん
24/02/07 10:46:44.24 rJGaKMx5.net
>>396
>その時間有効に使えるのかって話なんだよ。
非同期にすることでawsに関係なく別の処理を同じリソースで走らせられる
もしその時間を有効に使えないような用途なら省リソース高性能とは無縁だからわざわざRustを選ぶ必要ない
409:デフォルトの名無しさん
24/02/07 10:52:51.94 ndvPWcVf.net
なんかプログラミング言語総合スレみたいになってんな
いやちゃんと説明してくれて勉強になるから別にいいんだけど
410:デフォルトの名無しさん
24/02/07 11:05:20.92 tO9J4ky9.net
>>402
Rustはプログラム言語の王だから理由がなくてもRustを使って良い
411:デフォルトの名無しさん
24/02/07 11:12:27.12 dhCR1KyQ.net
>>398
え、tokioランタイム無しで非同期関数呼べるんだ？ 知らんかった
でもクレートの依存は付いてきてビルド遅くなるよね
412:デフォルトの名無しさん
24/02/07 11:34:03.35 A5F8kPnc.net
>>405
tokioに依存してない非同期関数ならクレートの依存もなく自分でFuture::pollを呼べばいい
例えばpollsterってクレートはそれ専用で、block_onだけ呼べる最小限の実装になってるよ
413:デフォルトの名無しさん
24/02/07 11:48:56.31 EgwSQeAh.net
自分でFuture::poll呼ぶとか罰ゲームすぎるやろ
414:デフォルトの名無しさん
24/02/07 12:13:10.25 DO0hQq6L.net
>>361
ゲームサーバーはユーザーの操作ログを逐一集めてるよ。
415:デフォルトの名無しさん
24/02/07 12:15:26.39 DO0hQq6L.net
>>370
いや、無知は恥だよ。ただ罪では無い。
無知のままでいようとすることは罪だけど。
あ、実際の法律云々じゃなくて技術者としてね。
416:デフォルトの名無しさん
24/02/07 12:39:51.49 3p2K3Rhv.net
>>407
自分で呼んでもいいし自分で呼ばなくてもいい
それは何をやりたいかどこまでやりたいかなどに依存
>>405
軽いものなら例えばこれだけ
fn main() {
let val = futures_lite::future::block_on(async {
...
});
}
417:デフォルトの名無しさん
24/02/07 13:49:24.53 hXp0LcUB.net
pollを自分で呼ぶコードは悪手とかなんとか主張する人間と
そのコードに警告もしないコンパイラを
比較できるのがRustの楽しいところで
リソースを節約する話などは人間と人間の論争でありRustに責任はない
418:デフォルトの名無しさん
24/02/07 19:07:50.52 tO9J4ky9.net
C++に安全の責任はない
Pythonに動作速度の責任はない
Brainfuckにリソース節約の責任はない
Rustにリソース節約の責任はない
419:デフォルトの名無しさん
24/02/07 19:08:11.49 tO9J4ky9.net
うーん
420:デフォルトの名無しさん
24/02/07 19:08:14.90 e4qAQ6ae.net
>>366
ゲームのミドルウェアがUE4だから、サーバー側もC++で書いてるんじゃないかな。
421:デフォルトの名無しさん
24/02/07 19:15:08.54 p3QVKrD0.net
>>412
リソース節約の責任って何？
リソース節約の責任があるプログラミング言語が存在するの？
422:デフォルトの名無しさん
24/02/07 19:30:42.71 DWMhsuR7.net
>>412
何の面白味もないな
423:デフォルトの名無しさん
24/02/07 19:49:16.82 tO9J4ky9.net
>>415
リソース節約の責任の定義は>>411に聞くべきでは？
424:デフォルトの名無しさん
24/02/07 20:05:00.19 oFnccM2b.net
そもそもRustとそのエコシステムを同一視してるんじゃないか。もちろん不可分なところはあるにせよ、分けて考えないとね。
425:デフォルトの名無しさん
24/02/07 23:23:34.90 BkEIpOIl.net
言語の形式的なルールと実利を同一視するのは
ルールを守れば必ず報われるべきってことじゃないか
でもルールを守ることと勝つことは難易度が全然違う
426:デフォルトの名無しさん
24/02/07 23:47:29.64 Y7NjV+uy.net
Rustの駄目なところ
コンパイルが遅い
コンパイル時間を含めたらPythonのが圧倒的に速い
427:デフォルトの名無しさん
24/02/08 00:07:22.21 5/bJ8Q79.net
>>420
すごいでちゅねー
428:デフォルトの名無しさん
24/02/08 01:41:05.03 2eX+Xi95.net
Googleがプログラミング言語「Rust」に100万米ドルを助成、「C++」との併存・置き換えを図る
URLﾘﾝｸ(forest.watch.impress.co.jp)
429:デフォルトの名無しさん
24/02/08 04:23:52.18 vwr7y0Aq.net
>>420
みっともないからルビガイジみたいなレス乞食やめろよ
430:デフォルトの名無しさん
24/02/08 04:49:47.24 TVrzLD8V.net
ルビガイジって何？
431:デフォルトの名無しさん
24/02/08 07:47:36.74 guCqNZzs.net
何にでもruby推してくる変な人の事じゃね？
432:デフォルトの名無しさん
24/02/08 10:03:29.26 5zPu7Sf5.net
>>414
フロントとサーバーは間にネットワーク通信が挟まるんだから言語をフロントとサーバーで統一するメリットなし
433:デフォルトの名無しさん
24/02/08 10:24:35.32 TVrzLD8V.net
>>426
直接に通信するあたりは言語を統一しておくと共通のライブラリを使えたりするので便利。
少人数で運用しているシステムだとクライアントとサーバーがある程度に
共通のスキルセットで構築できたほうがいいってこともある。
それがデメリットを上回るほどのメリットかどうかは状況によるけど。
434:デフォルトの名無しさん
24/02/08 12:09:04.39 ug5u5xxX.net
gRPCやRESTなら主要言語のほぼ全てで対応されてるんだから別に同じ言語に囚われる必要無いと思うけどなあ
435:デフォルトの名無しさん
24/02/08 12:31:37.22 LLz4mv+z.net
シリアライズフォーマットの話とプロトコルの話も区別できないのかぁ
436:デフォルトの名無しさん
24/02/08 12:39:36.57 +yfo15bd.net
スキルセットが一番発揮されるのはコード実装前の設計段階だよ
アルゴリズムとデータ構造、各種言語の各種フレームワークの知見を活かして設計してるだろ？
実装段階に入ったらあとは作業
フロント担当サーバー担当それぞれが実装する
フロントとサーバーはお互いに入出力のAPIだけ知ってればいい
言語の書き方そのものに対するスキルセットは納入期間の短縮にでも活かしてくれ
437:デフォルトの名無しさん
24/02/08 12:43:32.12 ug5u5xxX.net
>>429
そんなんprotobufかjsonのどっちかだろ
当たり前すぎてデータをどう送受信するかの話をしてたわすまん
438:デフォルトの名無しさん
24/02/08 12:47:52.48 ug5u5xxX.net
あっごめんzstdかgzipのどっちでデータ圧縮するかの話もしたほうがいいの？
439:デフォルトの名無しさん
24/02/08 12:58:22.52 L2e7Z7sZ.net
それら全て些細な問題でどうでもいい
通信でもファイルでも何でも
APIやフォーマットさえ決められていればよい
どの言語かどのフレームワークやライブラリかなんて一切関係なく自由
440:デフォルトの名無しさん
24/02/08 13:08:16.93 aB2xl6fL.net
>>426
一応、lddで確認したけれど、Epicのオンラインライブラリリンクしてたから、>>427 も言うように、クライアント側のゲームエンジンに引っ張られてると思う。
441:デフォルトの名無しさん
24/02/08 13:14:50.58 ug5u5xxX.net
自社規格のデータをシリアライズ、デシリアライズするのに自社ライブラリを使うのと、サーバーやフロントをどの言語で実装するかは全くの別問題でしょ
>>414が言ってる、サーバーをC++で実装するだなんて効率の悪いことはするもんじゃない
442:デフォルトの名無しさん
24/02/08 13:16:12.56 L2e7Z7sZ.net
もちろんサーバとクライアントで同じ言語を利用すると有利な場合もある
もっと複雑なデータを別な形のデータに変換する同じ動作(コード)がサーバでもクライアントでも求められる場合がそれにそれに相当する
具体例としてはサーバサイドレンダリングをしつつフロントエンドでもシングルページのためレンダリングをする場合
従来はサーバサイドをNode.jsにすることで両側JavaScriptにしてコード共有が行われてきたが両側Rustでの動きもある
443:デフォルトの名無しさん
24/02/08 13:27:14.44 21XfFHH6.net
人によっては使用言語を統一したほうが数多なるデメリットを単一のメリットが上回ることもある
このご時世、簡略化されたプログラミング言語で溢れたなかで、単一言語しかできないというのは珍しいとは思うが、誰しもがバイリンガルプログラマというわけではない
444:デフォルトの名無しさん
24/02/08 13:39:56.20 557abryP.net
unreal engineってフレームワークでサーバーアプリも作れるけど、自前でAPI組んでサーバーやったほうが圧倒的に軽量なんだよね
445:デフォルトの名無しさん
24/02/08 13:40:27.02 wg4U7wDf.net
バイリンガルでないプログラマ、Javaしか書けなそう
446:デフォルトの名無しさん
24/02/08 14:05:04.22 u09hDjq1.net
Java界隈では未だにXMLが現役なのかな
一時期は全てがXMLだったけど最近触れる機会がない
447:デフォルトの名無しさん
24/02/08 14:06:53.53 0U3NNgcj.net
jsonの後にxml使うとデータの無駄が気になる
448:427
24/02/08 14:06:56.11 TVrzLD8V.net
>>430
「少人数で」と但し書きを入れたのは一人が色々と担当する状況であるという意味だよ。
449:デフォルトの名無しさん
24/02/08 14:22:34.49 TVrzLD8V.net
ウェブまわりはいろんな規格が入れ子状態だから名前空間で分離する仕組みも要るところでは要る。
XML の万能さは他には代えられない便利さはある。
ただ、それが要らないところでは負担がデカいのも本当だし、多くの場合には要らんかったわという気づきがあったんだよ。
XML もスキーマがあれば大幅に情報を短縮できるバイナリXMLの規格も出てるんで、
そういうのを活用すればそれほど過剰に冗長なわけではない。
450:デフォルトの名無しさん
24/02/08 14:33:58.18 d7zFncjn.net
>>436
例えがフロントエンドって急にレベル下がってワロタ
451:デフォルトの名無しさん
24/02/08 14:44:36.25 K+TPHqwf.net
>>431
ゲームサーバーでも性能を極限まで高めることが要求されるような場合はprotobufやJSONはあまり使われない
↓ここでいうRaw Struct的なものが今でも使われてる
URLﾘﾝｸ(flatbuffers.dev)
言語ニュートラルじゃないしサーバーとクライアントと同時アップデートしないといけないとかいろいろ制約あるけど性能が必要ならそれらの手間を惜しまない
452:デフォルトの名無しさん
24/02/08 14:50:39.80 L2e7Z7sZ.net
>>444
ならばプロコトル以外で
サーバとクライアントで同じコードを実行するために同じ言語であることが求められる例を挙げろよ
453:デフォルトの名無しさん
24/02/08 14:52:06.22 ZTHDKZhp.net
>>440
早くxmlは滅んで欲しい。
454:デフォルトの名無しさん
24/02/08 14:52:54.34 TVrzLD8V.net
シリアライズやパースのコストは小さくはないけど、
メモリコピーのコストが多くを占めているという発見から
なるべくコピーを減らしたシリアライズの規格として message pack が
実行性能と可搬性を (ある程度に) 両立したものとして人気がある。
まあ要するにそれぞれに利点があるんでこれが決定版とはなかなか言えないんだよな。
ある程度の収斂はしたにしても両立不可能なトレードオフってものはある。
455:デフォルトの名無しさん
24/02/08 14:58:14.76 ug5u5xxX.net
>>445
まあゲームだとデータの規格のバージョン互換性を考えなくていいし独自規格で暗号化も兼ねたシリアライズをしたほうが悪意あるデータの改ざん防止のための対策にもなりそう
てかデータ記述言語の話なんざクソほどどうでもいいんだが
456:デフォルトの名無しさん
24/02/08 15:04:17.46 2EtcR70r.net
xmlだろうがjsonだろうがrest通すときはgzipするからどっちでもいいわ
457:デフォルトの名無しさん
24/02/08 15:04:23.12 d7zFncjn.net
>>446
一昔前の分散オブジェクトシステムは大抵それだぞ
COBRAとか
そういう設計古くさいから基本的にやらない
458:デフォルトの名無しさん
24/02/08 15:14:54.75 ug5u5xxX.net
>>438
ああ、なるほど、UEはゲームレンダリングエンジンとしてではなくそれ単体でサーバーサイドもできるってことね知らんかった
小規模サーバー用途ならそれで十分そう
459:デフォルトの名無しさん
24/02/08 15:16:59.91 ZTHDKZhp.net
クライアントとサーバーで同じ "プログラミング言語" 使うことの話が、いつのにかプロトコルとデータシリアライズの話にすり変わってるし。
発端は >>426 あたりかな。
460:デフォルトの名無しさん
24/02/08 15:26:56.26 L2e7Z7sZ.net
>>451
分散オブジェクトの話とは状況が全く異なる
ウェブのサーバーサイドとクライアントサイドでのコード共通化は現在使われている最新技術
これを片側でしか行なわないと速度面すなわちブラウザを使う人間の体感面で不利となってしまう
両側ともにJavaScriptにするのが主流だがサーバーリソースコスト面で不利なため両側Rust化
461:デフォルトの名無しさん
24/02/08 15:32:31.05 d7zFncjn.net
>>454
別にお前のお気持ちは聞いてないよ
462:デフォルトの名無しさん
24/02/08 15:34:25.91 L2e7Z7sZ.net
>>455
気持ち？
理解していないようなので現在のウェブ界での動向を伝えただけだが
463:デフォルトの名無しさん
24/02/08 15:39:43.48 lShPsUxC.net
>>454
それwasmってやつ？ファイルサイズがjavascriptより大きくならない？
464:デフォルトの名無しさん
24/02/08 15:46:12.86 rcfTmCHH.net
フロントエンドってAPI受け取ってReactで画面描いてAPI送りつけるだけじゃん、これのどこがサーバーサイドとコード共通にすなるん？？
465:デフォルトの名無しさん
24/02/08 15:52:25.19 VkQAw5RB.net
javascriptでサーバーサイドって言ってる時点で頭がおかしいからスルーでおけ
466:デフォルトの名無しさん
24/02/08 15:57:01.04 z3sGsuBj.net
nodejsで済むサーバーって自宅サーバーか何かか?
467:デフォルトの名無しさん
24/02/08 16:06:02.61 34mhb8ps.net
>>457
一般的には何をするかに拠る
レンダリングコード共通化の話ならばその部分については誤差範囲
>>458
あまりにも基礎知識が無さすぎるようなので
SSRとCSRの違いと両者のメリットとデメリット及びコード共通化によるメリットを勉強しなさい
468:デフォルトの名無しさん
24/02/08 16:07:53.03 d7zFncjn.net
>>456
いやそれが余計なんだって
next.js app router+rust使ってる俺に対してする説明ではない
469:デフォルトの名無しさん
24/02/08 16:08:25.23 34mhb8ps.net
>>459
>>460
そこはPHPでもRubyでもPythonでもJavaScriptでも変わらない
しかしそれらは遅いからサーバーサイドはRust化すべきだろう
つまりレンダリング共通コードもRustで統一すべき
470:デフォルトの名無しさん
24/02/08 16:43:53.73 ug5u5xxX.net
WASMはあまりにアセンブリ言語すぎる
watで直接WASMを書いてコンパイルするのが一番バイナリのファイルサイズを抑えられるけど大変
watじゃなくて他の言語で書くにしてもstd使うとファイルサイズが爆増する
既存のライブラリをWASM化するならともかく、既存のJavaScriptコードをstd有りで書き直すのは、ファイルサイズがJavaScriptのときと比較して増えて本末転倒だからJavaScriptのままでいい
watやRust with no-stdでWASMを頑張る人は頑張って
471:デフォルトの名無しさん
24/02/08 16:54:49.99 GUaqsUfs.net
>>459 >>460
今は企業サイトでもサーバーサイドでJavaScriptが動く時代よ
Next.jsやNuxt.jsなどの名前を聞いたことないですか？
472:デフォルトの名無しさん
24/02/08 17:10:13.67 ug5u5xxX.net
だめだ、WASM specを見直してるけど相変わらず何書いてあるのかわからん
473:デフォルトの名無しさん
24/02/08 17:15:11.69 TVrzLD8V.net
>>464
規模がデカいアプリケーションは std の大きさなんてどうでもよくなるくらいにデカい。
大規模化するウェブアプリケーションが想定されているから
JavaScript のほうが軽量であるときは JavaScript を使えばいいよ。
そうじゃないときがあるって話なんだよ。
474:デフォルトの名無しさん
24/02/08 17:20:27.37 K+TPHqwf.net
1コアで毎秒数万リクエスト処理するようなゲームサーバー的なものの話をしてると思ってたらSSRとかReactとか全く違うユースケースの話をしてる人達がいたのか
そりゃ話が噛み合わないわなぁ
475:デフォルトの名無しさん
24/02/08 17:26:24.69 Z/Y0D/hR.net
話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち
476:デフォルトの名無しさん
24/02/08 17:26:27.02 Z/Y0D/hR.net
話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち
477:デフォルトの名無しさん
24/02/08 17:33:18.45 wPAPAJoC.net
>>467
その規模のデカいアプリケーションとやらがffmpegとかゲームとかをやるwasmならファイルサイズが大きくなる以上のメリットがあるからいいが、きれいなUIを表現するためにjavascriptよりファイルサイズの大きくなったwasmを使うのはアホとだけ言っておくわ
478:デフォルトの名無しさん
24/02/08 17:42:32.82 EBOg13nx.net
>>464
Wasmではfsなど必要ないのだから
no_stdで全く問題なくプログラミングできます
Rustの基本はほとんどcoreに入っています
allocを使えばVecやStringも使えます
あと欲しくなるのはHashMapあたりでしょうがこれもhashbrownで使えます
一度no_stdでプログラミングしてみることをオススメします
479:デフォルトの名無しさん
24/02/08 17:44:09.24 EBOg13nx.net
>>471
いえいえ
Wasmのファイルサイズはそんな巨大になりません
480:デフォルトの名無しさん
24/02/08 17:55:44.80 TVrzLD8V.net
Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので
wasm で出力してみたけどだいたい 140kb くらいな感じ。
たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが
だからといって Rust でやって深刻に巨大すぎるということはない。
小さいプログラムのときでも Wasm は使い物になる。
いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、
全くのアンチパターンってことはない。
481:デフォルトの名無しさん
24/02/08 17:56:24.51 ug5u5xxX.net
>>472
いやー、watでいいかな
482:デフォルトの名無しさん
24/02/08 18:26:36.73 d7zFncjn.net
Figmaはecmascripten使ってるそうだよ
C++で書いてWebGL用にコンパイル
おそらく世界最大のwasmコードだろう
URLﾘﾝｸ(www.figma.com)
483:デフォルトの名無しさん
24/02/08 18:29:10.38 d7zFncjn.net
今のところrustよりはecmascriptenの方が既存コードを活かせる
484:デフォルトの名無しさん
24/02/08 18:37:22.37 //05Mhwl.net
>>462
Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね
そこをRust化したいと思わないの？
485:デフォルトの名無しさん
24/02/08 18:41:39.17 d7zFncjn.net
>>478
next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね
486:デフォルトの名無しさん
24/02/08 18:54:05.90 //05Mhwl.net
>>479
Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど
「バックエンドはRustだから」って？
外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね
487:デフォルトの名無しさん
24/02/08 19:25:31.03 QINBs586.net
単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。
488:デフォルトの名無しさん
24/02/08 19:29:46.46 0U3NNgcj.net
途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん
489:デフォルトの名無しさん
24/02/08 19:34:55.22 XA34Vq7w.net
>>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな
490:デフォルトの名無しさん
24/02/08 19:38:03.57 XODN4PGj.net
next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ
491:デフォルトの名無しさん
24/02/08 19:54:29.48 vWC2S6ww.net
サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案
492:デフォルトの名無しさん
24/02/08 20:01:51.28 ZqeEswjg.net
Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ
493:デフォルトの名無しさん
24/02/08 20:03:16.79 XODN4PGj.net
それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった
494:デフォルトの名無しさん
24/02/08 20:29:26.04 ZTHDKZhp.net
>>464
forthみたいで面白くない？
495:デフォルトの名無しさん
24/02/08 21:09:57.90 iGefvq8R.net
Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ
496:デフォルトの名無しさん
24/02/08 21:15:13.68 fAoXwANU.net
>>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある
497:デフォルトの名無しさん
24/02/08 22:03:30.31 z3hLjd3o.net
もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ
498:デフォルトの名無しさん
24/02/09 00:17:38.71 tjbjc/kZ.net
今はRuby on Rails でも、React/Next.js, TypeScript が転職で必須。
少し前は、Vue.js だったけど、Vue 3 は流行らなかった
Rails 7 からは、Hotwire に変わった。
HotwireはHTML Over The Wireの略で、
SPAの開発において、JavaScriptのコーディングを極力必要としない。
脱node.js, webpack
JSONではなく、HTMLベース。
サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信する
これで、Reactに取られたシェアを回復する
499:デフォルトの名無しさん
24/02/09 06:07:49.74 79P7yOqB.net
>>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？
500:デフォルトの名無しさん
24/02/09 07:43:30.04 uUxbU3bY.net
Ruby信者はズレてるから仕方ない
501:デフォルトの名無しさん
24/02/09 07:53:26.10 cmMrL7Ws.net
SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい
502:デフォルトの名無しさん
24/02/09 08:55:44.38 so08h4Qi.net
SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう
503:デフォルトの名無しさん
24/02/09 09:34:26.12 Kdv0HxUE.net
std::any::type_name_of_val()は学習時にも良さそ
504:デフォルトの名無しさん
24/02/09 09:59:55.75 so08h4Qi.net
昔から使えるよ
fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str {
std::any::type_name::<T>()
}
505:デフォルトの名無しさん
24/02/09 10:27:55.96 C39eXNkM.net
>>493
JS使った方が楽という感覚は理解できんわ
506:デフォルトの名無しさん
24/02/09 13:19:22.70 YdTAf9YB.net
>>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？
507:デフォルトの名無しさん
24/02/09 13:59:04.29 wfDAL7tm.net
リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ
508:デフォルトの名無しさん
24/02/09 14:16:42.17 YdTAf9YB.net
>>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった
509:デフォルトの名無しさん
24/02/09 15:05:02.67 7wM1u29W.net
どんどんrustの話から離れていってんな
510:デフォルトの名無しさん
24/02/09 15:19:56.77 d4LbU2O8.net
SSRやCSRがややこしいと感じる意味がわからん
Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？
特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ
ReactのサーバーコンポーネントはNext..jsではサーバーサイドでレンダリング(HTML生成される)、つまりSSR
クライアントコンポーネントはクライアントサイドでレンダリングされる、つまりCSR
ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ
511:デフォルトの名無しさん
24/02/09 15:26:09.73 wyTCEkUp.net
Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ
512:デフォルトの名無しさん
24/02/09 15:36:06.60 gZOHhCrR.net
>>505
型システムとの兼ね合い。
513:デフォルトの名無しさん
24/02/09 15:38:36.69 ixshWTAh.net
>>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス
マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う
514:デフォルトの名無しさん
24/02/09 15:52:26.69 IKpgt5UR.net
next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね