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
べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。
626:デフォルトの名無しさん
24/02/10 22:26:31.80 ewSY5W0Q.net
継承は廃れた技術だから議論する意味がない
関心の分離を意識したプログラミングをしていこう
627:デフォルトの名無しさん
24/02/10 22:29:03.46 Lf9bQLCg.net
>>613
前にこのスレで話題になってただろ
Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか
628:デフォルトの名無しさん
24/02/10 22:30:28.98 HLmY2iS7.net
>>619
なにそのアンチパターンww
俺らはこれを反面教師として頑張ろうな
629:デフォルトの名無しさん
24/02/10 22:42:16.36 +PSgdWvA.net
>>604
手続き型には関数とデータ構造がある
関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ
630:デフォルトの名無しさん
24/02/10 22:56:15.78 XEL9SE6k.net
関数型言語が言う関数ってのは数学用語の関数のことで、
引数と評価結果の関係で表現される。
C とか Rust とかがいう関数のことではないよ。
関数とは呼ばれていても値を返すサブルーチンであって関数ではない。
631:デフォルトの名無しさん
24/02/10 22:57:32.43 YTHRY4oL.net
いやマジレスすなw
632:デフォルトの名無しさん
24/02/10 23:01:02.32 2CpL/1KO.net
Deref使った継承もどきは委譲と変わらんよ
継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと
基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから
基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ
633:デフォルトの名無しさん
24/02/10 23:23:00.37 +PSgdWvA.net
正しい責任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい
正当化が必要と感じる人には継承が必要なのだろう
634:デフォルトの名無しさん
24/02/11 08:17:40.00 Jcf8p7/N.net
委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる
635:デフォルトの名無しさん
24/02/11 08:28:38.26 8+WjthrU.net
インターフェースでやるときこそ委譲の使いどころでは？
データレイヤーでのインターフェースRepositoryのImplからDataSourceの各メゾットを呼び出すのはまさしく委譲の考え
636:デフォルトの名無しさん
24/02/11 09:33:37.86 QXc2iF2X.net
オブシコ＝オブジェクト指向
で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。
637:デフォルトの名無しさん
24/02/11 09:47:23.19 mQVY2wVN.net
>>627
レポジトリはドメインレイヤーがやるところでしょ
638:デフォルトの名無しさん
24/02/11 12:10:09.20 xzgPE83s.net
>>627
delegationとforwardingの区別が付いてないね
639:デフォルトの名無しさん
24/02/11 12:18:42.79 eNn3abAv.net
ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向
640:デフォルトの名無しさん
24/02/11 13:10:55.53 5cbdJqGT.net
オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある
だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる
641:デフォルトの名無しさん
24/02/11 13:30:06.52 UTHxd4xs.net
>>627
それは委譲ではない
継承と委譲とインターフェースは違うもの
642:デフォルトの名無しさん
24/02/11 14:12:49.22 tvA72CFJ.net
自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない
643:デフォルトの名無しさん
24/02/11 14:28:55.59 FmT3HYkV.net
>>634
“賢い”の定義が違うんだろ
察してやれ
644:デフォルトの名無しさん
24/02/11 14:35:31.96 eNn3abAv.net
定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている
645:デフォルトの名無しさん
24/02/11 15:00:23.67 p0mJmxcL.net
Rustにはインターフェースは無くて型クラスはある
型クラスを推してけ
646:デフォルトの名無しさん
24/02/11 15:56:01.57 EVWrf4kv.net
>>634
その用語、定義ありませんよｗ
君が勝手に思い込んでるだけｗ
647:デフォルトの名無しさん
24/02/11 16:06:16.13 nNzLNGzY.net
オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね
648:デフォルトの名無しさん
24/02/11 16:16:18.76 +E66gntj.net
>>639
(^_^)ﾉ
649:デフォルトの名無しさん
24/02/11 16:21:31.17 cP74y9AE.net
時代はオブシコではなく関数型プログラミング
オブシコは時代遅れ
例えば機械学習は関数型プログラミングやってる
650:デフォルトの名無しさん
24/02/11 16:24:12.02 aCOYKxUA.net
>>637
型理論においてはどちらも同じ
651:デフォルトの名無しさん
24/02/11 16:30:25.25 O/MMVA2r.net
なんかみんな単発だからレスバできないなあ
652:デフォルトの名無しさん
24/02/11 20:46:34.90 XOn8R4o/.net
RustがJSを滅ぼしてくれるのはいつになるかいのう……
653:デフォルトの名無しさん
24/02/11 21:26:37.41 M/VumamL.net
まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない
DOMがJS依存すぎる
654:デフォルトの名無しさん
24/02/11 21:51:44.10 XOPhWcHA.net
DOMはJSに依存しないしいろんな言語のインターフェースがあるが。
655:デフォルトの名無しさん
24/02/11 22:42:14.41 575tRfGH.net
>>646
肝心のWasmにDOM操作を許可しないんじゃ意味ない
656:デフォルトの名無しさん
24/02/11 22:47:25.71 YLWTi6Ka.net
>>647
DOM操作自体はwasmでもできるぞ
オーバーヘッドが大きすぎて遅いだけ
657:デフォルトの名無しさん
24/02/11 22:56:40.04 Ij1X5KaV.net
>>648
Wasmから直接DOM操作は不可能
JavaScriptにやってもらうしかない
つまりJavaScriptしかできない
そのため単純なDOM操作だとJavaScriptが有利だが
Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく
658:デフォルトの名無しさん
24/02/11 23:09:37.71 bi52uRem.net
自演ええて
659:デフォルトの名無しさん
24/02/11 23:36:32.19 BuG8Esm8.net
>>649
645だけど、だからDOM自体が欠陥品なんだって
JS依存の現状から脱却するにはDOMに変わるものが必要
660:デフォルトの名無しさん
24/02/12 00:40:57.30 cVfqqlnc.net
tree構造以外である程度の汎用性あるデータ構造なんてないわ。
661:デフォルトの名無しさん
24/02/12 01:04:43.36 tgn3NuIP.net
DOMに文句言ったところで何かが変わるわけじゃないからな
どうでもいい話
662:デフォルトの名無しさん
24/02/12 10:19:02.60 Autq7Dxb.net
>>651
現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。
663:デフォルトの名無しさん
24/02/12 10:33:25.13 QcKWCRm/.net
>>654
DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実
664:デフォルトの名無しさん
24/02/12 10:41:33.86 Autq7Dxb.net
DOMの設計と全然関係ない話。
665:デフォルトの名無しさん
24/02/12 10:51:22.86 dpV2oNnW.net
>>653
他人に文句を言うより自分で労働するという正義感は過労死の原因だよ
クレーマーはこの正義感を変えるじゃなくて既に変化した人
666:デフォルトの名無しさん
24/02/12 11:07:16.48 UiVeSAOt.net
domなしでのナビゲーションの方法があってもいいとは思う
667:デフォルトの名無しさん
24/02/12 11:08:30.75 CTu12wXT.net
いい加減にDOMはXMLをやめようぜ
無駄な構文が莫大な通信ロスを生んでる
668:デフォルトの名無しさん
24/02/12 11:23:28.89 u1N968/b.net
>>657
正義感w
自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね
DOMが欠陥品？
で？君はどうしたいんだい？
669:デフォルトの名無しさん
24/02/12 11:28:30.41 e3JrcLqa.net
>>655
昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った
670:デフォルトの名無しさん
24/02/12 11:38:53.51 nlvJBCEb.net
DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと
671:デフォルトの名無しさん
24/02/12 11:41:30.45 dpV2oNnW.net
やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい
672:デフォルトの名無しさん
24/02/12 13:30:26.12 UkU83gVN.net
DOMの代替の候補って存在するのかな
673:デフォルトの名無しさん
24/02/12 13:49:21.10 3NLsFenn.net
>>662
Windowsはゴミだから個人も仕事からも排除した
しかしネットがWebベースのこの時代にWebブラウザは排除できない
DOMは取り扱わざるを得ない
とはいえRustによるWasmからの取り扱いは以前よりかなり状況が良くなってきている
まずReference Types の導入によりJavaScriptのオブジェクトをそのまま透過的にだがRust(Wasm)側でも持ったり返したりできるようになった
これはJavaScriptグルーコードの削減をもたらしている
さらにGC対応もメモリ管理のうちJavaScript側依存のものの扱いを任せられるようになりRustでも取り扱いが楽になる
Rust側の内部に閉じたデータのみメモリ管理すればよくなるからだ