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なんだよね
515:デフォルトの名無しさん
24/02/09 16:25:40.87 YdTAf9YB.net
>>504
その発想だとサーバーアクションは説明できないよ
516:デフォルトの名無しさん
24/02/09 16:28:31.07 YdTAf9YB.net
>>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる
517:デフォルトの名無しさん
24/02/09 16:37:49.82 DOCRBofH.net
>>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい
518:デフォルトの名無しさん
24/02/09 17:13:49.98 wfDAL7tm.net
>>510
同感
519:デフォルトの名無しさん
24/02/09 18:59:39.30 wyTCEkUp.net
C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？
520:デフォルトの名無しさん
24/02/09 19:22:48.34 6IeD8Xf6.net
実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さな
521:ければいけなかったんじゃないでしょうか。
522:デフォルトの名無しさん
24/02/09 19:24:12.28 6IeD8Xf6.net
あ、可変長引数の話とオーバーロードの話を混同してしまっていた。
523:デフォルトの名無しさん
24/02/09 19:32:53.51 RpHX5dqz.net
URLﾘﾝｸ(qiita.com)
こういうの知ってたら
オーバーロードもデフォルト引数もいらね～
どうしてもほしけりゃ別名の関数作るわ
ってならん？
524:デフォルトの名無しさん
24/02/09 19:45:04.86 qkcXaSLH.net
別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので
525:デフォルトの名無しさん
24/02/09 20:35:29.36 gZOHhCrR.net
田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。
526:デフォルトの名無しさん
24/02/09 23:53:50.41 qm1w3dJY.net
オーバーロードは無くてもいいけどキーワード引数は欲しいかな
527:デフォルトの名無しさん
24/02/09 23:59:48.02 D/1cks9J.net
>>519
あるよ
X { name: "foo", num: 123, ... }
528:デフォルトの名無しさん
24/02/10 02:54:22.21 rfU+NtYa.net
>>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ
529:デフォルトの名無しさん
24/02/10 09:13:20.91 KcmgHb9l.net
>>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある
530:デフォルトの名無しさん
24/02/10 09:40:29.45 d2BF2Jtb.net
Rustでなぜデフォルト引数がサポートされてないのかはここでよろしく
URLﾘﾝｸ(www.reddit.com)
531:デフォルトの名無しさん
24/02/10 09:50:58.48 lXB6J68A.net
構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ
532:デフォルトの名無しさん
24/02/10 09:54:14.05 Lf9bQLCg.net
ビルダーパターンは自分で書くならめんどい
533:デフォルトの名無しさん
24/02/10 10:07:03.72 iJNhxzEm.net
>>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌
534:デフォルトの名無しさん
24/02/10 10:08:52.95 QvZInASK.net
ADAってどう？
535:デフォルトの名無しさん
24/02/10 10:22:50.56 iJNhxzEm.net
Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって
536:デフォルトの名無しさん
24/02/10 10:33:01.11 VP+Iax6j.net
>>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな
537:デフォルトの名無しさん
24/02/10 10:33:37.95 2jz47bNZ.net
パターンとかきしょすぎ
Javaみてえな文化
538:デフォルトの名無しさん
24/02/10 10:36:17.39 VP+Iax6j.net
>>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから
539:デフォルトの名無しさん
24/02/10 11:15:35.75 6T66/lvp.net
>>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは
540:デフォルトの名無しさん
24/02/10 11:20:28.46 iJNhxzEm.net
>>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので
541:デフォルトの名無しさん
24/02/10 11:21:55.77 xcSAMi5J.net
キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな
542:デフォルトの名無しさん
24/02/10 11:24:20.16 iJNhxzEm.net
キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て
543:デフォルトの名無しさん
24/02/10 11:32:26.22 iJNhxzEm.net
パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ
544:デフォルトの名無しさん
24/02/10 11:53:44.03 H5a70urg.net
>>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない
545:デフォルトの名無しさん
24/02/10 11:54:44.92 H5a70urg.net
可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ
546:デフォルトの名無しさん
24/02/10 11:57:02.97 iJNhxzEm.net
>>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか
547:デフォルトの名無しさん
24/02/10 12:00:29.93 iJNhxzEm.net
>>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから
548:デフォルトの名無しさん
24/02/10 12:04:27.79 09Czk/ru.net
>>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい
549:デフォルトの名無しさん
24/02/10 12:09:31.06 H5a70urg.net
まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か
550:デフォルトの名無しさん
24/02/10 12:12:05.42 X5MB5Dp7.net
>>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ
551:デフォルトの名無しさん
24/02/10 12:13:49.11 H5a70urg.net
Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも
552:デフォルトの名無しさん
24/02/10 12:18:46.21 Gv6WNLHY.net
デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ
553:デフォルトの名無しさん
24/02/10 12:30:54.19 iJNhxzEm.net
パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる
554:デフォルトの名無しさん
24/02/10 12:33:11.47 lBFnzKPs.net
いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている
555:デフォルトの名無しさん
24/02/10 13:01:44.04 YTHRY4oL.net
>>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ
556:デフォルトの名無しさん
24/02/10 13:16:33.29 8ut+BFv7.net
Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから
557:デフォルトの名無しさん
24/02/10 13:20:09.17 LlCsSE+Z.net
>>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ
558:デフォルトの名無しさん
24/02/10 13:24:24.95 RZD3J/dp.net
>>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね
559:デフォルトの名無しさん
24/02/10 13:42:15.57 bXBK2+hH.net
>>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな
一言で言えばどちらも低DX
560:デフォルトの名無しさん
24/02/10 13:57:43.35 UK9hi/1i.net
>>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい
561:デフォルトの名無しさん
24/02/10 13:58:54.16 iJNhxzEm.net
>>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど
562:デフォルトの名無しさん
24/02/10 14:03:55.89 lW9Vkr52.net
>>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな
563:デフォルトの名無しさん
24/02/10 14:05:28.57 iJNhxzEm.net
デザインパターンといえばGoFは流石に古くないか？？
564:デフォルトの名無しさん
24/02/10 14:05:43.92 AU1t0rvZ.net
デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン
565:デフォルトの名無しさん
24/02/10 14:08:00.40 iJNhxzEm.net
デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます
566:デフォルトの名無しさん
24/02/10 14:23:27.48 Aed3I3PZ.net
話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか
567:デフォルトの名無しさん
24/02/10 14:40:14.16 XEL9SE6k.net
出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。
568:デフォルトの名無しさん
24/02/10 14:40:53.07 b8HpDXca.net
>>559
いつからブラウザで見ていると勘違いしていた
569:デフォルトの名無しさん
24/02/10 14:42:22.10 YTHRY4oL.net
>>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？
570:デフォルトの名無しさん
24/02/10 14:46:24.04 VP+Iax6j.net
Javarが考えた設計は根本的に汚い
571:デフォルトの名無しさん
24/02/10 14:49:44.24 WFGhMJhr.net
オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった
元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している
572:デフォルトの名無しさん
24/02/10 14:56:46.66 iJNhxzEm.net
>>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood
573:デフォルトの名無しさん
24/02/10 14:58:45.32 VP+Iax6j.net
いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話
574:デフォルトの名無しさん
24/02/10 14:59:40.15 iJNhxzEm.net
ついJavaという言葉に反応しちゃったけどよく見たらJavarだった…
575:デフォルトの名無しさん
24/02/10 15:00:30.74 iJNhxzEm.net
>>566
ごめん勘違いした>>565はスルーしてほしい
576:デフォルトの名無しさん
24/02/10 15:16:47.93 +PSgdWvA.net
・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる
577:デフォルトの名無しさん
24/02/10 16:24:25.37 YTHRY4oL.net
今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな
578:デフォルトの名無しさん
24/02/10 16:37:42.00 LPOrO1iz.net
継承抜きオブシコで十分っす
579:デフォルトの名無しさん
24/02/10 16:45:54.10 8zmdFTlm.net
なんでrustスレで他言語の雑談始まってしもたん
580:デフォルトの名無しさん
24/02/10 16:58:53.57 WFGhMJhr.net
>>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと
581:デフォルトの名無しさん
24/02/10 17:00:23.08 9OXXn/no.net
継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？
582:デフォルトの名無しさん
24/02/10 17:09:17.38 qHcm0B3l.net
従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし
583:デフォルトの名無しさん
24/02/10 17:37:53.51 lWs+b/Tw.net
Rustの型クラスは最強
584:デフォルトの名無しさん
24/02/10 17:45:44.24 cODs5/To.net
rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ
585:デフォルトの名無しさん
24/02/10 17:48:42.70 7r8QxWN2.net
>>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話
586:デフォルトの名無しさん
24/02/10 18:00:46.16 5OwpQQMY.net
>>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？
587:デフォルトの名無しさん
24/02/10 18:18:59.99 cODs5/To.net
>>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ
588:デフォルトの名無しさん
24/02/10 18:20:18.08 iJNhxzEm.net
>>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん
589:デフォルトの名無しさん
24/02/10 18:22:04.19 /ZC4Oa+s.net
只の道具なんで、向いていれば適応するし、向いてなければ使わない。
宗教的な正しさなんてどうでも良いんですよ。
おまいらは政治将校か？
590:デフォルトの名無しさん
24/02/10 18:23:43.39 7r8QxWN2.net
実装パターン < デザインパターン < アーキテクチャパターン
すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う
591:デフォルトの名無しさん
24/02/10 18:25:26.70 iJNhxzEm.net
Rustでよく使われてるパターンは
レイヤードアーキテクチャ
DDD
クリーンアーキテクチャ
なのかな？他にある？
592:デフォルトの名無しさん
24/02/10 18:26:30.51 iJNhxzEm.net
>>583
勉強になる👍
593:デフォルトの名無しさん
24/02/10 18:27:23.64 7r8QxWN2.net
>>580
そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て
クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う
594:デフォルトの名無しさん
24/02/10 18:29:37.58 +PSgdWvA.net
>>570
暴力でも寛容でもないふつうの非暴力闘争がいいのに
非暴力的な二項
595:対立まで否定するのは行き過ぎだよ
596:デフォルトの名無しさん
24/02/10 18:50:48.17 cODs5/To.net
>>586
そういう逃げは良くないぞ
例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ
実質そのような原典は存在しない
独自解釈によるものにすぎない
597:デフォルトの名無しさん
24/02/10 19:06:04.16 kzqqrU6F.net
オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ
598:デフォルトの名無しさん
24/02/10 19:08:51.93 kzqqrU6F.net
あと関数型と手続き型の区別がつかない
599:デフォルトの名無しさん
24/02/10 19:19:34.87 IjP+HezS.net
関数型はオブジェクト指向において部分的に使うもの
高階関数とかラムダ式とかはそんなに難しくない
600:デフォルトの名無しさん
24/02/10 19:31:34.99 76r5Dddg.net
>>590
一緒だよ
601:デフォルトの名無しさん
24/02/10 19:44:00.53 6ZZO7tOM.net
高階関数は「人間にとって」わかりにくくなるので使うなと
言われているね
あと論理型というのがあったなあ
602:デフォルトの名無しさん
24/02/10 19:47:12.54 IoMlesHJ.net
>>589
フロントエンド用途でコンポーネント指向
あと関数型というのは名前の通り関数に型を持たせたってだけ
高階関数と呼ばれてるね
オブジェクト指向に成り代わるものはいまだ出てきていない
603:デフォルトの名無しさん
24/02/10 19:50:32.36 H74b4wDc.net
オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある
あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう
オブジェクト指向信者もJavaは嫌いそう
604:デフォルトの名無しさん
24/02/10 19:52:30.82 IoMlesHJ.net
それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？
605:デフォルトの名無しさん
24/02/10 19:57:03.35 iu2BL++f.net
むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。
606:デフォルトの名無しさん
24/02/10 20:00:09.44 lgwlEc8K.net
オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手
607:デフォルトの名無しさん
24/02/10 20:03:05.61 6ZZO7tOM.net
狭義のオブジェクト指向言語は
データと操作を一つにまとめて型として使えるよ
ということだけ
カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは
昔から諸説ある
608:デフォルトの名無しさん
24/02/10 20:03:30.97 WFGhMJhr.net
>>596
オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること
継承なんて概念はない
609:デフォルトの名無しさん
24/02/10 20:05:33.42 2iG7gUv6.net
なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね
610:デフォルトの名無しさん
24/02/10 20:10:54.41 VlV2WaeL.net
オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど
611:デフォルトの名無しさん
24/02/10 20:13:45.74 o2x+aGn+.net
関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない
612:デフォルトの名無しさん
24/02/10 20:22:15.34 6cZfMrU8.net
>>603
関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ
613:デフォルトの名無しさん
24/02/10 20:30:09.19 xWWw0qe+.net
フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない
実装屋は逆にオブジェクト指向をベースにしたものばっかりやる
オブジェクト指向アンチの正体が分かっちゃうね
614:デフォルトの名無しさん
24/02/10 20:39:26.86 U5vUZCjE.net
手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型
615:デフォルトの名無しさん
24/02/10 20:46:30.71 lnD8LNvj.net
オブジェクト指向も関数型も確固たる定義がないバズワードだからな
話題にするだけ無駄
616:デフォルトの名無しさん
24/02/10 20:54:14.59 XEL9SE6k.net
グラデーション的だわな。
常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。
文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。
617:デフォルトの名無しさん
24/02/10 21:00:12.52 2fVxDtyX.net
オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど
618:デフォルトの名無しさん
24/02/10 21:04:41.79 hNXhuidE.net
勉強になるような知識どんどん書き込んでくれ
619:デフォルトの名無しさん
24/02/10 21:20:25.37 wHWIBAUz.net
オブジェクトを指向指向したら汚いコードがいっぱい出た
620:デフォルトの名無しさん
24/02/10 21:34:14.43 t6h0tc+k.net
オブジェクト指向自体には問題はなにもない
問題とされているのはオブジェクト指向ではなくクラス継承
これは実装継承となるアンチパターンなので使ってはいけない
621:デフォルトの名無しさん
24/02/10 22:00:16.03 EoWeXpbc.net
>>612
ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？
622:デフォルトの名無しさん
24/02/10 22:03:08.49 TERvB2uZ.net
みんながRustを使えば解決だね
623:デフォルトの名無しさん
24/02/10 22:07:13.96 a08tomEu.net
一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い
普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで
有益な情報が集まらないと判断しここを見限った
結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった
624:デフォルトの名無しさん
24/02/10 22:12:14.65 Bpk68K+1.net
今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない
バイリンガルプログラマな姿こそ実装屋が目指すべきところ
625:デフォルトの名無しさん
24/02/10 22:14:50.40 XEL9SE6k.net
べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。