Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
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 part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/08/05(月) 12:25:55.60

話は聞かせてもらった
最適な比率は2でも1.5でもなく黄金比1.618だな
こういう問題は大体フィボナッチ数列が正解になる
僕は数学に詳しいんだ

**デフォルトの名無しさん** · 2024/08/05(月) 12:37:42.98

>>37
わかる
もうちょいライトなユーザ向けのスレも欲しいかも

**デフォルトの名無しさん** · 2024/08/05(月) 12:46:25.51

>>37
むしろ彼しか問題にしてないだろ
g++とclang++のvectorとrustcのVecは2倍にしていく
もし2倍が致命的なら大論争になり変更されるはずだ
現実には実用面も含めて問題となっていない

**デフォルトの名無しさん** · 2024/08/05(月) 13:06:57.87

「致命的」に後退しちゃったねｗ

**デフォルトの名無しさん** · 2024/08/05(月) 13:12:56.68

Linux などのメモリ管理戦略ではアロケータは空いてる番地を返すだけで
アクセスするまで実メモリの割り当てをしない。 (割り当てを遅延させる。)

vector を極端に伸ばしたり縮めたりするなら話は別だが、
徐々に伸びていって最後に捨てる一般的なユースケースなら
倍率はテキトーでも理論的な効率はそんなに差はない。

**デフォルトの名無しさん** · 2024/08/05(月) 13:21:17.66

rustやc++では再割り当てが行われると参照が無効になるから2倍にして頻度を下げるのかも

**デフォルトの名無しさん** · 2024/08/05(月) 14:50:20.61

https://github.com/rust-lang/rust/issues/29931
これだね
2015年から議論されてるけど、結局1.5倍がいいという結論には至ってないし
実際1.5倍を試してみた結果パフォーマンスが落ちてるから単純に1.5倍にするのはダメそう
もし1.X倍でパフォーマンス上がる方法があるならそのissueに報告すれば採用されるかもよ

**デフォルトの名無しさん** · 2024/08/05(月) 15:01:05.36

>>44
rustcがベンチマークのネタに適してないんじゃないの？

**デフォルトの名無しさん** · 2024/08/05(月) 15:14:32.99

>>45
そう思うならrustc以外のアプリでベンチ取って提示してみれば？
少なくともパフォーマンス低下するアプリが一つ示されたんだからそれ以上のデータ出さないと話進まないでしょ

**デフォルトの名無しさん** · 2024/08/05(月) 15:48:02.67

もっと歴史の長いGCCのC++もClangのC++もvectorの再割り当ての長さ2倍を採用している
そしてGCを用いてメモリ管理する言語は各々で諸事情があるようだから参考にできない

**デフォルトの名無しさん** · 2024/08/05(月) 16:04:04.60

fbvectorの話はアロケータが確保する単位に合わせて無駄を無くすということと
Vecのリサイズによって開放されたメモリ領域を再利用しやすくするということが書いてるだけ

どっちも理にかなってる

**デフォルトの名無しさん** · 2024/08/05(月) 16:26:39.60

標準として提供する機能には平均的な性能が高いよりも
最悪の場合でもそれなりの性能が出るほうを優先するみたいな考え方もあるし
設計思想にもよるわな。

**デフォルトの名無しさん** · 2024/08/05(月) 18:42:38.74

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56
C++の結果だけど結構な差が出てる
この人のコードを自分の環境でも試してみたがpush_backで5倍前後違う

単純に1.5倍固定じゃなくて真似したやつで試してみたらいいのにね

**デフォルトの名無しさん** · 2024/08/05(月) 19:15:50.62

>>50
ソース見てみたけど恣意的に10倍ずつ異なる長さで順にアロケーションを汚染していき
vectorは単発使い捨てで毎回残らないからその前の残骸の空きエリアにたまたま上手くマッチするかの勝負になっていて
現実とはかけ離れたテストになっていると思った

**デフォルトの名無しさん** · 2024/08/05(月) 23:13:48.63

>>49
速度vsメモリ効率なんかもあるしね

**デフォルトの名無しさん** · 2024/08/05(月) 23:56:18.02

>>50
こんなに違いが出るのか

**デフォルトの名無しさん** · 2024/08/06(火) 00:27:44.41

>>44を読んでると
1.5倍にすると実用なプログラムでは遅くなるのに対し
>>50の特殊なベンチな時だけ1.5倍がとても速い理由は
他のメモリ割り当てに邪魔されずに1つのベクタだけがどんどん成長していくからで
1+1.5+1.5^2+1.5^3 ＜ 1.5^4 であるため
自分が過去に用いたところを結合してそのまま使えるため速いらしい
しかし現実のプログラムは他のヒープ利用も間に起きるためその再利用はうまく行かずメリットが起こらないと

**デフォルトの名無しさん** · 2024/08/06(火) 10:36:53.30

2.71828倍が良いとおもいますん

**デフォルトの名無しさん** · 2024/08/06(火) 13:40:39.24

1.14514倍で

**デフォルトの名無しさん** · 2024/08/06(火) 17:53:14.98

C++が1.5倍伸長のFBVectorで自分の抜け殻を上手く再利用する件
Rustはなぜ2倍伸長でもっと速いのかを調べてみた

同じように他に邪魔されず伸長していくケースだと
RustのVecは以下のように
128Kバイトまでは同じアドレスのまま移動せずにコピー無しで2倍伸長していく
256Kバイト以上ではmremap利用でアドレスは移動するがコピー無しで2倍伸長していく
そのためRustのVecは2倍伸長でもサイズが巨大になっても速いことがわかった

addr=0x5642549e6ab0 cap=8 len=1+1
addr=0x5642549e6ab0 cap=8 len=2+1
addr=0x5642549e6ab0 cap=8 len=4+1
addr=0x5642549e6ab0 cap=16 len=8+1
addr=0x5642549e6ab0 cap=32 len=16+1
(途中略) 【アドレスはずっと変わらない】
addr=0x5642549e6ab0 cap=32K len=16K+1
addr=0x5642549e6ab0 cap=64K len=32K+1
addr=0x5642549e6ab0 cap=128K len=64K+1
【ここでアドレスが変化＆mremap利用が始まる】
addr=0x7f661c06f010 cap=256K len=128K+1
addr=0x7f661bfee010 cap=512K len=256K+1
addr=0x7f661beed010 cap=1M len=512K+1
addr=0x7f661bcec010 cap=2M len=1M+1
(以降略)

**デフォルトの名無しさん** · 2024/08/06(火) 18:25:14.08

もちろんVecは2倍伸長をアロケータにリクエストするだけなので
実際に処理しているのはRust標準のGlobalアロケータ
この環境では出来たバイナリにglibcのmallocやreallocがリンクされてるので最終的にはそこに行き着くはず

**デフォルトの名無しさん** · 2024/08/06(火) 19:53:13.46

Carbon Languageに期待

**デフォルトの名無しさん** · 2024/08/06(火) 20:16:16.47

Rustの標準アロケータを使わずに
>>57をjemalloc利用でアドレス変化を調べると全く異なる結果となった

8Kバイトまではアドレスが毎回変わりコピー移動
16Kバイトから1Mバイトまではアドレスが変わらずコピー無し
2Mバイト以上はアドレスが毎回変わりmremapが使われてないためコピー移動

少なくとも今回の前提での利用の範囲内ならば
Rust標準をそのまま用いるのが最適となる

**デフォルトの名無しさん** · 2024/08/06(火) 20:54:39.49

そういや一昔前、jemallocを採用してるから
Rustは良いんだよ、って主張があったよね

**デフォルトの名無しさん** · 2024/08/06(火) 21:01:13.77

jemallocは色々と問題もあるため5年半前の2019年1月のRust1.32で標準採用しなくなった
もちろんjemallocが好ましいケースもあるのでその時は各自で簡単に使えるようにもなってる

**デフォルトの名無しさん** · 2024/08/07(水) 00:45:04.42

未だに Vec::new_in() が安定化しないRustとは対照的に
Zigはヒープ使う関数すべてで毎回毎回アロケータを引数に渡させて
毎回毎回成功したか確認させるんだね

Linuxカーネル開発にはZigの方が向いてるんじゃなかろうか？

**デフォルトの名無しさん** · 2024/08/07(水) 01:13:06.44

{C++ std::vector, C++ fbvector, Rust std::Vec} × {jemalloc, glibc malloc, LLVM libc malloc, msvc malloc, musl libc malloc} × {Linux, macOS, Windows} × {x86_64, 仮想メモリの機能を持たない何らかのアーキテクチャ}

壮大な議論になってきたなあ
これ全部検証するつもり？

そういやglibc mallocは環境変数でヒープとmmapのどっちを使うかの閾値調整できるとか
msvc mallocは_DEBUGマクロが定義されていると確保したメモリに未初期化を表すバイトを書き込むとかもあった

条件はいくらでも付け加えられそうやね

**デフォルトの名無しさん** · 2024/08/07(水) 01:28:00.75

サイズの大きなベクタは
キャパシティ拡張してもコピーが発生しないmremap利用のアロケータが有利という結論だな
サーバなどで一般的に使われるLinux環境ならRust標準でその条件を満たすから大丈夫

**デフォルトの名無しさん** · 2024/08/07(水) 08:32:07.19

>>63
Zigはまぁ1.0にならないと検討の俎上にもあげられないし
Cと比べてそれほど強い保証が得られるわけでもないから
あまり導入するモチベーションもなさそう

**デフォルトの名無しさん** · 2024/08/07(水) 22:36:11.64

https://www.publickey1.jp/blog/24/rustservowebverso.html
2024年8月6日
欧州を基盤にオープンでセキュアなインターネットの実現を支援しているNLnet Foundationは、
昨年(2023年)末から、Linux Foundation傘下でRust製のクロスプラットフォーム対応Webブラウザエンジンとして開発が進められている「Servo」を用いたWebブラウザ「Verso」の開発プロジェクトの立ち上げを発表した。
また、この「Servo」をTauriの組み込みのWebViewとする方向で開発が始まっている。
Chromiumに代わるRust製

**デフォルトの名無しさん** · 2024/08/07(水) 22:38:49.83

>>67
名前がダサすぎるからダメ

**デフォルトの名無しさん** · 2024/08/08(木) 05:28:31.41

ChromiumがC++のメモリ管理ミスで度々セキュリティ脆弱性を招いてるから
対抗馬ができるのは良いこと

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

まともに動くまで20年ぐらい掛かるんだろ

**デフォルトの名無しさん** · 2024/08/08(木) 13:55:28.27

Firefox先生の明日はどっちだ

**デフォルトの名無しさん** · 2024/08/09(金) 06:14:59.59

Tauri2.0 Android/iOSでマルチwebviewしたかった
この流れだとVersoになるまで出来なさそう

**デフォルトの名無しさん** · 2024/08/09(金) 10:26:33.54

タウリン実際どうなん？
実用になる？

**デフォルトの名無しさん** · 2024/08/09(金) 10:41:11.99

>>73
有用だけど場合による。

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

implementation of `From` is not general enough
= note: `From<&'0 Hoge>` would have to be implemented for the type `Fuga<'_>`,
for any lifetime `'0`...
= note: ...but `From<&'1 Hoge>` is actually implemented for the type `Fuga<'1>`,
for some specific lifetime `'1`

これはどうやって解決するのが普通？

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

こういう実装は書いてあります
impl<'a> From<&'a Hoge> for Fuga<'a> {
fn from(src: &'a Hoge) -> Fuga<'_> {
Fuga::from(なんかの変換(src))
}
}

**デフォルトの名無しさん** · 2024/08/09(金) 17:18:10.35

fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge> {
中身
let m = T::from(hoge);
中身
}

みたいな関数を呼んだ(コンパイル時)ときに >>75 のエラーで止まります

**デフォルトの名無しさん** · 2024/08/09(金) 17:22:16.81

呼ぶ方は
let x = moge::<Fuga>(2, 5);
みたいに呼びたいのです

**デフォルトの名無しさん** · 2024/08/09(金) 17:22:41.31

fn mame(a: &str, b: &str) -> i64 {
中身
let m = Fuga::from(hoge);
中身
}
としたときは正常にコンパイルも動作もできました

**デフォルトの名無しさん** · 2024/08/09(金) 18:10:20.58

>>77
全体が見えないのでなんとも言えないが
>>75のエラーを解決するなら
例えば
fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge>
↓
fn moge<'a, T: 'a>(a: &str, b: &str) -> i64 where T: From<&'a Hoge>

**デフォルトの名無しさん** · 2024/08/09(金) 19:57:46.44

`src` does not live long enough
--- argument requires that `src` is borrowed for `'a`
borrowed value does not live long enough
`src` dropped here while still borrowed

**デフォルトの名無しさん** · 2024/08/09(金) 21:05:31.98

playgroundに再現する最小限のコードを貼れよ

**デフォルトの名無しさん** · 2024/08/09(金) 21:17:17.11

タウリンで作られたなんか実用的なアプリある？

**デフォルトの名無しさん** · 2024/08/09(金) 23:57:36.49

>>83
https://github.com/tauri-apps/awesome-tauri

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

>>84
なんか中国人が多いな

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

先月の航空業界や病院に政府機関など850万台のWindows端末が影響を受けた世界的な大規模システム障害について、
CrowdStrikeが根本原因分析のレポートを発表しました。

「コンテンツインタープリターは20個の値しか想定していませんでした。
したがって、21番目の値にコンテンツインタープリターがアクセスしようとすると、入力データ配列の末尾を超えて領域外のメモリが読み取られ、
その結果システムがクラッシュしました」と報告しています。

記事
https://gigazine.net/news/20240809-crowdstrike-root-cause-analysis/

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

>>86
Windowsやマイクロソフトは何も悪くなかったのか

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

>>86
Rustを使っていれば防げたな
スライスイテレータが個別のインデックスチェックコスト無しで境界チェックできるから

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

Rustを使っていればってのは机上の空論なんだよな
自分でできないことを人に求めるなよと

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

っぱRustだな

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

今までそのプロジェクトに一度も貢献したことの無い人が「Rustで書き直さないの？」ってIssueを立てて即リジェクトされるのを見かける……
なぜかそういう人が好む言語 (彼らが本当にRustを書いているのかは不明)

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

人間がチェックするよりコンパイラに機械的にチェックさせたほうがこういうミスは出ないってことだ

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

>>92
今回のクラウドストライクのやらかしは本来はテストコードで見つかるはずの脆弱性なんだけどな

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

Rustで防げる種類バグがあるのは事実でも、Rustに変えるとバグが減ります！と言っちゃうと嘘になる現実があるからみんな苦しんでるんですよ

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

>>93
うっかりテストコードが抜けていても
Rustならコンパイラが撥ねてくれるからいいね

>>94
こういう参照バグやメモリ競合バグは確実に減るね

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

それなのにRustは全然使われない理由って何なのかなあ

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

クラウドストライクが件のセキュリティソフトを開発し始めた頃はまだRustが安定版になかったし仕方ない

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

言語とビジネスは別の話だからだろ
顧客はソフトウェア製品にお金を出すのであって、「Rustで書かれていること」にお金を払うわけじゃない
既存プロジェクトを置き換えたところで顧客から追加のお金を貰えるわけではないし、置き換えをメインに作業してる間は機能追加などの開発は止まるわけだし
新規開発での採用は進んでると思うぞ

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

以前からのは対策が遅れるの仕方ないよな
ただし新規案件でC++はアウトで言い訳できない
十分に学習とお試しする時間があったのだから

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

もともとC++を使う案件自体が少ないんで

シビアなところは互換性を考慮してC++のまんまだし

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

>>99
お前は何様なんだよw

警備員[Lv.1][新芽] · 2024/08/10(土) 16:19:11.72

チンパンジーのあいちゃん

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

>>82
trait 使うのやめて

>>77 の関数を
fn moge<F>(a: &str, b: &str, f: F) -> i64
where F: for<'a> Fn(&'a Hoge) -> Fuga<'_> {
中身
let m = f(hoge);
中身
}
にかえて

>>78 の呼ぶ側を
let x = moge(2, 5, |hoge| Fuga::from(hoge));
にしたらうまくいきました
ほんとうにありがとうございました

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

多分>>76の戻り値をFuga<'a>に直すのが根本的解決だけどうまくいったならもういっか

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

タウリン好き
WinMacで動くクライアントアプリ書きたかってん

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

>>104
私の記憶ではそこはやってみたのですが治りませんでしたね

**デフォルトの名無しさん** · 2024/08/11(日) 08:59:52.85

>>86 >>93 ほんそれ
こんなんテストしてれば見つかる話で恥ずかしいレベルの大チョンボ
マイクロソフトはもちろんクラウドストライクを訴えれば良いし
デルタ航空はマイクロソフトとクラウドストライクに5億ドル請求って言ってるけど
マイクロソフトを訴えるのは筋違いなので
デルタ航空以外の被害受けた各社はみんなでクラウドストライクを訴えれば良い

**デフォルトの名無しさん** · 2024/08/11(日) 11:53:58.67

Rustで防げるっていうのは、リストに正常にアクセスできたかチェックを強制されるって意味？

**デフォルトの名無しさん** · 2024/08/11(日) 12:32:03.37

標準環境なら範囲外アクセスはpanicして停止する
Cだとそこに有効なデータがあるものと思ってそのまま操作してしまい、その結果何が起きるか分からないということがある (言語でなくOS側のチェックにより防がれることはある)
no-std環境のRustについては自分も詳しくないので誰か書いてくれ

**デフォルトの名無しさん** · 2024/08/11(日) 12:55:28.88

>>108
Rustでは20個の領域を作った時点で
そこをその先頭アドレス=ポインタで指すのではなく
連続体(スライス)を抽象的な参照で指す
もちろんそのスライスへの参照は内部では先頭アドレスと長さになるが抽象的なスライス参照&[T]として扱う
そこからイテレータは20個の個別参照&Tを連続的に返したりインデックス指定によりget(index)でOption<&T>を得たりできる
21個目のアドレスを得たりその中身を見たりすることはsafeの範囲ではできない

警備員[Lv.4][新芽] · 2024/08/11(日) 14:07:38.05

それはどんなアセンブルコードに落ちているの？

**デフォルトの名無しさん** · 2024/08/11(日) 14:30:38.38

抽象的なレベルで安全を確保してしまえばその後にそのコードは最適化し放題
生成アセンブルコードはcargo asmでその場で確認できる

**デフォルトの名無しさん** · 2024/08/11(日) 15:19:18.37

>>111
範囲内かどうか比較する処理は入る。
ただし、静的に絶対安全と分かる状況なら最適化で消えることもある。
そうでなくても現代的 CPU だと分岐予測によって速度的ペナルティは小さいことが多い。
ゼロコストというわけではないが、 C 風のポインタがあまりにも素朴でミスしやすいことに対する解決法としては十分以上に小さいコストだと考えられている。
今では C++ にもスライス的な、範囲を表すクラスが標準に追加されていて再編成が進んでるのでやっぱりそのほうがよいという時代の潮流があるんだと思う。

**デフォルトの名無しさん** · 2024/08/11(日) 15:21:08.97

またいつもの嘘吐きが

**デフォルトの名無しさん** · 2024/08/11(日) 16:17:49.13

zigはリリースビルドだと範囲チェックをオフにしちゃうらしい
やっぱゼロコストじゃないよね

**デフォルトの名無しさん** · 2024/08/11(日) 16:42:50.50

>>111
例えばスライスをforで回してその値を書き込む関数
#[inline(never)]
fn foo(slice: &[i32]) {
　for t in slice {
　　write_volatile!(VOLATILE, *t);
　}
}

生成アセンブリコード
::foo:
　test rsi, rsi
　je .LBB11_3
　shl rsi, 2
　xor eax, eax
.LBB11_2:
　mov ecx, dword ptr [rdi + rax]
　mov dword ptr [rip + ::VOLATILE], ecx
　add rax, 4
　cmp rsi, rax
　jne .LBB11_2
.LBB11_3:
　ret

範囲内かどうかのチェックはC/C++と同じくループ内で1箇所のみで同じ動作になる

**デフォルトの名無しさん** · 2024/08/11(日) 17:01:54.96

ベアメタル環境でもRustってCより有用なものなの？
安全性は保証しやすくなるとして、書きやすさ (あるいは面倒臭さ) がどれほどのものか
実際経験ある人いる？

**デフォルトの名無しさん** · 2024/08/11(日) 18:11:06.27

>>117
内部的には unsafe が必要だけど外に対しては安全性を保障している基礎的な語彙が標準ライブラリにはいっぱいあるじゃん。
ああいう感じの基礎的なものを環境に合わせて作るというのがスタートラインで、それが適切に出来てればベアメタル環境だからといって特別な違いはない。

unsafe を適切に下層レイヤに押し込めれていないと全体に unsafe が頻出して Rust の安全性の恩恵を受けにくいし、
安全性の恩恵を受けられないのに Rust の面倒くさい部分はあるという状況になって嬉しくない。

最初の整備をまじめにやるのがすごく大事。

警備員[Lv.7][芽] · 2024/08/11(日) 20:48:33.63

>>116
thx

**デフォルトの名無しさん** · 2024/08/11(日) 21:00:21.89

no_stdだとRustの基本的な機能は使えるけど
I/O入出力ライブラリなどが当然ないから
Hello, World!するのにこんな感じなのね
https://zenn.dev/zulinx86/articles/rust-nostd-101#final-code

**デフォルトの名無しさん** · 2024/08/12(月) 13:11:33.58

>>117
保守には良いと思う
リファクタリングには向いていない

**デフォルトの名無しさん** · 2024/08/12(月) 13:21:38.56

>>120
ベアメタルって元々そういうもんでそ

**デフォルトの名無しさん** · 2024/08/12(月) 14:00:36.88

>>121
ちゃんとトレイトベースで作っていれば
Rustはリファクタリングもしやすくミスも防げる

**デフォルトの名無しさん** · 2024/08/12(月) 14:04:58.34

>>123
「ちゃんとトレイトベースで作っていれば」
というのが難物という罠。

**デフォルトの名無しさん** · 2024/08/12(月) 14:12:42.26

トレイトを使いこなせば便利で快適なのに
難しいと思い込んで使いこなさない人が困るだけ

**デフォルトの名無しさん** · 2024/08/12(月) 14:53:33.48

複オジに餌を与えないでください！
みんなが迷惑しています！

**デフォルトの名無しさん** · 2024/08/12(月) 15:10:33.91

事前に理想的な設計が出来るなら苦労はないんだが現実はそうではないという話だわな

**デフォルトの名無しさん** · 2024/08/12(月) 15:15:42.43

新たにtraitを導入する時やリファクタリングで構成を変える時も新たなtrait境界を満たしていけばよくて使い勝手がいいね

**デフォルトの名無しさん** · 2024/08/12(月) 15:16:59.31

リファクタリングができない難しいという
人が定期的に出るけど他の言語とも比較して
コード例出してくれ

**デフォルトの名無しさん** · 2024/08/12(月) 15:32:17.85

リファクタリングしやすいしにくいの違いの定義がそもそもわからん
そういう意味でも例を頼む

**デフォルトの名無しさん** · 2024/08/12(月) 16:20:20.18

自分的には「リファクタリングしやすい」＝「書き換えミスがコンパイルエラーとして検出されやすい」なので
型強めの静的型（Rust）>型弱めの静的型（C系）>動的型
って感じ
ただ「書き換え時にコンパイルエラーに煩わされない」を重視してて動的型がリファクタリングしやすい派もいるっぽい
（個人的にはエラーにならなくてもいつのまにか動作変わってたら意味なくない？と思うけど…）

**デフォルトの名無しさん** · 2024/08/12(月) 17:02:05.11

ああ，書き換え中にエラーなり警告なりが出るのが煩わしいってことか
大抵の言語でそれはありそうだから，エディタの設定で最後にタイプしてから何秒後にアナライザのチェックを入れるかとかいじればいいのでは

**デフォルトの名無しさん** · 2024/08/12(月) 17:13:40.85

JetBrainsがリファクタリング機能の出来具合で比べてみると一目瞭然
静的型付け言語の中では最弱

**デフォルトの名無しさん** · 2024/08/12(月) 17:14:55.12

前スレでもリファクタリングの話出てたけど
無かったことにしてまた同じ話するの

**デフォルトの名無しさん** · 2024/08/12(月) 17:16:15.95

プログラマの中には剛腕タイプというか、脳のメモリが大きくて広い範囲の見通しを付けられる人はいる。
そういう人にとっては抽象レイヤも静的型も邪魔になる。

でもまあそういうのはほんまもんの超人なので普通の人は静的型のほうがいいと思う

**デフォルトの名無しさん** · 2024/08/12(月) 17:23:31.41

他言語との比較もネタ切れ感無理矢理感が激しくていい加減飽きてきた

**デフォルトの名無しさん** · 2024/08/12(月) 17:32:40.07

昔から静的型付け言語はリファクタリングが不便と主張する人がいるけど
イヤなら動的型付け言語を使っていなさい、で終わる話

**デフォルトの名無しさん** · 2024/08/12(月) 20:58:59.97

Rustの面倒臭さって静的型付けだけでないと思う
方針が見えてるものを堅く作る分には強いけど、作る→試す→改善するといったサイクルを回すような開発は負荷が大きい
Rustでのゲーム開発を断念したLogLog Gamesが出した文章 (https://loglog.games/blog/leaving-rust-gamedev/) なんかは、全てに同意しないにしても、Rustってそういうデメリットはあるよねって感じるだろうし