海外「ZigはCの後継になるか」議論、記事がAI生成と判定され炎上
姉妹サイトの新着
Hacker Newsで、「システムプログラミングにCではなくZigを使うべき理由」を解説した記事が話題になった。スレでは、Zigのコンパイル時実行(comptime)やアリーナ対応を評価する声と、Cの明示性のほうが優れているとする反論が対立し、長期的にはRustがCやC++を置き換えるという意見も出た。さらに、元記事の文体がAI判定ツール「Pangram」で「99%AI生成」と出たことが指摘され、議論は言語の優劣論からAIライティングへの不信感にまで広がった。
システムプログラミングでCよりZigを選ぶ理由
出典: mtsoukalos.eu / 元記事はこちら
それに、Zigの表現力はC++と同等以上だ(ただしC++特有の暗黙的な動作や言語全体の複雑さがなく、厳密にどの処理が行われているかを確認する必要があるセンシティブなコードのレビューを難しくすることもない)。そのうえアリーナのサポートもC/C++/Rustより優れている。
>>5 じゃあZigで演算子オーバーロードをやってみせてくれよ
>>33 演算子オーバーロードに反対する人は多いよ。俺個人としては、C++の演算子オーバーロードで問題なのは代入演算子までオーバーロードできてしまう点だと思う。見たところ、これが多くの不具合の根っこになっている
>>33 そうだ!例外も継承もRTTIも全部持ってこいよ。過去の失敗を全部復活させよう。C++99時代のノリでパーティーしようぜ
最近の新しい言語はどれもCに比べて読みにくい。俺みたいに for (size_t i = 0; i <= n; i++) total += a[i]; みたいな明示的な書き方が好きな人間には、新しい言語はどれも向かない
>>6 ループの書きやすさが悪いのは設計として疑問だけど、そのループ自体は total = reduce(a, +, 0) より優れているわけじゃないよ
>>6 正直、total = a.sum() がforループより明示性に欠けるとは思わない。むしろa.sum()のほうが、プログラマの意図をそのまま表しているという意味で明示的だ。forループは読み手と書き手の意図の間に余計な層を一枚挟むだけで、しかも実際にハードウェア上で何が起きているかを忠実に反映してもいない。つまり一番悪いとこ取りになっている
ちなみにDやNimは何年も前から同じ機能を持っているよ
>>7 GC付きの言語には便利な機能がいくつもある。でもシステムプログラミングの話をしているときには、それはかなり的外れだよ
>>7 高校生の頃にDで遊んでたのが本当に楽しかった。あの頃は絶対に大きく流行ると思ってたのに、結局広まらなかったのが本当に残念。すごい言語なんだけどな
>>7 Nimony(実質Nim 3.0、作者本人による)をチェックしてみて。これまでの教訓を全部盛り込んでNimを根本から見直したものだ。正直すごく期待してる
どうせRustがこういうニッチな言語を全部駆逐するよ。長期的に見ればRustはCやC++の実用的な後継になり得る。Zigは単に中間的な立ち位置を狙っているだけで、それがうまくいかないことはもう分かっている。LLM時代においてはZigの存在意義はRustに比べて特に薄い
>>8 そもそも人間にとって使いやすいように設計された言語(Rustも含めて)は、「LLM時代」には全部存在意義が薄くなるってこと?
>>8 「Zigは中間を狙っているだけで、それがうまくいかないことはもう分かっている」…分かってたの?
「無視できないエラー」について。GCCとClangなら `__attribute__((warn_unused_result))` でマクロを定義すればいいし、そのCコードを後でC++としてコンパイルする場合(あるいは何もしない場合)は `[[nodiscard]]` を使えば済む話だ
>>9 [[nodiscard]]はC23に入ってるよ
本当にそう。ネイティブなスライスが無いことは、俺が思うにCの最も明白な欠陥だ(そして当然、委員会はそれを実装しないし、当然Cは壊れたままになる)
>>11 だったら手伝えばいいんじゃない?仕様への貢献方法はちゃんと公開されてるよ。まあ、可変修飾型と自作のspan型を使えばどこまでできるか、個人的にはかなり満足してるけどね
>>11 よく分からないんだけど、C配列ってスライスとして使えるよね?ポインタと長さを渡せば(Cの配列はどれもそうやって扱う)、それでスライスと同じくらいうまく機能するんじゃないの?長さの無い配列をそれでいいと思うならだけど
新しい言語が出るたびにわざわざCと比較したがる限り…俺はCを使い続けるよ。それは俺のAGENTS.mdファイルにも書いてある
Zigはもう安定版になった?いいえ
>>13 Zigは好きなんだけど、昔作ったZigのプロジェクトに触るたびにバージョンの不整合を直す羽目になるのは、正直かなり熱が冷める
AIの量産記事だな。このサイトの記事は全部「正直なトレードオフ」みたいな見出しが付いてる。どうせ本の宣伝のために生成されたんだろう、その本もどうせ大したものじゃない
>>14 1週間前までは「AIっぽい文体」に文句を言う人の気持ちが全然分からなかったんだけど、ある日突然自分にも分かるようになった。急に木材の粉塵アレルギーを発症するような感覚に近い
>>14 このZig対Cの記事がAI生成かは分からないけど、同じ著者のZig対Rustの記事は痛々しいほどAIっぽい文章だった。AIそのものに思想的に反対してるわけじゃないけど、記事を書くのにAIが必要な人の本を買う気にはさすがにならないな…
>>14 AI判定ツールのPangramでは99%AIという結果が出てる
シニカルな意見だけど、俺は職を失いたくないんでC++を使うことにするよ
Zigは絶対に成功しない
>>19 なぜそう思うの?
他サイトの新着
>>2 でもZigがやろうとしていることの一部は、そうした良い習慣が自然と身につく「成功の落とし穴」を作ることなんだと思う。だから答えとしては「確かに最近のCでもそれは出来るけど、それを一貫してやるには自分たちが望むより多くの規律が必要になる」というようなものになるんじゃないか
>>20 そんなに規律が必要だとは思わない。必要なのは「やる気」であって、それは別の言語に乗り換える場合にも同じことが言える
>>20 だったらRustを使ってもっと広くて深い「成功の落とし穴」に落ちたほうがいいんじゃない
>>2 でもプリプロセッサマクロの代わりにcomptimeがあるのはかなり大きいと思うけど…
>>2 そういうツールの一部は1979年から存在しているけど、企業にそれを標準として採用させるのはずっと不毛な戦いだった。サイバーセキュリティ関連の法規制が本格化するまではね
>>2 オプトイン(自分で選んで使う)機能とオプトアウト(デフォルトで有効)機能の間には大きな違いがあるよ
>>4 同意。STLを完全に捨てるんじゃなくて、フリースタンディングなサブセットだけ使うのがいいと思う。実装の中にはSIMDで高速化されたコードも含まれている。それに、STLは例外を使わなくても動く
>>4 それが正解。自分の用途に合う部分だけ使えばいい。C++を使うからといって全機能を使わなきゃいけないわけじゃない
>>30 そして自分と違う「お気に入りのC++サブセット」を使う人とは一緒に仕事しないことだね
>>4 ビルドシステムには何を使ってるの?
>>5 アリーナアロケータに興味がある人へ。Rustはバージョン1.100.0で `Allocator` APIをついに安定化させた。チェックしてみる価値は絶対にあるよ
この話題の背景と論点
Zigは2016年に登場したシステム言語で、プリプロセッサマクロの代わりにコンパイル時実行(comptime)を使い、隠れた制御フローや暗黙の型変換を避ける設計を特徴とする。一方Cには標準のスライス型が無く、ポインタと長さを渡す慣習で代用されており、委員会での仕様追加も進みにくい(C23では[[nodiscard]]のような安全機構が追加された)。スレに出たPangramはAI生成文章を検出するツールで、技術系ブログの「AIっぽい文体」への不信感が広がっている一例として挙がった。またD言語やNimは同種のアイデアを先行して実装していたが、普及には至っていない。どの言語が将来主流になるかという議論は海外の開発者コミュニティで定期的に繰り返される話題であり、この一本のスレで結論が出たわけではない。
※本記事は海外掲示板 Hacker News のスレッド「Why Zig over C for Systems Programming」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。