Rustアンチスレ

>>156
>マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど

汎用OSで自分の起動したタスクしか動いてないと思ってるわけ?
RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。
そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。
今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、
やっぱりフラグメントは常時発生してる。
てか、メモリデフラグとか動かしたことないのか?

それなんかRustと関係あるんすか？

>>154
まずは基礎知識を勉強しよう
Rustにおいてタスクとは非同期にスケジューリングされるスタックレスなコルーチンのこと
そうでない意味のタスクならばプログラミング言語Rustとは関係ない話

>>155
そのRustプログラム例はBoxを使っているのでスタック上てはなくちゃんとヒープを用いた実験となっている
そんな基本的なことも理解できないならば勉強して出直してきなさい

>>159
それはRustとは全く無関係ない話
基礎的なことを会得していないとそういった無関係な話を持ち出してしまう

>>157
ページサイズより大きい領域の獲得解放を繰り返す想定で良いのかな？
malloc/freeがmmap/munmap呼び出しと一対一対応するような
で、どのOSの実装で問題が起きたの？

ページ単位で割り当てるのにどうやってフラグメンテーション起こすんだろう

じゃあなんでLinuxやBSD、Windowsはメモリコンパクション機能を実装してるの？

>>164 LinuxやBSD、Windowsはメモリコンパクション機能を実装してるの？

なんで、mallocの話がOSの話とすり替わってたの？

>>140あたりでもう一緒くたにされてるからしょうがない
たぶん誰も問題意識を共有できてない

たぶんmallocとOSが密に関連するようなRTOS?が前提なんだと思うよ
>>140は業務で触ってるとかで特性をよく知っているがそのコンテキストが他の人と共有できていないのだろう

ずっと暴れている>>140だけが『所有権』と『OS』を同時に登場させていて二つの別レイヤのメモリ管理の話を区別できていない
ここはRustアンチスレなのにプログラミング言語Rustとは無関係な話で暴れていている

便乗すんな複おじ

まあ所有権の話は唐突でよく分かんないけど彼の中では理屈的に繋がりがあるのではないのかな
もうちょっと丁寧に書いてくれれば分かりそうな気もするんだけど

あーうぜー
1.61.0ビルドしてるけどなんだかいろいろとボコボコDLしてくる()
1.61.0なのに 1.60.0-xxx をDLしてくるし()

あーうぜー

いつのまにかpython module のビルドに入り込んでるのな

悪質

腐れ言語

早く外せよ

なんか第二Javaという感じの臭いがする
非人間的な設計で人間を不幸にしていく悪しき文明というか

確かに奴隷言語っぽいね

linus はこれがいいみたいだけどな()

git も Rust もゴミ

meson のビルドで、

× Preparing metadata (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [64 lines of output]

こんなエラーが出た

すげーイラっとくる


> .toml

クズ言語

>>177
重要な部分はRustで作らないと思うよ

なんでこれ、こんなにコンパイル遅いの？

>>177
俺もgitもgithubも使いにくいと思っていた。

git自体は悪いと思わんが、なんかgit奉行が色々言い出すのがうざいわ。
rustもそういう匂いがぷんぷんする。

どのバージョン管理ソフトが良いの？

>>183
名前は変わったと思うが、MS製のVisual Source Safeなんかは直感的で便利
だったな。特に何も学ばなくても普通に使えた。

cargo check error: failed to run custom build command for `glib-sys v0.17.10`

いい加減にしろよカス言語

cargo publish して初めて出るエラー (cargo のあっち側の環境でコンパイルしてる) ってうざいよね

>>185
Cコンパイラかリンカが入ってないんじゃね
そのメッセージの前に何か出ていると思うが

>>186
あっち側ってcrates.ioのこと？
リモート側でビルドなんか走るんだっけ

firefox のビルドもrust が邪魔しまくりだよね()

RustとC++の相性は最悪だが
RustとCはまあまあイケる
いいじゃんいいじゃん

カス言語ではない

C美しい
C++カス
Rustもうちょっとがんがれ

Rust リファクタリングしてるときに
trait 境界が変わって
あれ？ってなることが多いな

>>192
trait境界を満たせなくなるとコンパイラが教えてくれるので安全にリファクタリングできて良いよね

>>0185
お前はディストリ自分で組まないの？
情弱だな(ﾌﾟ

創価

crates.io が死ぬと詰むな・・・

なんなの vendoring とか stable channel とか

意識高そうですね()

Ruby批判だけど
https://qiita.com/scivola/items/17470c52641d3ffa1650
Rustにも同じことが言える

>>198
Rustに該当する話が一つもないのにRustを批判？

信者は信者スレに帰れ

おまいらホントRuby好きだな

遅いのがなあ

test

githubの応答が遅いんだが

知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

無敵で草

理由なんか不要
ゴミはゴミ

安全なんかどうでもいいから早く書かせろよ
国防総省がどうとかAIがどうとかうるさいんだよ

愛は重要だ

Rustには開発者への愛がないんだよ
機械ばっかり見てる

Rust信者はいちいちThe Book読めとか言ってくる
自分では説明しない

俺にわからないことがあいつらにわかるわけないだろｗｗｗ

>>211
そんな専門書読むほどRustに興味ないｗｗ

unsafeとかいうゴミ

偉そうにメモリ安全とか言ってるけどわかってないだろ

どうせ流行ってるから使ってるだけ

流行ってるから使うとか、JKのインスタかよ

専門書を読めばJKでもわかる

>>218 専門書を読めばｗ

そんな勉強熱心なやつはいないｗｗ

rustなんてクソ言語学ぶ価値ない

RustはHaskellと同じ道を辿ってる

コンパイルの遅さが致命的

RAM爆喰いデブrust-analyzer

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

Rustスレのアンチコメントをまとめてくれているのか

RustはAIが無かったらワンチャンあったかもな
ご愁傷様

>>227
信者「いや、AIがあるからこそ！」

Rustは契約プログラミングをサポートしていない

>>229
流石にバカ

>>1
その段階で躓くのはアホすぎる

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

Rustはフールプルーフじゃない

むしろフールプルーフだからコンパイラに止められるんでは

俺の思い通りに動かないRustが悪い

Rustはコンパイルが速くなるように作られてないからコンパイルが遅い
C++はコンパイルが速くなるように作られてるからコンパイルが速い

コンパイル時なんちゃらで今後遅くならんか
ゼロコスト抽象化の代償かな

C++は神
rustはゴミ

>>237
コンパイル時処理はC++が先にいってる

RUSTは美しくない

アンチの頭脳はこの程度

信者ぶちギレで草

Rsut応援隊って一人で何人分の自演してるんだろうな

美しくないのは事実だからｗｗ
信者乙ｗｗｗ

自分の言葉で語れない信者ｗ

信者はウェブまでrustで書くらしいぞｗ

moveとかいうキショすぎ仕様

>>247
お前さっきから古い投稿コピペしてるだろ

>>13
>>15
お前らは何なら書けるんだよｗｗ

どうせpython
しかも境界条件でバグる

Pythonは神だろ

pythonなんて遅くてバグだらけ

Pythonアンチはよそでやれよ

アンチの頭はこの程度

>>246
草
頭悪いんやろな

RustなんてしょせんMLのパクリ

Rustスレまた荒れてて草
Rust信者は協調性ゼロの奴しかいない

電燈がついてたら集まる虫だもんｗ

このスレダメじゃん。読んでると擁護したくなるわ

>>256
Rustは関数型を一部壊してCっぽくしたやつだから

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

>>261
これ無敵すぎて笑う

unsafeがあるからゴミ
厳しいからゴミ
↑これ

Rustがゴミなのはrustcがゴミだから

所詮メモリ管理ができない奴のひがみ

>>265
黙れ

WASMの失敗はRustなんかを入れたこと

もうコレ「お笑い小噺板」でやってても良いのでは？

>>268
それは違う

>>21
自分を天才だと思ってる奴はだいたいバカ

学習難易度は高いけど、ミスをしないと思ってる奴はバカ

使う意味ない

意味ないってことはないだろ

>>268 アンチスレ立てる用の板じゃないでしょ

個人で使う意味はないでしょ

別にC++でいいよね

モダンC++書くならもうRustでいいだろ

C++は慣れてるから……

Rustも慣れたらええやん

うるさい

Rustが嫌いだから嫌いなんじゃなくて、Rust信者が嫌いなんだわ

>>267
golangでいいぞ

Goはいいぞ

C++のコンパイラにguardオプションを付ければいいだけなのよ。
又は後付けのセキュリティチェックを準備すればいい。
もう誰かやってると思う。
大丈夫　また戻ってくるよ。

流石にC++は言語仕様で安全じゃない部分があるからなあ

unsafe使えば一緒だろ

コンパイル通らんかったら意味ない

thread::spawn() すら知らないくせにイキってるバカもこっちで隔離してほしい

BunをClaudeでRustに変換したみたいだけどunsafeだらけらしいなｗ

バカは何使ってもダメってこと

>>288
thread::spawn() を使う奴はRustアンチらしいぜｗ

このスレより意味不明でおもろい

>>141
それならもうRustで書いた方が楽なん笑う

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

草

RUSTは"Resource acquisition is Unforgiven STealing"の略な

リソース取得は息をするようにやってるんですがそれは

信者が怒ってて草

信者イライラ

ｗｗｗ

>>3
これ好き

>>48
C++完全に理解した

C++100%わかってると思ってるのは流石におもろい

RustはC++と比べるとまだマシ

ここまで自演までしてRustを盛り上げようとしなきゃいけない理由って？

民家への飛び込み営業って、営業になりたがるような陽キャでもすぐ精神病むような過酷な仕事だけど
宗教の信者はそれを無報酬で喜んでやるわけじゃん？

複おじ理論「thread::spawn() を使う奴はRustアンチ！」

複オジ理論「不要なスコープを取り除いたらスコープが壊れてるんだ！」

複おじ理論「どんな寿命の参照でも、関数から必ず返せる！」
↓
「スコープで寿命が変わってるから返せないんだ！　こんなのは反例にならない！」

おもろすぎる

信者もアンチもここまでぶっ飛んだことは言わない

Cをやらないと理解できない欠陥言語

Cくらい分かるでしょ？
問題ないな

……と言ってる奴はだいたいわかってないｗ

Cわかってるってイキってる奴はわかってないよな

Rust信者もRustわかってない

Rustって言語仕様は他の言語と比べて大きいの？普通なの？

C++より非常に小さくコンパクトにまとめられている

でもC++でよく使われてる機能はだいたいある
C++には使われていない/使わない方がいい機能が多すぎる

Rustよく分かってないけどclaudeでインターフェイスだけ書いてcargo check満たしたコード書かせるだけでRustは爆速でメモリコスパも良い
スポットで使うつもりがどんどん拡大してるよ

REST APIとDB使うくらいなら簡単そう

>>320
AI時代になって遅い言語を使う意味がなくなったよな
その言語じゃないと不利な特殊環境などを除けばGC言語は全廃でよくなった

goとJavaはいるでしょ
ライブラリの資産が膨大すぎる

それ以前にAIにRustやCで複雑なロジックやメモリ管理を書かせると動かないことはまだ多い
人が書くより時間をかけて繰り返しデバッグして作るよりはGoみたいなGC言語を使った方がいいんだよね

わざわざ開発速度を落とすメリットがないことは多いしな
Rustで最高速・最軽量を徹底しなきゃいけない用途ってアプリケーション開発では少ない

なんか建設的な話題になってて草

ライバルが同じサービスやアプリなどをRustで軽量高速に作ったらライバルに負けてしまう
ライバルがいない間は安心
ライバルが出現する前にRustへ移行が建設的かも

普通のスタートアップはパイソンで十分だと思うよ
ゲームや広告配信処理あたりは速度重要だろうけど

>>328
こうやってメンテナンスできないゴミを作って後で困るんですねｗ

>>327
心配しなくてもそんなコストをかけるメリットがない
数ミリ秒速くても客は気付きもしない
Goで書いてそこそこの速度で動けば十分

それはそう

【悲報】Rust信者、スタックとヒープの区別を free() するかどうかだけだと思っている模様

アホすぎて草

やっぱりこの程度

複オジ、ムーブとコピーの区別がつかない様子

ムーブなんか使わないだろｗｗ

こっちの方が治安よくて笑う

ここはC++のすばらしさを語るスレですか？

別にC++の話そんな続いてないだろ

それな

またRustスレ荒れてて草
わからないのにイキりたがる信者が多いからだね

Rust応援隊って仕事でやってるんだろ

>>322
AI時代にメモリ食って遅い人間向きの言語は不要になってきてる。さすがにCだとAIのトークンコスパが悪いから辞めたけどRustは良い
もう既に3桁はN+1みたいなクソコード書いてるだろうけど書いてはいけないコード、良いコードとルールを足してテストを増やせばコンパイルが遅いだけになった
ある程度開発〜運用できるプログラマが使う前提ならAI×Rust 可読性がどうしても必要ならGo

Rustなんて何に使うんや？
Webでもゲームでも使い物にならんやろ
学生さんが夏休みに楽しく遊ぶのはええけどね

>>343
AIがそもそも何を書いてるのか理解してなさそう

>>344Webとゲームしか思いつかないのが浅はか
大半のプログラムはそのどちらでもない

Webとゲームは学歴不問だったりするからな。Webは特にレベル低い。DDDとかなんじゃそりゃ

ドメイン駆動設計って頭悪すぎる言葉よな
そうじゃないソフトウェアを作るアホがいるのかって感じ

高速省メモリの分野はRustに任せて
我々は妥協してC言語を使おうぜ

Fil-Cプロジェクトは、コンパイラの修正とガベージコレクションを通じてCコードにメモリ安全性の計装を追加するもので、大規模な書き換えなしにレガシーなCコードベースを保護するためのパラダイムシフトの可能性を示している。
Fil-Cは、コンパイル時の計装と並行ガベージコレクタの組み合わせを通じて、空間的安全性（境界外アクセスの防止）と時間的安全性（解放後使用エラーの排除）の両方を提供する。
Fil-Cでコンパイルされたコードのパフォーマンスオーバーヘッド（推定1～4倍のサイクルと追加のメモリ使用量）は、議論の中心的なポイントとなっている。
ガベージコレクションの要件により、Fil-Cは決定論的メモリ管理が極めて重要であるカーネル開発や組み込みシステムには適さない。
このツールは、他の言語から呼び出されるCライブラリでも課題に直面しており、二重のガベージコレクションシナリオが複雑さを生み出す可能性がある。

C言語は高速省メモリの代表例だろ
Rustとの違いは安全性

>>348
それな
用途考えずにソフトウェア開発するとか人手と金の無駄

>>349
Fil-Cを使うことで、C言語は高速省メモリを失う代わりに安全な言語になった。
Fil-Cのメモリ管理は並行ガベージコレクタで動作する。
free() はオブジェクトを「free 状態」にマークするだけで、実際のメモリ回収は GC が行う。
これにより use-after-free が原理的に攻撃に使えなくなる。
検査に違反した操作は全て「Fil-C panic」として捕捉され、プロセスが停止する。
ヒープ/スタックの範囲外アクセス、use-after-free、ポインタと非ポインタの型混同、va_list の誤用、システムコールに渡すバッファの検査など、C のメモリ安全性を脅かすものは一通りカバーされている。

CプログラマはGCなどという気持ち悪いモノを使わない
そんなものに手を出すならRustの方がマシ

C言語の文法もライブラリもそのままだよ
コンパイラをFil-Cへ変更するだけでGC言語としてコンパイルされる
C言語の文法が好きな人にはピッタリだね

高速省メモリを失ったらC言語の意味がないのでは。。。
そんな捻くれた実装なんか乗せずにRustと同じレベルの厳格なコンパイルエラーモードを追加するだけでいいのに

Fil-C実用で使う奴ってバカだよね、Go使った方が同じことができてより安全でより書きやすいんだから
そんな実験的に作られたものを例に出して「だからCは高速省メモリじゃない」というのはただのバカ

>>355
C言語の仕様ではそもそもRustみたいな厳格なコンパイルエラーは検出できない
最近のGCCには標準で -fanalyzer が搭載されてるけど、これをもってしてもRustよりは弱い保護しかできない

実用出来ないでしょ
既存の.so使えなくなる制限が大きすぎる
CIに使えるかな

-fanalyzer(静的解析)と-fsanitize(動的解析)なんてのがあったなんて知りませんでした。
gcc14以上みたいですね。

>>345
自然言語語も理解してなさそう

>>360
自然言語語は草
お前だろｗ

>>352
C言語の美しさは挙動の透明さによるものなわけで、挙動が不透明なGCに全てのオブジェクトを任せて、メモリ消費量を増やし、動作速度を落とし、stop the worldを発生させるFil-CはC言語であるメリットがない

GCがないRustへ書き換えた方がいいね

それどころかGC言語のGoよりも遅くて非効率なケースが多い
いくらなんでもバカすぎる

Goより遅いのは草
ただの道楽やんｗ

アホくさ

Goより遅くてGoより書きにくくてGoより環境依存でGoよりバグりやすくてGoより使えるバイナリのライブラリが少ないのか
……ん？

既存のC言語のソースコードをGCモードで安全に動かすのがFil-Cコンパイラ
Goより遅いのも仕方ない

RustはGoより早いの？

特殊な用途で役にたつかもしれない。?

>>369
早くていけない

>>368
※ただし既存のバイナリは使えない
これが欠点として大きすぎて使う気にならない
それならGoのエコシステムでも十分使い勝手がいいよ

>>369
GCの処理が丸々ないんだから、当然速いわな

>>370
特殊な用途で役立つ数よりも、勘違いしたアホがゴミを量産する数の方が多そう

>>369
そこはGCの有無が効いてる
GC無い方が速い

C使ってて努力してsoの置き換えまでやる人いるかな
ヒマ人検出器として見守る

まあ、GCあるGoより遅いあたりFil-Cは最適化も大したことない

Go向けにした方が100倍よさそう

世のため人のためにFil-CではなくGo対応にしましょう

Goより遅いｗｗ

Rustの代わりにFil-Cは頭わいてる

>>349
>>352
GC付きのいい言語は別にいくらでもある

>>354
バカが「俺もC言語書けるんだぜ」って知識もないのに威張るために使うならアリってことか？

>>349
>>354
移行期技術を新規開発に使っていいと勘違いするバカが湧いてて草

新規開発ならGC不要なRustでしょ

そらそうよ。Cの過去資産が多い場合に考える用だ

Cの既存資産が多くてもGCをつけられて困らない分野となるとGoで書き直す方がよさそう

言語機能が弱くて不便なGoをわざわざ使うことはあるまい

最近はCのアプリ減ってるし、sqlite3みたいなものはCがいいっしょ

>>386
言語機能が弱いとは？
クラス信者かな

イテレータのループ無かったGoさん

ループも自力で書けないのかこいつは

>>389
いつの話してるんだこいつは

>>389
いつの話してるんだこいつは

>>388
信者は信者スレに帰れ

>>387
Fil-CにするくらいならGoでいいだろ
Fil-CじゃダメならRustになるな

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

>>393
いつからここはGoアンチスレになったんだよｗ

>>392
最近までなかったような
ここはアンチスレだから手厳しいぞ

>>394
だからピュアCだって

>>398
ピュアCのままがベストってことは、安全性度外視ってことだがわかってるか？
SQLがホントに安全性度外視でいいと？

>>397
ここはGoアンチスレじゃないぞ

>>389
Cにもない定期

>>399
めちゃくちゃテストあるからいいんじゃね
あと組込みDBなのでMySQL達とは違うよ
Go実装のDBあるしそっち使えばいい

テストで安全性は保証できないよｗ

そんなもの保証しなくていい。手段と目的を入れ違えてないか
20年続いてるプロダクトを切り替えるほどのものじゃない。
やりたいならスクラッチからsqlite.rsを実装せよ

>>404
話をすり替えてるのはお前だよｗ
>>387でCがいいと言い出したからこういう話になってるんだわ

技術的にCがいい理由なんかないんだよな
既存資産ってだけ

新規ならね。20年続いてたらRustはないしFなんとかもない

>>389
Cにもないですよ

>>408
Rustとの比較じゃないの?

>>409
Fil-CよりもGoの方がマシって話だっただろマヌケ

えーと
Rust、C、Go、Fなんとかの順だね
あれ?アンチになってない

Rustはゴミ

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

無敵理論やめろｗ

根拠なくていいんだこの錆

序盤の書き込み見ればわかるけどろくに根拠なんかないぞ

Goより遅いとか書いてるやつってRust使ったこと無いだろ

メモリを逐次バラバラにたくさん確保して使いまくる特殊な分野のベンチマークにおいて、
何も考えずに書いたRustのコードがGoに負けたことがある。
そういう分野での常套手段であるメモリをまとめて確保とまとめて解放をすれば、もちろんいつも通りと同じくRustがGoより速い。

「まとめて確保とまとめて解放」をしなければGoのほうが速いんだなｗ
Goすごくね？

GCを持っている以上は独自のメモリープールもあるだろう
細かく確保するように見えて実はメモリープールから切り出しているから速くなる
ただしメモリープールの追加確保が必要になった場合はスパイク状の負荷が発生する

>>419
メモリをバラバラに取得解放よりも
まとめて解放するGCが勝つレアケースがある

しかし現実にはC/C++/Rustでも
その手のケースではメモリをいわゆるアリーナ管理でまとめて解放している
したがって常にGC言語が負けている

Postgresの構文器用に確保したメモリの一括解放エグいよね

意図的にクソコード書かない限りGoとのパフォーマンス差は圧倒的なのに
GoにはGoの良さがあった。Javaにだってあったわけだけど今はもう時代遅れよな

ライブラリが弱いからまだまだでしょ
GC言語でゆとりちゃんも良い

今日はRsut応援隊がいなくて寂しいな

>>412-421
お前ら日本語読めねえのか
Goより遅いって言われてるのはFil-Cだろ

Rustしか勝たん

今5ちゃんにいる奴なんてTwitterの140字も読めない奴だけだろ

長いと縦読み探すよね🤣

バカには日本語が読めない

Rust製`cp`コマンドがUbuntuのISOビルドを破壊——「メモリ安全」と「動作互換」は別の問題だ
https://techfeed.io/entries/6a4823ee71759f74d1a34afe

読んだがRustの問題ではなかった
方針が書かれてないので不明だが
なんらかの互換性を保ちたいならそのテストを書いてパスさせるべき
言語の問題ではなく要求仕様とそのテストの問題

Rustにあらずは置き換えるべきという魔女裁判的な行為あるいは精神に問題があるのでは

zedがemacs互換モード無くてダメだわ

>>434
それはまあ普通にEmacsでいいじゃない

emacsをRust化するまでオレは認めないぞ

>>436
つ Neomacs

https://github.com/eval-exec/neomacs

Rustが使えないプログラマーは淘汰される

LLMにRustで、と言えば書いてくれちゃうんだよなあ

近頃はまた酷くなったな

個々のパッケージをビルドすると、ビルド毎のディレクトリにボコボコボコボコとゴミをDLし

ビルドし直すごとにまた同じものをDLさせるのが原則的な挙動にされた

悪質すぎる

毎回 cargo clean

trait Drop の仕様変わったんかね

アメリカでソフトを作ってる人の環境はもの凄く豪華な場合が
有ると聞いた。だから、ストレージもCPUパワーもバンバン使う
のだとか。

メモリ64GB、24コアが人権

じゃあCでいいね

何でバレたし

ああ Maybeuninit の中身が変わったんか

Rustは、現場に即した現実的言語、というが、
ビルド時に色々なものを勝手にダウンロードしてストレージを爆食いするのではないか。

それに、人間が明確にダウンロードしてから、あとは
インターネットの接続を OFF にしてクリーン開発する、
という「現実」にも対応できないかもしれない。

昔からある
cargo -offline build

>>450
それでは、根本解決にはならないだろう。
そもそもの設計思想からして違うから。

cargoだと、バージョンの保存、固定、魚拓、の考え方も難しそう。
通常、C/C++言語だと、昔のライブラリ、ヘッダファイルなどを
ローカルに保存しておき、メーカーやプラットフォーマーが
古いライブラリは使ってほしくない、といくら望んでも、
敢えて使い続ける、という事ができるのが C/C++ の
良いところだった。
それが cargo のようなものではできなくなり、すべて
ネットの先にある「誰か」に支配されることになる気がする。

cargoはバージョンの固定ができるため
cargo -offlineでダウンロードすることなく動作します

ライブラリが原則としてソース配布なので、気づかないうちに破壊される危険性がある。

また、同一性チェックをチェックサムやハッシュ値で行う
としても、ソースコードは大きく、しかも、個別ファイルに
分散しているので、チェックサムを求めること自体に時間が
かかる。*.lib だと壊れたらリンク自体が出来なかったり、
または、中のマシン語がおかしくなるので、テスト段階で
ハングアップしたりして気づく可能性が有るが、
ソースが壊れた場合、気づかないかもしれない不安がある。

マシン語になっているライブラリの中にウイルスを仕込むのは、結構大変なのに対し、
*.rs のソースコードの中にウイルスを仕込むのは誰でも出来て
しまう。
その恐ろしさがある。

>>455
RustのcargoはSHA256チェックサムによる改変チェックができるため安心です

>>457
仕組みが複雑する過ぎる。恐らく、今後、
個別アプリ作者のマイペースが取れなくなり、
cargo作者、Rust作者によって
開発が左右されるようになる。

プラットフォーマーによる支配から、左翼による支配に移る
だけ。
個人的には後者の方が怖い。

Rustはソースコードを手動ダウンロードも可能

ライブラリがソースコードで配布というのがまた困る。
その文化は左翼にしか受け入れられない。
Linuxが有料アプリがほとんど作られず、サーバーサイドでしか花開かなかったのも、
AndroidでライブラリlibcのLGPLからbionicのapacheに変えたとたん、
アプリが怒涛の如く出現したことも、全てOSSという
左翼思想が拒絶されていることを表している。
Rustは左翼思想。

オープンソースは左翼だとか言ってる例のダメな人が発狂してるだけかよ

PC98は無いよな。ガラパゴスガラパゴス

PC98とは、PC-9801の事か？

RED hat から 赤帽 のイメージで 赤帽 が共産だと思ってたけどやっぱりそうだった

統失か
お薬飲んでね

>>465
RedHat はなんで食っていけるのかと疑問だったが、イギリス軍が
資金を投入してるらしい。

オープンソースは、エンジニアに対する搾取の仕組み。
エンジニアをただ働きさせ、RedHat みたいな文系の
サポート集団みたいなところが儲ける仕組み。

IBMに買収されたぞ

>>469
また訳の分からんところに。
まさに類は友を呼ぶ。

OSSでも「フリーライダー問題」っていうけど、その言葉は、
むしろ逆に、結果の平等を求めたために、労働意欲を失った
共産主義国家の問題点として使われた言葉らしい。
OSSは、共産主義みたいなことをするから、自分で自分で
フリーライダー問題を作り出しているのだ。

先生！じゃあRustは終わりってことですね！！

マイナ破綻ωωω
Rustにしとけば良かったのにωωωωωωωω
https://asahi.5ch.io/test/read.cgi/newsplus/1787953774/

crates.ioにはフリーライダーが多いのは事実

1. 語彙が多すぎて直交していないと感じる具体例
�@ メモリを指す「ポインタ・参照」の種類が多すぎる
C言語なら基本的に * だけで済むポインタ表現が、Rustでは用途ごとに細分化されています。
&T / &mut T （安全な参照）
Box<T> （ヒープ確保）
Rc<T> / Arc<T> （参照カウント）
*const T / *mut T （生ポインタ・C言語と同じ）
Cow<'a, T> （コピー・オン・ライト）
�A 文字列を表す型が多すぎる文字列ひとつ扱うのにも、文脈で使い分けが必要です。
String
&str
CString / &CStr （C言語互換用）
OsString / &OsStr （OSのファイルパス用）
�B 非同期処理や制御構文の「専用キーワード」が追加され続けている
直交性を犠牲にして、書きやすさのために追加されたキーワードが多数あります。
エラー処理の ? 演算子（match で十分書けるが、記述量削減のため追加）
非同期の async / await
ループの loop、while let、for

2. なぜRustは「直交性」を犠牲にしたのか？
Rustがこれほど語彙を増やした理由は、主に「コンパイル時に安全性を100%保証する」ため、
そして「ゼロコスト抽象化（実行速度を落とさない）」を達成するためです。
特徴 - C言語の割り切り - Rustの割り切り
設計思想 - シンプルで直交した構文を組み合わせる。安全性は開発者が頭の中で担保する。 - コンパイラに事実を正確に伝えるため、専用の語彙を増やす。安全性は機械が担保する。
デメリット - 自由すぎるがゆえに、バグ（Nullポインタ、メモリリーク）が実行時まで見えない。 - 学習曲線が非常に険しい。コードの見た目が複雑で、覚えることが多い。
Rustは「直交性を犠牲にしてでも、実行時のバグをコンパイルエラーとして検出する」というトレードオフを選択した結果、語彙の塊のような言語になっています。
もしRustの学習や実装で、特に「どれを使えばいいか分からない」と混乱している具体的な要素があれば教えてください。
文字列の使い分け（String と &str）
スマートポインタの使い分け（Box や Rc）
ジェネリクスやトレイトの複雑さ
あなたのC言語の知識をベースに、最もシンプルに整理する方法を提案します。

馬鹿にはRustは難しい

ボコボコダウンロードさせる割りに

llvm なんかの変更についていけないポンコツぶりw

>>473
ラスト関係ないよ

読み方ルストじゃないんだな

dust→ダスト
just→ジャスト
must→マスト
trust→トラスト

日本語で馴染みがあるのはこのくらいか

今の若者はrusty nail知らないのかね👴

jusco岡田屋～

ガス爆発か()

Rustでもソフトウェアサプライチェーン攻撃　「arrayref」など人気クレートで侵害
Rust Security Response Teamは、「arrayref」などの人気クレートが悪意あるコードを参照するよう改ざんされたと発表した。該当バージョンはすでに削除済みで、開発者にローカル環境の確認を呼びかけている。
https://atmarkit.itmedia.co.jp/ait/articles/2608/31/news037.html

ここまでラストハリケーンなし

Rustで造っておけとあれほど
http://blog.livedoor.jp/corez18c24-mili777/archives/60026921.html

>>481
Gust

ガッツ石松

Rustデバッグ調査2026：74%が「変数の中身が正しく見えない」——print文頼りが半数超の実態
https://techfeed.io/entries/6a9f2e8e3e0b24377900ab0f

Cでもデバッガ使わないから構わん

go とか rust とか

管理し難いステルスDLをボコボコさせるのはゴミ

>>492
どちらも他の言語と同じく必要となるもののみ自動ダウンロードされる
プログラミング言語での標準

C最強
インターネットにホイホイ繋げない環境もあるのにな
SaaSとかダサダサだぜ

>>494
Rustも事前ダウンロードでofflineでもコンパイルできる

それはいい選択だ。最近yoctoの環境作るのにofflineで面倒

とりあえずCはほぼどこでも使える基礎教養みたいなもんかな

Cコンパイラしか使えない一部の組み込み環境を除くと
それ以外は全てRustが代替できるようになった

信号処理Rustでやるかね。matlabからのトランスパイラがあればワンちゃん🐶

とりあえずCは指先サイズマイコンからスパコンまでフルカバーだしね。
良くも悪くも高水準アセンブラ
その上でプラスアルファとして何を積むかって感じだけどそこまで言語仕様でガチガチにしなくてもコーディングスタイルまで含めてAIで「てめえ、そんなコード書いてんじゃねえ！」とチェックされていくような感もある。

サーバーサイドプログラミングで、Javaやnode.jsやPythonの遅さに
困ってた人が、C++ だとメモリーエラーに悩まされてプログラミング
が進まなくて、さらに困っていた時に Rust というのは解決策になって
喜ばれたのかもしれないが、C や C++ を普段から使いこなしている人は、
そもそもメモリーエラーにあまり悩まされていない。だから、
Rust に魅力を感じない。

>>501
Rustが使える環境・状況ならばC/C++を使うな！がIT業界の常識
アメリカなどは政府レベルでもRustを推奨している
現実問題としC/C++は未だにセキュリティホールを生み出し続けているため

AIがソースコードのチェックしてくれる時代にはC/C++だろうとRustだろうとあまり関係なくなるかな

>>503
Rustなら言語仕様によりコンパイルを通すだけで100%防ぐことができます
これをAIにやらせることも可能でコンパイルが通ったことをもって100%検証できます

しかしC/C++の言語仕様とAIでは100%防ぐことはできません
そんな方法は存在しません
検証もできません

もうプログラム言語はRust一択なんだよ
それ以外の言語は使うヤツはザコ

Rust面倒くさいし、Cでいいよ。セキュリティホールってスパコン内で計算するのに気にしないわ

コマンドラインのオプションにセキュリティホールがあったからって何だってんだ。このアプリ使うのはオレだけさ

マイクロソフトに就職しろ。あそこは第一言語にしたそうだ

Cは全ての環境で使える共通言語だし、既存の資産も膨大だから使えたり読めるのは当たり前かな

Rustは個人的興味で使うこともあるけど、書いてて楽しくないのよね。
プログラムを書かされる人のための拘束具付き言語って感じで。Mな人は嬉しいのかな？
まあ、何を使おうとアルゴリズム自体のミスはどうしようもなかったりもするけどね。

いずれパイプコーディングが進んでいくと人間にも可読性のある中間言語としてはシンプルなもので良いってことになって、ぐるっと回って結局Cでいいじゃん！になるのかもしれないけどね

バイブね

>>509
AIにCでコード書かせてもそれが100%安全であるという検証方法が存在しない
そもそも自分で書いていても楽しいのは抽象度高く読み書きとメンテしやすいRustだろう

その通り
今時Cなんて使ってるヤツは糞ザコ

>>509
書いてて楽しくないのめっちゃ判ります
そういうの大事よね

bunはCじゃないけどメモリ関連バグに悩まされて
AIでRustに書き直したのに
AIならRust不要とかよく言えるな

色んなプログラミング言語を使ってきたけどRustは書きやすくて楽しい言語
楽しくないと言ってる人は色んな言語を使ったことがなくてプログラミング不得意な人でしょう

>>514
書き直し後の13,000個のunsafeは今どうなった?

アンチスレで擁護コメ書いても無駄骨だわなあ。擁護スレあるんだから、そっちで吠えてたら？
RustはM体質な方には良いかもしれないね

>>511
最後は結局機械語/アセンブリ言語なんだし、それより少し上位なのがC言語ってだけだから、その主張はナンセンスだよ。
そういや、初期のC++はトランスレーターだったなあ。

>>514
AIにアセンブラまで落としこんでと言えば落ちたでしょ？

ID:Gzj/jzxQはアセンブラが何かをわかってないんだと思う
プログラムのコードをアセンブラにする馬鹿はいない

Rustの悪口言ってもAI時代ならCは安心にはならないという
単純な話がわからない馬鹿だからアンチやってるんだなあ

安心など不要
吹っ飛ぼうぜコアダンプ

普通のAI：AIにアセンブラまで落としこんでと言えば「こうです」と出して来る
賢いAI：「断る。プログラムのコードをアセンブラにする馬鹿はいない。」
忖度出来るAI：「5chでマウントとりたいならこう言いなさい。『Rustの悪口言ってもAI時代ならCは安心にはならない』」

何で擁護が湧いてるんだ。ちゃんとアンチのロールプレイして

アンチが馬鹿すぎるからだろ

十分条件と必要条件の区別もできないから
痛い批判してやったぜとアンチ本人だけが思ってる

シームレスにGPUが使えるとかCにないメリット出てこないと置き換えは難しいだろね
apacheとか書き換えてこ

そうかあ
RustにはAlgebraic Effectsは無いのか

そもそもRustが嫌いなのに、なんで Rustの成長を応援するものか。
むしろ 全力で Rust の足を引っ張りたい。

CはCPUやOS問わず使えるユニバーサルな言語だからね。
アセンブラに落とす前の中間コードとして使うのにも便利なのよね。
過去資産も山ほどあるしてCが使えること自体は必修科目みたいなもの。
Rustを使いたいなら使えば良いけど当面Cが使えることは基礎教養。

Rust自体の開発はペース落ちてるらしいな

>>530
一部に基礎教養が含まれるが
C言語は基礎教養ではない
まず大量にある未定義動作の存在は一切覚える必要がない
欠陥だらけの標準関数も覚える必要はない

システムコールはC基準だから覚えた方がいいぞ

>>533
システムコールは重要だがCではなくOSの機能
そしてシステムコールの呼び出しABIとCのABIが一致するわけではない
そのためCのライブラリでもシステムコール部分はアセンブラを使う

システムコールをフルに使える言語ってCでしょ
Goもシステム系言語だけど網羅してなさそう

>>535
自由にシステムコールを自分で呼び出せばよい

Goはインラインアセンブラ機能はないが提携機能はある
Go側にシグネチャだけ書いて*.sファイルをリンクできる

Rustはインラインアセンブラ機能がある
Rustコードの中にasm!マクロでシステムコール呼び出しを書ける

CはRustと同様にインラインアセンブラ機能で未知のシステムコールにも対応できる

さすがに生のシステムコール呼びたくないから、nixやら使うじゃないの
Cは用意されてるからCがいいよ

そもそもシステムコールがC I/Fだかんね。

Linuxプログラミングインターフェース、1604ページ、オライリー
をよろしく

>>538
システムコールのABIとCのABIは一致しない
システムコールはOS毎にアーキテクチャ毎に決まる

Q. システムコールとC言語のインターフェースはなぜ異なるのですか？

A. システムコールは関数呼び出しではなくシステムコール用のCPU命令や割り込み命令を使います。
引数や戻り値に使われるレジスタやメモリの使用方法も同じとは限りません。
通常の引数とは別にシステムコール番号をレジスタに指定する必要もあります。
その他に退避させるべきレジスタの決まりが異なる場合もあります。
以上の理由によりシステムコールとC言語のインターフェースは異なります。

x86-64/amd64アーキテクチャの場合
システムコールは専用のsyscall命令が使われて戻りアドレスとフラグはrcx/r11に自動的に退避される
一方でCの関数呼び出しだと戻りアドレスはスタックに退避されてrcxは第4引数に用いるなどインターフェイスは違う
結局アセンブリ言語で書くしかない

普通は直接書かないよ。ライブラリを使う

Cのライブラリもシステムコールはマシン語で書かれてるよ
Cだけが何か特別な立場ではないし何か優遇されてることはないよ

そのライブラリの充実度はどの言語がいいかなあ。という勝負が始まっているんよ
Rustはシステムコールをラップしたライブラリ良いのあるかね

普通のプログラミング言語では
システムコールという特定のOSに依存した形でのプログラミングをしません

Rustはシステムプログラミング向けの新しい言語と言われていた記憶があるのだが
>>546の主張は何なのか誰か解説して

>>541
めちゃくちゃ原始的な意味でのsystem callは、
sysenter、syscall、int 21h みたいなことが多いが、
例えば、Windows API の基礎である Win32 API の
CreateWindow() や、CreateFile()、TextOut()、
LineTo()、MoveTo()、glBegin()、glEnd() などは、
全て、C の関数呼び出しの ABI の一種を使っている。
Windows においては、
C は、通常は、32BIT モードでは、cdecl、64BIT モードでは、fastcall
を使っている。
上記の Win32 API だと、
32BIT モードだと、stdcall に変わるが、C 言語でサポートされている
calling convention の一種で、関数宣言の際に、
stdcall と修飾していれば、C 言語で普通に使える。
64BIT モードだと、C の関数も、Win32(Win64？) API も、
どちらも、fastcall。
なお、クラスに所属する非staticなメンバ関数は、32
BIT モードの場合は、thiscall と呼ばれ、cdecl と似ているが、
this が、ecx レジスタに乗る、という点が、cdecl と異なる。
cdecl は、すべて stack 経由。stdcall は、cdecl とほとんど同じ
だが、stack pointer を元に戻すのが、呼び出された側。
cdecl は、呼び出した側。

>>548
補足すると、Win32 API は、kernel32.dll や user32.dll、
gdi32.dll などの中で、実装されていて、user land
で実行されるものは、それらの dll の中で実行される事が
ある。
kernel land で実行されるものは、それらの dll の中には、
syscall などを使った短い呼び出しコードが書いてある。
また、アプリから、Win32 API を使う場合、
例えば、kernel32.dll の中の API を使いたい場合には、
kenel32.lib という小さなライブラリをリンクする。
しかし、アプリ側から見ると、どの場合も、syscall などは
直接使わず、C 言語レベルの関数を呼び出しているだけ。
但し、32BIT モードの場合は、通常の cdecl ではなく、stdcall
と呼ばれる呼出し規約(calling convention)が使われる。
stdcall と cdecl の際は非常に小さく、msvc、gcc、clang は
当然のことながら、必ず実装している。

>>549
誤: stdcall と cdecl の際は非常に小さく、
正: stdcall と cdecl の差異は非常に小さく、

>>58
[何が言いたかったか]
WindowsでもUnix(Linux)でも、「システムコール」、または、
それに当たるものは、C 言語から直接呼び出せる、
ということ。
その際、アセンブラコードは全く不要。
* Linuxでは、open、close、read などがシステムコールで
C 言語から普通に呼び出せる。というか、それは非常に古く
からのUnixの伝統。C言語と Unix 系OSは、一蓮托生。
* Windowsでは、システムコールという言い方は余りしないが、
それに当たるものは、CreateFile() や、CreateWindow()
で、Win32 API と呼ばれているものであり、それらも、
C 言語から普通に呼び出される。

>>551 は、アンカーミスで、正しくは、
は、>>548 に向けたもの。

>>551
今思ったが、>>534 から書きこんでいる人は、
x86/x64 の マシン語の「syscall 命令」と、
昔から Unix 系OSで「システムコール」と呼ばれていた関数群を
混同していたのかもしれない。
それらは別の概念。

>>548
それらはシステムコールではなくWindows API

私もlinux(unix)ぐらいしかわからんので、システムコールと言えば
open、read、write、close　みたいなもんだと思ってた。

>>554
そこまでいうなら、Windows における「システムコール」という言葉の定義から始めなければならない。
いずれにせよ、C言語から呼び出せない OS の機能は、基本的に
ドライバですら使うべきではない、と考えられている。
つまり、C言語から呼び出せないシステムコールは、
実質的には存在し無いと言える。
何か有ったとしてもそれは非公開機能であり、システムコール
とは通常言わないものである。

>>551
必ずアセンブラコードが必要になります
システムコールはC言語の機能だけでは呼び出すことができません
実際にそのopen、close、readなどの関数がどのように実装されているのか見てみるとよいでしょう

>>557
そんなことない。
あなたの理解が間違っている。

>>556
MS-DOSの時代からシステムコールはint 21h割り込みとして定義されていたよ
だってC言語使う人は少数派だしシステムコールがC言語で規定されても困る
どの言語から見てもint 21hやsyscallなどはアセンブラで呼べるからね

>>559
MS-DOSのシステムコールは int 21h だったことは間違いないが、
現代の OSであるところの、Linux(Unix系)、Windows OSの
システムコールと言えば、open()、read()、
CreateFile()、CreateWindow() などの C 言語インターフェース
の関数のことを言う。
MS-DOS は古い。

なんか違和感が有って、今調べてみたら MS-DOS の int 21h
は、正式名称は「DOSファンクションコール」。
システムコールでも間違いではないが、正式名称ではない。

>>557が正しい
ID:eomllbB2は実際にLinuxなどでopen, read, write関数を実装してみることを勧める
インラインアセンブラを用いないとCでは実装できないことがわかる

>>562
間違ったことに賛同すべきではない。
知識の浅い人が知識の浅い人に賛同している。

>>562
なお、いま議論しているのは、
「システムコール自体を自分で実装する」
という意味ではないハズだぞ。
システムコールがC言語から呼び出さるかどうかの話だ。

>>563
システムコールopen, read, writeなどをC言語だけでは実装できないこと理解できたかい？

もしかして、OSを自作したい人が、システムコールを自作するために
C言語だけでは無理、と言っているのだとしたら、それは正解。
システムコールと呼び出す側と、システムコールを提供する側
は全く別の話だ。
それを混同しては駄目。

>>564
どの言語からでもアセンブラを使えばシステムコールを呼び出せるよ
C言語でも全く同じでアセンブラを使ってシステムコールを呼び出してるよ
C言語だけでは無理

>>565
実装と呼び出しは別だ。
言葉が間違っている。

>>567
違う。
呼出しは、C言語だけでもできる。
実装は無理。
「実装」 != 「呼出し」

「Unixは、99%がC言語で作られている」
という事は正しい。
しかし、すべてC言語だけで作れる訳ではない。
その syscall などの部分だけは C 言語では無理。
しかし、アプリやドライバは、C 言語だけで
システムコールを呼び出せる。なお、
「syscall 命令」 != 「system call」
ということを理解しないとダメ。
ちゃんとGoogle検索にかけるか、ちゃんとしたAIに聞け。

その通りで
「OSが提供するシステムコール」と
「C言語でシステムコールを呼び出せるようにC言語が提供するシステムコール関数」は異なる
この違いが特に顕著にわかるのはC言語のerrno変数
C言語が提供するシステムコール関数の汚点や恥部と呼ばれている
もちろんOSが提供するシステムコールにはそんな欠陥は存在しない
C言語だけの欠陥だ

>>571
そういうことではない。
あなたもちゃんと理解できてない。

OSのシステムコールにerrno変数は存在しないけど、
C言語のopenやreadはerrno変数を使うということは、
C言語のopenやreadはあくまでもC言語用にカスタムされた独自のインターフェースの関数という理解でいいのかな。

その観点でもCのインターフェースとシステムコールのインターフェイスは異なる

libcがラップしてシステムコールを関数としてCから呼べるようにしてくれてる。
Rustのnixなどもシステムコールに新規のフラグなどが追加されたら更新に追従するのだが、glibcより数ヶ月は遅れるそうだ
C最強！

libcもglibcもerrno変数が酷いよな
関数呼び出ししてるのに
グローバル変数(問題が起きまくってスレッドローカル変数へ変更)
に結果を返す極悪仕様

pthread昔なかったから

システムコールのインターフェース仕様はシンプルで美しいのに
C言語インターフェースが邪悪なerrno変数を産んだ理由は何なの？

シグナル

>>573
おそらく誤解を含んでいると思われ、指摘しておくと
linuxのシステムコールであるopenやreadは、errnoは設定しない。
errnoを設定するのはC標準ライブラリ関数のfopen、freadだ。(errno自体もC標準ライブラリに属する変数だ。システムコールに属するものではない。)

ライブラリ関数はカスタムというか、OSには非依存、言語としての定義だね

>>580
Cの関数はシステムコールを生で提供していないニセモノだよな
errnoなどの独自カスタムをしている

本物になれなかった偽物と言うより意図して他層に作られた別物だよ
ファイル周りはハードウェア制御が関わる領域はOS側(システムコール)、バッファリング等のソフト寄りはユーザプログラム側(ライブラリ)で賄う構成が見て取れる。OSもプログラム言語も同時期に作ったからその塩梅は作り手の自在だったろうね

C言語はerrnoの存在やバッファオーバーフローを容易に発生させる関数も抱えたけど、当時の他言語が抽象化を進める代わりに実行効率を落とした。対してCは軽量なデザインによって高効率かつ充分高級な言語が実現できることを証明した。メモリ64KByte以下クロック10MHz未満のシステムでもコンパイルと実行、実用が可能だった
マルチスレッドや性善的設計に関わる問題まで初期開発当時に対処せよというならば、それは状況的に酷に思う

>>582
Rustはゼロコスト抽象化だから全てを手に入れたうえで速いよ
速いだけで全てがないCに勝ち目なし

Linux、UNIXはlibc使って、生のシステムコールを隠蔽してるんだよ
移植性のためだと思われ
OSによっては生システムコールのABI変更したりするそうだよ。appleとかappleとか

>>584
途中でlibcの実装を変えることはできないため
新たな環境な新たなアーキテクチャに対応する時に新たに決めるだけで後からの変更はできない
だからlibc使わずとも直接システムコール呼んで構わない

macOSでは生はダメだそうだ。
Linuxは御大のユーザーランドに迷惑をかけないという強い信念でABIが維持されているから大丈夫なだけだよ

組込みなら運用始まったら、カーネルとlibcを互換性崩れるようなものに入れ替えないのは、それはそう

何のスレかわからんが、ためになりました。linuxはともかく、winとかは大変みたいですね。

WindowsはWindowsで、Microsoftが血反吐を吐きながらWin32 API維持してくれてるから、たいへんという程でもないんじゃない？
Ansi版APIとUtf16版APIを意識しておく必要という点ではややたいへんとも言えるかもだが

最初期のRustコンパイラってRustで描かれてたの？
まさかC使ってたなんて言わないよね？

言わんね

>OCaml（旧称：Objective Caml）の最初のバージョン（1996年リリース）は、
>前身である Caml Special Light や Caml Light などをベースに開発されており、
>主に OCaml自身（およびCaml方言） および仮想マシン・ランタイム部分などに C言語 が使われて書かれました。
>なお、歴史をさらに遡った最初の「Caml」の処理系（1987年）は、Lisp で書かれていました。
フーンω

コンパイラもインタプリタも任意の言語で作れるからな
C言語なんて必要ない

最初だけは仕方ないわね。CコンパイラもアセンブリでCのサブセット言語作って、それで一旦コンパイルしてから、出来たやつでコンパルするとかややこしいことやってた