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/

今でも基本的な資料が C をベースに説明されていることはあるので文法の詳細までは不要にしても C を全く知らないでいるというのが難しいことはあるよ。

Cがあるのは怠慢でしかない

BunがZigからRustに、わずか11日のバイブコーディングで完全移植されたけど
これって結局実験のための使い捨てじゃなくて、Zig版は放棄してRust版で開発していくんだな

どうして最初からRustで作れなかったんだろう…

>>656
JavaScriptCore を中核にする前提だからというのが大きいらしい。
Bun 側のメモリ管理は JavaScriptCore 側と協調して性能が出るようにチューニングしたいという動機があって底レイヤのメモリ管理の細部をいじりやすいものを選んだら Zig になった。

でもそんな細部を手作業でいじってたら問題も起こるわな。
Bun がいきづまっていたのは Zig の問題ではなく Bun の設計方針が品質管理しづらい形だったってことだ。
方針を変えないなら Rust に変えたからと言ってそんなに良くならないと思うし、細部の制御を諦めるなら Zig でも十分なコード品質になったと思う。

じゃあAIとRustは相性バツ牛ﾝってことで

AI禁止？😨
ヒエッ😨
ガチガイジやんけ😨

>>649
>>654
まあ、コンピュータの知識や既存資産の知識がなければそうだろうね

知識がない状態でいくら言っても「ああ、こいつ何もわからんのか」と思われるだけだけどｗ

>>651
PC向けならね

>>652
Cをアセンブリ言語に近いものと見ると足をすくわれる
Cには抽象という概念がある

マイコン用と教材用言語としては最適というのは同意

>>653
それはホントにそうで、Cを理解せずにはRustを理解するのも難しかったりする

>>657
そもそもBunはシンプルに品質管理がダメすぎるんだよな
もともと不具合をものすごい量出していたし、Rustへの書き換えもやっぱり雑にやって問題を起こしてたし

yt-dlpは利用するJavaScriptランタイムのサポートにあたって
BunがAnthropicにJoinしたことで、開発がClaudeによるバイブコーディング100%になるってんで
今後の品質向上に期待できないと切り捨てて、denoメインに切り替えてたな

Denoメインなのは元からやぞ
あと、それ以前から期待できる品質があったとは思えん

つまりRustは最高で
他はハナクソってことか😂

ゴミ言語の知識とか持ってるだけで負債や😨

Cとか言い始めたらジジイ

まぁ、基本文法とかどの言語もCベースだし
C学べば他の言語も書きやすいよね

えっ、includeしなくていいの！？
メイン関数にリターンつけなくていいの？

とかはあるけどさ

だからこそRustのfor文は最初ナニコレしてた

Rustを理解できなくて問題山積みのC言語にこだわってるダメなプログラマーもいるよ

cmake書かないでいいってだけで地獄を回避できるしrustでいい

Mesonがあるやん

これでいいんでないの？
https://cabinpkg.com/

>>670
それはCもちゃんと理解できてないからやな
Rustに新しい要素なんか実際ほとんどない

>>667-668
まあCを知らないと新しいとか古いとかだけで語りたくなるかもな

>>671
別にCでも書かなくていいんやで

なぜかCMakeとC言語を区別できない人が多いけど、別物だからね

>>674
C言語も楽しいけど本質的でない部分に多方面に渡って手間暇がかかるから捨てた
今となっては使うメリットが皆無

言語としては C のメリットがゼロだと仮定しても C で作られたものや資料が今の瞬間にただちに消滅して Rust に置き換わるわけではないからな。

Cはシンプルなので初修言語として工学部で大人気

教師「これはおまじないです」

名前空間がないならマクロで識別子合成すればいいじゃない

Cは階層名前空間がないだけでなく
マクロが汚染マクロという欠陥もあって

C(やC++)とcmakeとvcpkgをセットで入門しようとするのは良い心がけかと
一方でcmake書くのが地獄と言ってる向きはpreset以前の昔の話を引きずってるのかも

>>679
ゴミ

>>681
変なマクロ書くから……

>>682
C++ならともかくCだとあんなに複雑で重厚長大なビルドシステムはいらないことが多い

>>676
雑務が多すぎるってのはそう
わかり切ってることはコンパイラにやらせた方がいい
ただ、シェルスクリプトと組み合わせて小さな処理をやらせる程度ならRustを使う方が手間だったりするので、そこは使い方次第でメリットがないわけじゃない

>>677
それ

>>678
C言語というよりC抽象マシンモデルが優秀
世の中のコンピュータの大半の最小公倍数になってて、もっと色々抽象化した方が人には使いやすいんだけど、コンピュータ一般を学ぶならこれ以上ない選択肢になる

Cとかいう欠陥言語😨

LLVM が汎用のコンパイラ基盤といいつつ C/C++ の抽象計算機のモデルに依存してるのは他に参考になるモデルが存在しないからというすごくシンプルな原因がある。

自閉症は長文と起源主張とキムチが多い
つねに後ろ向きなのだ

一方ZigはLLVM依存を解消するのであった

脱LLVMというより下請なんで
新しいものが作られていく

Rsutと比べるならHaskell

Zigをよそ目にOdin-langが1.0になったね

>>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のプロジェクト見たことないのはわかった