Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

**デフォルトの名無しさん** · 2024/06/15(土) 12:55:07.64

>>148
置き換える意味があるかないかの問題でしょ
ほぼシステムコールなグラフィックAPIのRust実装の有意義性はあるのか

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

>>148
根っこを捨ててpure Rust で再構築したとして
それは置き換えたんじゃなくて
別のものを似せて造り治しただけじゃないのか

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

>>149
完全に pure Rust の OS があったとして
その上で動くアプリケーションは全て Rust で描かないといけない世界が良いのか
Rust OS の上でも C/C++ で開発したい(API は C 相当)のかで意見が変わる

**デフォルトの名無しさん** · 2024/06/15(土) 13:33:19.67

完全に純粋に一人で打席に立つことは
そいつの年収やそのカネの所有権を定義するのに必要みたいな感じでしょ

**デフォルトの名無しさん** · 2024/06/15(土) 15:03:07.44

勘違いしてる人が多いようだけど
Rustの目的は全てをRustで書くことではなく安全にすることなんだよ
だからOSシステムコール呼び出しもRust(と最小限の各アーキテクチャ毎のレジスタ積み等)で頑張るのではなくCで書かれたlibcを用いている
つまりRustのunsafe部分を最小限にするとともに、unsafeだが枯れて安全なlibcを活用している

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

勘違いしてんのはここでまともなRustの話ができると思ってるお前だよ

**デフォルトの名無しさん** · 2024/06/15(土) 15:51:53.03

概論でいいんならこれ貼るよ

オブジェクト指向を学ばなかった話
https://qiita.com/adaiimps/items/e04ae03371435aeffe87

**デフォルトの名無しさん** · 2024/06/15(土) 15:54:39.14

自分は pure Rust に全然拘っていないし
むしろ unsafe 大好きだが
pure Rust に拘ってる人や
unsafe 絶対無くせって言ってる人も居るのを知ってる
後者は基地外

**デフォルトの名無しさん** · 2024/06/15(土) 16:13:09.69

use std::io::{self, BufRead, BufReader};
const FULL_BITS: u32 = (1 << 26) - 1;
fn main() {
　let mut shortest: Option<String> = None;
　for line in BufReader::new(io::stdin()).lines() {
　　let line = line.unwrap();
　　let mut bits = 0;
　　for b in line.as_bytes() {
　　　let index = match b {
　　　　b'A'..=b'Z' => b - b'A',
　　　　b'a'..=b'z' => b - b'a',
　　　　_ => continue,
　　　};
　　　bits |= 1 << index;
　　}
　　if bits != FULL_BITS {
　　　continue;
　　}
　　if let Some(ref shortest) = shortest {
　　　if shortest.len() < line.len() {
　　　　continue;
　　　}
　　}
　　shortest = Some(line);
　}
　if let Some(shortest) = shortest {
　　println!("{shortest}");
　} else {
　　eprintln!("ERROR: no matched lines");
　}
}

**デフォルトの名無しさん** · 2024/06/15(土) 17:55:06.95

ソースコードのコピペで止まるスレ

**デフォルトの名無しさん** · 2024/06/15(土) 20:29:16.21

ソースコード貼るなんて暴力ですよ！

**デフォルトの名無しさん** · 2024/06/15(土) 21:06:34.26

コピペしただけなんだけどね

http://mevius.5ch.net/test/read.cgi/tech/1691038333/6

**デフォルトの名無しさん** · 2024/06/15(土) 21:09:34.98

>>156
unsafeは好き嫌いというよりも
最下層のCPUとメモリもしくは境界のFFIで必須な存在とみるべきではないかな
ただしそこだけにunsafeを閉じ込めて一般プログラマーはsafeなインタフェイスのみを使う

**デフォルトの名無しさん** · 2024/06/15(土) 21:10:47.55

一行のコードも書かずに形而上学みたいにプログラミングを学ぶ贅沢はいいね

**デフォルトの名無しさん** · 2024/06/15(土) 21:54:03.45

Rust「で」作るんじゃなくてRust「を」作る秘密が知りたいんだよね
すべてのソースコードがコンパイル時に手元にあったとして、メモリの使途を解析してしまえるなんて普通は思わないからね
この点を「たまたま思いついた天才がいた」で済ませたくない

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

Copy型とそうでない型。よろしい
Copy型の自動変数みたいにそうでない型もスコープを抜けると解放。それはよろしい
しかしそんなものは遥か実用に遠い

**デフォルトの名無しさん** · 2024/06/15(土) 22:29:19.17

いったい何がきっかけでメモリの使途を把握してしまえるかもと思ったか
それが分かるまでごくごくゆっくりとしか勉強しないよ

**デフォルトの名無しさん** · 2024/06/15(土) 22:33:28.01

ヒープを一切使わないパラダイムは昔に戻っただけ
スタックの安全性だけを考えてヒープはライブラリに任せる

**デフォルトの名無しさん** · 2024/06/15(土) 22:46:06.16

全部スタックでやってるって本当の話なの？

**デフォルトの名無しさん** · 2024/06/15(土) 22:51:02.34

allocaとかとっくにあったよ？

**デフォルトの名無しさん** · 2024/06/15(土) 23:22:17.89

逆のものを想像してんだけどな
スタックでなくヒープにあっても同じなのがRustじゃないの？

**デフォルトの名無しさん** · 2024/06/15(土) 23:47:36.34

参照の寿命が尽きても参照元のデストラクタは呼ばれない
だから参照元がヒープにあろうがなかろうが参照の寿命はスタックに基づいて決めてしまえば良い

**デフォルトの名無しさん** · 2024/06/16(日) 00:42:56.54

>>170
「参照元」は誤用か
参照先と言うべきだったか

**デフォルトの名無しさん** · 2024/06/16(日) 00:50:00.04

>>169
スタック上への参照とヒープ上への参照をRustでは区別しない
ライフタイムさえ満たしていればどこを指していても区別なく参照を扱う
そのため、従来行われてきた「安全にヒープ上でに領域を確保してヒープ上への参照を返す」をしなくても
ライフタイムさえ満たしていればスタック上への参照を安全に渡したり返したり自由にできるようになった
そのため、従来はヒープ上に確保していていたケースがRustではスタック上に置くことができるようになり、その点でも高速化に寄与している

**デフォルトの名無しさん** · 2024/06/16(日) 01:00:26.12

複オジのレスはいつも通り8割は嘘だな

**デフォルトの名無しさん** · 2024/06/16(日) 01:15:13.88

>>172
別にC言語だってallocaの返したポインタとmallocの返したポインタを区別しないけど

**デフォルトの名無しさん** · 2024/06/16(日) 01:25:03.80

誰が解放するか責任もなく解放忘れや多重解放を生むＣ言語は論外だろ
解放されたスタックフレームやヒープエリアを指し続けているポインタが残ったりな

**デフォルトの名無しさん** · 2024/06/16(日) 01:32:46.10

C言語と違って区別しないわけじゃないし、C言語と違って高速ってわけでもない

**デフォルトの名無しさん** · 2024/06/16(日) 01:39:48.74

C言語同様に区別しないし、C言語同様に高速なんでしょう

**デフォルトの名無しさん** · 2024/06/16(日) 01:45:22.24

そろそろ自己隔離しとけザコども

結局C++とRustってどっちが良いの？ 9traits
ttps://mevius.5ch.net/test/read.cgi/tech/1701997063/

**デフォルトの名無しさん** · 2024/06/16(日) 03:32:45.56

へえ、コピーじゃなくて移動をデフォにしちゃうのか

**デフォルトの名無しさん** · 2024/06/16(日) 04:03:11.69

>>174
mallocで得たポインタとallocaで得たポインタは明確に区別しなければならない
mallocで得たポインタのみfreeの対象としなければならない
この区別はCプログラマーの責務でありミスると破綻する

**デフォルトの名無しさん** · 2024/06/16(日) 04:10:20.19

>>180
コンパイラが区別してくれるわけじゃないからそう書いた
今はRustコンパイラの秘密を探ってるんだし

**デフォルトの名無しさん** · 2024/06/16(日) 04:28:58.35

Rustはヒープで確保したメモリ領域も完全自動で安全にメモリ解放されるからプログラマーの負担がなくていいよね

ヒープへの参照とスタックへの参照に区別がないだけでなく
それらをたとえ混ぜて関数間で渡したり返したりたらい回しにしても安全で
もし安全でない使い方をした時はライフタイムが切れてコンパイルエラーになるから自由と安全が両立されてるね

警備員[Lv.18] · 2024/06/16(日) 04:37:34.79

解放されたスタックフレームが残って、どうやって呼び出し元に帰るつもりなんだろう。😱

**デフォルトの名無しさん** · 2024/06/16(日) 04:43:29.58

メモリはコピーじゃなくて（所有権の）移動がデフォ
所有者がスコープを抜けるとメモリは解放
所有者に別の値が代入された際もメモリは解放
代入元は所有権が移ると未初期化の扱いになる

これだけでもかなり面白いね

**デフォルトの名無しさん** · 2024/06/16(日) 04:50:45.28

>>183
C/C++/Rustすべて関数が呼び出し元に戻るときにスタックフレームは自動解放されます
もしその破棄されたスタックフレーム上を指すポインタ(参照)がどこかに残っていた場合、
C/C++ではそのポインタ使用でそこをアクセスしてしまい気づかないバグや穴となるでしょう
Rustではコンパイル時点でライフタイムエラーとなるため問題が起きないです

**デフォルトの名無しさん** · 2024/06/16(日) 05:46:32.57

正体不明のボイス・トォ・スカル
マイクロ波聴覚効果の機能より

神の声兵器は機器の場所が割れているので
ハッキング下と奪取後に器機を複製できた音を宣言していた

電磁波音波なのでむやみに器機に仕掛けると誰かが攻撃しているとすぐに設置したものは察知するが
その監視網をかいくぐるということは一発で危機をジャックしたことになる

そして機器の性能は年々よくなるので自分に行って見分けがつかないくらいになると器機使用者が幻覚を見ていると錯覚し始める

**デフォルトの名無しさん** · 2024/06/16(日) 06:03:13.93

メモリはそれ自体は無論のこと、それを指すポインタもひとつしかないわけだ

**デフォルトの名無しさん** · 2024/06/16(日) 07:56:02.10

この発想は正直なかったわ
ひとつのメモリをあちこちから参照すればするほど高効率みたいな思い込みがあるからね

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

>>167
>全部stack
そういう描き方をすればそうなるってだけで
そういう描き方ならCでも出来る

**デフォルトの名無しさん** · 2024/06/16(日) 10:11:02.64

>>169-171
CにBoxを導入すれば解決

**デフォルトの名無しさん** · 2024/06/16(日) 10:13:30.02

>>173
ほんそれ

**デフォルトの名無しさん** · 2024/06/16(日) 10:32:48.33

で、配列の要素だったり構造体のメンバだったりは「移動済み」にできない？

**デフォルトの名無しさん** · 2024/06/16(日) 10:36:59.18

とにかく&をつければアドレスを借用できて、その生存規則違反はコンパイラがはじく、と

**デフォルトの名無しさん** · 2024/06/16(日) 10:41:20.79

新参に教えといてあげると
172, 175, 180, 182あたりはすべて複製おじさん(通称複オジ)という同一人物だよ
知ったかぶりで出鱈目ばかり書いて全く反省しないという
悪い意味で有名な人ので騙されないように注意してね

**デフォルトの名無しさん** · 2024/06/16(日) 10:51:27.98

1日10行推敲するより1日1万行書いた方が数値化に貢献しやすいからしょうがない

**デフォルトの名無しさん** · 2024/06/16(日) 11:21:38.24

ボローチェッカーは作るのも使うのも難しそう
よくこんなこと可能だと思ったもんだ

**デフォルトの名無しさん** · 2024/06/16(日) 11:48:19.48

Rustの中ではつまらないというか泥臭い部分だね

**デフォルトの名無しさん** · 2024/06/16(日) 12:06:57.33

>>196
ライフタイムについてまじめに知りたいなら（ある程度Rustには慣れた前提として）NLLのRFCを読むのをおすすめしたい
ttps://rust-lang.github.io/rfcs/2094-nll.html

そろそろこれよりいい資料は出ないもんかね……というかReferenceに明記してもらえんかね
なんか1.79でも地味にルールが拡張されたようだし

**デフォルトの名無しさん** · 2024/06/16(日) 12:23:11.10

ええっと、メモリの所有者が
・スコープを抜けること
・別の値が代入されること
・別の変数に所有権を移動させること
はもともと検出できる前提なのだよね
ボローチェッカーと言ってもその３つの組み合わせに毛が生えた程度なのかどうか

**デフォルトの名無しさん** · 2024/06/16(日) 12:27:02.82

>>198
全ての言語仕様を「仕様書」としてまとめる提案は出ているんだけど何年も動きがないんだよね……

**デフォルトの名無しさん** · 2024/06/16(日) 12:30:31.60

>>174
allocaで得たポインタfreeしてそうなコメントだな

**デフォルトの名無しさん** · 2024/06/16(日) 12:32:49.98

>>199
メモリとかアドレスとか言ってる時点で正確な理解から遠いと思う。
変数はメモリではないし、参照はアドレスではない。
処理系の実装としてはそのように対応するという想定はあるだろうけど機械語レベルの事情と言語のルールはレイヤが違う。

**デフォルトの名無しさん** · 2024/06/16(日) 12:33:46.16

>>201
機械語知ってるからそんな心配はない

**デフォルトの名無しさん** · 2024/06/16(日) 12:36:26.13

>>202
そうだね。Rustは高級アセンブラってわけではまったくないね。勘違いしてた

**デフォルトの名無しさん** · 2024/06/16(日) 12:42:20.38

代入だったり関数呼び出しの引数だったりはコピーじゃなくて移動がキホンって時点で機械語ともC言語とも違う

**デフォルトの名無しさん** · 2024/06/16(日) 12:51:16.07

>>205
代入と考えるよりもパターンマッチングと考えるといいかな
＝や引数などで複雑なパターンを書いてもマッチングしてくれるよ
それがたまたま1対1の時が昔からの代入に相当してマッチングして移動

**デフォルトの名無しさん** · 2024/06/16(日) 13:26:09.91

あえて機械語レベルでも考えるとするなら概念的には移動でも (最適化を別にすれば) ビットパターンはコピーしている。
所有権を失った変数にはアクセスできないように静的に制限されるから所有権が移動したように見える。
借用は (借用が存在している間は) 移動を許さない権利として捉えることができる。

**デフォルトの名無しさん** · 2024/06/16(日) 13:35:38.29

>>200
現状だとここを見ておくのがいいかも
https://public-docs.ferrocene.dev/main/specification/index.html
ISO 26262の認定通すために書かれたものだからかなりちゃんとしている

**デフォルトの名無しさん** · 2024/06/16(日) 15:11:48.05

>>208
C/C++はISO認定だからな
一方、Rust連中はほんぽん仕様変える(変えたい)から、そんなISOレベルの仕様書書く意味がないって感じじゃないのか

**デフォルトの名無しさん** · 2024/06/16(日) 15:51:37.66

>>209
C++ だって三年ごとに更新する制度になってるし、その間の議論でも仕様の文面をどう変えるかという形式をとる。
頻繁に変えるつもりがあるならなおさら今どうなってるのかの全体像を把握できる仕組みがないと困る。

**デフォルトの名無しさん** · 2024/06/16(日) 15:52:59.06

RubyもISOになったことあるし

**デフォルトの名無しさん** · 2024/06/16(日) 15:57:39.35

15.4:16 ??? (this should describe the order of borrowing and when the borrow is returned)

わろた

**デフォルトの名無しさん** · 2024/06/16(日) 16:23:56.88

NLLというくらいだからもともとLL

**デフォルトの名無しさん** · 2024/06/16(日) 16:49:41.43

まあ一応（ボローチェッカーというものが）可能そう

**デフォルトの名無しさん** · 2024/06/16(日) 17:20:46.77

コンパイラはプログラム中の全ての参照型に対してライフタイムを割り当てる、と

**デフォルトの名無しさん** · 2024/06/16(日) 17:45:29.17

言語にISO標準を求めるのって相当なお爺ちゃんでしょ
もうそういう時代じゃないですよ

**デフォルトの名無しさん** · 2024/06/16(日) 17:52:05.41

>>215
所有者がどのスタックフレーム(の中のどのブロックスコープ)にいるかだけの話だよな
そこより先なら参照は生きて
そこより元なら参照も死ぬ

もちろんそんな神の絶対的な視点を実行前のコンパイル時点で静的に持つことはできない
しかし各関数内での出入り(引数がinで返り値がout)は静的にわかるから
相対的な視点で有効か無効かわかることになると

**デフォルトの名無しさん** · 2024/06/16(日) 17:55:19.72

>>216
ISO 規格が必要なんて話はしてないだろ。
仕様書が要るって話をしてるんだぞ。

**デフォルトの名無しさん** · 2024/06/16(日) 18:05:26.18

複製おじさんと遊ぼうスレ

**デフォルトの名無しさん** · 2024/06/16(日) 18:43:24.33

>>218
>仕様書が要るって話をしてるんだぞ。
別に全然要らないぞ
逆になんで要るんだ？

**デフォルトの名無しさん** · 2024/06/16(日) 18:44:48.95

ひとつしかない所有者がスコープを抜ける、もしくは所有者に別の値が代入されると、そこから先にはメモリはもうない

**デフォルトの名無しさん** · 2024/06/16(日) 18:57:47.09

なんとなく、所有者はスタックの根元の方に、参照はスタックの枝葉の方にいそうなイメージ

**デフォルトの名無しさん** · 2024/06/16(日) 19:01:15.44

>>221
有効な参照(借用)が存在したまま移動や破棄は起きない
これは静的に判定されコンパイルエラーとなる

**デフォルトの名無しさん** · 2024/06/16(日) 19:08:46.55

>>223
つまり所有権も静的に解析できる？

**デフォルトの名無しさん** · 2024/06/16(日) 19:26:50.69

ここは結局こんな感じなのでID:dwkxcYMWは本当のことが知りたいならrust-lang-jpのZulipにでも行くといい
ttps://rust-lang-jp.zulipchat.com/

**デフォルトの名無しさん** · 2024/06/16(日) 21:12:46.18

>>220
じゃあ言語の仕様をどうやって把握すんの？
何が出来ていれば Rust のコンパイラを実装できましたって言えるの？

**デフォルトの名無しさん** · 2024/06/16(日) 21:13:16.76

>>224
できるというか、それが Rust のキモやで。

**デフォルトの名無しさん** · 2024/06/16(日) 22:06:19.67

ゴールポストを固定することが正しいという考えが衰退したんだよな
正しさを疑うことが常識になったから

**デフォルトの名無しさん** · 2024/06/16(日) 22:29:00.55

>>228
ゴールを設定したいという話じゃなくて「今」どうなっているか見えないと疑うべきものすら存在できないって話なんだよ。

**デフォルトの名無しさん** · 2024/06/16(日) 22:37:41.81

>>226
>じゃあ言語の仕様をどうやって把握すんの？
言語の仕様はリファレンスで把握しろよ

>Rust のコンパイラを実装できましたって言えるの？
言える必要性が全くないやろ
どうしても言いたければ公式が用意してるコンパイラと標準ライブラリのテストを全部通したらいいんじゃね？

**デフォルトの名無しさん** · 2024/06/16(日) 23:02:11.93

>>230
端的に言うと現状のリファレンスマニュアルで Rust の仕様の全てを読み取ることは出来ない。
そのことは >>198 あたりからの話題の流れ。
リファレンスマニュアルは仕様を書くものじゃないし。

**デフォルトの名無しさん** · 2024/06/17(月) 06:58:24.07

【マイクロ波センサー】長距離でも壁があっても動きを検出！
↓2010年ごろには完成
高齢化社会を支える“見守りシステム”の開発に成功-カギを握った半導体ソリューションとは
↓2026年ごろにさらに性能工場
旭化成、ミリ波・マイクロ波帯の空洞共振器による微小金属検査システムを開発

男女関係なく陰部を撮影
一度でも盗撮されていれば正確な色合いの・・・
初期型は赤外線センサー【自動ドアのセンサなど】

子どもが言語を獲得していくのと同じようにAIモデルに学習させることに成功
AIを使って「赤外線カメラ画像のフルカラー化」に成功！

世界中で横行

**デフォルトの名無しさん** · 2024/06/17(月) 16:27:54.49

役に立たないどんぐり

**デフォルトの名無しさん** · 2024/06/17(月) 21:23:17.19

卒業式でみんなで思い出を言うやつみたいだな

卒業生　「そして役に立たないどんぐり！」
卒業生一同　「どんぐり～」

**デフォルトの名無しさん** · 2024/06/17(月) 21:51:46.63

卒業生A　「高速で動作しながら保たれる高いメモリ安全性」
卒業生一同　「安全性！」

**デフォルトの名無しさん** · 2024/06/17(月) 22:06:12.81

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2024/06/18(火) 00:33:44.73

卒業生　「みんなで借りた所有権」
卒業生一同　「所有権！」

**デフォルトの名無しさん** · 2024/06/18(火) 02:26:00.95

AIにC++とRustのコードを比較してもらった
https://nshinchan01.hateblo.jp/entry/2024/06/18/021159

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

見えない仕様書より見えているコロンブスを殴る
殴る

**デフォルトの名無しさん** · 2024/06/18(火) 09:12:34.89

>>238
sum()自体は使わないとしてこうかな

fn foo(input: impl IntoIterator<Item = i32>) -> i32 {
　input
　　.into_iter()
　　.filter(|x| x % 2 == 0)
　　.map(|x| x * 2)
　　.fold(0, |sum, x| sum + x)
}

fn main() {
　let numbers = vec![1, 2, 3, 4, 5];
　assert_eq!(foo(numbers), 12);
}

**デフォルトの名無しさん** · 2024/06/18(火) 12:23:59.59

Rustの仕様と実装の分離ができてないと、公式の実装が唯一になるから困る分野があるんだろうね。
Cとかコンパイラいっぱいあるじゃん。

Rustぐらい複雑で成長途上の言語で仕様を文書化して実装を交換可能にするなんて事実上無理っぽいけど、10年後ぐらいには問題でてくるのかもね。

**デフォルトの名無しさん** · 2024/06/18(火) 12:31:26.48

>>241
現在のRustの仕様は実用的なプログラミングをする上で十分なレベルとなっているけど
さらに便利にするための追加仕様がTODOリストに積まれていてそれらが少しずつ解決されて追加されていってる状況ですね
まだ当面しばらくは現状体制のまま成長させていくのが望ましいと思います

**デフォルトの名無しさん** · 2024/06/18(火) 13:47:06.59

実装が仕様でもいいけど、その場合はその実装のコアの部分を明確にした方がいいかもね

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

GPT-4oがAIベンチマークのARC-AGIで50％のスコアに到達、これまでの最高記録である34％を大幅に更新
2024年06月18日
※さらに最適化すれば７０%以上も可能な模様

スマホに搭載可能な小型透視チップが開発される
2024年06月18日

**デフォルトの名無しさん** · 2024/06/18(火) 16:50:36.49

>>241
Cの標準化の更新なんて10年とかだろうが。

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

>>241
>Cとかコンパイラいっぱいあるじゃん。
それは各チップでそれぞれ別のCコンパイラが必要なのと
クローズドソースでプロプライエタリのコンパイラを有償で販売できる環境があるからだよ

Rustだと各チップで必要になるのはLLVM対応であってRustのコンパイラではないし
リスクをとってまでプロプライエタリなコンパイラをわざわざ作るメリットもほぼない
それにコンパイラが乱立しないというのは今のところはエコシステム的にはメリットしかない

**デフォルトの名無しさん** · 2024/06/18(火) 19:09:22.28

gccが頑張ってるくらい？

**デフォルトの名無しさん** · 2024/06/18(火) 19:12:43.09

団体がすべての主導権を握ってるならある日急にガラッと変えても誰も文句を言えない
実装が仕様です

C++や他の言語で規格がって言ってるのはコンパイラだけの問題じゃなくてコード利用してる側の都合でもある