Rust part22

1 名前：デフォルトの名無しさん [2024/01/20(土) 23:21:40.08 ID:wyzQTwgG.net] 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust 公式ドキュメント https://www.rust-lang.org/learn Web上の実行環境 https://play.rust-lang.org ※Rustを学びたい人はまず最初に公式のThe Bookを読むこと https://doc.rust-lang.org/book/ ※Rustを学ぶ際に犯しがちな12の過ち https://dystroy.org/blog/how-not-to-learn-rust ※Rustのasyncについて知りたければ「async-book」は必読 https://rust-lang.github.io/async-book/ ※次スレは原則>>980が立てること 前スレ Rust part21 https://mevius.5ch.net/test/read.cgi/tech/1692105879/ ﾜｯﾁｮｲスレ プログラミング言語 Rust 4【ﾜｯﾁｮｲ】 https://mevius.2ch.net/test/read.cgi/tech/1514107621/ 263 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 03:14:48.13 ID:6VJ4TLXv.net] >>243 Protocol Buffers古いし、MessagePack(古い)やCBORのほうがいいんじゃない？ 使ったことないけど。 264 名前：デフォルトの名無しさん [2024/02/05(月) 03:40:05.05 ID:d3c/QlU3.net] Protocol buffersは仕様変更に強いしフォーマットを別ファイルに定義出来るという特徴があるから、msgpackやcbor とは使うべきケースが違いそう 265 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 06:01:25.37 ID:ip7v+BR3.net] >>247 もちろん少人数ガチ勢による開発もRustが向いてるのはおっしゃる通りだけど 大人数による開発もRust向いてるでしょう 特にC++で次から次に穴の発生が尽きない各大規模プロジェクトたちは作り直しや新規ならRust一択だね 266 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 06:45:17.21 ID:bXI/bbyn.net] >>247 Rustはサーバーサイドで最もよく使われているっていう調査結果がすでに出ているが>>117,119 267 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 06:55:14.99 ID:qjaRN2nq.net] >>253 どうでもいいがこの記事では非同期処理ライブラリにtokioじゃなくてrayonを使ってるんだな 気になってぐぐったら「rayonのスレッド プールは、CPU を集中的に使用する 268 名前：作業、つまり大規模なデータ セットの大規模な並列処理向けに設計されています。」らしい https://www.reddit.com/r/rust/comments/xec77k/rayon_or_tokio_for_heavy_filesystem_io_workloads/ [] [ここ壊れてます] 269 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 07:04:12.02 ID:ip7v+BR3.net] >>261 rayonは非同期を使わない並列に特化した時に速い tokioは非同期で並行＆並列で万能 270 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 08:21:40.19 ID:kahA1Glb.net] >>227 なら言語的に優れていてPythonライブラリを使えるNim最強だな。 271 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 08:36:20.41 ID:ip7v+BR3.net] Rust⇔PythonはPyO3で相互に呼び出せるのでRustだけあれば十分 272 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 09:57:56.35 ID:3fgxGQeI.net] 他の言語スレに乗り込んできて居座るとかやってる事ルビガイジとなんら変わらんっていう 273 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 12:16:47.03 ID:Uc3vGql0.net] >>263 Nimは速いしCへのトランスパイルも賛否あれど個人的には好き 274 名前：デフォルトの名無しさん [2024/02/05(月) 12:56:18.45 ID:WdhGREbJ.net] >>211 お前や俺らがそのunsafe部分を書く。 で職場の他の今動きゃいいってコード書いてる奴らにはunsafe部分は利用させても書かせない。 そういう分け方できるのはメリットじゃないかね。 275 名前：デフォルトの名無しさん [2024/02/05(月) 13:02:02.94 ID:WdhGREbJ.net] >>266 同意 276 名前：デフォルトの名無しさん [2024/02/05(月) 22:28:07.58 ID:UHwE0rib.net] >>259 もう5年くらいこんなこと言ってる人いるけど一向に普及してないよね。 277 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 22:40:04.70 ID:5g9amV19.net] >>269 カーネルのRustへのマイグレーションの成果が各所で出てるの知らない？ 278 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 22:49:23.20 ID:dxOzlQzX.net] >>269 AWS SDKにRustが正式登場して、色んなところがRustを触りだしてるぞ 279 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 23:29:16.62 ID:bm3rzOD2.net] AWSやCloudflareが大規模に使ってるからインターネットのトラフィックの結構な分量をRustが捌いてるはず この5年でこういう人目には触れないけど基礎的な部分にずいぶん普及したよ 280 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:09:13.25 ID:gR/xoQQt.net] Rust のユーザ規模はもはや小さくはないが仮に小さかったとしても、それが無用のものということを意味するわけではない。 Cobol や Fortran だって一般には化石のような印象を持たれつつも近年にも規格改定などの発展はあるし、それが求められる程度の利用シーンはある。 Lisp がインフラの中に潜んでいたりするし、Caml で書かれたプログラムがあなたがたのパソコンにインストールされていたりするのもそれなりに高い確率でありうる。 普及するっていうのはそれを不必要なところにまで押し付けたいわけじゃないだろう。 281 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:25:40.67 ID:oam+zbbU.net] 物を作ってから普及するまでの時間で評価されれば まだ作ってない物を売るようになったり、評価を信じなくなったりする 282 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:35:44.14 ID:QhlaBKsr.net] >>271 あれすげー使いにくいよ そもそもがAWSのAPI自体が非同期の作りですぐに返ってくるものばかりだから ライブラリ側は同期的で良いのにtokio使っちゃってるし 283 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:39:31.81 ID:OWeq/GHS.net] >>272 現在のネットのインフラであるクラウドとCDNがRust製になっていってるから Rustがネットインフラを支えるようになって来たと言っても過言ではないんだね 284 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 01:36:56.00 ID:bbDh9Fvv.net] >>275 割と何言ってるかよくわからないので どのあたりが使いにくいのか詳しく 285 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 08:02:11.78 ID:TiTcC6K4.net] >>275 javascriptでただの同期functionだったものが非同期のasync awaitに変わった経緯がある 同期functionだとブラウザから呼び出した時に待ち状態がフリーズみたいになって不便だった 286 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 08:41:24.69 ID:Lhg6cl8R.net] >>275 それはキミの非同期処理に関する知識が欠如してるだけ 287 名前：デフォルトの名無しさん [2024/02/06(火) 10:42:58.91 ID:rmP9tpon.net] まあわざわざライブラリ側で非同期にしなくても、必要ならユーザーが勝手に非同期にすればいいってのはあるかもな 288 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:02:01.98 ID:viYUZILO.net] お前らはawait禁止縛りでもしてるの？ 289 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:12:37.31 ID:tyBWuvJT.net] tokioの非同期って async fn、spawn、async、await を最低限使えればなんも不自由なくね？ 同期じゃないといけない理由あんの？ 290 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:17:49.52 ID:gR/xoQQt.net] 同期的に使うだけの場合でも tokio をリンクするってのが気分よくないというのはわかる。 291 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:19:55.73 ID:g9hJ5hPW.net] >>282 同期じゃないといけない理由？非同期の使い方がわからないからじゃないか？ ちなみにRustがダメだとアンチが言うのはアンチがRustコードのコンパイルを成功できないから 292 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:23:28.54 ID:YZW9kbIH.net] AWS SDKを同期的に使いたいってそれAWS CLIじゃだめなん？w 293 名前：デフォルトの名無しさん [2024/02/06(火) 11:25:05.20 ID:BOUvQi0K.net] >>280 そこの今まで独自にそれぞれが用意してた部分を async await 等のAPIとして整理されたことに意義があるんと思う。 294 名前：デフォルトの名無しさん [2024/02/06(火) 11:26:18.87 ID:J68o5uRN.net] AWS CLIはcargo installで入ってこないから…… 295 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:28:28.70 ID:DRX9b4l9.net] そもそもRustを使う意味がないよね AWS SDK for Pythonがあるんだから 296 名前：デフォルトの名無しさん [2024/02/06(火) 11:28:33.03 ID:J68o5uRN.net] >>286 async awaitへの統合に意義があるのはわかるけど、tokioにまで限定されるのはダルイという気持ちがある 297 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:33:54.88 ID:GPQIFWbx.net] >>289 そこはしょうがないでしょ tokioはAWSが積極的に支援してるライブラリだからね https://tokio.rs/ https://i.imgur.com/NSjb82s.png 298 名前：デフォルトの名無しさん [2024/02/06(火) 11:35:59.00 ID:J68o5uRN.net] >>290 説教的に支援って資金的な支援じゃなくてAWSがtokioの営業することだったのか…… 299 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:38:49.18 ID:GPQIFWbx.net] あ、AWSがtokioを運営してんのか 単なるスポンサーだと思ってた 300 名前：デフォルトの名無しさん [2024/02/06(火) 11:40:13.71 ID:J68o5uRN.net] マジか 301 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:42:17.61 ID:4dmbx6OY.net] 説教的な支援は5chの担当 302 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:42:20.07 ID:4dmbx6OY.net] 説教的な支援は5chの担当 303 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:53:48.52 ID:9gL8Mjmo.net] Rustで非同期やるライブラリって昔からたくさんあるけど最近はtokioしか使ってないや すごく重い処理があるプロジェクトはtokioとrayonで使い分けてるけどそれでも両方のライブラリをプロジェクトで共存させてる 304 名前：デフォルトの名無しさん [2024/02/06(火) 12:09:35.30 ID:eJTRS9Cw.net] 非同期と言いつつ出来てない奴って8割いるよね 305 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 13:54:11.58 ID:oam+zbbU.net] 非同期のそのデメリットを消す方法は まだ作ってないことにしよう 306 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:05:46.01 ID:QhlaBKsr.net] >>277 まずAWSのAPIってのは基本的にすぐ返ってるの この辺はわかる？ 例えばインスタンスを作るAPIってのはインスタンスを作り終わるまでブロックするんじゃなくてインスタンス生成命令を出してすぐに返ってくるわけ 実際にインスタンスが生成完了したかはインスタンスの状態取得APIを使って確認するわけ だから常に同期的に呼び出しで問題ないの pythonのboto3ってライブラリが1番使いやすい 307 名前：デフォルトの名無しさん [2024/02/06(火) 14:08:10.63 ID:9MgF8+tA.net] Boto3、あんま補完されなくて馬鹿にはキツい 308 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:39:52.97 ID:HfVCyUAp.net] >>299 AWSが鯖落ちしてたらどーすんの？ 309 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:47:03.29 ID:bbDh9Fvv.net] >>299 あなたが何言ってるかわかるけどnodejsでも 似たような使い方だしrust sdkの欠点と言われても 広く同意は得られないんじゃないかなあ 310 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:52:06.28 ID:QhlaBKsr.net] >>302 欠点というか使い方を難しくしてるだけな気がするんだよな 普通にCLIでええやんって思う 311 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:59:31.38 ID:bbDh9Fvv.net] >>303 awsに限らずweb apiのライブラリは 非同期にするのが主流だから 頑張って勉強してねとしか… 312 名前：デフォルトの名無しさん [2024/02/06(火) 15:05:27.46 ID:eJTRS9Cw.net] AWSのSDKは.NETのが1番だな 313 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 16:38:39.75 ID:m1uPeMIU.net] AWS SDK for Rustはsend()がめちゃくちゃダサい そのうち大幅に改修されるだろうけど >>299 ネットワークI/Oを同期で書くのはさすがにどうかと 314 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 16:55:31.82 ID:/Z6uowCt.net] >>300 今から見ると微妙だがCLIと対応がつけやすいし 余計なことはしなくて良いから楽だよ 315 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:04:11.45 ID:/Z6uowCt.net] >>306 どう書くか？はユーザーのユースケースによるからそうとも言えないよ 例えばAzureのCLIは--no-waitというオプションがあり 処理が成功するまで待つか待たないかを決められる これこそユーザー視点の設計だよ 316 名前：デフォルトの名無しさん [2024/02/06(火) 17:08:06.92 ID:8tVnzyvy.net] Google規模の会社が$1 million渡したくらいでわざわざアナウンスするなよな タイトル詐欺じゃん Improving Interoperability Between Rust and C++ https://security.googleblog.com/2024/02/improving-interoperability-between-rust-and-c.html 317 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:08:19.95 ID:/Z6uowCt.net] 非同期を押し付けることはユーザーのメリットにはならない Rust SDKは作り直して欲しい 318 名前：デフォルトの名無しさん [2024/02/06(火) 17:21:49.29 ID:HJO9dxnA.net] prostもblocking版の関数ないのかよってびっくりした記憶があるわ C#版もPython版もasyncとblockingの両方あるのにな 319 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:23:58.68 ID:pGyPKkef.net] >>299 >>まずAWSのAPIってのは基本的にすぐ返ってるの >>この辺はわかる？ 初心者でもそんなウソはつかないぞ AWSに限らず任意のサービスに言えるが通信時間がかかる さらに各サービス内で状態取得だけであっても実行時間がかかる >>だから常に同期的に呼び出しで問題ないの 本気で言ってる？ 通信時間と向こうでの実行時間の間こちらはずっと何もせずに待つわけ？ 非同期プログラミングの意味すら理解できていてないのか？ 320 名前：デフォルトの名無しさん [2024/02/06(火) 17:27:07.44 ID:eJTRS9Cw.net] >>312 コンピューターにとって1秒待つって事がどれだけ長いかを理解してないんだろ 321 名前：デフォルトの名無しさん [2024/02/06(火) 17:28:50.84 ID:2AaBK8OM.net] 非同期の方が良いことが多いのは同意するが、非同期を押し付けられると「こんなプログラムのためにTokio入れるのかよ」って思ってしまうケースは存在する 322 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:48:41.35 ID:Izyc/wZS.net] API が非同期で設計されてるのに、それを呼び出す側もさらに非同期でハンドリングするのは正直無駄じゃない？ ってのはわりと自然な感想だと思うけどな。 AWS の API なんてクライアント側で並列に呼び出したいユースケースも無いだろ。 バカスカ叩いてもスロットリングされるだけだし。 323 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 18:00:53.30 ID:eyCZAgqI.net] >>315 APIの向こう側で非同期なのとこちらの処理を 同期か非同期化は関係ないよね 324 名前：デフォルトの名無しさん [2024/02/06(火) 18:18:54.67 ID:w99V6zNl.net] それな 無関係ではないけど分けて考えないと 325 名前：デフォルトの名無しさん [2024/02/06(火) 18:33:39.13 ID:nmitk2Uo.net] >>308 非同期APIが提供されてれば同期化は簡単にできるから必要ないんだよ 326 名前：デフォルトの名無しさん [2024/02/06(火) 18:36:16.19 ID:2AaBK8OM.net] 同期化ってasyncでない関数から呼べるようにするって解釈で合ってるだろうか もしそうだとしたらasyncでない関数の中でtokioランタイム作ってawsよんでruntime終わらせるみたいな処理になっちゃわないか 327 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 19:56:13.91 ID:kbEH5D0U.net] AWSの同期的APIの機能リクエストあるのね https://github.com/awslabs/aws-sdk-rust/issues/505 328 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:03:24.75 ID:Dpp0fICO.net] AWSのAPIの呼び出しが非同期になるのはAPIの内部で効率化のために非同期処理をやってるからでしょ？ 329 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:17:12.09 ID:7oKTbIPT.net] うちはAWS SDK RustはAxumベースのWebアプリでDynamoDB接続に使ってるけど、みんなはなににAWS SDK使ってるん？ 330 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:38:04.56 ID:NQvIuvVx.net] >>312 だからーなーんにもわかってない発言丸出しはやめよ？ 通信の時間なんてかからんのやって すぐ返ってくるから そこちゃんと読もう？ 331 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:44:38.46 ID:NQvIuvVx.net] AWS APIを生のRESTで実装してみろよ すぐわかるぞ 332 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:45:53.99 ID:NQvIuvVx.net] 言っておくが俺は一般論として非同期がダメと言ってるわけじゃないぞ もちろんその用途としての方が便利なことは多い あくまでAWS SDKのRust版については不満があるということよ 333 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:50:46.76 ID:dKDdJveN.net] >>325 web apiの実装として相手側が非同期処理で 手元も非同期なんてのはawsだけじゃないというか それが主流だけど他はいいの？ 334 名前：デフォルトの名無しさん [2024/02/06(火) 20:50:52.38 ID:2AaBK8OM.net] このスレにはRust関連の悪い所の指摘を見ると自分が全否定されたように怒り出す人間がいるっぽいので 335 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:57:52.50 ID:NQvIuvVx.net] tokioが素晴らしいのは間違いない しかし今回のREST APIの呼び出しで程度で必要かな？と思う 非同期が必要ならtokio::process::commandでCLIを非同期で呼ぶ方が良くないか？とか色々考えてしまう 336 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:04:51.51 ID:pGyPKkef.net] >>323 >>通信の時間なんてかからんのやって >>すぐ返ってくるから 呆れた 敢えてウソをついているのか？ それとも本当に無知な初心者なのか？ 337 名前：デフォルトの名無しさん [2024/02/06(火) 21:08:56.44 ID:rmP9tpon.net] Web通信ですぐ返ってくることなんかあるのか？　と思ったけど、AWSのAIPの中身知らんから何とも言えんくなってしまった そういえばファイルIOはすぐ返ってくるって言って良いんだろうか 338 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:12:11.34 ID:NQvIuvVx.net] >>330 サイズが小さいファイルに対して非同期呼び出しをするか？という話 339 名前：デフォルトの名無しさん [2024/02/06(火) 21:14:41.84 ID:rmP9tpon.net] >>331 まあ「ファイルIOにTokioが必要です」って言われたらちょっと嫌な気分になるな 340 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:15:39.21 ID:pGyPKkef.net] >>330 Web通信は通信時間だけで大きく時間を要する さらにWebサーバ側で処理時間がかかる 341 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:56:45.71 ID:Z39zy7L3.net] >>323 cpuのナノ秒単位の処理速度に比べたら通信はとてつもなく遅いけど レスポンスを受け取るまでの時間は処理を中断させたほうがコンピュータに優しい tokioのグリーンスレッドを活かせ 342 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:05:59.23 ID:wkt5OFgc.net] >>334 tokioのランタイムが裏で動くとか気持ち悪すぎだろ 同期でやらせろ 343 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:13:28.77 ID:IqTcjswh.net] 他のSDKのようにv3くらいになれば使いやすくなってるかもね 344 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:16:42.98 ID:GPQIFWbx.net] aws sdk for rust ってwebフレームワークでサーバーサイドやってる人向けだから当然のようにみんなtokioを既に組み込んでるもんじゃないの？なにがそんなに気に入らないのか理解ができない まあtokio以外の非同期ランタイムを使わせろって人はドンマイだけど 345 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:17:52.75 ID:GPQIFWbx.net] 「rustのwebフレームワーク」が抜けてた 346 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:21:16.54 ID:1nslx8NY.net] >>337 そういう話じゃないけど 347 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:24:12.00 ID:DARHuXMe.net] >>337 実装の話に逸らさないで AWSのAPIくらい同期で十分なのにわざわざ非同期にする理由を言えよ 348 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:24:15.12 ID:UMLcFsAo.net] いくらすぐ返ってくるっていってもネットワーク通信なんだから 不通だったりレイテンシが長くなることはありうるし、 タイムアウトやリトライをtokioのエコシステムに乗っかってやれるメリットはあると思うけどな そりゃ軽量な同期版があるに越したことはないけど、優先順位は落ちるだろう 349 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:27:24.19 ID:QhlaBKsr.net] JavaScript SDKも内部は非同期だけど使いやすいよ 単なるコールバックで同期的に書けるし 350 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:33:38.08 ID:QhlaBKsr.net] どうも最近tokioがでしゃばってきて気持ちが悪い ここまできたらもうコアをtokioに入れてWeb用の専用言語としてフォークしたほうがよいのでは？ 351 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:35:03.21 ID:GPQIFWbx.net] >>340 はぁ？そんなに同期でやりたいなら同期のある言語のSDKを使うかAWS CLIでコマンド実行しててくれよ 同期同期言ってるやつはRustでAWS触るアプリ作ってねえだろ こちとらつい先日ようやく待ちに詫びたAWS SDK for Rustが正式版になって、ようやく、ようやくこれを本番投入できるって喜んだのによ 352 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:36:26.88 ID:QhlaBKsr.net] まあ俺はCLI使ってるw ぶっちゃけコードで書くメリットがわからない 353 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:36:30.11 ID:UMLcFsAo.net] というか同期版もランタイム切り替えも別にissueとしては却下されてるわけじゃないんだし 欲しい人は実装してPR出せばいいんだよ それがされてないってことは結局需要がないんでは？ 354 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:38:18.90 ID:YgjIpfMr.net] >>344 はい、じゃあお前の負けね もう二度と口答えすんなよ 355 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:40:20.30 ID:QhlaBKsr.net] >>341 不通だろうが普通はソケットのタイムアウト値設定するから許容できる範囲内の値を設定すればよろしい どちらにしろリトライすることになるのだ 356 名前：デフォルトの名無しさん [2024/02/06(火) 22:44:11.89 ID:oodj9UUv.net] 「そんなに××したいなら○○使えば良いんじゃないの？ 」→をはい○○使っています」っていう流れ、最強言語たるRustのスレの流れとしてはあまりにも敗北感がある 357 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:50:36.48 ID:QhlaBKsr.net] まとめると tokio使わない同期API作れ 非同期版はランタイム切り替えできるようにしろ ってことでオッケー？ 358 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:53:13.82 ID:j3cHqQGJ.net] >>340 コンマ1秒～1秒の頻度でデータベースクエリするWebアプリとかだったら非同期のが次々に処理できると思うけど 359 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:56:34.96 ID:LdUhtiaW.net] >>351 なんだそれ？ お前そんなにバカみたいな頻度でAWS APIを使うの？笑うわ 360 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:57:34.03 ID:MUGS3GDn.net] >>351 クエックエッ 笑笑 361 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:58:56.15 ID:QhlaBKsr.net] >>352 それくらいの頻度で呼び出す可能性があるのってGAFAMクラスの会社ぐらいじゃね？w 362 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:04:22.29 ID:JKYjZJJo.net] >>351 ゲームサーバーとかかな？ 363 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:06:26.14 ID:6KaTvZBM.net] >>354 それな笑笑 >>351は負けず嫌いの単発の敗者笑笑 364 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:08:14.09 ID:IqTcjswh.net] 使ってる用途が違うから噛み合わないんだな CLIで十分な用途とAPIが必要な用途くらいは区別しようぜ 365 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:08:21.31 ID:1CYgky+r.net] あ、もしかしてガーファ勤めなんかな笑笑？ なわけねえだろ笑笑 366 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:09:19.34 ID:nVMpMpiW.net] ガーファ最強笑笑 367 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:10:22.99 ID:fZ7dPHD5.net] >>351はバカです 368 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:12:04.80 ID:N6+r1oq4.net] >>355 ゲームサーバーってなに？マインクラフトでもやってるの？ガキんちょか？ 369 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:15:06.92 ID:aJWngw7a.net] >>357 うるさいな 非同期じゃないといけない理由を具体的に言ってみろよ？あ？ 370 名前：デフォルトの名無しさん [2024/02/06(火) 23:16:25.72 ID:QhlaBKsr.net] >>351 GAFAM社員age 371 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:26:25.88 ID:qbDsNmRG.net] 自分用のツールなら一々tokioとかめんどくさいとか わからんでもないけどそういう人をターゲットに してないからなあ 372 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:26:55.98 ID:IqTcjswh.net] GAFAMの規模を舐めすぎだろ 10リクエスト/秒程度なら中堅企業の社内向けシステムでも普通にあるレベル 373 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:35:03.14 ID:O9rpVDxS.net] 実際ゲームサーバーって大変そうよね 最近話題になったパルワールドってやつもサーバー要素があるけど、ゲームデータをどこかしらのクラウドサービスをレンタルしてやってるわけで、>>351よりもすごいレベルで行われてそう パルワールドのサーバーはどの言語のWebフレームワークでやってるのか知らんがJavaとかC#、GoあたりならRustのが高速、省メモリでサーバー代を節約できただろうな 374 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:43:25.52 ID:ZEorkRES.net] ゲームサーバーってプログラミング関係あるの？サーバーを借りてるだけなんじゃないの？ 375 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:56:44.33 ID:7jT2HGcX.net] 無知は恥ってよくわかるね 376 名前：デフォルトの名無しさん [2024/02/07(水) 00:00:36.36 ID:/3r7f4vo.net] >>366 人気ゲームだと桁が3つ4つ違う 377 名前：デフォルトの名無しさん [2024/02/07(水) 00:02:07.90 ID:HSCt9mfq.net] >>368 無知自体は何も恥じることではない 378 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:25:18.71 ID:ZYweHa7T.net] まさかゲームサーバーがなんなのかわからない人がこのスレにいるとは 379 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:29:20.89 ID:HhW4UiiT.net] AWSはCLIでいい、非同期はゴミって結論出たね 380 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:41:54.53 ID:O61WTlOm.net] 通信時間＋向こうでの処理時間はCPUにとって莫大な待ち時間 async/awaitによる非同期プログラミングをすれば同期と同じようにプログラムを組めつつその莫大な待ち時間を有効活用できる これは特定のプログラミング言語に関係なく対応しているすべての言語で成り立つ話 もちろんRustでも同じ 381 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:51:24.66 ID:EnTbeTL9.net] AWS Lambdaだと同時実行数の制限があるから、同期処理をするのは犯罪的。 382 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:58:32.65 ID:p1o31ALH.net] 現状のasync/awaitの使いやすさは Swift > C# > JavaScript >>> Rust 383 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:59:45.05 ID:p1o31ALH.net] KotlinやF#は使ったこと無いのでわからない 384 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:07:53.33 ID:p1o31ALH.net] >>375 Python忘れてたわ Swift > C# > JavaScript/Python >>> Rust 385 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:10:26.42 ID:O61WTlOm.net] >>375 Rustが最もきめ細かく扱えて便利 386 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:13:21.82 ID:O61WTlOm.net] もちろん性能面でもRustが最も有利 だからインフラに至るまで採用されている 387 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:20:07.41 ID:R4SwjTOT.net] >>377 c++は？ 388 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 02:44:08.20 ID:7skGlnTk.net] >>377 swiftってそんなに書きやすいんか？ 389 名前：デフォルトの名無しさん [2024/02/07(水) 04:57:14.90 ID:uDrK2oQi.net] >>375 asyncもRxもC#が発祥だけどこの言語だけ異常だよな 390 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 06:30:56.86 ID:EnTbeTL9.net] Pythonはスレッドが擬似的なので並行処理の性能が低い。 391 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 06:35:55.67 ID:5V24VW//.net] >>375 392 名前：Kotlinが抜けてる Kotlin>（越えられない壁）>Swift > C# > JavaScript/Python >>> Rust [] [ここ壊れてます] 393 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 06:52:43.34 ID:r0kpHnB4.net] Rustを叩きたいだけのアンチさんだから無茶苦茶や 394 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:15:51.00 ID:Z0+c6VxI.net] >>380 C++は論外 アンチではなく本当に書きにくい さらにtokioのような高性能な基盤も整備されていない 395 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:16:35.05 ID:0B0Tt2Zv.net] 非同期はC#GoKotlinRustのどれも同等に使いやすいと感じる JavaはSpringありき、Swiftはつかったことない、C/C++は考えたくない 396 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:25:44.75 ID:qmafesNd.net] swiftやdartはモバイルアプリ開発以外で全く使われてない 397 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:30:51.78 ID:KVAhvvz+.net] SwiftはApple製ってだけで使う価値なし 開発環境の依存があまりに高すぎる 398 名前：デフォルトの名無しさん [2024/02/07(水) 07:38:16.28 ID:2LChEtDL.net] 出来ればJVMも使わずに済みたい なんとなく 399 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:40:43.27 ID:lxo2szIV.net] >>375,377,384 なんか言語のラインナップ見るにバリバリのフロントエンド開発屋さんかな？ そらRustを使うことなんてないわな なんでこのスレにいるのか 400 名前：デフォルトの名無しさん [2024/02/07(水) 07:53:07.34 ID:q5vZGjA+.net] Rustはフロントエンドも取り込むのでRustスレはフロントエンド屋も書き込んで良い 401 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 08:12:27.93 ID:gKkOyEKn.net] まぁRustの非同期の良いところはランタイムを言語から切り離したので Webでも組み込みベアメタルでも非同期が使えるところなんだけど 使い勝手としてWebのユースケースに特化した他言語に負けるのはしょうがない これは時間がたっても根本的には改善されないから 不満があるなら早く他言語に移ったほうがいいよ 402 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 08:15:11.44 ID:0B0Tt2Zv.net] >>390 ならGoかC#のASP.NETでいんじゃね？ さまざまな導入コストを払えるなら事実上クラウドネイティブ言語のRust一択 それとJVMがダメという理由が、Oracle JVMのLTSサポート期間が短縮されJVMのイメージが悪化したってことに依るものなら、 Kotlin/JVMだとJDK8をベースに、どのJDKバージョンでも動くようにサポートされ続けられるから、JDK8から最新のJDK21までのLTSバージョンで難なく動く https://kotlinlang.org/docs/faq.html#which-versions-of-jvm-does-kotlin-target OracleのJavaは終わってるがJetBrainsのKotlinは無限に始まってる 403 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:03:48.96 ID:7skGlnTk.net] 静的言語ではkotlinが個人的には1番かな コルーチンスコープを作れるから既存の処理の中に非同期を唐突に入れられる これが理想 ただしクラスありきなのが微妙なところ クラスなしでkotlinのような使い心地がある言語が欲しい 404 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:09:08.81 ID:oJ2HGwP7.net] >>373 その時間有効に使えるのかって話なんだよ。 例えばRDSを休止したい場合に、休止するAPIを呼んで、状態を確認するAPIで休止を確認してすると思うけど、 そういう処理を自動化する時に非同期でハンドリングする意味あるかっていう。 DynamoDB のデータ操作とか業務トランザクション扱う系は非同期あっていいとは思うけどね。 405 名前：デフォルトの名無しさん [2024/02/07(水) 09:21:27.90 ID:+r3v4OXU.net] 既存の処理の中に非同期を唐突に入れられるのってランタイムがグローバルで一意じゃないと出来なそう ランタイムいくらでも作れるし複数種類存在しうるRustでは無理そうね 406 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:33:38.70 ID:3p2K3Rhv.net] >>395 それはRustも同じ Rustのasyncもコルーチンでありtrait Futureによって抽象化されている Future::pollの引数であるContextがKotlinでのコルーチンコンテキストに相当する >>397 Rustでも既存の処理に唐突に非同期を取り扱える Rustでtokioのようなランタイムが必要になるのはspawnして完全に制御外へ切り離すときのみ 制御内ならば複数のFutureを取り扱う場合でもjoinなど様々な方法で取り扱うことができる もちろんtokioランタイムは必要ない 407 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:42:26.35 ID:x+YpU8Xz.net] async{}.await 408 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:45:13.70 ID:kuiQPbhX.net] >>380 C++ はその性質上、システムとの連携が必要な標準ライブラリは薄い。 幅広いシステムで実現可能なように配慮するから。 必要ならサードパーティライブラリでやれというスタンス。 ただそこで強力な誰もが認めるサードパーティライブラリが結局は現れなかったというのが C++ のあかんかったところなんやわ。 個人的には C++/WinRT の非同期処理は好きなんだがね。 409 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 10:36:03.38 ID:0B0Tt2Zv.net] >>395 KotlinはデフォルトでclassがJavaでいうfinal classで定義されてて ・クラス継承禁止 ・やってることはCの構造体と同じ だから、自分はclassであるデメリットを感じてないかな Kotlinでクラス継承するにはご存知の通りclassをopen classやabstract classと書くから見て分かるのがヨシ 410 名前：デフォルトの名無しさん [2024/02/07(水) 10:46:44.24 ID:rJGaKMx5.net] >>396 >その時間有効に使えるのかって話なんだよ。 非同期にすることでawsに関係なく別の処理を同じリソースで走らせられる もしその時間を有効に使えないような用途なら省リソース高性能とは無縁だからわざわざRustを選ぶ必要ない 411 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 10:52:51.94 ID:ndvPWcVf.net] なんかプログラミング言語総合スレみたいになってんな いやちゃんと説明してくれて勉強になるから別にいいんだけど 412 名前：デフォルトの名無しさん [2024/02/07(水) 11:05:20.92 ID:tO9J4ky9.net] >>402 Rustはプログラム言語の王だから理由がなくてもRustを使って良い 413 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 11:12:27.12 ID:dhCR1KyQ.net] >>398 え、tokioランタイム無しで非同期関数呼べるんだ？　知らんかった でもクレートの依存は付いてきてビルド遅くなるよね 414 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 11:34:03.35 ID:A5F8kPnc.net] >>405 tokioに依存してない非同期関数ならクレートの依存もなく自分でFuture::pollを呼べばいい 例えばpollsterってクレートはそれ専用で、block_onだけ呼べる最小限の実装になってるよ 415 名前：デフォルトの名無しさん [2024/02/07(水) 11:48:56.31 ID:EgwSQeAh.net] 自分でFuture::poll呼ぶとか罰ゲームすぎるやろ 416 名前：デフォルトの名無しさん [2024/02/07(水) 12:13:10.25 ID:DO0hQq6L.net] >>361 ゲームサーバーはユーザーの操作ログを逐一集めてるよ。 417 名前：デフォルトの名無しさん [2024/02/07(水) 12:15:26.39 ID:DO0hQq6L.net] >>370 いや、無知は恥だよ。ただ罪では無い。 無知のままでいようとすることは罪だけど。 あ、実際の法律云々じゃなくて技術者としてね。 418 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 12:39:51.49 ID:3p2K3Rhv.net] >>407 自分で呼んでもいいし自分で呼ばなくてもいい それは何をやりたいかどこまでやりたいかなどに依存 >>405 軽いものなら例えばこれだけ fn main() { 　let val = futures_lite::future::block_on(async { 　　... 　}); } 419 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 13:49:24.53 ID:hXp0LcUB.net] pollを自分で呼ぶコードは悪手とかなんとか主張する人間と そのコードに警告もしないコンパイラを 比較できるのがRustの楽しいところで リソースを節約する話などは人間と人間の論争でありRustに責任はない 420 名前：デフォルトの名無しさん [2024/02/07(水) 19:07:50.52 ID:tO9J4ky9.net] C++に安全の責任はない < 421 名前：br> Pythonに動作速度の責任はない Brainfuckにリソース節約の責任はない Rustにリソース節約の責任はない [] [ここ壊れてます] 422 名前：デフォルトの名無しさん [2024/02/07(水) 19:08:11.49 ID:tO9J4ky9.net] うーん 423 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 19:08:14.90 ID:e4qAQ6ae.net] >>366 ゲームのミドルウェアがUE4だから、サーバー側もC++で書いてるんじゃないかな。 424 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 19:15:08.54 ID:p3QVKrD0.net] >>412 リソース節約の責任って何？ リソース節約の責任があるプログラミング言語が存在するの？ 425 名前：デフォルトの名無しさん [2024/02/07(水) 19:30:42.71 ID:DWMhsuR7.net] >>412 何の面白味もないな 426 名前：デフォルトの名無しさん [2024/02/07(水) 19:49:16.82 ID:tO9J4ky9.net] >>415 リソース節約の責任の定義は>>411に聞くべきでは？ 427 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 20:05:00.19 ID:oFnccM2b.net] そもそもRustとそのエコシステムを同一視してるんじゃないか。もちろん不可分なところはあるにせよ、分けて考えないとね。 428 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 23:23:34.90 ID:BkEIpOIl.net] 言語の形式的なルールと実利を同一視するのは ルールを守れば必ず報われるべきってことじゃないか でもルールを守ることと勝つことは難易度が全然違う 429 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 23:47:29.64 ID:Y7NjV+uy.net] Rustの駄目なところ コンパイルが遅い コンパイル時間を含めたらPythonのが圧倒的に速い 430 名前：デフォルトの名無しさん [2024/02/08(木) 00:07:22.21 ID:5/bJ8Q79.net] >>420 すごいでちゅねー 431 名前：デフォルトの名無しさん [2024/02/08(木) 01:41:05.03 ID:2eX+Xi95.net] Googleがプログラミング言語「Rust」に100万米ドルを助成、「C++」との併存・置き換えを図る https://forest.watch.impress.co.jp/docs/news/1566662.html 432 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 04:23:52.18 ID:vwr7y0Aq.net] >>420 みっともないからルビガイジみたいなレス乞食やめろよ 433 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 04:49:47.24 ID:TVrzLD8V.net] ルビガイジって何？ 434 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 07:47:36.74 ID:guCqNZzs.net] 何にでもruby推してくる変な人の事じゃね？ 435 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 10:03:29.26 ID:5zPu7Sf5.net] >>414 フロントとサーバーは間にネットワーク通信が挟まるんだから言語をフロントとサーバーで統一するメリットなし 436 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 10:24:35.32 ID:TVrzLD8V.net] >>426 直接に通信するあたりは言語を統一しておくと共通のライブラリを使えたりするので便利。 少人数で運用しているシステムだとクライアントとサーバーがある程度に 共通のスキルセットで構築できたほうがいいってこともある。 それがデメリットを上回るほどのメリットかどうかは状況によるけど。 437 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:09:04.39 ID:ug5u5xxX.net] gRPCやRESTなら主要言語のほぼ全てで対応されてるんだから別に同じ言語に囚われる必要無いと思うけどなあ 438 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:31:37.22 ID:LLz4mv+z.net] シリアライズフォーマットの話とプロトコルの話も区別できないのかぁ 439 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:39:36.57 ID:+yfo15bd.net] スキルセットが一番発揮されるのはコード実装前の設計段階だよ アルゴリズムとデータ構造、各種言語の各種フレームワークの知見を活かして設計してるだろ？ 実装段階に入ったらあとは作業 フロント担当サーバー担当それぞれが実装する フロントとサーバーはお互いに入出力のAPIだけ知ってればいい 言語の書き方そのものに対するスキルセットは納入期間の短縮にでも活かしてくれ 440 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:43:32.12 ID:ug5u5xxX.net] >>429 そんなんprotobufかjsonのどっちかだろ 当たり前すぎてデータをどう送受信するかの話をしてたわすまん 441 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:47:52.48 ID:ug5u5xxX.net] あっごめんzstdかgzipのどっちでデータ圧縮するかの話もしたほうがいいの？ 442 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:58:22.52 ID:L2e7Z7sZ.net] それら全て些細な問題でどうでもいい 通信でもファイルでも何でも APIやフォーマットさえ決められていればよい どの言語かどのフレームワークやライブラリかなんて一切関係なく自由 443 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:08:16.93 ID:aB2xl6fL.net] >>426 一応、lddで確認したけれど、Epicのオンラインライブラリリンクしてたから、>>427 も言うように、クライアント側のゲームエンジンに引っ張られてると思う。 444 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:14:50.58 ID:ug5u5xxX.net] 自社規格のデータをシリアライズ、デシリアライズするのに自社ライブラリを使うのと、サーバーやフロントをどの言語で実装するかは全くの別問題でしょ >>414が言ってる、サーバーをC++で実装するだなんて効率の悪いことはするもんじゃない 445 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:16:12.56 ID:L2e7Z7sZ.net] もちろんサーバとクライアントで同じ言語を利用すると有利な場合もある もっと複雑なデータを別な形のデータに変換する同じ動作(コード)がサーバでもクライアントでも求められる場合がそれにそれに相当する 具体例としてはサーバサイドレンダリングをしつつフロントエンドでもシングルページのためレンダリングをする場合 従来はサーバサイドをNode.jsにすることで両側JavaScriptにしてコード共有が行われてきたが両側Rustでの動きもある 446 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:27:14.44 ID:21XfFHH6.net] 人によっては使用言語を統一したほうが数多なるデメリットを単一のメリットが上回ることもある このご時世、簡略化されたプログラミング言語で溢れたなかで、単一言語しかできないというのは珍しいとは思うが、誰しもがバイリンガルプログラマというわけではない 447 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:39:56.20 ID:557abryP.net] unreal engineってフレームワークでサーバーアプリも作れるけど、自前でAPI組んでサーバーやったほうが圧倒的に軽量なんだよね 448 名前：デフォルトの名無しさん [2024/02/08(木) 13:40:27.02 ID:wg4U7wDf.net] バイリンガルでないプログラマ、Javaしか書けなそう 449 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:05:04.22 ID:u09hDjq1.net] Java界隈では未だにXMLが現役なのかな 一時期は全てがXMLだったけど最近触れる機会がない 450 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:06:53.53 ID:0U3NNgcj.net] jsonの後にxml使うとデータの無駄が気になる 451 名前：427 mailto:sage [2024/02/08(木) 14:06:56.11 ID:TVrzLD8V.net] >>430 「少人数で」と但し書きを入れたのは一人が色々と担当する状況であるという意味だよ。 452 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:22:34.49 ID:TVrzLD8V.net] ウェブまわりはいろんな規格が入れ子状態だから名前空間で分離する仕組みも要るところでは要る。 XML の万能さは他には代えられない便利さはある。 ただ、それが要らないところでは負担がデカいのも本当だし、多くの場合には要らんかったわという気づきがあったんだよ。 XML もスキーマがあれば大幅に情報を短縮できるバイナリXMLの規格も出てるんで、 そういうのを活用すればそれほど過剰に冗長なわけではない。 453 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:33:58.18 ID:d7zFncjn.net] >>436 例えがフロントエンドって急にレベル下がってワロタ 454 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:44:36.25 ID:K+TPHqwf.net] >>431 ゲームサーバーでも性能を極限まで高めることが要求されるような場合はprotobufやJSONはあまり使われない ↓ここでいうRaw Struct的なものが今でも使われてる https://flatbuffers.dev/md__benchmarks.html 言語ニュートラルじゃないしサーバーとクライアントと同時アップデートしないといけないとかいろいろ制約あるけど性能が必要ならそれらの手間を惜しま 455 名前：ない [] [ここ壊れてます] 456 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:50:39.80 ID:L2e7Z7sZ.net] >>444 ならばプロコトル以外で サーバとクライアントで同じコードを実行するために同じ言語であることが求められる例を挙げろよ 457 名前：デフォルトの名無しさん [2024/02/08(木) 14:52:06.22 ID:ZTHDKZhp.net] >>440 早くxmlは滅んで欲しい。 458 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:52:54.34 ID:TVrzLD8V.net] シリアライズやパースのコストは小さくはないけど、 メモリコピーのコストが多くを占めているという発見から なるべくコピーを減らしたシリアライズの規格として message pack が 実行性能と可搬性を (ある程度に) 両立したものとして人気がある。 まあ要するにそれぞれに利点があるんでこれが決定版とはなかなか言えないんだよな。 ある程度の収斂はしたにしても両立不可能なトレードオフってものはある。 459 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:58:14.76 ID:ug5u5xxX.net] >>445 まあゲームだとデータの規格のバージョン互換性を考えなくていいし独自規格で暗号化も兼ねたシリアライズをしたほうが悪意あるデータの改ざん防止のための対策にもなりそう てかデータ記述言語の話なんざクソほどどうでもいいんだが 460 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:04:17.46 ID:2EtcR70r.net] xmlだろうがjsonだろうがrest通すときはgzipするからどっちでもいいわ 461 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:04:23.12 ID:d7zFncjn.net] >>446 一昔前の分散オブジェクトシステムは大抵それだぞ COBRAとか そういう設計古くさいから基本的にやらない 462 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:14:54.75 ID:ug5u5xxX.net] >>438 ああ、なるほど、UEはゲームレンダリングエンジンとしてではなくそれ単体でサーバーサイドもできるってことね知らんかった 小規模サーバー用途ならそれで十分そう 463 名前：デフォルトの名無しさん [2024/02/08(木) 15:16:59.91 ID:ZTHDKZhp.net] クライアントとサーバーで同じ "プログラミング言語" 使うことの話が、いつのにかプロトコルとデータシリアライズの話にすり変わってるし。 発端は >>426 あたりかな。 464 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:26:56.26 ID:L2e7Z7sZ.net] >>451 分散オブジェクトの話とは状況が全く異なる ウェブのサーバーサイドとクライアントサイドでのコード共通化は現在使われている最新技術 これを片側でしか行なわないと速度面すなわちブラウザを使う人間の体感面で不利となってしまう 両側ともにJavaScriptにするのが主流だがサーバーリソースコスト面で不利なため両側Rust化 465 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:32:31.05 ID:d7zFncjn.net] >>454 別にお前のお気持ちは聞いてないよ 466 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:34:25.91 ID:L2e7Z7sZ.net] >>455 気持ち？ 理解していないようなので現在のウェブ界での動向を伝えただけだが 467 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:39:43.48 ID:lShPsUxC.net] >>454 それwasmってやつ？ファイルサイズがjavascriptより大きくならない？ 468 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:46:12.86 ID:rcfTmCHH.net] フロントエンドってAPI受け取ってReactで画面描いてAPI送りつけるだけじゃん、これのどこがサーバーサイドとコード共通にすなるん？？ 469 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:52:25.19 ID:VkQAw5RB.net] javascriptでサーバーサイドって言ってる時点で頭がおかしいからスルーでおけ 470 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:57:01.04 ID:z3sGsuBj.net] nodejsで済むサーバーって自宅サーバーか何かか? 471 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:06:02.61 ID:34mhb8ps.net] >>457 一般的には何をするかに拠る レンダリングコード共通化の話ならばその部分については誤差範囲 >>458 あまりにも基礎知識が無さすぎるようなので SSRとCSRの違いと両者のメリットとデメリット及びコード共通化によるメリットを勉強しなさい 472 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:07:53.03 ID:d7zFncjn.net] >>456 いやそれが余計なんだって next.js app router+rust使ってる俺に対してする説明ではない 473 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:08:25.23 ID:34mhb8ps.net] >>459 >>460 そこはPHPでもRubyでもPythonでもJavaScriptでも変わらない しかしそれらは遅いからサーバーサイドはRust化すべきだろう つまりレンダリング共通コードもRustで統一すべき 474 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:43:53.73 ID:ug5u5xxX.net] WASMはあまりにアセンブリ言語すぎる watで直接WASMを書いてコンパイルするのが一番バイナリのファイルサイズを抑えられるけど大変 watじゃなくて他の言語で書くにしてもstd使うとファイルサイズが爆増する 既存のライブラリをWASM化するならともかく、既存のJavaScriptコードをstd有りで書き直すのは、ファイルサイズがJavaScriptのときと比較して増えて本末転倒だからJavaScriptのままでいい watやRust with no-stdでWASMを頑張る人は頑張って 475 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:54:49.99 ID:GUaqsUfs.net] >>459 >>460 今は企業サイトでもサーバーサイドでJavaScriptが動く時代よ Next.jsやNuxt.jsなどの名前を聞いたことないですか？ 476 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:10:13.67 ID:ug5u5xxX.net] だめだ、WASM specを見直してるけど相変わらず何書いてあるのかわからん 477 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:15:11.69 ID:TVrzLD8V.net] >>464 規模がデカいアプリケーションは std の大きさなんてどうでもよくなるくらいにデカい。 大規模化するウェブアプリケーションが想定されているから JavaScript のほうが軽量であるときは JavaScript を使えばいいよ。 そうじゃないときがあるって話なんだよ。 478 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:20:27.37 ID:K+TPHqwf.net] 1コアで毎秒数万リクエスト処理するようなゲームサーバー的なものの話をしてると思ってたらSSRとかReactとか全く違うユースケースの話をしてる人達がいたのか そりゃ話が噛み合わないわなぁ 479 名前：デフォルトの名無しさん [2024/02/08(木) 17:26:24.69 ID:Z/Y0D/hR.net] 話を合わせようとしたら負け 駄文乱文を量産し続けて最後まで圧倒したやつの勝ち 480 名前：デフォルトの名無しさん [2024/02/08(木) 17:26:27.02 ID:Z/Y0D/hR.net] 話を合わせようとしたら負け 駄文乱文を量産し続けて最後まで圧倒したやつの勝ち 481 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:33:18.45 ID:wPAPAJoC.net] >>467 その規模のデカいアプリケーションとやらがffmpegとかゲームとかをやるwasmならファイルサイズが大きくなる以上のメリットがあるからいいが、きれいなUIを表現するためにjavascriptよりファイルサイズの大きくなったwasmを使うのはアホとだけ言っておくわ 482 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:42:32.82 ID:EBOg13nx.net] >>464 Wasmではfsなど必要ないのだから no_stdで全く問題なくプログラミングできます Rustの基本はほとんどcoreに入っています allocを使えばVecやStringも使えます あと欲しくなるのはHashMapあたりでしょうがこれもhashbrownで使えます 一度no_stdでプログラミングしてみることをオススメします 483 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:44:09.24 ID:EBOg13nx.net] >>471 いえいえ Wasmのファイルサイズはそんな巨大になりません 484 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:55:44.80 ID:TVrzLD8V.net] Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので wasm で出力してみたけどだいたい 140kb くらいな感じ。 たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが だからといって Rust でやって深刻に巨大すぎるということはない。 小さいプログラムのときでも Wasm は使い物になる。 いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、 全くのアンチパターンってことはない。 485 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:56:24.51 ID:ug5u5xxX.net] >>472 いやー、watでいいかな 486 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:26:36.73 ID:d7zFncjn.net] Figmaはecmascripten使ってるそうだよ C++で書いてWebGL用にコンパイル おそらく世界最大のwasmコードだろう https://www.figma.com/ja/blog/webassembly-c 487 名前：ut-figmas-load-time-by-3x/ [] [ここ壊れてます] 488 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:29:10.38 ID:d7zFncjn.net] 今のところrustよりはecmascriptenの方が既存コードを活かせる 489 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:37:22.37 ID://05Mhwl.net] >>462 Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね そこをRust化したいと思わないの？ 490 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:41:39.17 ID:d7zFncjn.net] >>478 next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね 491 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:54:05.90 ID://05Mhwl.net] >>479 Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど 「バックエンドはRustだから」って？ 外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね 492 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:25:31.03 ID:QINBs586.net] 単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。 LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。 493 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:29:46.46 ID:0U3NNgcj.net] 途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね TypeScriptは使ってないから知らん 494 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:34:55.22 ID:XA34Vq7w.net] >>480 Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな 自分が求めてるレベルが低いだけなのかな 495 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:38:03.57 ID:XODN4PGj.net] next.jsは普通に速いよ ビルドがクソ遅いだけで 他のエコシステムはもっと高速なんだけどねえ 496 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:54:29.48 ID:vWC2S6ww.net] サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい すべてをRust化するのが最善案 497 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 20:01:51.28 ID:ZqeEswjg.net] Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね Next.js以上のものはもはや作れんよ 498 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 20:03:16.79 ID:XODN4PGj.net] それな App Routerが神過ぎるんよ これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった 499 名前：デフォルトの名無しさん [2024/02/08(木) 20:29:26.04 ID:ZTHDKZhp.net] >>464 forthみたいで面白くない？ 500 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 21:09:57.90 ID:iGefvq8R.net] Next.jsがRailsの息の根を止めたわけだが、 React+Next.js+〇〇 このバックエンド部分の〇〇がRustが活かせるところ 501 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 21:15:13.68 ID:fAoXwANU.net] >>486 >>487 ReactとNextの大改革されてきた歴史を知っていれば 数年後にはまた改善されて新たな導入が必ずある 502 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 22:03:30.31 ID:z3hLjd3o.net] もう大きくは変わらないんじゃないか？ 正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった しかしApp Routerを見たときまさに俺の求めているものだと感じた 多分これが最高地点だよ 503 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 00:17:38.71 ID: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に取られたシェアを回復する 504 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 06:07:49.74 ID:79P7yOqB.net] >>492 javascript使ったほうがラクなのになんでわざわざhtml縛りするの？ 505 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 07:43:30.04 ID:uUxbU3bY.net] Ruby信者はズレてるから仕方ない 506 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 07:53:26.10 ID:cmMrL7Ws.net] SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい 507 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 08:55:44.38 ID:so08h4Qi.net] SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう 508 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 09:34:26.12 ID:Kdv0HxUE.net] std::any::type_name_of_val()は学習時にも良さそ 509 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 09:59:55.75 ID:so08h4Qi.net] 昔から使えるよ fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str { 　std::any::type_name::<T>() } 510 名前：デフォルトの名無しさん [2024/02/09(金) 10:27:55.96 ID:C39eXNkM.net] >>493 JS使った方が楽という感覚は理解できんわ 511 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 13:19:22.70 ID:YdTAf9YB.net] >>496 next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？ 512 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 13:59:04.29 ID:wfDAL7tm.net] リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ 513 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 14:16:42.17 ID:YdTAf9YB.net] >>495 app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ 極めてシンプルになった 514 名前：デフォルトの名無しさん [2024/02/09(金) 15:05:02.67 ID:7wM1u29W.net] どんどんrustの話から離れていってんな 515 名前：デフォルトの名無しさん [2024/02/09(金) 15:19:56.77 ID:d4LbU2O8.net] SSRやCSRがややこしいと感じる意味がわからん Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？ 特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ ReactのサーバーコンポーネントはNext..jsではサーバーサイドでレンダリング(HTML生成される)、つまりSSR クライアントコンポーネントはクライアントサイドでレンダリングされる、つまりCSR ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ 516 名前：デフォルトの名無しさん [2024/02/09(金) 15:26:09.73 ID:wyTCEkUp.net] Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ 517 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 15:36:06.60 ID:gZOHhCrR.net] >>505 型システムとの兼ね合い。 518 名前：デフォルトの名無しさん [2024/02/09(金) 15:38:36.69 ID:ixshWTAh.net] >>505 オプショナル引数 → 数が少ないならOption多いならbuilder 可変長の引数 → スライス マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う 519 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 15:52:26.69 ID:IKpgt5UR.net] next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね 520 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 16:25:40.87 ID:YdTAf9YB.net] >>504 その発想だとサーバーアクションは説明できないよ 521 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 16:28:31.07 ID:YdTAf9YB.net] >>508 俺は将来的にnext.jsは全部rustで書きなおされると思ってる 522 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 16:37:49.82 ID:DOCRBofH.net] >>504 概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ App Routerはどこで実行されるか？だけを意識すればよろしい 523 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 17:13:49.98 ID:wfDAL7tm.net] >>510 同感 524 名前：デフォルトの名無しさん [2024/02/09(金) 18:59:39.30 ID:wyTCEkUp.net] C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ これはRustの目指したいところなのか？ 525 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 19:22:48.34 ID:6IeD8Xf6.net] 実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから ゼロコスト抽象化という観点ではC++のほうがそちらを目指さなければいけなかったんじゃないでしょうか。 526 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 19:24:12.28 ID:6IeD8Xf6.net] あ、可変長引数の話とオーバーロードの話を混同してしまっていた。 527 名前：デフォルトの名無しさん [2024/02/09(金) 19:32:53.51 ID:RpHX5dqz.net] https://qiita.com/buntafujikawa/items/1bd808f5f55eb63df7c4 こういうの知ってたら オーバーロードもデフォルト引数もいらね〜 どうしてもほしけりゃ別名の関数作るわ ってならん？ 528 名前：デフォルトの名無しさん [2024/02/09(金) 19:45:04.86 ID:qkcXaSLH.net] 別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので 529 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 20:35:29.36 ID:gZOHhCrR.net] 田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。 都会では物より空間のほうが高くつくから。 何が大事か、何を大事ということにするかで判断が変わる。 名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。 でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。 530 名前：デフォルトの名無しさん [2024/02/09(金) 23:53:50.41 ID:qm1w3dJY.net] オーバーロードは無くてもいいけどキーワード引数は欲しいかな 531 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 23:59:48.02 ID:D/1cks9J.net] >>519 あるよ X { name: "foo", num: 123, ... } 532 名前：デフォルトの名無しさん [2024/02/10(土) 02:54:22.21 ID:rfU+NtYa.net] >>520 いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ 533 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:13:20.91 ID:KcmgHb9l.net] >>521 同じことだろ 関数の引数で列挙するか構造体で列挙するかで差はない 構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい 他の関数でも使い回せるメリットもある 534 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:40:29.45 ID:d2BF2Jtb.net] Rustでなぜデフォルト引数がサポートされてないのかはここでよろしく https://www.reddit.com/r/rust/comments/fi6nov/why_does_rust_not_support_default_arguments/ 535 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:50:58.48 ID:lXB6J68A.net] 構造体を使うかビルダーパターンで困ることはないからね もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ 536 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:54:14.05 ID:Lf9bQLCg.net] ビルダーパターンは自分で書くならめんどい 537 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:07:03.72 ID:iJNhxzEm.net] >>525 でも可視性があがるよ、あと保守が楽ちん メリットいっぱいなんだよ✌ 538 名前：デフォルトの名無しさん [2024/02/10(土) 10:08:52.95 ID:QvZInASK.net] ADAってどう？ 539 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:22:50.56 ID:iJNhxzEm.net] Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね 後に開発されたC++やJavaに影響を与えたんだって 540 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:33:01.11 ID:VP+Iax6j.net] >>490 OSSはなんだって始め数年は大改革されるもんよ 良くない作りは早めに治さんと後になったら大変になるから 逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな 541 名前：デフォルトの名無しさん [2024/02/10(土) 10:33:37.95 ID:2jz47bNZ.net] パターンとかきしょすぎ Javaみてえな文化 542 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:36:17.39 ID:VP+Iax6j.net] >>501 スクリプト言語は人員が集めやすいから消えはしない 世の中は理想論じゃなく現実で回ってるんだから 543 名前：デフォルトの名無しさん [2024/02/10(土) 11:15:35.75 ID:6T66/lvp.net] >>522 えっ、マジで違いがわからないの？ キーワード引数の価値を理解できない人がいるとは 544 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:20:28.46 ID:iJNhxzEm.net] >>530 悪いがデザインパターンの考えは大事だと主張させてもらうよ 可読性、保守性至上主義なので 545 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:21:55.77 ID:xcSAMi5J.net] キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ デフォルト値はまとめてDefault実装でがっちりコードも書けるしな 546 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:24:20.16 ID:iJNhxzEm.net] キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い 数年後には有用な実装が提言されてるかもしれないから待て 547 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:32:26.22 ID:iJNhxzEm.net] パターンにアンチ的な考えを持つのはお門違い Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ 548 名前：デフォルトの名無しさん [2024/02/10(土) 11:53:44.03 ID:H5a70urg.net] >>533 構文が優れていないからパターンみたいなキショいものが必要になる 誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない 549 名前：デフォルトの名無しさん [2024/02/10(土) 11:54:44.92 ID:H5a70urg.net] 可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない まるでJavaみたいだ 550 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:57:02.97 ID:iJNhxzEm.net] >>537 だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか 551 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:00:29.93 ID:iJNhxzEm.net] >>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから 552 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:04:27.79 ID:09Czk/ru.net] >>537 Pythonは欠陥プログラミング言語として知られているように酷い状況だよ 特に酷いと言われてるのはPythonにはinterface機能がないこと 抽象クラスで無理に実現しても劣りコードも汚い Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい 553 名前：デフォルトの名無しさん [2024/02/10(土) 12:09:31.06 ID:H5a70urg.net] まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か 554 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:12:05.42 ID:X5MB5Dp7.net] >>541 pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ 555 名前：デフォルトの名無しさん [2024/02/10(土) 12:13:49.11 ID:H5a70urg.net] Pythonで抽象クラス使うくらいならProtocolでも使うかな まあtrait使う方が良いのはそうかも 556 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:18:46.21 ID:Gv6WNLHY.net] デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ 557 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:30:54.19 ID:iJNhxzEm.net] パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり フレームワーク入れ替えのリファクタリングだって容易にできる 558 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:33:11.47 ID:lBFnzKPs.net] いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている 559 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:01:44.04 ID:YTHRY4oL.net] >>546 オブジェクト指向ありきのあの本はもうオワコン 読み返すとオブジェクト指向だらけで胸焼けするよ 560 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:16:33.29 ID:8ut+BFv7.net] Rustスレにオブシコアンチの居場所はないぞ Rustはオブシコの主要機能の2/3を取り入れてるんだから 561 名前：デフォルトの名無しさん [2024/02/10(土) 13:20:09.17 ID:LlCsSE+Z.net] >>537 Pythonもデザインパターン盛り盛りで作られてる 必要ないとか思っちゃってるのは経験が浅いだけ 562 名前：デフォルトの名無しさん [2024/02/10(土) 13:24:24.95 ID:RZD3J/dp.net] >>547 >いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い この考えが間違ってるんだよなぁ デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね 563 名前：デフォルトの名無しさん [2024/02/10(土) 13:42:15.57 ID:bXBK2+hH.net] >>541 Pythonではインターフェースを抽象クラスで代替できるってのと Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな 一言で言えばどちらも低DX 564 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:57:43.35 ID:UK9hi/1i.net] >>552 それは全く違う C++とRustにキーワード引数がないのは リソース管理の問題があるためだ つまり引数部分で色々やると リソース獲得問題と解放問題などが生じてしまう だからキーワード引数ではなぬ分離したほうが好ましい 565 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:58:54.16 ID:iJNhxzEm.net] >>548 クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ とにかく関心の分離にこだわる、この考えに尽きる まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど 566 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:03:55.89 ID:lW9Vkr52.net] >>551 言いたいことはわかるがデザインパターンといえば GoFと言われてるようではダメで 今のパラダイムに合った本が出ないとつらいかな 567 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:05:28.57 ID:iJNhxzEm.net] デザインパターンといえばGoFは流石に古くないか？？ 568 名前：デフォルトの名無しさん [2024/02/10(土) 14:05:43.92 ID:AU1t0rvZ.net] デザインパターンという言葉はGoFに汚染されているからな デザインパターンという言葉を使うこと自体がアンチパターン 569 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:08:00.40 ID:iJNhxzEm.net] デザインパターンが広義的すぎるのは分かる デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます 570 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:23:27.48 ID:Aed3I3PZ.net] 話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様 デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか 571 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:40:14.16 ID:XEL9SE6k.net] 出来ることが多いほどいいってわけじゃないからなぁ。 「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。 そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。 これから良いアイデアが出るかもしれないし出ないかもしれない。 572 名前：デフォルトの名無しさん [2024/02/10(土) 14:40:53.07 ID:b8HpDXca.net] >>559 いつからブラウザで見ていると勘違いしていた 573 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:42:22.10 ID:YTHRY4oL.net] >>551 その導き出される原則がデザインパターンなんだが何か勘違いしてない？ 574 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:46:24.04 ID:VP+Iax6j.net] Javarが考えた設計は根本的に汚い 575 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:49:44.24 ID:WFGhMJhr.net] オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように 一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった 元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい そのためRustやGoなど多くのモダン言語がクラスを排除している 576 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:56:46.66 ID:iJNhxzEm.net] >>563 Java？古いぞKotlinでだいぶキレイになった >>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood 577 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:58:45.32 ID:VP+Iax6j.net] いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話 578 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:59:40.15 ID:iJNhxzEm.net] ついJavaという言葉に反応しちゃったけどよく見たらJavarだった… 579 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 15:00:30.74 ID:iJNhxzEm.net] >>566 ごめん勘違いした>>565はスルーしてほしい 580 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 15:16:47.93 ID:+PSgdWvA.net] ・コンストラクタと関数を区別するのが面倒臭い ・関数とオブジェクトを区別するのが面倒臭い ・引数リストと普通のリストを区別するのが面倒臭い デザパタの原則を導き出せばまあこうなる 581 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 16:24:25.37 ID:YTHRY4oL.net] 今こそ新しいソフトウェア設計の本が必要かもな オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな 582 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 16:37:42.00 ID:LPOrO1iz.net] 継承抜きオブシコで十分っす 583 名前：デフォルトの名無しさん [2024/02/10(土) 16:45:54.10 ID:8zmdFTlm.net] なんでrustスレで他言語の雑談始まってしもたん 584 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 16:58:53.57 ID:WFGhMJhr.net] >>572 他言語の話ではなく デザインパターンの多くがクラスとその継承を前提あるいは例示していて Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと 585 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:00:23.08 ID:9OXXn/no.net] 継承なんざインターフェースでいくらでも代用できるやん 応用力ないん？ 586 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:09:17.38 ID:qHcm0B3l.net] 従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね 継承をサポートしないならクラスいらないし 587 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:37:53.51 ID:lWs+b/Tw.net] Rustの型クラスは最強 588 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:45:44.24 ID:cODs5/To.net] rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ 誰か出してくれ 589 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:48:42.70 ID:7r8QxWN2.net] >>546 クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話 590 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:00:46.16 ID:5OwpQQMY.net] >>578 デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？ 591 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:18:59.99 ID:cODs5/To.net] >>578 クリーンアーキテクチャとかもろにオブジェクト指向だろ 592 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:20:18.08 ID:iJNhxzEm.net] >>578 うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん 593 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:22:04.19 ID:/ZC4Oa+s.net] 只の道具なんで、向いていれば適応するし、向いてなければ使わない。 宗教的な正しさなんてどうでも良いんですよ。 おまいらは政治将校か？ 594 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:23:43.39 ID:7r8QxWN2.net] 実装パターン < デザインパターン < アーキテクチャパターン すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う 595 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:25:26.70 ID:iJNhxzEm.net] Rustでよく使われてるパターンは レイヤードアーキテクチャ DDD クリーンアーキテクチャ なのかな？他にある？ 596 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:26:30.51 ID:iJNhxzEm.net] >>583 勉強になる👍 597 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:27:23.64 ID:7r8QxWN2.net] >>580 そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う 598 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:29:37.58 ID:+PSgdWvA.net] >>570 暴力でも寛容でもないふつうの非暴力闘争がいいのに 非暴力的な二項対立まで否定するのは行き過ぎだよ 599 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:50:48.17 ID:cODs5/To.net] >>586 そういう逃げは良くないぞ 例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ 実質そのような原典は存在しない 独自解釈によるものにすぎない 600 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:06:04.16 ID:kzqqrU6F.net] オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ 601 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:08:51.93 ID:kzqqrU6F.net] あと関数型と手続き型の区別がつかない 602 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:19:34.87 ID:IjP+HezS.net] 関数型はオブジェクト指向において部分的に使うもの 高階関数とかラムダ式とかはそんなに難しくない 603 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:31:34.99 ID:76r5Dddg.net] >>590 一緒だよ 604 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:44:00.53 ID:6ZZO7tOM.net] 高階関数は「人間にとって」わかりにくくなるので使うなと 言われているね あと論理型というのがあったなあ 605 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:47:12.54 ID:IoMlesHJ.net] >>589 フロントエンド用途でコンポーネント指向 あと関数型というのは名前の通り関数に型を持たせたってだけ 高階関数と呼ばれてるね オブジェクト指向に成り代わるものはいまだ出てきていない 606 名前：デフォルトの名無しさん [2024/02/10(土) 19:50:32.36 ID:H74b4wDc.net] オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう オブジェクト指向信者もJavaは嫌いそう 607 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:52:30.82 ID:IoMlesHJ.net] それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？ 608 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:57:03.35 ID:iu2BL++f.net] むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。 609 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:00:09.44 ID:lgwlEc8K.net] オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手 610 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:03:05.61 ID:6ZZO7tOM.net] 狭義のオブジェクト指向言語は データと操作を一つにまとめて型として使えるよ ということだけ カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは 昔から諸説ある 611 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:03:30.97 ID:WFGhMJhr.net] >>596 オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること 継承なんて概念はない 612 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:05:33.42 ID:2iG7gUv6.net] なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね 613 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:10:54.41 ID:VlV2WaeL.net] オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど 614 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:13:45.74 ID:o2x+aGn+.net] 関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない 615 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:22:15.34 ID:6cZfMrU8.net] >>603 関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ 616 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:30:09.19 ID:xWWw0qe+.net] フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない 実装屋は逆にオブジェクト指向をベースにしたものばっかりやる オブジェクト指向アンチの正体が分かっちゃうね 617 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:39:26.86 ID:U5vUZCjE.net] 手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型 618 名前：デフォルトの名無しさん [2024/02/10(土) 20:46:30.71 ID:lnD8LNvj.net] オブジェクト指向も関数型も確固たる定義がないバズワードだからな 話題にするだけ無駄 619 名前：デフォルトの名無しさん mailto:sage [2024/02/10 ] [ここ壊れてます] 620 名前：(土) 20:54:14.59 ID:XEL9SE6k.net mailto: グラデーション的だわな。 常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。 文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。 [] [ここ壊れてます] 621 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 21:00:12.52 ID:2fVxDtyX.net] オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど 622 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 21:04:41.79 ID:hNXhuidE.net] 勉強になるような知識どんどん書き込んでくれ 623 名前：デフォルトの名無しさん [2024/02/10(土) 21:20:25.37 ID:wHWIBAUz.net] オブジェクトを指向指向したら汚いコードがいっぱい出た 624 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 21:34:14.43 ID:t6h0tc+k.net] オブジェクト指向自体には問題はなにもない 問題とされているのはオブジェクト指向ではなくクラス継承 これは実装継承となるアンチパターンなので使ってはいけない 625 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:00:16.03 ID:EoWeXpbc.net] >>612 ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？ 626 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:03:08.49 ID:TERvB2uZ.net] みんながRustを使えば解決だね 627 名前：デフォルトの名無しさん [2024/02/10(土) 22:07:13.96 ID:a08tomEu.net] 一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い 普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで 有益な情報が集まらないと判断しここを見限った 結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった 628 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:12:14.65 ID:Bpk68K+1.net] 今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない バイリンガルプログラマな姿こそ実装屋が目指すべきところ 629 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:14:50.40 ID:XEL9SE6k.net] べつに実装継承でもそれ自体が問題ってわけではない。 実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。 ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。 プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。 630 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:26:31.80 ID:ewSY5W0Q.net] 継承は廃れた技術だから議論する意味がない 関心の分離を意識したプログラミングをしていこう 631 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:29:03.46 ID:Lf9bQLCg.net] >>613 前にこのスレで話題になってただろ Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか 632 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:30:28.98 ID:HLmY2iS7.net] >>619 なにそのアンチパターンww 俺らはこれを反面教師として頑張ろうな 633 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:42:16.36 ID:+PSgdWvA.net] >>604 手続き型には関数とデータ構造がある 関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ 634 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:56:15.78 ID:XEL9SE6k.net] 関数型言語が言う関数ってのは数学用語の関数のことで、 引数と評価結果の関係で表現される。 C とか Rust とかがいう関数のことではないよ。 関数とは呼ばれていても値を返すサブルーチンであって関数ではない。 635 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:57:32.43 ID:YTHRY4oL.net] いやマジレスすなw 636 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 23:01:02.32 ID:2CpL/1KO.net] Deref使った継承もどきは委譲と変わらんよ 継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと 基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから 基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ 637 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 23:23:00.37 ID:+PSgdWvA.net] 正しい責 638 名前：任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい 正当化が必要と感じる人には継承が必要なのだろう [] [ここ壊れてます] 639 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 08:17:40.00 ID:Jcf8p7/N.net] 委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる 640 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 08:28:38.26 ID:8+WjthrU.net] インターフェースでやるときこそ委譲の使いどころでは？ データレイヤーでのインターフェースRepositoryのImplからDataSourceの各メゾットを呼び出すのはまさしく委譲の考え 641 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 09:33:37.86 ID:QXc2iF2X.net] オブシコ＝オブジェクト指向 で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。 642 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 09:47:23.19 ID:mQVY2wVN.net] >>627 レポジトリはドメインレイヤーがやるところでしょ 643 名前：デフォルトの名無しさん [2024/02/11(日) 12:10:09.20 ID:xzgPE83s.net] >>627 delegationとforwardingの区別が付いてないね 644 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 12:18:42.79 ID:eNn3abAv.net] ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向 645 名前：デフォルトの名無しさん [2024/02/11(日) 13:10:55.53 ID:5cbdJqGT.net] オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる 646 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 13:30:06.52 ID:UTHxd4xs.net] >>627 それは委譲ではない 継承と委譲とインターフェースは違うもの 647 名前：デフォルトの名無しさん [2024/02/11(日) 14:12:49.22 ID:tvA72CFJ.net] 自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない 648 名前：デフォルトの名無しさん [2024/02/11(日) 14:28:55.59 ID:FmT3HYkV.net] >>634 “賢い”の定義が違うんだろ 察してやれ 649 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 14:35:31.96 ID:eNn3abAv.net] 定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている 650 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 15:00:23.67 ID:p0mJmxcL.net] Rustにはインターフェースは無くて型クラスはある 型クラスを推してけ 651 名前：デフォルトの名無しさん [2024/02/11(日) 15:56:01.57 ID:EVWrf4kv.net] >>634 その用語、定義ありませんよｗ 君が勝手に思い込んでるだけｗ 652 名前：デフォルトの名無しさん [2024/02/11(日) 16:06:16.13 ID:nNzLNGzY.net] オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね 653 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 16:16:18.76 ID:+E66gntj.net] >>639 (^_^)ﾉ 654 名前：デフォルトの名無しさん [2024/02/11(日) 16:21:31.17 ID:cP74y9AE.net] 時代はオブシコではなく関数型プログラミング オブシコは時代遅れ 例えば機械学習は関数型プログラミングやってる 655 名前：デフォルトの名無しさん [2024/02/11(日) 16:24:12.02 ID:aCOYKxUA.net] >>637 型理論においてはどちらも同じ 656 名前：デフォルトの名無しさん [2024/02/11(日) 16:30:25.25 ID:O/MMVA2r.net] なんかみんな単発だからレスバできないなあ 657 名前：デフォルトの名無しさん [2024/02/11(日) 20:46:34.90 ID:XOn8R4o/.net] RustがJSを滅ぼしてくれるのはいつになるかいのう…… 658 名前：デフォルトの名無しさん [2024/02/11(日) 21:26:37.41 ID:M/VumamL.net] まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない DOMがJS依存すぎる 659 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 21:51:44.10 ID:XOPhWcHA.net] DOMはJSに依存しないしいろんな言語のインターフェースがあるが。 660 名前：デフォルトの名無しさん [2024/02/11(日) 22:42:14.41 ID:575tRfGH.net] >>646 肝心のWasmにDOM操作を許可しないんじゃ意味ない 661 名前：デフォルトの名無しさん [2024/02/11(日) 22:47:25.71 ID:YLWTi6Ka.net] >>647 DOM操作自体はwasmでもできるぞ オーバーヘッドが大きすぎて遅いだけ 662 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 22:56:40.04 ID:Ij1X5KaV.net] >>648 Wasmから直接DOM操作は不可能 JavaScriptにやってもらうしかない つまりJavaScriptしかできない そのため単純なDOM操作だとJavaScriptが有利だが Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく 663 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 23:09:37.71 ID:bi52uRem.net] 自演ええて 664 名前：デフォルトの名無しさん [2024/02/11(日) 23:36:32.19 ID:BuG8Esm8.net] >>649 645だけど、だからDOM自体が欠陥品なんだって JS依存の現状から脱却するにはDOMに変わるものが必要 665 名前：デフォルトの名無しさん [2024/02/12(月) 00:40:57.30 ID:cVfqqlnc.net] tree構造以外である程度の汎用性あるデータ構造なんてないわ。 666 名前：デフォルトの名無しさん [2024/02/12(月) 01:04:43.36 ID:tgn3NuIP.net] DOMに文句言ったところで何かが変わるわけじゃないからな どうでもいい話 667 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 10:19:02.60 ID:Autq7Dxb.net] >>651 現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。 668 名前：デフォルトの名無しさん [2024/02/12(月) 10:33:25.13 ID:QcKWCRm/.net] >>654 DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実 669 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 10:41:33.86 ID:Autq7Dxb.net] DOMの設計と全然関係ない話。 670 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 10:51:22.86 ID:dpV2oNnW.net] >>653 他人に文句を言うより自分で労働するという正義感は過労死の原因だよ クレーマーはこの正義感を変えるじゃなくて既に変化した人 671 名前：デフォルトの名無しさん [2024/02/12(月) 11:07:16.48 ID:UiVeSAOt.net] domなしでのナビゲーションの方法があってもいいとは思う 672 名前：デフォルトの名無しさん [2024/02/12(月) 11:08:30.75 ID:CTu12wXT.net] いい加減にDOMはXMLをやめようぜ 無駄な構文が莫大な通信ロスを生んでる 673 名前：デフォルトの名無しさん [2024/02/12(月) 11:23:28.89 ID:u1N968/b.net] >>657 正義感w 自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね DOMが欠陥品？ で？君はどうしたいんだい？ 674 名前：デフォルトの名無しさん [2024/02/12(月) 11:28:30.41 ID:e3JrcLqa.net] >>655 昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った 675 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 11:38:53.51 ID:nlvJBCEb.net] DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと 676 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 11:41:30.45 ID:dpV2oNnW.net] やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい 677 名前：デフォルトの名無しさん [2024/02/12(月) 13:30:26.12 ID:UkU83gVN.net] DOMの代替の候補って存在するのかな 678 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 13:49:21.10 ID:3NLsFenn.net] >>662 Windowsはゴミだから個人も仕事からも排除した しかしネットがWebベースのこの時代にWebブラウザは排除できない DOMは取り扱わざるを得ない とはいえRustによるWasmからの取り扱いは以前よりかなり状況が良くなってきている まずReference Types の導入によりJavaScriptのオブジェクトをそのまま透過的にだがRust(Wasm)側でも持ったり返したりできるようになった これはJavaScriptグルーコードの削減をもたらしている さらにGC対応もメモリ管理のうちJavaScript側依存のものの扱いを任せられるようになりRustでも取り扱いが楽になる Rust側の内部に閉じたデータのみメモリ管理すればよくなるからだ 679 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:41:26.64 ID:QicyHe7E.net] デザインパターンはあくまで定石集なんだから、Rust用のデザインパターン作ればいいだけの話。 「Rustならこんなに簡単にできる」と自慢できるから、信者にとってもいいことかと。 あと、Rustでダックタイピングできたっけ？ 事前にTraitで定義しなきゃいけないんだったら面倒だなぁ。 680 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:46:26.73 ID:FSKnAMMD.net] デザインパターンって簡単に実装できるとか 自慢するたぐいのものだっけ？ 681 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:55:33.33 ID:Jqge1vnq.net] 単発NG推奨 682 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:56:29.31 ID:9yTkyF6j.net] ドメインまわりをフレームワークと分離させる設計ならなんでもいいや 今後リファクタリングすることを考えた設計が大事 683 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:56:34.13 ID:Jqge1vnq.net] ここはRustスレです消えてください 684 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 16:00:10.23 ID:nHDMmyKy.net] >>666 ダックタイピングは動的型付け言語のためのオモチャであり デメリットも多いためまともな言語はダックタイピングを排除して別の形を取っている ダックタイピングは規律のない無政府状態であり可読性も下げデバッグもしにくくなり最悪となる もちろん実行時の動的型付けの問題もはらんでおり自然の静的なチェックができない 685 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 16:11:47.85 ID:KZYjz35/.net] ダックタイピングというゴミのような方法に対して Rustはダックタイピングを採用せずに代わりに完璧な方法を用意した それがtraitのrequired methodsとtrait boundsである この二つにより全てを解決している 686 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 16:12:19.21 ID:9yTkyF6j.net] ダックタイピングなんて荒業ではなく、ポリモーフィズムをやりましょ 687 名前：デフォルトの名無しさん [2024/02/12(月) 16:23:13.06 ID:cVfqqlnc.net] >>664 ない。結局まともに使えるものを用意しようと思えばああなる。 それも理解せずに馬鹿みたいに文句言ってるだけだわな。 688 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 18:20:41.31 ID:g0MzjlGR.net] >>667 繰り返されれば飽きる 繰り返されないのはパターンではない 689 名前：デフォルトの名無しさん [2024/02/12(月) 18:37:22.53 ID:NJ55srXB.net] >>671 GoやTypeScriptみたいな静的片付け言語でもダックタイピング採用してるよ nominal/structuralと動的/静的は直交 690 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 18:47:33.19 ID:0RqNbR5g.net] Goは実行時にランタイムが動的にvtableを生成してメソッドlookupするわけだから 静的ではないでしょ？ そんなことはC++やRustでは許されない行為だよ 691 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 19:22:42.84 ID:QavMz5Qe.net] >>676 TSはanyで型が消えてるときの話じゃないの？ 692 名前：デフォルトの名無しさん [2024/02/12(月) 20:01:03.19 ID:uYjIYqfU.net] 誰も定義の擦り合わせをしないのでどんどん意思疎通が困難になっていく 693 名前：デフォルトの名無しさん [2024/02/12(月) 20:07:14.69 ID:uYjIYqfU.net] 一言居士の群れ 694 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 20:21:22.17 ID:oZv/D2wt.net] ダックタイピングは一見するとお手軽に見えるけどプログラミング開発の足を引っ張る悪 Rustは排除しているので大丈夫 そしてRustではトレイト境界により確実に使えるものだけを呼び出せることを静的に保証しつつ用いる 695 名前：デフォルトの名無しさん [2024/02/12(月) 20:24:19.09 ID:H9LyWZwk.net] 現代はデザインパターンで設計するんじゃなくフレームワークで作る時代だけどな 696 名前：デフォルトの名無しさん [2024/02/12(月) 20:44:24.28 ID:5CWzyU2K.net] >>682 そのフレームワークがデザインパターンで出来てるんだけど 697 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 21:02:02.43 ID:g0MzjlGR.net] アルゴリズムはライブラリを一個作れば終わり もう一個作ったら車輪の再発明 だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない 698 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 21:59:54.43 ID:QicyHe7E.net] >>673 >>677 c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ…… Rustのgenericsはどれくらいダックタイピングできているかね。 699 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:09:04.93 ID:h7gv4DVB.net] >>685 C++の静的ポリモーフィズムはダックタイピングではない ダックタイピングは実行時に動的に処理されるものだけを指す 例えばGoはinterfaceでダックタイピングするが実行時にランタイムが動的にitable (interface table)を生成して用いる これは実行時に動的に処理されるためダックタイピングとなる もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる 手軽さとの引き換えだ 700 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:14:48.84 ID:YxZv/CkW.net] C++のtemplate（concepts無し）のダックタイピングが好きなら genericsよりmacro_rules!の方がいいよ 701 名前：デフォルトの名無しさん [2024/02/12(月) 22:15:23.35 ID:JpOX7sRf.net] C++のtemplateで正しく関数を呼ぶの難しいよ…… 702 名前：デフォルトの名無しさん [2024/02/12(月) 22:30:02.58 ID:DrV/13x2.net] >>677 静的型付けの意味から解説せなあかんのんか？ 勘弁してくれよ 703 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:30:58.32 ID:9yTkyF6j.net] C++はちゃんとコンセプト使わないとだめだよ 黒魔術は禁止です 704 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:50:06.45 ID:kWCXoXun.net] C++のテンプレートは闇深すぎるよね 705 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:50:36.74 ID:4VueJhli.net] >>686 C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。 一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。 706 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:54:09.63 ID:RSTU7X98.net] >>685 Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる 707 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 23:33:02.01 ID:g0MzjlGR.net] >>692 ダックタイピングの言い回しに前例はなくても原因はあるんだろう そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある 708 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 23:52:54.50 ID:Dj37TM3K.net] 委譲やダックタイピングを理解してないのもどうかと思ったけど ↓これらの区別ができてないのは致命的だと思うので勉強しようね 静的型付け/動的型付け 静的ポリモーフィズム/動的ポリモーフィズム 静的処理/動的処理 709 名前：デフォルトの名無しさん [2024/02/13(火) 00:30:00.87 ID:xtMg5XLl.net] 確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？ 710 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 02:23:26.95 ID:vbRTXFPD.net] ファクトチェック界隈では事実かデマかが確固たる論点だよね 公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ 711 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 03:26:01.95 ID:s0kRtfrq.net] オレオレ定義で擬似問題作るの止めろ。 ダックタイピングについてはWikipediaの解説でいいか。 ja.m.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0 英語版が一番詳しいかね。 712 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 07:31:17.64 ID:KlTxxkJG.net] >>683 フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある 結局パターン通りに作る云々が論じられるのはフレームワークを使う側 713 名前：デフォルトの名無しさん [2024/02/13(火) 08:18:01.41 ID:EJGfS3Xj.net] >>699 アンチパターンや亜種になるだけで全部パターンだぞ 714 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 08:30:13.65 ID:eXWviQcC.net] はじめにパターンありき、ではない 715 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 09:29:40.48 ID:d0oThnC1.net] ダックタイピングはお手軽さを上回るデメリットだらけの悪手法 問題もなく安全で高速なRustのトレイト方式が最善策 トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所 716 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:20:47.32 ID:yeb3oliP.net] うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？ 717 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:23:31.22 ID:T85IlqBy.net] >>703 そんなわけないでしょ 718 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:29:29.95 ID:iVxwtbvh.net] >>703 Pythonは遅いし本質でない実行時デバッグも大変だし 速くて実行前に静的に解決できるRustがベストな言語だよ 719 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:30:11.10 ID:ep9QvdZW.net] >>703 その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう 720 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:31:44.87 ID:mnEJD8Sx.net] >>703 その講師優秀やな 721 名前：デフォルトの名無しさん [2024/02/13(火) 11:11:21.55 ID:mXdLEMzy.net] >>705 その講師も大概だがお前もデバッグをまともにやったことないだろ。 722 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:16:14.81 ID:iVxwtbvh.net] >>708 Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ 723 名前：デフォルトの名無しさん [2024/02/13(火) 11:22:46.51 ID:BKo58x30.net] ここまで俺の自演 724 名前：デフォルトの名無しさん [2024/02/13(火) 11:32:02.27 ID:mXdLEMzy.net] >>709 よっぽどレベル低いことしてない限りそこまでキツくはないわ。 むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。 725 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:43:25.76 ID:bOFev+sF.net] >>703 どーせデータ分析やデータサイエンスの講師だろ くだらない釣りやめろ 726 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:46:14.62 ID:bOFev+sF.net] まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな くだらねえほんと 727 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:53:02.08 ID:rA+hqhZ3.net] 荒らしに構った時点でお前らの負け 728 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:57:48.21 ID:qvC4XjeP.net] >>703が荒らし判定されてて草ww 729 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:05:17.83 ID:n6Gkr1cM.net] >>702 trait boundはgenerics と型パラメータの相互依存が重たい気が。 c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？ 730 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:09:09.09 ID:IxuyFkNI.net] わかる→　Pythonで簡単なスクリプトを書く キチガイ→　Pythonでプログラミング開発する 731 名前：デフォルトの名無しさん [2024/02/13(火) 12:12:34.52 ID:KvZIg8uL.net] Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ 732 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:15:32.69 ID:1UgkqCq+.net] よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？ 733 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:03:33.72 ID:X5Whr4lm.net] 単発NG推奨 734 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:04:48.12 ID:X5Whr4lm.net] 単発NG推奨 連鎖あぼーん推奨 735 名前：デフォルトの名無しさん [2024/02/13(火) 13:49:44.45 ID:BKo58x30.net] スレNG推奨では？ 736 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 14:10:44.85 ID:q0xfm82v.net] また境界知能が暴れてんのか いい加減諦めろよ 737 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 15:09:27.64 ID:j+0n3+gu.net] C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね まだまともに使う機会が来なくて慣れてないけど 738 名前：デフォルトの名無しさん [2024/02/13(火) 19:22:36.57 ID:ui4ZrT7T.net] XML大嫌い 739 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 20:34:52.16 ID:u8WS3GIa.net] >>716 やりたいことがよく分からないけどtraitのassociation typeで解決しない？ I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな C++のconceptだとtypenameに相当するのかな traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど 選択肢が複数あって外部から決められる　⇒　generics型パラメータ（例：AsRef<T>） traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target） みたいに使い分けるといい 全部をgenericsの型パラメータでやろうとするとカオスになる 740 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 21:06:36.86 ID:4D6oEUgV.net] >>716 できる 例えばこのように https://docs.rs/hyper/latest/hyper/service/trait.Service.html pub trait Service<Request> { 　type Response; 　type Error; 　type Future: Future<Output = Result<Self::Response, Self::Error>>; 　 　// Required method 　fn call(&self, req: Request) -> Self::Future; } ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり 型パラメタResponseは依存しない >>726 その二種類の混合も可能 741 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 21:08:42.27 ID:4D6oEUgV.net] ごめん >>727はこうね 型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり 型パラメタRequestは依存しない 742 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 22:37:37.84 ID:s0kRtfrq.net] ちょっと違うなぁ。 c++ template & conceptだと wandbox.org/permlink/74j79ZQ3mbPb2cLO みたいな感じでCircleはf()の影響を受けずに独立させることができる。 draw()メソッドというダックテストを満たせば他はどうでも良い。 Rustのgenericsだと wandbox.org/permlink/CvepQKXOXaNTJoJm みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。 f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。 クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。 743 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:17:32.55 ID:RVgq5WHA.net] それはgeneric constraintがnominalかstructuralかという違い Rustはnominalのみでstructural generic constraintはサポートしてないよ 744 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:20:56.53 ID:KlTxxkJG.net] Pythonは全てにおいてJuliaに劣った言語だな 745 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:28:47.57 ID:u8WS3GIa.net] >>729 Circleを fn f<T: Drawable>(t: &T) -> f64 { t.draw() } に渡したいなら普通に impl Drawable for Circle { fn draw(&self) -> f64 { <Circle as D>::draw(self) } } を追加するな コントラクトの明示を余計な依存関係だとは思わない ちなみに impl Circle { fn draw() -> f64 {...} } みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから impl Drawable for Circle { fn draw(&self) -> f64 { self.draw() } } って書ける １つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし 746 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:28:48.94 ID:RVgq5WHA.net] >>726 >traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target） ある型に対するtrait実装をただ一つだけにしたいものや 自然と一つだけになるような性質のものはassciated typesを使う 使う側はassociated typesのほうが使いやすいので 悩んだらとりあえずassociated typesからはじめてみる 747 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:30:39.22 ID:9eHJiOzP.net] >>729 そこはtrait介在させなきゃいけないところでしょ Rustの方針が正しいと思うよ 748 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:32:24.97 ID:RaqlAe+S.net] traitとかいうつまらない機能にこだわってないでPython極めろよ 時代はAIだぞ 749 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:35:00.89 ID:8wj/C7pB.net] >>735 Rustをただ貶したいだけのやつは黙っとけよ雑魚 750 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 05:05:25.04 ID:uLd8jazY.net] Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。 比較で持ち出すならせめてNimにしろよ。 751 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 05:28:01.52 ID:uLd8jazY.net] >732 >734 Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。 これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？ 呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。 まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。 AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。 752 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 06:58:38.09 ID:t2TEYrx/.net] >>738 >>これはRustが嫌っているクラスの継承みたいなもの クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点 一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する したがってRustでは実装継承とはならず問題が生じない 753 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:00:00.30 ID:HWQ4xiFb.net] 自演きもいなあ 754 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:00:27.71 ID:523CbVaw.net] 実装継承はゴミ 755 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:05:57.04 ID:Uwd6Wtce.net] >>737 Ninはコンパイル時間の無駄があるからゴミ Pythonは実行までの速度が一番早い 756 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:33:52.24 ID:uLd8jazY.net] >>739 全然理解できていないね。 継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。 機能とか実装の問題じゃなくて設計の問題。 757 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:08:30.71 ID:b46uhNiQ.net] >>742 実運用はビルド済だから関係ないな。 758 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:09:58.02 ID:t2TEYrx/.net] >>743 それは継承の問題点 Rustのトレイトは各型が自分で実装するため継承ではない 759 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:41:45.06 ID:W3PM5KGQ.net] >>745 早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ 760 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:51:32.74 ID:t2TEYrx/.net] >>746 早すぎる最適化が問題になるのは継承 Rustのトレイトは継承ではなく合成で用いる 761 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:55:57.66 ID:b46uhNiQ.net] >>745 全然理解できていないね。 >>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。 >729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。 c++のtemplate concept はあくまでdrawのみに依存するという違いがある。 762 名前：デフォルトの名無しさん [2024/02/14(水) 09:07:35.89 ID:L7EuZktb.net] 真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ 763 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 09:20:06.07 ID:BSRmwKLd.net] >>729 C++は酷いな struct定義の時点でdraw()宣言を要求してしまうのか Rustなら struct定義の時点でdraw()宣言を要求せずに済む 後からdraw()という機能(＝Drawableトレイト)が必要になった時点で structに対してDrawableを実装すればいい Rustの方が優れてるな 764 名前：デフォルトの名無しさん [2024/02/14(水) 09:36:07.02 ID:48k6rT3Y.net] >>738 複オジに毒されすぎ オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね 765 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 09:47:17.10 ID:c6aYZ04m.net] >>738 根本的な理解がおかしいので説明すると Rustのtraitは機能を抽象化している 各型はその機能が必要になった時にそのtraitを実装(impl)すればよい 必要な分の各機能(trait)を実装する� 766 名前：ｱとで結果的に各機能の合成となる [] [ここ壊れてます] 767 名前：デフォルトの名無しさん [2024/02/14(水) 09:59:07.19 ID:YhuSf3ik.net] 細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ 実装上の違いを見て異なる概念だと勘違いしてると本質を見失う 768 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:10:46.95 ID:Z6/Yikm0.net] >>750 そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。 >>752 もともとの話はダックタイピングでtraitじゃないよ。 Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？ 769 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:17:10.59 ID:naKe/3pl.net] ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ 770 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:27:45.39 ID:s2Ev9A6j.net] >>738 言語側のサポートならマクロで十分でしょ macro_rules! impl_drawable { ($type:ty) => { impl $crate::path::to::Drawable for $type { fn draw(&self) -> f64 { self.draw() } } }} を定義すれば impl_drawable!(Circle); だけでimpl Drawable for Cirle {...}を生成できる 渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング Drawableに関数を追加したらマクロにも追加すればいい draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる 771 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:44:54.87 ID:AzS2pw5X.net] ダックタイピングは使う側が気をつければなにも問題ないんだよなあ そこらへん理解してないあたり実装をやったことのないエアプなんだろうな かわいそう 772 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:53:25.15 ID:naKe/3pl.net] >>757 その「使う側が気をつければ問題ない」が最悪 ミスが入り込んだ時に気付かず問題を引き起こす ダックタイピングを持ち上げるのはバカだけ 773 名前：デフォルトの名無しさん [2024/02/14(水) 11:07:38.32 ID:RfRsJx+N.net] 使う側が気をつけるならC++も問題ないからな 774 名前：デフォルトの名無しさん [2024/02/14(水) 11:17:22.43 ID:NjTyhCIW.net] >>756 これがいわゆる実装継承の再発明 このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター 775 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:23:15.20 ID:FEB+PUkj.net] >>759 そゆこと だからRustは不要 776 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:28:02.15 ID:naKe/3pl.net] ダメ人間の思想「使う側が気をつければ問題ない」によって 今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史 今後はそのような言語を用いてはいけない 777 名前：デフォルトの名無しさん [2024/02/14(水) 11:51:49.92 ID:L7EuZktb.net] ここで>>9-20の流れを振り返ってみましょう 778 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:52:42.46 ID:3OoaoCBc.net] C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？ リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。 具体的に言えば fn increment(dest: &mut u32) -> u32 { let t = *dest; *dest += 1; t } みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。 779 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:13:59.14 ID:s2Ev9A6j.net] >>760 どこをどう曲解しても実装継承にはならんだろ すべてのケースでマクロ使うとでも思ってるの？ 〇〇の思考回路はよく分からん >>764 Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな std::mem::replace使えば replace(&mut t, t+1) とかできるけど+1するだけなら大袈裟すぎる気がする 780 名前：デフォルトの名無しさん [2024/02/14(水) 12:19:27.37 ID:Cdw7DngV.net] >>761 だから の文が全然繋がってなくてワラタw こういう低能はプログラミングしちゃダメだよ。 781 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:25:13.12 ID:b46uhNiQ.net] >>755 そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。 DbCとか勉強したほうがいいよ。 782 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:29:23.30 ID:naKe/3pl.net] >>767 ダックタイピングが負の遺産であることは自明だが ダックタイピングを使わないことが負の遺産だと主張する君は破綻している 783 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:49:07.16 ID:b46uhNiQ.net] >>768 自明だと� 784 名前：沛ﾘできる証明を示して頂戴。 検証可能性の無い主張は単なる疑似科学だし。 [] [ここ壊れてます] 785 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:52:16.39 ID:KpCwABm3.net] 欠点がない言語なんて無いから言い争ってもね。 786 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:57:57.69 ID:p6Tfi6cJ.net] そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明 787 名前：デフォルトの名無しさん [2024/02/14(水) 13:07:28.33 ID:L7EuZktb.net] たし🦀 788 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:09:31.24 ID:aR1xhX8a.net] おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき 789 名前：デフォルトの名無しさん [2024/02/14(水) 13:16:05.40 ID:eD+V22zq.net] drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる 適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ 790 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:33:10.33 ID:Q08aEmFz.net] 境界知能が可視化されてる 791 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:53:52.28 ID:Z6/Yikm0.net] >>774 当たり前だろ。 インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。 792 名前：デフォルトの名無しさん [2024/02/14(水) 13:55:32.21 ID:eD+V22zq.net] >>776 ダックタイピングはその契約書が定義されてないのが良くない Traitは契約書の定義みたいなもんだ ダックタイピングは白紙の契約書にサインするようなものだ 793 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:57:04.55 ID:s22bd+Hs.net] >>775 お前のこと？ 794 名前：デフォルトの名無しさん [2024/02/14(水) 14:31:04.48 ID:h4S8S2sP.net] >>777 これな 795 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 14:41:15.13 ID:3OoaoCBc.net] >>765 replace だと借用規則に引っかかってエラーになるようです。 まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが…… 796 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 15:12:12.70 ID:s2Ev9A6j.net] >>780 Copy型だから通りそうな気がしたけど無理だったか 何か技がありそうだけどそこまでするほどの問題じゃないよな 797 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 15:36:36.14 ID:S2bQYQek.net] >>764 Rustで++は排除されている 理由はたくさんあるようだが 例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか 前置と後置の間違いミスも多いことに加えて 生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや move/copy問題もあったかな 798 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:02:27.29 ID:3OoaoCBc.net] >>782 そんな話はしてないです。 役に立つことを言えないなら余計な茶々入れるな。 799 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:29:39.74 ID:ona7PgM1.net] >>783 おまえ質問してる分際でキチガイなのか？ そういう態度を改めないなら二度と教えてやらんぞ fn increment(dest: &mut u32) -> u32 { 　std::mem::replace(dest, *dest + 1) } 800 名前：デフォルトの名無しさん [2024/02/14(水) 16:36:51.93 ID:b+wxXawK.net] 質問している人間相手なら関係ないことを書いて良いわけではない 801 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:42:22.39 ID:3OoaoCBc.net] >>784 結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。 質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。 802 名前：デフォルトの名無しさん [2024/02/14(水) 16:46:13.61 ID:L7EuZktb.net] ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん…… 803 名前：デフォルトの名無しさん [2024/02/14(水) 16:46:26.67 ID:b+wxXawK.net] 一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない 804 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:51:03.66 ID:3OoaoCBc.net] >>788 あれは誤読 (?) なんでしょうか。 茶化しているように受け取ったので腹立たしかったのですが、 そうだとしたら >>783 は言い過ぎですね。 ID:S2bQYQek さん、すいません 805 名前：デフォルトの名無しさん [2024/02/14(水) 17:05:32.23 ID:ZK4bCcm/.net] 人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい 806 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 17:06:20.11 ID:Q08aEmFz.net] だから境界知能なんでしょ 807 名前：デフォルトの名無しさん [2024/02/14(水) 17:19:45.82 ID:qgmjNVo3.net] 腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ 気に入らなかったらスルーする程度には心に余裕を持っておこう 808 名前：デフォルトの名無しさん [2024/02/14(水) 17:26:03.70 ID:h4S8S2sP.net] tmuxよりscreen派だよ。 809 名前：デフォルトの名無しさん [2024/02/14(水) 17:50:47.59 ID:6CXfQ6Kw.net] 個人的には後置インクリメントだけを関数化するのは微妙に感じる fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う 810 名前：デフォルトの名無しさん [2024/02/14(水) 19:51:05.67 ID:7rKeAYke.net] >>762 こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。 811 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 19:57:21.78 ID:b46uhNiQ.net] >>777 c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか…… ダックタイピングは契約の主体・時期・範囲が違うという話だかね。 812 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 20:14:14.28 ID:yh2p7tDo.net] >>796 C++では機能の異なる同名メソッドを区別できないから欠陥品 813 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 20:52:10.35 ID:b46uhNiQ.net] >>797 引数・戻り値で区別できるだろ。 814 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:01:37.45 ID:yh2p7tDo.net] >>798 それに依存してしまうのがC++の限界 815 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:18:41.79 ID:b46uhNiQ.net] >>799 名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。 816 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:58:58.38 ID:H5X+9PTs.net] >>796 それだとRustでいうところのトレイト境界を課すことができないな つまりC++では安全に呼び出すことができない 呼び出したメソッド内で出来ること出来ないことが定まらないため 817 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 22:13:29.10 ID:uLd8jazY.net] >>801 「呼び出したメソッド内で出来ること出来ないこと」 て何？ Rustのtraitて、副作用のコントロールできたっけ？ 818 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 22:26:20.82 ID:8gvFvpJ5.net] traitのprovided methodのdefault実装で呼び出せるのはrequired methodと trait境界がある場合はそのtraitのmethod そしてそれらで構成された他のprovided methodのみ って制限をC++でどうするんだろ 819 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 23:19:42.33 ID:3OoaoCBc.net] >>803 コンセプト。 820 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 23:20:56.22 ID:3OoaoCBc.net] >>792 毎度毎度のことで余裕を削られた最後だったんだよ。 821 名前：デフォルトの名無しさん [2024/02/15(木) 00:20:11.01 ID:AyUC+mx+.net] 毎度毎度のことという認識を持っていながらなぜここに書き込むのか 822 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 00:23:07.31 ID:x2y7hFPc.net] >>806 せやな。 けど日本で比較的活発な Rust コミュニティというとここなんよ。 823 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:06:08.60 ID:13EQhuxe.net] >>804 concept記述が多すぎて書いててイヤになるな 普及しそうにない仕様がまたC++に増えた感じ Rustが必要な機能を洗練して提供しているのと対照的 824 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:43:10.62 ID:j4EJcuA3.net] >>808 洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。 枯れた既存プログラムの置き換え用途が無難なところかと。 コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。 825 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:55:56.64 ID:hKdVOM0D.net] >>809 Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に RustやめてGoにする宣言してる 理由を真面目に話してるから一見の価値のあり 826 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:11:38.37 ID:j4EJcuA3.net] >>810 検索したけど見つからなかった…… リンクある？ 827 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:17:50.82 ID:Me0Wd39H.net] [Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY) 828 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:19:40.94 ID:j4EJcuA3.net] >>812 サンクス。 家帰ったら見るわ。 829 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:48:36.69 ID:UeUfm3Ct.net] >>812 見た ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い そして批判されてるのはなぜかTypeScrpt Goについてはシンプルなのが好きでジェネリックが導入されてワクワク Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ Rustの型システムはとても素晴らしいけど、 830 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 09:52:51.93 ID:x2y7hFPc.net] >>808 過去のコードと矛盾しない形での後付けだからな。 C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。 簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。 Rust だって歴史が積み重なればいずれそうなる。 「綺麗なのは使われないもの」という格言を聞いたことないか？ Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。 規格策定・処理系保守のリソースは無限なわけではないしな。 831 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 09:55:25.99 ID:LYiZEs3M.net] エディションはすでに複数あるけど あっても無理とか問題起きるとか 実例あるの？ 832 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:07:56.04 ID:x2y7hFPc.net] >>816 問題が抑えられているのは問題がないように保守されているからで、 その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。 今問題があるとかそういう話じゃないから未知数と述べてる。 833 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:11:47.35 ID:9MXGquuv.net] C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる 834 名前：デフォルトの名無しさん [2024/02/15(木) 10:21:13.40 ID:qaCOVcST.net] まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある 835 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:32:36.57 ID:LYiZEs3M.net] >>817 今は良くても未来は何が起こるかわからない論法は 何にでも使えるから意味ある話とは思えないけど… 836 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:37:24.02 ID:x2y7hFPc.net] 「出来る」ということを大前提として確信できて、 その上で「上手く出来る」ならより良いってのが産業的な考え方だ。 おおよその場合に上手く出来ても ちょっとした想定外に直面したときに破綻するようでは使い物にならない。 現実の問題ってのは想定してないところから出てくるものだから そういうことも乗り越えられることを証明するには 実績 (歴史) を重ねるしかしょうがないんだ。 C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。 Rust は今の時点では実に使いやすいように見えるが、 本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。 837 名前：デフォルトの名無しさん [2024/02/15(木) 10:38:37.60 ID:TrooctNX.net] 今の時点で使いやすければなんでもいいんだYO 838 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:45:22.07 ID:9MXGquuv.net] C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない これだけ増築工事を重ねてもまだ見込みが立たないまま 839 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 11:47:28.36 ID:olqTmpaN.net] C++の知識は大いに再利用されているので現実世界の変化は小さい 想定外かもしれないのは変化の大きさではなく 現実世界を定義できないことだ 定義できるのは理論だけ 840 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 12:02:34.79 ID:oxTsPXaA.net] >>821 今の想定が甘いとか具体的指摘なかったら 想定外の対処ができてないから駄目は無敵論法 841 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 14:40:35.94 ID:wvzNp0zm.net] そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分 842 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 14:47:01.34 ID:z+RD4XEG.net] サーバーサイドは群雄割拠時代よね Rust、Go、Java/Kotlin、C#いっぱいある 843 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:20:13.71 ID:x2y7hFPc.net] >>825 駄目とは言ってない。 駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。 844 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:46:19.25 ID:606b12LT.net] >>828 あなたの話相手してもrustでも他言語でもいいけど 問題回避のためにこういう仕様や実装にすべきじゃないか みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね 845 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:50:52.01 ID:olqTmpaN.net] すべてを疑っても産業だけは疑いようがないって話なら 想定内と想定外の境界がどの辺にあるのかはなんとなくわかる 846 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:21:54.77 ID:SzbBTI0k.net] >>814 Rustは型〇ナニーで長時間バトルだったと言ってるぞw >>812動画の人がいくら天才でも2年間かき回したのは頂けない 847 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:26:25.25 ID:BHoNDVf7.net] Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい 848 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:31:26.55 ID:dtRRoOMy.net] Ruby は、Go/Rust/Elixir の3大言語を超えた！ Rust の上昇は止まったか？ Stack Overflow 米国年収。2022 -> 2023 Ruby : 9.3 -> 9.9 万ドル Elixir : 9.3 -> 9.6 Go : 8.9 -> 9.3 Rust : 8.7 -> 8.7 多くの言語 : 6.5〜7 -> 7.3〜7.8 PHP : 5 -> 5.9 Dart : 4.4 -> 5.6 849 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:35:21.87 ID:eOw5Ad1t.net] >>832 夢見てないで現実見ては？ https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/ 850 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:41:41.98 ID:wvzNp0zm.net] >>812 流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草 851 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:53:07.04 ID:8jpdfcc8.net] >>835 Rustインフルエンサーの成れの果てですなw 852 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:08:05.70 ID:uSGIT3N+.net] >>834 せめて用途別のプログラミング順位を挙げてくれ …単発に言っても無駄か😭 853 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:08:23.00 ID:giVh/goG.net] Goは２年も続けられるだろうか 大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら 返されたResultを無視してもコンパイラが警告出さないからやめた Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに ↓を見て気持ち悪さを感じる人には向かない file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる 854 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:11:15.85 ID:x2y7hFPc.net] >>829 情報が充分じゃない (から議論を始めることさえできない) ことが リスクだという話をしているつもりなんだが、伝わってないのか？ どんな問題が起こるのか事前にわかれば苦労しないよ。 起きたことに対処し続けるしか仕方がないが 可能なら自分が対処する当事者にはなりたくない。 855 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:19:47.46 ID:SZiIKMeC.net] 「Go」、2月のTIOBE指標で過去最高8位に https://japan.zdnet.com/article/35215159/ https://japan.zdnet.com/storage/2024/02/13/0ee0eaf7a75e201ad2ee580740569609/240213_tiobe.png 856 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:24:55.60 ID:x2y7hFPc.net] >>838 悪いほうがよい (Worse is Better) 原則というものも知られている。 正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。 問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。 正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。 857 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:31:33.80 ID:j4EJcuA3.net] >>829 >>839 このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。 あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。 858 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:34:16.56 ID:3rKktGL8.net] >>817 これはごもっともな意見 50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題 859 名前：デフォルトの名無しさん [2024/02/15(木) 19:40:03.38 ID:TrooctNX.net] 50年後にC++23はサポートされているのだろうか というかC++は50年後もアップデートしているのだろうか 860 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 19:52:43.98 ID:flxKbqvK.net] >>843 cargo fix --edition のあるRustは至れり尽くせりだよ 861 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 20:00:49.77 ID:nijJOd3e.net] >>844 既にC++17とC++20で以前導入の機能の削除が大量に行われている 862 名前：デフォルトの名無しさん [2024/02/15(木) 20:11:12.94 ID:Zy70aZMD.net] じゃあもうRustで良いじゃん 863 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 20:27:48.49 ID:Y7OgkdHD.net] CになかったC++の機能は削除してもチューリング完全が保証される 逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター 864 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 22:27:00.96 ID:MX4y8Eg+.net] >>840 Kotlinが上がってきてるのうれしい Fortranも上がってるのはなぜだ 865 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 22:56:46.83 ID:x2y7hFPc.net] C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。 たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。 基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。 実質的には Rust のエディションみたいなことにはなってるんだよなあ。 866 名前：デフォルトの名無しさん [2024/02/15(木) 23:13:05.86 ID:17JkefKn.net] llvmも実装はc++だし。 867 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 23:33:02.83 ID:CqGYBNeH.net] >>850 Rustは必ずeditionを明示しないといけないから あるソースコードがどのeditionなら確実に動くのか明確にわかる そしてそのeditionを指定してコンパイルも通り実行もできる しかしC++は当初のC++11に従いコンパイルできて動いていたものが 今はC++11の機能のいくつかは削除されてしまっているために 868 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 23:44:16.83 ID:x2y7hFPc.net] >>852 C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが 869 名前：デフォルトの名無しさん [2024/02/15(木) 23:57:58.06 ID:m2l7AKkd.net] 一般人と同等の読解力を複オジに期待しないこと 870 名前：デフォルトの名無しさん [2024/02/16(金) 01:17:00.51 ID:2uzjzXJf.net] cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ 勉強になるわ〜 871 名前：デフォルトの名無しさん [2024/02/16(金) 02:58:58.82 ID:T31Boec7.net] >>853 名前が同じならなんでも良い…… ってこと！？ 872 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 05:29:44.45 ID:VnZfCvN7.net] >>856 「規格が同じなら」ということだよ。 c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。 873 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 06:06:29.14 ID:VMcEA5aE.net] RustのEdition方式が優秀すぎる 新たな機能の規格で分けるのではなく 各Editionは後方互換性の変化で分けているため 過去に書かれたコードも必ず動く 874 名前：デフォルトの名無しさん [2024/02/16(金) 08:50:06.12 ID:T31Boec7.net] >>857 規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん 875 名前：デフォルトの名無しさん [2024/02/16(金) 08:50:57.44 ID:T31Boec7.net] 規格から機能ごと消えるんならよう 876 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 08:57:09.07 ID:MpEo3rxP.net] >>859 消してないけど何いってんの？ 877 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 07:36:35.11 ID:pKHDV/cx.net] ID:T31Boec7 流石にこいつ日本語能力なさすぎだろ ガイジかな？ 878 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 07:58:38.87 ID:y2U3e6uM.net] mojo vs rustでmojo公式とnetflix天才とRust本著者で盛り上がっている https://www.youtube.com/watch?v=MDblUyz0PtQ >>814,835 早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ 879 名前：デフォルトの名無しさん [2024/02/17(土) 08:38:43.36 ID:P+bU7/QC.net] >>863 copilotで要約して貰うのが時間も短縮できるのに無能だなw 880 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:31:52.42 ID:/wuPDCL7.net] >>864 この天才同士のディスカッションを楽しめないなんて損してんね🥲 881 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:55:10.10 ID:wfN7KjH7.net] Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。 882 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:54:06.77 ID:p6Fewl3N.net] >>863 この人の英語聞き取りにくい もうちょっとゆっくり喋って欲しい 中身うっすいのにさ 883 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:58:21.47 ID:p6Fewl3N.net] >>862 普通に境界性知能ってやつでは？ この手のは全部そうだと思うようにしてる 884 名前：デフォルトの名無しさん [2024/02/17(土) 17:40:44.30 ID:SxaDWram.net] >>863 ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ 公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ 見識を疑うレベル 885 名前：デフォルトの名無しさん [2024/02/17(土) 18:56:01.48 ID:bc7xcSj4.net] Netflixの天才がいかがでしたかブログレベルの動画を出すとは 886 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 19:01:49.62 ID:hd6B0gbf.net] >>863 動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!! Mojoコンパイラ賢いな 887 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 19:07:25.89 ID:1+LtKHMi.net] 以前からMojoがCより何倍も速い！とかやってるけど ベンチ方法や条件などが何かおかしい 888 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 20:11:15.92 ID:lHr0QJnq.net] SIMDが効くような恣意的なベンチだしな 889 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:00:37.77 ID:QWthdRCX.net] でもデータを見てから断罪するのは俗っぽいから データを見ないでロジハラするのがベター 890 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:16:16.12 ID:lHr0QJnq.net] DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ あと末尾最適化する くだらなすぎる 891 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:40:36.38 ID:WeOJL5ES.net] え？　Rustって末尾最適化できんの？ 892 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 23:56:23.75 ID:uU5eCENW.net] Rust Reserved keywords KW_ABSTRACT : abstract KW_BECOME : become KW_BOX : box KW_DO : do KW_FINAL : final KW_MACRO : macro KW_OVERRIDE : override KW_PRIV : priv KW_TRY : try KW_TYPEOF : typeof KW_UNSIZED : unsized KW_VIRTUAL : virtual KW_YIELD : yield 893 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 09:43:13.97 ID:2fU6EVDD.net] >>873,875 同じLLVM系なのにRustが3倍遅いのかよ!! Mojoがコンパイラ賢いのかRustコンパイラが... 894 名前：デフォルトの名無しさん [2024/02/18(日) 10:23:17.76 ID:8VIVYK48.net] あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない 895 名前：デフォルトの名無しさん [2024/02/18(日) 10:24:13.10 ID:8VIVYK48.net] ちなみにSIMD云々は本質じゃないよ 896 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 10:33:07.03 ID:diN1NxZN.net] >>879が3倍速いRustコードを出すってよ 897 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 10:46:23.01 ID:fnRzA2e2.net] これはGoの方が速いんじゃないか？ 898 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:13:09.56 ID:NoFg1fuK.net] GoはGCを伴う言語だから論外 MojoはC/C++/Rustより3倍速い 899 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:27:28.89 ID:YdXgtYKq.net] >>878 同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い 恣意的な例である 900 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:36:55.83 ID:a/PaZk8n.net] そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した なんか懐かしい 901 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 12:18:39.29 ID:Wi99yBdV.net] 20年後にRustを懐かしむスレはここですか？ 902 名前：デフォルトの名無しさん [2024/02/18(日) 14:55:22.54 ID:LhS8zjp4.net] 20年後には流石にもっと良い言語が登場して流行っていることを期待している 903 名前：デフォルトの名無しさん [2024/02/18(日) 15:22:23.80 ID:L2mk1x1a.net] >>885 アンダースヘルスバーグ天才だよな ボーランドでDelphi作って マイクロソフトでC#とTypeScript作って 904 名前：デフォルトの名無しさん [2024/02/18(日) 15:34:23.48 ID:CKqOMEmo.net] >>888 MAUIくん！病室に戻るんだ！ 905 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 09:27:30.10 ID:JlpPRp2V.net] >>888 俺は天才とは思わない この人ってお手本となる言語があって それをよりよくすることは得意な気がする 906 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 10:19:49.07 ID:j7eyydGe.net] 普通の人が実務で使うような汎用プログラミング言語は とびぬけた画期的なパラダイムで構成しても使い難いし、 ひとつひとつはどうということはない要素を上手く組み合わせる バランス感覚が重要って感じはあるね。 天才的な閃きでどうにかするようなものではない。 907 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 11:58:45.15 ID:r1DaNm3S.net] 既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな 908 名前：デフォルトの名無しさん [2024/02/19(月) 12:07:19.13 ID:BnjhEPJH.net] 自分は何も出来ない無才なのによく言うわw 909 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 14:11:02.99 ID:JlpPRp2V.net] C#→Javaのビミョーなところを直す Delphi� 910 名前：ｨPascalのビミョーなところを直す TypeScript→JSに型付け [] [ここ壊れてます] 911 名前：デフォルトの名無しさん [2024/02/19(月) 14:41:59.29 ID:FfoO1n86.net] Rustのビミョーなところを直して欲しい 912 名前：デフォルトの名無しさん [2024/02/19(月) 15:33:58.75 ID:BnjhEPJH.net] R#だすかー 913 名前：デフォルトの名無しさん [2024/02/19(月) 16:37:49.01 ID:pyxz0P7h.net] Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな 広報+コントリビューター+社外との政治的調整役 914 名前：デフォルトの名無しさん [2024/02/19(月) 18:10:38.68 ID:VthC7yJG.net] R#とか絶対統計処理用の言語じゃん 915 名前：デフォルトの名無しさん [2024/02/19(月) 18:20:06.89 ID:BnjhEPJH.net] そうだな じゃあRustyNailって名前にするか 916 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 18:38:07.38 ID:j7eyydGe.net] ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。 だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。 917 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 18:50:17.05 ID:JlpPRp2V.net] 割とマジでヘルスバーグ動きますの可能性はある Carbon、Go→Google Rust→Mozilla ？→Microsoft この流れは確かにある 918 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:05:38.11 ID:gidehIA9.net] GoogleもMicrosoftもRust支持で Carbonの公式FAQにはRustが使えるならRustが良いと明記されている 919 名前：デフォルトの名無しさん [2024/02/19(月) 20:34:12.24 ID:VthC7yJG.net] Rust支持というより、現状最良の選択肢がRustであると認めているだけでは なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う 920 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:55:09.09 ID:WSW9DaUh.net] 代替の芽が今ないから早くて十数年以上先 MojoはPythonベースで関心が数値計算に向いていて違う 921 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:57:44.38 ID:34j+4tJw.net] Netflixの天才は2年かけて右端の住人になったのか https://pbs.twimg.com/media/GDa2G6iWIAAsyh3.jpg:orig これからは目立った実績が無いのにRust歴が長いと 型〇ナニーで時間溶かしてると認定される 922 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 21:23:20.71 ID:MW9zngaI.net] >>905 Go？ Goはランタイムが大きくGCベースの言語だからRustの代わりにならんよ 923 名前：デフォルトの名無しさん [2024/02/19(月) 21:38:55.37 ID:BnjhEPJH.net] >>906 結局さ一周回ってAdaで良いんじゃ？ 924 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 21:46:39.06 ID:VDl5KQ6V.net] オーガスタちゃんが平伏せと命令する言語？ 925 名前：デフォルトの名無しさん [2024/02/19(月) 22:19:23.32 ID:hvnIqBoW.net] Web用途だとRustはtokioと関連ライブラリが必須だからGoよりランタイム大きくなるけどね 926 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 22:41:42.37 ID:+OQMy10I.net] >>909 Rustバイナリが小さい tokio+hyper他で特別な指定もなく普通に作ったweb server実行バイナリがstrip後に1.3MB 927 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 23:17:36.45 ID:aeOZND98.net] サーバーエンドでバイナリサイズなんてどうでもいいけど専有メモリ量がJavaやGoより小さいのはよい 928 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 03:09:16.36 ID:sgoVzbhC.net] Rustってcargo buildとかやると通信量結構えげつない 929 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 08:39:03.07 ID:VuVDzPkr.net] 依存関係があるライブラリをダウンロードすれば Rust に限らず それなりにたいくさんひっついてくるのはよくあること。 930 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 08:51:21.95 ID:HobPlk1l.net] C++でビルドする前にapt-getしてね、ってのも同じことだしな 931 名前：デフォルトの名無しさん [2024/02/20(火) 09:54:42.94 ID:avQkuhyK.net] Rustだと依存ライブラリの数が桁違いに多くなるのが原因 932 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 10:20:25.82 ID:VuVDzPkr.net] お前それ、 JavaScript の前でも同じこと言えるの？ 933 名前：デフォルトの名無しさん [2024/02/20(火) 10:20:33.45 ID:kmanQ674.net] >>903 その通り Rustの次に期待 934 名前：デフォルトの名無しさん [2024/02/20(火) 13:00:59.06 ID:MPPpoDC+.net] >>907 ブロックが波カッコだったらなぁと思ったことある。 935 名前：デフォルトの名無しさん [2024/02/20(火) 13:46:52.53 ID:sgoVzbhC.net] 一回DLしたパッケージOSにキャッシュしてくれればいいんだけど そうじゃないから学習でやってると無尽蔵に取りにいくのはなんとかならんのか 936 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:05:25.22 ID:VuVDzPkr.net] >>919 えっ、普通にキャッシュしますが……。 937 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:18:44.11 ID:YaBXE8T+.net] >>919 1回しかダウンロードしない その後はそのキャッシュを用いる 938 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:47:39.06 ID:NZma60kC.net] それよりディスク使いすぎだろ ビルドの中間生成物が簡単にギガ単位になる 939 名前：デフォルトの名無しさん [2024/02/20(火) 15:44:30.40 ID:s70xdtq8.net] >>922 それな 複雑なコンパイラでインクリメンタルビルドを高速化するには空間性能を犠牲にするしかないんだろ 940 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 15:54:29.36 ID:VuVDzPkr.net] 大きなライブラリは動的リンクすることにしてもいいけど、 そしたら実行環境の管理と開発環境の管理を分離しづらくて面倒くさくなる。 どうやったってどこかに負担はかかるならストレージさえあれば だいたい解決ってほうがいいという戦略なんだろ。 941 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 18:32:02.94 ID:NZma60kC.net] Rustほどディスク使う言語他にあるの？ 桁違いに多いと思うんだが 942 名前：デフォルトの名無しさん [2024/02/20(火) 18:32:44.23 ID:pzacWR0B.net] ディスクはまあTB行かなければ何をやっても良いわ 943 名前：デフォルトの名無しさん [2024/02/20(火) 18:46:34.01 ID:2x98KEBQ.net] ビルドキャッシュの一部を何もしなくてもプロジェクト跨いで共有してくれればまだいいんだけどね 用途的に外部ストレージやNASに置くようなものじゃないというのが困るところ 944 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 18:56:04.80 ID:qhUDP5tY.net] Rust (cargo)のソースダウンロードしてすべて同一マシンでビルドする前提の設計はいいと思う。 soとかdllとかjarみたいなの、あまり信頼したくないというか。 945 名前：デフォルトの名無しさん [2024/02/20(火) 1 ] [ここ壊れてます] 946 名前：9:01:23.73 ID:aUCxPGU2.net mailto: Crates.ioを信頼してどうせ落ちてきたもの毎回ソース全行確認したりはしないんだから、落ちてくるものがバイナリになっても別に良いかな [] [ここ壊れてます] 947 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 19:12:55.50 ID:HobPlk1l.net] so使ってsymbol not foundとかよくあるしな 基本的にC++ソフトのビルドは作者が使ってるディストリでしか再現しないと思ったほうがいいくらい しょうがないからDockerでビルド環境作ったりするけど面倒だしディスクも食うし 結局ディスクキャッシュが多少多いくらいで済んでるRustが一番マシな気がする 948 名前：デフォルトの名無しさん [2024/02/20(火) 19:56:43.04 ID:hRyg00SZ.net] soが悪いのではなくまともなパッケージマネージャーもまともな依存解決ツールもないのが悪い 949 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 20:07:01.59 ID:+of8n4/M.net] 確かにOS非依存のC++標準パッケージマネージャと中央レジストリがあれば良かったかもね ただその場合でもABIが不安定なのはどうしょうもないから Rustと同じく手元で全部コンパイルする方式になったと思うけど 950 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 20:11:30.03 ID:VuVDzPkr.net] Cargo 風の管理をする C++ 用パッケージマネージャはある。 最初からそのパッケージマネージャ用に構成してくれてないと なかなか素直にはビルドできないことに変わりないんだけど。 パッケージマネージャが優秀でも C++ 世界では 「統一されていない」ことが面倒くささになってる。 951 名前：デフォルトの名無しさん [2024/02/20(火) 21:39:15.46 ID:1smOJz8O.net] そう考えると中間言語形式で配布できてAOTコンパイルもできる.NETがさいつよって話？ 952 名前：デフォルトの名無しさん [2024/02/20(火) 21:43:07.30 ID:BYbBGAeA.net] NuGetが使いやすいと感じた事がないし、充実していると感じたこともない 953 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 21:59:58.18 ID:VuVDzPkr.net] >>934 dotNET は事前コンパイルしてもランタイムサポートの分厚さ (にかかる実行コスト) は避けられないので コンピュータの性能を絞りきるようなつよつよ最適化は無理じゃないかなぁ。 いろんな方式の良いところを上手く取り入れて総合的には良いものに仕上がってるとは思うけど それが最強かというと状況によるんじゃないの。 954 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:14:04.42 ID:sgoVzbhC.net] >>921 チャプターサンプル毎にプロジェクト作ったら毎回DLしてるように見えるけど 955 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:16:27.29 ID:FbkkUU+G.net] パッケージの使い勝手という意味ではdocs.rsの存在も大きい気がするな どんな野良ライブラリでも決まった場所に決まったフォーマットのAPI一覧が確実に存在するというのはかなり便利 956 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:30:04.17 ID:VuVDzPkr.net] ドキュメントを全く書かなくても少なくとも公開されている一覧はわかるってのは強い。 最悪の場合でもコードへのリンクもあるし。 Haskell のリポジトリがこういう感じだったので他の言語でもこれくらいやればいいのにと思ってたから Rust で取り入れてくれたのはかなり嬉しい。 957 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:37:39.60 ID:NZma60kC.net] >>926 いや、スマホでセルフ開発する時に困るだろ？ 958 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:45:53.34 ID:VuVDzPkr.net] >>940 そんなやつはおらんで〜〜 959 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:47:07.61 ID:1CgxDriU.net] ス、スマホ？ 960 名前：デフォルトの名無しさん [2024/02/20(火) 23:05:21.55 ID:YDnp1LJs.net] procマクロとかコンパイル環境で展開したいものを除くとtarget指定した環境に依存するだけだから手元でコンパイルする必要性は全くない いずれにしろどこでビルドするかと中間生成物のサイズが異常にデカくなる話とは別の話だよね 961 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 23:07:55.15 ID:VuVDzPkr.net] もしスマホで開発する人がいたとしても レンタルサーバに接続して表面上の操作にスマホを使うだけで、 実質的なストレージ・計算リソースはサーバのものを使う形にするのが普通。 スマホ内で完結させようとしたらツールチェインをセットアップするだけでもクソ面倒くさい話になるぞ。 962 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 00:35:56.53 ID:ax8uXPdD.net] 働いてないとスマホで開発するとかいう前代未聞の人間がいるんだな 963 名前：デフォルトの名無しさん [2024/02/21(水) 01:44:30.82 ID:q3i686zw.net] スマホで開発はむしろ最先端 964 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 05:17:16.65 ID:cGlapTzK.net] iPhoneが出たばかりの頃から、脱獄して開発環境を入れてObjective-Cでプログラミングしてる人は一定数居ただろ。 最近では、どのプログラミング言語でも使えてLinux（Android）と遜色ないよ。 今のスマホは、外部モニターも外部SSDも繋げるし、外部グラボのGPUでLLM開発だってできる。ほぼほぼRaspberryPi5と変わらないよ。 だからこそ組み込みにも強いRustが注目されてるんｼﾞｬﾏｲｶ 965 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 05:44:41.84 ID:cGlapTzK.net] スマホでRustformersからLLM開発する場合、ローカルにOllama入れとくか、サーバにGPT-4やLlama2を入れとくかぐらいの違いしかない。 Google Coralもスマホでも使える前提の製品で、このチップは発熱量が減ればスマホに内蔵されるだろう。 実際、Vision Transformerのような技術を応用しているApple Vision Proが製品化されたから、スマホからこういった機器に移行するのかもしれない。 今後数年間、これらの技術動向から目が離せない状況が続くんだろう。 966 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 08:28:43.22 ID:/iiJfWDN.net] ダウンロードしたクレートキャッシュの自動削除はもうすぐ来そう ビルドキャッシュの自動削除はその後実装予定っぽい https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning.html 967 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 08:31:36.21 ID:/iiJfWDN.net] グローバルなビルドキャッシュ共有の話も予定には挙がってるね 968 名前：デフォルトの名無しさん [2024/02/21(水) 09:05:07.84 ID:33Eh81yS.net] >>934 何を基準でさいつよかの定義による デスクトップ Web バックエンド iOS/Android ゲーム とC#だけで全部作れる 各分野でベストな選択肢では無いけど平均点以上のベターではある とりあえずC#使えれば何でも作れるという意味ではさいつよ 969 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 09:19:16.71 ID:VUY6mIOu.net] >>951 .netの毎年の長文blog最適化レポートを見ると2年後くらいでNativeAOT最適化がC/C++に肉薄すると思う 970 名前：デフォルトの名無しさん [2024/02/21(水) 10:25:34.81 ID:ygn/feiE.net] デスクトップ Web バックエンド iOS/Android ゲーム とC言語だけで全部作れる 各分野でベストな選択肢では無いけど平均点以上のベターではある とりあえずC言語使えれば何でも作れるという意味ではさいつよ チューリング完全なので 971 名前：デフォルトの名無しさん [2024/02/21(水) 10:33:55.14 ID:3B94ePzU.net] 無能なやつほどゴールデンハンマー症候群に罹患しやすい 972 名前：デフォルトの名無しさん [2024/02/21(水) 10:37:42.60 ID:33Eh81yS.net] >>953 嘘ばっかりだなw 973 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 12:23:52.50 ID:FRHKNAr+.net] >>949 さすがに問題として認識はしてたんだな スマホセルフ開発の日は近い 974 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 12:50:43.67 ID:ax8uXPdD.net] マジでスマホしか持ってないの？ クソワロタ 975 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 13:41:48.13 ID:s/93fWsg.net] ウェアラブル系の機器には失望した。 どこへでも持っていけるよりどこへも往く必要のないインフラこそ目指すべき未来だろ。 976 名前：デフォルトの名無しさん [2024/02/21(水) 14:32:00.13 ID:T2E+AzfY.net] >>954 同意 977 名前：デフォルトの名無しさん [2024/02/21(水) 15:10:22.61 ID:KvtS9dqN.net] >>958 背もたれ付きベッド 978 名前：デフォルトの名無しさん [2024/02/21(水) 15:11:12.28 ID:KvtS9dqN.net] >>953 Rustはチューリング安全だぞ 979 名前：デフォルトの名無しさん [2024/02/21(水) 16:06:34.40 ID:RjxZ1GsP.net] >>957 働いてないと「スマホで開発==スマホしか持ってない」という発想になるんだなww 980 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:15:10.41 ID:cGlapTzK.net] >>960 ベッドといえばフランスベッドが取り扱ってるAI 視覚支援機器『オーカム マイアイ2』(OrCam MyEye 2)は、 イスラエルのオーカムテクノロジーズ（OrCam Technologies Ltd）の製品だったな。 これは活字の読み上げみたいだけど、寝具メーカーは、どこへも往く必要のない未来インフラをAI使って目指してるんだろう。 ウェアラブル系が狩猟型・動物型とすれば、寝具系は農耕型・植物型なんだろうな。人間は生活の約３割は寝てるんだから当然だけど。 981 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:30:25.40 ID:vYwp44u6.net] 表向きはどうであれたぶん寝たきり用だから話を膨らませるのはそのくらいにしとけ 982 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:47:28.48 ID:OHlXXLmE.net] いくらなんでもスマホでコーデングはせんやろ 983 名前：デフォルトの名無しさん [2024/02/21(水) 16:49:23.05 ID:1mshJDzd.net] 寝たきりで親指しか動かないとかならスマホでコーディングするかもしれん 984 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:54:05.86 ID:s/93fWsg.net] 性能がどうこうよりもシンプルに画面が狭いのはすごくつらい。 無理。 985 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 18:17:59.27 ID:ax8uXPdD.net] >>962 いやお前に当てはめてるだけだぞ 何言ってんだ？ 986 名前：デフォルトの名無しさん [2024/02/21(水) 21:37:40.46 ID:4F0o6gVI.net] はちみつ餃子氏最近見ないからRust関連は触れないことにしたのかと思ったらコテ外して書き込みに来ててわろた 987 名前：デフォルトの名無しさん mailto:sage [2024/02/22(木) 16:00:18.09 ID:o0M/RgFs.net] >>969 新スレ立ったときに名前欄に入力するのを忘れてたままやな 988 名前：デフォルトの名無しさん mailto:sage [2024/02/22(木) 23:42:55.14 ID:1e40BABA.net] >>949 毎晩ならその機能もう使えるのか 989 名前：デフォルトの名無しさん [2024/02/23(金) 12:05:46.18 ID:vPqrWVzU.net] 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。 もちろんその場合は外付けのディスプレイとキーボードつけるだろうが。 990 名前：デフォルトの名無しさん [2024/02/23(金) 12:05:51.79 ID:vPqrWVzU.net] 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。 もちろんその場合は外付けのディスプレイとキーボードつけるだろうけど。 991 名前：デフォルトの名無しさん [2024/02/23(金) 15:12:44.34 ID:z6SHyxko.net] iPadでXcode使えるからそれで遊んでみれば 992 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 15:20:09.67 ID:CheDQupm.net] Rustが使えないとな 993 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 15:21:05.22 ID:jTrUecQ5.net] クソスレまで立てちゃってw 素直に中古のノートPCでも買えよ 994 名前：デフォルトの名無しさん [2024/02/23(金) 16:04:17.89 ID:02Kw336h.net] traitの種類多すぎて把握しきれん 使い分けもようわからんし 995 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 16:18:25.67 ID:NJWNbZ5N.net] Pythonのpep20みたいなってRustにもあるの？ 996 名前：デフォルトの名無しさん [2024/02/23(金) 16:32:06.33 ID:eHVJk53E.net] スマホやタブレットなどのモバイルOS上に開発環境用意するのは主に2つユースケースがある 1つはモバイルOS上で実行させる小さなユーティリティを作るため だいたいlinux emulatorみたいなアプリ内環境で稼働させる もう一つは出先の空いた時間や障害対応等の緊急時にノートPCを持ち歩かなくても簡易的な作業なら対応できるようにしておくため 前者はスマホだけで作るやつもいるにはいるが少数派 なので今のところはメイン開発環境は別に用意してるのが大半 997 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:15:31.94 ID:kgcjkDLJ.net] PEP20って何だよと思ったらあのウンコポエムだった 998 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:26:44.63 ID:kgcjkDLJ.net] 次スレタイトル間違えてしまったのですまんが 999 名前：誰か立て直してくれ 規制食らってもう立てられなくなった [] [ここ壊れてます] 1000 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:35:21.56 ID:CheDQupm.net] >>977 traitとは機能を抽象化した抽象型だから使いたい機能のtraitを選ぶか作ればよい structなどの具象型は各々必要な各機能(trait)を実装しているもしくは実装すればよい そして抽象型(trait)を用いてプログラミングすることでその機能を実装する全ての具象型を対象とした共通コードにできる 1001 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:38:39.47 ID:CheDQupm.net] 次スレ Rust part23 https://mevius.5ch.net/test/read.cgi/tech/1708677472/ 1002 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:45:54.27 ID:kgcjkDLJ.net] >>983 ありがとう 1003 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:51:32.20 ID:jYYzpIEX.net] >>978 こういうのをまとめようとはしているよ https://smallcultfollowing.com/babysteps/blog/2023/12/07/rust-design-axioms/ 1004 名前：デフォルトの名無しさん [2024/02/23(金) 20:10:18.94 ID:1IK2X2kO.net] >>982 FromとかAsRefとかDerefとかの時点でもうようわからんぜ 1005 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 22:42:10.08 ID:oukljDwS.net] Fromは汎用的な変換だよ 変換に失敗する可能性を含む時はTryFromを使う AsRefは参照から(別型の)参照への読み替え変換 コストがかからない場合が対象 コストがかかるものはFromを使う Derefは変換ではなく演算子 変換は複数の型への変換を実装できるけど 演算子なので各型で決められた一つの型へderefできる &T→T Box<T>→T Rc<T>→T Vec<T>→[T] String→str PathBuf→Path など 1006 名前：デフォルトの名無しさん [2024/02/23(金) 23:50:59.87 ID:1IK2X2kO.net] あー。それぞれの比較はまあそうなのかもしれないんだけど、そもそもどういうtraitがあってどういう時に使うべきなのかを全て把握できてないせいで実際にコード書く時にどれを使うとRustらしいコードになるのかわからなくなるってのがしんどいんだよね 1007 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 23:59:41.76 ID:hX/YHnPg.net] >>988 どの分野のどんな話でも基本パターンの学習による慣れ 問題 match std::env::args().XXXXX { 　Some("yes") => ..., 　Some("no") => ..., 　_ => ..., // エラー } 1008 名前：デフォルトの名無しさん [2024/02/24(土) 02:12:39.95 ID:YQ3M0cmx.net] 梅 1009 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 04:00:00.27 ID:felFEjYK.net] 「当然こういうのが標準ライブラリにあって然るべきだろう」みたいな感覚ができるから結局は慣れ。 常識的に考えてあるだろうと思ったら nightly だったみたいなこともよく経験するから俺が欲しいようなものはみんな欲しいんだなと思う。 実質的に言語の一部みたいなくらいのやつは嫌でも避けられないから何度もドキュメントを読み返すはめになるし、そのうち自然に使えるようになる。 1010 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 12:21:57.67 ID:lhpjpr9r.net] >>987 Derefは演算子でも利用されるがDerefそのものが演算子(や演算子の実装)というわけではない Type Coercionというのは型変換(Type Conversion)の一種なのでDerefは変換ではないというのもやや言い過ぎ 各型で決められた一つの型にderefされるのは演算子だからという理由ではなくて Derefはスマートポインタが包んでる値へのアクセスを便利にするために用意されたものだからderef先の型は自然と一つに決まるため(>>733) &T→TはDerefの役割ではない 1011 名前：デフォルトの名無しさん [2024/02/24(土) 12:57:43.72 ID:Sbx59RJL.net] AsRefとBorrowは未だにわからんなあ 調べてもHashMapがBorrow要求するならそこだけBorrow使っておけばいいか……で思考停止してる 1012 名前：デフォルトの名無しさん [2024/02/24(土) 13:58:08.04 ID:Q2pRspv0.net] 埋 1013 名前：デフォルトの名無しさん [2024/02/24(土) 13:58:23.94 ID:Q2pRspv0.net] 生め 1014 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:40.99 ID:Q2pRspv0.net] 、埋め 1015 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:46.56 ID:Q2pRspv0.net] ！埋め 1016 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:52.17 ID:Q2pRspv0.net] ？埋め 1017 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:59:00.55 ID:Q2pRspv0.net] ○埋め 1018 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:59:07.65 ID:Q2pRspv0.net] 〜埋め 1019 名前：1001 [Over 1000 Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 34日 14時間 37分 28秒 1020 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef