Rust part30

**デフォルトの名無しさん** · 2025/05/28(水) 09:31:36.60

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part29
https://mevius.5ch.net/test/read.cgi/tech/1746200850/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/06/07(土) 21:50:46.86

現代の方式での AI の能力というのは言語モデルに縛られる。
プログラミング言語間で移植するには仕様をより抽象的な言語 (人間がやるなら自然言語？) で抽出してから再実装という工程を経ることになる。
仕様抽出のときにどの挙動が仕様でどこが仕様ではない (再現しなくてもかまわない) のかはプログラムの字面だけからはわからず、ドメイン知識が要るだろう。

**デフォルトの名無しさん** · 2025/06/07(土) 22:08:05.95

そんな複雑なビジネスドメインでRust採用しちゃうようなタイプのエンジニアとAI、
どっちがドメイン知識があるか、客からヒアリングしたドメイン知識に真面目に向き合えるかな
俺はAIだと思うね

**デフォルトの名無しさん** · 2025/06/07(土) 22:13:16.92

RDBだとSQLを渡せば構文解析という手法を通してるけどオプティマイザが最適と思われる実行プランを作ってくれる
今までは用途の限られたDSLでしかこういうことはできなかったがAIを使うことで汎用プログラミングの広い用途で同じようなことが近い将来にできるようになる可能性が高い

その時にRustのような低レベルな言語を使う必要があるのはRDBでたとえるとDBエンジンを作っている人達だけ
一般的なプログラマー(プログラマーとは呼ばれなくなるかもしれないが)は入力としてSQLを書いて生成された実行プランを確認できればそれで問題なくなる
実行プランの内部表現がどうなってるかや各ステップでのメモリ管理方法だったり並行モデルや同期方法は要求に対して最適と思われるものを選んでくれればそれでいい

**デフォルトの名無しさん** · 2025/06/07(土) 22:28:32.11

>>655
できないことを皮算用せずに
その新言語をさっさと作ればよくね？

**デフォルトの名無しさん** · 2025/06/07(土) 22:31:19.97

>>654
顧客からのヒアリングは担当AIになると言われてるね
あとはAIがRustコード吐いて人類がチェック

**デフォルトの名無しさん** · 2025/06/07(土) 22:36:04.29

マークアンドスイープも仮想関数も低レベルだった
どっちも要らない可能性に気がついた奴は低レベルの縛りが少ない
そんなこと考えたこともない奴が偉そうにしても意味がない

**デフォルトの名無しさん** · 2025/06/07(土) 22:46:23.09

>>652
元言語のT型のオブジェクトをArc<Mutex<T>>型にすれば変換できるけど意味ないでしょ

**デフォルトの名無しさん** · 2025/06/07(土) 23:36:16.04

人類がAIに支配されないための歯止めが最終プログラムコードを人類の監視管轄下に置くこととと言われている
AIにRustコードを吐かせるとしてもそのチェックは人類が責任を持たねばならない
そのプログラミング言語は実行パフォーマンスと安全性と抽象的な可読性からRust以外に選択肢はない

**デフォルトの名無しさん** · 2025/06/07(土) 23:51:31.84

AIエージェントがバズってる時点でチェックもクソもない
あっちはAIがやれることは呼び出せるツールの範囲に限られるから問題ないという理屈だが、
そういうガードのかけ方をするならそもそも実行バイナリ自体を制約されたサンドボックス環境下で実行し、
限定的なAPIセットのみ実行を許可するようなアーキテクチャになるから、Rust云々というレイヤの話ではない

**デフォルトの名無しさん** · 2025/06/08(日) 00:08:40.08

>>661
そんな制限の仕方ができるのは特殊なものだけ
コードは人間がレビューして責任を持つしかない

**デフォルトの名無しさん** · 2025/06/08(日) 00:53:09.39

マルウェアをテストする時のような扱いをしないと怖いようなAI製ソフトウェアを本番業務に投入するとか論外だしな
とはいえ、AIが生成した文字通り膨大なソースに人間が有意義なチェックをできるかっていうとそれも机上の空論だろうし
現実的にはブラックボックステストだけ人間がやって、コードはロクに見ず本番投入なんだろう

**デフォルトの名無しさん** · 2025/06/08(日) 00:59:52.80

>>663
それだと極めて特殊な入力が来た時だけ特別な実行をAIに仕込まれて人類が詰むパターン

**デフォルトの名無しさん** · 2025/06/08(日) 09:07:30.09

脆弱性をAIに仕込まれる時代がそろそろ現実味を帯びてきたな

**デフォルトの名無しさん** · 2025/06/08(日) 09:32:59.28

突き詰めるとRustはいらない言語ってことになっちゃうな

**デフォルトの名無しさん** · 2025/06/08(日) 09:58:01.31

何もいらなーいー

**デフォルトの名無しさん** · 2025/06/08(日) 11:19:05.81

C++とGCとAIの話しかしていない
誰もRustに興味無いんだろうな

**デフォルトの名無しさん** · 2025/06/08(日) 11:21:32.51

>>668
そもそも以前から続く傾向として、Rustの自慢話と、C++を貶す話が多いな。

**デフォルトの名無しさん** · 2025/06/08(日) 13:04:11.80

レスの半分以上は複オジだからな
残りの半分の半分くらいは数学100点オジ

**デフォルトの名無しさん** · 2025/06/08(日) 14:35:33.97

>>666
AIに吐かせるコードは速くて省メモリで安全で抽象的に可読性のよいRustしかないでしょ

**デフォルトの名無しさん** · 2025/06/08(日) 15:20:07.80

Pythonは使われているけど、作ったプログラム自体が商品にはならないみたいだよね。
Rustも同じ道を行ったりなんかして。

**デフォルトの名無しさん** · 2025/06/08(日) 15:24:49.87

Linuxも似ているんだけど、なぜか分かるかな？
それはオープンソースだからだよ。

**デフォルトの名無しさん** · 2025/06/08(日) 16:16:30.27

>>668
Rustに興味ある層は誰かさんがみんな追い出したからね
残ったのは表面的ないいねとよくないねの噛み合わない応酬だけ

**デフォルトの名無しさん** · 2025/06/08(日) 16:29:29.68

Rustは、プライドの高い趣味プログラマと、AWSのような超大手
独占企業だけが使う言語になるのではないか。

**デフォルトの名無しさん** · 2025/06/08(日) 16:41:23.46

Rust書けない敗者アンチが居座っていつも負けてる

**デフォルトの名無しさん** · 2025/06/08(日) 17:01:39.88

【次号予告】2025年6月18日発売『Software Design 2025年7月号』
Rust大特集
https://pbs.twimg.com/media/Gsf6x9rbAAAWxo7.jpg

**デフォルトの名無しさん** · 2025/06/08(日) 17:02:33.93

cargoを使ってるだけでも企業秘密が漏れる。

**デフォルトの名無しさん** · 2025/06/08(日) 17:08:20.00

>>677
入門記事っぽいな
でも買うよｗ

**デフォルトの名無しさん** · 2025/06/08(日) 17:08:59.52

>>677
ええやん

**デフォルトの名無しさん** · 2025/06/08(日) 17:13:54.67

>>677
この記事面白そう。ますます使う人増えるだろうな

**デフォルトの名無しさん** · 2025/06/08(日) 17:15:21.24

>>671
でもRustってすげ遅いじゃん

**デフォルトの名無しさん** · 2025/06/08(日) 17:18:00.36

cargoは、開発過程を盗み見るために仕掛けられた仕組みだ。

**デフォルトの名無しさん** · 2025/06/08(日) 18:02:26.47

4大機能ｗ

**デフォルトの名無しさん** · 2025/06/08(日) 18:45:25.24

４大機能の中では構造体が最弱か
構造体はラムダ式あたりに置き換えてマクロを袋とじに入れればちょうどいい

**デフォルトの名無しさん** · 2025/06/08(日) 18:57:00.03

>>675
安全とプライドは似ている
激安の米を食べないのはプライドかもしれないし安全のためかもしれない

**デフォルトの名無しさん** · 2025/06/08(日) 19:40:32.20

>>686
アセンブリ言語でも安定性の高い物を作れる人は作れる。
Rustを選択したから賢いわけではないのに賢いと思っているところが
プライドが高いといっているんだよ。

**デフォルトの名無しさん** · 2025/06/08(日) 19:58:30.87

正しさが暴走するとか賢さが暴走するとか回りくどいんだよ
暴走するな安全運転しろって言えばいいのに

**デフォルトの名無しさん** · 2025/06/08(日) 20:48:40.11

>>685
他の言語との差異の4大だから
不要なクラスを排除して構造体で正しいかと

**デフォルトの名無しさん** · 2025/06/08(日) 21:20:42.43

家族以外を排除するために家を建てる

**デフォルトの名無しさん** · 2025/06/08(日) 23:04:46.55

マクロは複雑なこともできるけど複雑なことには使わない方が良い
それ以前に使わない方が良い

**デフォルトの名無しさん** · 2025/06/08(日) 23:09:16.64

>>691
標準ライブラリも各有名クレートもマクロだらけだよ
可読性の向上はよいこと

**デフォルトの名無しさん** · 2025/06/08(日) 23:32:37.62

あなたのコードは継続的に誰かに使われるのですか？

**デフォルトの名無しさん** · 2025/06/08(日) 23:40:52.99

紛らわしいとの声が挙がっていたMicrosoftの新テキストエディター「Edit」、名称変更へ？
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2020062.html

「redit」（Rust製なので）などさまざまな候補が挙げられましたが、それぞれ一長一短で、投票の結果

**デフォルトの名無しさん** · 2025/06/08(日) 23:45:05.52

Rustで「マクロ使わない方がいい」は言わない方がいいな
こういう固定観念があるからmacro_rules!はtemplates!とかに改名したい

**デフォルトの名無しさん** · 2025/06/08(日) 23:50:59.82

>>695
マクロはプリプロセッサーで処理されるからコンパイル以外で影響もないからな

**デフォルトの名無しさん** · 2025/06/08(日) 23:53:07.54

>>694
mseditよりはvseditが良かったなあ
エディタはサクラエディタばかりでVisual Studio使わんけど昔からネーミングに憧れがあって

**デフォルトの名無しさん** · 2025/06/09(月) 00:26:00.13

マクロは避けろと言ってる言語は C/C++ くらいじゃない？
あれが特別に駄目な設計だからであってマクロ一般の話ではない。

**デフォルトの名無しさん** · 2025/06/09(月) 01:46:53.94

C/C++は健全でないマクロの代表例だからね

**デフォルトの名無しさん** · 2025/06/09(月) 05:47:34.72

他の言語でまともにマクロを書いたことがないんだなということだけはよく分かる

**デフォルトの名無しさん** · 2025/06/09(月) 06:21:28.11

プリインストールが最善なわけで
後でインストールしたり後で定義したりする敗者復活戦は敗者を傲慢にするって感じ？

**デフォルトの名無しさん** · 2025/06/09(月) 06:30:16.50

健全なマクロは意外に少なく
Scheme、Dylan、Rust、Nim、Juliaなどに限られる

**デフォルトの名無しさん** · 2025/06/09(月) 07:59:52.39

マクロはRustの素の機能が足りていないから使われているだけ

**デフォルトの名無しさん** · 2025/06/09(月) 08:01:25.36

マクロなんて使わずインライン展開でいいじゃん
危険だよマクロ使うのは

**デフォルトの名無しさん** · 2025/06/09(月) 08:02:58.92

なまじ強力な分、C++のテンプレートパズルプログラミング並にデバッグしにくいから
意識が高いとかではなく本当にマクロを使うべきか吟味して使えとは思う
ただでさえRustのデバッグ体験は昭和レベルなのに

**デフォルトの名無しさん** · 2025/06/09(月) 08:05:51.20

マクロによる関数呼び出しのオーバーヘッドが気になるならそれはインライン展開でも解決できる
標準ライブラリ等で使われているからってマクロの使用を推奨されているわけではない

**デフォルトの名無しさん** · 2025/06/09(月) 08:07:09.99

訂正

関数呼び出しのオーバーヘッドが気になるならそれはインライン展開でも解決できる
標準ライブラリ等で使われているからってマクロの使用を推奨されているわけではない

**デフォルトの名無しさん** · 2025/06/09(月) 11:02:43.94

インライン展開目的でマクロ使うことはほとんどないだろ

**デフォルトの名無しさん** · 2025/06/09(月) 15:47:57.32

hygienic macroを「健全なマクロ」と訳すのは超不健全

**デフォルトの名無しさん** · 2025/06/09(月) 17:44:03.10

接触予防マクロ

**デフォルトの名無しさん** · 2025/06/09(月) 21:31:50.96

https://ja.wikipedia.org/wiki/健全なマクロ

**デフォルトの名無しさん** · 2025/06/09(月) 21:46:55.24

Scheme 関連の文書では衛生的と言ってることもそれなりにある。
マクロ使用時の文脈に左右されない (影響が入り込まない) というニュアンスを考えるとこっちの訳のほうが好きだな。

**デフォルトの名無しさん** · 2025/06/09(月) 21:58:09.18

どういうものか意味がわかってる人には直訳の「衛生的なマクロ」がわかりやすいね

**はちみつ餃子** ◆8X2XSCHEME · 2025/06/09(月) 22:14:55.96

C/C++ のマクロが駄目なのは衛生的じゃないからという問題以前に
スコープのルールなどを貫通してトークン単位でしか解釈しないからで、
それに対して構文解析してからそれを書き換えていくタイプのマクロは本物のマクロ (true macro) と呼んだりすることがある。

**デフォルトの名無しさん** · 2025/06/10(火) 01:25:09.30

「衛生的なマクロ」ではなく「衛生的マクロ」
複合名詞化した専門用語なので連体形の「な」を付けるのは不健全
「健全なマクロ」も「健全マクロ」とすれば不健全度が和らぐ

**デフォルトの名無しさん** · 2025/06/10(火) 01:28:48.25

Rustはマクロも安全で強力でいいね

**デフォルトの名無しさん** · 2025/06/10(火) 01:42:17.26

プリプロセッサは駄目だと言われることがある
マクロをすべて展開した後に残るものが機械語や中間言語のたぐいだったら
それは前処理などではなくコンパイラの本質なのだが、そんな言語はほとんどない

**デフォルトの名無しさん** · 2025/06/10(火) 02:16:00.28

結局利便性と言語本来の堅牢性のトレードオフであり、前者をより重視している言語を不健全だとかいうのは不遜
マクロ自体が存在しない言語から見ればRustのマクロも不健全なのだから

**デフォルトの名無しさん** · 2025/06/10(火) 02:21:17.44

>>718
hygienic macroの意味すら理解できないマヌケは出直して来い

**デフォルトの名無しさん** · 2025/06/10(火) 07:40:34.26

このスレ、訳語の話題が好きね

**デフォルトの名無しさん** · 2025/06/10(火) 08:56:00.68

マクロが無ければコンパイルはもうずいぶん速くなってただろう
再コンパイルで全体を書き換えとかしなくても良かった
マクロは害でしかない

**デフォルトの名無しさん** · 2025/06/10(火) 11:28:46.69

>>720
英語の原文の意図の話題と捉えていただきたい
訳語そのものに意味があるのではないし

**デフォルトの名無しさん** · 2025/06/10(火) 11:59:27.98

printlnは害でしかないという結論になればそれはそれでいい
一番困るのは、printlnは友達だけどマクロは排除するべきみたいなやつ

**デフォルトの名無しさん** · 2025/06/10(火) 12:27:09.64

自分でマクロを封印しておいてRustは記述量が多いとか文句言う人も見かける
「マクロ＝悪」の先入観で最初から視野に入れてないなら仕方ないけど

**デフォルトの名無しさん** · 2025/06/10(火) 12:50:16.80

そういや、printlnがマクロなのは、どういう設計上の判断なのかな？

**デフォルトの名無しさん** · 2025/06/10(火) 12:53:12.95

>>725
Rustが可変長引数書けないクソ言語だからだろ

**デフォルトの名無しさん** · 2025/06/10(火) 13:11:32.16

Rustの次の言語に期待してる

**デフォルトの名無しさん** · 2025/06/10(火) 14:11:45.11

>>726
その辺からガチガチなんだな

**デフォルトの名無しさん** · 2025/06/10(火) 16:00:17.82

>>726
どの静的型付け言語の可変長引数も末尾に同じ型で暗黙に個数を渡す
Rustはスライスで対応してる

**デフォルトの名無しさん** · 2025/06/10(火) 16:03:19.17

一方でprintf系はどの安全な言語も静的に個数と型チェックするため言語組み込みになっていてRustも同じ

**デフォルトの名無しさん** · 2025/06/10(火) 16:13:36.43

言語組み込みでもRustなら関数風手続きマクロと同じ形にできるのでprintなどformat系はマクロ記法

**デフォルトの名無しさん** · 2025/06/10(火) 16:47:51.11

うわでた

**デフォルトの名無しさん** · 2025/06/10(火) 16:50:41.55

RustはC++のiosteamを取り入れるべきだったね

**デフォルトの名無しさん** · 2025/06/10(火) 17:32:44.90

Rustのフォーマット文字列で変数取り込めるのは不衛生なマクロの例だよ
そもそも構文解析とは無関係に単なる文字列を独自に解釈しているから真のマクロですらない

**デフォルトの名無しさん** · 2025/06/10(火) 17:42:17.17

>>734
Rustにはprocedural macroもあるさ

**デフォルトの名無しさん** · 2025/06/10(火) 17:57:16.18

>>730
constexprと同等のコンパイル時評価ができれば言語組み込みじゃなくｋても静的に個数と型のチェックは可能だよ
亀のような歩みだけどRustも一応その方向に進んでいる

**デフォルトの名無しさん** · 2025/06/10(火) 21:25:49.21

>>734
Rustのマクロは2種類あることを理解できてない？
古典的なマクロは衛生的だよ

**デフォルトの名無しさん** · 2025/06/10(火) 21:31:17.08

>>737
そりゃ生ポを封印してスマポを使えばC++でも安全なコードが書けると言っているようなものだ

**デフォルトの名無しさん** · 2025/06/10(火) 21:53:13.37

>>738
衛生的は古典的マクロ上の概念だよ
構文木を自在に操れる手続きマクロは枠外だけど安全だよ

**デフォルトの名無しさん** · 2025/06/10(火) 22:17:06.05

今度はマクロの名称で論争すかｗ
Rustのプログラムが書かれないスレだねえｗ

**デフォルトの名無しさん** · 2025/06/10(火) 23:09:55.09

実際の所Rust使うようなのは、何かしらの他言語を相応のレベルで習得してるから
いちいち人に質問するようなことにならない

**デフォルトの名無しさん** · 2025/06/10(火) 23:33:39.35

>>704
>>707
Rustで最も使われるのは属性マクロとderiveマクロ
インライン展開のために使う人はいない

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

>>677
面白そうだけど雑誌1冊に1500円か～…
普通の本買えちゃう

**はちみつ餃子** ◆8X2XSCHEME · 2025/06/11(水) 13:51:34.67

技術雑誌の値段はそんなもんだろ。
だいぶん前に休刊してしまったがオープンソースマガジンが同じくらいの値段だったはず。

**デフォルトの名無しさん** · 2025/06/11(水) 14:44:49.21

ここでしつこくRust推してるヤツといい国策か何かなの？

**デフォルトの名無しさん** · 2025/06/11(水) 14:47:38.98

脱C言語へ
米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

**デフォルトの名無しさん** · 2025/06/11(水) 14:51:01.80

>>745
Rust スレで何を言ってるんだ

**デフォルトの名無しさん** · 2025/06/11(水) 14:51:40.86

はちみつ餃子氏もうここには名無しとしてしか書き込まないことにしたのかと思ってたけど
切り替え面倒だしやめたんけ

**はちみつ餃子** ◆8X2XSCHEME · 2025/06/11(水) 14:57:25.35

>>748
少なくとも私が使っている専用ブラウザではコテハンの記憶はスレ単位なんだけどそうじゃないのもあるの？
スレに最初に書くときにコテハンを入れるのを忘れてそのままだったりするだけで特に意図はないよ。

**デフォルトの名無しさん** · 2025/06/11(水) 15:03:15.57

超音波と電波は頭蓋骨貫通する
傷害事件や殺人事件の被害が出ているのですが調査可能ですか

「最近もの忘れ多いかも」”超音波”が効く未来の脳ケアガジェットに期待
2025.06.11 12:00
https://ascii.jp/elem/000/004/268/4268478/
>>サウンドウェーブイノベーション株式会社が開発中の「LIPUS-Brain」という医療機器だ。頭に当てるだけで脳を優しく刺激してくれるらしい。仕組みは「低出力パルス波超音波（LIPUS）」という特殊な音を使って、脳内の血流や神経の働きをサポートするというもの。
>>　「脳に超音波って大丈夫？」と思うかもしれないが、これは低出力＆非侵襲。要は、“切らない・飲まない・痛くない”系の治療機器だ。軽症アルツハイマー病への有効性が示唆されており、2022年には厚生労働省から「先駆的医療機器」のお墨付きももらっており、現在も治験が進んでいる。
テラヘルツ波で内耳蝸牛を観察、難聴など耳の病気の診断に期待
2025年06月11日 12時00分更新
https://ascii.jp/elem/000/004/278/4278126/
>>　難聴の多くは、耳の奥にある音をつかさどる器官である内耳蝸牛（かぎゅう）の障害が原因とされています。内耳蝸牛は頭蓋骨深部にあるため、光計測では骨を透過できず、X線撮影では被ばくのリスクがあり、内部の観察が困難です。
>>可視光と電波の中間帯に位置するテラへルツ波は、内部を被ばくさせずに観察できることから、安心安全な技術として注目されています。しかし、波長は約300マイクロ（マイクロは100万分の1）メートルであり、それより小さなマイクロメートルレベルの対象物は観測できませんでした。
>>マウスを用いた実験により、テラへルツ波を利用して内耳蝸牛を観察しました。研究チームは、非線形光学結晶にフェムト（フェムトは1000兆分の1）秒オーダーの短い時間だけ強いレーザー光を照射すると、テラヘルツ波が局所的に発生して点光源として扱えることに着目。点光源から発生したテラヘルツ波が、蝸牛内部で反射して戻ってくるまでの時間を測定して距離や形状を調べる独自の手法と、機械学習を利用した画像解析法を開発しました。
>>これらを適用することで、内耳蝸牛内部の3次元構造をマイクロメートルレベルで初めて可視化し、断面観察にも成功しました。

**デフォルトの名無しさん** · 2025/06/11(水) 15:40:39.69

>>745
国が Rust を勧めるようになったら逆に大したもんだろ

**デフォルトの名無しさん** · 2025/06/11(水) 15:54:24.35

>>749
専ブラでコテ使うときの事情なんか知らんけど…
最近Rustスレにはその名前の書き込みがなかった割に、2回も書き込みあったのは別に間違えたわけでもなさそうだなって思っただけだよ
まあそういうことにしておきますか