Rustアンチスレ

Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです

今の若者は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などの独自カスタムをしている