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/04(水) 23:51:21.99

>>541
「という事で」の意味が分からんけど対応されたら何か困るらしい
WM_ENTERSIZEMOVE消すだけだと破壊的だからfork限定でPRは出せんけどね

**デフォルトの名無しさん** · 2025/06/04(水) 23:54:26.85

>>542
マスクは経営サイドなんだから当然だろ。
自分でコードを書いているのならともかく。

**デフォルトの名無しさん** · 2025/06/04(水) 23:57:54.43

>>543
>WM_ENTERSIZEMOVE消すだけだと破壊的だから

分かってるなら、自分でテストしないのか疑問だ

**デフォルトの名無しさん** · 2025/06/04(水) 23:59:22.16

各社どこでも新しいシステムはRustで作る時代になったね

**デフォルトの名無しさん** · 2025/06/05(木) 00:18:01.72

>>545
画面移動させたりサイズ変更した時にフォーカスが復元されなくなるだけだからな
それが原因でIMEが挙動不審になるなら切ってもいいと思うけど
その挙動が無くなったら困る人もいるんじゃね？くらいは破壊的
まじめに対応するならWM_ENTERSIZEMOVEでMoveFocusを呼ぶ条件を分岐する

**デフォルトの名無しさん** · 2025/06/05(木) 05:52:19.18

>>543,547
気が向いたら再現手順に落とし込むけど
>>529を適用したら見栄えが悪い状態が発生した
https://i.imgur.com/2nqirNQ.png
https://i.imgur.com/RLQ0UCR.png

(確定状態の文字に)未確定状態の点線がついてる

**デフォルトの名無しさん** · 2025/06/05(木) 08:11:45.26

IT土方用の言語としては最適だよな

**デフォルトの名無しさん** · 2025/06/05(木) 08:57:28.49

Rustは無能判別機だからね
unsafe無しでコンパイルできる時点で価値のある人間だと分かる

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

> 当初はJavaVM上のKotlinで開発されたものの、バグの混入を避けるためなどの理由でメモリ安全なRust言語での開発に切り替えたところ、それだけで性能が約10倍向上した
https://www.publickey1.jp/blog/25/awspostgresqldbamazon_aurora_dsql.html

> CもC++も知らないエンジニアにRustを学ばせてパフォーマンスを考えずにとりあえず書かせたRust実装は、長年パフォーマンスチューニングをしてきたKotlin実装より速かった。

**デフォルトの名無しさん** · 2025/06/05(木) 12:34:43.00

「無能判別器」とかRust信者らしい物言いだよなぁ。
Linuxの時もそうだった。Linuxの良さが分からないのは無能だとか、馬鹿だとか、
そんなんばっかだった。

**デフォルトの名無しさん** · 2025/06/05(木) 12:36:14.00

OSSが理解できないのは「古い」とかなんとか。
でもそう言ってる人の年齢は60歳超えてるとか。そんなことが多かった。

**デフォルトの名無しさん** · 2025/06/05(木) 12:41:30.48

>>551
Kotlinも結局GC言語だから限界があり遅いのは仕方ないかと

**デフォルトの名無しさん** · 2025/06/05(木) 12:50:06.51

>>551
新人のひよっこコードに負けるなんて屈辱だっただろうな

**デフォルトの名無しさん** · 2025/06/05(木) 12:53:34.45

>>551
そういう真面目に改善に取り組んでいる企業や分野では全てRustへ置き換えられていくのだろうね

**デフォルトの名無しさん** · 2025/06/05(木) 16:05:58.05

Rust化が進むと聞くだけで不安感や不快感を感じる人も居るぞ。

**デフォルトの名無しさん** · 2025/06/05(木) 16:31:04.08

Rustは安心感と速さの両立にプログラミングのしやすさが快適

**デフォルトの名無しさん** · 2025/06/05(木) 16:51:58.44

Rust化が進んだことと数値化が進んでいないことのギャップが不快なんじゃないか
良いことや悪いことをした瞬間にただちに報酬や罰が与えられることはない
時間差がある

**デフォルトの名無しさん** · 2025/06/05(木) 18:39:37.18

>>559
そもそも日本企業は「社会主義的」だから、何をやっても報酬は変わらず、
どんなに良い事をやっても給料が上がることはない。
あなたが何をしたかではなく、最終的に商品が売れればボーナスが僅かに上がる。

**デフォルトの名無しさん** · 2025/06/05(木) 18:56:11.37

RustってWEBアプリのバックエンドでも使われることあるの？

**デフォルトの名無しさん** · 2025/06/05(木) 19:09:12.79

>>561
そこは他の言語と比べて最もRustが適している分野

**デフォルトの名無しさん** · 2025/06/05(木) 19:43:22.97

>>561
クラウドは使ったリソース (CPU時間やメモリ) に対して課金されるのでユーザから見た速度になんの差もない場合でも Rust だと有利になりえることから選択されることがある。
ただ、小規模なサービスだと無駄にリソースを使って金を払ったほうがマシということもあるので場合による。

**デフォルトの名無しさん** · 2025/06/05(木) 20:21:52.92

Rustを使えない人は高いリソースコストを負担
Rustを学んで使えば有利になる

**デフォルトの名無しさん** · 2025/06/05(木) 22:08:00.36

別にそれだけならC++でもいいわけだが。

**デフォルトの名無しさん** · 2025/06/05(木) 22:24:45.12

俺は一番得意なPetlで書くことが昔より減ってきた
お前らも同じような感じなの

**デフォルトの名無しさん** · 2025/06/05(木) 22:30:17.30

>>565
残念ながらC++は大量の非同期タスクをマルチコアで回す基盤やその上のWeb処理など不便すぎて無理

**デフォルトの名無しさん** · 2025/06/05(木) 23:49:02.97

それらの基盤ライブラリが整っていて使いやすくクライアントを大量に捌けるRustが一番有利だね

**デフォルトの名無しさん** · 2025/06/06(金) 09:25:11.44

>>566
Petlであってる？ Perl の事かな？

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

>>567
それは言語ではなくライブラリで解決できそうだね。

**デフォルトの名無しさん** · 2025/06/06(金) 11:26:05.53

リソースコストよりRustエンジニアを集める人件費の方が高くつく

複おじは経営者でもないのにリソースコストだとか語ってる惨めなおっさん

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

Rustで一番コストがかかるのはライブラリ周りなんだって

そこそこ優秀なエンジニアを集めたければ単価的なものはRustだろうとJavaだろうとGoだろうと大してかわらん
単価をとにかく安くして人海戦術でプロジェクト回してるような生粋の土方はRustとか使わんからな

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

外部ライブラリを考慮しなければ生産性は大きくても2〜3倍の悪化で済むからJVM言語のように常にヒープアロケーションする言語と比べれば処理内容によっては10倍くらいの性能差は普通に出るのでペイできると勘違いしやすい

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

>>570
C++はそのライブラリが弱い
Rustで開発されるようになった理由はライブラリが充実しているため

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

充実は違うな
C/C++の方が圧倒的に充実しているが、せっかくあってもそれを利用するのが難しい
Rustが流行った大きな要因はビルドやパッケージマネージャがcargoで統一されてること

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

>>575
C/C++は大量の非同期タスクをマルチコアで回したりその上のWeb処理などまともなライブラリ群がない

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

>>576
ある
でも知らないだろ？そこがRustとの大きな違い

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

>>577
C/C++はまともなものがない
Rustは充実していて使いやすい
この差が決定的となった

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

Web開発でRust笑

**デフォルトの名無しさん** · 2025/06/06(金) 13:06:50.86

>>579
Rustは昔からWeb分野が最大コミュニティ
https://image.itmedia.co.jp/ait/articles/2006/01/l_ait_200601_rust3_h500.jpg

**デフォルトの名無しさん** · 2025/06/06(金) 14:29:45.68

むしろ Rust はウェブ以外の分野での躍進が思ったほどではないと解釈すべきなのかもしれない。

**デフォルトの名無しさん** · 2025/06/06(金) 16:32:47.31

>>574
>大量の非同期タスクをマルチコアで回す
シングルスレッドで書いたほうが楽だし、C++は速いのでそれで十分なことの方が多いから。

**デフォルトの名無しさん** · 2025/06/06(金) 17:14:08.28

>>582
無知アホすぎてこのスレ出入り禁止

**デフォルトの名無しさん** · 2025/06/06(金) 17:23:29.23

Rustは現実的じゃないって事だな。

**デフォルトの名無しさん** · 2025/06/06(金) 17:25:16.55

C++なりPythonなりを一通りやったあと、
不満があってRustを始めた奴が多いから
他言語ニワカはすぐバレるんよな

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

>>582
それは大昔の方法
今はRustやGoのように非同期タスクをCPUスレッド個数分の上で最大限効率的に回す

**デフォルトの名無しさん** · 2025/06/06(金) 17:43:30.86

C++ も Python も必要なものはある。
けど楽にやれるかっていうとそうでもないところがしんどい。

**デフォルトの名無しさん** · 2025/06/06(金) 17:54:58.69

>>586
C++でも出来るようになっているが。

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

>>586
特殊な処理以外はシングルスレッドで十分だし、逆にシングルスレッドで高速で
無ければGUIのレスポンスは遅くなる。

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

>>588
C++にはRustやGoのような非同期タスクM:Nスケジューラがない
その上の各種ライブラリもない

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

>>589
CPUのマルチスレッド数を活かせないのは今どき論外だよ
Webのサーバもブラウザも

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

>>590
もし本当に無いなら作ればいい。そんなに難しいわけじゃないはずだ。

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

>>591
プログラムの下手さをコア数の多さで誤魔化している例が多そうだが。

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

C++はモダンな非同期に出遅れた
使い勝手も悪いまま他の言語と比較にならん

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

>>594
非同期こそがJavaScriptが嫌われる理由であるといわれているが。

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

>>592
各階層を非同期でライブラリ作り上げて普及させないと誰も使ってくれない

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

>>595
Rust含めて主要言語すべてモダンな非同期に対応して利便性とパフォを両立させている

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

>>597
>利便性とパフォを両立させている
ダウト

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

一部のOSがシングルタスクだった時代に
throwとcatchの方がexitよりも便利そうだとか、そもそもunix系ならexitで問題ないと
言われたんだろうな
現在はLinuxの良さが多少分かりにくくなった
C++の意味も分かりにくい

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

>>598
AWSやCloudflareなどもRustの非同期プラットフォームtokioの上に構築しているよ

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

>>600
ほら、また、データセンターだ。バックエンドだ。

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

C++の並行プログラミングはfuture(async-await)よりもアクターモデルが主流だね
Rustでも最高のスループットを追求するならアクターが有利だけど、Web上がりには取っ付きにくいから安易にfutureが選ばれがち

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

>>599
C++は時代遅れで不要だけど
今もLinuxの上にRustで構築されてるよ

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

>>602
C++で高性能が作れるものなら作ったら？
各社の新システムはRust futureモデルを採用しているから

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

Actixはアクターモデルだよ。複おじが知ってるわけないか

**デフォルトの名無しさん** · 2025/06/06(金) 19:15:06.63

ActixはRustのfutureの上に作られている
この分野はFuture/Promiseモデルが勝利した

**デフォルトの名無しさん** · 2025/06/06(金) 19:21:48.66

みんなよく見とけ。Rustは、他でもなくこういうようなニーズにぴったりな言語だという事だよ。

**デフォルトの名無しさん** · 2025/06/06(金) 20:23:58.53

実際みんな何がC++を捨てるきっかけだったん？
俺はMSVCのモジュール対応がいつまでたっても微妙なこと

**デフォルトの名無しさん** · 2025/06/06(金) 20:31:21.71

actixとaxumで迷ってる
現時点のパフォーマンスならactixだとは思うんだけど
axumが追い上げてるよね

**デフォルトの名無しさん** · 2025/06/06(金) 20:39:58.07

>>608
捨ててない。
選択肢が増えた。

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

>>609
設計の中身見ればactix一択。よく作り込んである

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

#[no_mangle]
pub extern "C" fn call_from_c() {}

**デフォルトの名無しさん** · 2025/06/06(金) 22:47:40.65

無料で配り出してからVisualStudioの評判が下がったかもしれない。
無料で配ると価値が分かってない人が入ってきてしまうことで、
顧客の忠誠心が下がったりクレームが多くなったり、ブランド低下に繋がると言われている。

**デフォルトの名無しさん** · 2025/06/06(金) 22:50:14.29

商品は高い価格をつけていると、よく吟味してから購入されるので
納得して買ったユーザーが多いため、クレームも少ない。
逆に安くしてしまうと、ニーズに合ってないのに買う人が現れるため、
文句ばっかり言うようになってしまう。それがC++に対しての現状の
評判低下に繋がったのかも。
になっているのかも知れない。

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

VisualStudioは、C++とC#を分けて買うことが出来ないことも C++の人気低下に繋がったのだろう。
C#を目的でVSをインストールした人は、C++を試しに使っても悪い印象しか持たないだろう。
そもそも顧客ターゲットが違うのだから。その結果、C++の悪い評判が広まってしまったのではないか。

**デフォルトの名無しさん** · 2025/06/06(金) 23:28:33.90

>>611
もちろんそうなんだけど
axumの方が今後伸びそうな気がしてるんよ
githubのstarももうすぐ並ぶ
仕様からして採用しやすいと思う
仮に今後パフォーマンスで並んだら完全にシェア奪われると思う

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

同感

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

マイクロソフトにとって VisualStudio の評判は重要ではないと思う。
ソフトウェアの販売よりもサービスで稼ぐスタイルに移行していて、この方針の中では開発ツールの一部を無料にしてでも開発者コミュニティを活発にするのは利がある。

C++ の世間の評価が低いとは思わない。
使われないものなら悪い評判すら出ないから、そういう評判があるのだとしたらユーザ数は間違いなく多い。
どんな評価であれ、なんだかんだで使ってるんだよ。

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

ここはRust専用スレだよ

**デフォルトの名無しさん** · 2025/06/06(金) 23:43:40.46

actixって、1回作者がタダ働きしないことに誹謗中傷や罵倒を繰り返す乞食連中にブチギレてクローズしちゃったよね
今は平気な体制なのかな？

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

>>616
多少性能を犠牲にしても安心感をとる => axum
多少安心感を犠牲にしても性能をとる => actix-web

俺はaxumのほうがtokio傘下で大口スポンサー付きなので安心だと思ってる
パフォーマンスはsafe縛りなので並ぶことは無いんじゃないかな

actix-webは大口ユーザーが出てこないとまだ心配
脆弱性対応とかも数は少なくてもこれからも出てくるだろうし

**デフォルトの名無しさん** · 2025/06/06(金) 23:57:17.71

axumは本流の安心感が大きいね

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

C++のムーブとRustのムーブは根本的に異なる
C++では失敗しemplace_backなどが別途必要となった

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

早くRustで仕事できる優秀な人で溢れて、単価安い世界になって欲しい。そうすれば楽ができるはず。

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

AI以下の人材は要らなくなるけどな
コーディングはAIの領域になっていくから

**デフォルトの名無しさん** · 2025/06/07(土) 09:42:27.95

n=1よりも邪悪なのはn=0
統計学者にはそれが分からんのです

**デフォルトの名無しさん** · 2025/06/07(土) 11:15:27.05

AIファーストでいうと、Rustは素材が少ないからただの補完でもパッとしないし
本当にAI時代になると膨大な学習資産があるCのほうが優れた言語として扱われそう
脆弱性は人間より優れているAIならそもそも踏まないし

**デフォルトの名無しさん** · 2025/06/07(土) 11:32:51.12

>>627
ディープラーニングは大量の学習元データを必要とするけれどある程度を越えると性能の伸びは急激に鈍化する。
つまり際限なく多くのデータを投入すれば良いというわけではないし、学習データとして使うには充分な分量はあるよ。

**デフォルトの名無しさん** · 2025/06/07(土) 11:49:58.62

プログラミング言語ってのは機械にも読めるようにした人間が読み書きするための言語
書く部分を代理してもらったところで人間が読まなきゃいけないことには変わりない

AIが賢くなっていけばいくほど人間が理解しやすい読みやすい言語へシフトしていく
アセンブリが学習資産として膨大にあるからといって人間用にアセンブリを生成させてその抽象度でコードを管理したりしない

もちろん人間用に生成するのはCやRustじゃなくても全然いいからRustも過渡期の言語

**デフォルトの名無しさん** · 2025/06/07(土) 12:45:57.58

>>627
Cの言語仕様ではAIがどんなに賢くても静的に安全性を保証できないよ
AIに吐かせるならRust

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

>>629
現存する言語でデータ競合まで安全を保証して抽象的で可読性のいいRustが使われるね

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

>>629
とはいうものの、プログラミング言語が自然言語で書かれるようなことにはならず
検証のために何らかの論理的整合性を保った記法で書かれる必要があるし
それを読んで理解できるセンスを持った人はある程度は限られるので
プログラミング言語の読みやすさという点では、あまり現状と変わることはないんじゃないかな
人間の方が進化すれば別だけど

ただ、Rustが保証するメモリ管理については、AIが後から適切な箇所に解放処理を挿入してくれるようになって、
GCを使っていないがGC言語のようにコードを書けるようになる、ということはあるかもしれない

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

>>632
最後のその仕組みがRustだよ
AIですら静的に解決できる情報が必須でそれがRust

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

それは明らかに誤り
現に極めて高い精度で適切なタイミングでリソースを解放するRustコードをAIは生成できているのだから、
AIが前提であればそのような情報は省略可能であることは自明

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

>>634
それは静的に解決できるRustの言語仕様のおかげで様々な安全性が保証される
人間もAIも立場は同じ

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

複おじに構うつもりはないのだけど、AIはRustの言語仕様を理解しているのだから、
例えばRustの仕様に基づいた暗黙的なメモリ解放が行われるコードをAIが生成した場合、それはAIが明示的に制御して解放しているのと変わらないとも考えられるよね
632の言うように、GC言語がフェイルセーフとしてGCは使いつつも殆どの場合において適切に確定的なタイミングでメモリ解放するようになったら、
Web系みたいに多少ファジーでもいい分野は完全に持っていかれるかもね

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

>>636
架空の言語？既存の言語？
Rustの肝はその言語仕様にあるから既存の言語には無理だよ

**デフォルトの名無しさん** · 2025/06/07(土) 15:58:12.17

>>633
rustは、メモリ管理を人に強制してるじゃん。>>632の言いたいことは、違うと思うけれどな。

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

>>638
その「適切な箇所に解放処理を挿入してくれる」はRustやC++の仕様で実現されてる
他の言語には無理

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

言語仕様を既に理解している者にRustは何も強制しない
逆に言えば強制とは理性のない物体を操る技術とか、それを人間にも当てはめるしぐさのこと

**デフォルトの名無しさん** · 2025/06/07(土) 18:53:43.86

究極の理想系は Python みたいな軽い言語で雑に書いて、それを AI が最大限効率的なコードに変換するようなものだろうな
ヒープ不要な変数はスタックに、他と共有しないデータは変数のスコープと共に破棄されるように、共有されるデータはArcに、循環参照してるものは寿命の短い方を判断して weakref に、というふうに

現在はまだ無理だからGCレスが必要な場面にRustを使うけど、 &T や Arc<Mutex<T>> みたいな型はメモリ管理のためでしかないし、AIが自動的にうまく変換してくれるならその方が進化だと思う

**デフォルトの名無しさん** · 2025/06/07(土) 19:02:14.18

>>641
Rust以外の既存の言語の仕様でそれは不可能