RustにZigのコンパイル時機能がやってきた Crabtimeってマジ 開発が捗るらしいぞ
引用元：https://news.ycombinator.com/item?id=43415820
ロゴめっちゃいいね！Rustのマクロを簡単にするのは素晴らしいと思うよ。ユーザーとしては、proc macroが別のcrateを必要とするのが特にめんどいんだよね。Crabtimeはそれを解決してくれるみたいでいいね。でも、Zigのcomptimeの類似物ってより、コンパイル時のevalの強化版って感じかな。Zigとの大きな違いは型情報へのアクセスだと思う。ZigではできるけどRustではできないからね。残念ながらRustでそれが実現するのはまだ先になりそう。compile time reflectionがあれば、もっとcomptimeっぽくなるんじゃないかな。
＞ZigのcomptimeとRustのマクロの大きな違いは型情報へのアクセスだと思う”ってあるけど、他にも違いはあるよ。まず、comptime関数は構文マクロじゃないから、すごく扱いやすいしデバッグしやすいんだ。強力なリフレクションを備えた、部分的に型付けされた言語で実行される通常の関数みたいなもんかな。comptimeは他の言語機能を冗長にするから、言語全体がシンプルになるってのがユニークな点だと思う。つまり、シンプルだけど強力な機能があれば、他のいくつかの機能が要らなくなるんだよね。Zigはとてもシンプルな言語なのに、他の複雑な言語と同じくらいの表現力を持ってるってこと。それをローレベルで実現してるのが革命的なんだよね。comptimeを複雑な言語に追加しても、その最大のメリットは得られないと思うな。
細かいことだけど、JavaScriptはシンプルじゃないよ。個人的には、一般的に使われてる言語の中で一番複雑なセマンティクスを持ってると思う。
型の自動変換とか’with’とかの変な部分以外で例を挙げられる？JavaScriptの子孫で後方互換性のないやつを作って整理しようと思ってるんだけど、問題点について聞きたいな。
ぱっと思いつくのは…
・undefinedとnullがある
・変数の宣言方法が3つある
・typeof vs instanceof
・for in vs for of
・thisの挙動
・引数の数が間違った関数を呼び出した時の挙動
まだまだ色々あると思う。
＞扱いやすいってことだけど、Zigのcomptimeの方がマクロよりもエラーを見つけやすい例ってある？
＞他の言語機能を冗長にするってことだけど、IDEとかユーザーは一般的なイディオムを意識する必要があるよね？それなら、コンパイラで実装されてるかcomptimeで実装されてるかって、そんなに重要？
comptimeが冗長にする他の言語機能の例ってなんかある？
例えばジェネリックシステムはcomptimeの上に構築されてるんだ。ジェネリックな構造体は、型を引数として受け取って構造体を返す関数みたいなもん。
fn Vec(comptime T: anytype) {
return struct {
// …
}
}
第一級のジェネリック型パラメータの構文がある方がいいと思うけど、これはOPの主張を示してる。
C++のテンプレートとちょっと構文が違うだけに見える…
いや、ちょっと違うよ。C++ではできないような、あらゆるレベルのデータ型の複雑なものを渡せるんだ（comptimeで有効なものに限るけど）。
fn MyType(T: type, comptime tag: [] u8, comptime count: usize) type {
const capitalized = some_module.capitalize(tag);
return struct{
fn name() []const u8 {
return capitalized;
}
array: [count]T,
};
}
みたいな。
その例はC++のconstevalとテンプレートで簡単に再現できそうじゃん？ちょっとした構文の違いを除けば、基本的には同じって感じ。
C++のconstevalとテンプレートじゃ絶対に無理だよ。C++はリフレクションのサポートが必要だし、10年後には実現するかもしれないけど、現状じゃ不可能。それに、議論のポイントはC++でできるかどうかじゃなくて、Zigの一つの機能が、C++のconsteval、テンプレート、SFINAE、type traitsといった多くの機能を包含してるってこと。バラバラな機能が微妙に違う動きをするんじゃなくて、一つの機能で全部統一できるってわけ。
一般論としてはその通りだけど、C++26でリフレクションの中核部分が導入される予定だよ。それでこれが実現できるかは詳しくないけどね。Rustは…10年後かもね。
crates.ioには色々リフレクションのクレートがあるのは知ってるでしょ？
reflectクレートがもっと進んで欲しかったな。言語サポートが重要だと思ってるけど、色々あって時間がかかりそう。残念。
ジェネリクス、インターフェース/traits/コンセプト、マクロ、条件付きコンパイル、const関数/constexpr。C++やRustでは4つか5つの異なる機能だけど、全部comptimeっていう単純な構成要素で表現できるんだ。
comptimeでジェネリクスの型チェックとか型推論をどうやるの？[1]で提起されてる問題全部に対応できるの？comptimeがジェネリクスのシステムを完全に再現できるなんて、明らかに嘘じゃん。
[1]: https://typesanitizer.com/blog/zig-generics.html
これは問題というより違いって感じかな。根本的な問題として提示されてるものも、実は小さいものが多いと思う。例えばZigがfn foo (comptime T : type, ...){typecheck(T); ...}じゃなくて、fn foo (comptime T : typecheck(T), ...){ ... }みたいな構文を導入したら、ジェネリクスじゃなくてテンプレートって言う？この変更が価値があるかどうかはまだわからないけど、もしそうなら後からでもできるし。この記事のほとんどの”問題”はIDEサポートの問題だと思う。C++のテンプレートよりコンパイルエラーがわかりやすいって認めてるし（もっとわかりやすいと思う）。
Zigの選択が常に優れてるとは思わないけど、ジェネリクス、マクロ、条件付きコンパイル、constexprが必要な場合に、特に魅力的なトレードオフを実現してると思う。Javaみたいな言語では不要だし、Zigスタイルのcomptimeはそこまで言語を単純化しない。C++やAdaの最大の欠点は言語の複雑さだと思う人にとって、Zigは革命的な一歩だよ。これだけシンプルで表現力豊かな低レベル言語はなかったんじゃないかな。
このスレッドの多くの返信が「今はXができないけど、ZigはXを追加できる」って言うのが面白いね。Zigが”今できること”に基づいた議論が見たい。Rustには同じように甘くないのに、Zigはそんなに若い言語じゃないし。PL界隈では、まだ実現してないことを約束するって評判があるよね（例えば、高階関数の存在下でスタックオーバーフローを静的に検出するとか、無理だと思う）。
＞それは僕の主張じゃないよ。
＞Rustに同じように甘くしないのは、Rustの美学的な問題は複雑な機能が多すぎることだから、どうやって甘くすればいいかわからない。機能を追加するのと削除するのには非対称性があるけど、僕がZigに与えてる美学的な”ポイント”は、追加”できる”機能じゃなくて、まだ重要だと示されてない機能を”持ってない”ことに対してだよ。
どんな言語の機能も、何らかの肯定的な価値を追加するために追加されたのは明らかだと思う。でも、全ての機能は言語を複雑にするっていうマイナスの価値も持っていて、全体としてはその言語で書かれるプログラムが少なくなるかもしれない。重要なのは、機能の価値と複雑さのバランスを取ること。Rustの美学を好む人でも、Zigのパワー/シンプルさのバランスへの斬新なアプローチは、近年プログラミング言語設計で見られなかったものだと認めるはず。
ZigでSendみたいなtraitってどう表現するんだろ？ それが必要なら、proof checkerとかが必要になるんじゃない？ Rustが提供してるやつみたいな？ こういうプロジェクトは見たことない？ そういうプロジェクトは見たことあるよ。でも、Zigが今できることに基づいた議論が見たいんだよね。将来的にできることじゃなくて。昔、C++の人もISO C++ Core Guidelinesでmemory safetyを約束してたけど、今は聞かないよね。C++のままじゃ無理だってわかったから。 Rust Nightlyから出る予定だったものの約束はどうなったの？ C++のmetaprogrammingの進化ってマジですごいと思う。 C++のtemplate metaprogrammingって、今でもC++の中の別の言語じゃない？ Zigってどうやってmacrosの前にtypeをresolveするんだ？ Zigにはmacrosはなくて、comptimeに実行できるfunctionがあるんだよ。 補足だけど、Rustにもコンパイル時に実行できる関数があるよ。それはconst fnって呼ばれてて、標準で使えるんだ。crateは要らない。Rustそのもので、マクロみたいに別の構文じゃないんだ。 Rustにはコンパイル時の環境変数があって、const fnで解析できるんだ。コンパイル時にRustのコードを試したり設定したりするのに便利だから、もっと活用されるべきだね。 RustがC++からconstexpr関数をコピーしたのはよくわからないな。constexpr関数はコンパイル時に実行される”かもしれない”だけだし。 Rustでは、浮動小数点数がコンパイル時と実行時で完全に同じになるとは限らないよ。 そこまで悪くはないよ。違いはNaNの表現（符号とペイロードのビット）が安定しているとは限らないってことだけ。NaNの特定の表現に頼ってないなら、const fnでの浮動小数点演算は同じだし、違いが見られたらRustコンパイラのバグってことになる。 コンパイルするシステムと実行するシステムで精度が違う場合はどうなるの？ 例えば、64bitシステムでコンパイルして、FPアクセラレータ付きの32bit組み込みとか、softfloatの16bitシステムをターゲットにする場合とか。 もしRustにZigのcomptime機能があるなら、このcrateは何？ どう違うの？ 何を追加するの？ RustにはZigのcomptime機能はないよ。Rustのconst fnは普通の関数で、コンパイル時に実行できる”だけ”。これは単なる最適化で、ランタイムでも実行できる必要があから、特別な機能はないんだ。 Zigのcomptimeはマクロじゃなくて、ステージングプログラミングだよ。 Zigのcomptimeは、C++のテンプレートを改良したものだね。C++のテンプレートと同じような問題もあるけど。関数がcomptimeかどうかは、comptimeに入れてみて初めてわかるんだ。 このライブラリ試してみたけど、マジで使いやすかったよ。前にbenchmark関数を生成するdeclarative macroを書いたんだけど、マジ苦行だったし、変更を加えるのも不安だったんだよね。でもcrabtime使ったら、マジ快適になった。ほとんどRustコード書くだけだし、めっちゃ見やすいしカスタマイズしやすいんだよね。例えば、新しいモジュール追加するたびに名前渡す必要なくなったし。paste!{}とcrabtime::output!{}の中身見比べたらわかると思うけど、Rustコードで文字列作って{{ str }}でポン置きできるのがマジでかい。paste!{}の方は、マジでどうやったか覚えてないけど、動くまで試行錯誤してたわ。years_and_daysのループも、declarative macroの こういう感謝の言葉ってマジ良いよね。感謝の気持ちだけじゃなくて、共同作業のクリエイティブな過程が垣間見えるし。 最初、eval_macroにそっくりじゃんって思ったけど、名前が変わっただけみたいだね。新しい名前マジ良いね。おめでとう! マジすごい。誰か使ったことある人いる? フィードバックとかあれば聞きたいな。既存のマクロより全然良さそうに見える。 作者が数週間前に前のバージョンを発表して、2日前にこの新しいバージョンを発表したみたい。だからまだユーザーは少ないかもね。declarative macroをcrabtimeで置き換えたけど、declarative macroは自分が書いたはずなのに、どう動いてるか全然わかんなかった。crabtimeにしたら、理解できてメンテできるようになった。crabtimeマジ最高。以前はRustのメタプログラミングとか避けてたけど、これからは状況次第で全然ありだわ。 マジ neatだけど、Zigのcomptimeと同じではないと思うな。Zigの動的な挙動はないし、コンパイル時のリフレクションもないし。RustはZigのcomptimeみたいな動的な特性は持てないし、ZigもRustのコンパイル時の保証は絶対に得られない。動的なケーキを同時にコンパイル時に食べることはできないんだよね。理論的には可能だけど、言語を大幅に変える必要があると思う。 使ったことないけど、マジ良さそうだし役に立ちそう。でもZigのcomptimeとは全然違うと思う。 これマジ良さそう。昨日macro_rulesでコードを簡潔にしようとしたんだけど、macro_rulesじゃ無理だったから全部書いたんだよね。proc macrosはできるだけ避けてる。たくさん書いたことあるけど嫌い。synとかquoteとかproc_macros2とかの依存関係が増えてコンパイル時間が長くなるし。依存関係が増えないか確認してみよう。 proc-macro2、syn、quote、toml、rustc_versionに依存してるみたい。最初の3つは複雑なprocedural macrosなら当然だよね。Tomlとrustc_versionはCargoの設定用みたいで、悪影響はなさそう。transitive dependenciesはunicode-ident（proc-macro2から）、serde、serde_spanned、toml_datetime（tomlから）、semver（rustc_versionから）みたい。 最高に素晴らしい! それってまさに「blursed」って言葉のためにあるようなもんじゃん。 それ、もっと頻繁に使わなきゃ… これクールだけど、プロジェクトのコンパイル時間にどう影響するんだろ？同じ引数でマクロを何度も呼び出す場合のキャッシュについて書いてあるけど、生成されたプロジェクトの作成、コンパイル、実行にかかるおおよその時間があると嬉しいな。 Rustのマクロの問題は、コンピューターへのフルアクセス権があるってことだよね。これって文字通り、悪用を招いてるようなもんじゃん。Rustがもっと普及したら、この脆弱性を利用した攻撃が出てくると思う。 もっとヤバいのは、テキストエディタで開くだけで(lspがあるとして)pwnされる可能性があるってこと。Rustだけじゃないけどね。多くのエディタは、知らないリポジトリを開くときはダウングレードモードで起動すると思う。 さらにヤバいのは、敵対的なgitリポジトリのチェックアウトでディレクトリに移動するだけでも、シェルがgit情報(どのブランチにいるかなど)を表示する場合、任意のコードが実行される可能性があるってこと。 他の言語にはこれに対するセキュリティモデルってあるの？どんな言語でも、任意のコードをビルドすれば何かしら実行されると思ってた。 Cマクロとgccはコンパイル中に任意のコードを実行することはできないよ。 Cの標準は相変わらず融通が利くね。 実際、Cのビルドシステムは全部そうしてるよね。 wasmでマクロをサンドボックス化するランタイムはもうあるよ。https://github.com/dtolnay/watt つまり、セキュリティを最初から用意するんじゃなくて、webブラウザ言語にコンパイルしたり、設定ファイルをいじったりするハックが必要ってこと？ これはデモンストレーションだよ。wasmは“言語”というよりポータブルなISAでしょ。段階的に構築するのは当然じゃない？ Procマクロはそうだけど、宣言的マクロは違うよ。 このページ以外に例ってある？理解に苦しんでるんだよね。 正直、crates.ioのページよりこの長いドキュメントの方が参考になると思うよ。 単純にコードをコピペするだけなら、一番簡単な従来の 実は、まさに君が求めてることをするコマンドがあるんだ。「expand macro」だよ。Crabtimeも同じような機能があるって言ってるね。 こっちのリンクの方がいいかもね。 マクロってコード全体をgrepしにくくならない？Semantic grepで解決できそうだけど、マクロのユースケースって聞いたことないな。 だからマクロで新しいstruct作るの基本避けてるんだよね。エラーライブラリのsnafuが個人的に嫌いな理由もそれ。定義へのジャンプとかコード検索ができなくなるのはマジ勘弁。proc macroでメソッド追加するくらいならまだマシだけど、定義が隠された型を使うのはマジ無理。 Snafuはrust-analyzerの定義ジャンプは少なくとも問題ないよ（参照ジャンプは確かに壊れるけど）。 問題はマクロじゃなくて、識別子の連結でしょ。CSSプリプロセッサでよくあるやつ。 ＞問題はマクロじゃなくて、識別子の連結でしょ。” 普通のサブルーチン呼ぶより？ crabtimeのreadmeのコード例がgrepしにくい例だよね。例えば マジで理解できないんだけど、comptimeって何がいいの？マクロはわかるけど、crabtimeって何が改善されるの？proc macrosの代わりに普通のRustコードを書けるってこと？ Zigのcomptimeとは全然違うよ。 いやいや、これ全然Zigのコンパイル時計算じゃないって。Zigのコンパイル時計算はマジで別次元ですごいんだから。もっとコメントを表示（1）
https://doc.rust-lang.org/std/marker/trait.Send.html
スレッドをspawnするときとかに、値が安全に別のスレッドに移動できることを保証するやつ。
https://doc.rust-lang.org/std/thread/fn.spawn.html
Zigはmemory safeじゃないから無理だよね。
https://github.com/ityonemo/clr
色々出てきてるよね。なぜかZigの人がRustのものを欲しがって、Rustの人がZigのものを欲しがるんだよね。
Zigに関しては、1.0になるのが遅すぎるからまだ早いって言う人がいるよね。機能開発はもう終わったって言うの？何が言いたいの？
C++98の時はtemplateのハックだったけど、C++23ではかなり使いやすくなったし、compile time reflectionでさらに良くなる。
Rust macrosみたいに別の言語を学ぶ必要もないし、3rd party crates (syn)に頼る必要もないし。
syntaxとかlogicとか、普通のC++と全然違うじゃん。
評価順序がマジでヤバい気がするんだけど。
どういう仕組みなの？
macrosのlayerが複数あるの？
levelを宣言する必要があるの？
どうやってmacrosでtypeを定義したり、変数のtypeを宣言したりするの？
そのtypeを別のmacrosで使えるの？
typeを返すfunctionを作って、別のfunctionから呼べる。
宣言は最初に使われた時にしか解析されないし、comptimeに呼ばれたfunctionはその引数に基づいてmemo化される。
評価順序はマジでシンプルで予測可能。
ただ、Zigのcomptimeの完全な代わりにはならないかな。ある意味、Zigより制限が多いし、良いか悪いかは別として、Zigより高い目標を持ってる。
const fnはコンパイル時か実行時に動く必要があって、常に同じ結果を出す必要があるんだ。これは結構大変で、コンパイル環境と実行環境が違うクロスコンパイルだと特にね。
副作用も禁止だから、Rustのconst fnは純粋関数って言われてるよ。
C++は結局constevalとconstinitを追加することになったんだ。これらは本当にコンパイル時専用だよ。
Zigのcomptime関数はコンパイル時”だけ”に実行されるから、特別なことができるんだ。特に、型を操作するとかね。ランタイムで実行する必要がある関数ではできないことだよ。
＞https://typesanitizer.com/blog/zig-generics.htmlもっとコメントを表示（2）
($($year:ident {$($day:ident),+ $(,)?}),+ $(,)?)より、crabtimeのfor (year, day) in years_and_daysの方が読みやすいし。crabtimeマジ最高。前まではRustのメタプログラミングとか避けてたけど、これからは状況次第で全然ありだわ。
全角の＞以下の方々の貢献に心から感謝します。
全角の＞timonv – このクレートの素晴らしい名前を発見し提案してくれたことに感謝します。
全角の＞Polanas – テスト、設計、そしてプロジェクトを大幅に改善する洞察力に富んだフィードバックという貴重な支援に感謝します。
全角の＞あなたのサポートと貢献は、このクレートをより良くするために重要な役割を果たしました—ありがとうございます!”make myfile.mk -> pwned
マジそれなー。めっちゃ思うわー。でも、ビルドスクリプトがある環境ならどこでもコンピューターぶっ壊せるよね。できる限り暗号化するしかないけど、ソフトウェアエンジニアリングってセキュリティ的に超危険な仕事だよね。
OpenBSDのpledge syscallみたいなのをコンパイラで使うと便利かも。システム上の何にアクセスできるかをプロセスレベルで制御できるから。
＞https://feross.org/gcc-ownage/
＞“gccをハックする方法が書いてあるよ”もっとコメントを表示（3）
でも、役に立つことを教えてくれてありがとう。
https://internals.rust-lang.org/t/pre-rfc-sandboxed-determin…
今メタプログラミングに興味があって、Vec3 SIMDタイプを構築してるところ。f32::Vec3x8とかf64::Vec3x16とか、似たようなバリアントをたくさん管理する必要があるんだ。これって従来の
マクロ、手続き型マクロ、または“code gen”（コードの文字列操作だと思う）で処理できる？Crabtimeを代わりに使える？使うべき？
https://docs.rs/crabtime/latest/crabtime/
＞ This could be handled using traditional macros, procedural macros, or something called “code gen”, which I think is string manipulation of code. Could I use crabtime to do this instead? Should I?
＞できるみたいだよ。Crabtimeは手続き型マクロと“code gen”の両方に対応してるみたい。
マクロから始めるのがいいかも。どんな方法を選んでも、コードは読みにくくなると思うけどね（IDEに“生成されたコードを表示”ボタンが欲しいよね）。
https://docs.rs/crabtime/1.1.1/crabtime/
.user {
&–profile { color: red; }
}
みたいな。
こうなると、user–profileってCSSクラスを探すのが不可能になる。SASSとかは人気だけどね。フロントエンド開発者には期待してないから別にいいけど。識別子を壊さなければ検索できるはず。でもIDEの補完とかは無理かもね。
それも問題だよね。MySQLCursorDict Classとかも。コード全体で全てのテーブルのカラム名をgrepしないといけなくなる。Position1ってのを見つけて、定義場所を知りたいとするじゃん？でもenum Position1なんてないんだよね。識別子が連結されてるから。IDEの機能も使えない。定義にジャンプできないとか。
