Qiita 7 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2025/09/13(土) 12:24:07.83

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/
Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/
Qiita 4 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1705486836/
Qiita 5 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1717651046/
Qiita 6 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1739527246/

**デフォルトの名無しさん** · 2025/10/22(水) 20:39:07.74

>>378
コードを書けないのはおまえだろ
その出力結果を見ろよ

999999999 0.000000 sec.

**デフォルトの名無しさん** · 2025/10/22(水) 21:14:42.57

> コードを書けないのはおまえだろ
> その出力結果を見ろよ

何が起こってるか分からんとこういう反応ｗ

**デフォルトの名無しさん** · 2025/10/22(水) 21:44:59.81

実行時間0秒ということはコンパイル時の定数化だろうね
コードを正しく書けない人が定数データをそのまま使って正しくベンチマーク計測できていない典型的な失敗例

**デフォルトの名無しさん** · 2025/10/22(水) 22:01:20.17

>>379
>>381
「とんでもなく高い」と>>279が言ってるオーバーフローチェックをコンパイル時にやれてることが理解できない低能ｗ

**デフォルトの名無しさん** · 2025/10/22(水) 22:11:40.81

比較ベンチを測るプログラムでコンパイル時に定数になってしまってるのは初心者あるあるでちよっと恥ずかしい
さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ

**デフォルトの名無しさん** · 2025/10/22(水) 22:25:59.29

> さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ

コスト0でできるオーバーフローチェックの例を挙げただけだけど馬鹿だとこういう理解になんのなｗ

**デフォルトの名無しさん** · 2025/10/22(水) 22:40:18.18

連投クンは3つの過ちを犯している
①実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった
②その結果をもってコスト0だと主張
③その事例をもってオーバーフローチェックは重くないと主張

**デフォルトの名無しさん** · 2025/10/22(水) 22:53:43.71

> ①実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった

オーバーフローチェックのコストの話だからコンパイル時にできるんなら御の字なんだよなあ。

> ②その結果をもってコスト0だと主張

俺が挙げた例ではその通り。

> ③その事例をもってオーバーフローチェックは重くないと主張

オーバーフローチェックの重い例はIDコロコロ君が挙げりゃ良いのにｗ

馬鹿って本気で馬鹿なんだなあという感想しかないわｗ

**デフォルトの名無しさん** · 2025/10/22(水) 23:22:33.57

定数の同士の計算をコンパイル時にできるだけでしょ
普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ

**デフォルトの名無しさん** · 2025/10/23(木) 00:01:19.28

> 定数の同士の計算をコンパイル時にできるだけでしょ
　
同じコードで「最適化レベル3 オーバーフローチェックなし」では定数の同士の計算をコンパイル時にできていないので場合による。rustcは最適化が控えめなのでオーバーフローチェックを行ったほうがデータフロー解析を深いレベルで行なって効率良いコードを吐いてくれる可能性まである。
　
> 普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ
　
できる場合もあればできない場合もある。
安全性を蔑ろにして良いわけはないのでコンパイル時にできないのであれば実行時のオーバーフローチェックは行うべき。そのコストが問題になるのであればプログラマがオーバーフローしないことを保証してやれば良い。

**デフォルトの名無しさん** · 2025/10/23(木) 00:05:35.18

言い訳ばかりだな
オーバーヘッドを比較するための実行時間ベンチマークで
まともなプログラマーならばコンパイル時定数になるコードを書かない

**デフォルトの名無しさん** · 2025/10/23(木) 00:08:38.47

コンパイル時にオーバーフローチェックされた例が余程悔しかったと見えるｗ

**デフォルトの名無しさん** · 2025/10/23(木) 00:10:30.87

つか何で
　
> オーバーフローチェックのコストはとんでもなく高いんだよ。
　
という具体的を提示しないんだろうか?

**デフォルトの名無しさん** · 2025/10/23(木) 01:00:14.89

>>379
実行時間を比較しようとして定数計算で実行時間0.000秒は草
それをそのまま貼るのは慌てん坊

**デフォルトの名無しさん** · 2025/10/23(木) 22:48:26.28

最適化レベル3 オーバーフローチェックなし
https://wandbox.org/permlink/LOcWoipF2aESW8HO
> 999999999 0.000000 sec.

最適化レベル3 オーバーフローチェックなし
https://wandbox.org/permlink/BcHSm4UljxoF26fp
> 999999999 0.192019 sec.

なるほど、確かに最適化控えめだなｗ

**デフォルトの名無しさん** · 2025/10/24(金) 10:56:06.36

> オーバーフローチェックのコストはとんでもなく高いんだよ。
　
clangより遅いRustがますます遅くなっちゃうってことか。
でもそれで安全性と天秤に掛けて安全性捨てて良いって理屈にはならんと思うが。

**デフォルトの名無しさん** · 2025/10/24(金) 11:39:42.14

Rustはオーバーフローに関しても最も充実している言語
まずデフォルトではデバッグモードとなりオーバーフローを含めた様々な問題をチェックして指摘してくれる
次にオーバーフローを取り扱う関数が30個以上と充実しておりオーバーフロー時に様々な対処ができるようになっている
さらにオーバーフローチェック強制モードを指定することもできる

**デフォルトの名無しさん** · 2025/10/24(金) 12:33:51.25

肝心のユーザーが
　
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
　
こんなこと言ってるようじゃせっかくの機能も台無し。
こういうユーザーはオーバーフローを軽視しているので、それを扱う関数を呼んだりオーバーフローチェック強制モードを指定することもしない。

**デフォルトの名無しさん** · 2025/10/24(金) 12:54:38.21

Rustより優れているプログラミング言語がなく出現しそうにない
IT大手をはじめとして各社が次々とRust採用に踏み切った理由

**デフォルトの名無しさん** · 2025/10/24(金) 21:32:19.69

何をもって優れてるというのか知らんけど
採用される率だったら圧倒的に Python や JavaScript じゃないの？

**デフォルトの名無しさん** · 2025/10/24(金) 22:24:54.90

普及している言語を採用するのは当たり前
普及してない言語をわざわざ採用するのは他の言語では代わりにならないほどメリットがある時

**デフォルトの名無しさん** · 2025/10/24(金) 23:11:41.06

> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない

この程度の実行時検出もできなくて「メリットがある」と言い張ってて草ｗ

**デフォルトの名無しさん** · 2025/10/25(土) 00:27:47.26

見ていてなんとなくわかってきた
プログラミング言語として敵わないからよくわからない言いがかりをつけてずっと粘着しているだけのような

**デフォルトの名無しさん** · 2025/10/25(土) 08:20:17.15

言語の優劣（笑）にこだわってる子が一人だけおるっていう状況かな
自己のアイデンティティを借り物で満たそうとしちゃってるね
自分がRustの作者ってんならともかく、単なるユーザでしかないのにね

**デフォルトの名無しさん** · 2025/10/25(土) 08:45:36.74

>>395
オーバーフローに関してそこまで充実していない言語も多いけど、なぜか充実している言語の方をしつこく叩いてるコンプレックス持ちがおるから面白い。

**デフォルトの名無しさん** · 2025/10/25(土) 11:38:38.14

安全性分かってない奴がRust盲信してて笑われてるだけｗ

**デフォルトの名無しさん** · 2025/10/25(土) 11:52:03.54

>>52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ
　
IDコロコロ君安全性は屁のように考えてるみたいだけど、だったら配列アクセスのたびに範囲チェックで無駄なコスト払ってるRustは良い言語ではないんじゃね? それかunsafeでポインタアクセスするのが正義?

**デフォルトの名無しさん** · 2025/10/25(土) 11:53:06.73

安全性のためにRustを採用するところが世界的にどんどん増えているのはなぜだろう？

**デフォルトの名無しさん** · 2025/10/25(土) 11:59:12.87

Rustの普及と
　
> 安全性などはついでのオマケ
　
とか言っちゃう馬鹿が笑われてるのは別の話だゾｗ

**デフォルトの名無しさん** · 2025/10/25(土) 12:07:43.62

>>405
Rustは配列などのアクセスもゼロコスト抽象化で速さと安全性を両立してるよん

**デフォルトの名無しさん** · 2025/10/25(土) 12:58:15.22

>>408はrustcの出力見たことない人かな?
配列の範囲チェックって

https://godbolt.org/z/6johWYEce
> cmpq %rsi, %rdx
> jae .LBB0_7

↑がそれ。

ちなみにCだとこんなだ。
https://godbolt.org/z/3q4rv8P3M

**デフォルトの名無しさん** · 2025/10/25(土) 13:03:29.33

rustcが最適化控えめという話は既出か。

rustc
https://godbolt.org/z/4T5Wha7M3

clang
https://godbolt.org/z/j9r59Pv9q

**デフォルトの名無しさん** · 2025/10/25(土) 17:01:14.86

C言語は、ポインタが、ヤバイくて、危ないよね。
RUST言語は、ポインタが、無いのなら、安全ぢゃねえ?

**デフォルトの名無しさん** · 2025/10/25(土) 17:40:57.11

>>402
マジでこれ
関数型言語あたりに多いけど、自分が好きな言語をアイデンティティにしてる奴にまともなのはいない
自分は何を作れるか・何を作ったかの方がプログラマにとっての価値だろ

**デフォルトの名無しさん** · 2025/10/25(土) 18:04:23.93

個人開発ならともかく、仕事で使う言語は自分の好みじゃなくて組織によって決まるものだよね
Rustが好きでも、Goのプロジェクトに入ったらGoを書く、Javaのプロジェクトに入ったらJavaを書くのがプロ
宣言的なコードが好きだからといって、OOPの言語や、for文と if文をひたすら書かされる言語では仕事したくないです、なんてのは社会人としてだめでしょ
(Rustを使える企業に転職する、という選択ができる人は別だけど)

**デフォルトの名無しさん** · 2025/10/25(土) 19:23:29.07

企業や立場によってピンキリだよ
そういう歯車として使われる人もいればそうでない人もいる

**デフォルトの名無しさん** · 2025/10/25(土) 19:50:23.21

どの分野でもAとBの比較の話をしている時に同じことが起きてるな
純粋にそれぞれの特徴やメリットで優劣を比較すればいい
ところが不利になった側はどの話でもこう言い出す
Aを使うやつはXXXだ！Aの価値よりおまえの価値はどうなんだ！
AとBの比較から逃避して人間の攻撃を始める

**デフォルトの名無しさん** · 2025/10/25(土) 19:55:57.53

なんか話がズレまくってるなここ

**デフォルトの名無しさん** · 2025/10/25(土) 19:56:03.79

> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
　
とか
　
> 安全性などはついでのオマケ
　
とか言ってる人は根本的なところがわかってないので言語を選定したりプロジェクトを先導する立場に立たせてはダメ。

**デフォルトの名無しさん** · 2025/10/25(土) 20:04:36.75

安全性と速さの両立が最重要だもんな
利害対立し合うIT大手企業が珍しく揃ってそのために選択したRustを用いるのが正しい

**デフォルトの名無しさん** · 2025/10/25(土) 20:25:04.83

> 安全性と速さの両立が最重要だもんな
　
↑馬鹿発見ｗ

**デフォルトの名無しさん** · 2025/10/25(土) 20:33:41.34

安全性と速さだけではダメ
高い抽象度で読み書きしやすいことが大切
Rustはそこを満たしたからこそ新たな移行先になった

**デフォルトの名無しさん** · 2025/10/25(土) 22:07:09.40

>>411
Rustもポインタが使えるし場合によっては危険。
https://godbolt.org/z/7TPGs1xsr

**デフォルトの名無しさん** · 2025/10/25(土) 22:29:45.32

>>421
生ポインタの指す先を読み書きできるのはunsafe Rust
unsafe RustではC言語と同じ状態という点で危険だが普通のプログラミングでunsafeを使うことはない

**デフォルトの名無しさん** · 2025/10/25(土) 22:31:29.44

言語の良し悪しを語ってる時点で草なんよね
だって俺らは与えられた言語で仕事するだけだから
C++でもPerlでもPHPでも書くだけだから
You play with the cards you're dealt.

**デフォルトの名無しさん** · 2025/10/25(土) 22:36:24.17

>>423
IT土方は仕事を選べないもんな

**デフォルトの名無しさん** · 2025/10/25(土) 22:58:03.75

はい（真顔）

**デフォルトの名無しさん** · 2025/10/25(土) 23:15:04.51

土方が無理に言語の優劣の話にクビを突っ込まなくてもいいけど
新たな優秀な言語が出現したチャンスと捉えて習得して土方を脱出する手もある

**デフォルトの名無しさん** · 2025/10/25(土) 23:23:22.89

> 普通のプログラミングでunsafeを使うことはない
　
と言ってる人はunsafeが使われてる標準ライブラリも使わないのかな?

**デフォルトの名無しさん** · 2025/10/25(土) 23:28:59.12

>>427
それは真逆だよ
Rustでunsafeが使われるのは標準ライブラリの内部やそれに準じる基盤クレートの内部
普通のRustプログラミングでunsafeは使われない

**デフォルトの名無しさん** · 2025/10/25(土) 23:40:35.95

> 普通のRustプログラミングでunsafeは使われない
　
ああ低レイヤに縁のない人か

**デフォルトの名無しさん** · 2025/10/25(土) 23:53:30.01

低レイヤの意味は複数あるけど
いずれも可能な限りunsafeは使われないね
効率面でunsafe必要になるパターン一般化されてプログラムの外部へ切り出されてライブラリ化されるよ
そうしてできたのがRustの標準ライブラリ

**デフォルトの名無しさん** · 2025/10/26(日) 01:56:48.53

画像処理でピクセルを走査するようなケースだと unsafe なポインタ操作は必須じゃないの？
インデックスアクセスだと範囲チェックのコストがかかるし
単に1画素を1画素にマップするだけならほぼノーコストでイテレーターを使えるだろうけど、周辺画素を参照する操作もよくあるから単純なイテレーターは使えないし

**デフォルトの名無しさん** · 2025/10/26(日) 01:59:51.53

あとはCとのFFI
過去に書かれたC/C++資産の利用はRustでやりたいことの一つだろうし、これは流石に標準ライブラリのような「一般的なユーザーは使わない」ものでは無いと思う

**デフォルトの名無しさん** · 2025/10/26(日) 02:39:48.97

Rustのunsafeは他の言語と同じ様の状況になりますよという意味で、コンパイルが通っても安全性を保証しませんという意味。
つまり他の言語と同様に、unsafeな部分の安全性は人間が保証してください、がRustのunsafe。

したがって他の言語とリンクする場合にその境界部分がunsafeになるのは当たり前でこれを避けることはできない。
しかしパターン化できる場合はunsafe使用部分をライブラリの中に閉じ込めてそれを安全に用いることもできる。
例えばPythonのライブラリをRustのPyO3クレートで作成する場合など。

**デフォルトの名無しさん** · 2025/10/26(日) 03:35:04.78

低レイヤに縁がない人がオーバーフローチェックを否定してるのがわけわからんのよねｗ
低レイヤ担当は色々手段を尽くして実行効率が良くて安全なものを提供してると思うんだけどそれに乗っかってる側は自分が書いてるコードの実行効率を気にするよりは安全性を重視するべきではないの?

**デフォルトの名無しさん** · 2025/10/26(日) 04:33:18.62

また言語の話で不利になったため逃げて、
妄想上の人の話へとすり替えようとしてる

**デフォルトの名無しさん** · 2025/10/26(日) 09:10:11.83

もうQiita関係ないな

**デフォルトの名無しさん** · 2025/10/26(日) 20:55:09.12

IDコロコロくんは面白いなｗ

**デフォルトの名無しさん** · 2025/10/27(月) 06:58:16.48

せやな

**デフォルトの名無しさん** · 2025/10/29(水) 20:12:21.16

『Cから学ぶRustの良さ』
　
3年前に書かれた記事だがトレンドに挙がってたので初めて見た。
酷い記事だなあ。なんで90人もいいねしてんの?

**デフォルトの名無しさん** · 2025/10/29(水) 23:35:08.75

>>439
C/C++は弱い型付け言語なのでサイズの異なる型への自動変換が起きることに加えて8bit環境以外では
Cでは sizeof('a') == sizeof(123)
C++では sizeof('a') != sizeof(123)
などの無茶苦茶な仕様が混乱に拍車をかけているよな

**デフォルトの名無しさん** · 2025/10/29(水) 23:46:47.92

AIに聞いたら聞き返された
もしよろしければ、あなたが特に「酷い」と感じた記事の具体的な内容や論点について教えていただけますか？
それについて、Rustの技術的な視点から掘り下げて解説することもできます。

**デフォルトの名無しさん** · 2025/10/30(木) 01:06:50.83

ChatGPTに

> この記事読めますか? https://qiita.com/uv_ussy/items/71248bdd081089b7ba09

> 前述の記事には誤りと思われる個所が複数あると思います。気が付いた点があれば挙げてみてください。

と訊いたら

> 確認できた範囲で、記事「Rust と C の比較（著：ushijima ryosuke／uv_ussy）に誤りまたは誤解を招きやすい記述がいくつかあります。いくつか挙げますので、もしよければさらに掘り下げましょう。

と言って気になった点というのを 5点挙げてくれたけどな? >>441はどういう聞き方したんだろう?

**デフォルトの名無しさん** · 2025/10/30(木) 01:16:31.30

>>442
レスの全文を正確にコピペしただけ
AIに聞いた質問は誤りと思われる個所を探すことでない
レスをよく読んでみてね

**デフォルトの名無しさん** · 2025/10/30(木) 01:40:41.25

>>443
俺はお前が「AIに聞いたら聞き返された」って馬鹿なこと言ってるから面白がってるだけよ?

**デフォルトの名無しさん** · 2025/10/30(木) 01:43:15.62

> レスの全文を正確にコピペしただけ

アドレスも貼らんでAIが理解してくれるって認識かｗ

**デフォルトの名無しさん** · 2025/10/30(木) 02:40:13.26

>>440
CとC++で色々と違っているのを知らずに誤解する人多いよね

>>442
Rustの問題ではなくて
Cの問題点と不備な点と間違えやすい点に加えて誤解してる点と間違ってる点のフルコースの記事だね

**デフォルトの名無しさん** · 2025/10/30(木) 08:28:20.42

> C/C++は弱い型付け言語なので
　
それはそう。
　
> サイズの異なる型への自動変換が起きることに加えて
　
サイズの同じ異なる型への自動変換もあるからサイズ関係ないぞ。件の記事はなんでかサイズで説明してるが。
　
> 8bit環境以外では
> Cでは sizeof('a') == sizeof(123)
> C++では sizeof('a') != sizeof(123)
> などの無茶苦茶な仕様が混乱に拍車をかけているよな
　
件の記事ではCとC++の仕様の違いについて言及してないね。「8bit環境以外では」も意味不明。結論的には>>440はバカ。

**デフォルトの名無しさん** · 2025/10/30(木) 08:58:26.48

Cの時点でぐちゃぐちゃなのにC++が互換性を持たせずに変えてしまった部分だからめちゃくちゃになってるところ

**デフォルトの名無しさん** · 2025/10/31(金) 08:16:40.44

>>439の記事の筆者名検索するとFaceBookのページ出てくるけど国立大学で情報工学専攻でこれというのはいろいろ考えてしまうな。

**デフォルトの名無しさん** · 2025/10/31(金) 23:01:52.88

IDコロコロ君はRustスレにも迷惑掛けてるのかｗ
もう自分を迷惑な人材として認識しておとなしくすりゃ良いのにねｗ

**デフォルトの名無しさん** · 2025/11/01(土) 10:19:13.22

12月1日から25日まで、みんなで技術記事を投稿して、カレンダーを埋め尽くそう
qiita.com/advent-calendar/2025
完走チャレンジ賞の達成条件は以下です。
・1人で15～24記事投稿した方を表彰します。
プレゼントカレンダーは2025/10/31～2025/12/31に記事を投稿
期間が2つある

**デフォルトの名無しさん** · 2025/11/01(土) 12:59:34.87

>>447
それが意味不明で分からないなら馬鹿はお前の方では？

**デフォルトの名無しさん** · 2025/11/01(土) 13:07:22.38

『stdio.hやiostream.hの中身を見る方法』
　
/usr/include/ かINCLUDEが指してる先見に行った方が早くね?

**デフォルトの名無しさん** · 2025/11/01(土) 13:40:27.56

> 8bit環境以外では
> Cでは sizeof('a') == sizeof(123)
> C++では sizeof('a') != sizeof(123)

8bit環境に限っては↑のようにならないとでも言いたげだがC言語では'a'の型はintなので
sizeof('a') == sizeof(123)
は常に1となる。
C++では'a'の型はcharなのでcharのサイズがintと同一な環境でもない限りは
sizeof('a') != sizeof(123)
は常にtrueとなる。C++は規格としてintのサイズは最小でも16bitあるから仮にcharのサイズがintと同一の環境であれば
sizeof('a') != sizeof(123)
はfalseとなるが>>440が言ってる8bit環境とやらはcharのサイズが16bitあるのかな?
結論的には>>452もバカ。

**デフォルトの名無しさん** · 2025/11/01(土) 13:50:33.72

そういう基本的な部分でCとC++の扱いが違うなんて失敗言語だよなあ

**デフォルトの名無しさん** · 2025/11/01(土) 15:57:18.25

C++では'a'の型はchar
知らんまま書いとったわｗ

**デフォルトの名無しさん** · 2025/11/02(日) 13:42:32.21

『データ構造入門(1) - ポインタ・配列・構造体』
https://qiita.com/juna1013/items/406723a90ceeff3b04a9#comment-336c986ee3daed589a0f
> 学習のためなら、一度はコンパイルして実行した方がよいと思います。
> C++ならコンパイルエラーになってくれます。

コンパイル確認しろはその通りだがCのタグついててC++のタグはない記事のコードになんでC++でコンパイルなんて言うかなあ?
>>455 同様CとC++が違う言語と認識できてない人かな。

**デフォルトの名無しさん** · 2025/11/02(日) 14:35:56.04

>>457
int genderに"man" や"woman"を入れようとしてるんだぞ
エラーにする言語が正しい

**デフォルトの名無しさん** · 2025/11/02(日) 14:53:51.62

CとC++が違う言語と認識できてない人が早速現れたｗ

**デフォルトの名無しさん** · 2025/11/02(日) 15:01:26.49

>>459は誰に対して言ってるんだ？

**デフォルトの名無しさん** · 2025/11/02(日) 15:18:30.34

CでもC++でもint genderに"man" や"woman"を入れるべきではない
エラーにできない言語を使うべきではない

**デフォルトの名無しさん** · 2025/11/02(日) 20:42:12.68

C言語でポインタ値をintのオブジェクトに代入するべきでないという話はCの規格やコンパイラの吐いた警告で説明できるのだしルールも異なる他の言語引き合いに出す意味はないんだよなあ。
また、C言語は使うべきでないという個人の主張はC言語を学ぼうとしてるQiitaの記事とは関係ないから他所でやるべき。

**デフォルトの名無しさん** · 2025/11/02(日) 22:02:55.28

Cコンパイラしかない組み込み用CPUを使う場合しかCを使う機会ないよな
ほとんどの人にCは不要という現実を教えてあげたほうがよい

**デフォルトの名無しさん** · 2025/11/02(日) 22:10:57.03

>>463は主要な部分をCで組まれたLinuxも使わないで済む世界の住人かな

**デフォルトの名無しさん** · 2025/11/02(日) 22:27:16.77

現在LinuxのカーネルモジュールはRustで書くのがメインとなってるよ
カーネルコアはCのままだけど我々がコードを書く部分はカーネルモジュール

**デフォルトの名無しさん** · 2025/11/02(日) 22:57:14.90

> 現在LinuxのカーネルモジュールはRustで書くのがメインとなってるよ
> カーネルコアはCのままだけど我々がコードを書く部分はカーネルモジュール

馬鹿なこと投稿する前にAIに「LinuxのRustの導入ってどれくらい進んでるの? 」とか訊いたら良いのにねｗ

**デフォルトの名無しさん** · 2025/11/02(日) 23:37:05.58

Linuxの新たなカーネルモジュールはRustで書かれるようになったな
カーネルモジュールのせいで落ちたりセキュリティホールになることを嫌って新たなものから安全性の高いRustで書くことになった
カーネルモジュールの一つであるデバイスドライバもRust製へ

**デフォルトの名無しさん** · 2025/11/03(月) 03:05:07.69

rustきっしょいライブラリやめてC++みてえなのに置き換えりゃいいのに

**デフォルトの名無しさん** · 2025/11/03(月) 13:41:34.84

Rustはgithubにある面白そうなリポジトリでgit cloneしてビルドしてみると外部クレートでビルドが失敗するパターンが多くて損してる希ガス。
Rust開発チームの方針なのだろうけどよく使われるライブラリは保守まで組織的に面倒見る体制は必要だと思う。

**デフォルトの名無しさん** · 2025/11/03(月) 13:59:58.31

>>469
Rustはバージョン管理がしっかりしてるからビルド失敗に滅多に出逢わないよ
バージョン指定していない古いexampleでコンパイルできなかったことがあるくらいかな
具体的に何が失敗したの？

**デフォルトの名無しさん** · 2025/11/03(月) 14:13:09.36

>>470
chatgptに訊いてやったからあとは自分で調べてね。
　
> あなた:
> githubにあるRustで書かれたリポジトリで外部クレートが原因でビルドが通らない問題ってstackoverflowとかで質問に上がることってありますか?
> ChatGPT:
> はい、かなり頻繁にあります。
> Rustのプロジェクト（特にGitHubで公開されているオープンソースのもの）では、外部クレート（依存クレート）に起因するビルドエラーは非常に一般的で、Stack OverflowやGitHub Issuesなどでよく質問・報告されています。
(以下略)

**デフォルトの名無しさん** · 2025/11/03(月) 14:59:51.90

RustはCargo.tomlでversionなど指定していれば古い昔のものでもコンパイルが通る。
指定してなければ最新のversionのものを使おうとするからコンパイルの通らないことが起きる。
ここまでは外部クレートのせいではなくそれ自身の問題。

**デフォルトの名無しさん** · 2025/11/03(月) 16:33:56.23

ChatGPTは依存クレートに起因するビルドエラーの原因を複数挙げるけどこれで論破したつもりかな？

**デフォルトの名無しさん** · 2025/11/03(月) 16:38:27.98

>>469の質問の後、>>471の「Rust開発チームの方針なのだろうけどよく使われるライブラリは保守まで組織的に面倒見る体制は必要だと思う。」も入力すると今のRustの抱えてる問題詳細に語ってくれるなｗ
「Rustはバージョン管理がしっかりしてるからビルド失敗に滅多に出逢わないよ」とは何だったのかｗ

**デフォルトの名無しさん** · 2025/11/03(月) 16:40:19.30

> >>469の質問の後、>>471の
　
>>469と>>471逆だったわｗ

**デフォルトの名無しさん** · 2025/11/03(月) 17:34:50.05

Rustのよく使われてるライブラリなら現実に問題が起きていないから妄想を語っても意味ないかと。

**デフォルトの名無しさん** · 2025/11/03(月) 17:57:47.09

IDコロコロ君Rustスレでは複おじと呼ばれてて「もはや一周回ってRustアンチまである」とまで言われてるのは草ｗ

**デフォルトの名無しさん** · 2025/11/03(月) 19:34:23.76

相当昔だけどいくつかのproc_macroが意図せず公開されていたsynのプライベートアイテムに依存してて
synがしれっとバージョンアップでパスを消して以降ビルド通らなくなるみたいなことはあった
https://github.com/nushell/nushell/issues/2867