Rust part28

**デフォルトの名無しさん** · 2025/03/24(月) 17:37:00.15

公式
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 part27
https://mevius.5ch.net/test/read.cgi/tech/1733146370/

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

**デフォルトの名無しさん** · 2025/04/15(火) 10:42:57.35

hoge.map(Ordering::reverse)

**デフォルトの名無しさん** · 2025/04/15(火) 10:51:02.82

>>459
反転はreverseすればいいとして
普通にcondition.cmp(0)したほうがいい

事情があってOption化したいとしても
cmpできる場合とそうでない場合の2つに分岐させる

**デフォルトの名無しさん** · 2025/04/15(火) 11:01:31.96

【脳科学】「政治行動の激しさ」に関連する脳回路の存在が研究で判明 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1744637408/

上記のリンクをたどったリンク先の本文とコメントを読まれると・・・
余裕ありますか・・・
大々的にインターネット上にばらまかれました！

**デフォルトの名無しさん** · 2025/04/15(火) 17:11:35.23

PartialOrdを実装してるようには見えんよな

**デフォルトの名無しさん** · 2025/04/15(火) 21:09:18.10

XY問題っぽいけど本人がいいなら別にいいんじゃね

**デフォルトの名無しさん** · 2025/04/15(火) 23:20:57.63

>>459
それらi32やi64はOrd境界を満たしている
そしてOrdにはsupertrateとしてのトレイト境界PartialOrdがある
まずそのifの4分岐を使わずともx.partial_cmp(&0)でOption<Ordering>を得ることができる
ただしOrdも満たす整数型では常にSomeとなりNoneになることはない

一方でf64などの浮動小数点は!Ordなのでpartial_cmpでNoneが返りうる
自分でstruct Pair(i32, i32)を作り二つのi32のcmpが同じ時のみpartial_cmpをSomeにする型等も同様にNoneが返りうる
そのためにPartialOrdとOrd(: PartialOrd)の二段階に分かれている

今回のi32型やi64型はOrdも実装されているためNoneが返ることは絶対にない
したがって今回はx.cmp(&0)でOrderingを返すのが正しい

**デフォルトの名無しさん** · 2025/04/16(水) 00:32:42.55

>それらi32やi64はOrd境界を満たしている
トレイト制約とトレイト実装の区別ができてないやつをちょくちょく見かけるけどあれ境界本の影響だったのか

**デフォルトの名無しさん** · 2025/04/16(水) 00:40:00.05

ある型がXxx境界を満たすこと＝その型がXxxを実装していること、だから正しいよね

**デフォルトの名無しさん** · 2025/04/16(水) 09:39:47.23

境界を満たすことって表現が気持ち悪い
日本語的じゃない

区域に含まれるようでいてそういう話でもない

**デフォルトの名無しさん** · 2025/04/16(水) 10:00:02.42

>>468
英語的にも自然ではない。でも Rust 用語ではこう言うことになっている。
テクニカルタームってのはそういうもんなので自然かどうかを論じるのは無意味。

**デフォルトの名無しさん** · 2025/04/16(水) 11:16:05.15

明らかに間違った言葉を使っていても”テクニカルタームってそういうもんなので”で済ませるメンタリティの持ち主が誤訳を生み出して広めるってことだな

役に立つ誤訳ならいいけど>>465からも分かるように境界は足を引っ張る誤訳だから早く止めるに越したことはない

**デフォルトの名無しさん** · 2025/04/16(水) 11:28:23.19

traitボヨヨ～ンでいいよ。

**デフォルトの名無しさん** · 2025/04/16(水) 11:30:24.19

普通にC#/TypeScript/Kotlinあたりで採用されているconstraint: 制約でよかったと思うけどね
Rustは変な選民意識が足を引っ張っている

**デフォルトの名無しさん** · 2025/04/16(水) 11:33:26.57

Cの置き換え言語に高尚な意識は要らん

**デフォルトの名無しさん** · 2025/04/16(水) 11:34:30.78

組込みやってる人達と接点は持ったほうがいいね

**デフォルトの名無しさん** · 2025/04/16(水) 12:15:29.62

くだらない議論する労力あるならとっととthe rust book 最新版を翻訳して用語統一しろよ。

**デフォルトの名無しさん** · 2025/04/16(水) 12:22:24.48

プログラムという単語自体がもうおかしいからな
そこに目を瞑ってる時点で同じ穴の狢よ

**デフォルトの名無しさん** · 2025/04/16(水) 12:41:52.97

>>460
Option<Ordering> に .map(Ordering::reverse) ってゼロコストなんか
可読性がどうでも良いなら
>>459 でそのまま -condition した方が速いんじゃね

**デフォルトの名無しさん** · 2025/04/16(水) 12:48:16.89

>>469
>英語的にも自然ではない。
CPU boundsとか聞いたことないの？

**デフォルトの名無しさん** · 2025/04/16(水) 15:44:17.59

意識高い系プログラミング言語界隈はbindを多用しすぎていて曖昧になってしまっているのは問題
ネイティブにとってクールで知的な語感なのか知らんがどんだけ束縛プレイ好きなんだよ

**デフォルトの名無しさん** · 2025/04/16(水) 16:00:15.57

緊縛緊縛

**デフォルトの名無しさん** · 2025/04/16(水) 18:39:21.33

AとBの境界を満たすって意味がもうすでに訳が分からないので気持ち悪い

**デフォルトの名無しさん** · 2025/04/16(水) 19:25:04.78

上界下界

**デフォルトの名無しさん** · 2025/04/16(水) 19:28:02.69

AとBの条件を満たすならわかる
AとBの境界を満たすのは意味不明

Aの境界を満たすですら意味不明

**デフォルトの名無しさん** · 2025/04/16(水) 19:31:37.92

簡単な概念に難しい言葉使いすぎ。共和党党員でも理解出来るdealみたいな簡単な単語にする
computerとかラテン語っぽいのは嫌われちゃうぞ

**デフォルトの名無しさん** · 2025/04/16(水) 21:14:58.28

テクニカルタームってのは「その分野に固有の定義がある語」なので日常用語の意味で解釈されないようにしなきゃならないんだよ。
その分野を学んだことがない初心者でも自然に読めてしまうのは用語の選定が失敗した証だとも言える。
法律用語の「悪意」「ないし」あたりは日常用語とは明瞭に意味が異なるのに日常用語としても解釈できてしまうので良くない例だ。
その一方では全く由来のないデタラメに作り出した語は単純に言いにくいし覚えにくい。
境界と言うかわりにププイータとかフニャコソとか言ったって (それで統一されるなら) 辻褄は合うが、さすがにそれはあんまりというものだろう。
そういう微妙な機微を踏まえて選定するものなんだよ。

**デフォルトの名無しさん** · 2025/04/16(水) 21:17:18.07

ボヨヨ～ン一択

**デフォルトの名無しさん** · 2025/04/16(水) 21:24:19.59

>>477
それは最適化されるので大丈夫
「-condition」を使ってはいけない
これはi32::MIN時にoverflowする
したがってそのif文で書くならばGREATERとLESSを入れ替えるか
「condition > 0」と「condition < 0」を入れ替えることになる

しかしOrderingについて「if文で多分岐させる」こと自体がいけない
可読性に劣るとともにケアレスミスも起きうるだけでなく
生成コードを見ると以下の正解よりも少し長くなりえて遅くなりうることがわかる

正解はこれ
普通のまま: condition.partial_cmp(&0)
逆にする時: condition.partial_cmp(&0).map(|x| x.reverse())
逆にする時: condition.partial_cmp(&0).map(Ordering::reverse) 【上記と同じ】
いずれも生成コードがそのif文より短くなりうる
そして可読性も優れている

ただしconditionにi32やi64の整数型を使うとpartial_cmp()がNoneになることはない
Option<Ordering>を使う必要はなくcmp()でOrderingを得れば十分
真の正解はこれ
普通のまま: condition.cmp(&0)
逆にする時: condition.cmp(&0).reverse()

**デフォルトの名無しさん** · 2025/04/16(水) 22:12:59.22

てすと

**デフォルトの名無しさん** · 2025/04/16(水) 23:55:34.09

Rustでの抽象化したコードの方が可読性の良さだけでなく速いんだよな
様々な抽象化したコードの連鎖もRustでの最適化と下請けのLLVMでの最適化のおかげで速くなってる

**デフォルトの名無しさん** · 2025/04/17(木) 00:27:01.07

エイリアス解析は最適化の重要な要素だから参照関係を明瞭に追える Rust は有利。

**デフォルトの名無しさん** · 2025/04/17(木) 06:01:08.25

Rustはオワコン

**デフォルトの名無しさん** · 2025/04/17(木) 11:32:45.05

>>485
bind (bound, boundary, 等々)なんて、特に固有の定義を持たない雰囲気ワードの最たるものだろう
なんとなくオシャレだからというだけで乱用されすぎてもはや意味不明

**デフォルトの名無しさん** · 2025/04/17(木) 11:47:53.19

>>477
反転するコストがあるんだからゼロコストではない
でも反転前の値が既にある前提なら.map(Ordering::reverse)より速くするのは無理
conditionから新規に反転した値を取得したいのなら当たり前だけど.map(Ordering::reverse)を使わないほうが速い
(ただし>>459の実装ではなくstdと同じ実装を使わないと最適化の度合いで差が出る)

**デフォルトの名無しさん** · 2025/04/17(木) 12:04:31.60

これは嘘です
その場合でも.map(Ordering::reverse)が一番速いです

>>493
>>conditionから新規に反転した値を取得したいのなら当たり前だけど.map(Ordering::reverse)を使わないほうが速い

**デフォルトの名無しさん** · 2025/04/17(木) 12:20:41.10

ところがRustならゼロコストなんだなあ

**デフォルトの名無しさん** · 2025/04/17(木) 13:46:18.29

ユースケース説明してくれないのに速いとかなんとか言っても不毛だし境界の話に戻ろうぜ！

**デフォルトの名無しさん** · 2025/04/17(木) 14:21:55.09

>>487
論理的に反転したいときにreverseって一般的なのかな
negateの方がふさわしいと思うが

**デフォルトの名無しさん** · 2025/04/17(木) 15:59:50.14

【AI】OpenAIが「GPT 4.1」のAPIを公開、100万トークン対応と実用性能で飛躍的進化を遂げた次世代AIモデル [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1744724723/

上記のリンク先のコメントを読んでもまだ医者の威厳を保てるのか？

**デフォルトの名無しさん** · 2025/04/17(木) 18:53:03.37

>>459
それと全く同じ動作をする関数fはこれが速さも簡潔さもベスト

fn f(condition: i64) -> Option<Ordering> {
　condition.partial_cmp(&0)
}

Less/Greaterを反転させた関数f_revはこれが速さも簡潔さもベスト

fn f_rev(condition: i64) -> Option<Ordering> {
　0.partial_cmp(&condition)
}

アセンブリ手書きでもこれらの生成コードより速くできないことをx86-64で確認した

**デフォルトの名無しさん** · 2025/04/17(木) 19:35:44.38

>>497
Rustではサイドエフェクトが無いことを保証できるので
どちらでも同じコードに落ちます

**デフォルトの名無しさん** · 2025/04/17(木) 19:48:15.83

>>497
論理反転ではないからreverseだと思う
論理反転ならlt⇔ge　gt⇔le　eq⇔neだろうけど
Orderingはlt,eq,gtの3種
そしてOrdering::reverseはlt⇔gtだから

**デフォルトの名無しさん** · 2025/04/17(木) 22:47:28.82

結局RustではC風に書くより抽象的に書いた方が、
可読性が良いだけでなく実行速度でも有利なんだな。

**デフォルトの名無しさん** · 2025/04/17(木) 22:49:00.49

>>499
でも>>494は
condition.partial_cmp(&0).map(Ordering::reverse)のほうが
0.partial_cmp(&condition)より速いって言ってるけどどっちが本当？

**デフォルトの名無しさん** · 2025/04/17(木) 23:42:56.97

simple is best

**デフォルトの名無しさん** · 2025/04/17(木) 23:59:58.22

この本の帯すき

https://i.imgur.com/gVFQctS.png

**デフォルトの名無しさん** · 2025/04/18(金) 06:24:24.51

なんでビルドのときからﾎﾞｺﾎﾞｺﾎﾞｺﾎﾞｺDLさせるの?

なんでアクセスさせようとするの?

**デフォルトの名無しさん** · 2025/04/18(金) 07:02:30.53

他の言語も同じ

**デフォルトの名無しさん** · 2025/04/18(金) 07:04:06.26

>>506
標準ライブラリだけ使っていればDLしないよ
他のライブラリを使うなら自動的に依存関係がDLされるのは当たり前
もちろん事前にDLしておけばオフラインでも cargo build －－offline できるよ

**デフォルトの名無しさん** · 2025/04/18(金) 07:57:54.21

>>505
ScalaやHaskellとかと同じ道を歩んでるな

**デフォルトの名無しさん** · 2025/04/18(金) 08:25:24.05

>>509
それらはRustのように速く動くわけではなく
Wasm上でもランタイムによるバイナリサイズ大きくてメリットが何もない

**デフォルトの名無しさん** · 2025/04/18(金) 09:03:11.60

>>503
わざわざ人に聞かなくてもわかるでしょ
某オジのレスはほぼフェイクと思っておくくらいで丁度いい

**デフォルトの名無しさん** · 2025/04/18(金) 09:55:44.96

.partial_cmp(&0) ってダサくない？
なんで
.partial_cmp(0) に出来ないの？

**デフォルトの名無しさん** · 2025/04/18(金) 10:28:07.41

0と比較した結果をOrderingで返す関数とか無用の長物じゃね？

**デフォルトの名無しさん** · 2025/04/18(金) 10:32:03.94

確かに >>499 は無駄そのもの

**デフォルトの名無しさん** · 2025/04/18(金) 10:47:04.28

>>512
出来ない

**デフォルトの名無しさん** · 2025/04/18(金) 10:47:35.98

>>514
話の流れを理解できてなさそうだな
if文で4分岐する関数を作るのはコードが見にくく実行も遅くなる可能性があって無駄だから素直にpartial_cmp()を使おうって話だろ

**デフォルトの名無しさん** · 2025/04/18(金) 11:56:29.53

>>494も>>499も複オジだった件w
この嘘吐きおじさんの振る舞いはいくらなんでも酷すぎるだろ

**デフォルトの名無しさん** · 2025/04/18(金) 12:06:41.66

>>512
初心者っぽいから説明すると
大きな構造体や文字列やBigIntなど含めた様々なデータを比較する関数だよ
参照を渡す方が良いことを理解できるよね？
もちろん数値の場合はコード上は他のデータと同じく参照を渡していても最適化で参照を使わずに数値同士が比較されるから心配しなくていい

**デフォルトの名無しさん** · 2025/04/18(金) 12:21:49.30

gpt o3がバックエンドはRustがオススメです。
みたいに推してくるから、理由を聞いたら、「何にでも雑に強い」からだって開き直りよった

**デフォルトの名無しさん** · 2025/04/18(金) 12:25:55.76

可読性ですね判ります

**デフォルトの名無しさん** · 2025/04/18(金) 12:29:26.06

政治を嫌うやつがほしがるのは共感でも最適解でもなく、政治的ではないことが保証された解だな
だから乱数や賭博を嫌いになれないのか

**デフォルトの名無しさん** · 2025/04/18(金) 20:38:04.94

Rustで書くとLLVMが最適化するので事実上最速のコードであることが保証されます

**デフォルトの名無しさん** · 2025/04/18(金) 21:32:44.78

単に競争を回避するだけならできなくはないと思うが
政治家の競争と民間企業？の競争を区別するのは無理ゲーだ

**デフォルトの名無しさん** · 2025/04/18(金) 21:55:39.18

>>514
それコンパイルしたらSETccとCMOVcc使って最短最速の分岐していて無駄ないよ

**デフォルトの名無しさん** · 2025/04/19(土) 04:04:16.66

【2025年最新】自然な声の音声読み上げソフト5選！AI技術で ...
https://ondoku3.com/ja/post/natural-voice-software/
※無料で５０００文字まで音声合成エンジンで読み上げ可能
※音声合成エンジンは人間の声のサンプルから声質が作成されている
「Grok」が過去の会話を覚え続けるようになった--ChatGPTに追従　オフにする方法は？
2025年04月18日 05時20
http://japan.cnet.com/article/35231959/
>>「ChatGPT」やGoogleの「Gemini」も同様の記憶機能を導入している。これらのサービスも、長期的な会話履歴を保持し、ユーザーに合わせた回答が可能となっている。
※GrokはChatGPTで規制されていることも返答するようになっている
統合失調症の幻聴で半分人間半分AIと申されていた
統合失調症の幻聴で宇宙人とも話されていたのでかなり昔からできていたと思われる
※対象者【統合失調症】の考えに対しては何を考えているかは対象者【統合失調症】に聞いてみないことには意味不明⒮

**デフォルトの名無しさん** · 2025/04/19(土) 21:57:19.62

>>524
それRustのOption<Ordering>が速い理由がわかったわ
Orderingが8bitであることに加えてOption<Ordering>も8bitに抑えてる
しかもOrderingとSome(Ordering)が同じ8bit表現になるようにしている
それらにより8bitしか変化させてくれないsetCC命令をゼロ拡張や事前ゼロクリア無しに使えるわけだ

**デフォルトの名無しさん** · 2025/04/19(土) 22:46:36.80

Option が特別扱いなわけではなく、全般に空いているビットに詰め込む仕組みがあるのでいろんなところで効いてくる

**デフォルトの名無しさん** · 2025/04/19(土) 22:55:31.71

Option持たない言語や持っていても使われない言語は別途bool値などで表すしかないためOptionのような対応処理ができずに不利だね

**デフォルトの名無しさん** · 2025/04/19(土) 23:14:20.43

詰め込む分だけ取り出すコストが生じる場合もあって、どちらが良いとは一概には言えないんだけど Rust は上手くやれてるみたいだね。

**デフォルトの名無しさん** · 2025/04/19(土) 23:27:11.24

Optionを持たない流派とかどうでもいい
相性に依存したくないし

**デフォルトの名無しさん** · 2025/04/20(日) 02:35:00.94

Some(Equal)
どちらが良いとも言えない

None
どうでもいい

**デフォルトの名無しさん** · 2025/04/20(日) 08:28:25.78

ぬるぽ

**デフォルトの名無しさん** · 2025/04/20(日) 10:53:41.23

今どきの言語だと大体は string? みたいな記法はあるし
unwrap_or や map, and_then に相当する操作も普通にできるから、 optional は実はあまり困らない
(演算子で書けるぶん、こちらのほうが記述も簡潔)

Resultは無いから、欲しい場面は結構ある

**デフォルトの名無しさん** · 2025/04/20(日) 11:10:13.02

HaskellはリストやOption (Maybe), Tree などをモナドという構造として抽象化できると考えた
これは理論的な美しさはあるけど、実用的にはエラーハンドリングのための専用の構文があつた方が多くの場面で便利

Optionに限れば、C#やTS, Kotlin などにもそういうものがある
Resultも含めるとRustの?演算子はバランスがいいと思う
(これを monadic bind と説明せず、エラーの場合の早期リターンとして説明してる点も含めて)

**デフォルトの名無しさん** · 2025/04/20(日) 12:25:33.06

構造ってのはコタツから出なくても向こうから勝手に押しかけてくる
たとえばCではOOPができないって言って、本当のOOP探しをする必要は全くない
それと同じ

**デフォルトの名無しさん** · 2025/04/20(日) 12:55:01.09

錆みたいな名前なんとかならなかったのかね
システムに使うには縁起が良くない

**デフォルトの名無しさん** · 2025/04/20(日) 13:52:39.43

とりあえず占い師をクビにして、祟りが起きたらその時に考える
これが効率化だ

**デフォルトの名無しさん** · 2025/04/20(日) 14:06:28.40

名前の由来もちゃんとあるから調べたらいい

**デフォルトの名無しさん** · 2025/04/20(日) 14:07:44.47

枯れたものでシステム作ろうとするくせに生意気な
お似合いの名前の由来じゃん

**デフォルトの名無しさん** · 2025/04/20(日) 14:13:49.78

糖分多め

**デフォルトの名無しさん** · 2025/04/20(日) 15:51:30.56

・さび菌よる多くの病害はさび病と呼ばれ、農業・林業において重大な病害を含む
・サビの進行度によっては、チェーンリング強度低下、チェーン張力の低下、チェーン断裂のリスクなどの可能性がある

草

**デフォルトの名無しさん** · 2025/04/20(日) 15:53:22.75

鉄は表面だけ錆びさせることで破壊が起きるような深い錆びを起こさないように出来るのだ

**デフォルトの名無しさん** · 2025/04/20(日) 16:27:55.26

このスレに巣食っている信者が喧伝しているような「メモリ安全でコンパイルが通れば
バグがないことが保障される」信頼性が高い言語だから名前はTrustだ!とドヤ顔で言い切る
自信が開発者にはなかったんだろうな。

**デフォルトの名無しさん** · 2025/04/20(日) 16:32:59.12

開発当初にそこまで自信ないだろ
1人で作り出したのでしょ

**デフォルトの名無しさん** · 2025/04/20(日) 16:35:34.71

ロジックのバグは開発者の責任だからね
あとCよりマシと言う所が抜けてる
Cの地獄はやったものしかわからないだろ、あれから比べたら劇的に楽に違いない

**デフォルトの名無しさん** · 2025/04/20(日) 16:38:39.63

フレームワーク上でビジネスロジックしか組んでないアプリレベルの開発者には無用の長物なんだよ。
業界的にはアプリレベル開発者が80%だろうし、違いの分かり恩恵がある開発者は20%だからね

**デフォルトの名無しさん** · 2025/04/20(日) 17:07:39.21

このスレの今盛り上がってるこのお題

プログラミングのお題スレ Part22
https://mevius.5ch.net/test/read.cgi/tech/1691038333/712

Rustだと桁違いに速く解けるみたいだけど
これは言語の差なの？

**デフォルトの名無しさん** · 2025/04/20(日) 17:59:03.47

ハードウェアを固定して言語を色々変えるなら
ハードの差には絶対にならない

**デフォルトの名無しさん** · 2025/04/20(日) 20:56:57.67

>>547
見たけど言語の差ではない。モダンな言語であればほぼ同様の記述が可能。
この手の小さなアルゴリズム実装程度の課題ではRustの面倒臭い面が表に出ることはない

**デフォルトの名無しさん** · 2025/04/20(日) 22:09:40.01

課題を変えたら課題の差が計測されてしまう
既に、良い課題と悪い課題があるみたいな空気になりかけている

**デフォルトの名無しさん** · 2025/04/20(日) 22:12:48.98

>>549
他の言語で速いプログラムが出てこないのはなぜなのかなと思って

**デフォルトの名無しさん** · 2025/04/20(日) 22:45:33.70

速度に固執してる奴がたまたまRust信者だっただけだな
まだアルゴリズムの改善でオーダーが変わっている段階であり、細かい最適化とかの次元ではない
遅くない言語であれば十分

**デフォルトの名無しさん** · 2025/04/20(日) 22:51:31.25

clangでも同じにできるよね
どちらもLLVM

**デフォルトの名無しさん** · 2025/04/20(日) 22:53:22.13

rustが本当に速かったらもっと普及したと思う

**デフォルトの名無しさん** · 2025/04/20(日) 22:57:10.24

CやFORTRANより速くはならんからな

**デフォルトの名無しさん** · 2025/04/20(日) 23:05:02.71

こういうミクロなベンチマークは速度を追求すると最終的には拡張命令等によるハードウェア依存の最適化に行き着くから、Rustに勝ち目はない
一応Rustコンパイラを使い続けながら最速に到達することは可能かもしれないが、もはやRustとは呼べない何かになる

**デフォルトの名無しさん** · 2025/04/20(日) 23:16:39.25

インラインでsseして頑張ろう

**デフォルトの名無しさん** · 2025/04/20(日) 23:24:22.62

>>555
Rustは同じ速さにできる

>>556
CPU依存でいいならRustはインラインアセンブラに対応していてRustの変数をそのまま渡すことができるためそのクリティカルな部分以外をそのままRustで記述できるRustは有利

**デフォルトの名無しさん** · 2025/04/20(日) 23:37:04.43

知ってる知ってる