結局C++とRustってどっちが良いの？ 3traits

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

◆QZaw55cn4c · 2023/05/07(日) 21:21:38.60

>>226
素数に関して突っ込んでいえば、素数の定義と素数の性質＝すべての自然数は素数の積で一意に表現できる、との間には大きなギャップがあるのに、それがあまり意識されていないのが問題

**デフォルトの名無しさん** · 2023/05/07(日) 21:25:03.91

>>227
全く逆だよ
そういうことを差別化要素と捉えてるようなプログラマがいらなくなる
コモディティ化しやすい知識とそうでない知識の違い

**デフォルトの名無しさん** · 2023/05/07(日) 21:34:18.83

>>229
難しくてわかんない
もう少し優しく

**デフォルトの名無しさん** · 2023/05/07(日) 22:10:30.80

バイアスがあった可能性を否定できない　っていうんなら逆方向も否定できないだろうに、なんでこのおじいちゃんは片方にだけ肩入れするん？
不自然ですよ

**デフォルトの名無しさん** · 2023/05/08(月) 00:59:11.95

最大の問題は rustの利用者が何でこんなに少ないかだな
ただこれには複案があっておそらくは C ++から移ってきたやつらがrustをやってると思われる
すると rustの標榜するモットーにも合致すると思われる

**デフォルトの名無しさん** · 2023/05/08(月) 01:13:16.38

もう出ている通りにこの問題を最速で解く機械語は存在するので
あと疑うべきは入出力のオーバーヘッドだけになる

メインのアルゴリズムやらロジックやらが同じなら
遅くしている要因は入出力だ

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

>>232
しかし、SNSを見てると、好きな言語にRustを書いている人は、他の好きな言語と
して、JSやGo、Kotlinなどを挙げる傾向が強く、C++は全く書かれてない
ことが多い。

**デフォルトの名無しさん** · 2023/05/08(月) 02:06:52.10

C++のほうが機能が多いので、使える人はC++を使うからだろ

**デフォルトの名無しさん** · 2023/05/08(月) 02:33:43.51

機能の差の比較は難しいが
言語自体で様々な安全保証をするRustの機能が本質的に大きいかな

**デフォルトの名無しさん** · 2023/05/08(月) 02:37:25.24

C/C++の90%のコードが危険というような話は
9割が20年以上前に書かれているだけで
最近のマナーで書けば済む話では

**デフォルトの名無しさん** · 2023/05/08(月) 03:00:18.94

IT大手各社が揃って同じ判断をした
C++では無理なので新たなシステムからRustを採用
そしてRust Foundationを共同で立ち上げた
さらに既存のWindows、Linux、AndroidなどもRustの採用を開始

**デフォルトの名無しさん** · 2023/05/08(月) 03:33:40.76

そんなこと言ったらJavaの採用も開始してるしC/C++なんか大昔から採用を開始してるだろ

**デフォルトの名無しさん** · 2023/05/08(月) 03:48:41.01

非GC言語として絶対的な王道を確立したC++が存在するにも関わらず、
新たな部分からC++ではなくRustを採用し始めたことに重い意味があるのでしょう。
しかも競合ライバル同士が同じ判断をした点も非常に重い意味があるのでしょう。
そのため正しい判断をした可能性が極めて高いでしょう。

**デフォルトの名無しさん** · 2023/05/08(月) 04:02:39.80

C++は死ぬべきだけど、後釜がRustでいいかはわからんわ
コストかけて置き換えるなら最高の言語がいいしな

**デフォルトの名無しさん** · 2023/05/08(月) 04:21:48.93

Rustの書きやすさは気に入ったね
次の言語はコンパイラが様々な保証をする点を押さえた上で、Rustが取り込めないような別の新たな画期的な機能を持たないといけない
他に芽が現状ないからこのままRustで進みそう

**デフォルトの名無しさん** · 2023/05/08(月) 04:29:17.13

この流れなら言える

cpp2を知らなかったなんて言えない

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

実際のところ、将来的に最適化はAIがやるようになって、要件定義と検証だけ人間がやるようになるんだろ。
設計自動化の流れだわな。

そうなってくると実装を人間がやる状況は限定されて、言語もIDLみたいになってくるかと。土方コーダーは全滅だな。
まぁ、c++はCOBOLみたいに過去資産メンテに、Rustはpostscriptみたいにバックエンドで生き残る可能性はあるけど。

**デフォルトの名無しさん** · 2023/05/08(月) 09:34:04.39

>>244
AIにとっても機械語を直接吐くのは保守性が悪すぎる
一方で少なくとも当面は人間が検証できる既存のプログラミング言語になりそう
万が一の時の対応や問題把握のためにも既存の言語が良さそう
インフラは人間がある程度把握し続けないとAIに主導権を奪われかねない点でも同じ
使われる言語は自動的に色々と保証されるRustになるのかな

**デフォルトの名無しさん** · 2023/05/08(月) 10:33:58.34

人命や経済損失に大きく関わるシステムは責任や論理的な信頼性の観点からAIに頼るのは無理そうだね。

**デフォルトの名無しさん** · 2023/05/08(月) 10:45:11.11

AIはTDD（人間がテストコード書いてAIが実装コード書く）と相性いいかなって思ったけど
絶妙にテストケースだけパスするようなコード吐いてきそうで怖い
人間的な一般化パターンを学習すれば使えそうだけど現状だとコピペミキサーでしょ

**デフォルトの名無しさん** · 2023/05/08(月) 11:29:16.24

AIがどうとか関係無いはずなんだが
Rustのここがダメ！みたいなことを書くと必死でレスしてくれる人がいるから無限に話を脱線させることができるんだね

**デフォルトの名無しさん** · 2023/05/08(月) 11:46:17.60

.gitignore に Cargo.lock を入れてるのに
cargo publish すると Cargo.lock もうｐされる
github の方にはもちろんうｐされていない
cargo publish --allow-dirty は本気で要らないものまでうｐされるからこれはやってないのだが

**デフォルトの名無しさん** · 2023/05/08(月) 12:11:03.58

AIに書いてもらうプログラミング言語はC++かRustになるんだろうが、
C++でプログラムの本質でない部分の隙を残すよりも、
コンパイルが通れば静的にその部分が自動検証されるRustになるんだろうな

**デフォルトの名無しさん** · 2023/05/08(月) 12:16:11.80

>>174
すばらC洞察

**デフォルトの名無しさん** · 2023/05/08(月) 12:31:11.67

>>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ

**デフォルトの名無しさん** · 2023/05/08(月) 12:43:44.96

>>201
これは良いサンプル
https://www.youtube.com/watch?v=U-_43dmdV_I

**デフォルトの名無しさん** · 2023/05/08(月) 12:43:46.40

>>249
内部で呼ばれるcargo packageの仕様っぽいね
https://doc.rust-lang.org/cargo/commands/cargo-package.html
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな

**デフォルトの名無しさん** · 2023/05/08(月) 12:48:52.30

>>228
全ての素数の積でπを造る公式あるな

**デフォルトの名無しさん** · 2023/05/08(月) 12:50:45.02

>>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き

**デフォルトの名無しさん** · 2023/05/08(月) 12:56:17.27

Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？

**デフォルトの名無しさん** · 2023/05/08(月) 12:57:11.50

thx!

**デフォルトの名無しさん** · 2023/05/08(月) 13:48:29.03

今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。

**デフォルトの名無しさん** · 2023/05/08(月) 14:22:47.81

>>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね

**デフォルトの名無しさん** · 2023/05/08(月) 15:04:56.15

>>245
AIにRustのコード吐かせる理由なんて無いよね

**デフォルトの名無しさん** · 2023/05/08(月) 15:39:48.45

Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので

**デフォルトの名無しさん** · 2023/05/08(月) 15:42:47.04

速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。

**デフォルトの名無しさん** · 2023/05/08(月) 16:19:16.98

>>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな

**デフォルトの名無しさん** · 2023/05/08(月) 16:35:56.27

>>263
llvmの方がgccより性能良くなった?

**デフォルトの名無しさん** · 2023/05/08(月) 16:41:27.47

>>265
12年前から既にclangの方が速いです:
https://stackoverflow.com/questions/3187414/clang-vs-gcc-which-produces-faster-binaries

**デフォルトの名無しさん** · 2023/05/08(月) 17:24:13.85

>>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し

機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい

**デフォルトの名無しさん** · 2023/05/08(月) 18:43:10.50

>>266
その手の話は信用ならねえな

**デフォルトの名無しさん** · 2023/05/08(月) 20:09:42.31

>>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？

**デフォルトの名無しさん** · 2023/05/08(月) 22:23:28.00

>>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない

ちなウォーターフォールね

**デフォルトの名無しさん** · 2023/05/08(月) 22:48:34.95

そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない

**デフォルトの名無しさん** · 2023/05/09(火) 02:35:37.18

公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ

**デフォルトの名無しさん** · 2023/05/09(火) 02:55:17.89

yank

**デフォルトの名無しさん** · 2023/05/09(火) 03:40:24.06

>>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。

**デフォルトの名無しさん** · 2023/05/09(火) 06:12:08.21

そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな

**デフォルトの名無しさん** · 2023/05/09(火) 07:51:20.97

yankしても消えないやん？

**デフォルトの名無しさん** · 2023/05/09(火) 08:28:08.83

いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ

**デフォルトの名無しさん** · 2023/05/09(火) 09:22:12.89

プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ

**デフォルトの名無しさん** · 2023/05/09(火) 10:03:50.18

vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち

**デフォルトの名無しさん** · 2023/05/09(火) 10:17:59.79

とフィボナッチイテレータより高度なプログラムが書けない人が申しております

**デフォルトの名無しさん** · 2023/05/09(火) 10:29:01.80

>>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ

**デフォルトの名無しさん** · 2023/05/09(火) 11:12:55.99

>vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt

>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt

>まあClone回避パターンもありRustは完璧だ
doubt

よくこんな短文で嘘ばかりかけるな

**デフォルトの名無しさん** · 2023/05/09(火) 11:27:29.07

複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい

**デフォルトの名無しさん** · 2023/05/09(火) 11:41:48.76

オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん

**デフォルトの名無しさん** · 2023/05/09(火) 12:08:20.62

オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ

**デフォルトの名無しさん** · 2023/05/09(火) 12:19:41.76

な、単発だろ

**デフォルトの名無しさん** · 2023/05/09(火) 12:27:45.30

プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい

**デフォルトの名無しさん** · 2023/05/09(火) 13:50:33.38

>>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。

**デフォルトの名無しさん** · 2023/05/09(火) 14:18:30.40

>>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利

**デフォルトの名無しさん** · 2023/05/09(火) 14:27:49.18

>>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。

**デフォルトの名無しさん** · 2023/05/09(火) 14:49:54.81

>>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る

**デフォルトの名無しさん** · 2023/05/09(火) 15:08:56.17

https://stackoverflow.com/questions/57259126/why-does-the-rust-compiler-not-optimize-code-assuming-that-two-mutable-reference

だいたいそんな感じなんだけど実際にはバグったせいで付けたり外したりしてしてます

**デフォルトの名無しさん** · 2023/05/09(火) 15:10:24.05

>>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。

**デフォルトの名無しさん** · 2023/05/09(火) 15:21:42.16

>>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね

**デフォルトの名無しさん** · 2023/05/09(火) 16:23:47.59

重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです

**デフォルトの名無しさん** · 2023/05/09(火) 16:57:31.86

>>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる

Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い

**デフォルトの名無しさん** · 2023/05/09(火) 17:04:50.38

コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな

**デフォルトの名無しさん** · 2023/05/09(火) 17:08:17.41

>>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする

**デフォルトの名無しさん** · 2023/05/09(火) 17:09:31.38

そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です

**デフォルトの名無しさん** · 2023/05/09(火) 17:30:52.58

Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど

**デフォルトの名無しさん** · 2023/05/09(火) 17:33:18.67

おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな

**デフォルトの名無しさん** · 2023/05/09(火) 17:35:11.58

普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ

**デフォルトの名無しさん** · 2023/05/09(火) 17:49:39.63

速度じゃないわな
実行時間だ
速度だと
c > c++ > rust

**デフォルトの名無しさん** · 2023/05/09(火) 21:13:21.70

>>300
Rustは適当に書いたらコンパイル通らない。

**デフォルトの名無しさん** · 2023/05/09(火) 21:36:53.43

いうて、C++でinline、constexprやらテンプレートメタとかで実行時の処理効率を上げまくったらRustじゃ敵わないと思うんだけど、、
Rustでも似たようなこと出来るんだっけ？

**デフォルトの名無しさん** · 2023/05/09(火) 21:55:51.60

>>305
できるよw

**デフォルトの名無しさん** · 2023/05/09(火) 22:07:22.50

>>305
Rustもできるよ
そもそもRustのconstはコンパイル時定数でC++のconstexprのこと
Rustの手続きマクロはRustコードの構文解析を入出力としてコンパイル時に実行生成するためC++より強力だね

**デフォルトの名無しさん** · 2023/05/09(火) 22:10:15.60

なるほどね
俺の全力のC++コードじゃRustには敵わないようだ

**デフォルトの名無しさん** · 2023/05/09(火) 23:53:36.96

>>299
>>301
noalias指定で劇的に速くなる例はC言語でrestrict修飾の有無の解説ページが多数あって詳しい
restrict指定がないとnoalias最適化ができずにベクタ化されずに遅くなる例なども出ている

**デフォルトの名無しさん** · 2023/05/10(水) 07:24:49.96

テキトーに書いてもコンパイルが通る言語に憧れるなあ

**デフォルトの名無しさん** · 2023/05/10(水) 08:38:28.50

体感ではこうかな
c > rust > c++

**デフォルトの名無しさん** · 2023/05/10(水) 08:59:49.54

複雑なことを好き勝手に書けるのがC++だったけど、簡潔に書くことも求められるようになりそうだねえ

当初は複雑だったけど、やることが大体固まったものをrewriteするなら、
いまなら確かにrustがアツい成果も目に見えると思うたぶんCでは力不足だしね

**デフォルトの名無しさん** · 2023/05/10(水) 10:30:02.81

>>308
全力のrustコードを書けばいい

**デフォルトの名無しさん** · 2023/05/10(水) 12:47:47.75

C++相談室part161、ﾜｯﾁｮｲ導入直前のスレ
https://mevius.5ch.net/test/read.cgi/tech/1653135809/343-381
https://mevius.5ch.net/test/read.cgi/tech/1653135809/481-650

C++相談室part162、ﾜｯﾁｮｲ導入直後
https://mevius.5ch.net/test/read.cgi/tech/1667194175/
"Rust" の検索結果: 1件

は～

**デフォルトの名無しさん** · 2023/05/10(水) 12:48:26.46

lintだけでもいいから、smart c++とか名前を付けてRustもどきの強制フォーマットを作って欲しいわ。
Rustそのものは要らん。

**デフォルトの名無しさん** · 2023/05/10(水) 12:49:05.61

Rust本スレもﾜｯﾁｮｲ無しのほうやめちまえばいいのにな
C++相談室はすんなり移行できてて羨ましい

**デフォルトの名無しさん** · 2023/05/10(水) 13:11:50.30

>>310
それならば静的型付けではない言語を選ぼう
ここは静的型付けのC++とRustのスレだからコンパイル時に可能な限りエラーを出す言語

>>315
その方向を求めるならばRustの方が優れているからC++にこだわる必要ないんじゃないかな
生産性の高いRustを使った方がメリット享受もたくさん

**デフォルトの名無しさん** · 2023/05/10(水) 13:15:44.86

crates.io にうｐして docs.rs の comment cover が
中々 100% に到達しないんだが
どこの comment が足りないって簡単に教えてくれるツールは？
local で docker 使えば判るもんなの？
あと「未 comment」数を減らした(=100%に近付けた)はずなのに
逆に%下がるケースもあるみたいで良く判らん

**デフォルトの名無しさん** · 2023/05/10(水) 14:03:23.86

lintにmissing_docs
https://doc.rust-lang.org/rustdoc/lints.html#missing_docs
があるけどデフォルトでallowになってるらしい

lib.rs（main.rs）に
#![warn(missing_docs)]
を足すかコマンドで↓を実行
cargo rustc -- -W missing-docs

**デフォルトの名無しさん** · 2023/05/10(水) 14:21:07.26

>>316
注意喚起テンプレとこの隔離スレが効いてるから本スレも平和

**デフォルトの名無しさん** · 2023/05/10(水) 16:48:54.33

>>319
㌧クス
しかし足りない数(あと5ヶ所のはず)よりはるかに多い warning が出て来たでござる

**デフォルトの名無しさん** · 2023/05/10(水) 17:11:01.06

>>319
5ヶ所治して残りの warning 放置で 100% 達成出来ました！
ほんとうにありがとうございました！！！

**デフォルトの名無しさん** · 2023/05/10(水) 17:13:13.74

コメントカバー率の計算対象は限定されてるよ
https://doc.rust-lang.org/rustdoc/unstable-features.html#--show-coverage-calculate-the-percentage-of-items-with-documentation

**デフォルトの名無しさん** · 2023/05/11(木) 03:47:03.48

C++だとdoxygenなど使うところが
Rustだと公式サポートされて色々と進んでいるのね

**デフォルトの名無しさん** · 2023/05/11(木) 08:01:31.45

https://twitter.com/markrussinovich/status/1656416376125538304

If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel!
https://pbs.twimg.com/media/FvzF4ZraQAUumaq.png
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2023/05/11(木) 11:43:59.84

win32kbase_rs.sys
win32kfull_rs.sys
って何?
ついでに名前が似た以下のファイルも
win32kbase.sys
win32kfull.sys

**デフォルトの名無しさん** · 2023/05/11(木) 12:35:35.38

ttps://japan.zdnet.com/article/35198420/