Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

公式
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/

**デフォルトの名無しさん** · 2024/02/08(木) 19:25:31.03

単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。

**デフォルトの名無しさん** · 2024/02/08(木) 19:29:46.46

途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん

**デフォルトの名無しさん** · 2024/02/08(木) 19:34:55.22

>>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな

**デフォルトの名無しさん** · 2024/02/08(木) 19:38:03.57

next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ

**デフォルトの名無しさん** · 2024/02/08(木) 19:54:29.48

サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案

**デフォルトの名無しさん** · 2024/02/08(木) 20:01:51.28

Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ

**デフォルトの名無しさん** · 2024/02/08(木) 20:03:16.79

それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった

**デフォルトの名無しさん** · 2024/02/08(木) 20:29:26.04

>>464
forthみたいで面白くない？

**デフォルトの名無しさん** · 2024/02/08(木) 21:09:57.90

Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ

**デフォルトの名無しさん** · 2024/02/08(木) 21:15:13.68

>>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある

**デフォルトの名無しさん** · 2024/02/08(木) 22:03:30.31

もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ

**デフォルトの名無しさん** · 2024/02/09(金) 00:17:38.71

今は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に取られたシェアを回復する

**デフォルトの名無しさん** · 2024/02/09(金) 06:07:49.74

>>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？

**デフォルトの名無しさん** · 2024/02/09(金) 07:43:30.04

Ruby信者はズレてるから仕方ない

**デフォルトの名無しさん** · 2024/02/09(金) 07:53:26.10

SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい

**デフォルトの名無しさん** · 2024/02/09(金) 08:55:44.38

SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう

**デフォルトの名無しさん** · 2024/02/09(金) 09:34:26.12

std::any::type_name_of_val()は学習時にも良さそ

**デフォルトの名無しさん** · 2024/02/09(金) 09:59:55.75

昔から使えるよ
fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str {
　std::any::type_name::<T>()
}

**デフォルトの名無しさん** · 2024/02/09(金) 10:27:55.96

>>493
JS使った方が楽という感覚は理解できんわ

**デフォルトの名無しさん** · 2024/02/09(金) 13:19:22.70

>>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？

**デフォルトの名無しさん** · 2024/02/09(金) 13:59:04.29

リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ

**デフォルトの名無しさん** · 2024/02/09(金) 14:16:42.17

>>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった

**デフォルトの名無しさん** · 2024/02/09(金) 15:05:02.67

どんどんrustの話から離れていってんな

**デフォルトの名無しさん** · 2024/02/09(金) 15:19:56.77

SSRやCSRがややこしいと感じる意味がわからん
Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？
特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ

ReactのサーバーコンポーネントはNext..jsではサーバーサイドでレンダリング(HTML生成される)、つまりSSR
クライアントコンポーネントはクライアントサイドでレンダリングされる、つまりCSR

ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ

**デフォルトの名無しさん** · 2024/02/09(金) 15:26:09.73

Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ

**デフォルトの名無しさん** · 2024/02/09(金) 15:36:06.60

>>505
型システムとの兼ね合い。

**デフォルトの名無しさん** · 2024/02/09(金) 15:38:36.69

>>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス

マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う

**デフォルトの名無しさん** · 2024/02/09(金) 15:52:26.69

next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね

**デフォルトの名無しさん** · 2024/02/09(金) 16:25:40.87

>>504
その発想だとサーバーアクションは説明できないよ

**デフォルトの名無しさん** · 2024/02/09(金) 16:28:31.07

>>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる

**デフォルトの名無しさん** · 2024/02/09(金) 16:37:49.82

>>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい

**デフォルトの名無しさん** · 2024/02/09(金) 17:13:49.98

>>510
同感

**デフォルトの名無しさん** · 2024/02/09(金) 18:59:39.30

C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？

**デフォルトの名無しさん** · 2024/02/09(金) 19:22:48.34

実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さなければいけなかったんじゃないでしょうか。

**デフォルトの名無しさん** · 2024/02/09(金) 19:24:12.28

あ、可変長引数の話とオーバーロードの話を混同してしまっていた。

**デフォルトの名無しさん** · 2024/02/09(金) 19:32:53.51

https://qiita.com/buntafujikawa/items/1bd808f5f55eb63df7c4
こういうの知ってたら
オーバーロードもデフォルト引数もいらね～
どうしてもほしけりゃ別名の関数作るわ
ってならん？

**デフォルトの名無しさん** · 2024/02/09(金) 19:45:04.86

別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので

**デフォルトの名無しさん** · 2024/02/09(金) 20:35:29.36

田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。

**デフォルトの名無しさん** · 2024/02/09(金) 23:53:50.41

オーバーロードは無くてもいいけどキーワード引数は欲しいかな

**デフォルトの名無しさん** · 2024/02/09(金) 23:59:48.02

>>519
あるよ
X { name: "foo", num: 123, ... }

**デフォルトの名無しさん** · 2024/02/10(土) 02:54:22.21

>>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ

**デフォルトの名無しさん** · 2024/02/10(土) 09:13:20.91

>>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある

**デフォルトの名無しさん** · 2024/02/10(土) 09:40:29.45

Rustでなぜデフォルト引数がサポートされてないのかはここでよろしく
https://www.reddit.com/r/rust/comments/fi6nov/why_does_rust_not_support_default_arguments/

**デフォルトの名無しさん** · 2024/02/10(土) 09:50:58.48

構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ

**デフォルトの名無しさん** · 2024/02/10(土) 09:54:14.05

ビルダーパターンは自分で書くならめんどい

**デフォルトの名無しさん** · 2024/02/10(土) 10:07:03.72

>>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌

**デフォルトの名無しさん** · 2024/02/10(土) 10:08:52.95

ADAってどう？

**デフォルトの名無しさん** · 2024/02/10(土) 10:22:50.56

Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって

**デフォルトの名無しさん** · 2024/02/10(土) 10:33:01.11

>>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな

**デフォルトの名無しさん** · 2024/02/10(土) 10:33:37.95

パターンとかきしょすぎ
Javaみてえな文化

**デフォルトの名無しさん** · 2024/02/10(土) 10:36:17.39

>>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから

**デフォルトの名無しさん** · 2024/02/10(土) 11:15:35.75

>>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは

**デフォルトの名無しさん** · 2024/02/10(土) 11:20:28.46

>>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので

**デフォルトの名無しさん** · 2024/02/10(土) 11:21:55.77

キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな

**デフォルトの名無しさん** · 2024/02/10(土) 11:24:20.16

キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て

**デフォルトの名無しさん** · 2024/02/10(土) 11:32:26.22

パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ

**デフォルトの名無しさん** · 2024/02/10(土) 11:53:44.03

>>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない

**デフォルトの名無しさん** · 2024/02/10(土) 11:54:44.92

可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ

**デフォルトの名無しさん** · 2024/02/10(土) 11:57:02.97

>>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか

**デフォルトの名無しさん** · 2024/02/10(土) 12:00:29.93

>>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから

**デフォルトの名無しさん** · 2024/02/10(土) 12:04:27.79

>>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい

**デフォルトの名無しさん** · 2024/02/10(土) 12:09:31.06

まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か

**デフォルトの名無しさん** · 2024/02/10(土) 12:12:05.42

>>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ

**デフォルトの名無しさん** · 2024/02/10(土) 12:13:49.11

Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも

**デフォルトの名無しさん** · 2024/02/10(土) 12:18:46.21

デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ

**デフォルトの名無しさん** · 2024/02/10(土) 12:30:54.19

パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる

**デフォルトの名無しさん** · 2024/02/10(土) 12:33:11.47

いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている

**デフォルトの名無しさん** · 2024/02/10(土) 13:01:44.04

>>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ

**デフォルトの名無しさん** · 2024/02/10(土) 13:16:33.29

Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから

**デフォルトの名無しさん** · 2024/02/10(土) 13:20:09.17

>>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ

**デフォルトの名無しさん** · 2024/02/10(土) 13:24:24.95

>>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね

**デフォルトの名無しさん** · 2024/02/10(土) 13:42:15.57

>>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな

一言で言えばどちらも低DX

**デフォルトの名無しさん** · 2024/02/10(土) 13:57:43.35

>>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい

**デフォルトの名無しさん** · 2024/02/10(土) 13:58:54.16

>>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど

**デフォルトの名無しさん** · 2024/02/10(土) 14:03:55.89

>>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな

**デフォルトの名無しさん** · 2024/02/10(土) 14:05:28.57

デザインパターンといえばGoFは流石に古くないか？？

**デフォルトの名無しさん** · 2024/02/10(土) 14:05:43.92

デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン

**デフォルトの名無しさん** · 2024/02/10(土) 14:08:00.40

デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます

**デフォルトの名無しさん** · 2024/02/10(土) 14:23:27.48

話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか

**デフォルトの名無しさん** · 2024/02/10(土) 14:40:14.16

出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。

**デフォルトの名無しさん** · 2024/02/10(土) 14:40:53.07

>>559
いつからブラウザで見ていると勘違いしていた

**デフォルトの名無しさん** · 2024/02/10(土) 14:42:22.10

>>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？

**デフォルトの名無しさん** · 2024/02/10(土) 14:46:24.04

Javarが考えた設計は根本的に汚い

**デフォルトの名無しさん** · 2024/02/10(土) 14:49:44.24

オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった

元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している

**デフォルトの名無しさん** · 2024/02/10(土) 14:56:46.66

>>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood

**デフォルトの名無しさん** · 2024/02/10(土) 14:58:45.32

いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話

**デフォルトの名無しさん** · 2024/02/10(土) 14:59:40.15

ついJavaという言葉に反応しちゃったけどよく見たらJavarだった…

**デフォルトの名無しさん** · 2024/02/10(土) 15:00:30.74

>>566
ごめん勘違いした>>565はスルーしてほしい

**デフォルトの名無しさん** · 2024/02/10(土) 15:16:47.93

・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる

**デフォルトの名無しさん** · 2024/02/10(土) 16:24:25.37

今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな

**デフォルトの名無しさん** · 2024/02/10(土) 16:37:42.00

継承抜きオブシコで十分っす

**デフォルトの名無しさん** · 2024/02/10(土) 16:45:54.10

なんでrustスレで他言語の雑談始まってしもたん

**デフォルトの名無しさん** · 2024/02/10(土) 16:58:53.57

>>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと

**デフォルトの名無しさん** · 2024/02/10(土) 17:00:23.08

継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？

**デフォルトの名無しさん** · 2024/02/10(土) 17:09:17.38

従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし

**デフォルトの名無しさん** · 2024/02/10(土) 17:37:53.51

Rustの型クラスは最強

**デフォルトの名無しさん** · 2024/02/10(土) 17:45:44.24

rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ

**デフォルトの名無しさん** · 2024/02/10(土) 17:48:42.70

>>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話

**デフォルトの名無しさん** · 2024/02/10(土) 18:00:46.16

>>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？

**デフォルトの名無しさん** · 2024/02/10(土) 18:18:59.99

>>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ

**デフォルトの名無しさん** · 2024/02/10(土) 18:20:18.08

>>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん