Rust part27

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

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

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

**デフォルトの名無しさん** · 2025/01/11(土) 10:21:28.46

むむっ

**デフォルトの名無しさん** · 2025/01/11(土) 11:00:56.87

そもそもMozillaはRust開発者の大半をリストラしてしまったし
すでに単なる1ユーザ企業に過ぎなくて、Rustの発展にはあんまり関係なくなってる
どちらかというとMDNを維持できるかとかの方が重要そう

**デフォルトの名無しさん** · 2025/01/11(土) 11:44:47.56

GoogleはChromeが独占禁止法違反にならないようにFirefox支援しててMozillaは生きててもらわなきゃならん
デフォルトの検索エンジンに採用する見返りにGoogle社から受け取ってる金がMozillaの収益の90%を占めるから潰すのはその金を絞るだけでいい

**デフォルトの名無しさん** · 2025/01/11(土) 12:13:12.32

>>187
おまえ日本語不自由なら無理に書き込まなくてもいいんだよ？

**デフォルトの名無しさん** · 2025/01/11(土) 12:35:47.49

>>188
お前には難しかったか
すまんな

**デフォルトの名無しさん** · 2025/01/11(土) 12:37:03.90

添削してあげる

GoogleのChromeが独占禁止法違反にならないように対抗馬のFirefoxにある程度台頭してもらう必要がある
そのためGoogleはMozillaを投資している
投資の一例としてMozillaはデフォルトの検索エンジンに採用する見返りにGoogleからMozillaの収益の90%を占める投資を受け取ってる
仮にGoogleがMozillaを潰すのならその投資を絞るだけでいい

**デフォルトの名無しさん** · 2025/01/11(土) 12:38:54.31

訂正

誤そのためGoogleはMozillaを投資している
正そのためGoogleはMozillaに投資している

**デフォルトの名無しさん** · 2025/01/11(土) 12:49:21.17

いずれも着実にRust化

**デフォルトの名無しさん** · 2025/01/11(土) 12:57:56.78

>>190
俺より頭が良さそう
尻拭いしてもらってすまんな

**デフォルトの名無しさん** · 2025/01/11(土) 16:20:18.17

ところがMozillaに資金援助してるのが
独禁法違反ともめてるわけだ

**デフォルトの名無しさん** · 2025/01/12(日) 23:53:09.91

ChromeもMozillaも各々Rust化へ向かってるなら
今後はここでもう揉めなくて済むな

**デフォルトの名無しさん** · 2025/01/13(月) 05:20:11.26

>>189
結局添削されてるな
ガイジ乙

**デフォルトの名無しさん** · 2025/01/13(月) 13:52:02.59

>>188
あなたは頭が不自由なのですね判ります

**デフォルトの名無しさん** · 2025/01/13(月) 16:13:11.82

Rust 1.84.0でprovenance関係が安定化されてるね

**デフォルトの名無しさん** · 2025/01/18(土) 10:00:11.55

Rustで描かれてるMozillaがめっちゃ不安定なんすけど

**デフォルトの名無しさん** · 2025/01/18(土) 10:07:56.33

>>199
Mozillaのメモリ管理や中核部分はC++で書かれている

**デフォルトの名無しさん** · 2025/01/19(日) 17:48:38.01

＞2016/07/20 まとめ：Firefox 48 には、Rust で書かれたコードが初めて含まれます。以降のバージョンにも Rust での実装が予定されている部分があります。
10年掛けてまだ置き換わってないってどういう事なの

**デフォルトの名無しさん** · 2025/01/19(日) 18:43:58.99

現場を動かすほどの言語じゃなかったってこと
いずれ忘れ去られていくだろうねｗ
必死で宣伝するやつはしばらく残るだろうけど

**デフォルトの名無しさん** · 2025/01/19(日) 18:56:23.31

Rust化を進めようとしているのはChromeの方だよ
ソース >>182 >>184

**デフォルトの名無しさん** · 2025/01/19(日) 21:30:19.41

>>201
単純に考えてその時点で約20年積み上がってからね

**デフォルトの名無しさん** · 2025/01/19(日) 21:49:11.92

firefoxシェアほとんど無くなって自立収入ではやっていけなくて
独占禁止法を逃れるためのGoogleからの資金で開発やってるから
基本部分は変えずに独自機能の強化の方に力を入れてるんじゃないかな

**デフォルトの名無しさん** · 2025/01/19(日) 21:58:50.96

GoogleはRustでXilemやってるね

**デフォルトの名無しさん** · 2025/01/25(土) 15:49:13.35

WindowsのOsStringってなんでUTF-16直接保持しないであんな面倒なことやってるんだろ

**デフォルトの名無しさん** · 2025/01/25(土) 20:21:28.98

>>207
Rustは時代に応じて文字列をUTF-8で扱っていてString型には必ず正規なUTF-8が入ることが保証される
しかし外の世界は魑魅魍魎でUnicodeですらないものを扱えないといけない
ファイル内容やネット通信でUTF-8以外が定められてるならencoding_rsを使って明示的に変換しながら読み書きする

**デフォルトの名無しさん** · 2025/01/25(土) 20:22:51.37

>>207
一方で問題となるのはファイルシステムのパス等だ
OS環境毎に異なるプログラムは書きたくないからコード上はString型つまりUTF-8で統一して扱いたい
パスがUTF-8自体もしくはUTF-8に1対1で対応するUTF-16等ならプログラム中はString型(＝UTF-8)で扱えてうれしい
しかしパス内にはUTF-8に変換できないものも含まれている可能性があるためOsString型(＝UTF-8＋α)として区別して扱う

**デフォルトの名無しさん** · 2025/01/25(土) 20:30:47.77

>>207
OsString型は以下の2つを満たす抽象的な型となっている
正規UTF-8のみを含むならばコスト無しでString型に変換できて逆にString型からは常にOsString型にコスト無しで変換できる
各OS環境で扱える全ての表現と1対1に対応できる(特に正規なUnicodeならばUTF-8に対応する)
この1対1が重要でありUnicodeでない場合も読み書きしての同一性が保証される
これらを満たせば内部の構造は自由でありユーザープログラムがその構造に依存することはなく構造を知る必要もない

**デフォルトの名無しさん** · 2025/01/25(土) 20:42:28.32

>>207
Windows OSのUTF-16環境であってもユーザープログラムは環境の違いを気にせず統一して扱えるようにString(＝UTF-8)とOsString(＝UTF-8＋α)で扱う
そのため正規なUTF-16はUTF-8に変換して内部で扱うことになる
しかし実際には任意の16bit列がパス等に現れることも可能なのでUTF-16以外の場合も1対1にOsStringに変換できなければならない
この任意の16bit列にはUTF-16のみの場合も含まれるため区別してWTF-16と呼ぶ
つまりWTF-16＝UTF-16＋αの関係になっている
あとはそれと1対1に対応するWTF-8＝UTF-8＋αを上手く定義してやれば前述の性質を満たす内部構造が完成する
以上おわり

**デフォルトの名無しさん** · 2025/01/25(土) 22:15:52.59

> Windows OSのUTF-16環境であってもユーザープログラムは環境の違いを気にせず統一して扱えるようにString(＝UTF-8)とOsString(＝UTF-8＋α)で扱う

OsStringの内部エンコーディングがWTF-16だと統一的に扱えないと言いたいの？

**デフォルトの名無しさん** · 2025/01/25(土) 22:25:37.00

どうなっているか、ではなく、なぜそうなっているか

**デフォルトの名無しさん** · 2025/01/25(土) 23:56:53.55

String <-> OSString <-> System Native String

右の変換コストよりも左の変換コストを下げることを優先してる
そのほうが標準ライブラリ内部で共通の実装や似通った実装を使いやすい

**デフォルトの名無しさん** · 2025/01/26(日) 00:33:00.73

System Native Stringは直接取り扱わず、OsStringでラップして扱うのが原則なら
ゼロコスト抽象化の観点から言えば右の変換コストをゼロにするべきでは？
左の変換は必ず行うとは限らないのだから

**デフォルトの名無しさん** · 2025/01/26(日) 00:38:12.14

というか、Windows以外なら実際右の変換が実行時チェック無しのゼロコストになってて、左の変換時にチェックしてるんだから、その説明には合わないじゃないか
どこにそんな説明が書いてあるんだ

**デフォルトの名無しさん** · 2025/01/26(日) 01:11:13.56

>System Native Stringは直接取り扱わず、OsStringでラップして扱うのが原則なら
別にそんな原則ない
OsStringで楽できないなら使わなくてもいいよ

>ゼロコスト抽象化の観点から言えば右の変換コストをゼロにするべきでは？
それは君がマルチプラットフォーム対応のライブラリを維持管理する立場で考えず
Windows中心でしか物事を見てないからだよ

>というか、Windows以外なら実際右の変換が実行時チェック無しのゼロコストになってて、左の変換時にチェックしてるんだから
間違って理解してるね

>どこにそんな説明が書いてあるんだ
公式ドキュメント

**デフォルトの名無しさん** · 2025/01/26(日) 13:21:14.47

？ちょっと調べたらバレるくだらない嘘つくんだったらもう相手してあげないよ

**デフォルトの名無しさん** · 2025/01/26(日) 18:31:50.46

外部と内部でデータの表現形式が異なる場合
外部に従属するソフトウェアを作ってるのでなければ
可能な限り境界に近いところで変換を行うのは当然の選択

**デフォルトの名無しさん** · 2025/01/26(日) 19:05:06.86

外部とUTF-8変換する微々たるコストが深刻になる用途があるならば標準ライブラリを使わずに独自に実装すればよいだけの話
標準ライブラリはAsRef<OsStr>やAsRef<Path>でそのままstrやStringが使えるように設計されている
File::openなどでのパス指定の引数もこのAsRef<Path>がトレイト境界となっている
as_で扱える設計が望ましい

**デフォルトの名無しさん** · 2025/01/26(日) 20:54:35.44

>>220
後半の話は全然関係ないじゃん

**デフォルトの名無しさん** · 2025/01/26(日) 21:10:37.51

>>221
後半ためにはOsStringがStringを含む拡張になっていなければならない
そうなっていれば型の読み替えだけでas_refできる

**デフォルトの名無しさん** · 2025/01/26(日) 22:23:21.64

>>222
それは>>213が書いてるようにどうなってるかの話で
なぜそうなってるかの理由ではないよね

File::openはAsRef<Path>を受け取るけど
windowsならすぐにVec<u16>に変換されてる

仮にwindows向けOsStrの内部がu16ベースで
File::openがInto<Path>を受け取る実装だったとしても
処理内容は変わらない

**デフォルトの名無しさん** · 2025/01/27(月) 20:17:02.44

>>223
それは違うな
str.as_ref()と参照を読み替えるだけでOsStrになることが重要
そのためOsStrとstrのPartialEqも用意されていてコストなく比較可能
UTF-8のみであればOsStrとstrは一致することが本質

**デフォルトの名無しさん** · 2025/01/27(月) 23:21:32.51

>>224
どれも結果であって原因ではないね

>str.as_ref()と参照を読み替えるだけでOsStrになることが重要
なんで重要なの？

>そのためOsStrとstrのPartialEqも用意されていてコストなく比較可能
OsStrとstrをコストなく比較可能にするために
System Native StringをOsStrにするタイミングでコストがかかってる
コストをかけるタイミングだけの違い
OsStrとstrがコストなく比較可能でなければならない必然性は全くない

**デフォルトの名無しさん** · 2025/01/28(火) 15:31:40.54

ファイル操作なんてI/O負荷の方が高いんだからファイルパスの変換コスト気にする必要あるか？
文字コードが違う環境はwindows以外にも色々あるだろうし。

**デフォルトの名無しさん** · 2025/01/28(火) 16:58:57.81

直交する話を持ち出しても元の議論には一切影響しませんが

**デフォルトの名無しさん** · 2025/01/28(火) 20:40:46.87

一般的な話として
アスキー非互換かつサロゲートペア問題を抱えるUTF-16は欠陥品なので使用は好ましくない
UTF-16や16bitで扱うシステムはユニコードが16bit時代に決めた古いシステムがほとんどで稀に後に無知者が導入したものがある程度

Rustで文字charは正しく32bitとなっており
文字列strはネット上やファイル内でも推奨されアスキー上位互換のUTF-8になっている
さらにOsStrはそのUTF-8の上位互換となり集合的にはOsStr⊃str⊃アスキーとなっている
それさえ満たせば細かい内部実装は各OS毎に異なってよい
欠陥品のUTF-16は何も満たせずそこでも排除で正しい

**デフォルトの名無しさん** · 2025/01/28(火) 22:01:50.93

また意味のない話を始める
さすが複オジ

**デフォルトの名無しさん** · 2025/01/29(水) 00:32:12.48

OsStringの用途はファイルパスに限られたものではないけど主たる用途で性能が問題にならないというのは今の実装方法が選ばれた理由の一部ではある

**デフォルトの名無しさん** · 2025/01/29(水) 00:58:47.06

UTF16はメモリとパフォーマンスのバランスが良い
オンメモリの内部形式としては悪くないチョイス

**デフォルトの名無しさん** · 2025/01/29(水) 02:25:08.58

別に理由が無いなら無いと言えばいいのに、変にこじつけようとするから

**デフォルトの名無しさん** · 2025/01/29(水) 07:54:01.03

スレを荒し続けているUTF16信者は何がしたいの？
本気でUTF16がいいと信じているならそういうcrateを作って布教すればいい
そんな需要はないと思うが

**デフォルトの名無しさん** · 2025/01/29(水) 08:41:13.10

>>225
それは >>219 が述べるように「変換は境界で」という基本思想による。
このやり方が複雑さを避ける良い方法だというのは歴史の積み重ねで皆が実感してきたことなので今さらどうこう言っても「その話はもう終わった。蒸し返すな」という気持ちなんだよ。

**デフォルトの名無しさん** · 2025/01/29(水) 10:10:29.66

じゃあせめて「その話」がどのissueでされたかでも貼ってくれないかな

**デフォルトの名無しさん** · 2025/01/29(水) 10:45:41.27

甘え過ぎw

**デフォルトの名無しさん** · 2025/01/29(水) 11:52:20.85

ソース無しの妄想だからそう返すしかないか

**デフォルトの名無しさん** · 2025/01/29(水) 11:54:18.78

複オジはともかく質問者もまだ分かってなかったのか

**デフォルトの名無しさん** · 2025/01/29(水) 21:48:50.26

わかった
少なくともこうして容易に使えることが最低必要条件
fn OsStr::to_str(&self) -> Option<&str>
したがってOsStrはstrを含む拡張集合
それ以外に制約はなく各OS毎に内部実装は自由

**デフォルトの名無しさん** · 2025/01/29(水) 22:07:32.91

それがお前の妄想でないという根拠は？

**デフォルトの名無しさん** · 2025/01/29(水) 23:10:55.15

impl AsRef<OsStr> for str

**デフォルトの名無しさん** · 2025/01/29(水) 23:12:05.86

issueで内部が16ビットではそれが機能しないと

**デフォルトの名無しさん** · 2025/01/29(水) 23:17:05.07

機能しないと議論されて決定してる

**デフォルトの名無しさん** · 2025/01/29(水) 23:58:56.14

>>234
219と225は同一人物だぞ

**デフォルトの名無しさん** · 2025/01/30(木) 00:13:31.97

>>232
特定のプラットフォームに依存するコードはなるべく減らしたいという動機は理解できるんだよね？

可能な限り境界に近いところで外部表現と内部表現の変換を行うことがプラットフォーム依存のコードを減らすことに寄与するというのもわかるよね？

あとは外部の表現形式を内部でも維持したとしてもデメリットを上回る十分なメリットがあるかどうか
OsString/OsStrの主たる用途ではそれだけのメリットはないという判断
メリットがある用途ならOsString/OsStr以外を使いましょうということ

**デフォルトの名無しさん** · 2025/01/30(木) 00:26:18.93

str <-> OsStrの話は差異をうまく隠蔽しにくくシグニチャに影響しうるというのがあるけど仮に影響しなくても境界で変換するのが望ましいという判断は変わらなかったはず

**デフォルトの名無しさん** · 2025/01/30(木) 00:39:30.16

https://github.com/rust-lang/rfcs/pull/575
https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md#string-handling

**デフォルトの名無しさん** · 2025/01/30(木) 20:50:11.01

>>247
ありがとう、RFCのほう探せばよかったのか

> ## Wide string representation
> Downsides:
> * These conversions have inconsistent performance characteristics between platforms. (Need to allocate on Windows, but not on Unix.)

やっと納得できる理由が出てきた、これはたしかにな…いやでもなあ、直接OsString/OsStrを触るAPIがもっと充実していれば別にString/strとの変換をそこまで気にする必要もないのでは？
一気にString/str相当のAPIを実装するのも手間だし、OsString/OsStrで何かやりたかったらとりあえずString/strと変換してなんとかしてくれ、だからここではプラットフォームごとの差を付けたくない、って方針だったのかね？
とはいえ、考えられる発展としていろいろな文字列型を一般化する抽象化を作れるはずとかちゃんと書いてあるし、まあまあ納得できる経緯説明ではある
ありがとうね

> // and ultimately other functionality typically found on vectors,
> // but CRUCIALLY NOT as_bytes

…とか書いてるけど、今は普通にas_encoded_bytesとして実装しちゃってるし、結局なんだかよく分からんなあ

**デフォルトの名無しさん** · 2025/01/30(木) 23:18:13.05

>>248
>> * These conversions have inconsistent performance characteristics between platforms
こう書かれてるけどパフォーマンスという点では特にDownsideじゃないと思うんだけどね
今の実装でも発生してるし違う環境用のOsStringを1つのプログラムが実行時に混ぜて扱うわけでもないし

問題なのは内部コードにアロケーションタイミングの違いみたいなのが侵食して分岐が増えること
わかりやすい例としてはOsStr::new(“foo”)が&OsStrを返せなくてCow<OsString, OsStr>になるとか

**デフォルトの名無しさん** · 2025/01/30(木) 23:38:58.04

そうだね
だから現状の仕様で正しくて
10年間も問題視されていない
許容できない用途が仮にあるならWindows専用のクレートを作ればいい

**デフォルトの名無しさん** · 2025/01/30(木) 23:54:08.19

as_encoded_bytesの話はこれ
https://github.com/rust-lang/libs-team/issues/306

**デフォルトの名無しさん** · 2025/01/31(金) 02:25:28.04

> # Alternatives
> * A split_at(&self, pos: usize) -> (&OsStr, &OsStr) style method. This is ostensibly simpler than a slicing API. But:
> ** The OMG-WTF-8 encoding does not support this. It requires some splits to produce overlapping slices, so that left.len() + right.len() > orig.len(). The encoded bytes on one side of pos might form a valid OMG-WTF-8 string while those on the other side do not.
> *** RFC #2295 that proposes this encoding was merged five years ago (but has not been implemented).

何その絵に描いた餅を喉に詰まらせて死ぬみたいな話……

**デフォルトの名無しさん** · 2025/02/03(月) 22:01:34.61

ほとんどのシステムはUTF-8以外のファイル名があったら無視かエラーでいいからどうでもええわ

**デフォルトの名無しさん** · 2025/02/06(木) 13:08:01.16

https://mevius.5ch.net/test/read.cgi/tech/1691038333/514-528

ﾜｯﾁｮｲ付いてないとどこにでも出るな妖怪

**デフォルトの名無しさん** · 2025/02/07(金) 13:12:05.02

LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中 - TechFeed
https://techfeed.io/entries/67a52d4677bdbc0f2990eed9

争え……もっと争え……

**デフォルトの名無しさん** · 2025/02/07(金) 21:47:52.74

Linusが一喝するまで収めるの無理やろ

**デフォルトの名無しさん** · 2025/02/07(金) 22:08:06.65

そりゃドライバーはカーネルのインターフェイスに従って動作すべきだから、ラッパーなりで隠蔽すべきなんじゃないんかね。

個別のドライバーのためにカーネル側をカスタマイズするのはインターフェイスを侵食する越権行為だから、そんなのドライバーのラッパー側でやれ、と言いたくなるのはわかる。

**デフォルトの名無しさん** · 2025/02/08(土) 23:53:09.62

>>257
それは君の理解が間違っている

今回はRust製の各デバイスドライバが独自のCバインディングを持つ不便な状況を改善するためのパッチだ
つまりカーネルのC側に手を入れるパッチではなくC側は同じままで変更は一切ない
今回の件は該当部分dma_alloc_coherent()のC⇔Rustの抽象ラッパーのコードを含めるパッチだけだ
それさえメインテナーに拒否されたため大問題になっている

**デフォルトの名無しさん** · 2025/02/08(土) 23:57:46.16

デバドラはRustで書くのが普通になってきているから
そういう共通ラッパーという形のRustインターフェイスが色々と欲しいのよね
でもそれはいずれカーネル自体のRust化へ繋がる道になるから強く反対してるのよ

**デフォルトの名無しさん** · 2025/02/09(日) 00:59:41.26

普通に考えたら異種の言語が混ざるとデバッグと開発の障害でしかないからどこかで境目は必要

**デフォルトの名無しさん** · 2025/02/09(日) 06:01:46.16

>>258
メンテナーがRust用コードのメンテナンスを拒否したということじゃないの？
Rust for Linuxでサポートするような話じゃないんかね。

**デフォルトの名無しさん** · 2025/02/09(日) 06:47:59.48

>>260
異種の言語を混ぜる話なんか誰もしていない
今回の事件のパッチも異種の言語を混ぜることなくCのAPIはそのままで
その上にRustの層を作る話

In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.

**デフォルトの名無しさん** · 2025/02/09(日) 08:50:09.78

最終的にRust側のメンテナが切れてSNSで晒したりしたのは良くなかったけど
技術的にはC側に迷惑かからないように十分配慮して、出てきた懸念も全て潰したにも関わらず
「とにかくRustに関わりたくないから却下」だったからまぁ切れるのも分かる

**デフォルトの名無しさん** · 2025/02/09(日) 09:09:11.56

>>263
そのコードはcで使えるの？
使えるならともかく、Rust専用ならメンテナーが「そんなののメンテナンスで負担増えるのは嫌だからRustドライバー側でやってくれ」というのもわかる。

Rust for Linuxはこういうのの受け皿にならんのかしらん？

**デフォルトの名無しさん** · 2025/02/09(日) 09:24:37.62

>>264
受け皿も何もそもそもRust for Linuxでやってる話だし
完全にRustドライバー側でやるからCには影響しないって言ってるわけ
具体的にメンテナンスの負担が増える理由を挙げてくれれば対応策も考えられるけど
「とにかくお前らを邪魔するためなら何でもする」って言ってるからどうしようもない

**デフォルトの名無しさん** · 2025/02/09(日) 10:38:22.52

>>265
メンテナが「Rustは俺のサポート範囲に出てこないでドライバ内で閉じてやってくれ」と言うんだから、当面はrust fir linux でドライバーのテンプレートを作るなりCバインディングサポートライブラリを作るなりすればいいんじゃないんかね。

「Rust製の各デバイスドライバが独自のCバインディングを持つ不便な状況」というのもrust fir linuxでフレームワーク作ってサポートすれば解決するし。

**デフォルトの名無しさん** · 2025/02/09(日) 10:58:29.23

互いにブラックボックス内でなにが起ってるのかわからないとすると困るけどね

コレコレこういうコードを書いたらこういう結果が出るはずなのに出ないとコード提示されても
相手が理解できなければこじれるだけ

**デフォルトの名無しさん** · 2025/02/09(日) 11:17:45.05

>>266
そこで言う当面はってのは3-4年前の状況かな
今はもう準備も整って、Mac用のAsahiLinuxとかAndroidとかフォークしてる勢には普通に入ってる段階
だからそろそろ本体にって話になってるわけだけど、拒絶されるなら彼らはフォークに戻っていくだけだとは思う

**デフォルトの名無しさん** · 2025/02/09(日) 11:46:40.81

>>256
Linusの返答も出てるな
https://x.com/lauriewired/status/1888018962811863109

**デフォルトの名無しさん** · 2025/02/09(日) 12:46:41.58

内部の問題をSNSつかって文句言うなアホ
お前が問題じゃ

**デフォルトの名無しさん** · 2025/02/09(日) 13:50:57.72

ここや他のスレでRustに意味のわからん難癖つける人が
いるのは5ちゃん民度のせいではないのがわかった

**デフォルトの名無しさん** · 2025/02/09(日) 14:20:31.41

C++に似ている部分はC++と同じ程度に批判される
それとハイブリッド的な部分
100%ガソリンで動くか100%電気で動くかどっちかにしろという

**デフォルトの名無しさん** · 2025/02/09(日) 16:28:50.86

>>268
該当コード用のメンテナがRustを使いこなすようになるか、専用のメンテナが別に現れるか、現在のメンテナが引退してRust推進のメンテナに代わるまでじゃない？

これはメンテナの複雑性管理＆管理ポリシーの問題だから、普及具合とかはあんまり関係ない。

**デフォルトの名無しさん** · 2025/02/09(日) 23:42:15.23

色んなものがRust製になっていく中
最後まで残りそうなのが巨大でモノリシックなカーネルとブラウザになりそうだな

**デフォルトの名無しさん** · 2025/02/10(月) 00:33:23.09

日本の古文漢文は残らないかもしれないが西洋では全部保存していて選択肢が増えるだけ
だから、向こうが世界の中心みたいな空気になる

**デフォルトの名無しさん** · 2025/02/10(月) 16:53:59.27

firefoxはまだrust製にはならんの？

**デフォルトの名無しさん** · 2025/02/10(月) 17:38:09.01

Linux カーネルは保守的な方針だろ。
数年前まで C89 が前提だったんだぞ。
この速度感で考えるなら Rust 導入なんてまだまだ時期尚早じゃね？

**デフォルトの名無しさん** · 2025/02/10(月) 19:19:29.76

Firefoxのレンダリングエンジンは大分前からRust製（Servo）でしょ

**デフォルトの名無しさん** · 2025/02/10(月) 19:49:30.60

>>278
Servoにそんな完成度はない
実験レベル

**デフォルトの名無しさん** · 2025/02/10(月) 22:57:20.26

錆→癌

**デフォルトの名無しさん** · 2025/02/10(月) 22:59:57.28

Mozillaお金なさすぎて色々と切り捨てて
RustもRust Foundationへ移管されたもんな
結果的にRustにとっては中核が安定してラッキーになったけどさ

＞ 2020年にMozillaがすべてのServo開発者を解雇した後、プロジェクトのガバナンスはLinux Foundation Europeに移管された。
＞開発作業は公式には同じGitHubリポジトリで続けられており、プロジェクト自体は完全にボランティア主導です。

**デフォルトの名無しさん** · 2025/02/10(月) 23:42:58.20

C/C++その他の知識を蒸留してないわけがないから
コストもコスパもないんだよ

**デフォルトの名無しさん** · 2025/02/12(水) 22:57:39.73

Pointers (this includes values of reference type) in Rust have two components.
- The pointer's "address" says where in memory the pointer is currently pointing.
- The pointer's "provenance" says where and when the pointer is allowed to access memory.
We have to know not only the address the pointer points to,
but also track which other pointer(s) it is "derived from".
Provenance is useful because it allows powerful optimizations.
Provenance can affect whether a program has undefined behavior.

**デフォルトの名無しさん** · 2025/02/16(日) 23:45:42.12

Rust Tokyo 2024 開催レポート
https://gihyo.jp/article/2024/12/rust-tokyo-2024-report