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/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ってそういうデメリットはあるよねって感じるだろうし

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

matchで全揃い(Some(a), Some(b), Some(c)) =>などができない言語だと確かに面倒かもしれない

484 デフォルトの名無しさん 2024/08/12(月) 17:05:54
Optional型の変数はNoneの場合のハンドリングが必要だから余計に複雑度が増す
だからNoneで明示的に初期化が必要な関数ローカルの状態変数が3つもあるのなら
リファクタリングを検討したほうがいいと思ってる

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

>>138
その人も「Once you get good at Rust all of these problems will go away」と書いているように
Rust流のやり方を身に着ければ消える問題ばかり

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

https://github.com/rust-lang/rust/issues/91639

デフォルトでwarnにもdenyにもなってないけど最重要級のlint見つけたぞい
前スレのライフタイムリファクタの話題が出た時点で教えて欲しかったな……

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

>>140
内容読んでるか？
その反応こそ批判対象の一部だぞ
Rustの根本的な部分で困難が生じていても、Rustコミュニティは「それはあなたがRustのやり方を知らないだけだ」としか言わない、というのを批判してるチャプターだ

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

複オジをRustコミュニティの代表者として扱うなよ

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

>>141
それよりも簡単な解決方法として
ライフタイム'1と'2の相違エラーが出た時点で
その部分の省略ライフタイムを自分で明示的に補ってやればいい
そうすると何が問題だったのかが視覚化される

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

>>139
Pythonでも普通に出来るぞw
論点そこじゃないだろww

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

他言語と比較して優位を示したい向きがメインになってしまうとどうも Rust の問題の存在を否定する方向に向かいがちで良くないな
そう考えるとオナニーコードでレスバやってたほうがいくらかマシだったのかもしれん

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

リファクタリングの件でも他の件でもいいけど、
他の言語と比較してRustで何が難しくて困っているのかを具体的なコード例で出してくれないと、
話が進まずに個人の感想か空想に終わってしまう。

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

>>131
ミスをコンパイルエラーにしてくれることがプログラム書いて色々試してる時もリファクタリングしてる時も一番重要だもんな
他の言語だと実行時のエラーや実行時のデバッグに依存せざるを得なかったことがRustでは実行前に解決することが多くて開発効率が良くて助かる

**デフォルトの名無しさん** · 2024/08/13(火) 12:58:50.63

設計を変更する際に必要な変更が多いのはありそう
例えば既存のコードをasyncに対応させようとすると、必要なデータを Arc, Mutex で包んだり、参照のせいでSendできないものをOwnedな型に置き換えたり、トレイト境界に Sync + Send を付けてまわったりといった手間が要る
「設計を変更する」と決めたのでなく、「変更するとどうなるか試したい」といった場合でもこういった作業が必要で、その点は面倒かもしれない
必要な変更をコンパイラが教えてくれるのがありがたいというのは自分も同意する

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

>>149
シングルスレッドの言語以外は
メモリを共有するならそれら排他制御が必要となる点で言語に関係なく同じ
メモリを直接共有しない(例えばチャネル使用)ならRustでもそれらは必要ない
つまりRust特有の話ではない

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

動的言語に比べて静的言語がリファクタリングしやすいのは当たり前
モダンな言語の中でRustは所有権とライフタイムのせいで他に比べて明らかにリファクタリングが面倒

火を見るより明らかなことなのになぜ必死に否定したがるのか意味がわからない

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

>>149
asyncはリファクタリングとはまた別のRustの弱点

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

>>152
Rustのasyncはスタックレスでリソース消費も少なく高速で動作して使い勝手もいいよ
何を根拠に弱点と？

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

>>151
所有権とライフタイムは慣れの問題であり大した問題ではない。
それが出来ない人はGCに依存して遅くメモリ喰いの言語を使っていなさい。

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

非同期による排他は別にしても参照まわりの面倒さはある
&str にするか String にするか、Rc<String> なのか Arc<Mutex<String>> なのかといったものを考える必要があるし、リファクタ/設計変更の際にこれらの置き換え作業が必要になることはある
細かな最適化はできなくても、GC有りの言語がシンプルに1つString型だけ提供しているのは楽といえば楽

なぜエラーになるのかはコンパイラが教えてくれるし、慣れれば分かるものだけど、必要な変更が他の静的言語に比べて多くて面倒というのは否めないでしょ
自分はRustは好きだし良い言語だと思ってるけど、不便が無いとは思わないし、それが分からないのは現実の開発経験が無いんじゃないかとすら思う

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

Rustはわかってないとそもそも型チェックに通るコードが書けない

**デフォルトの名無しさん** · 2024/08/13(火) 14:03:17.07

もっと経験を積むと「なぜエラーになるのかはコンパイラが教えてくれる」どころか「コンパイラはこちらのミスをエラーにしてくれる」すら思い込みだったと気づく時が来る
もう一度貼っておくからよく読むように
特に「5) コンパイルされたならライフタイムの記述は正しい」と「7) コンパイラのエラーメッセージはプログラムの直し方を教えてくれる」

https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md

**デフォルトの名無しさん** · 2024/08/13(火) 14:04:43.72

Rustの問題じゃないね
チーム適用や実要件に当てはめて見る実務マと趣味マの違い

**デフォルトの名無しさん** · 2024/08/13(火) 16:05:15.51

>>157
それは詭弁
例えばその「5) コンパイルされたならライフタイムの記述は正しい」
まずこれは参照の安全性を保証するRustとしては常に正しい

もちろん複数の参照が登場する時は色んな組み合わせのライフタイムの付け方がある
それらのうち参照の安全性を保証できる組み合わせのみをコンパイラは通す
コンパイルが通る組み合わせのうちどれが自分の意図なのかは各自の問題となる

もし自分の意図と異なっていた場合はそれが利用されるところで参照が切れてコンパイルエラーとなる
そのため間違っていたことに気づくことができる
そして修正してコンパイルが通れば記述は正しい
その記事の例でもこの流れで正しい記述にたどり着けている