Rust part36

公式
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 part35
https://mevius.5ch.io/test/read.cgi/tech/1774514307/

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

>>686
何言ってんだこいつ

>>687
別にLLVMは C / C++ の抽象計算機のモデルには依存してないぞ
LLVM IRはCやC++とは別物

>>689
RustもバックエンドにLLVMを使わないツールチェーンは開発されてるし、C / C++ はGCCやMSVCなどLLVMに依存しないコンパイラが最初から多いしで、別に珍しい話でもない

>>690
というか、適材適所やね
LLVMはコンパイルが遅いが最適化が優秀、でも開発中は最適化はイマイチだがコンパイルが速いという方がうれしいこともある

🥴

🌚

makefile書く方が楽
CMakeListsは自由度高すぎ、設定多すぎて逆に覚えにくい
コンパイルオプションそんな色々いじらんて

cargoでいいじゃん

>>692
ZigもOdinもCと比べれば格段に良いけど
色んな安全性の保証がプログラマ頼みな点で中途半端な立ち位置のまま
Rustさえいなければ～！状態

中途半端だといっそCで良くない？ってなるんだよな。コンパイラとかも組み込み含め揃ってるし。
今時バイブコーディングでコンパイラもライブラリも整備できるとはいえ、タダじゃないんだから

Rustは次世代標準
簡単な話だ

っぱモズィラ・ファウンデーション製のラストよ

>>698
> コンパイルオプションそんな色々いじらんて
それらを CMakePresets.json や CMakeUserPresets.json に書いておいて使いまわすのですよ
基本 CMakeLists.txt にはプロジェクト名とソースファイル名、依存パッケージ関連しか書かない

>>702
数十年後にはISO標準化されているかな

足を引っ張るそういうのは要らん
コンパイラ乱立も不要

リストラされまくりエンジニアたちに新規開拓する余地が生まれるのがRust

>>707
流石に釣り針デカすぎｗ

>>701
それはそう
既存資産もあるしな

>>704
だったら読みやすく保守しやすいMakefileの方がよくないか

>>692
Odin のリリースは日付で書いてあるからバージョンナンバーがわかんねぇ

>>709
cmake はクロスプラットフォーム、クロス IDE のためのメタビルドツール

しかも CMakeLists.txt と CMake(User)Presets.json をプロジェクトフォルダにおいておけば
VS なら勝手に cmake プロジェクトと認識するから VS 固有のソリューション/プロジェクトを生成する必要もない

Presetsで定義したビルドプリセット(通常は debug/release など)をプルダウンから切り替えるだけで自動的に cmake の configure が走って find_package に従って依存関係を debug/release でビルドしてくれる (しかも vcpkg がバイナリキャッシュしてるので2度目や他のプロジェクトで同一オプションでビルドしてあればそれが使われる)

同等の事をやったら「読みやすく保守しやすいMakefile」ではなくなるのでは?
(少なくともcmakeで生成したmakefileは読む気にならない)

cmake が発明されたのは autotools の屋上屋っぷりへの反省からだと思うのでメタにメタを重ねるような cmake のプリセットをあまり好意的には見れない。
必要な場面もあるとは思うけどどんなプロジェクトでも採用すべきというほどの標準という気はしない。

###結論
​ビルドシステムの進化は「開発プロセスの効率化」には貢献していますが、「安全なプログラムの作成」という目的において、C言語という言語仕様そのものが抱える負債（欠陥）を解消するものではありません。
​Rustなどのモダンな言語が「なぜあそこまでビルドシステム（Cargo）と型システムを密結合させているのか」を考えると、**「ビルドシステムだけで安全を担保するのは不可能であり、言語そのものが安全でなければならない」**という現代の結論が浮き彫りになります。
​「Cの欠陥から目を逸らすための複雑化」に対して、どれだけ冷静でいられるかが、エンジニアとしての力量を分ける分岐点かもしれませんね。

Rustは最初からごちゃごちゃと複雑化しているので安心

Rustは完成型
認められない奴らは老いぼれか障害者

じゃRustのコア開発者は全員老いぼれか障害者だな

今まで避けてた人はmodern cmakeから始められるのがラッキーだと思うけどなあ
この期に及んで必要性が分からないと言ってる人がいたら、あっ、となる

>>717
https://xkcd.com/927/

bacon→Makefile（スクリプトとか挟む）→cargo xtask（出来るだけシンプルに）

今のところのお気に入り

>>711
ホームページビルダーで生成したHTMLは読みにくいから、HTMLはシンプルでも読みやすくもない、みたいな話をされても困る
当たり前だが、CMakeを使わなくてもMakefileできれいに書けるケースも多いという話をしている以上、CMakeが生成するMakefileの話はしていない

>>712
あくまで複雑なプロジェクトを何とか扱うための仕組みであって、シンプルなプロジェクトで使う意味はないんだよな

>>713
Rustの言語仕様はビルドシステムと関係ないし、C言語も同じく関係はない
君はそこを切り分けていないので会話が成立していない

>>714
Rustの考え方を知らずに記法だけ丸暗記しようとするとそう感じるかもしれないが、実際はそんなことはなく、シンプルに作られている

>>715
当然ながらそんなわけはないし、Rustは安定して開発が高コストという重大な欠点がある

>>717
モダンになったら必要だ、なんて話にはならないし、前よりよくなったことと、必要になることとは別問題
お前は前よりおいしくなったと言われたらうんこ味のカレーを買うのか？

基本的にCのプロジェクトならよほど大きくない限りMakefileやバッチファイルで管理は事足りるし、C++くらい複雑になればCMakeも必要になることは増えてくるというだけのこと
Rustの場合Cargoがその役割を担えるし、扱い方もシンプルなのでわかりやすいが別にCargoほど大仰なものは必要ない、小さなプロジェクトもたくさんあるだろう

地雷の見える化システム

その上で、C++のエコシステムの複雑さと低レベル（抽象化が提供されていないという意味）さの結果として、CMakeは複雑になっていて、多少マシになったとはいえ多くのCのプロジェクトでは不必要なほど面倒が多いのは変わっていないというだけの話

>>725
そういう意味ではrustcは優秀
でもビルドシステムはあまり関係ない

>>725
ふーむ...🤔

「ある種」の可視化ツール
cargoと違って強制力はなくて半分は協調性だからね

cargoの強制力ってなんやねん

Rustは様々な言語機能が滑らかに噛み合っていて美しい

Rust のプロジェクトで他の言語を混ぜたりするような事情もないならあえて Cargo 以外のビルドツールを使う選択はとり難い。
ある程度の人数が関わるプロジェクトで Cargo を避けるならよっぽどの理由がないと納得させられない。
強制力というか Cargo を使うべきという圧力はあると思うよ。

>>732
Cargo避ける、って実質的に無理では?
依存外部crateを再帰的に全部ローカルcrateにするって事？

makefile爺さんはC/C++依存ライブラリは予めシステムグローバルにインストールかgit submoduleにしてください、と言うスタンスだろうか

料理で調理器具使いませんと言ってるようなもん

キッチンなんて複雑で重厚長大だよな

>>733
>>730 に対する反応なので強制力とは何のことを言っているのかを説明してるだけだよ。
まさにあなたがそう考えるように Cargo は実質的に強制されてる。

Cargo=Rustだとわからん障害者はCでも使えばええんや

強制って言うと悪だと捉えられがちだが
Cargoみたいな役割のところが乱立したところで別にいいことないしな

CARGO_HOME で ls -l すると
全てシンボリックリンクリンク

cargo -> rustup
cargo-clippy -> rustup
cargo-fmt -> rustup
cargo-miri -> rustup
clippy-driver -> rustup
rls -> rustup
rust-analyzer -> rustup
rust-gdb -> rustup
rust-gdbgui -> rustup
rust-lldb -> rustup
rustc -> rustup
rustdoc -> rustup
rustfmt -> rustup
rustup

つまりcargoなど公式ツールは全て同じ実体
rustupもコンパイラrustcもcargoと同一だとわかる

busyboxみたいにマルチコールバイナリになってるのか

makefile cmakeとか乱立してる時点でうんこなのね

>>740
マルチコールっていうかプロキシだね
実体は当然別にある

>>742
なるほどなあ、賢いやり方やね

>>737
実はRustでも直にrustcを呼ぶことはできるんやで

>>741
そもそもどれも言語仕様と結びついていないというだけの話
好きなの使えばいいのにCMakeじゃないとダメだと思いすぎなのがいけない

>>739
>つまりcargoなど公式ツールは全て同じ実体
>rustupもコンパイラrustcもcargoと同一だとわかる
ネタとして言ってるんだろうがこういうの真に受けちゃうやつもいるからな

cmakeにしても数あるコンフィグツールの一種でしかないから持ち上げるな
プロジェクトごとに採用の是非は決めればいいし、おすすめでも何でもない
なくても困らん

ほんそれ

>>742
実体は別に存在しない
Rustコンパイラrustcとcargoはもちろん同一バイナリ

どっちでも良いならcmakeにするのが今現在の協調性
Qiita/ZennでC/C++プロジェクトのgithubレポを公開してる人が
cmake一つも使ってなくて全部makefileだと協調性ゼロだと思われる

まあ昔からVisualStudio用のsolution形式だけで公開されたら利用できる環境が限定されて困ったことある
makefile限定公開も今やその扱い

>>750-751
Cのプロジェクト見たことないのはわかった

Makefileは普通に使われてるしshさえあれば動くから今でもしっかり標準だぞ

本日の地雷を検知しましたw

なんか頭悪そうなのが湧いてるな

ngだらけで草ｗｗ

NG宣言とか古典的なことやってんねｗ

>>725
ふーむ...🤔

.rustup/toolchains/stable-x86_64-pc-windows-msvc/bin で ls するとcargoがデカい
30M cargo.exe*
1.2M cargo-clippy.exe*
1.2M cargo-fmt.exe*
14M clippy-driver.exe*
108K rustc.exe*
12M rustdoc.exe*
4.6M rustfmt.exe*

rustc_driver-4aa755545f2784f5.dll が 192M あるな

>>746
rustcはcargoは同一の単体実行バイナリになっている
だからcargoからrustcの呼び出しも内部呼び出しのみで高速

>>760
rustc.exeはrustc_driver-***.dllをimportしてるけど
cargo.exeはimportしてないね
名前から想像はつくけど一応調べた

https://lp.jetbrains.com/the-state-of-c-2025/
56% CMake
37% Makefiles
29% Visual Studio projects
12% Ninja
05% Xcode projects
04% Meson
04% Custom build system

https://lp.jetbrains.com/the-state-of-cpp-2025/
59% CMake
34% Visual Studio projects
27% Makefiles
15% Ninja
09% Xcode projects
08% Gradle
04% qmake

>>639
安定化いいね
isolate_highest_one
isolate_lowest_one
highest_one
lowest_one
bit_width

>>761
ちゃんと挙動調べてから言おうぜ

>>763
そりゃそうだろうなという感じ
JetBrains IDEを使う比較的大きなプロジェクトを扱うエンジニアが多めのアンケートにもかかわらず、MakefileはC言語で40%近く使われている
小さなプロジェクトも入れればもっと増えるだろう

また、C++の複雑さはCより高度なビルドシステムを必要とする傾向があるというのも数字からわかる
MakefileはC++においても利用はされるものの、Cのようにこれで十分とは言えない中途半端な立ち位置に収まっている

なので、やはりよほど複雑でなければまずCのプロジェクトならMakefileを検討してよいし、CMakeでないとオワコンだなんてのはCMake書ける自慢したい奴が言ってるだけという話ではある

これはもっとハッキリ出てるね

https://isocpp.org/files/papers/CppDevSurvey-2026-summary.pdf
CMake 81.9%
Ninja 46.2%
MSBuild 33.5%
Make/nmake 30.7%
Custom / in-house system 14.4%
distcc/ccache 11.1%
Autotools 7.4%
Bazel 6.4%
Meson 6.4%
QMake 6.4%
Gradle 6%
Xcode projects 5.4%
xmake 4.3%
other 3.6%
Maven 3.3%
UnrealBuildTool (UBT) 3%

墓場😨

>>768
CMakeとNinjaは重複も多いだろうし、Makefileの値はあまり変わってないから、やっぱり3割くらいはC++でもMakefileを使ったことがあるんやな
とはいえCよりはやはり少なそうだ

C叩きをしたせいでRustスレが関係ない話題で埋め尽くされましたね😊

C老害ジジイ

煽ってスレを潰す簡単なお仕事

そりゃ煽り潰される覚悟のない奴はなあ

まぁ　今や質問はAIで済むから、このスレを消化するにはそれしかない。
秋葉原コンカフェの話題でもやってくれれば、まだ価値がある。

>>771
老害😇

秋葉原でRustカフェを！？

>>772
>>776
頭悪そう

The Book読んでないレベルの奴がRust語るからおかしくなってるところもある
RustがCと違うのはどこか、書いてないからよくわかってない、そういう人が多い

本日の地雷を検知しましたw

botかな

>>780
正論言われて気に入らなかったんでちゅね、かわいそｗ

>>779
Cみたいなゴミ言語と比較しても意味ないだろ

＞ Rustが影響を受けた言語
＞ Alef、C++、C Sharp、Cyclone、Erlang、Haskell、Limbo、Newsqueak、OCaml、Ruby、Scheme、Standard ML、Swift

Cは負債😨

>>783
C++について知らないんですかねｗ
あれはCのスーパーセットなんですけど

>>784
これしか言えないバカいるけど話の邪魔だから消えてほしい

そもそも Rust がなぜ安全な C / C++ 代替になり得ると言われているのか、そこに Rust の一番の特徴がある

そりゃ負債を解消するからだよw

つかCは欠陥言語なんだが

>>787
しない。
C言語で作られた資産は勝手にRustになることはない

>>788
どこが欠陥か言えないのに「欠陥言語！」って言うだけで賢くなったように感じる、結構な言語ドラッグだなｗ

Rustエアプあるある

* 「Rustはメモリ管理が自動！意識しなくても参照が使える！」などと言い出す
実際にはRustはコードの構造の段階でメモリ管理を意識していないとコンパイルが通らないし、借用（Rustの参照をこう呼ぶのは、所有権をベースにメモリ管理を行うためである）は鬼門となる

* unsafeブロックを「雑に書いたからたぶんクラッシュするで〜ｗｗ」だと思っている
実際はコンパイラが安全性を検証できないケース（外部とのやり取りである、コンパイラの想定にないデータ構造であるなど）を開発者が「ここは私が責任を持つから、コンパイラは黙っていてくれ」と宣言するのがunsafeブロックである

* 「メモリ安全」を「バグが出ない」だと思っている
実際はバッファオーバーフローやダングリングポインタなどの、RAMアクセス時に発生するバグや脆弱性から保護されている状態のことを言うのであって、ロジックのバグなどメモリに関連しないものは普通に発生する

たぶん>>787は1つ目か3つ目のタイプのエアプやな

Bytecode AllianceのZulipに面白そうなの来てた

NASAのSpaceWasm
github.com/nasa/spacewasm

宇宙船上でWasmバイナリを解釈・実行することを目的とした、Wasm 1.0仕様のインタープリタ

白家が使うなと言ってるから