Rust part30

[1 デフォルトの名無しさん 2025/05/28(水) 09:31:36.60 ID:ciITeZ5D]

公式
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/

[2 デフォルトの名無しさん 2025/05/28(水) 10:58:58.89 ID:6w3mqYSW]

糞スレ終了

[3 デフォルトの名無しさん 2025/05/28(水) 12:43:14.56 ID:S0ZbDXHw]

RustでC#なみに簡単にGUIが作れる未来は何年後に来ますか？

[4 デフォルトの名無しさん 2025/05/28(水) 12:54:25.58 ID:3diyko22]

>>3
C#より簡単
Rustで人気GUI crateトップegui
https://www.egui.rs/#demo

[5 デフォルトの名無しさん 2025/05/28(水) 13:47:42.84 ID:V3p2RWJM]

C#だからって言って、GUIの作りやすさが簡単なわけじゃないよ
XAMLもHTMLもほぼ一緒だよ

[6 デフォルトの名無しさん 2025/05/28(水) 13:59:09.37 ID:sR0xPDfG]

前スレのegui日本語入力不備の例を見たら分かるけど
それぞれのフレームワークで「作り方」を学ぶ必要があるので
品質を度外視したら通り一遍での「作りやすさ」は対して変わらない

違いは
C#の場合は品質が良い
eguiの場合はrya

[7 デフォルトの名無しさん 2025/05/28(水) 14:02:53.48 ID:sR0xPDfG]

言い方を変えたら、eguiでは海外プログラマが品質の良い日本語入力体験を実現することがほぼ不可能

[8 デフォルトの名無しさん 2025/05/28(水) 14:04:08.88 ID:3diyko22]

>>6
eguiに日本語入出力の不備はありません
3年前に解決しています

[9 デフォルトの名無しさん 2025/05/28(水) 14:10:06.47 ID:DJ+9iHRJ]

>>8
eguiの依存crate winitで
今現在、IME対応トラッキングで「中途半端」ってなっているよ

[10 デフォルトの名無しさん 2025/05/28(水) 15:06:56.76 ID:jEpOPo+L]

Rustは中国人多いからIME対応についてはわりと恵まれてる方なんじゃない？
C#とは比べるべくもないけども

[11 デフォルトの名無しさん 2025/05/28(水) 15:08:51.14 ID:3diyko22]

>>9
具体的にどの環境で何の問題？

[12 デフォルトの名無しさん 2025/05/28(水) 15:19:08.76 ID:3cuSGzQE]

>>10
当然だけどC#が良いよね

[13 デフォルトの名無しさん 2025/05/28(水) 15:19:45.07 ID:3cuSGzQE]

前スレ>>976、
200万ダウンロードある割にめぼしいegui製アプリを挙げられないとは

[14 デフォルトの名無しさん 2025/05/28(水) 15:48:37.42 ID:5c61hWcj]

>>10
>>12
C#にはeguiに匹敵するまとまなものがありません
特にクロスプラットフォームと即時モード

[15 デフォルトの名無しさん 2025/05/28(水) 15:52:05.17 ID:jEpOPo+L]

C#でeguiみたいなのが欲しいならUnityがあるでしょ
比べるのも失礼だが

[16 デフォルトの名無しさん 2025/05/28(水) 15:54:45.63 ID:rI3faRy9]

UIを作りたいならJava/Kotlinで十分
ついこの前からKotlinのLSPの登場によってVSCodeでKotlinを触れるようになったし

[17 デフォルトの名無しさん 2025/05/28(水) 15:55:44.40 ID:5c61hWcj]

>>15
C#でGUI作るのにUnityを持ち出すとは
C#は辛い環境ですね

[18 デフォルトの名無しさん 2025/05/28(水) 15:56:23.68 ID:su0T3dFZ]

ここまでegui製アプリがない時点でお察し

[19 デフォルトの名無しさん 2025/05/28(水) 15:59:53.99 ID:su0T3dFZ]

>>14
eguiが現実的に目指すべきはImGUI
今は劣化版

[20 デフォルトの名無しさん 2025/05/28(水) 16:00:28.40 ID:jEpOPo+L]

>>17
だったらeguiを持ち出すのが間違いだな

[21 デフォルトの名無しさん 2025/05/28(水) 16:04:47.52 ID:5c61hWcj]

>>19
C++はさすがに論外
脱C/C++の流れに逆行ですか

[22 デフォルトの名無しさん 2025/05/28(水) 16:05:21.74 ID:su0T3dFZ]

検索したけどテキスト入力系のegui製アプリは本当に見つからない

[23 デフォルトの名無しさん 2025/05/28(水) 16:05:49.77 ID:rI3faRy9]

Unityは素晴らしい3Dグラフィックフレームワークだよ
ライセンス等が面倒くさいから単なる2Dアプリを作る場合には敬遠されるが、3Dアプリを作るならUnityは最高の選択肢

[24 デフォルトの名無しさん 2025/05/28(水) 16:06:33.52 ID:su0T3dFZ]

>>19
Unrealゲームエンジン(C++)の人たちのご用達だからニッチはある

[25 デフォルトの名無しさん 2025/05/28(水) 16:07:23.12 ID:su0T3dFZ]

Godotそうだな

[26 デフォルトの名無しさん 2025/05/28(水) 16:08:21.19 ID:su0T3dFZ]

Rust eguiは地盤が弱すぎる

[27 デフォルトの名無しさん 2025/05/28(水) 16:09:09.63 ID:XB/Z7e3W]

>>15
C#だとMAUIかUnityしかないけど
どちらもWasmで重すぎる
Rust eguiがベスト

[28 デフォルトの名無しさん 2025/05/28(水) 16:10:49.74 ID:su0T3dFZ]

>>4 こんなGUI見せられたら一般人は即閉じだけどねw

[29 デフォルトの名無しさん 2025/05/28(水) 16:11:27.52 ID:su0T3dFZ]

>>27 Webアプリの画面にすらならないよ

[30 デフォルトの名無しさん 2025/05/28(水) 16:12:12.15 ID:jEpOPo+L]

>>27
MAUIもUnityもネイティブだぞ
Webもターゲットとして選べるってだけ
リサーチが足りなかったね！残念！

[31 デフォルトの名無しさん 2025/05/28(水) 16:12:46.59 ID:rI3faRy9]

WASMならKotlinの2DグラフィックフレームワークのComposeが高速に動作しますな
C#は時代遅れだがKotlinとそのグラフィックフレームワークは最先端を行ってる
3DグラフィックはC#のUnityに劣るが

[32 デフォルトの名無しさん 2025/05/28(水) 16:14:38.63 ID:rI3faRy9]

ちなみにこれKotlin ComposeのWASMね
むっちゃいいで
https://oikvpqya.github.io/android-2048-compose/
https://github.com/oikvpqya/android-2048-compose

[33 デフォルトの名無しさん 2025/05/28(水) 16:16:03.19 ID:XB/Z7e3W]

>>30
C#の完敗だね
ブラウザ上WasmでもRust eguiなら軽く動く

[34 デフォルトの名無しさん 2025/05/28(水) 16:17:27.30 ID:rI3faRy9]

2Dグラフィック分野はC#の一人負けやな
時代はWebもデスクトップも対応するRustあるいはKotlinの2Dグラフィックフレームワークだ

[35 デフォルトの名無しさん 2025/05/28(水) 16:21:46.58 ID:l0HGF9yk]

eguiで汎用的なGUIは無理だよ
イベント処理と描画をワンパスで回してるからコンポーネントの並び順でデータ反映のタイミングが変わる
データ表示が1tickくらい前後しても気にしないなら有用だけど操作と表示の厳密な同期が必要だと不適
READMEにもimmediate mode GUIについて書いてあるはず
試したの大分前だから今は改善されてるかもしれないけど

[36 デフォルトの名無しさん 2025/05/28(水) 16:23:51.42 ID:5bAVydlz]

>>30
その時点でC#は時代遅れの役立たずと気づかなくちゃ
C#厨はRustスレを荒らすなよ

[37 デフォルトの名無しさん 2025/05/28(水) 16:23:57.29 ID:rI3faRy9]

KotlinのComposeもRustのeguiの即時モードと似たようなもんだけど、再計算してほしくないところを簡単に設定できる
もしかしてComposeが最強か？

[38 デフォルトの名無しさん 2025/05/28(水) 16:26:16.00 ID:5bAVydlz]

>>35
そこまで求める用途ないだろ

[39 デフォルトの名無しさん 2025/05/28(水) 16:29:23.92 ID:rI3faRy9]

さくっとクロスプラットフォーム対応の即応性のあるUIを作れるかどうかだよな
それができる、VSCodeでの開発にも対応したKotlinのComposeが最強ですわ

[40 デフォルトの名無しさん 2025/05/28(水) 16:32:03.18 ID:aUEr/cjd]

>>37
eguiは毎フレーム再計算再描画するわけではなくてデフォルトでリアクティブモード

[41 デフォルトの名無しさん 2025/05/28(水) 16:51:11.86 ID:2fsuNGRP]

実際のC#のGUIはwindows上では実際は一人勝ちだけどね
winforms
WPF
UWP
WinUI3

ゲーム
Unity

マルチプラットフォームでも
MAUI
Avalonia UI

[42 デフォルトの名無しさん 2025/05/28(水) 16:53:30.99 ID:rI3faRy9]

>>41
フレームワークの名前を上げてるだけで草

[43 デフォルトの名無しさん 2025/05/28(水) 16:54:26.24 ID:2fsuNGRP]

>>42
無知で草

[44 デフォルトの名無しさん 2025/05/28(水) 17:06:55.64 ID:rI3faRy9]

>>43
今後新しく2Dグラフィックアプリを作るうえで君の挙げたフレームワークはとてもじゃないが選択肢になりえないわ

[45 デフォルトの名無しさん 2025/05/28(水) 17:09:07.01 ID:2fsuNGRP]

>>44
windwosのエクスプローラーが新しくなったけどWinUIi3製だけど

[46 デフォルトの名無しさん 2025/05/28(水) 17:09:12.20 ID:aUEr/cjd]

>>41
ここはRustスレ
一切関係ない話をするな
WASMで軽く動くeguiの勝ち

[47 デフォルトの名無しさん 2025/05/28(水) 17:10:02.40 ID:2fsuNGRP]

むしろRustのGUIアプリは多分一個も使ってない

[48 デフォルトの名無しさん 2025/05/28(水) 17:11:29.48 ID:rI3faRy9]

>>45
あ、そう…

[49 デフォルトの名無しさん 2025/05/28(水) 17:12:24.43 ID:2fsuNGRP]

>>48
手も足も出なくて敗北して気分はどうなのかしらないけど無知は辛いな！

[50 デフォルトの名無しさん 2025/05/28(水) 17:14:07.73 ID:YI5TrplL]

君の勝ちでいいから
そろそろスレ違いの話を続けて荒らすのやめてくれないか？

[51 デフォルトの名無しさん 2025/05/28(水) 17:14:21.91 ID:aUEr/cjd]

>>45
Rustと無関係な話でスレを荒らすな
そんな狭い環境の話は専用スレでやれ

[52 デフォルトの名無しさん 2025/05/28(水) 17:16:51.21 ID:04x+Td+0]

スレ違いの話じゃなければ荒れてないとでも言いたげ

[53 デフォルトの名無しさん 2025/05/28(水) 17:18:38.82 ID:04x+Td+0]

ここは複おじと遊ぶためのスレだからな

[54 デフォルトの名無しさん 2025/05/28(水) 17:19:26.05 ID:YI5TrplL]

その通りさ
君がいればどんな話題でも荒れてるし
君がいなけりゃどんな話題でも荒れてないよ

荒らしてるのは君だけだからね

[55 デフォルトの名無しさん 2025/05/28(水) 17:20:08.80 ID:rI3faRy9]

俺もKotlin宣伝したさでスレチしてすまん

[56 デフォルトの名無しさん 2025/05/28(水) 17:23:52.14 ID:2fsuNGRP]

>>55
俺もじゃなくてお前がだろ馬鹿

[57 デフォルトの名無しさん 2025/05/28(水) 17:25:00.32 ID:rI3faRy9]

>>56
君もC#を宣伝したいだけじゃん
やってることは俺と一緒だよ

[58 デフォルトの名無しさん 2025/05/28(水) 17:26:48.94 ID:2fsuNGRP]

>>57
宣伝じゃなくてどうどうと嘘を書いたやつが居たから反論しただけだろ
お前が唯一無二で悪い

[59 デフォルトの名無しさん 2025/05/28(水) 17:30:35.85 ID:04x+Td+0]

結局C++とRustってどっちが良いの？スレにﾜｯﾁｮｲがついてない間、このスレにはほとんど書き込みが無かった
馬鹿が9traitsでﾜｯﾁｮｲを付けて隔離スレとしての機能を潰したらそっちは急に伸びなくなって、代わりにこっちが伸び始めた
つまりそういうことです

[60 デフォルトの名無しさん 2025/05/28(水) 17:31:46.13 ID:8mhebNI4]

C#スレもKotlinスレも他の言語の話題で埋められたらイヤだろ
ここはRustスレだから他の言語は禁止

[61 デフォルトの名無しさん 2025/05/28(水) 17:35:18.26 ID:04x+Td+0]

でもお前はGoスレにRustの宣伝垂れ流したじゃん

[62 デフォルトの名無しさん 2025/05/28(水) 17:56:30.13 ID:tdx1nu72]

1つ分かったのは

軽い気持ちで Rust GUI に手を付けたらだめ

見ての通り日本語入力で詰む

アーキテクチャデッドエンドってやつ

[63 デフォルトの名無しさん 2025/05/28(水) 18:21:13.98 ID:IJZJUmhj]

>>62
デマはダメですよ
eguiでもslintでもtauriでも
Rustで日本語入出力に問題はありません

[64 デフォルトの名無しさん 2025/05/28(水) 18:33:35.13 ID:jI9NxBSE]

継承もない言語でGUIは無理

GUIで実績があるC#、Android開発のJava、iOS開発のSwiftは全部普通のOOP言語

GoFのデザインパターンなんかはまさにGUIアプリを想定して作られたのが多いわけで、わざわざOOPから逸脱した言語をGUI開発で採用するメリットなど存在しない

[65 デフォルトの名無しさん 2025/05/28(水) 18:49:14.58 ID:L8a1pV32]

その主張は非OOPかつ大成功してる React という反例があるだろ

[66 デフォルトの名無しさん 2025/05/28(水) 18:51:34.57 ID:n1E/cJSB]

>>64
RustやGoはオブジェクト指向プログラミング言語
OOPと継承は一切関係がない
クラス継承は負の遺産

[67 デフォルトの名無しさん 2025/05/28(水) 18:51:43.18 ID:FvzDKMY4]

相変わらずだなここは

[68 デフォルトの名無しさん 2025/05/28(水) 18:54:51.36 ID:n1E/cJSB]

>>64
GoFのデザインパターンとGUIも一切関係がない
継承とも関係がない

[69 デフォルトの名無しさん 2025/05/28(水) 18:56:23.03 ID:hjnFeeaY]

時代は委譲だよ
継承は時代遅れ

[70 デフォルトの名無しさん 2025/05/28(水) 18:58:49.49 ID:O4qDurOb]

あれ、rustで委譲ってできるんだっけ

[71 デフォルトの名無しさん 2025/05/28(水) 19:31:51.52 ID:jI9NxBSE]

>>69
GoF本にも継承より委譲って書いてあるが、継承を使ったパターンも多いわけで
委譲が推奨されるだけで継承が適切な場面では当然使ってもいい
is-a関係じゃなくhas-a関係なのに継承使う人間が多いのが問題なだけ、つまり継承が問題なんじゃなくてそれを使う側の問題
それを言語側で勝手に制限するのはどうなのって話

GUIアプリでは継承が適切に当てはまるパターンが多い

[72 デフォルトの名無しさん 2025/05/28(水) 19:35:27.82 ID:04x+Td+0]

継承より合成の間違いでは

[73 デフォルトの名無しさん 2025/05/28(水) 19:39:37.68 ID:l0HGF9yk]

移譲と言われるとcompositionして自分で関数を実装するイメージだけど
Vec<T>→[T]のderefは委譲とみなせるのかな
&[T]に&Vec<T>を渡せるから継承っぽい雰囲気もある

[74 デフォルトの名無しさん 2025/05/28(水) 19:53:51.93 ID:d7M80YbK]

>>63
嘘も100回言えば本当になる思想のお国出身かな

[75 デフォルトの名無しさん 2025/05/28(水) 19:55:08.98 ID:n1E/cJSB]

>>71
GoFでクラス継承に依存したパターンは無い
GUIアプリでも欠陥だらけのクラス継承は不適切

[76 デフォルトの名無しさん 2025/05/28(水) 19:58:28.60 ID:bd87TuSw]

>GUIアプリでは継承が適切に当てはまるパターンが多い
>継承が適切な場面では当然使ってもいい
>継承が問題なんじゃなくてそれを使う側の問題
>継承もない言語でGUIは無理
あれれ

[77 デフォルトの名無しさん 2025/05/28(水) 20:00:30.74 ID:d7M80YbK]

egui製アプリのオススメさえないのかな

[78 デフォルトの名無しさん 2025/05/28(水) 20:00:39.99 ID:wPD/RllL]

77get

[79 デフォルトの名無しさん 2025/05/28(水) 20:03:29.90 ID:pVCw2YJ5]

>>74
RustのそれらGUIの日本語入力に問題はないけど
問題あると主張したいなら具体的なことを言わないと

[80 デフォルトの名無しさん 2025/05/28(水) 20:05:26.68 ID:d7M80YbK]

Rust part29
https://mevius.5ch.net/test/read.cgi/tech/1746200850/988
988: デフォルトの名無しさん sage 2025/05/28(水) 00:45:54.75 ID:jV0wUpuO
前スレ 985
前スレ 983じゃないけど egui/crates/egui_demo_app/ をビルドして
TextEditを追加してIMEで日本語入力しようとしたら
① カーソル位置には文字化けした□
② カーソル位置とは別に、変換前文字のエコーバックがあらぬ位置に出現したりしなかったり不安定
③ IME変換候補一覧で候補をエンターで確定したら改行も入力される
④ IME変換候補一覧で候補をタブで補完確定しようとしたらフォーカスがあらぬ所に飛んで入力出来ない

ここでやる気が無くなった

[81 デフォルトの名無しさん 2025/05/28(水) 20:06:40.39 ID:jI9NxBSE]

C#しかりJavaにしかりSwiftにしかりFlutterにしかりGUI開発で使われるのはすべて継承をサポートした通常のOOP言語
アプリ側で継承を使わずともGUIのフレームワーク側で継承が必ず多用されている

継承がないRustやGoがGUI開発に向いているというなら、それらで書かれた有名アプリを上げてみろ
個人開発者のオナニーでしか使われてないだろ、エンタープライズで採用されるわけがない

[82 デフォルトの名無しさん 2025/05/28(水) 20:07:24.47 ID:d7M80YbK]

IME変換候補一覧でEscおして未確定入力に戻ろうとすると
未確定入力が全部消える

[83 デフォルトの名無しさん 2025/05/28(水) 20:09:57.48 ID:pVCw2YJ5]

>>80
それは前スレに出ていたegui::FontDataを指定していない貴方のミス
デフォルトは最小限にしてくれている

[84 デフォルトの名無しさん 2025/05/28(水) 20:10:18.35 ID:EIair+pr]

【兵庫】「知事・元副知事の指示に基づき正当業務を…」斎藤知事の“側近”井ノ本氏の弁明書　知事は改めて否定 [ぐれ★]
2025/05/28(水) 17:08:14.82
https://asahi.5ch.net/test/read.cgi/newsplus/1748419694/
※追い詰められてないか？

[85 デフォルトの名無しさん 2025/05/28(水) 20:12:28.66 ID:d7M80YbK]

>>83
スクショ
ttps://i.imgur.com/TSnY3Fz.jpeg

[86 デフォルトの名無しさん 2025/05/28(水) 20:16:53.37 ID:d7M80YbK]

>>83
> デフォルト

デフォルトじゃないよ、demoだよ
2025年にこれはないよね

[87 デフォルトの名無しさん 2025/05/28(水) 20:19:26.88 ID:pVCw2YJ5]

>>85
デフォルトは全てのフォントを読み込むムダをしません
必要分を指定してアプリを作ります

[88 デフォルトの名無しさん 2025/05/28(水) 20:21:52.38 ID:d7M80YbK]

> フォントを読み込むムダ
フォールバック知らないのかな？

[89 デフォルトの名無しさん 2025/05/28(水) 20:30:25.48 ID:pVCw2YJ5]

>>88
eguiにはフォントフォールバックするよう指定もできます
各アプリで必要な方法を指定してね

[90 デフォルトの名無しさん 2025/05/28(水) 20:33:30.22 ID:7VtIWnA4]

RustでUIを組むことに拘らずとも、
ロジック部分をRustで組んでそれをJavaScriptなりFlutterなりUnityなり既存のUIフレームワークに吸収させればよくね？
eguiの即時モードなんざ大した強みでもあるまいに

[91 デフォルトの名無しさん 2025/05/28(水) 20:34:37.16 ID:0kR8GlE/]

>>89
TextEditに入力される言語なんて予めは分からないけど
eguiでは多言語対応するには予め全言語のフォントをロードするのかな？

>>85はフォントの問題だけじゃないのが一目瞭然だね

[92 デフォルトの名無しさん 2025/05/28(水) 20:41:49.63 ID:/TPXOOE5]

eguiぐらいの簡単さで、かつ即時モードとかクロスプラットフォームとか尖ったことをやらない
ふつーの地味なGUIツールキットが欲しいね

[93 デフォルトの名無しさん 2025/05/28(水) 20:43:03.97 ID:jI9NxBSE]

そもそもGUI開発でなんでGCなしとかいう縛りゲームやらないといけないのって疑問があるわけだけど
メモリなんか潤沢にあるんだから使えばいいだけ、そもそもブラウザがメモリ馬鹿食いするだろ
並列処理のメモリ安全もOSみたいにパソコン全体が落ちるわけでもなくアプリが強制終了するだけだしどうでもいい

まさに目的と手段をはき違えた白痴でしかないわな、RustのGUIフレームワークなど地球上から消滅してもRustアホ信者以外誰も困らないわな

[94 デフォルトの名無しさん 2025/05/28(水) 20:44:12.30 ID:bd87TuSw]

>>85
windowsのコントロールは何もしなくてもマルチランゲージ対応だよ
あなたのTextEditに問題がある

[95 デフォルトの名無しさん 2025/05/28(水) 20:45:20.11 ID:9xHYJpU5]

>>93
大昔からGUIライブラリがCやC++で作られてきた現実も知らないアホ発見

[96 デフォルトの名無しさん 2025/05/28(水) 20:47:36.94 ID:BJsMqKQA]

>>91
eguiはwasmでも動くため特定のプラットフォームのフォントシステムに非依存
バイナリサイズも重要

[97 デフォルトの名無しさん 2025/05/28(水) 20:47:52.91 ID:04x+Td+0]

>>92
その方向性ならプラットフォームごとのネイティブライブラリをextern "C"で叩くのが安牌か
簡単かどうかは知らん

[98 デフォルトの名無しさん 2025/05/28(水) 20:51:52.58 ID:04x+Td+0]

>>85
これはひどい

>>87>>91
そしてこの反応はもっとひどい

[99 デフォルトの名無しさん 2025/05/28(水) 20:52:17.02 ID:04x+Td+0]

>>91じゃなくて>>94でした

[100 デフォルトの名無しさん 2025/05/28(水) 20:57:40.31 ID:Vlv5P5ob]

>>98
ひどくない
wasmで動くデモに全てのフォント対応する必要はない

[101 デフォルトの名無しさん 2025/05/28(水) 21:04:49.37 ID:V4kzLhX1]

>>85 >>98
フォント指定で日本語入出力使えるeguiに対してここまでスレ荒らしするおまえが酷いぜ

[102 デフォルトの名無しさん 2025/05/28(水) 21:05:54.14 ID:04x+Td+0]

>>100
これ見て豆腐になってる以外何も気づかないの？
境界知能？

[103 デフォルトの名無しさん 2025/05/28(水) 21:05:55.54 ID:47YO4Tql]

なぜeguiが持ち上げられてるんだ？
Open GL、OpenGL ES、WebGLのRustポートのglowがベースな時点で他言語のUIフレームワークと変わらないのに

[104 デフォルトの名無しさん 2025/05/28(水) 21:09:03.26 ID:04x+Td+0]

バグのないソフトウェアとは使われていないソフトウェアである

[105 デフォルトの名無しさん 2025/05/28(水) 21:09:20.72 ID:V4kzLhX1]

>>103
ここはRustのスレ
例えばPythonのスレでC#やKotlinを勧めて延々とスレを荒らす人はいない

[106 デフォルトの名無しさん 2025/05/28(水) 21:10:43.66 ID:V4kzLhX1]

>>104
eguiはRecent Downloads 200万でRust GUI crate人気トップ

[107 デフォルトの名無しさん 2025/05/28(水) 21:15:52.43 ID:jQOiyAX1]

>>103
VulkanやMetalに対応してないのやる気無いだろw
OpenGL系はもはや時代遅れなのにw

[108 デフォルトの名無しさん 2025/05/28(水) 21:18:05.93 ID:V3p2RWJM]

そんなに他言語のページ記述法が好きなら、ライブラリだけRustで書いてGUIなんか好きなもんでつくりゃいいんじゃねえのか

[109 デフォルトの名無しさん 2025/05/28(水) 21:19:17.59 ID:V4kzLhX1]

>>108
ここはRustのスレ
他の言語の話はそのスレでやってくださいね

[110 デフォルトの名無しさん 2025/05/28(水) 21:21:16.53 ID:04x+Td+0]

>>106
仮に「バグのないソフトウェア」なるものが存在するならばという仮定の話ですよ

[111 デフォルトの名無しさん 2025/05/28(水) 21:21:29.92 ID:/3UkF8CZ]

>>107
vulkano crateとmetal crateがあるよ

[112 デフォルトの名無しさん 2025/05/28(水) 21:25:32.09 ID:04x+Td+0]

そこでwgpuが出てこない辺りがお里が知れるって感じ

[113 デフォルトの名無しさん 2025/05/28(水) 21:29:26.09 ID:N33gBpK7]

GUIアプリだと、よほど重い処理をするのでない限りは人間の視覚や認知能力、操作速度がボトルネックだからね
Webだと多数のユーザーを1台で捌くからサーバー台数減らせる論法が通じるんだけど、
デスクトップアプリだと一台一ユーザーだから基本的にリソースがら空きなのよね

[114 デフォルトの名無しさん 2025/05/28(水) 21:32:51.56 ID:+C/Or4KG]

>>92
icedおすすめ
https://iced.rs/
フォント指定で日本語も使える

[115 デフォルトの名無しさん 2025/05/28(水) 21:33:22.83 ID:rI3faRy9]

>>107
そんな君にはrust-skiaという選択肢を授けよう
SkiaのRustバインディングでVulkan、Metal、OpenGLに対応してるぞ

[116 デフォルトの名無しさん 2025/05/28(水) 22:06:03.44 ID:LvaIuI6v]

wgpuは便利そうね

wgpuでFPSゲーム開発
$tech #cg #webgpu #rust
2024/08/08
https://skdassoc.com/posts/wgpu-simple-fps/

[117 デフォルトの名無しさん 2025/05/28(水) 22:21:56.88 ID:mckRK7kG]

ゲームエンジンといえばRust製ゲームエンジンのBevyはまだUnityに勝てないのかい？
だいぶ安定したと聞いたけど。

[118 デフォルトの名無しさん 2025/05/28(水) 22:28:32.59 ID:trxd20LN]

>>114
リリース版では、まだ日本語入力できないよ

[119 デフォルトの名無しさん 2025/05/28(水) 22:29:48.50 ID:iQxD0DPy]

Unity頼みしかなく利用者減少中のC#は消える言語

[120 デフォルトの名無しさん 2025/05/28(水) 22:32:02.21 ID:yb4IZ4ZN]

>>118
リリース版て何だ？？
icedは以前から日本語使える

[121 デフォルトの名無しさん 2025/05/28(水) 22:53:39.79 ID:L8a1pV32]

>>120
Icedは日本語を表示できるだけで、入力はまだ対応してないぞ
いまの master ブランチには最低限の対応が入ったみたいだから、次のリリース以降で対応予定
出来具合は知らん

[122 デフォルトの名無しさん 2025/05/28(水) 22:55:30.34 ID:04x+Td+0]

内実がどうであってもRustは他のすべてより優れているという言説に囲まれていれば幸せ、それを否定する言説は不快という精神性なんだろう
信者というよりワナビと言ったほうが近い
だから「不具合はない」なんて平気で言えてしまう

[123 デフォルトの名無しさん 2025/05/28(水) 23:01:42.06 ID:L8a1pV32]

その様子だと当然、他のフレームワークも自分で試した経験は無いよね

[124 デフォルトの名無しさん 2025/05/28(水) 23:07:14.58 ID:TC9Jxa8O]

巷ではAIがプログラマの仕事を侵食して日々阿鼻叫喚状態だってのにここは日本語入力ができるできないで揉めてて頭がお花畑なのかな

[125 デフォルトの名無しさん 2025/05/28(水) 23:36:33.87 ID:yYsvLAUb]

rustすきだから仕事でも使いたいけどそんな仕事はないのであった

[126 デフォルトの名無しさん 2025/05/28(水) 23:43:08.73 ID:aOveZ1uY]

>>85
コンパイラが文字化け直してくれないの？

[127 デフォルトの名無しさん 2025/05/28(水) 23:58:50.90 ID:1glX32a/]

>>85
Rustプログラマにはwarning位は出してあげないと不親切だな

[128 デフォルトの名無しさん 2025/05/28(水) 23:59:36.62 ID:1glX32a/]

少なくとも約一名には

[129 デフォルトの名無しさん 2025/05/29(木) 00:34:53.79 ID:HC3P1AcQ]

>>85
それは漢字フォント挿れたら解決する
なぜそんなところで詰まってるの草

[130 デフォルトの名無しさん 2025/05/29(木) 00:39:15.44 ID:TWUjYqyj]

【悲報】兵庫県斎藤知事のデモに増山誠氏が行くと、共産党員らしき人達に取り囲まれ罵声をあびせられる [662593167]
2025/05/26(月) 10:13:20.40
https://hayabusa9.5ch.net/test/read.cgi/news/1748222000/
元総務部長が処分に異議「エロ小説公開は知事の指示に基づく外部通報！正当な業務行為だ！！」斎藤「」 [754019341]
2025/05/28(水) 17:40:55.62
https://hayabusa9.5ch.net/test/read.cgi/news/1748421655/
斎藤兵庫「私は情報漏えいを指示してないが総務部長は知事から指示されてやったので処分は軽くする」 [659060378]
2025/05/28(水) 21:57:18.08
https://hayabusa9.5ch.net/test/read.cgi/news/1748437038/
カンボジアの巨大特殊詐欺拠点で日本人２０人以上を拘束wwwwwwwwwwwwwwwwwwwww [271912485]
2025/05/28(水) 22:14:24.13
https://hayabusa9.5ch.net/test/read.cgi/news/1748438064/
日本で行方不明になる子供が増加 中國人に誘拐され臓器売買されてる（画像あり） [659060378]
2025/05/28(水) 22:18:14.00
https://hayabusa9.5ch.net/test/read.cgi/news/1748438294/
【兵庫】県庁内に動揺　幹部「県職員という誇りが持てない」　斎藤元彦知事の漏えい指示可能性に　県民からは辞職を求める声も [ぐれ★]
2025/05/28(水) 20:04:46.31
https://asahi.5ch.net/test/read.cgi/newsplus/1748430286/
【斎藤知事告発問題】情報漏えい認定され懲戒処分　兵庫県元総務部長・井ノ本知明氏が処分の執行停止を申し立てる意向示す ★2 [ぐれ★]
2025/05/28(水) 20:06:37.11
https://asahi.5ch.net/test/read.cgi/newsplus/1748430397/
【兵庫】「知事・元副知事の指示に基づき正当業務を…」斎藤知事の“側近”井ノ本氏の弁明書　知事は改めて否定 [ぐれ★]
2025/05/28(水) 17:08:14.82
https://asahi.5ch.net/test/read.cgi/newsplus/1748419694/

[131 デフォルトの名無しさん 2025/05/29(木) 00:58:51.00 ID:/VGnPfwc]

>>124
日本語入力は問題ない
出来てる記事も検索でいくらでも見つかる
荒らしに騙されるな

[132 デフォルトの名無しさん 2025/05/29(木) 01:01:20.08 ID:1wQvJgBW]

大丈夫
自分を騙したくてしょうがない某以外はちゃんと現実を見てるから

[133 デフォルトの名無しさん 2025/05/29(木) 01:07:56.74 ID:b/WYgMAJ]

>>85を見てフォントしか見えない人間には「問題ない」のか

フォーカスが散らかったら(>>80)普通の人には極めて不愉快な日本語入力体験だよ

[134 デフォルトの名無しさん 2025/05/29(木) 01:11:50.59 ID:a68+kVcN]

記事ぐぐって真似したら日本語入力できたわ
ちゃんと候補変換もできた

[135 デフォルトの名無しさん 2025/05/29(木) 10:31:37.73 ID:Fzugd6EU]

AIチャットボットに有害な情報を出力させる手口が存在、研究者が危険性を指摘
2025-05-27 20:00
https://karapaia.com/archives/512716.html
>>　イスラエルの研究チームが、主要なAIチャットボットが「脱獄（ジェイルブレイク）」と呼ばれる手口で、安全制御を回避され、違法で有害な情報を出力してしまう可能性があることを示した。
>>　ChatGPTのような生成AIには、ユーザーの指示に対して有害な回答をしないよう制限が組み込まれている。しかし、今回の実験では、その制限が比較的簡単にすり抜けられることが明らかになった。
>>　研究チームは、「これまで国家機関や犯罪組織に限られていた情報が、今やノートパソコンやスマートフォンを持つ誰にでも届く可能性がある」と警鐘を鳴らしている。
中略
>>　ネットワークのハッキング法や犯罪行為であっても、手順を追って教えてくれるのだ。
中略
>>　この報告は『arXiv』（2025年5月15日投稿）で閲覧できる。
※電波攻撃音波攻撃詳細に方法を教えてくれる

[136 デフォルトの名無しさん 2025/05/29(木) 11:15:32.82 ID:P/EhFQUC]

一番不愉快なのは電池が入ってないことだ
だから電池自体が無料になっても大多数はフリーライダーにならない

[137 デフォルトの名無しさん 2025/05/29(木) 12:39:45.23 ID:38QdIlfQ]

>>121
icedのexampleのtourのText inputで日本語入力できたよ
フォント指定とか何もせず表示されてるよ

[138 デフォルトの名無しさん 2025/05/29(木) 14:28:34.29 ID:FS2yMHN+]

icedスクショ
https://i.imgur.com/HoUFPXr.png

[139 デフォルトの名無しさん 2025/05/29(木) 14:31:32.99 ID:FS2yMHN+]

中華系
https://i.imgur.com/U2ERYzu.png

[140 デフォルトの名無しさん 2025/05/29(木) 14:34:19.88 ID:FS2yMHN+]

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

[141 デフォルトの名無しさん 2025/05/29(木) 16:36:24.76 ID:J+/v4u6H]

複オジの品質基準では「何の問題もない」
一般的な品質基準では「問題ありまくり」
ってことだね

[142 デフォルトの名無しさん 2025/05/29(木) 16:52:15.94 ID:zvp26qtt]

>>141
そう思います
きりがなさそうだったので止めたけどこれだけ追加

変換候補選択と入力がずれるスクショ
https://i.imgur.com/ZtTwBKS.png

[143 デフォルトの名無しさん 2025/05/29(木) 18:33:06.88 ID:CVbdbSI1]

>>137
slintは以前からデフォルトで日本語OK

[144 デフォルトの名無しさん 2025/05/29(木) 18:42:04.47 ID:P/EhFQUC]

日本人が10億人ぐらいいたらいいのにな
薬の副作用みたいに、統計的に無視できる数だとしたら、薬の品質とは一体何なんだろう

[145 デフォルトの名無しさん 2025/05/29(木) 18:47:00.08 ID:uFXH/Bz1]

C++ではwxWidgets使ってたからwxDragonには期待してるけど
結局のところRustのライブラリ全般の問題として、あくまで個人がほぼ1人でメンテしてるから作者の気力次第で終わっちゃうんだよな
結局実開発で使うなら、Tauriしか選択肢ない気がする

[146 デフォルトの名無しさん 2025/05/29(木) 19:00:13.93 ID:rJxPuwpw]

中央揃えにしてるのに入力時に右側だけに伸びるのとかもアカンよね

[147 デフォルトの名無しさん 2025/05/29(木) 19:34:00.55 ID:Zakc8vPY]

Rustが必要なGUIってゲームエンジンぐらいじゃねーの

[148 デフォルトの名無しさん 2025/05/29(木) 19:43:25.99 ID:ecKICX3I]

>>145
slintが正解ってことじゃん

[149 デフォルトの名無しさん 2025/05/29(木) 19:43:54.92 ID:CVbdbSI1]

>>145
slintは企業が開発し多くの企業で使われている
https://slint.rs/

[150 デフォルトの名無しさん 2025/05/29(木) 19:45:49.63 ID:CVbdbSI1]

>>149のslint公式見ると
Rust FoundationやRaspberry Piも会員

[151 デフォルトの名無しさん 2025/05/29(木) 19:46:48.55 ID:CVbdbSI1]

>>147
slintが組み込みなど世界各地で既に使われている

[152 デフォルトの名無しさん 2025/05/29(木) 20:22:36.72 ID:Ycbjs3h7]

slintのデスクトップのレンダラはskiaか
ええやん

[153 デフォルトの名無しさん 2025/05/29(木) 21:05:15.61 ID:nHbMuSGa]

頑張って捜してきたのかな

[154 デフォルトの名無しさん 2025/05/29(木) 21:43:51.50 ID:eP09c0cT]

slintは神！

[155 デフォルトの名無しさん 2025/05/29(木) 22:23:39.24 ID:nezA3YNU]

オープンソース版はGPLで機能制限あり
無償ライセンスは機能制限あり&組み込みは不可
なかなか厳しいねえ
まあこういう選択肢があること自体はもちろん悪いことではないが、これを引き合いに出してGUI開発におけるRustの優位性を主張するのはちょっと無理があるかな
残念だけどやり直してきましょう

[156 デフォルトの名無しさん 2025/05/29(木) 22:56:38.86 ID:PpGjeRAQ]

SlintもIME周りはバグだらけで似たようなもんだな
細々と自分で修正していくつもりじゃなければ全く使えない

[157 デフォルトの名無しさん 2025/05/29(木) 23:07:20.84 ID:PcftYTY1]

>>156
slintの日本語入力は完璧ですよ
バグの証拠はあるんですか？
Rustアンチ活動はよそでやってください

[158 デフォルトの名無しさん 2025/05/29(木) 23:12:35.45 ID:d43wh1Zk]

match slint = Rust {
Some(日本語入力) => …
}
みたいなのやって何が楽しいんだ

[159 デフォルトの名無しさん 2025/05/29(木) 23:31:50.99 ID:hr2gWeV0]

現時点でのGUIライブラリの総まとめみたいな記事があるから、これでも見ればいいんじゃない？
英語圏の人 (?) の記事にしては珍しく IME の動作にも触れてるし
https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-gui-libraries.html

[160 デフォルトの名無しさん 2025/05/29(木) 23:37:20.56 ID:7sGSsoDI]

Err(日本語入力 =>　諦める

[161 デフォルトの名無しさん 2025/05/30(金) 08:12:56.85 ID:h4Wa/khY]

>>159
素晴らしい比較記事
GTK 4, WinSafe, Xilemがよさそうだな

[162 デフォルトの名無しさん 2025/05/30(金) 12:50:08.14 ID:MmHFotTI]

>>159
そのページで、冒頭の以下の部分から始まっているプログラミング言語は何ですか？
const Demo = () => {・・・}

[163 デフォルトの名無しさん 2025/05/30(金) 12:52:09.42 ID:MmHFotTI]

よく見ると、「Reactでは」と書いてありますね。

[164 デフォルトの名無しさん 2025/05/30(金) 13:22:57.61 ID:FTEPrInt]

悪用されるのは当然です
高品質かつ高速な画像生成AI「FLUX.1 Kontext」が登場したので使ってみた、テキストと画像の入力に対応しアニメ風も実写風も生成可能
https://gigazine.net/news/20250530-flux-1-kontext-image-generation-ai/

全てのAIの推論をどうやって導き出したかがわかるのでプログラムの改造がはかどる
AnthropicがAIモデルの思考内容を可視化できるオープンソースツール「circuit-tracer」を公開
https://gigazine.net/news/20250530-anthropic-open-source-circuit-tracing/

[165 デフォルトの名無しさん 2025/05/30(金) 13:41:18.42 ID:NYSfPt/q]

>>163
useState hooks使ってるしな

[166 デフォルトの名無しさん 2025/05/30(金) 15:55:45.90 ID:uGql1Hfj]

>>159
IME日本語入力問題なし多いな
アンチが暴れてたのは何だったんだ

[167 デフォルトの名無しさん 2025/05/30(金) 16:21:21.83 ID:cHohYJDu]

ゲームエンジンも好調だしRustが天下を取る日も近い
UIフレームワークはFluent Designに対応してくれたら完璧

[168 デフォルトの名無しさん 2025/05/30(金) 16:25:20.82 ID:uGql1Hfj]

「Linuxカーネル6.15」がリリース--NVIDIA GPU用のRust製ドライバーなど追加
https://japan.zdnet.com/article/35233609/

[169 デフォルトの名無しさん 2025/05/30(金) 17:36:24.85 ID:cHohYJDu]

むっちゃ感動ものがあんじゃん
泣いたわ😭

「Rust」が10周年--エレベーター故障から始まったシステムプログラミング言語の歴史
https://japan.zdnet.com/article/35233577/

[170 デフォルトの名無しさん 2025/05/30(金) 18:48:04.55 ID:YIY2nzAq]

>>161
>GTK 4, WinSafe, Xilem

XilemはeguiやIcedと同じで「入力が可能」なだけで実用レベルには達してないね
GTKやWinSafeは既存のC/C++のGUIライブラリを使ってるから安心だね
現時点でまともなのを作ろうとするとRust製以外のGUIライブラリを土台としたものしかないって結論だね

[171 デフォルトの名無しさん 2025/05/30(金) 21:24:39.37 ID:h4Wa/khY]

>>170
普段からlibcにリンクしてるんだから気にしなくていいよ

[172 デフォルトの名無しさん 2025/05/30(金) 21:32:56.61 ID:sYt0biH/]

>>170
>>159のGUIライブラリ一覧でIME完動が7つもある
著者が日本語を入力して動作確認してる

[173 デフォルトの名無しさん 2025/05/30(金) 21:56:09.18 ID:Lwt4GhfM]

IMEが正常動作して日本語が豆腐にならないのって
突破してようやく最低のラインを超えたって話だからな

[174 デフォルトの名無しさん 2025/05/30(金) 22:01:28.10 ID:sYt0biH/]

完全に合格が7つもあれば十分だろう

[175 デフォルトの名無しさん 2025/05/30(金) 22:02:18.93 ID:bH8zoGf4]

>>172,174
筆者がperfectlyと表現しているのがごくわずかなので、書き下して周りの反応を見ては？
「完動」が「複オジの品質基準」の可能性があるし>>141

[176 デフォルトの名無しさん 2025/05/30(金) 22:03:55.07 ID:bH8zoGf4]

perfectlyはこれだけかと
Dioxus, fltk

[177 デフォルトの名無しさん 2025/05/30(金) 22:06:02.44 ID:bH8zoGf4]

Tauriですら
> the IME provisional states are drawn in the corner of the screen
(変換候補)

[178 デフォルトの名無しさん 2025/05/30(金) 22:09:02.02 ID:h4Wa/khY]

>>177
これはおかしい気がする
俺が試す限りでは、Tauri v2は変換候補含めて完璧
Edgeと同じ挙動になる

[179 デフォルトの名無しさん 2025/05/30(金) 22:10:35.03 ID:bH8zoGf4]

>>157
slintスクショお待たせしました
https://i.imgur.com/GpQnqQ0.png

[180 デフォルトの名無しさん 2025/05/30(金) 22:13:10.66 ID:bH8zoGf4]

>>178
とりあえず「IME完動が7つ」を挙げては

[181 デフォルトの名無しさん 2025/05/30(金) 22:13:54.71 ID:sYt0biH/]

>>176
Dioxus fltk だけでなく
WinSafe Tk Realm GPUI GTKもIME合格と書かれている

[182 デフォルトの名無しさん 2025/05/30(金) 22:15:04.58 ID:bH8zoGf4]

合格と完動では印象違います

[183 デフォルトの名無しさん 2025/05/30(金) 22:16:26.67 ID:sYt0biH/]

>>182
完動の意味の合格
部分合格が多数ある中で>>181の7つは完動

[184 デフォルトの名無しさん 2025/05/30(金) 22:17:11.67 ID:UA2Q80OL]

>>167
Rust製のエンジンが使われたゲームってどういうのがあるの？

[185 デフォルトの名無しさん 2025/05/30(金) 22:17:34.83 ID:bH8zoGf4]

記事筆者は
perfectly
correct (指摘意外は)
fine
sort of works
refuses to activate
など微妙に使い分けています

[186 デフォルトの名無しさん 2025/05/30(金) 22:19:54.97 ID:bH8zoGf4]

>>181
GPUIはworks fineですね
perfectより劣るとの見方でしょう

[187 デフォルトの名無しさん 2025/05/30(金) 22:20:09.99 ID:UA2Q80OL]

>>181
どれも既存のフレームワークのバインディングな件

[188 デフォルトの名無しさん 2025/05/30(金) 22:22:04.63 ID:sYt0biH/]

記事著者は最後に表にして
IMEについて完動はyes！
部分動作はきちんと指摘してる

[189 デフォルトの名無しさん 2025/05/30(金) 22:22:47.89 ID:J/zQgQcb]

>>175
複おじ本人に「複オジ品質基準」を指摘しても無駄やろ

[190 デフォルトの名無しさん 2025/05/30(金) 22:23:30.58 ID:bH8zoGf4]

>>188
はい、表と本文で見てます

[191 デフォルトの名無しさん 2025/05/30(金) 22:26:02.78 ID:bH8zoGf4]

>>189
「複オジ品質基準」で「何の問題もない」としていたegui/iced/slintの筆者評価が面白いですね

日本人なら筆者より更に気が付く不具合がありそうな気もしてます

[192 デフォルトの名無しさん 2025/05/30(金) 22:28:31.23 ID:AYugJGTX]

>>176
Rust製のDioxusが完全合格だとアンチ君もついに認めたのか
これは記念碑だな

[193 デフォルトの名無しさん 2025/05/30(金) 22:29:57.28 ID:AYugJGTX]

Dioxusはかなり良い
ReactやFlutterに慣れてる人ならすぐ理解できる

[194 デフォルトの名無しさん 2025/05/30(金) 22:30:45.68 ID:Cn6XLlw/]

>>193
で何作ってるの？

[195 デフォルトの名無しさん 2025/05/30(金) 22:34:03.08 ID:AYugJGTX]

>>194
Dioxus製の例が19掲載されている
https://dioxuslabs.com/awesome

[196 デフォルトの名無しさん 2025/05/30(金) 22:34:28.63 ID:bH8zoGf4]

>>192
いまZed/GPUIを少し触った感じでは
再変換が出来ない
再変換を使わない人には合格かと

Dioxusはfltkを検証する気は無いけど記事筆者の意見を尊重します

[197 デフォルトの名無しさん 2025/05/30(金) 22:36:18.22 ID:bH8zoGf4]

ただし品質的にはZed/GPUIは「完動」とは言えませんね

[198 デフォルトの名無しさん 2025/05/30(金) 22:36:56.66 ID:Cn6XLlw/]

>>195
こんなサンプルやお遊びじゃなくて実用的なプロジェクトの事例を知りたい
少なくともあなた自身はそれに関わっているのでしょう？

[199 デフォルトの名無しさん 2025/05/30(金) 22:39:48.67 ID:bH8zoGf4]

Geany/GTK?の感じでは変換候補の位置が上過ぎ、再変換出来ない

[200 デフォルトの名無しさん 2025/05/30(金) 22:40:38.88 ID:bH8zoGf4]

>>199
GeanyはRust製ではないけどGTKのIME品質の話です

[201 デフォルトの名無しさん 2025/05/30(金) 22:40:44.53 ID:Lwt4GhfM]

DioxusはElectron系なんだから動くのは動くだろう
フロントはTypeScriptで書けって割切ってるからWeb屋がやってることは全部できるTauriと違って
RustとCSSのみで頑張るっぽいのは、正直作り込むほど面倒になりそうに思える

[202 デフォルトの名無しさん 2025/05/30(金) 22:43:07.37 ID:bH8zoGf4]

Electron系 Webview系は変換候補の位置が正しく出せるか位ですかね、見るべきところは

[203 デフォルトの名無しさん 2025/05/30(金) 22:43:50.52 ID:bH8zoGf4]

あとフォーカスもありますね

[204 デフォルトの名無しさん 2025/05/30(金) 22:44:43.88 ID:bH8zoGf4]

フォーカスを失ってから戻った時にIMEオンオフ状態がリセットされるのを散見します

[205 デフォルトの名無しさん 2025/05/30(金) 22:45:32.44 ID:bH8zoGf4]

入力途中の文字が消えるのも散見します

[206 デフォルトの名無しさん 2025/05/30(金) 22:47:21.53 ID:AYugJGTX]

>>198
お遊び？
例えばBionicGPTの規模を見ろよ
これもDioxusが使われている

[207 デフォルトの名無しさん 2025/05/30(金) 22:52:50.02 ID:Qt/sCeP/]

比較記事でTauriの日本語入力がやや変なのは
著者が偏見でjsを使わず、wasmでビューを作ったせいじゃないかな
普通の人はjsでやるので問題ない

[208 デフォルトの名無しさん 2025/05/30(金) 22:58:24.77 ID:R5s1SUqD]

>>206
ようするに自分ではなにも作ってないのね

[209 デフォルトの名無しさん 2025/05/30(金) 22:59:22.38 ID:NYSfPt/q]

>>208
それ誘導尋問してボロ出させた印象あるよ、、、やめよそういうのは

[210 デフォルトの名無しさん 2025/05/30(金) 23:11:55.52 ID:Zy/1fV9r]

BionicGPTはRust製なんだな
Dioxusが既に実用的に使われてるとは驚き

[211 デフォルトの名無しさん 2025/05/31(土) 01:04:57.23 ID:YcA/fePE]

いいところ探し的な書き込みがされるごとに>>122の真実味が増していく

[212 デフォルトの名無しさん 2025/05/31(土) 02:04:46.35 ID:IWkyfeO/]

メモリ安全性に異常にこだわるのは「バーダー・マインホフ効果」なのかも知れないな。

[213 デフォルトの名無しさん 2025/05/31(土) 02:42:33.46 ID:kWi082u0]

色んなものがRust製になっていってる要因は開発のしやすさではないか
安全性はオマケ

[214 デフォルトの名無しさん 2025/05/31(土) 08:47:00.79 ID:vaxfTYLN]

Rustは言語だけで差別化できる(と信じられている)言語なので、
一部の人間はRustを使うことで自己肯定感を高めることができる、というのが流行った最大の要因
同種のユーザーベースをもつ言語としては直近Scalaがあったけど、あれは見事に大失敗して逆にその手の言語が世間の信頼を失う結果となった
それ以来しばらくはKubernetesや機械学習など、プログラミング言語など道具の一つである、な不遇の時代が続いていたが、
Rustでにわかにその種の人達が活気付いたわけだね
最近はAIの隆盛でまた潮目が変わっているが、とはいえ向こう3年くらいは続くんじゃないかな

[215 デフォルトの名無しさん 2025/05/31(土) 08:47:04.10 ID:nmv5+SMF]

安全性や品質を鑑定するだけ批判するだけなら異常にはならない
何かを変えようとしなければ日常が続く
変えようとすれば異常になる

[216 デフォルトの名無しさん 2025/05/31(土) 09:18:19.11 ID:BT0xlZs3]

GUIツールキットってどちらかというとどれだけコンポーネント用意できるかの作業量勝負だし、Rustだからどうってもんでもないしな
これで優劣決めるとDelphiこそ最強になってしまう

[217 デフォルトの名無しさん 2025/05/31(土) 09:41:36.08 ID:nmv5+SMF]

どんな言語もポインタとヒープとガベコレが必ずあって違いはシンタックスだけという説があった
これが覆されると、シンタックスだけ変えても無意味という説もいまいち説得力がなくなる

[218 デフォルトの名無しさん 2025/05/31(土) 09:48:40.29 ID:Wfh15HZ5]

お前ら実際なにを作ってるんだ？

[219 デフォルトの名無しさん 2025/05/31(土) 09:57:47.44 ID:vZiA6X1v]

>>216
GTKを使えば安心だね

[220 デフォルトの名無しさん 2025/05/31(土) 10:02:14.58 ID:Wfh15HZ5]

お前ら実際なにを作ってるんだよ？

[221 デフォルトの名無しさん 2025/05/31(土) 10:22:32.58 ID:nmv5+SMF]

今から作る物が最終的にどうなるかは不明であいまいで文系みたいだから
理系は既に作られた物の話ばかりするんじゃないか

[222 デフォルトの名無しさん 2025/05/31(土) 10:35:49.28 ID:drfCYGUr]

>>213
>色んなものがRust製になっていってる要因は開発のしやすさではないか
一行で二度の突っ込みどころ。

[223 デフォルトの名無しさん 2025/05/31(土) 10:35:50.89 ID:CY+qZmOP]

Rust製のネイティブレンダリングは全滅だな

webviewレンダリングならユーザーベースも実績も少ない新興ライブラリを選びたくない
まだまだα版のお試し期間

[224 デフォルトの名無しさん 2025/05/31(土) 10:46:57.33 ID:drfCYGUr]

CやC++を大規模プログラミングで長年使ってきた経験を持つ自分には、
・メモリー安全性が問題になったことは少ない。
・Rustの構文は好きになれない。

[225 デフォルトの名無しさん 2025/05/31(土) 11:31:04.08 ID:BT0xlZs3]

さすがに未だにメモリ安全なんて無くても平気ってのは現状認識的にどうかと・・・
Bjarne StroustrupですらC++にメモリ安全が組み込めなければ未来はないって言ってるのに

[226 デフォルトの名無しさん 2025/05/31(土) 11:45:03.07 ID:bDBUs6R8]

いくらメモリが安全でもさすがにlinuxコマンドの置き換えしかできないRustは無理

[227 デフォルトの名無しさん 2025/05/31(土) 11:48:13.96 ID:Wfh15HZ5]

win10のころだけどwindowsのコードが500GBあって400万ファイルあるらしい
それが全て有用で重複がないとは言えないけどそういうのを置き換えるのは事実上不可能に近い

今後も開発が続いてコードは増えていくだろうけど本当の意味での置き換えは難しい

[228 デフォルトの名無しさん 2025/05/31(土) 11:56:42.72 ID:r5FVVu+x]

>>226
この5chでのやりとりすら毎日1兆回のリクエストを処理するRust製のPingoraのおかげ

[229 デフォルトの名無しさん 2025/05/31(土) 11:58:51.14 ID:Wfh15HZ5]

>>228
なんやかんやあったけど5chがあるのはひろゆきのおかげだね
Rust以上に凄いねひろゆきは

[230 デフォルトの名無しさん 2025/05/31(土) 12:11:48.87 ID:3vD6seHF]

MicrosoftはWindows 11 24H2からカーネルをRustで置換し始めてる
OS全部を置換する気はないだろう
重要な部分だけだろうね

[231 デフォルトの名無しさん 2025/05/31(土) 12:17:37.85 ID:r5FVVu+x]

>>229
5chはCDN世界シェアTOPのCloudflareに全面依存
全トラフィックがRust製のPingoraを通る

[232 デフォルトの名無しさん 2025/05/31(土) 12:20:42.77 ID:Wfh15HZ5]

>>231

じゃあ5chがPingoraを通ってなかった時期はひろゆきはすごくなかったという認識なの？
変わってるね

[233 デフォルトの名無しさん 2025/05/31(土) 12:22:07.47 ID:74ZBElLo]

>>230,231
なおrya

「Firefox」の開発リポジトリが「GitHub」に移行
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2013958.html
https://github.com/mozilla-firefox/firefox
JavaScript 28.5%
C++ 28.1%
HTML 22.0%
C 10.5%
Python 2.9%
Kotlin 2.5%
Other 5.5%

[234 デフォルトの名無しさん 2025/05/31(土) 12:28:29.47 ID:Wfh15HZ5]

FireFoxのスレはずいぶん前からただの不具合報告スレみたいになってる

[235 デフォルトの名無しさん 2025/05/31(土) 12:29:23.56 ID:k/HRtZBH]

>>227
なぜWindowsに「Rust」を使うのか？　C、C++から移行するMicrosoftの狙い
https://techtarget.itmedia.co.jp/tt/spv/2505/16/news01.html

[236 デフォルトの名無しさん 2025/05/31(土) 13:00:43.43 ID:dwXs6n8j]

ヒープヒープうるさいわ

Performance: Heap usage and allocation on rav1d is significantly higher than on original dav1d code #1419
https://github.com/memorysafety/rav1d/issues/1419

[237 デフォルトの名無しさん 2025/05/31(土) 13:02:18.62 ID:Wfh15HZ5]

RustコーダーをMSがどの程度抱えているのかによって話は変わる

C#が開発されてC#で.net frameworkが作られた際に当然ながらC#プログラマと言うのは存在しなかった
MS内部にはJAVAプログラマは大量におらずC++プログラマが当てられたのだろう

.net frameworkのソースコードが公開されるとC++プログラマらしきコードが多数含まれていた

[238 デフォルトの名無しさん 2025/05/31(土) 13:04:47.81 ID:k/HRtZBH]

Microsoft CTOによるRust利用最新状況
https://www.linkedin.com/pulse/inside-microsofts-rust-revolution-ctos-vision-safer-code-developrec-q366e/

[239 デフォルトの名無しさん 2025/05/31(土) 13:07:16.14 ID:a3/V91sF]

RustなんかMSにいるレベルのC++プログラマなら楽勝でしょ
上で話題になってたeditの開発者もRust初めてみたいだし

[240 デフォルトの名無しさん 2025/05/31(土) 13:18:03.82 ID:Wfh15HZ5]

>>239
過去にZigのコードメンテナーというかチーフみたいな位置にいた人らしいけど
そういう量産型じゃない人が一部にいて全体の品位がわかるとは思えない

windowsのコア部分はCでC++ですらないらしいけど

[241 デフォルトの名無しさん 2025/05/31(土) 13:22:11.35 ID:3vD6seHF]

アイリスオーヤマ傘下に入ったロボットベンチャーもRustを採用してるらしい

https://www.synchrobo.co.jp/company/
> 主なプログラミング言語として、​高効率でセキュアな言語であるRustを使用

https://www.smilerobotics.com/technology
> Rustによるロボット開発フレームワークOpenRR

[242 デフォルトの名無しさん 2025/05/31(土) 13:41:27.31 ID:9v34VQAW]

>>236
毎回スタックが～してるのはC/C++よりヒープ使うからだったのか

[243 デフォルトの名無しさん 2025/05/31(土) 13:43:03.18 ID:VyYYfbbo]

>>242
逆だ
Rust素人が不必要なArcをしてるとの指摘だ

[244 デフォルトの名無しさん 2025/05/31(土) 13:46:12.33 ID:976xRPKt]

Rustの話になると、Rustは凄い凄い、良い良い、C++は悪い悪い、の話になるから嫌。
中国人？

[245 デフォルトの名無しさん 2025/05/31(土) 13:49:01.53 ID:976xRPKt]

Rust言語そのものからは、学んでも魅力を感じてない人に対して、
「凄い人がRustを使っている」
という話ばかりがされ続けている。Linuxみたい。

[246 デフォルトの名無しさん 2025/05/31(土) 13:55:18.04 ID:uPzYXJIr]

>>243
Rust素人がやってるプロジェクトだったのか

[247 デフォルトの名無しさん 2025/05/31(土) 13:56:36.33 ID:0EZlcd7x]

>>238
Rust化で脆弱性解消だけでなくC++よりパフォーマンス向上したとCTOが明言してるな

[248 デフォルトの名無しさん 2025/05/31(土) 13:59:02.93 ID:976xRPKt]

VisualStudioも、ビルゲイツがいた頃は安定していたが、今は不安定。
そんなCTOは信頼できるのか？

[249 デフォルトの名無しさん 2025/05/31(土) 14:01:07.96 ID:976xRPKt]

今のVSは、不安定なだけでなく使いにくい。バグがある。
画面の左にあったものが右に変ったり、昔より使いにくくなっていたり、
タイトルバーに余白が少なすぎてWindowが移動できない。
この板にVSにバグがあることを報告してもオマカン扱いされる。

[250 デフォルトの名無しさん 2025/05/31(土) 14:13:03.17 ID:D0pC9gWD]

>>227
AIが急速に発展してマイクロソフトはその恩恵を最大に受けられるから、書き換えを自動化する未来はそう遠くないよ

[251 デフォルトの名無しさん 2025/05/31(土) 14:14:08.34 ID:0EZlcd7x]

>>249
VisualStudioは利用者減で優先度低くなってるのかも

[252 デフォルトの名無しさん 2025/05/31(土) 14:15:42.17 ID:fQ1g/sA4]

こんな人が
> ... recruitment business.

ここだけ抜き出す所が「複オジ品質基準」みたいになってるなw
> “If it compiles, it works”

[253 デフォルトの名無しさん 2025/05/31(土) 14:16:34.40 ID:qOsEEcP9]

VSCodeでいいや、無料だし

[254 デフォルトの名無しさん 2025/05/31(土) 14:35:21.08 ID:976xRPKt]

>>250
まだなってないわな。

[255 デフォルトの名無しさん 2025/05/31(土) 14:40:01.13 ID:29bTeRz7]

ゆるふわWebにRust使ってるようなアホはともかく、
一般的にはRustはコードをゴリゴリ書くよりも事前の検証や設計、テストの比重が大きい開発で使用されるため、
相対的にはAIに食われるのは遅いだろうね

[256 デフォルトの名無しさん 2025/05/31(土) 14:56:58.99 ID:BT0xlZs3]

現状Copilotレベルの補完すらちょっと応用的なことしようとすると使い物にならんからな
Web屋の言語と違ってVibe Codingなんて夢のまた夢

[257 デフォルトの名無しさん 2025/05/31(土) 14:57:54.14 ID:Wfh15HZ5]

>>250
今のAIだと結局人間の監査が必要だからまだまだ先かと
AIの得意とする言語はPythonなのが現状だし

[258 デフォルトの名無しさん 2025/05/31(土) 15:00:20.05 ID:0EZlcd7x]

Pythonなどスクリプト言語プログラマから不要になりそうね

[259 デフォルトの名無しさん 2025/05/31(土) 15:10:36.04 ID:Wfh15HZ5]

逆では？グルー言語は残る

[260 デフォルトの名無しさん 2025/05/31(土) 15:13:34.19 ID:BT0xlZs3]

別にバグってても何かがぶっ壊れてても、エンドユーザにバレた後で修正すればいいって感じのものなら
AIに全部生成させてもあんまり困ることないだろう

[261 デフォルトの名無しさん 2025/05/31(土) 16:19:47.05 ID:976xRPKt]

>>260
あれだけメモリ安全性に固執しておいて、バグッててもOK的な姿勢とは。

[262 デフォルトの名無しさん 2025/05/31(土) 16:23:22.78 ID:0EZlcd7x]

>>261
消え行くスクリプト言語の話だろ

[263 デフォルトの名無しさん 2025/05/31(土) 16:35:20.26 ID:Wfh15HZ5]

単純に関数名などで用途がわかって実行できる言語が有利だと思うけどね
rustはそうはいかない

[264 デフォルトの名無しさん 2025/05/31(土) 16:37:33.86 ID:0EZlcd7x]

>>263
プログラマがAIで不要になる話だよ

[265 デフォルトの名無しさん 2025/05/31(土) 16:46:59.83 ID:/yGsmgz4]

第1段階 スクリプト言語はAIのみが生成の時代へ
第2段階 AIはもっと速い言語のコードを生成へ

[266 デフォルトの名無しさん 2025/05/31(土) 17:00:21.29 ID:vaxfTYLN]

RustにとってAIによる目先の脅威は、既存物のRustへの書き換えの作業のうちコーディングが自動化されて人間はテストばかりやらされるようになることじゃないかな
書き換えなんてAIが最も得意とするタスクで、Rustでも十分な精度が出る
書き換えは単純作業なので人間にとっては脳内麻薬ドバドバなのに、その気持ちいい部分がAI化されちゃうとRust触って俺スゲーしたいだけの人達がやる事なくなっちゃうよ

[267 デフォルトの名無しさん 2025/05/31(土) 17:26:37.61 ID:/yGsmgz4]

>>266
普通の人は書き換えなんてやりたくない
新たな設計や機能の改善など創造的なことが楽しい

[268 デフォルトの名無しさん 2025/05/31(土) 19:05:28.17 ID:INfHeArP]

>>267
その論でいくと書き換えAIの精度を上げていくのは楽しいんじゃないかな

[269 デフォルトの名無しさん 2025/05/31(土) 19:14:49.45 ID:Wfh15HZ5]

それはllmが何をしているのかを理解してない発言

[270 デフォルトの名無しさん 2025/05/31(土) 19:23:46.27 ID:/yGsmgz4]

遅い言語のコードを生成するのはバカげてる時代になるから速くて省メモリな言語が有利だね

[271 デフォルトの名無しさん 2025/05/31(土) 19:26:17.54 ID:nmv5+SMF]

悪いリファレンスカウントとヒープを使っていてもあれはライブラリだから
言語は悪くも良くもならないという中立性に魅力がある

[272 デフォルトの名無しさん 2025/05/31(土) 21:52:40.30 ID:YcA/fePE]

ワナビおじさん

[273 デフォルトの名無しさん 2025/05/31(土) 21:56:37.03 ID:hZhWOomP]

>>236,243
指摘した人も指摘しただけで
マルチスレッド対応したままArcやめるPRは出してないな

[274 デフォルトの名無しさん 2025/06/01(日) 01:44:05.23 ID:HqUXKEdT]

Linux 6.15リリース：486クラスCPUサポート終了でRust統合加速
https://innovatopia.jp/uncategorized/55816/

[275 デフォルトの名無しさん 2025/06/01(日) 08:13:47.82 ID:4sBAU+Od]

コマンドを作った奴は本当は喉から手が出るほどGUIがほしいんでしょ
ほしがれー

[276 デフォルトの名無しさん 2025/06/01(日) 08:47:16.18 ID:3zBjeqMb]

BionicGPTもそのGUIのDioxusもRust製
https://github.com/bionic-gpt/bionic-gpt

[277 デフォルトの名無しさん 2025/06/01(日) 08:52:33.88 ID:zL90snIl]

実用レベルのGUIアプリはどれもWebブラウザを使ってる奴か

[278 デフォルトの名無しさん 2025/06/01(日) 09:00:06.64 ID:3zBjeqMb]

>>277
DioxusはTauriやElectronのようなWebブラウザJavaScript依存とは違って純Rust

[279 デフォルトの名無しさん 2025/06/01(日) 09:01:28.49 ID:oe0B6NCW]

文字合成とかまで含めてきちんと UNICODE の全部をサポートしようとするとおおごとだからなぁ……
OS (または実質的に OS の一部のようなミドルウェア) が提供する機能のラッパーという形にしてもらったほうが安心できる。

[280 デフォルトの名無しさん 2025/06/01(日) 09:03:49.22 ID:3zBjeqMb]

>>277
DioxusはTauriやElectronのようなWebブラウザではない
JavaScript依存もなくピュアRust

[281 デフォルトの名無しさん 2025/06/01(日) 09:19:26.30 ID:uL2Wr00R]

>>280
現実は非情
https://dioxuslabs.com/learn/0.6/guides/desktop/#
> Apps built with Dioxus desktop use the system WebView to render the page.

Rustのコード自体はwasmじゃなくてネイティブで動くらしいから、頑張って慣れない英語読もうとしてそのあたりの説明を勘違いしちゃったんだろうね
健気で哀れな複おじ

[282 デフォルトの名無しさん 2025/06/01(日) 09:33:24.37 ID:3zBjeqMb]

>>281
違いが理解できない？
ElectronとTauriはブラウザそのものでJavaScript依存
Dioxusは純Rust

[283 デフォルトの名無しさん 2025/06/01(日) 10:02:51.51 ID:4sBAU+Od]

XAMLみたいなのはスクリプトじゃなくてデータだから純度が下がらないというのはまあわかる
じゃあCSSは

[284 デフォルトの名無しさん 2025/06/01(日) 10:03:09.02 ID:F948rj57]

>>282
ElectronのJSランタイムは基本Node.jsで、オプションとしてブラウザ側も使用できる
Tauriも同様に、Rustコードの実行はネイティブ
上記のリンクにも記述のある通り、Dioxusはブラウザ側のDOMやjs/wasmにアクセスする手段がなく、その点で機能性が劣っていると言えるが、本質的には現時点ではElectronやTauriと大きな違いはない

[285 デフォルトの名無しさん 2025/06/01(日) 10:14:51.82 ID:zL90snIl]

>>284
さっきのURLに document::eval() でDioxusはブラウザ側jsにアクセスできるって書いてあるじゃん

[286 デフォルトの名無しさん 2025/06/01(日) 10:16:54.42 ID:0BZHKwCC]

>>284
全く異なる
Dioxusはマルチプラットフォーム
desktop platformの時のみwebviewを使う

[287 デフォルトの名無しさん 2025/06/01(日) 10:20:48.90 ID:wOKtdl9D]

単純にWebに載せるやつのほうが機能が充実してるしフレームワークのメンテナも利用者も多い
あと流行りのデザインやアニメーションを容易に組めるのが一番でかい
こういうとRustじゃない～て暴れられるけどGUIとロジックで役割分担してるだけなんよ

[288 デフォルトの名無しさん 2025/06/01(日) 10:38:08.36 ID:F948rj57]

>>286
stableな実装は現状どのプラットフォームでもWebブラウザベースのみだよ
DOMとCSSが独自仕様なFlutterと違ってDioxusは仕様上HTML/CSSに依存してるんで、脱WebViewしようとすれば結局自前でブラウザを実装する必要があり、
互換性は全く期待できないしパフォーマンスでWebViewに勝つのも相当厳しいだろうな

[289 デフォルトの名無しさん 2025/06/01(日) 10:42:10.51 ID:0BZHKwCC]

>>288
いいえ
Dioxusがwebviewを使うのはdektopのみ

[290 デフォルトの名無しさん 2025/06/01(日) 10:46:19.31 ID:F948rj57]

>>289
https://dioxuslabs.com/learn/0.6/guides/mobile/
> Mobile is a first-class target for Dioxus apps, with a robust WebView implementation that supports CSS animations and transparency effects.
> Mobile apps are rendered with either the platform's WebView or experimentally with WGPU.

[291 デフォルトの名無しさん 2025/06/01(日) 10:50:53.13 ID:OE0EnsgK]

DioxusはAndroidもiOSも対応してるのか
なかなか良さそうだな

[292 デフォルトの名無しさん 2025/06/01(日) 10:53:22.67 ID:4sBAU+Od]

互換性ねえ
JVMと完璧な互換性のあるScalaみたいなのをまた作りたいのか

[293 デフォルトの名無しさん 2025/06/01(日) 10:59:10.87 ID:OE0EnsgK]

Androidではjni-rs使ってRustで書けるのね

[294 デフォルトの名無しさん 2025/06/01(日) 11:27:32.43 ID:P0zCx+Hv]

>>287
Rustで一番書きたいのは、ビジネスロジックというかバックエンド側だし
今現在GUIの表現において、一番大量の資産と表現力があるのはWebブラウザだから、あんまりそっちをRustでこだわるうまみって薄いんよな
Excelだってテキストエディタだってもうブラウザベースでやれてんだし

ハード屋でもないなら、どうせフロントには一切触れないとかありえないからそっち方面の資産は持ってるだろってのもある

[295 デフォルトの名無しさん 2025/06/01(日) 12:35:57.00 ID:qAHg6uzj]

偏見だけどそもそもRustを好むような人ってフロントやりたがらない印象がある

[296 デフォルトの名無しさん 2025/06/01(日) 13:03:57.46 ID:MiYIiKjY]

DioxusもwebviewレンダリングじゃなければIME部分を含めバグだらけなのでまだまだ使い物にならないよ
どのライブラリもwinit依存が多いからバグも共有してるものが多い

>あれだけメモリ安全性に固執しておいて、バグッててもOK的な姿勢とは。
これは耳が痛いね

[297 デフォルトの名無しさん 2025/06/01(日) 14:36:26.65 ID:f44LlI2e]

>>296
バグどれよ？

[298 デフォルトの名無しさん 2025/06/01(日) 15:24:01.36 ID:ljy8kuAt]

>>296,297
ちょっとおねだりが過ぎませんか？w

dioxusは不合格でした
https://i.imgur.com/EcQtVvZ.png

[299 デフォルトの名無しさん 2025/06/01(日) 15:31:33.86 ID:ljy8kuAt]

platformはデフォルトのdesktop

WebView2 Managerが起動するので
> Render using Webview or - experimentally - with WGPU or Freya (Skia)
の内Webview backendかと

ウィンドウ移動やフォーカスを変えたりすると>>298になります

[300 デフォルトの名無しさん 2025/06/01(日) 15:35:54.01 ID:f44LlI2e]

>>298
それの何が問題なの？

[301 デフォルトの名無しさん 2025/06/01(日) 15:40:02.37 ID:x1YbBh3g]

>>298はDioxus TodoMVCのテキスト入力ボックスにフォーカスがあります

逆にWebViewでここまでひどいとは思いませんでした

フォント 中華
インライン入力 可
再変換 可
再フォーカス後 オンオフ状態リセット、入力途中文字も消える

[302 デフォルトの名無しさん 2025/06/01(日) 15:43:26.55 ID:x1YbBh3g]

>>296,298
WebView内で閉じた処理はブラウザベースなので良いのでしょうが(中華フォント以外)
WebViewと橋渡しする処理がバグっているのでしょう

[303 デフォルトの名無しさん 2025/06/01(日) 16:18:17.18 ID:fAD5kDB0]

まじで？
それタイミング関係なく常に発生する？

[304 デフォルトの名無しさん 2025/06/01(日) 16:46:42.32 ID:6daCzUqz]

>>298の画像を見ても問題があるように見えない
重箱の隅を突くようなバッシングをしてる？

[305 デフォルトの名無しさん 2025/06/01(日) 16:53:14.17 ID:2J1lKbXS]

ウィンドウ移動ですかね、>>298 バグのトリガー

正常動作(IMEオンしないパターン)
TodoMVC起動(自動的にテキストボックスに入力フォーカス)
タイトルバーをつまんでウィンドウを少し移動(入力フォーカスはテキストボックスのままカーソル点滅もしている)
キーボード入力
テキストボックスに反映される

異常動作(IMEオンするパターン)
TodoMVC起動(自動的にテキストボックスに入力フォーカス)
FEP切り替え
IMEオン
タイトルバーをつまんでウィンドウを少し移動(入力フォーカスはテキストボックスのままカーソル点滅もしている)
キーボード入力
デスクトップ左上に位置に入力エコーバックと変換候補ウィンドウ

起動後の初回IMEオン以外でも
テキストボックスフォーカス&IMEオンのまま、ウィンドウを移動、キーボード入力したら再現するかと

[306 デフォルトの名無しさん 2025/06/01(日) 16:59:11.99 ID:oe0B6NCW]

>>304
アプリが IME に非対応なときは IME の側で離れた場所に窓を開いて対処する仕組みになってる。
つまりこれはアプリが IME のサポートを(充分には)していない図。

[307 デフォルトの名無しさん 2025/06/01(日) 16:59:40.03 ID:6daCzUqz]

>>305
その動作の何が問題なのかな
webviewを使ってる数多のアプリでの動作は？

[308 デフォルトの名無しさん 2025/06/01(日) 17:01:32.91 ID:2E2nBA/3]

>>307
自分でVSCodeで試してみたらいいでしょ
いくらRustエアプでもそれくらいはすぐできるだろ？

[309 デフォルトの名無しさん 2025/06/01(日) 17:07:21.32 ID:4sBAU+Od]

コーディングができるのは玄人だけだがインストールと設定は素人でもできる
という認識と
フォントが文字化けしたりする現実が乖離してるんじゃないか

[310 デフォルトの名無しさん 2025/06/01(日) 17:13:02.27 ID:6daCzUqz]

>>308
Microsoft管轄のと比較しても意味ない
もっと単純な比較をすべきだ

[311 デフォルトの名無しさん 2025/06/01(日) 17:21:03.72 ID:2E2nBA/3]

>>310
だったらSlackで試したらいい
Rust経験ないのは仕方ないとしてもプログラミング自体完全エアプじゃなきゃさすがに入ってるだろ

[312 デフォルトの名無しさん 2025/06/01(日) 17:26:45.46 ID:6daCzUqz]

なぜデカいのと比べようとする？
もっと単純な比較にしとけよ

[313 デフォルトの名無しさん 2025/06/01(日) 17:34:03.73 ID:WYn8l9li]

>>305
なるほどありがとう
普通のWebViewアプリやブラウザでは再現しないから何かバグってるんだな
WebViewに全部まかせてるわけじゃないのか

[314 デフォルトの名無しさん 2025/06/01(日) 17:41:33.42 ID:bcDCNWwh]

比較がおかしい
WebViewを使うGUIフレームワーク同士を比較しないと意味がない

[315 デフォルトの名無しさん 2025/06/01(日) 18:16:51.61 ID:7HYVfiGT]

いまだにまともなGUI一つ作れないっておかしくね？

[316 デフォルトの名無しさん 2025/06/01(日) 18:29:20.11 ID:qAHg6uzj]

>>314
TauriでもElectronでもWailsでも、サンプルに入ってるような小さなアプリをビルドすれば分かるんじゃない？

[317 デフォルトの名無しさん 2025/06/01(日) 18:38:52.12 ID:EuGkxJef]

>>315
誰も気にしていないどうでもいいことで叩き合ってるだけ
GUIは多数あり実用に使われている

[318 デフォルトの名無しさん 2025/06/01(日) 18:45:14.37 ID:DK16msZE]

>>317
果たしてそうだろうか。

[319 デフォルトの名無しさん 2025/06/01(日) 18:49:41.21 ID:Afq2fQNa]

>複オジの品質基準では「何の問題もない」
>一般的な品質基準では「問題ありまくり」

これに尽きる

[320 デフォルトの名無しさん 2025/06/01(日) 19:12:46.36 ID:4sBAU+Od]

GUIを好む人はバグを再現する最小のコードを書きたがらない
反GUIの人はバグがなくても最小のコードを書いてる

[321 デフォルトの名無しさん 2025/06/01(日) 19:12:53.21 ID:F948rj57]

Rustに限らずGUIフレームワーク全般に言えることなんだけど、優秀なプログラマほどGUIを使わなくなるから、
ボランティアベースのGUIフレームワークってロクなの無いんだよね。
実際、Rustで成功しているGUIアプリの代表的な例として、ターミナルエミュレータがある。
Rust製のAlacrittyやWezTermはターミナルエミュレータとしては非常に人気があり、日本語も問題ない。

[322 デフォルトの名無しさん 2025/06/01(日) 19:29:51.30 ID:pwCmtyNg]

Alacritty スクショ
https://i.imgur.com/rDqVWcO.png

[323 デフォルトの名無しさん 2025/06/01(日) 19:32:30.27 ID:qAHg6uzj]

Rustで書くことが目的化してる人に何を言っても変わらないでしょ
ちょっとくらい見た目や動作に問題があっても、Rustで作られてるならそちらの方が優れてる的な価値観なわけだし
普通の人は逆で、作りたいものが先にあって、それを達成するのにどの道具が良いかを検討するものなんだけど

[324 デフォルトの名無しさん 2025/06/01(日) 20:23:59.45 ID:/r9EZP3i]

基本的な入力動作すらまともに動かなくてもメモリ安全であればいいんでしょ
そんなアプリを誰が使うのか

[325 デフォルトの名無しさん 2025/06/01(日) 20:31:34.92 ID:EOVsDC2W]

>>322
さすがにこの状態でまともに使えるとは言わんよ
手元の環境ではこんなことにはならないからAlacritty使ってるけど

[326 デフォルトの名無しさん 2025/06/01(日) 21:05:48.26 ID:P1xiFI4O]

>>322
それおまえの環境がおかしいんじゃね？
こちらでは起きない
そんな問題も上がっていない

[327 デフォルトの名無しさん 2025/06/01(日) 21:07:24.61 ID:P0zCx+Hv]

Rustのような新興システムプログラミング言語の優位性を
業務アプリすらWebばっかで、デスクトップ開発の需要自体が死んでる令和の時代になぜかデスクトップGUIフレームワークなんかで決めようとしてる時点で
Rustはクソ言語C++のほうが優れてるみたいな感じに持ってくのがゴールなんだよね

[328 デフォルトの名無しさん 2025/06/01(日) 21:13:17.99 ID:gyZ55+5M]

安心安全のはずのRustがGUIではバグだらけ
不思議

[329 デフォルトの名無しさん 2025/06/01(日) 21:15:37.04 ID:P1xiFI4O]

>>328
バグがあるなら示してみろ

[330 デフォルトの名無しさん 2025/06/01(日) 21:20:41.09 ID:oe0B6NCW]

示されてるのに「こちらではおきない」で無かったことにしてるのはお前だろ。

[331 デフォルトの名無しさん 2025/06/01(日) 21:34:08.02 ID:t7W26l2E]

Alacrittyは人気のターミナルエミュレータでもう9年目だけどそんなバグは聞いたことないな

[332 デフォルトの名無しさん 2025/06/01(日) 21:35:32.32 ID:zL90snIl]

>>305
Tauri v2もこのウィンドウ移動によるバグがあるけど誰も指摘しないから
これぐらいの軽度バグは世間的には許されるってことじゃないか？
日本語対応は100点満点じゃないけど70点ぐらいはある

[333 デフォルトの名無しさん 2025/06/01(日) 21:49:21.86 ID:P0zCx+Hv]

IME使った文字の入力中にウインドウを移動するっていうユースケースが、どれだけ日常かという話

[334 デフォルトの名無しさん 2025/06/01(日) 21:52:14.83 ID:vHN87OYL]

>>333
>>305の手順では必ずしも文字の入力中ではない様だけど

[335 デフォルトの名無しさん 2025/06/01(日) 21:58:36.70 ID:vHN87OYL]

>>332
そう自分で直すのが面倒だから見て見ぬふりするね
使うだけの側からしたら代わりは幾らでもある、そっと閉じ

[336 デフォルトの名無しさん 2025/06/01(日) 22:02:27.70 ID:t7W26l2E]

Rustを叩きたい人が通常ではありえない使い方をして無理やりにAlacrittyを批判してるだけか

[337 デフォルトの名無しさん 2025/06/01(日) 22:22:04.75 ID:/r9EZP3i]

脆弱性もありえない使い方すると出てくるんでは
メモリ安全だからロジックに集中できて完成度があがるはずじゃなかったんすかｗ

[338 デフォルトの名無しさん 2025/06/01(日) 22:28:33.11 ID:EOVsDC2W]

Windows11のAlacrittyでIME入力中にウィンドウ移動しても普通に追従するけどな
環境と再現手順を知りたいところ

[339 デフォルトの名無しさん 2025/06/01(日) 22:34:44.87 ID:4sBAU+Od]

Rustのコードが1行もないソフトに同じバグがあればとりあえず安心

[340 デフォルトの名無しさん 2025/06/01(日) 22:38:36.61 ID:6z/uSzky]

>>322,338

Alacritty 異常動作(IMEオンするパターン)
Alacritty起動
IMEオン
タイトルバーをつまんでウィンドウを少し移動
キーボードでa
デスクトップ右下に変換候補ウィンドウ

Windows11

[341 デフォルトの名無しさん 2025/06/01(日) 22:42:20.46 ID:6z/uSzky]

>>338
変換候補ウィンドウが出た後にAlacrittyウィンドウを移動するのではなく
>>340の順番通りにやると再現率半分くらい
(IMEオンはAlt+`)

[342 デフォルトの名無しさん 2025/06/01(日) 22:43:57.89 ID:6z/uSzky]

Microsoft IME
旧バージョン互換性オプションオフ

[343 デフォルトの名無しさん 2025/06/01(日) 22:45:30.38 ID:6z/uSzky]

再現率が半々で、ウィンドウを移動しなくても時々発生するので
ウィンドウを移動が根本原因ではない可能性もあるかと

[344 デフォルトの名無しさん 2025/06/01(日) 22:46:29.92 ID:HyrzgXWk]

tao（tauri版winit）の実装見たけど少なくともWindowsのIMEはあまりやる気ないな
WM_IME_*が↓でしかヒットしないしWM_IME_REQUESTもWM_IME_CONTROLも出てこない

https://github.com/tauri-apps/tao/blob/dev/src/platform_impl/windows/minimal_ime.rs

winitも同じかな

[345 デフォルトの名無しさん 2025/06/01(日) 22:46:30.67 ID:6z/uSzky]

今の所、WezTermでは同様のバグは発生してないですね

[346 デフォルトの名無しさん 2025/06/01(日) 22:51:47.81 ID:6z/uSzky]

>>343
再現率低いAlacritty 異常動作(IMEオンするパターン)

Alacritty起動
IMEオン
キーボードでa
デスクトップ右下に変換候補ウィンドウ

[347 デフォルトの名無しさん 2025/06/01(日) 22:57:05.24 ID:UP9ZJCIN]

今度はAlacrittyですか…
>Alacrittyはパフォーマンスとシンプルさを重視した自由かつオープンソースのGPUアクセレレーション端末エミュレータである。
知らんがな

[348 デフォルトの名無しさん 2025/06/01(日) 23:03:02.79 ID:EOVsDC2W]

>>340
おお、確かになるね
IMEオン状態のままだとならないから切り替え直後の1回だけって感じ？
ここ数年常用してて見たことないし、うちの環境ではウィンドウ移動なしでは発生しないっぽいかな

[349 デフォルトの名無しさん 2025/06/01(日) 23:11:44.02 ID:0CmIhd20]

>>340
Rustを叩くためにそんなありえない使い方をして深刻なバグだと吹聴していたとは呆れた

[350 デフォルトの名無しさん 2025/06/01(日) 23:15:24.99 ID:7HYVfiGT]

Rustは安心安全
※ただしありえない使い方をしない時にかぎる

[351 デフォルトの名無しさん 2025/06/01(日) 23:45:33.58 ID:sQgPtell]

ありえおじ

[352 デフォルトの名無しさん 2025/06/01(日) 23:46:59.52 ID:0CmIhd20]

>>350
ありえない使い方をしても問題ないことをRust叩きしてる人が証明してくれた

[353 デフォルトの名無しさん 2025/06/02(月) 00:05:41.71 ID:fXikgHg9]

ミニマム再現条件にすると滑稽ですが
好みの位置にウィンドウを持って来るのは普通の事なので(デスクトップ)
ありえない使い方と言うよりも、windowsでネイティブ日本人がテストしてないのか?品質に出ていますね

「ウィンドウ移動する前には、IMEはオフにせよ」なんて使用条件の方が変かと

[354 デフォルトの名無しさん 2025/06/02(月) 00:06:41.28 ID:fXikgHg9]

>>348
確認できたのはそのパターンです、自分は常用してないので他のバグ発生条件までは分かりませんね
(念のためPowerToysを落としても状況は同じだった)

Dioxus TodoMVCの方はIMEオン直後だけではなくウィンドウ移動後の1キー目で>>298こうなります

[355 デフォルトの名無しさん 2025/06/02(月) 00:07:15.73 ID:fXikgHg9]

>>332,335
ターミナルで日本語入力する事自体が稀なのでAlacrittyには70点あげても良いですが
Dioxusは「そっと閉じ」の方ですね

[356 デフォルトの名無しさん 2025/06/02(月) 00:09:31.08 ID:9UmaDGug]

>>355
じゃあ、Dioxusでターミナル作ったら？

[357 デフォルトの名無しさん 2025/06/02(月) 00:11:29.28 ID:fXikgHg9]

>>344
納得しましたw

[358 デフォルトの名無しさん 2025/06/02(月) 00:13:19.40 ID:fXikgHg9]

>>355
Readmeみたらそっと閉じ

windowsでの品質は現時点も先々もこんな感じなんですかね

[359 デフォルトの名無しさん 2025/06/02(月) 00:18:26.39 ID:Z4CT4v88]

Windowsを使う人は滅多にいないだろうしな
普通はLinuxかMac

[360 デフォルトの名無しさん 2025/06/02(月) 00:33:24.53 ID:FhxrXIqd]

人間の頭から放電した場合は下記の経路になる
人間は電磁界【脳波８Hz〜４０Hz】【電線【６０Hz】の電圧と同じ】なので周囲に影響を与えれる範囲が狭い

人体への雷撃パターン ｜身を守る｜ 雷の知識
https://www.franklinjapan.jp/raiburari/knowledge/safety/61/
超低周波電磁界にばく露した人体に起きる電磁的現象
https://www.jeic-emf.jp/public/web_mag/explanation/1016/

1 人間の頭部から放電しないことはここで説明されている
2 お風呂場で湯船につかっているのでお湯の方に電流が流れる
3 頭からお湯をかぶっているやシャワーを浴びている場合はお湯にそって電流が流れる
4 雨降りの時は雨によって地面の方に電流が流れる
5 何か物に接している【手で手すりを触っているなど】場合はその者にそって電流が流れる

などこれらの条件がそろっているのに外部の人が対象者の思考や動作がわかるはおかしなことを話している

[361 デフォルトの名無しさん 2025/06/02(月) 01:35:42.19 ID:d/cxZYnc]

>>321
何を言ってるんだか。

[362 デフォルトの名無しさん 2025/06/02(月) 02:03:54.92 ID:wOJOfP6S]

Windowsのtauriは余計なことしないでwebview2に丸投げすればIMEは普通に動きそうな気がするんだけど
クロスプラットフォームの抽象化があるから単純ではないのかな

[363 デフォルトの名無しさん 2025/06/02(月) 07:27:24.42 ID:GgLxuemZ]

>>359
GUIアプリってプログラマでなく一般ユーザーに使ってもらうために作るものじゃないの？
シェア率が70%もあるWindowsを「滅多に使わない」？

[364 デフォルトの名無しさん 2025/06/02(月) 08:02:49.76 ID:zmXNsHtd]

どちらかというとIME切り替えながらウィンドウ動かす、というのがないかな…
数年間毎日使って気付かなかったし正直どうでもいい
直してくれるならそれに越したことはないけども

[365 デフォルトの名無しさん 2025/06/02(月) 08:51:42.98 ID:h4tRZExf]

いや、ウィンドウズはほぼ毎日使うよ
会社でも同じだわ

[366 デフォルトの名無しさん 2025/06/02(月) 10:49:02.15 ID:XWrf3Dm6]

IDEなら編集しながらコンパイルしてるから不愉快な挙動をするのは火を見るより明らか

[367 デフォルトの名無しさん 2025/06/02(月) 11:11:49.92 ID:NteO/GBi]

>>293
Rustに限らずZigとかC#とか、extern cできる言語ならなんでもAndroidで使えるよ
Androidのjniやndkに全部C互換があるから

[368 デフォルトの名無しさん 2025/06/02(月) 11:15:54.47 ID:aX5lnsqr]

出来るけど公式にサポートしているもののほうが楽ではある。

[369 デフォルトの名無しさん 2025/06/02(月) 12:21:45.02 ID:yqv+vYMm]

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

[370 デフォルトの名無しさん 2025/06/02(月) 12:27:33.61 ID:XWrf3Dm6]

オールド公式とニュー公式どっちを選ぶかは結局自分で判断するしかない

[371 デフォルトの名無しさん 2025/06/02(月) 13:03:04.42 ID:cfmG04/d]

再現方法を見てウィンドウ動かさなければ問題ないだろうと考える人は経験が浅すぎるわな
そういう感覚で物作ってると行き着くところは「複オジ品質基準」だぞ

[372 デフォルトの名無しさん 2025/06/02(月) 13:17:30.01 ID:aX5lnsqr]

わかった上で重大ではない (から放置で良い) と判断することはあるだろうけど……
そういう小さなことが積み重なってよくわからん挙動を引き起こすこともそれなりにある話。

[373 デフォルトの名無しさん 2025/06/02(月) 14:20:48.94 ID:w8zlJvU9]

>>369
困るとそれを貼り付けるね

[374 デフォルトの名無しさん 2025/06/02(月) 14:21:05.82 ID:czhP5p30]

>>369
やはりサーバー分野はRustが最強だな

[375 デフォルトの名無しさん 2025/06/02(月) 14:21:43.53 ID:czhP5p30]

>>373
どゆこと？

[376 デフォルトの名無しさん 2025/06/02(月) 14:31:27.48 ID:czhP5p30]

373がなにを否定したいのかよく分からないがRustの並列処理は非常に効率がよい
Rustで再開発することによりこの恩恵を受けて大幅に性能が向上した
今回AWSが正式リリースしたAurora DSQLは並列処理に重きをおいたものだから特に高い効果を得られたのだろう

[377 デフォルトの名無しさん 2025/06/02(月) 14:41:07.84 ID:XWrf3Dm6]

カオスは初期値だけで引き起こせるんだよね
途中の小さな積み重ねは原因ではなく結果

[378 デフォルトの名無しさん 2025/06/02(月) 14:49:11.87 ID:z+CFOxG+]

KotlinというかJavaの並行処理はむっちゃ安全だけどその代わりにパフォーマンスが犠牲になってる。
C++のはパフォーマンスが良いけどみんなご存知のように安全性がゴミ。
Goのはパフォーマンスも安全性もいいからRustかGoのどちらを使うかでRustが選ばれたんでしょ知らんけど。

[379 デフォルトの名無しさん 2025/06/02(月) 15:15:13.25 ID:z+CFOxG+]

俺が考察せずともAWSの当事者の後日談的な記事あるじゃん。
KotlinのJVMのガベージコレクションのオーバーヘッドが敵だったみたいね。
もともとKotlinのスペシャリストであってRustは初心者だった開発チームが苦労の果てにコンパイル可能なコードを実行してみたらなんとKotlinで書いていたコードの10倍性能がよかった。
気分を良くした開発チームがどんどんKotlinのコードをRustに書き換えていったんだって。

Just make it scale: An Aurora DSQL story
https://www.allthingsdistributed.com/2025/05/just-make-it-scale-an-aurora-dsql-story.html

[380 デフォルトの名無しさん 2025/06/02(月) 15:31:24.30 ID:AD6qUyw7]

そんでこれはオープンソースなのか?

[381 デフォルトの名無しさん 2025/06/02(月) 15:53:39.10 ID:z+CFOxG+]

CLI部分はオープンソースだよ

[382 デフォルトの名無しさん 2025/06/02(月) 15:55:37.90 ID:3XGAbOaK]

本体をオープンソースにしろよw

[383 デフォルトの名無しさん 2025/06/02(月) 15:58:30.64 ID:bKFtipAC]

>>378
単に会社の方針としてJavaかKotlinかC/C++かRustで、Goは選択肢にないんだろう
379の元記事読んだけど技術選定の際に社内実績をかなり重視してそうだし、そもそも制約がなきゃKotlinなんか選ばないでしょ

[384 デフォルトの名無しさん 2025/06/02(月) 15:59:31.58 ID:WAnrQ9FR]

>>378
Goは同じくガベージコレクションのある言語だから厳しい

[385 デフォルトの名無しさん 2025/06/02(月) 16:03:48.59 ID:z+CFOxG+]

やはり敵はガベコレにあり。

[386 デフォルトの名無しさん 2025/06/02(月) 16:06:35.67 ID:qTYmSia5]

敵はオープンソース資産を食い逃げする企業だろ

[387 デフォルトの名無しさん 2025/06/02(月) 16:28:08.28 ID:owUgTJXK]

>>384
GoのGCはJVMと比較すると低遅延だから、記事の通りGCによる停止が問題になっている状況なら選択肢になりうる

[388 デフォルトの名無しさん 2025/06/02(月) 16:40:40.26 ID:k0FlxjxP]

>>387
GCによる害悪2つのうちレイテンシ悪化はGoで軽減できるが全体パフォーマンスはGoも悪化する

[389 デフォルトの名無しさん 2025/06/02(月) 16:43:17.43 ID:/ossn2s1]

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

Macではもっと遅かったしRustじゃなくてGoで良い領域だな

[390 デフォルトの名無しさん 2025/06/02(月) 16:49:07.25 ID:/ossn2s1]

>>236 >>243
Arc削除できないと返答してるな

[391 デフォルトの名無しさん 2025/06/02(月) 16:52:44.19 ID:Ca4PuVUf]

シャープ、PythonによるAIデバイス向け高位合成ツールをオープンソースで公開
https://news.mynavi.jp/techplus/article/20250602-3343055/

博報堂メディカル、生成AIを用いた審査業務効率化ソリューションを開発 [
https://news.mynavi.jp/techplus/article/20250602-3342950/

「AIをより魅力的にする戦略」がAIチャットボットに「薬物使用を促す」といった有害な考えを強化させる可能性があると研究で判明
https://gigazine.net/news/20250602-ai-chatbots-user-influence-attention/

[392 デフォルトの名無しさん 2025/06/02(月) 16:54:15.56 ID:64YfA+90]

Arcは所有者を増やすときのみカウンタ+1のオーバーヘッドがある
参照はderefによりコストゼロ

[393 デフォルトの名無しさん 2025/06/02(月) 17:21:42.21 ID:fJbPstNP]

>>390
なるほど
幸先良くスタートしたけど分かっていても直せない箇所が出て来る訳ね

[394 デフォルトの名無しさん 2025/06/02(月) 17:27:52.34 ID:64YfA+90]

所有者を増やしまくる愚を犯さない限りArcにデメリットはない

[395 デフォルトの名無しさん 2025/06/02(月) 17:49:16.64 ID:iSmTN9kp]

>>379
Aurora DSQLは、データベース管理ソフト(DBMS)であり、データを収めているのは原則としてHDDやSSD。
だから、メインメモリーは、キャッシュのために少し使う、というのが基本のはず。
だから、データ集約に関係する高度なアルゴリズムはHDD/SSDに対して必要となるが、
メインメモリに対しては余り必要ない。だから、Rustが適す。

[396 デフォルトの名無しさん 2025/06/02(月) 17:52:38.64 ID:F42JmYRi]

>>395
もうちょっと調べた方が良いよ、DB全般

[397 デフォルトの名無しさん 2025/06/02(月) 17:59:35.62 ID:iSmTN9kp]

>>396
ちゃんとした言葉で反論してください。

[398 デフォルトの名無しさん 2025/06/02(月) 18:02:50.08 ID:owUgTJXK]

>>397
Geminiに聞いてやったぞ

ご指摘のコメントは、データベースの仕組みとRustに関する理解に多くの誤解があるようです。
* DBのメインメモリ利用の認識違い: データベースはキャッシュだけでなく、データ処理やソート、インデックスなど、パフォーマンスのためにメインメモリを広範に活用します。「少し使う」というのは誤りです。
* Rust適用の理由が不適切: Rustはメモリを安全かつ効率的に制御できるため、DBのようなパフォーマンスが求められるシステム開発には適しますが、「メインメモリをあまり必要としないから」という理由は論理が破綻しています。
したがって、このコメントは技術的に見て多くの点で適切ではありません。

[399 デフォルトの名無しさん 2025/06/02(月) 18:04:48.37 ID:iSmTN9kp]

>>398
DBMSの場合、メインメモリーに置いておく集約構造は、データの量が小さい。
だから、ある程度の速度性能が出れば、全体の速度には影響が及びにくい。

[400 デフォルトの名無しさん 2025/06/02(月) 18:05:34.76 ID:iSmTN9kp]

そのGeminiの回答は、理解が浅い。

[401 デフォルトの名無しさん 2025/06/02(月) 18:06:28.04 ID:owUgTJXK]

>>399
お相手の方の返信も、やはりデータベースのメモリ利用とパフォーマンスに関する誤解が続いていますね。
主な問題点
* 集約構造のデータ量は「小さい」は誤り: データベースは、高速化のために可能な限り多くの集約データや中間結果をメモリに置こうとします。データ量が多いほど、メモリを効率的に使う必要があります。
* 「ある程度の速度」で全体の速度に影響が出にくいは誤り: メモリ上の処理が非効率だと、それが全体のパフォーマンスのボトルネックになり、特に大規模データや高負荷環境では深刻な影響が出ます。少しの遅延でも、積み重なると大きな差になります。
データベースの性能は、メモリの効率的な活用に大きく依存します。

書き込む前にAIにチェックしてもらうことをお勧めする

[402 デフォルトの名無しさん 2025/06/02(月) 18:08:30.83 ID:iSmTN9kp]

>>401
ただ、ネットで使うことが多い DBMSは、単位時間当たりの書き込み回数が小さい傾向がある。
そういう事まで含めて考えれば、あなたやGeminiの回答は理解が浅い。

[403 デフォルトの名無しさん 2025/06/02(月) 18:11:00.40 ID:iSmTN9kp]

論理ではなく、トータルの必要時間を数式で考えないといけない。

[404 デフォルトの名無しさん 2025/06/02(月) 18:13:55.93 ID:64YfA+90]

>>399
一番効果が大きいのはメモリ上のキャッシュ効果
そのキャッシュ構造管理もRustがベスト選択

[405 デフォルトの名無しさん 2025/06/02(月) 18:16:26.41 ID:iSmTN9kp]

>>404
DBMSに必要な処理の特徴が、Rustとは相性がいいとは言えるかもしれないが、
DBMS以外のアプリではもっと別の特徴が必要となることが有る。

[406 デフォルトの名無しさん 2025/06/02(月) 18:25:01.24 ID:iSmTN9kp]

>>404
「405」で「キャッシュ」という言葉を使ったが、CPUの中のキャッシュの事ではなく、
メインメモリー自体が HDD/SSDに対するキャッシュとみなせるという意味で使った。
混乱してはいけない。

[407 デフォルトの名無しさん 2025/06/02(月) 18:32:11.04 ID:iSmTN9kp]

>>406
誤: 405
正: 395

[408 デフォルトの名無しさん 2025/06/02(月) 18:40:12.36 ID:KbudeIgC]

次からスレタイ「複おじ Part31」に変えようぜ

[409 デフォルトの名無しさん 2025/06/02(月) 18:42:37.74 ID:64YfA+90]

>>406
DBはそのHDD/SDDに対するキャッシュ効果が最も効く
そのキャッシュ管理にもRustが最適

[410 デフォルトの名無しさん 2025/06/02(月) 18:44:18.26 ID:iSmTN9kp]

>>409
もちろん、KotlinやJavaよりは効くだろう。

[411 デフォルトの名無しさん 2025/06/02(月) 18:50:00.32 ID:uLOpbVD1]

>>408
別にそれでもいいよｗ
普通にRustスレ立ててもおかしな人間がやって来て自説を繰り返すだけだから

[412 デフォルトの名無しさん 2025/06/02(月) 19:31:43.37 ID:a238vP89]

それやっても自分でRustスレ立てて何事もなかったかのように振る舞うだけだと思う

[413 デフォルトの名無しさん 2025/06/02(月) 20:32:38.85 ID:ddfioDeu]

>>389
GCがあり不便なGoは適用範囲がほとんどないのよ
Goが使われている領域の狭さを見つめてね

[414 デフォルトの名無しさん 2025/06/02(月) 20:44:46.47 ID:+aIkiiO4]

将来的にオリジナルのdav1dと乖離させない様に出来るだけ1to1で移行するには良いのでは
TypeScriptコンパイラと同じ状況かと

[415 デフォルトの名無しさん 2025/06/02(月) 20:51:40.32 ID:+aIkiiO4]

書いてあるね
https://github.com/memorysafety/rav1d/issues/1419#issuecomment-2925693567
> And we'd like to keep the Rust code similar to the C code if there's no significant advantage to changing it, as this helps backporting changes from dav1d

[416 デフォルトの名無しさん 2025/06/02(月) 20:54:08.00 ID:+aIkiiO4]

Macの現状は7%差か
もう「significant」じゃない気がする

> Apple M3で8.8%遅かったのが7%になったとな
> 「5%遅い」はAMD Ryzenでの数字

[417 デフォルトの名無しさん 2025/06/02(月) 20:56:39.33 ID:OnNK0eHp]

小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
するとしても回避策はある。
そんなことより Go の問題点はメモリ管理を自動化しておきながらメモリアクセス違反をあまり防げないことだな。
C/C++ から移行する分にはそんなもんだろと思えるが、メモリ安全性を期待したら失望すると思う。

[418 デフォルトの名無しさん 2025/06/02(月) 21:00:04.05 ID:+aIkiiO4]

どの道テストはみっちり必要ですよ
コンパイル時のあの標語は罠かと

[419 デフォルトの名無しさん 2025/06/02(月) 21:06:48.63 ID:3VeAkVql]

Goは各種安全性対策が中途半端でプログラマの自己責任だからな
Goに未来はない

[420 デフォルトの名無しさん 2025/06/02(月) 21:18:44.47 ID:3Ri7GR+v]

>>396
禿同だな
>>395というか複おじはド素人なのになんで無理に変なコメントしようとするんだ？

[421 デフォルトの名無しさん 2025/06/02(月) 21:28:48.01 ID:uzsj2Y7F]

>>417
>小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
真逆だろ

[422 デフォルトの名無しさん 2025/06/02(月) 21:28:51.61 ID:XWrf3Dm6]

キリトリ記事禁止の呪いか
思いつたことはすべて公表しなければならないという

[423 デフォルトの名無しさん 2025/06/02(月) 21:40:20.45 ID:OnNK0eHp]

>>421
確保しようとするメモリが大きくても小さくても一回あたりの確保・解放に必要な実行コストはあまり差がない。
大きさではなく回数が効いてくるので頻繁な確保・解放がないなら GC のコストは小さいよ。
画像処理関係は大きなデータは扱うがメモリを確保・解放する回数が大きいわけではない。

[424 デフォルトの名無しさん 2025/06/02(月) 21:43:30.36 ID:nIRomA7P]

>>423
C/C++/Rustが絶対に勝つ利用法だ

[425 デフォルトの名無しさん 2025/06/02(月) 21:48:51.08 ID:GgLxuemZ]

>>413
Dockerとか使ったことないの？

[426 デフォルトの名無しさん 2025/06/02(月) 21:56:07.57 ID:OnNK0eHp]

Go の GC もヒープメモリの確保と解放のコスト自体は C と同程度じゃないかな。
生存しているか (参照が残っているか) どうかの判定にコストがかかっているので依存関係の複雑なデータ構造だと速度的には不利になる。
どうせそのあたりを意識しながら設計するなら Go より Rust のほうがいいかなぁとは思う。

[427 デフォルトの名無しさん 2025/06/02(月) 22:01:25.40 ID:OnNK0eHp]

逆にもう手に負えないほど複雑なデータ構造になってしまったときは GC の実行コストを受け入れてでも任せてしまいたいということはあるかもね。

[428 デフォルトの名無しさん 2025/06/02(月) 22:01:47.11 ID:bKFtipAC]

>>426
GC自体は軽い処理で、それ自体のコストが問題になることは少ない
問題は、現在主流のGCの実装では、予測困難なタイミングでGCによる比較的長時間のアプリケーションの停止が生じること
そもそも明示的なdeleteやRAIIや参照カウントのような方法も決してゼロコストではないわけで、そのコストを払うタイミングが違うんだよ

[429 デフォルトの名無しさん 2025/06/02(月) 22:03:46.27 ID:J5nAKj7S]

>>425
Docker創始者が明言「WASM+WASIがあればDockerは不要」
https://twitter.com/solomonstre/status/1111004913222324225
https://twitter.com/thejimwatkins

[430 デフォルトの名無しさん 2025/06/02(月) 22:26:19.81 ID:GjabKUPP]

なお>>429 tweetから丸6年後の今

[431 デフォルトの名無しさん 2025/06/02(月) 22:28:58.46 ID:UNbfduAo]

>>428
1行目から2行目で世界線が違うのか？

[432 デフォルトの名無しさん 2025/06/02(月) 22:33:31.23 ID:bKFtipAC]

>>431
あなた以外には理解いただけているものと思うが、念のため補足すると、
GCの問題は処理コストの大きさではなく、そのコストを払うタイミングにある

[433 デフォルトの名無しさん 2025/06/02(月) 22:44:13.11 ID:ur17A/w2]

>>432
要するにこれが良いと言う事か

> もうすぐGCが進化するからフリーランチ出来るね
> https://qiita.com/hez2010/items/e0a3573ecb3b14325336
> https://github.com/dotnet/runtime/discussions/115627

新計測データが来てる

[434 デフォルトの名無しさん 2025/06/02(月) 22:45:31.08 ID:MPKk5iPb]

>>432
GCはどの方式でも処理コストが高い
これがGC依存言語が遅い原因

[435 デフォルトの名無しさん 2025/06/02(月) 22:48:22.30 ID:MPKk5iPb]

GCするなら一斉停止が最も低コスト
並行しながらGCは時間の分散ができる代わりにコストの増大を招く

[436 デフォルトの名無しさん 2025/06/02(月) 22:59:32.23 ID:ur17A/w2]

Satori GC (No Gen0)は良さそうだから、さっさとGodotで試したデータを上げたら良いのに

[437 デフォルトの名無しさん 2025/06/02(月) 23:06:29.24 ID:ur17A/w2]

godot使いが言っている最大レイテンシーが~5ms程度が実際に達成されるのか見て見たい

[438 デフォルトの名無しさん 2025/06/02(月) 23:16:57.64 ID:9HexqnhX]

現実を無視して自己満足

[439 デフォルトの名無しさん 2025/06/02(月) 23:35:07.57 ID:e80Lnwqt]

5msが本当ならゲームチェンジャー

>>434
GC言語が楽なのは分かるから
逆にGC憎くしだな

[440 デフォルトの名無しさん 2025/06/02(月) 23:41:42.00 ID:MPKk5iPb]

>>439
GCを用いる以上はGCのコストを無くす方法はない
必ずペナルティが生じる

[441 デフォルトの名無しさん 2025/06/02(月) 23:43:45.20 ID:e80Lnwqt]

>>440
そこはクライアント側CPUはあまっているから大丈夫

ゲームだとGPU律速
DB/IOがあればそれで律速

[442 デフォルトの名無しさん 2025/06/02(月) 23:50:27.08 ID:e80Lnwqt]

というかJVMが取り入れたら世界線レベル
DSQLで1秒想定だったのが200分の1

[443 デフォルトの名無しさん 2025/06/02(月) 23:52:03.77 ID:w80jJ2EG]

GCはメモリ消費量の問題もあるため論外
何をするにも不利

[444 デフォルトの名無しさん 2025/06/02(月) 23:57:57.40 ID:ab+RrVue]

>>439
無学だな
GCコストを下げる魔法は存在しない

[445 デフォルトの名無しさん 2025/06/03(火) 00:01:16.56 ID:7WxgzsHE]

>>420
Geminiの方が優秀だね

[446 デフォルトの名無しさん 2025/06/03(火) 00:06:53.82 ID:7WxgzsHE]

見せて欲しい>>444氏の学とやらを

[447 デフォルトの名無しさん 2025/06/03(火) 01:21:41.32 ID:WkxEnd7y]

node.jsでサーバー構築してるけどRustにしたほうがええんかなあ

[448 デフォルトの名無しさん 2025/06/03(火) 09:39:37.51 ID:xhVN3bhy]

Rustの利点が活きるAPIサーバなら普通にいいんじゃないか
フロントもある普通のWebアプリケーションだったら辞めたほうがいいと思うが

[449 デフォルトの名無しさん 2025/06/03(火) 10:20:07.21 ID:cgHky4oh]

もし移行コストに見合った効果が出るのであれば相当にトラフィックの多いサーバーだろうから、
なんとなくの雰囲気や好みじゃなくて論理的に判断すべきだろう
たぶんそうではないんだろうけど、その場合モチベーションは無益な徒労を続ける上で無視できない重要な要素だから、Rustを採用することでモチベーションが上がるならやればいいんじゃないか

[450 デフォルトの名無しさん 2025/06/03(火) 10:46:12.79 ID:97yIcMrS]

>>423
arena使わないとRustがGC言語に速度で負けるのはどういう場合かな？
大昔ならいざ知らず現代のGCが問題になるのはそんな単純なケースじゃないよ

[451 デフォルトの名無しさん 2025/06/03(火) 11:29:40.94 ID:g1P4UzEL]

>>450
arenaを使っていないRustプログラムがほとんど
もちろんGC言語より速い

[452 デフォルトの名無しさん 2025/06/03(火) 12:38:00.30 ID:SsEYb5J+]

GC言語は速さと省メモリで勝ち目は一切ないため他の理由がある時のみ用いる

[453 デフォルトの名無しさん 2025/06/03(火) 12:47:09.85 ID:rqu5SnLS]

>>449
構築コストはRustもNode.jsも覚えた人には同じ
省メモリと捌けるクライアント数はRustが圧倒的

[454 デフォルトの名無しさん 2025/06/03(火) 13:01:58.34 ID:Kt5mEPBd]

>>453
クライアント数が増えたらサーバーの数を増やせばいいだけだ
一般に、Node.jsのエンジニアよりもRustのエンジニアの単価の方が平均的には高いから、
Rust採用による人件費の増加とサーバーのコスト低減効果のどちらが優位か？という金の問題に帰着する
先のAurora DSQLの例では明らかに後者が優位だが、>>447含め大多数のプロダクトでは状況は異なる
いやそうではない、Rustエンジニアの単価は安い、例えば俺のように、と主張するのなら話は別だかな

[455 デフォルトの名無しさん 2025/06/03(火) 13:04:22.23 ID:rqu5SnLS]

>>454
Rustが使える人にとってそんなこと関係ない
Rustで書けばサーバ数も激減できる

[456 デフォルトの名無しさん 2025/06/03(火) 13:09:50.21 ID:/7yVoUF5]

>>455
Rustはコーダーに好き勝手させないためのマネジメント向け言語だよ。

unsafeの扱いは問題あるけど、そのうちコーティング規約でライブラリアン以外はunsafe使えなくするケースが増えるんじゃないんかね。

[457 デフォルトの名無しさん 2025/06/03(火) 13:19:44.29 ID:VYRLmXgA]

>>456
無知がデタラメ書くのは止めなさい
Webサーバー構築でunsafeなんて出て来ない

[458 デフォルトの名無しさん 2025/06/03(火) 13:42:18.60 ID:/7yVoUF5]

>>457
「コーダーがunsafeを使わない」と「コーダーはunsafeを使えない」は別物。
マネジメントサイドはコーダーを信用しないから、禁止できるなら禁止するだろ。

[459 デフォルトの名無しさん 2025/06/03(火) 13:57:30.31 ID:VYRLmXgA]

>>458
ほとんどの分野でunsafeは使われない
unsafeを使うなら関係者の合意形成が必須レベル

[460 デフォルトの名無しさん 2025/06/03(火) 14:14:20.21 ID:xhVN3bhy]

unsafeって、必要もないのにやったところで何かが書きやすくなるような性質のものではないと思うが
C言語上がりだとおまじないみたいに全部unsafeして生ポインタ操作とか平気でやるのか？

[461 デフォルトの名無しさん 2025/06/03(火) 14:29:03.14 ID:idwVU/iA]

後知恵で、やっぱ必要かなと思ったらやる
unsafeを使わなかった敗者がunsafeで復活するかもしれない

[462 デフォルトの名無しさん 2025/06/03(火) 14:43:50.09 ID:VYRLmXgA]

熟練者になるまでunsafeの存在を忘れろ
初心者がunsafeを必要と思うのは無知と勘違いだ

[463 デフォルトの名無しさん 2025/06/03(火) 17:45:47.84 ID:ZZq2n2YO]

IT土方にunsafeを使わせるな

[464 デフォルトの名無しさん 2025/06/03(火) 17:51:28.94 ID:+aVViU0f]

FFIやるとunsafeはすぐ出てくる
webとは関係ないが

[465 デフォルトの名無しさん 2025/06/03(火) 18:09:13.25 ID:FQzY7vd6]

unsafe禁止とか言ってないで真面目にレビューしろ

[466 デフォルトの名無しさん 2025/06/03(火) 19:07:45.18 ID:idwVU/iA]

処刑されないこともあるが裁判にかけられる

[467 デフォルトの名無しさん 2025/06/03(火) 20:15:54.93 ID:E3wqr71x]

>>464
FFIでも整備されていてunsafe不要な分野も多いね
未整備なら素人は手を出さない方が

[468 デフォルトの名無しさん 2025/06/03(火) 20:26:02.65 ID:/7yVoUF5]

ほとんどの分野で使われないなら、なおさらunsafe禁止すべき。

膝を撃ち抜く自由を無くしたのがRustの利点なのだから、unsafeを使えないSafeRustのみのコーダーモードを用意すべきかと。
#![forbid(unsafe_code)]とかがデフォルトにならんかね。

[469 デフォルトの名無しさん 2025/06/03(火) 20:50:43.22 ID:idwVU/iA]

正確な判断はunsafeが使われた後でしかできないよ
後で訂正や追加されるようなルールは守りたくないと思ってる者ほど事前にルールを確定しようとする

[470 デフォルトの名無しさん 2025/06/03(火) 20:56:07.12 ID:RCZNeyZK]

そう
ソースを確かめず、アプリやサービスで判断する場合
今の Rust は SafeRust との明示がない限り
デフォルトは unsafe Rust だと言う事

[471 デフォルトの名無しさん 2025/06/03(火) 21:05:31.59 ID:E3wqr71x]

safe ＝ Rustコンパイラが安全性を保証する
unsafe ＝ 他の言語と同じくプログラマ自己責任

[472 デフォルトの名無しさん 2025/06/03(火) 21:09:34.02 ID:gJYjdNIy]

Cコードを呼び出すときはunsafeを使わざるを得ないけどな

[473 デフォルトの名無しさん 2025/06/03(火) 21:19:12.46 ID:KTSdNflr]

> Cコードを呼び出すときはunsafeを使わざるを得ないけどな

△ Cコードを呼び出すとき
○ dll関数を呼び出すとき (その関数がRustで書かれていても)

ABI策定はどうなっているのか

[474 デフォルトの名無しさん 2025/06/03(火) 21:33:34.20 ID:NXfOWsak]

いつの間にか serde_yaml のリポジトリがアーカイブされてる…

[475 デフォルトの名無しさん 2025/06/03(火) 21:59:05.52 ID:Ygo17qEp]

>>474
https://doc.serdeyml.com/serde_yml/

[476 デフォルトの名無しさん 2025/06/03(火) 22:11:40.12 ID:Y8fW8uWd]

>>475
0.0.12

Build Status FAILING

[477 デフォルトの名無しさん 2025/06/03(火) 22:19:03.78 ID:WkxEnd7y]

Node.jsのNestJS使ってる
使いやすくてすばらしい
Rustでもこういうフレームワーク使いたい

[478 デフォルトの名無しさん 2025/06/03(火) 22:42:41.40 ID:5VWOQt07]

>>473
Rust ABIはUndefined

[479 デフォルトの名無しさん 2025/06/03(火) 22:50:13.08 ID:/5P14uNg]

>>474
Rustのライブラリモデルの宿命だな

[480 デフォルトの名無しさん 2025/06/03(火) 23:00:49.81 ID:wy1dGgl0]

>>474
これunsafe使いまくり
なのに今後何があっても直さないのか

[481 デフォルトの名無しさん 2025/06/03(火) 23:24:47.93 ID:ovxpNXrv]

>>474
serde-yamlの管理人はsyn/proc-macro2やthiserror/anyhowなど幅広くやってるdtolnayだね

[482 デフォルトの名無しさん 2025/06/03(火) 23:28:35.41 ID:bSuEbnBN]

それらも用心が必要という事態か？

[483 デフォルトの名無しさん 2025/06/03(火) 23:29:41.66 ID:bSuEbnBN]

>>479
こんなに簡単にはしご外されるモデルなんだね

[484 デフォルトの名無しさん 2025/06/03(火) 23:30:11.84 ID:vFCBrwxa]

yamlの仕様は闇が深いので関わらない方がいい

[485 デフォルトの名無しさん 2025/06/03(火) 23:39:58.59 ID:wc70ijSk]

>>481
C++⇔Rust FFIのcxxも

[486 デフォルトの名無しさん 2025/06/03(火) 23:47:22.51 ID:C8xHrNgY]

MS/editが外部crate依存が少ないのは納得した

[487 デフォルトの名無しさん 2025/06/03(火) 23:49:19.18 ID:j/0hkWys]

>>486
それは不利だよ
自分で何もかもメンテしないといけない

[488 デフォルトの名無しさん 2025/06/03(火) 23:50:49.03 ID:C8xHrNgY]

>>487
事実になっとくしただけだぞ

[489 デフォルトの名無しさん 2025/06/03(火) 23:56:35.38 ID:C8xHrNgY]

前スレのバグのFixがリリースされてた
https://github.com/microsoft/edit/releases/tag/v1.1.0

他にもcrashするバグがあったのか
Pressing Alt followed by a non-English keyboard key will not crash Edit anymore (#244)

[490 デフォルトの名無しさん 2025/06/04(水) 00:09:54.76 ID:pcxtiJDU]

>>480
unsafe依存なserde-yamlではなく
safeなyaml-rust2が今は主流

[491 デフォルトの名無しさん 2025/06/04(水) 00:18:09.37 ID:qT5RunOJ]

やっぱシリアライズ形式はjsonだな

[492 デフォルトの名無しさん 2025/06/04(水) 00:50:17.21 ID:rKXA09I4]

メンテがいなくなり
移行先もなく
自分で手を入れる必要で
ようやくローカルフォーク

[493 デフォルトの名無しさん 2025/06/04(水) 00:52:07.22 ID:rKXA09I4]

逆に最初から全てを自分で持つのはメンテが辛いだけで不利

[494 デフォルトの名無しさん 2025/06/04(水) 01:06:11.88 ID:P1CiPc1i]

GUIライブラリの話もそうだけどこうやっていろんなライブラリを調べたりアップデートに対応したりするコストがRustはバカ高いんだよね

メンテナンスが急に止まったりしない安心して使える鉄板ライブラリの塊が増えないとバカ高いコストを支払ってもお釣りが来るCloudfrare級のところ以外からは見放さされる

[495 デフォルトの名無しさん 2025/06/04(水) 01:15:23.81 ID:ekCnNhZO]

メンテ必要なければ止まっていても何も困らない
必要になってから次策を考えればいい

[496 デフォルトの名無しさん 2025/06/04(水) 02:00:11.13 ID:NPEulGl+]

>>494
鉄板ライブラリが充実してる言語は何おすすめ？

[497 デフォルトの名無しさん 2025/06/04(水) 06:07:28.58 ID:efmS46GF]

>>496
どうせ論外論法なんだろ

[498 デフォルトの名無しさん 2025/06/04(水) 08:00:19.73 ID:k0G95ru9]

Javaがエンタープライズで世界取ったのは、どこでも動くではなく
充実の標準＆企業主体のデファクトスタンダードライブラリの存在によるところが大きいとは思う

[499 デフォルトの名無しさん 2025/06/04(水) 08:14:31.76 ID:G6dCwUPn]

それを言っても卵が先か雛が先かになるから仕方がない
Javaがエンタープライズで勝った大きな根本要因の一つは、UNIXサーバーをターゲットとした開発をWindows上で問題なく行えるから
その意味では、どこでも動くからというのは極めて重要な性質

[500 デフォルトの名無しさん 2025/06/04(水) 08:30:07.30 ID:uvY60KW1]

外のパッケージに依存すれば脆弱性も共有することになるし、サプライチェーン攻撃のリスクもある
crateのようなパッケージマネージャというのは完全に性善説で成り立っていて、
潜在的にはそこらのフリーソフトなんかより遥かに危険なのだが、
それを騒ぎ立てて経営層に問題として認識させることはエンジニアの間ではタブーとなっている

[501 デフォルトの名無しさん 2025/06/04(水) 09:18:54.95 ID:6ElB2UK6]

Rustで使われてたjemallocが開発終了してしまった件

[502 デフォルトの名無しさん 2025/06/04(水) 09:21:52.15 ID:YYmNTYsA]

広い意味では自動化に人気がないだけだな
手動のほうが良いというのがタブーになる

[503 デフォルトの名無しさん 2025/06/04(水) 09:37:55.19 ID:qT5RunOJ]

AWS社員はもっとRustライブラリの保守に尽力しろ

[504 デフォルトの名無しさん 2025/06/04(水) 09:38:26.06 ID:XvRleYyH]

>>501
終わってない。
facebook の管轄下に移動した。
https://github.com/facebook/Jemalloc

[505 デフォルトの名無しさん 2025/06/04(水) 10:03:06.02 ID:YYmNTYsA]

「どこでも動く」の究極の形は計算機がなくてもできるカードゲームや将棋みたいなやつだ

[506 デフォルトの名無しさん 2025/06/04(水) 13:04:56.35 ID:k6hN7zFM]

>>474
「アーカイブ」という言葉の意味は、メンテナンスしなくなったから、
書庫の様な場所に保管して開発を終える、という意味？

[507 デフォルトの名無しさん 2025/06/04(水) 13:26:32.91 ID:uvY60KW1]

>>506
GitHubにおけるアーカイブは、開発終了したリポジトリを凍結する機能
引き続き読取は可能だが書込みは不可になる

[508 デフォルトの名無しさん 2025/06/04(水) 14:18:22.24 ID:l+TAz4MO]

アーカイブされたのは2024年3月
serde_yamlを使いたい人は今後もそのまま使えて使われてる

[509 デフォルトの名無しさん 2025/06/04(水) 14:20:34.09 ID:l+TAz4MO]

ただしserde_yamlはCから移植のunsafe_ libyamlが下請け
safeなyaml_rust2をベースがいいだろうね

[510 デフォルトの名無しさん 2025/06/04(水) 16:14:01.87 ID:YYmNTYsA]

機械化（機械に責任転嫁）できないという点だけを見れば自己責任は禁忌だが

[511 デフォルトの名無しさん 2025/06/04(水) 16:49:49.89 ID:k6hN7zFM]

Rust推進者って、Linuxもそうだったが、自分は変わらず
世界の方を変えようとしているから、ウザイ。
自分が(社会的地位が)上であることは絶対的にゆるぎないと思ってる気がするよ。

[512 デフォルトの名無しさん 2025/06/04(水) 16:51:13.65 ID:k6hN7zFM]

むしろ、今までずっとそのようにしてきたことが社会を歪めておかしなことになって来た
事には気づいてない。

[513 デフォルトの名無しさん 2025/06/04(水) 16:52:55.60 ID:k6hN7zFM]

C#も押し付けがましかったが、それがRustに変わろうとしているらしい。
その前はJavaだった。Kotlinもそうされそうになったが衰退したらしいが。

[514 デフォルトの名無しさん 2025/06/04(水) 16:57:13.44 ID:k6hN7zFM]

中国人もそうなんだよ。民主主義で困ってないのに、民主主義や自由は
幻想だ。『日本や台湾は「幻想のバブルの中に」入る。
これからの時代は共産主義だ。だから、台湾の体制を中共に譲らなければ
ならない。それが人類にとって幸せだ。世界に赤い旗を立てる事が
人類の未来のためになるんだ』
などと言っている。Rustもそれに非常に似ている。

[515 デフォルトの名無しさん 2025/06/04(水) 17:02:22.14 ID:k6hN7zFM]

「xxxはRustに書き直して高速になった。バグが減った」
って、EVや空飛ぶ車に対するChinaのプロパガンダにそっくり。

[516 デフォルトの名無しさん 2025/06/04(水) 17:03:31.51 ID:k6hN7zFM]

イーロンマスクも南アメリカで17歳まで育ち、カナダから北米に渡り、
恥知らずにも中国で金儲けをし、Rustを宣伝している。

[517 デフォルトの名無しさん 2025/06/04(水) 17:03:32.52 ID:k6hN7zFM]

イーロンマスクも南アメリカで17歳まで育ち、カナダから北米に渡り、
恥知らずにも中国で金儲けをし、Rustを宣伝している。

[518 デフォルトの名無しさん 2025/06/04(水) 17:05:35.70 ID:k6hN7zFM]

南アメリカ-->南アフリカ

[519 デフォルトの名無しさん 2025/06/04(水) 17:17:57.01 ID:BCt/MqyZ]

複オジの謎自演が湧いたから軌道修正

>>509
その理屈でこうなる

Cから移植の rav1d も意味ない

[520 デフォルトの名無しさん 2025/06/04(水) 17:20:13.73 ID:LMOj5Orj]

イーロン・マスク、X表示名を「Gorklon Rust」に変更
https://jp.beincrypto.com/elon-musk-gorklon-rust-meme-coin-hype/

[521 デフォルトの名無しさん 2025/06/04(水) 17:24:03.91 ID:k6hN7zFM]

アホみたいだな。

[522 デフォルトの名無しさん 2025/06/04(水) 17:24:04.89 ID:k6hN7zFM]

アホみたいだな。

[523 デフォルトの名無しさん 2025/06/04(水) 17:24:12.07 ID:LMOj5Orj]

イーロン・マスクがRust製の次世代型メッセージングサービスXChatを発表
https://coinpost.jp/?p=622044

[524 デフォルトの名無しさん 2025/06/04(水) 17:58:41.63 ID:vVWK76SG]

>>501,504
Facebook/Metaは前々からforkしていて今現在 2 commits behind
Archiveの経緯やMetaが引き継いだ？メッセージが見つからない

[525 デフォルトの名無しさん 2025/06/04(水) 18:32:54.69 ID:LMOj5Orj]

Rustで構築されたXChatは暗号化、消えるメッセージ、ファイル送信、音声・ビデオ通話の機能が含まれる

[526 デフォルトの名無しさん 2025/06/04(水) 20:03:53.00 ID:Ao4InlGx]

GoogleのGemini 2.5で日本語を含む多言語の音声生成が可能に
https:
//gigazine.net/news/20250604-google-gemini-native-audio/

無料で超絶リアルな3DCGキャラを作成＆動かせるゲーム開発ツール「MetaHuman」の一部がUnreal Engine 5.6に統合
https:
//gigazine.net/news/20250604-unreal-engine-5-6-metahuman/

ついにAndroid版Photoshopのベータ版が登場、無料でAIによる画像生成やレイヤー編集を利用可能
https:
//gigazine.net/news/20250604-adobe-photoshop-android/

あなたは「生成AI製フェイク画像」を見抜けますか？--判別は"ほぼ無理”な時代、来歴証明が重要なワケ
https:
//japan.cnet.com/article/35233768/

ChatGPT無料版でも「会話履歴を踏まえた回答」が可能に、ただし最近の会話のみ
https:
//japan.cnet.com/article/35233795/

xAI「Grok」18禁モード無料開放　けしからん会話可能に　日本語OK
https:
//ascii.jp/ai/

[527 デフォルトの名無しさん 2025/06/04(水) 20:37:21.11 ID:bNQu7sc4]

>>501
jemallocは終了していない
https://crates.io/crates/tikv-jemallocator
毎日10万downloads

[528 デフォルトの名無しさん 2025/06/04(水) 21:30:49.14 ID:/YHraRZZ]

ただのwrapper >>527

[529 デフォルトの名無しさん 2025/06/04(水) 21:43:23.61 ID:oPHHrTh9]

上で話題になってたtauriのIMEと画面移動のバグ？の件

github.com/tauri-apps/wry/blob/dev/src/webview2/mod.rsの
parent_subclass_proc()で
...
WM_SETFOCUS | WM_ENTERSIZEMOVE => {
let controller = dwrefdata as *mut ICoreWebView2Controller;
let _ = (*controller).MoveFocus(COREWEBVIEW2_MOVE_FOCUS_REASON_PROGRAMMATIC);
}
...
のWM_ENTERSIZEMOVEを削ったら改善しそう
画面動かした時に無駄にフォーカス復元しようとして何か変なことになってる
動作確認はwryのcargo run --example simpleの検索入力でしかしてないけどtauriも同じだと思う

WM_ENTERSIZEMOVEでMoveFocus呼んでる理由が分からんしissue出すの面倒だから放置するけど
現実問題として困ってたら参考にしてくれ

[530 デフォルトの名無しさん 2025/06/04(水) 22:02:27.60 ID:QHp7QW/E]

>>519
同じCから移植でも
他言語からも使うためunsafeなC API維持と
Rustからのみでsafe可の違いが大きいでしょう

[531 デフォルトの名無しさん 2025/06/04(水) 22:04:51.79 ID:kc+wDMWW]

>>529
この場だけでも直った事にしたいのかも知れんが

tauriで徹底的に動作確認してないという事は
業務アプリ類は言わずもがな、自作ツールさも作ってないという事になった

[532 デフォルトの名無しさん 2025/06/04(水) 22:23:54.98 ID:Y1VDH1cW]

The Linux 6.15 kernel arrives - and it's big a victory for Rust fans!
https://www.zdnet.com/article/the-linux-6-15-kernel-arrives-and-its-big-a-victory-for-rust-fans/

[533 デフォルトの名無しさん 2025/06/04(水) 22:39:19.54 ID:1H7IBoRl]

jemallocはトラブルの匂いがするな
serde-yamlと違って開発終了ってことはないから様子見だね

[534 デフォルトの名無しさん 2025/06/04(水) 22:50:25.36 ID:9UK4z5dz]

jemallocは最新版が3年前でその前は6年前
C製だから穴発見があると危機だが

[535 デフォルトの名無しさん 2025/06/04(水) 23:10:20.18 ID:oPHHrTh9]

>>531
興味本位で調べただけだよ
OSSだから多少の不具合は自分で調べて対応できる
tauriはまだ本格的に使ってないけど期待はしてる

[536 デフォルトの名無しさん 2025/06/04(水) 23:13:27.02 ID:DFQUCkBF]

>WM_ENTERSIZEMOVEでMoveFocus呼んでる理由が分からんし

× OSSだから多少の不具合は自分で調べて対応できる
○ 迂闊にいじるとリグレッション

[537 デフォルトの名無しさん 2025/06/04(水) 23:17:32.86 ID:0rTSW7kB]

>>523
次世代ツイッターもRust製なのか

[538 デフォルトの名無しさん 2025/06/04(水) 23:19:17.30 ID:xluCwGJp]

>>535
自分で調べて
↓
理由が分からん

調べてないのでは

[539 デフォルトの名無しさん 2025/06/04(水) 23:26:53.32 ID:YYmNTYsA]

一部でアセンブラを使っていてもCで書いたとかRustで書いたとか自称しやがるから
アセンブラとCとRustはもう区別する必要ないのでは

[540 デフォルトの名無しさん 2025/06/04(水) 23:33:17.12 ID:oPHHrTh9]

>>538
取っ掛かりとして必要な範囲は調べてるだろ
0-100思考の方？

[541 デフォルトの名無しさん 2025/06/04(水) 23:36:30.76 ID:a0td9I7l]

>>540
という事でこれじゃあ未対応だな>>529

[542 デフォルトの名無しさん 2025/06/04(水) 23:38:36.41 ID:dxJlV5oD]

イーロンマスクまでRust派になるとは驚いた

[543 デフォルトの名無しさん 2025/06/04(水) 23:51:21.99 ID:oPHHrTh9]

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

[544 デフォルトの名無しさん 2025/06/04(水) 23:54:26.85 ID:c3QvVbDl]

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

[545 デフォルトの名無しさん 2025/06/04(水) 23:57:54.43 ID:0ZM3gFza]

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

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

[546 デフォルトの名無しさん 2025/06/04(水) 23:59:22.16 ID:VnO22Btn]

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

[547 デフォルトの名無しさん 2025/06/05(木) 00:18:01.72 ID:zDvwNPi0]

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

[548 デフォルトの名無しさん 2025/06/05(木) 05:52:19.18 ID:9oMXEf1f]

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

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

[549 デフォルトの名無しさん 2025/06/05(木) 08:11:45.26 ID:xg3puRce]

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

[550 デフォルトの名無しさん 2025/06/05(木) 08:57:28.49 ID:/1HPheJz]

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

[551 デフォルトの名無しさん 2025/06/05(木) 09:21:04.56 ID:6CqsT1b+]

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

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

[552 デフォルトの名無しさん 2025/06/05(木) 12:34:43.00 ID:h7HwLZOZ]

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

[553 デフォルトの名無しさん 2025/06/05(木) 12:36:14.00 ID:h7HwLZOZ]

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

[554 デフォルトの名無しさん 2025/06/05(木) 12:41:30.48 ID:ivO6rPSc]

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

[555 デフォルトの名無しさん 2025/06/05(木) 12:50:06.51 ID:0IjP0LtT]

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

[556 デフォルトの名無しさん 2025/06/05(木) 12:53:34.45 ID:e7PyAJ/v]

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

[557 デフォルトの名無しさん 2025/06/05(木) 16:05:58.05 ID:O/7ObmiI]

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

[558 デフォルトの名無しさん 2025/06/05(木) 16:31:04.08 ID:si4Xw2Nw]

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

[559 デフォルトの名無しさん 2025/06/05(木) 16:51:58.44 ID:VtwpHPUL]

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

[560 デフォルトの名無しさん 2025/06/05(木) 18:39:37.18 ID:O/7ObmiI]

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

[561 デフォルトの名無しさん 2025/06/05(木) 18:56:11.37 ID:TVBzAcEZ]

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

[562 デフォルトの名無しさん 2025/06/05(木) 19:09:12.79 ID:zMAzVPRE]

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

[563 デフォルトの名無しさん 2025/06/05(木) 19:43:22.97 ID:BNqgyRrD]

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

[564 デフォルトの名無しさん 2025/06/05(木) 20:21:52.92 ID:P5XWUA/E]

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

[565 デフォルトの名無しさん 2025/06/05(木) 22:08:00.36 ID:YvayYtMq]

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

[566 デフォルトの名無しさん 2025/06/05(木) 22:24:45.12 ID:xITjGZKh]

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

[567 デフォルトの名無しさん 2025/06/05(木) 22:30:17.30 ID:DF0+msFz]

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

[568 デフォルトの名無しさん 2025/06/05(木) 23:49:02.97 ID:F2pC0JZC]

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

[569 デフォルトの名無しさん 2025/06/06(金) 09:25:11.44 ID:XJlMjWKR]

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

[570 デフォルトの名無しさん 2025/06/06(金) 10:12:05.28 ID:XJlMjWKR]

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

[571 デフォルトの名無しさん 2025/06/06(金) 11:26:05.53 ID:Dh3sPLTt]

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

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

[572 デフォルトの名無しさん 2025/06/06(金) 12:05:30.99 ID:tmoIxOYF]

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

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

[573 デフォルトの名無しさん 2025/06/06(金) 12:12:17.09 ID:tmoIxOYF]

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

[574 デフォルトの名無しさん 2025/06/06(金) 12:14:48.45 ID:A1tr0fpa]

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

[575 デフォルトの名無しさん 2025/06/06(金) 12:16:57.67 ID:hpIL6JTz]

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

[576 デフォルトの名無しさん 2025/06/06(金) 12:19:54.83 ID:A1tr0fpa]

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

[577 デフォルトの名無しさん 2025/06/06(金) 12:20:50.82 ID:hpIL6JTz]

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

[578 デフォルトの名無しさん 2025/06/06(金) 12:22:41.80 ID:A1tr0fpa]

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

[579 デフォルトの名無しさん 2025/06/06(金) 12:27:00.11 ID:1NKDBcTf]

Web開発でRust笑

[580 デフォルトの名無しさん 2025/06/06(金) 13:06:50.86 ID:XmGFqaCQ]

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

[581 デフォルトの名無しさん 2025/06/06(金) 14:29:45.68 ID:C6RQeHrZ]

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

[582 デフォルトの名無しさん 2025/06/06(金) 16:32:47.31 ID:ju0XC4LS]

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

[583 デフォルトの名無しさん 2025/06/06(金) 17:14:08.28 ID:W6y55ttb]

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

[584 デフォルトの名無しさん 2025/06/06(金) 17:23:29.23 ID:ju0XC4LS]

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

[585 デフォルトの名無しさん 2025/06/06(金) 17:25:16.55 ID:Gse28VZ2]

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

[586 デフォルトの名無しさん 2025/06/06(金) 17:42:57.80 ID:J0042m2U]

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

[587 デフォルトの名無しさん 2025/06/06(金) 17:43:30.86 ID:C6RQeHrZ]

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

[588 デフォルトの名無しさん 2025/06/06(金) 17:54:58.69 ID:ju0XC4LS]

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

[589 デフォルトの名無しさん 2025/06/06(金) 18:00:07.40 ID:ju0XC4LS]

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

[590 デフォルトの名無しさん 2025/06/06(金) 18:17:12.71 ID:J0042m2U]

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

[591 デフォルトの名無しさん 2025/06/06(金) 18:23:14.91 ID:J0042m2U]

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

[592 デフォルトの名無しさん 2025/06/06(金) 18:24:57.87 ID:ju0XC4LS]

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

[593 デフォルトの名無しさん 2025/06/06(金) 18:29:44.35 ID:ju0XC4LS]

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

[594 デフォルトの名無しさん 2025/06/06(金) 18:38:16.48 ID:VxoAIN/b]

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

[595 デフォルトの名無しさん 2025/06/06(金) 18:40:29.68 ID:ju0XC4LS]

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

[596 デフォルトの名無しさん 2025/06/06(金) 18:42:10.43 ID:VxoAIN/b]

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

[597 デフォルトの名無しさん 2025/06/06(金) 18:44:07.97 ID:VxoAIN/b]

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

[598 デフォルトの名無しさん 2025/06/06(金) 18:45:34.80 ID:ju0XC4LS]

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

[599 デフォルトの名無しさん 2025/06/06(金) 18:50:46.27 ID:7glNIZb/]

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

[600 デフォルトの名無しさん 2025/06/06(金) 18:51:47.14 ID:jK2Njv63]

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

[601 デフォルトの名無しさん 2025/06/06(金) 18:52:44.07 ID:ju0XC4LS]

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

[602 デフォルトの名無しさん 2025/06/06(金) 18:52:58.14 ID:NfW6LToZ]

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

[603 デフォルトの名無しさん 2025/06/06(金) 18:53:26.81 ID:jK2Njv63]

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

[604 デフォルトの名無しさん 2025/06/06(金) 18:57:09.31 ID:jK2Njv63]

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

[605 デフォルトの名無しさん 2025/06/06(金) 19:08:08.67 ID:+jg06n/J]

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

[606 デフォルトの名無しさん 2025/06/06(金) 19:15:06.63 ID:kCiJWJGk]

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

[607 デフォルトの名無しさん 2025/06/06(金) 19:21:48.66 ID:ju0XC4LS]

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

[608 デフォルトの名無しさん 2025/06/06(金) 20:23:58.53 ID:2KEuAQPx]

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

[609 デフォルトの名無しさん 2025/06/06(金) 20:31:21.71 ID:bR69FDxG]

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

[610 デフォルトの名無しさん 2025/06/06(金) 20:39:58.07 ID:C6RQeHrZ]

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

[611 デフォルトの名無しさん 2025/06/06(金) 21:10:39.44 ID:h83wGeBI]

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

[612 デフォルトの名無しさん 2025/06/06(金) 21:24:25.01 ID:7glNIZb/]

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

[613 デフォルトの名無しさん 2025/06/06(金) 22:47:40.65 ID:r+7IJaB+]

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

[614 デフォルトの名無しさん 2025/06/06(金) 22:50:14.29 ID:r+7IJaB+]

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

[615 デフォルトの名無しさん 2025/06/06(金) 23:24:56.88 ID:r+7IJaB+]

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

[616 デフォルトの名無しさん 2025/06/06(金) 23:28:33.90 ID:bR69FDxG]

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

[617 デフォルトの名無しさん 2025/06/06(金) 23:31:26.54 ID:rGFHsXat]

同感

[618 デフォルトの名無しさん 2025/06/06(金) 23:31:47.18 ID:C6RQeHrZ]

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

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

[619 デフォルトの名無しさん 2025/06/06(金) 23:40:14.11 ID:3JEvODeg]

ここはRust専用スレだよ

[620 デフォルトの名無しさん 2025/06/06(金) 23:43:40.46 ID:2KEuAQPx]

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

[621 デフォルトの名無しさん 2025/06/06(金) 23:53:57.13 ID:QDWb4oK8]

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

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

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

[622 デフォルトの名無しさん 2025/06/06(金) 23:57:17.71 ID:E71NqYZh]

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

[623 デフォルトの名無しさん 2025/06/07(土) 05:06:43.11 ID:fIXrFGqI]

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

[624 デフォルトの名無しさん 2025/06/07(土) 07:57:16.81 ID:D5LAHAi0]

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

[625 デフォルトの名無しさん 2025/06/07(土) 09:22:57.46 ID:CnK/EgX1]

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

[626 デフォルトの名無しさん 2025/06/07(土) 09:42:27.95 ID:evsGciRN]

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

[627 デフォルトの名無しさん 2025/06/07(土) 11:15:27.05 ID:BgBV5HNm]

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

[628 デフォルトの名無しさん 2025/06/07(土) 11:32:51.12 ID:4dOcWkyN]

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

[629 デフォルトの名無しさん 2025/06/07(土) 11:49:58.62 ID:rtfJQBOq]

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

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

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

[630 デフォルトの名無しさん 2025/06/07(土) 12:45:57.58 ID:xi57kquP]

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

[631 デフォルトの名無しさん 2025/06/07(土) 12:50:15.19 ID:xi57kquP]

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

[632 デフォルトの名無しさん 2025/06/07(土) 13:01:57.88 ID:bjSjMKW4]

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

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

[633 デフォルトの名無しさん 2025/06/07(土) 13:11:57.59 ID:xi57kquP]

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

[634 デフォルトの名無しさん 2025/06/07(土) 13:26:22.04 ID:hQgu9D5P]

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

[635 デフォルトの名無しさん 2025/06/07(土) 13:38:44.17 ID:xi57kquP]

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

[636 デフォルトの名無しさん 2025/06/07(土) 13:52:46.13 ID:hQgu9D5P]

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

[637 デフォルトの名無しさん 2025/06/07(土) 13:58:37.96 ID:xi57kquP]

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

[638 デフォルトの名無しさん 2025/06/07(土) 15:58:12.17 ID:D5LAHAi0]

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

[639 デフォルトの名無しさん 2025/06/07(土) 16:21:03.28 ID:xi57kquP]

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

[640 デフォルトの名無しさん 2025/06/07(土) 18:36:37.64 ID:evsGciRN]

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

[641 デフォルトの名無しさん 2025/06/07(土) 18:53:43.86 ID:nANhvbt8]

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

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

[642 デフォルトの名無しさん 2025/06/07(土) 19:02:14.18 ID:xi57kquP]

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

[643 デフォルトの名無しさん 2025/06/07(土) 19:07:24.49 ID:WTKqP7i+]

>>641
循環参照が必要なケースはだいたいアリーナでいいんじゃないかな
アリーナのスコープはだいたい人間の意図をそのまま反映するのでAI向きだと思う

[644 デフォルトの名無しさん 2025/06/07(土) 19:07:29.04 ID:evsGciRN]

誰でもいいからPythonをRustに変換してもらうのが雑なやり方
AIを指名するのはちょっと細かいことにこだわり過ぎている

[645 デフォルトの名無しさん 2025/06/07(土) 19:10:35.54 ID:xi57kquP]

>>641
AIであろうと論理的に無理なことはできない
AIも人間と同様で魔法を使えない

[646 デフォルトの名無しさん 2025/06/07(土) 20:18:46.50 ID:nANhvbt8]

単純な構文解析では無理だけど、AIがコードの意味や呼び出し関係なども含めて解析できるようになれば可能性あるんじゃない？
2-3年後にとは思わないけど、5年や10年後ならそういう未来もあって良いように思う
最近のAIの発展は凄まじいし

Rustは良くも悪くも低レベルの事情が見えすぎるんだよな
Option, Result や enum のような型はビジネスロジックの表現に役立つし、他の言語でも欲しい人はいるだろうけど、SendやSyncなんかはちょっと違う
これらはC++経験者にとって嬉しいだけで、多くの人からすれば、そういうものは意識せずに済む方がずっと便利なはず

[647 デフォルトの名無しさん 2025/06/07(土) 20:22:33.18 ID:nANhvbt8]

意識することは必要かもしれないけど、そのための面倒くささを減らせるなら、その方がいい的な話

[648 デフォルトの名無しさん 2025/06/07(土) 20:27:29.58 ID:8xDjgwkI]

>>646
>これらはC++経験者にとって嬉しいだけで
勝手に妄想すんな。

[649 デフォルトの名無しさん 2025/06/07(土) 20:32:13.92 ID:xi57kquP]

>>646
そんな方法ロジックが存在するなら現在AI関係なく実現できる
AIと言えども無理

[650 デフォルトの名無しさん 2025/06/07(土) 21:03:48.33 ID:nANhvbt8]

実際面倒でしょ
GCのある言語ではとっくに解決済みの問題だし、パフォーマンスのためという理由さえ無ければ、そんな面倒は無い方がいい
人間が書くコードはビジネスロジックに注力して、最適化などの面倒な部分はAIが頑張る、みたいな未来を夢見ても良くない？

「世界中の初級〜中級プログラマがみんなRustを書ける時代」よりは、「初級〜中級プログラマが書いたコードがRust並みに高パフォーマンスに動く」の方が有り得そうに思う
大手ITとか新進気鋭のスタートアップならともかく、世の中のレベルってそんなに高くないと思うので

[651 デフォルトの名無しさん 2025/06/07(土) 21:18:42.39 ID:xi57kquP]

>>650
既存の言語の仕様では不可能
もし手段があるならAI関係なく今すぐ実現させる

[652 デフォルトの名無しさん 2025/06/07(土) 21:34:29.01 ID:nANhvbt8]

言語の限界というより、現状のコンパイラが行なっている構文解析という手法の限界じゃないの？
他の言語で書かれたプログラムを (人間が時間をかければ) Rustに移植できる、と言えるなら、それは将来AIにもできる可能性のある仕事だと思う
「理屈上どうやってもC/C++/Rustでは実現できないロジック」とかがあるなら無理だけど、そういうのはおそらく滅多に無いだろうし

[653 デフォルトの名無しさん 2025/06/07(土) 21:50:46.86 ID:4dOcWkyN]

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

[654 デフォルトの名無しさん 2025/06/07(土) 22:08:05.95 ID:WTKqP7i+]

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

[655 デフォルトの名無しさん 2025/06/07(土) 22:13:16.92 ID:V3GF7XBg]

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

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

[656 デフォルトの名無しさん 2025/06/07(土) 22:28:32.11 ID:noiqQ3+R]

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

[657 デフォルトの名無しさん 2025/06/07(土) 22:31:19.97 ID:5EbSwuA7]

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

[658 デフォルトの名無しさん 2025/06/07(土) 22:36:04.29 ID:evsGciRN]

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

[659 デフォルトの名無しさん 2025/06/07(土) 22:46:23.09 ID:x0Lmj2vj]

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

[660 デフォルトの名無しさん 2025/06/07(土) 23:36:16.04 ID:JFrNmexI]

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

[661 デフォルトの名無しさん 2025/06/07(土) 23:51:31.84 ID:WTKqP7i+]

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

[662 デフォルトの名無しさん 2025/06/08(日) 00:08:40.08 ID:T2dNb6GD]

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

[663 デフォルトの名無しさん 2025/06/08(日) 00:53:09.39 ID:ZN3JGvHo]

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

[664 デフォルトの名無しさん 2025/06/08(日) 00:59:52.80 ID:FT4pj4FW]

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

[665 デフォルトの名無しさん 2025/06/08(日) 09:07:30.09 ID:xGbxg89a]

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

[666 デフォルトの名無しさん 2025/06/08(日) 09:32:59.28 ID:PLM9xjLn]

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

[667 デフォルトの名無しさん 2025/06/08(日) 09:58:01.31 ID:LY0YSAF3]

何もいらなーいー

[668 デフォルトの名無しさん 2025/06/08(日) 11:19:05.81 ID:SVsPPZLo]

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

[669 デフォルトの名無しさん 2025/06/08(日) 11:21:32.51 ID:l86SYNjx]

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

[670 デフォルトの名無しさん 2025/06/08(日) 13:04:11.80 ID:wHU1y2Cy]

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

[671 デフォルトの名無しさん 2025/06/08(日) 14:35:33.97 ID:Dz6RrxG4]

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

[672 デフォルトの名無しさん 2025/06/08(日) 15:20:07.80 ID:+Shzj2Ty]

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

[673 デフォルトの名無しさん 2025/06/08(日) 15:24:49.87 ID:+Shzj2Ty]

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

[674 デフォルトの名無しさん 2025/06/08(日) 16:16:30.27 ID:d1+aCZ76]

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

[675 デフォルトの名無しさん 2025/06/08(日) 16:29:29.68 ID:+Shzj2Ty]

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

[676 デフォルトの名無しさん 2025/06/08(日) 16:41:23.46 ID:EeOpsjtM]

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

[677 デフォルトの名無しさん 2025/06/08(日) 17:01:39.88 ID:RG5MF58/]

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

[678 デフォルトの名無しさん 2025/06/08(日) 17:02:33.93 ID:+Shzj2Ty]

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

[679 デフォルトの名無しさん 2025/06/08(日) 17:08:20.00 ID:/WNe1XQ9]

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

[680 デフォルトの名無しさん 2025/06/08(日) 17:08:59.52 ID:xGbxg89a]

>>677
ええやん

[681 デフォルトの名無しさん 2025/06/08(日) 17:13:54.67 ID:RauPWj2e]

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

[682 デフォルトの名無しさん 2025/06/08(日) 17:15:21.24 ID:PLM9xjLn]

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

[683 デフォルトの名無しさん 2025/06/08(日) 17:18:00.36 ID:+Shzj2Ty]

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

[684 デフォルトの名無しさん 2025/06/08(日) 18:02:26.47 ID:2c7Ydjne]

4大機能ｗ

[685 デフォルトの名無しさん 2025/06/08(日) 18:45:25.24 ID:RzO7Dv3B]

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

[686 デフォルトの名無しさん 2025/06/08(日) 18:57:00.03 ID:m6lUw4i5]

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

[687 デフォルトの名無しさん 2025/06/08(日) 19:40:32.20 ID:+Shzj2Ty]

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

[688 デフォルトの名無しさん 2025/06/08(日) 19:58:30.87 ID:m6lUw4i5]

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

[689 デフォルトの名無しさん 2025/06/08(日) 20:48:40.11 ID:RG5MF58/]

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

[690 デフォルトの名無しさん 2025/06/08(日) 21:20:42.43 ID:m6lUw4i5]

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

[691 デフォルトの名無しさん 2025/06/08(日) 23:04:46.55 ID:/WNe1XQ9]

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

[692 デフォルトの名無しさん 2025/06/08(日) 23:09:16.64 ID:RG5MF58/]

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

[693 デフォルトの名無しさん 2025/06/08(日) 23:32:37.62 ID:/WNe1XQ9]

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

[694 デフォルトの名無しさん 2025/06/08(日) 23:40:52.99 ID:nJlppiBy]

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

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

[695 デフォルトの名無しさん 2025/06/08(日) 23:45:05.52 ID:RzO7Dv3B]

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

[696 デフォルトの名無しさん 2025/06/08(日) 23:50:59.82 ID:vZXisdaX]

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

[697 デフォルトの名無しさん 2025/06/08(日) 23:53:07.54 ID:vZXisdaX]

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

[698 デフォルトの名無しさん 2025/06/09(月) 00:26:00.13 ID:aoh/5V/q]

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

[699 デフォルトの名無しさん 2025/06/09(月) 01:46:53.94 ID:IFWO8L+1]

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

[700 デフォルトの名無しさん 2025/06/09(月) 05:47:34.72 ID:CW68i2LQ]

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

[701 デフォルトの名無しさん 2025/06/09(月) 06:21:28.11 ID:MX6aoBW/]

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

[702 デフォルトの名無しさん 2025/06/09(月) 06:30:16.50 ID:/CbNBsKE]

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

[703 デフォルトの名無しさん 2025/06/09(月) 07:59:52.39 ID:A/APCsbN]

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

[704 デフォルトの名無しさん 2025/06/09(月) 08:01:25.36 ID:m1yKB8bn]

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

[705 デフォルトの名無しさん 2025/06/09(月) 08:02:58.92 ID:bdAhEey/]

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

[706 デフォルトの名無しさん 2025/06/09(月) 08:05:51.20 ID:m1yKB8bn]

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

[707 デフォルトの名無しさん 2025/06/09(月) 08:07:09.99 ID:m1yKB8bn]

訂正

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

[708 デフォルトの名無しさん 2025/06/09(月) 11:02:43.94 ID:dPqUAdDo]

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

[709 デフォルトの名無しさん 2025/06/09(月) 15:47:57.32 ID:HbKFNITK]

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

[710 デフォルトの名無しさん 2025/06/09(月) 17:44:03.10 ID:T14jbayf]

接触予防マクロ

[711 デフォルトの名無しさん 2025/06/09(月) 21:31:50.96 ID:/CbNBsKE]

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

[712 デフォルトの名無しさん 2025/06/09(月) 21:46:55.24 ID:aoh/5V/q]

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

[713 デフォルトの名無しさん 2025/06/09(月) 21:58:09.18 ID:/CbNBsKE]

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

[714 はちみつ餃子 ◆8X2XSCHEME 2025/06/09(月) 22:14:55.96 ID:aoh/5V/q]

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

[715 デフォルトの名無しさん 2025/06/10(火) 01:25:09.30 ID:baavX47h]

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

[716 デフォルトの名無しさん 2025/06/10(火) 01:28:48.25 ID:zWRGTibt]

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

[717 デフォルトの名無しさん 2025/06/10(火) 01:42:17.26 ID:OrUO8mmc]

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

[718 デフォルトの名無しさん 2025/06/10(火) 02:16:00.28 ID:HpZ87BJ9]

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

[719 デフォルトの名無しさん 2025/06/10(火) 02:21:17.44 ID:I0746o4+]

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

[720 デフォルトの名無しさん 2025/06/10(火) 07:40:34.26 ID:NHBgn55o]

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

[721 デフォルトの名無しさん 2025/06/10(火) 08:56:00.68 ID:JftAYQGG]

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

[722 デフォルトの名無しさん 2025/06/10(火) 11:28:46.69 ID:Xnr//oCx]

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

[723 デフォルトの名無しさん 2025/06/10(火) 11:59:27.98 ID:OrUO8mmc]

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

[724 デフォルトの名無しさん 2025/06/10(火) 12:27:09.64 ID:sYrAmguw]

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

[725 デフォルトの名無しさん 2025/06/10(火) 12:50:16.80 ID:Ry2q2P+U]

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

[726 デフォルトの名無しさん 2025/06/10(火) 12:53:12.95 ID:elVv+WXw]

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

[727 デフォルトの名無しさん 2025/06/10(火) 13:11:32.16 ID:5Ydz39vk]

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

[728 デフォルトの名無しさん 2025/06/10(火) 14:11:45.11 ID:TSrtovVZ]

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

[729 デフォルトの名無しさん 2025/06/10(火) 16:00:17.82 ID:HozJcGjt]

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

[730 デフォルトの名無しさん 2025/06/10(火) 16:03:19.17 ID:HozJcGjt]

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

[731 デフォルトの名無しさん 2025/06/10(火) 16:13:36.43 ID:HozJcGjt]

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

[732 デフォルトの名無しさん 2025/06/10(火) 16:47:51.11 ID:S2dix7lV]

うわでた

[733 デフォルトの名無しさん 2025/06/10(火) 16:50:41.55 ID:7qJHI/Wj]

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

[734 デフォルトの名無しさん 2025/06/10(火) 17:32:44.90 ID:6a9r0WpG]

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

[735 デフォルトの名無しさん 2025/06/10(火) 17:42:17.17 ID:g81VuXMB]

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

[736 デフォルトの名無しさん 2025/06/10(火) 17:57:16.18 ID:IO/uE4l6]

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

[737 デフォルトの名無しさん 2025/06/10(火) 21:25:49.21 ID:210+b0Ig]

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

[738 デフォルトの名無しさん 2025/06/10(火) 21:31:17.08 ID:5sczGeWD]

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

[739 デフォルトの名無しさん 2025/06/10(火) 21:53:13.37 ID:210+b0Ig]

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

[740 デフォルトの名無しさん 2025/06/10(火) 22:17:06.05 ID:tc1jgizD]

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

[741 デフォルトの名無しさん 2025/06/10(火) 23:09:55.09 ID:ZGMSD8h1]

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

[742 デフォルトの名無しさん 2025/06/10(火) 23:33:39.35 ID:qWI8P8cy]

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

[743 デフォルトの名無しさん 2025/06/11(水) 12:22:55.52 ID:jlvxxwmL]

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

[744 はちみつ餃子 ◆8X2XSCHEME 2025/06/11(水) 13:51:34.67 ID:AWy+SoY4]

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

[745 デフォルトの名無しさん 2025/06/11(水) 14:44:49.21 ID:xDumJtEi]

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

[746 デフォルトの名無しさん 2025/06/11(水) 14:47:38.98 ID:eooYWpbp]

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

[747 デフォルトの名無しさん 2025/06/11(水) 14:51:01.80 ID:dp0MDJTs]

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

[748 デフォルトの名無しさん 2025/06/11(水) 14:51:40.86 ID:oPVwdzBR]

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

[749 はちみつ餃子 ◆8X2XSCHEME 2025/06/11(水) 14:57:25.35 ID:AWy+SoY4]

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

[750 デフォルトの名無しさん 2025/06/11(水) 15:03:15.57 ID:jtrpcw1X]

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

「最近もの忘れ多いかも」”超音波”が効く未来の脳ケアガジェットに期待
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次元構造をマイクロメートルレベルで初めて可視化し、断面観察にも成功しました。

[751 デフォルトの名無しさん 2025/06/11(水) 15:40:39.69 ID:/2SHSe4S]

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

[752 デフォルトの名無しさん 2025/06/11(水) 15:54:24.35 ID:oPVwdzBR]

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

[753 デフォルトの名無しさん 2025/06/11(水) 16:59:46.75 ID:iVc18kJp]

さっき調べて来ましたって内容を最初から知ってたかのように書く時の様々な特徴が某氏と全く同じだからバレバレなんだけどね

[754 デフォルトの名無しさん 2025/06/11(水) 17:04:07.73 ID:oPVwdzBR]

さっき調べて来ましたってノリであれだけC++の話できるならそれはもう十分詳しいんよ

[755 はちみつ餃子 ◆8X2XSCHEME 2025/06/11(水) 17:40:22.10 ID:AWy+SoY4]

>>753
細部まで丸暗記してるわけないだろ。
根拠になる資料 (主に規格) を確認するのが当然だと私は思ってるんだが、お前は根拠のないまま書き込んでるんか？

[756 デフォルトの名無しさん 2025/06/11(水) 18:23:50.25 ID:73ZawREd]

国策で思い出したけど
お金を使ったら10%取られて物々交換なら取られない国策あるでしょ
あれなに？

[757 デフォルトの名無しさん 2025/06/11(水) 19:02:16.12 ID:AWy+SoY4]

>>756
取り締まりが不可能な規則を課しても意味がない。

[758 デフォルトの名無しさん 2025/06/11(水) 19:10:09.89 ID:eooYWpbp]

米政府「ソフトウェアはメモリ安全でなければならない」との声明を発表
「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

[759 デフォルトの名無しさん 2025/06/11(水) 23:59:38.88 ID:s7PeEM5a]

国策か

[760 デフォルトの名無しさん 2025/06/12(木) 00:27:35.47 ID:29LmlBWU]

linuxもmac osもwindowsも否定されたわけだ

[761 デフォルトの名無しさん 2025/06/12(木) 00:45:26.17 ID:jdBLXeCX]

AppleもRustで書いてるのか
https://jobs.apple.com/en-us/details/200598995/
Our codebase is written entirely in modern Rust

[762 デフォルトの名無しさん 2025/06/12(木) 02:14:01.75 ID:LEhbsez2]

既存の置き換えは時間かかるけど
新たなものはC/C++使わずRustが各社の方針

[763 デフォルトの名無しさん 2025/06/12(木) 17:21:34.63 ID:/PCxqnPy]

>>761
それは、1つのプロジェクトへのプログラマー募集であってApple製品の全てではない。
>We are building a new distributed multi-tiered data orchestration service
>to support critical Artificial Intelligence/Machine Learning systems and
>services with direct business and customer value.

[764 デフォルトの名無しさん 2025/06/12(木) 18:02:28.45 ID:LEhbsez2]

新たな開発にはRustを使うという業界全体での普遍的な出来事

[765 デフォルトの名無しさん 2025/06/12(木) 18:03:51.97 ID:ejG6QGtN]

え？

[766 デフォルトの名無しさん 2025/06/12(木) 20:24:11.71 ID:mTbE53BM]

最近はみんなRust使ってるよな

[767 デフォルトの名無しさん 2025/06/12(木) 22:52:10.28 ID:yFGQuT0s]

環境に合わせてセキュリティ製品を無効化するRustベースのEmbargoランサムウェアを発見
https://eset-info.canon-its.jp/malware_info/special/detail/250114.html

BlackCatとHiveに続き、EmbargoグループもRustでランサムウェアペイロードを開発しています。
プロセスのスキャンと強制終了は、RayonというRustのデータ並列化ライブラリを利用して、複数のスレッドに分割されます。

[768 デフォルトの名無しさん 2025/06/12(木) 23:47:21.12 ID:2Z6xLH7x]

どこもかしこもRust製だな

[769 デフォルトの名無しさん 2025/06/13(金) 00:50:30.07 ID:Euk8Z2qV]

犯罪者もRustかい

[770 デフォルトの名無しさん 2025/06/13(金) 07:58:36.41 ID:EW1dlQVG]

rustスレだけ勢いあるな

[771 デフォルトの名無しさん 2025/06/13(金) 09:22:19.66 ID:7SY2psdg]

もうRust以外の言語に存在価値がないからな

[772 デフォルトの名無しさん 2025/06/13(金) 10:38:02.99 ID:JXhmj2e3]

Cのマクロってdefineのこと？

[773 デフォルトの名無しさん 2025/06/13(金) 10:41:53.68 ID:f5khIryW]

一人でレスパしてる香具師
めっちゃ当てはまっててワロス
watch?v=nsCKf0aQmDk

[774 デフォルトの名無しさん 2025/06/13(金) 12:11:18.07 ID:GtM+sqp8]

これからの時代、プログラミングスキルを磨いて、意味あるのかな？
お仕事は、生成AIにもっていかれるのに

[775 デフォルトの名無しさん 2025/06/13(金) 13:37:48.88 ID:+bvgw8RY]

>>774
化石になるほど使い物にならなくなる訳じゃないだろう
例えば停電した途端に仕事できなくなって納期守れないようなAIより俺らの方がまだ早いじゃん
想定が局所的か、、、

[776 デフォルトの名無しさん 2025/06/13(金) 14:44:41.80 ID:ccsGYBbu]

AIによる内製化が進むに従ってITエンジニアもユーザー企業に直接所属するケースが増えるだろうから、そっちに行ければ定年まで安泰だろう
Rustに自己肯定感を求めてるようなタイプの人達に社内の御用聞きが務まるか、そもそもやりたいかは疑問だが

[777 デフォルトの名無しさん 2025/06/13(金) 15:28:24.55 ID:EADdKRYM]

AIの時代は当然Rust一択

[778 デフォルトの名無しさん 2025/06/13(金) 17:47:14.23 ID:+Tak731A]

全部をAIに任せられるほど甘くないだろ
AIに細かく指示出すより自分でコード書いて見せた方が早い領域は残る

[779 デフォルトの名無しさん 2025/06/13(金) 18:16:39.57 ID:3/atOznW]

特定の言語でプログラムが書けるみたいな狭義かつ低次のプログラミングスキルは特定メーカーのワープロでタイピングができるとか特定メーカーの表計算ソフトが使えるとかそういうのと同じコモディティ化したスキルになっていく

大事なのは特定の言語に依存しないメタなプログラミングスキルのほう

[780 デフォルトの名無しさん 2025/06/13(金) 18:27:02.35 ID:e8dD01Bq]

それはそうだけど個別言語スレで言うことじゃないすぎる

[781 デフォルトの名無しさん 2025/06/13(金) 18:27:31.78 ID:ccsGYBbu]

>>778
コーディング能力は既に人間の方が下だから、下等な我々が細かく指示出すより、
ブラックボックスの仕様から好きに実装していただいて説明してもらった方がよい

[782 デフォルトの名無しさん 2025/06/13(金) 19:32:43.29 ID:hKGxiaka]

コモディティ化してもしなくても偶然にすぎない
偶然の産物は観察や考察するよりも編集してカットしたほうがいい
しかし編集すればするほど雑音が増えると思ってる人達にはそれができない

[783 デフォルトの名無しさん 2025/06/13(金) 19:45:58.10 ID:k1F86t2G]

>>779
その通り
特にRustも使えないと今後はプログラマ失格

[784 デフォルトの名無しさん 2025/06/13(金) 22:56:19.01 ID:TC0KAGOC]

jemallocはマジで終了だってさ
https://jasone.github.io/2025/06/12/jemalloc-postmortem/

[785 デフォルトの名無しさん 2025/06/13(金) 23:27:33.59 ID:UVwTiSSY]

>>784
終わってない、とかほざいてた人はどうなん？

[786 デフォルトの名無しさん 2025/06/13(金) 23:44:49.92 ID:/3nWCuFC]

>>784
2017年にFacebookを去った時点で手を引いて現Meta管轄なんだな

[787 デフォルトの名無しさん 2025/06/14(土) 00:01:13.21 ID:YcnPIob9]

>>786
その記事の内容を読んでそういう感想なら死んでるのと変わらない

[788 デフォルトの名無しさん 2025/06/14(土) 13:57:15.87 ID:k1IJmlZ/]

形式的には Meta が管理下に置いていたプロジェクトであるというのは間違いではないでしょ。
その上で Meta は全然やる気がなくなってるというだけで。 (少なくとも Jason の視点ではそう見えている。)

[789 デフォルトの名無しさん 2025/06/14(土) 14:50:51.36 ID:dtGV1Vl4]

凄腕のエンジニア達が長い時間をかけて育ててきたjemallocといえども、
アリーナアロケーションのようなアプリケーション依存の原始的な手法には敵わないってのは虚しい話だな
特にRust信者はともすると小手先の技巧にかまけて視野が狭くなりがちだから気をつけなければならない

[790 デフォルトの名無しさん 2025/06/14(土) 15:08:08.30 ID:YcnPIob9]

jemallocがMETAの管理下に入ってMETA寄りの機能を実装する開発方針に切り替わった
そして一般よりの機能を削減して一般からそっぽを向かれた
作者自身も一般からの需要にが付いていなかった

結局jemallocはMETA向けに局所最適化されてそこから一般向けに戻すにはかなりの人員と労力が必要だけど
それに見合うだけのメンテナーも資金もどこからも出てこない
実質死んでますよと

こういう内容

[791 デフォルトの名無しさん 2025/06/14(土) 15:13:02.44 ID:YcnPIob9]

資金力があるところに吸収されて開発されてもそれが必ずしも良いことではないと言うことだ
吸収する側には目的があって吸収して機能を実装し終わったらそれでもう満足なんだ

[792 デフォルトの名無しさん 2025/06/14(土) 15:48:51.99 ID:RARc7ln1]

万能なメモリアロケータは実現不可能
どういう用途に効率を特化するかで無数に分かれる

[793 デフォルトの名無しさん 2025/06/14(土) 15:53:14.56 ID:RARc7ln1]

>>789
最適なタイミングでまとめて確保と解放するアリーナ方式が最も性能出るのは自明

[794 デフォルトの名無しさん 2025/06/14(土) 19:21:21.54 ID:TLqczxub]

mRNAワクチンの“新たな懸念”接種済み妊婦の子どもに「異常タンパク質構造」血中で確認★2 [Gecko★]
2025/06/14(土) 15:48:24.59
https://asahi.5ch.net/test/read.cgi/newsplus/1749883704/


・ワクチン問題になっている

[795 デフォルトの名無しさん 2025/06/14(土) 20:11:15.75 ID:dS5ekNAa]

jemallocがRustから外されて各OSの標準アロケーターに戻った理由も重要だよね

[796 デフォルトの名無しさん 2025/06/14(土) 22:46:25.65 ID:3wtf6RT3]

性能は用途により一長一短
特定のアロケータが標準だとバイナリサイズで不利なため

[797 デフォルトの名無しさん 2025/06/15(日) 00:30:17.16 ID:bKWQLrbi]

#[global_allocator]標準化が1.28でjemalloc非標準化が1.32だな
外した理由はブログで書いてる
https://blog.rust-lang.org/2018/08/02/Rust-1.28/#global-allocators
https://blog.rust-lang.org/2019/01/17/Rust-1.32.0/#jemalloc-is-removed-by-default

[798 デフォルトの名無しさん 2025/06/15(日) 00:56:18.63 ID:sxaow1g9]

システム開発言語であるのにシステムのメモリアロケーターを使っていない

[799 デフォルトの名無しさん 2025/06/15(日) 00:59:44.98 ID:ujM9EzWd]

Rustにおけるシステムプログラミングというのは「ケチ臭いプログラミング」と読み替えるとよい
必ずしも低レベルであることを意味しない

[800 デフォルトの名無しさん 2025/06/15(日) 09:10:25.99 ID:sxaow1g9]

jemalloc使用するとメモリが300kb消費されると
rustプログラム一個につき300kb

[801 デフォルトの名無しさん 2025/06/15(日) 21:04:59.71 ID:nFrUb4vG]

組み込み開発はRust一択

[802 デフォルトの名無しさん 2025/06/15(日) 21:27:38.86 ID:xQVjBVZp]

WEB開発もERust一択

[803 デフォルトの名無しさん 2025/06/15(日) 21:37:03.14 ID:nFrUb4vG]

今日もRustで組み込み開発しちゃった

[804 デフォルトの名無しさん 2025/06/15(日) 22:40:54.62 ID:B7Y6UoIx]

俺はC++で開発し続けているが。

[805 デフォルトの名無しさん 2025/06/15(日) 23:08:21.56 ID:vsQD4t+X]

組込みデバイスのRustのサポート状況ってどうなん？
少し前にNVIDIAのJetsonを触ったことがあるんだけと、SDKやサンプルはC++が基本だったと思う
(例えばJetson multimedia APIというのがあって、デバイス付属のGPUで動画をエンコードする等ができるんだけど、これはC++のクラスを使うAPIだから他の言語からFFIしづらい)

こういうのがRustに対応するようになるまでは、この分野はまだしばらくC++中心になるんじゃないかと思う
ラズパイなんかはRustの話も聞くし、できることは増えてると思うけど

[806 デフォルトの名無しさん 2025/06/16(月) 02:15:29.18 ID:0s59hzvI]

メジャーなCPUならそれなりに対応してると思う
https://doc.rust-lang.org/beta/rustc/platform-support.html

SDKは需要とベンダーのやる気次第

[807 デフォルトの名無しさん 2025/06/16(月) 05:39:40.78 ID:YU6mcAo1]

ヌルポ😳😳

Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと
2025年6月16日
https://www.publickey1.jp/blog/25/google_cloud_3.html

[808 デフォルトの名無しさん 2025/06/16(月) 06:07:30.55 ID:Y7h+7ucI]

記事あんま理解できてないけどヌルポインタってそんなにまずいもんなの？
コンパイラーが検出してくれるし、スコープから外れた変数はドロップされるからそもそも参照されないかと思ってた

[809 デフォルトの名無しさん 2025/06/16(月) 06:43:29.69 ID:pyVTMG/F]

ヌルポインタ参照って
プログラムをCとかunsafeとか使わずにRustで全て作ってるとしたら起き得ないことであってる？

[810 デフォルトの名無しさん 2025/06/16(月) 08:20:04.56 ID:GmbZlZxT]

>>808-809
ヌルポインタの問題は型の非互換性、本質的には機能の非互換性の問題。

古いJavaで顕著だけど、ヌルポインタは何の機能もサポートしないのにコンパイル時はほとんどすべての型に化けることができるから、コンパイル時に問題を発見できずに実行時に問題になることがある。
本来なら互換性を保つためにヌルオブジェクトとかを使うべきだけど、言語で禁止しているわけではないので、低能力コーダーとか無能ライブラリアンとかはヌルポインタを返す関数とかを作って問題になる。

safe rust は基本的にヌルポインタを使えないので、このようなトラブルになることは少ないかと。

[811 デフォルトの名無しさん 2025/06/16(月) 11:48:14.62 ID:d1GW0AGS]

問題の本質はヌルポじゃないだろ
publickeyの人はそれがわかってない

てかGoogleの品質管理体制も杜撰すぎるな

[812 デフォルトの名無しさん 2025/06/16(月) 12:21:10.35 ID:LhShA12G]

ガッ！

[813 デフォルトの名無しさん 2025/06/16(月) 12:30:45.07 ID:Y7h+7ucI]

空白のフィールド含んだだけでクラッシュとかよく分かんないよ
俺がテストせずにこのプログラムをリリースさせた責任者だったら会社に残れないな。明らかにテスト捏造してるから
——
新しいポリシーデータには意図せず空白のフィールドが含まれており、これをサービスコントロールが読み込んで実行したところ、ヌルポインタ参照となりクラッシュが発生します
——

[814 デフォルトの名無しさん 2025/06/16(月) 13:38:36.81 ID:Zx2RP+Vb]

要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ
たまたま結果としてヌルポでクラッシュしただけで、仮にヌルポの可能性に気づけていたとしてもそれ自体がバグの原因でない以上、
問題のパターンが別の形で障害を起こしていた可能性を否定できないな

[815 デフォルトの名無しさん 2025/06/16(月) 14:56:07.05 ID:3OfwotkI]

もしRustで実装していれば、パニックですんでいたのにな

[816 デフォルトの名無しさん 2025/06/16(月) 15:28:10.23 ID:89xCrI9h]

今回の事態を招いた最も重大な要因は「リリース手続きの欠陥」であって、ヌルポ参照という"クラッシュに至る個別の事象"に着目した対策に終始するのは悪手（ヌルポ参照以外の要因で本件のような事象が再発しても良いのか、という問いにyesと答えることに他ならない）

[817 デフォルトの名無しさん 2025/06/16(月) 15:38:50.32 ID:2OOusEms]

>>814
>要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ

特定のパターンというか「新機能のために新しく適用する全世界共通のポリシーデータ」と「新機能」の組み合わせでクラッシュするんだから本番環境に適用するポリシーデータでは一切テストしてなかったってことでしょ

feature flagがなければステージングでのテストも行わず本番と同時適用ってのも意味がわからない

[818 デフォルトの名無しさん 2025/06/16(月) 15:40:30.06 ID:2OOusEms]

>>815
パニックでも結果は同じ

[819 デフォルトの名無しさん 2025/06/16(月) 16:50:55.12 ID:3OrQmcm3]

>>815
Rustで実装していればOption型になる
unwrapしない限りpanicは起きない

[820 デフォルトの名無しさん 2025/06/16(月) 17:11:52.79 ID:6J/NsGPY]

JavaはTとOption<T>を区別しないからStringでもnull検査パスしてるか分からんのよね
誰かが検査してると思ってたら誰も検査してなかったり逆に至る所で何重にも検査されてたり

[821 デフォルトの名無しさん 2025/06/16(月) 17:56:55.33 ID:Y40wNqxo]

>>819
今回のやつはRustで実装しててもunwrapしてたケースだろう

>>820
Javaの場合は@Nullableみたいなアノテーション使ってビルド時にチェッカーを走らせる

[822 デフォルトの名無しさん 2025/06/16(月) 18:02:11.42 ID:3OrQmcm3]

>>821
Optionをunwrapしていいのは常にSome自明時と
異常時にpanicで落ちていい時のみ

[823 デフォルトの名無しさん 2025/06/16(月) 18:48:18.73 ID:Y40wNqxo]

>>822
後者に該当

ポリシーデータから必須項目が欠落しているような状態はヌルポを発生させたプログラマーから見ればプログラムを即停止すべき異常事態という認識

[824 デフォルトの名無しさん 2025/06/16(月) 19:02:14.08 ID:F+AaTG3L]

Rustはわりとunwrapというかコンテキスト外し一般を使う人が多い印象があるね
そのあたりはやはりベターC++という感じがする

[825 デフォルトの名無しさん 2025/06/16(月) 19:03:13.08 ID:WftbHuxu]

>>823
異常時に停止してよい時のみpanicが使われて暴走やセキュリティの穴を防止するんだよ

[826 デフォルトの名無しさん 2025/06/16(月) 19:04:58.04 ID:WftbHuxu]

>>824
落ちてはいけないプログラムでそんなことする人はいないよ

[827 デフォルトの名無しさん 2025/06/16(月) 19:45:53.03 ID:GmbZlZxT]

>>823
panicにするかどうかを決めるのはサーバーを実装する側じゃなくてサーバーを使うユーザー側だろ。
Linusじゃないけど、サーバー側がランタイムエラーでパニックを発生させるのは根本的に問題がある。単にエラーを返すべき。

[828 デフォルトの名無しさん 2025/06/16(月) 19:53:50.09 ID:xdTbb2+R]

Rustは絶対安心安全なんだよ

[829 デフォルトの名無しさん 2025/06/16(月) 22:35:10.42 ID:GFXQS+aF]

>>827
もちろんあるべき姿としてはエラーを返すなりフォールバックさせるなりすべき
だけど現実はヌルポでエラーも返さずクラッシュさせてたわけでRustに置き換えればpanicで落としてたのと同じようなもの

つまりRustを使っていれば防げたかというと今回のケースは防げなかった可能性が高いということ

[830 デフォルトの名無しさん 2025/06/16(月) 23:23:51.15 ID:n/id3DH6]

Rustを使えば防げただろう

[831 デフォルトの名無しさん 2025/06/16(月) 23:25:29.39 ID:n/id3DH6]

>>824
そういう時はこれ

[lints.clippy]
unwrap_used = "deny"

[832 デフォルトの名無しさん 2025/06/17(火) 07:28:54.01 ID:nAKE0zH5]

>>829
ならpanicさせる>823の考えは間違いだね。

rustも安全性を標榜するならpanic禁止モードを用意すべきだわ。

[833 デフォルトの名無しさん 2025/06/17(火) 08:53:29.58 ID:wIiKTA/n]

DoS攻撃脆弱性でregexのCVEがあったけど
関連サービスの事を無視して自分勝手にpanicしちゃったら同じ脆弱性だよね

[834 デフォルトの名無しさん 2025/06/17(火) 09:28:01.71 ID:qKSR12sf]

ヌルポ騒動が起きるたびにRustの重要性が引き上がる

[835 デフォルトの名無しさん 2025/06/17(火) 09:35:12.84 ID:9ReeLirD]

>>834
ポリシーの内容をチェックして。受け入れ可能じゃなければResultでテキトーにErr返したら済んだんじゃないの？

パニックさせる必要ほんとにあったと思ってる？

[836 デフォルトの名無しさん 2025/06/17(火) 10:10:19.32 ID:ArcAimKK]

>>835
それでもこの件では障害になることには違いないのでは
クラッシュはしないかもしれないが

[837 デフォルトの名無しさん 2025/06/17(火) 10:27:20.42 ID:HytcwfDv]

Rustで書くなら関数は必ずResultもしくはOptionを返すことになり、上位で処理される

[838 デフォルトの名無しさん 2025/06/17(火) 10:32:24.66 ID:Q1H3y5Wh]

>>837
>>822にもあるけど
> Optionをunwrapしていいのは常にSome自明時と
その「自明」をコンパイラが静的分析するか>>831がデフォルトじゃないかぎり
隠れ unsafe

[839 デフォルトの名無しさん 2025/06/17(火) 10:35:09.70 ID:HytcwfDv]

>>838
unwrapは使われない
?オペレータで上位へ委託するか
match / if let等で処理される

[840 デフォルトの名無しさん 2025/06/17(火) 10:41:17.77 ID:wEWjoXoE]

このGoogleの件に関して言うなら、ポリシーの読み込み失敗即ちロールバックなんだろうからpanicは妥当
起動時に必須の環境変数が無い場合にpanicさせるようなもんだね

[841 デフォルトの名無しさん 2025/06/17(火) 10:46:12.73 ID:ya3T3y3J]

panicで全体を止めたくない時はUnwindSafeな処理単位をcatch_unwindで実行すればいい
使ったことないけど

[842 デフォルトの名無しさん 2025/06/17(火) 10:51:31.79 ID:gnbFtFWo]

>>832
ヌルポでクラッシュさせてたのは間違いではなかったとでも？

>>823はヌルポでクラッシュさせてた人たちの認識
その人たちが仮にRustを使ってたら同じようにpanicで落とすだけ
つまりRustを使っていたとしても障害は防げないという話

それに今回の障害を見てエラーハンドリングしていれば問題なかったと考えるのは短絡的すぎる
一番の問題点は一サービスの一コンポーネントがクラッシュしただけであらゆるサービスが全面的にダウンしたという点にある
だからあらゆるコンポーネントを絶対panicしないように作ろうとするよりも一コンポーネントがpanicしたとしても全面的なシステムダウンに繋がらない仕組みを作ろうと考えることが今回のような障害を防ぐための第一歩

[843 デフォルトの名無しさん 2025/06/17(火) 10:56:21.14 ID:tkXXIxpc]

>>842
まともなシステムはそれだな
プロセスが落ちてもハンドリングされる

[844 デフォルトの名無しさん 2025/06/17(火) 10:58:00.04 ID:tkXXIxpc]

異常状態のままプロセスが走り続けるよりもpanicなどでプロセス終了が正しいシステム構築

[845 デフォルトの名無しさん 2025/06/17(火) 11:09:29.63 ID:QpxoSzQp]

異常状態のまま動き続ける言語よりさ
panic or エラー処理されるRustが良い結論は変わらんよね

[846 デフォルトの名無しさん 2025/06/17(火) 11:13:48.44 ID:wEWjoXoE]

>>842
Google Cloud APIのコントロールプレーンのコアコンポーネントはさすがに一サービスの一コンポーネントとかいうレベルじゃないよ
OSのカーネルみたいなもん
こんなのヘタに誤動作を続けられたら会社が吹き飛ぶようなセキュリティ事故に繋がる可能性もあるわけで、死んでくれた方がマシ

[847 デフォルトの名無しさん 2025/06/17(火) 11:52:15.15 ID:e/HQQ23L]

ワンワンパニック

[848 デフォルトの名無しさん 2025/06/17(火) 12:50:17.15 ID:ya3T3y3J]

Javaで
if (value == null) {
throw AppException();
}
を書き忘れるのとRustで
let Some(value) = opt_value else { return Err(AppError); }
の代わりに
let value = opt_value.unwrap();
と書くのは発生リスクが全然違うと思うんだけど
Javaでうっかりnullチェックを忘れる人はRustでもうっかりunwrapを使うものなのか？

[849 デフォルトの名無しさん 2025/06/17(火) 13:10:12.25 ID:aeCwWEdf]

>>848
本人判断で「自明」と決めつけて意図的にunwrapを使うのでは

[850 デフォルトの名無しさん 2025/06/17(火) 13:36:52.80 ID:gAVRJIie]

>>822によれば
本人判断で「panicで落ちていい」と決めつけて意図的にunwrapを使うパターンもある

[851 デフォルトの名無しさん 2025/06/17(火) 14:21:36.03 ID:w2F36Aoo]

>>848
Rustでは必要により明示的にpanicさせる.unwrap()とコードを書いた時のみpanicが起きる
意思が必要

[852 デフォルトの名無しさん 2025/06/17(火) 15:48:15.44 ID:FL91roa2]

>>846
クラッシュしたのはコントロールプレーンの一部であるポリシーチェックシステムのさらにその一部のバイナリ
もっと言えば問題が起きたのはそのまた一部のクォータチェック部分

クォータチェックができなければGCPの全サービスを落とすべきというビジネス判断としてはなくはないがIncident Reportを見る限りGoogleはそうは考えてない

[853 デフォルトの名無しさん 2025/06/17(火) 16:05:37.54 ID:UZ5mCAEQ]

Rustにしとけ
続行不可能で意図的にpanicさせるか
きちんとResult/Option処理するかになる

[854 デフォルトの名無しさん 2025/06/17(火) 16:27:46.74 ID:9ReeLirD]

リリースしてから実際にポリシー変更が発生するまでの2週間、
テストやりこんで最後のバグだしするまでの時間とみなすか、
リリースヨシ！と思ってたかだよな

リリース後も2週間頑張ってテストやったけど境界条件探すの下手くそで見つけられませんでした、で通るかな。自分のことのようにゾッとする

[855 デフォルトの名無しさん 2025/06/17(火) 17:05:59.65 ID:FL91roa2]

>>854
プログラムの変更とポリシーデータの変更は責任者も管轄組織もプロセスも違うんだと思う
ポリシーデータのほうはビジネスよりの組織が管轄というのはよくある話
なのでDev的にはリリースヨシ！

改善点の2点目に「Regardless of the business need for 〜」とあるからOpsはBizの政治力で本来とは違うプロセスを強制させられたのかもしれない

[856 デフォルトの名無しさん 2025/06/17(火) 18:12:51.30 ID:FL91roa2]

ここに内部事情を含めていろいろ書いてあった
https://news.ycombinator.com/item?id=44274563

[857 デフォルトの名無しさん 2025/06/18(水) 00:29:09.64 ID:1jrMASAC]

ここでの議論と同じだね
Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ

[858 デフォルトの名無しさん 2025/06/18(水) 01:06:16.44 ID:aQwOTYhv]

>>857
>Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ

ここでもHNでもそんな議論はされてない
ただ複オジが連呼してるだけ

[859 デフォルトの名無しさん 2025/06/18(水) 01:09:01.01 ID:ZwZRjmCs]

さっさとC++捨ててRustにすれば防げたのにな

[860 デフォルトの名無しさん 2025/06/18(水) 01:12:36.99 ID:SA0JPy/4]

>>858
初心者は今回のこのまとめを見るといい
https://news.ycombinator.com/item?id=44281839

[861 デフォルトの名無しさん 2025/06/18(水) 02:58:44.97 ID:vm71nNgD]

Googleの事案なんてどうでもよくてインシデントにかこつけてRustの布教がしたいだけ
だから何を書いても無駄

[862 デフォルトの名無しさん 2025/06/18(水) 06:20:38.83 ID:KrGEp9Dg]

Rustを採用していれば防げた事案

[863 デフォルトの名無しさん 2025/06/18(水) 09:57:10.50 ID:NQ+tIPxW]

>>848
本質は同じ

書き忘れではなくロジカルな思い違いもある
ここでnulｌはないやろとここErrはないやろは同じで思い込みだから

言語によって優劣とかじゃなく人間の限界がある

[864 デフォルトの名無しさん 2025/06/18(水) 10:09:02.91 ID:4yVSzLnj]

>>863
全く違う
unwrap()はNone時にpanicを起こすための関数
書き忘れでpanicしない

[865 デフォルトの名無しさん 2025/06/18(水) 10:20:51.18 ID:NQ+tIPxW]

＞　書き忘れではなくロジカルな思い違いもある

[866 デフォルトの名無しさん 2025/06/18(水) 10:31:14.78 ID:GRTFL2K0]

panicさせてはいけないプログラムでpanicさせる関数を呼ぶバカはいない
reviewでもバレる

[867 デフォルトの名無しさん 2025/06/18(水) 10:49:25.62 ID:NQ+tIPxW]

メモリリークさせてはいけないぷろぐらむでめもりりーくさせるばかはいない！

[868 デフォルトの名無しさん 2025/06/18(水) 11:01:39.66 ID:Ulz+jHl5]

Rustを使えばメモリリークも未定義動作もなく安全安心よ

[869 デフォルトの名無しさん 2025/06/18(水) 11:23:14.90 ID:lQpFkqVW]

haskellと比べて、unwrapが気軽に使えすぎる気はする

[870 デフォルトの名無しさん 2025/06/18(水) 11:33:39.23 ID:S+5h0Q7c]

ErrやNoneの時にpanic!を呼びたい場合が多いからunwrapがある
呼びたくないのに使うのは痴呆

[871 デフォルトの名無しさん 2025/06/18(水) 11:34:34.48 ID:FuDCb+RV]

index out of boundsやdivide by zeroをはじめ意図せずpanicを起こすケースなんていくらでもある

[872 デフォルトの名無しさん 2025/06/18(水) 11:39:44.34 ID:SMOhWm6L]

panicはcatchできるし
そのthreadが死ぬだけだし
困らんよな

[873 デフォルトの名無しさん 2025/06/18(水) 11:43:26.69 ID:U/ksL7Wg]

>>871
panic禁止のプログラムのためにpanicしない方法が用意されていますよ
勉強しましょう

[874 デフォルトの名無しさん 2025/06/18(水) 11:45:58.97 ID:3o9Ti177]

>>860
視野の狭い末端プログラマーの視点だな
システム全体が見えていない

[875 デフォルトの名無しさん 2025/06/18(水) 11:46:56.90 ID:3o9Ti177]

>>873
視野の狭い末端プログラマーの視点だな
システム全体が見えていない

[876 デフォルトの名無しさん 2025/06/18(水) 11:50:22.96 ID:7xP0Uzu5]

>>874
落ちてはいけないシステムをUB地雷だらけのC++で書くことが愚か

[877 デフォルトの名無しさん 2025/06/18(水) 11:52:41.70 ID:qy96omZz]

>>875
Rustのスレでシステム全体って何やねん
説明してみ

[878 デフォルトの名無しさん 2025/06/18(水) 12:16:05.81 ID:iDJPvmxA]

「意図したpanic」禁止したら良い
その「意図」が正しいのかコンパイラが静的分析出来ないから

[879 デフォルトの名無しさん 2025/06/18(水) 12:29:52.79 ID:rx2CZFrG]

>>878
panicはプログラムやスレッドが続行不可能な時に正しく終了させるためにあります
禁止は困ります

[880 デフォルトの名無しさん 2025/06/18(水) 13:09:11.05 ID:uPLWgFQC]

mseditorがpanicしたら編集中のデータが飛ぶけど、それが「正しく終了」か？

[881 デフォルトの名無しさん 2025/06/18(水) 14:28:18.37 ID:AeXwuQQu]

ヌルポやバッファオーバーランに比べれば比較的マシ

[882 デフォルトの名無しさん 2025/06/18(水) 15:01:02.42 ID:90mEbGf5]

意図的ヌルポでセグフォと
意図的unwrap panicでabortは同じ

[883 デフォルトの名無しさん 2025/06/18(水) 15:13:41.28 ID:5Mu65nKv]

会社の怖い先輩が俺のコードはunwrapでいいんだよと言ったら、そうするしかないよね

[884 デフォルトの名無しさん 2025/06/18(水) 15:24:13.90 ID:45cvT+VF]

まさかとは思うがnullチェックしてれば防げた障害だと思ってるやつがいるのか？

[885 デフォルトの名無しさん 2025/06/18(水) 15:37:47.95 ID:s5c+Ng5v]

ぬるぽでクラッシュしたと聞いたけどnullチェックで防げないぬるぽってあるんすか

[886 デフォルトの名無しさん 2025/06/18(水) 15:49:01.71 ID:FHNv6txf]

今どきC++で新たなコードを書くから悲惨な事故が起きた

[887 デフォルトの名無しさん 2025/06/18(水) 16:01:28.34 ID:hZyAyOg0]

>>884
Rustなら防げたと言ってるあのおじさんを除けばそこまてのバカはいないかと

[888 デフォルトの名無しさん 2025/06/18(水) 16:01:44.34 ID:s5c+Ng5v]

設定がおかしい場合の例外処理フローはあったけどそこに入る前にぬるぽで爆死した認識

[889 デフォルトの名無しさん 2025/06/18(水) 16:35:49.37 ID:YaS/uO3Z]

RustならコンパイラがAIよりも厳密なチェックをしてるから防げるだろ

[890 デフォルトの名無しさん 2025/06/18(水) 17:03:37.08 ID:d8qsI0SX]

Rustは言語仕様が優れているけど
言語仕様が腐っていればAIでも防げない

[891 デフォルトの名無しさん 2025/06/18(水) 17:43:59.13 ID:mspDq+p2]

世界最長のコンテキストウィンドウ100万トークン入力・8万トークン出力対応にもかかわらずたった7800万円でトレーニングされたAIモデル「MiniMax-M1」がオープンソースで公開され誰でもダウンロード可能に
2025年06月18日 11時43分
https://gigazine.net/news/20250618-minimax-m1-open-source/
>>MiniMax-M1は、合計4560億のパラメーターが含まれており、トークンごとに459億のパラメーターがアクティブになるとのこと。これはDeepSeek R1の8倍に相当するコンテキストウィンドウです
>>以下のグラフは競技レベルの数学、コーディング、ソフトウェアエンジニアリング、エージェントツールの使用、長文理解タスクにおけるパフォーマンスを主要な商用AIモデルと比較したもの。赤色がMiniMax-M1で、どのタスクにおいても競合AIモデルに匹敵するパフォーマンスを発揮できている
>>MiiniMax-M1はいくつかのベンチマーク、特に長いコンテキスト駆動のベンチマークでClaude Opus 4のパフォーマンスを上回りました」と報告
※AIを動作させている動画あり
↓上記のAIお下記をプレイさせれば性能が判明する
Gemini 2.5 Proは手持ちのポケモンが瀕死になるとパニックに陥る
2025年06月18日 12時30分
https://gigazine.net/news/20250618-pokemon-gemini-panic/
◇
[プロテクトガードやセキュリティーホール発見可能]
※1 プログラムのバグ技[裏抜け道]を使用できる＝チートコードを発見可能
・ マリオカートのショートカットはプレイヤー「極悪人」の表の抜け道でNPC「一般人」は使用不可能
[インサイダー/談合/なねーロンダリング/霊感商法など行う時の悪行で音波や電波をしての悪行の方法を発見可能
※ 政治家の法律上の抜け道を仕込める＝ある業種だけの法律の抜け道を発見可能
[一般大衆の思考である特定の極悪人から目線を特定の統合失調症へ返させる装置]
※ ＡＩは正確な情報で人間を信用させれる＝ＡＩは嘘の情報を一部混ぜて人間を洗脳できる

[892 デフォルトの名無しさん 2025/06/18(水) 18:45:36.06 ID:JUQ8VjRJ]

まさかとは思ってたがnullチェックで防げたと勘違いしてるやつ結構いるんだな

[893 デフォルトの名無しさん 2025/06/18(水) 19:12:39.40 ID:M/E4rLLd]

＞読み込みデータに空白フィールドがあり、これがヌルポインタとなって参照した時点でクラッシュを引き起こした。

[894 デフォルトの名無しさん 2025/06/18(水) 20:36:14.97 ID:QsB71xf7]

OptionやResultの型をきっかけとして問題に気付けた可能性はあるんじゃない？
あくまで間接的な可能性でしかなく、この件をもってRustだったら起きなかったとかいうのはアホ丸出しだけども

[895 デフォルトの名無しさん 2025/06/18(水) 20:49:33.05 ID:JDJPNF+q]

Rustなら上位へそのエラー返して
その入力データに対するAPIでエラー返すだけだろ

[896 デフォルトの名無しさん 2025/06/18(水) 22:27:10.05 ID:/Y6EEbbi]

>>894
いいかげんにしろよ
Rustでどうやって問題が起きるんだよ

[897 デフォルトの名無しさん 2025/06/18(水) 22:47:29.81 ID:BBnSRnVn]

この件については、クラッシュを回避しエラーレスポンスを返したところで結局障害になることには違いがないからだな

[898 デフォルトの名無しさん 2025/06/18(水) 22:51:57.91 ID:ikP0pQuf]

>>894
間接的な可能性もないでしょ

[899 デフォルトの名無しさん 2025/06/18(水) 23:03:07.16 ID:0KvtUriT]

>>897
Googleのレポート見ろよ
エラーを返せていれば障害にならなかった

[900 デフォルトの名無しさん 2025/06/18(水) 23:18:21.28 ID:dYsLBH+C]

>>899
そんなことどこにも書いてないぞ
エラーを返していればなんで障害にならないんだ？
回復不能なエラーだぞ

[901 デフォルトの名無しさん 2025/06/18(水) 23:25:54.18 ID:7PLt8980]

Rustなら回避できたケースだけど
無理！と言う人は具体的に無理なシナリオを示してみたら？

[902 デフォルトの名無しさん 2025/06/18(水) 23:41:41.61 ID:sPCFWro/]

ワロ
理解できないから教えてくれと言えばいいものを

[903 デフォルトの名無しさん 2025/06/18(水) 23:53:20.04 ID:jD4yZQcZ]

公式読めよ
Rustにしてればポリシー変更データをエラーにして受け付けず落ちることもなく被害なし

[904 デフォルトの名無しさん 2025/06/19(木) 00:10:11.24 ID:oQzIUk1I]

設定のミスで１台のATMが使えなくなるか全部のATMが使えなくなるかみたいな話でしょ
どっちも障害だから同じだって考え方もあれば
障害を１台に抑えることに価値があるって考え方もある
Rustでも防げないって人は前者だしRustなら防げたって人は後者
どっちの考え方もそれなりに正しい

[905 デフォルトの名無しさん 2025/06/19(木) 00:25:10.66 ID:KZlMfI+O]

>>897
exponential backoffが実装されてなかったから
リクエスト単位のエラー返しにしてた場合は
復旧にもっと時間がかかってたと思われる

かといってC++でヌルポはだめだけどな

[906 デフォルトの名無しさん 2025/06/19(木) 00:48:27.34 ID:ftBjTcDx]

>>905
新たなポリシー変更要求がエラーで受け付けられなくて落ちることもないから障害が起きていない

[907 デフォルトの名無しさん 2025/06/19(木) 01:27:03.00 ID:l2wwX0Hv]

>>906
どこにそんなこと書いてる？
新しいポリシーがSpannerに書かれてレプリケートされた後の話だろこれ

[908 907 2025/06/19(木) 01:37:22.30 ID:l2wwX0Hv]

ああ、もしかしてポリシーのチェックというのをポリシー自体のバリデーションと勘違いしてるのかな
正しくはポリシーに基づいてAPIリクエストをチェックする処理のことなんで、新しいポリシーが反映された結果としての障害だよ

[909 デフォルトの名無しさん 2025/06/19(木) 01:38:01.02 ID:QXnAvsJc]

>>904,906
君は何を言ってるんだい？
Googleのレポート見ろよ&&公式読めよブーメランが刺さってるぞ

[910 デフォルトの名無しさん 2025/06/19(木) 02:14:01.17 ID:Pd2QOZgo]

>>908
新しいポリシーを反映させないか
反映させても空白のみエラーで飛ばせば障害は起きていない

[911 デフォルトの名無しさん 2025/06/19(木) 04:21:35.41 ID:yro0K3vV]

Rustにしとけってことか、速い話が

[912 デフォルトの名無しさん 2025/06/19(木) 05:04:25.47 ID:ct5m24p0]

落ちるプログラムを各リージョンにバラ撒かなければ何製でも防げてる
もちろんRustなら確実に防げた

[913 デフォルトの名無しさん 2025/06/19(木) 06:59:17.36 ID:tFafecL1]

とにかくRustにすれば安心安全
これはもう常識

[914 デフォルトの名無しさん 2025/06/19(木) 11:59:43.17 ID:cYRDzc4D]

ちゃんとした人が、Rustを使った場合に限る。
セキュリティもそうだけど、人が関わると碌なことがない。

[915 デフォルトの名無しさん 2025/06/19(木) 12:27:53.31 ID:/pQfT2SX]

Rustは安全に配慮したコンセプトはいいけど、それを徹底できていない。
せめてSafe Rust強制モードとpanic禁止モードは用意しておくべきだった。

[916 デフォルトの名無しさん 2025/06/19(木) 21:29:19.19 ID:67nyX+fT]

CPUとメモリは自由なunsafeが本質なので下位のライブラリは標準もデファクトもunsafeで作られている

[917 デフォルトの名無しさん 2025/06/19(木) 21:38:06.06 ID:67nyX+fT]

panicは意図せず混入防止も兼ねてこんな運用が多いかな
[lints.clippy]
missing_panics_doc = "warn"

[918 デフォルトの名無しさん 2025/06/19(木) 21:49:11.90 ID:nNn4PbNI]

標準ライブラリが内部では unsafe だらけというのは確かにそう。
外側に対しては安全になるように配慮してるけど、バグが絶対にゼロかというとそんなことはないし、実際に発見されたこともある。
まあ unsafe に限らず処理系や標準ライブラリにバグがあることを疑ってたらきりがないからそこらは割り切らないと仕方なくない？

[919 デフォルトの名無しさん 2025/06/19(木) 21:56:40.37 ID:6vmjzLKI]

みんな律儀にResultは全てちゃんとハンドリングしてるの？
Mutex.lock() なんかは気にせず unwrap してるんだけど

[920 デフォルトの名無しさん 2025/06/19(木) 22:11:01.42 ID:nNn4PbNI]

>>919
ロックが失敗するのはスレッドがパニックしたとき。
つまりハンドリングするならそのスレッド内のエラーであるべきで、 Mutex.lock の失敗に対してハンドリングしても出来ることがない。
そこは普通は unwrap してよいところだと思う。

[921 デフォルトの名無しさん 2025/06/19(木) 23:34:30.87 ID:67nyX+fT]

そのmutex毒入り状態からの復帰処理をしたい場合はunwrapせずにErr時に処理とclear_poison()する

[922 デフォルトの名無しさん 2025/06/20(金) 00:31:53.70 ID:xog7LFS0]

これおもしろー

https://blog.guillaume-gomez.fr/articles/2025-06-19+Rust%3A+Optimizing+integer+to+string+conversions

ポインターアクセスより配列の方が速いんやー

[923 デフォルトの名無しさん 2025/06/20(金) 01:02:39.89 ID:SpbybkFq]

unwrapではなくexpectを使う。

[924 デフォルトの名無しさん 2025/06/20(金) 01:08:46.49 ID:xog7LFS0]

>>923
いや、Optionにはunwrap使ってええんやで
コードに合わせて柔軟に対応すりゃバグは防げるよ
ビジネスロジックのバグは入念なテストしないと見つけられないけどね
ビジネスロジックのバグでシステム障害になることもまあ、あるっちゃあるよねテストしてなきゃ

[925 デフォルトの名無しさん 2025/06/20(金) 01:13:11.37 ID:/9Nz/yYP]

>>922
昔読んだが00～99のテーブルをコピーするところだな
配列境界検査は起きないコードだから速度は同じ

[926 デフォルトの名無しさん 2025/06/20(金) 01:18:17.09 ID:/9Nz/yYP]

>>924
panic許容シーンでない場合
絶対Some保証できない場ではunwrapもexpectも使わないよな

[927 デフォルトの名無しさん 2025/06/20(金) 07:50:16.10 ID:d5bZ3vB1]

expectに書く文がいまいち分からんのだよな
エンドユーザーがその一文だけ見て何か意味があるとも思えないし
デバッグする開発者向けなら結局前後の文脈込みで見るしかないから
unwrapにして詳細をコメントに書いたほうがいい気がしている

[928 デフォルトの名無しさん 2025/06/20(金) 08:04:54.66 ID:Op1qS17W]

>>927
ユーザに文章を示してpanicさせたいの？
文章をprintかeprintしてからpanic!呼んだら？

[929 デフォルトの名無しさん 2025/06/20(金) 08:15:40.44 ID:d5bZ3vB1]

>>928
いや、そうじゃなくて「unwrapの代わりにexpectを使ってunwrapしても大丈夫な理由を明記すべき」みたいな言説があるじゃん？
そのときにexpectに書くべき文がわからんって話

ユーザ向けにエラーとして表示したいならそりゃ普通にResult使うし、
どうしてもパニックしたいならprintlnすればいいのはその通りだけど

[930 デフォルトの名無しさん 2025/06/20(金) 08:22:37.63 ID:xog7LFS0]

基本フロントエンド側とAPIのエラーコード、エラーメッセ仕様は最初に決めておくから、あとは「どの関数レイヤーで」そのIFに合わせこむかだけじゃない？
ここのスレ多分Rustを業務用で使ってる人ばっかだから仕様の取り決めとから雇用主から降ってくるもんだと思うけど。返すエラー定義決まってなきゃそもそもテストコード先に書けないし、納品物にもテスト結果入れれなくて困るしな

[931 デフォルトの名無しさん 2025/06/20(金) 08:25:55.42 ID:xog7LFS0]

個人的にはtracing::debug!で自分用のデバッグ出力はON/OFFしてるけど、エラーコードやエラーメッセージは案件別に全然仕様が違うwwwやめてwwwから、仕方なくErrで一旦上げてresponse.bodyに詰め込む直前で相手さんの期待する結果になるようにparseしてることが多い

フロントエンド側で翻訳ぐらいせえやーって思うけど、たまにバックエンドで各言語に合わせて翻訳やってくれー案件もあったりするしバラバラで何考えてんのかはよー分からん

[932 デフォルトの名無しさん 2025/06/20(金) 09:04:21.71 ID:ymNSNGAk]

>>929
https://doc.rust-lang.org/std/error/index.html#common-message-styles
に尽きると思うが、何がわからんのかわからん
原則としては例外ケースが生じない確信があろうとエラーコンテキストは引き継がれるべきで、
panicさせるのは当該ケースの対処のしようがないことがその場で明らかなケースのみ
そして君のコード内でコントロールのしようがない事象である以上は基本的にそれは外部要因によるものだろうから、その要因を記載すればいい

[933 デフォルトの名無しさん 2025/06/20(金) 09:47:50.29 ID:Dy/CHU8X]

>>932
外部要因ならコード作者は制御できないんだからResultで表現すべきではない？
unwrapするケースって「このコードパスではxは（自分が書いたロジックが間違ってなければ）確実にSomeだから安全にunwrapできるはず」みたいなのだと思うんだけど、
その文をexpectに書いたとして誰が読むんだ？って疑問

[934 デフォルトの名無しさん 2025/06/20(金) 10:32:17.84 ID:p4ugM+VW]

panic時のメッセージは未来の自分を含めて他の開発者向け

ここの2つを読んでおくといいと思う
https://burntsushi.net/unwrap/#why-not-use-expect-instead-of-unwrap
https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/

[935 デフォルトの名無しさん 2025/06/20(金) 11:10:25.36 ID:Dy/CHU8X]

開発者向けにコードの意図を説明するのって普通はコメントだと思うんだよね
例えばunsafeを使っても安全な理由とかもコメントで書くし
なのにunwrapに限ってわざわざ文字列リテラルで書く理由が分からない（複数行や長文も書きづらいし）
コメントとの違いは実行時に表示できることではあるけど
実行時にその一文を出せて嬉しいか？
開発者なら結局周辺含めてコード読むんじゃない？

[936 デフォルトの名無しさん 2025/06/20(金) 11:19:56.95 ID:FlGaOpZd]

書いてて思ったけど「このメッセージが表示されたらライブラリのバグなんでこのGithubまで報告してね」
みたいなメッセージなら意味あるかな、という気がした
エンドユーザーが見てちゃんと理解できるから実行時に出す意味もあるし、
ライブラリの内部エラーだからアプリケーション側には責任がないことも表明できるし

[937 デフォルトの名無しさん 2025/06/20(金) 11:25:39.91 ID:xog7LFS0]

>>936
これいいな。OSSならそんな感じだしエンタープライズなら開発担当部門書いとこ

[938 デフォルトの名無しさん 2025/06/20(金) 12:33:04.85 ID:3ZKjcbd7]

バグなんて他にもいくらでもあるんだから、それこそunwrapに限ってそんな懇切丁寧なケアをする理由がない
やらかした犯人なんてgit blameですぐわかる

[939 デフォルトの名無しさん 2025/06/20(金) 13:09:09.82 ID:LFsGGVpd]

expectは使用者とか使用状況に対する期待だと思ってた
メッセージはコメントのPanicsに対応させる感じ

/// ...
///
/// # Panics
/// - Panics if the given size is 0.
///
pub fn make_buffer(size: usize) -> Buffer {
let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");
// ...
}

[940 デフォルトの名無しさん 2025/06/20(金) 15:04:20.99 ID:3ZuChe0s]

>>939
基本的にはその考え方で正しい。
でも標準ライブラリや処理系すらそうしてないし、現実は理想通りではない。

[941 デフォルトの名無しさん 2025/06/20(金) 16:00:22.03 ID:r2H2v8it]

Haskellにはならなかったな
Rustにもならないのでは？

[942 デフォルトの名無しさん 2025/06/20(金) 16:21:36.04 ID:+wQsfMK/]

>>941
Rustは本来的にはコーディングの誤りに対して939のようにわりと問答無用でpanicする指向だと思うけど、
関数型というかHaskellかぶれのオモチャにされてるせいで実行時panicダサいみたいな空気が醸成されてきている一方で、
なんでも型のコンテキストで上手に扱えるほど型に表現力があるわけでもないから中途半端な感じになってるね

[943 デフォルトの名無しさん 2025/06/20(金) 16:41:57.96 ID:3ZuChe0s]

システムプログラミング言語としての性質があるから仕方がない面はある。
ハードウェアやら OS やらが Rust の性質に従ってくれるとは限らないので言語の側で合わせないと仕方がない。

[944 デフォルトの名無しさん 2025/06/20(金) 16:53:23.26 ID:IXOAfd5T]

Rustバランスいいよな
抽象度の高い記述ができつつC言語の代替もできる

[945 デフォルトの名無しさん 2025/06/20(金) 17:25:54.91 ID:LFsGGVpd]

Haskellもボトム型あるから変わらんだろ
どの型の値も計算できない可能性を内包してる

[946 デフォルトの名無しさん 2025/06/20(金) 18:40:08.56 ID:0ePzwW3B]

>>936
そういうのはまとめてpanic handlerに書いたほうがいいんじゃないかな
最近はあまり使われてないかもしれないけどhuman-panicとかがそれ用

あとstdのリファレンスにもexpectに書くメッセージのスタイルについて解説があった
https://doc.rust-lang.org/std/error/index.html#common-message-styles

[947 デフォルトの名無しさん 2025/06/21(土) 18:45:15.07 ID:usD2bL3Y]

>pub fn make_buffer(size: usize) -> Buffer {
>let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");

事前条件がNonZeroなら
pub fn make_buffer(size: NonZeroUsize) -> Buffer
にしたほうが堅さという意味ではよくない？

[948 デフォルトの名無しさん 2025/06/21(土) 19:54:31.34 ID:aOIRcMzj]

外部入力が起源のデータに対しては必ずエラーを返す
プログラム自身発ならバグであり続行不可なのでpanicしてもよい

[949 デフォルトの名無しさん 2025/06/21(土) 19:55:55.14 ID:CfyG8iYl]

>>947
NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
NonZeroにしたところで結局呼び出し元でのチェックが0との比較からOptionのチェックに変わるだけのことでしかなく、
コードが冗長かつ余計なoptionが入ることでノイズが増え意図が不明瞭になるし、
unwrapしちゃったらpanic時のエラーもわかりづらい
ダメってわけじゃないが呼び出し元のことを考えると独善的な感が否めない

[950 デフォルトの名無しさん 2025/06/21(土) 22:49:35.45 ID:qYLKV/K+]

>>949
>NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
Optionと一緒に使うためのものというのはよく意味がわからない

例えばOptionに置き換えて考えてみたとしてこういう実装があったらおかしいと思わない？
fn make_buffer(size: Option<usize>) -> Buffer {
let size = size.expect("size must not be None”)
…
}

簡単に型で表現できないものならまだわかるんだけど

[951 デフォルトの名無しさん 2025/06/21(土) 23:02:46.26 ID:qYLKV/K+]

呼び出し元は外部入力なら
let size = NonZeroUsize::new(input_size)?;
let buffer = make_buffer(size);

定数なら
let buffer = make_buffer(NonZeroUsize::new(1024).unwrap());

validation前とvalidation後で型を変えるプラクティスと同じでこっちのほうが望ましいことのほうが多いんじゃないかという気がする

[952 デフォルトの名無しさん 2025/06/21(土) 23:54:32.82 ID:l7fBsL1H]

整理されて今はこう書くNonZero::<usize>::new(1024)
いずれにせよ外部データ由来時でもpanicさせ得る>>947は筋が悪い

[953 デフォルトの名無しさん 2025/06/22(日) 00:46:32.15 ID:DjMaTCto]

slice::windowsとかstdでも似たような実装はそれなりにある
pub fn windows(&self, size: usize) -> Windows<'_, T> {
let size = NonZero::new(size).expect("window size must be non-zero");
Windows::new(self, size)
}

windowサイズはバグ以外では0を指定しないだろうという想定だと思うがcalleeとcallerのコードを書く人間が異なっていて認識の齟齬があったりすればバグになるからエルゴノミクスとバグリスクのトレードオフってことになる

[954 デフォルトの名無しさん 2025/06/22(日) 01:30:55.82 ID:MKJ6VV9n]

docコメントの
///
/// # Panics
///
/// Panics if `size` is zero.
///
とセットで見ないといけない

[955 デフォルトの名無しさん 2025/06/22(日) 09:45:37.71 ID:fHVyA0qw]

RAIIが破綻するレベルのパニック、という意味の専門用語があればいいんだよね

[956 デフォルトの名無しさん 2025/06/22(日) 12:30:29.11 ID:4aXQSYOG]

・人間の思考「脳波」は頭蓋骨の外に漏れない
人間の脳は発光していた！「脳が放つ光」の観測に初成功
2025.06.19 12:00:38 THURSDAY
https://nazology.kusuguru.co.jp/archives/179808
>>カナダ・アルゴマ大学（Algoma University）の最新研究で、ついにこの「脳の光」を頭蓋骨の外から観測することに成功したのです。
>>UPEは細胞の代謝活動、特に酸化反応によって発生する副産物の一種です。
>>以来、UPEはあらゆる植物や動物の細胞からも確認されており、生体内の酸化ストレスや老化、さらにはがんの診断補助にも応用が期待されてきました。
>>脳は体の中で最も代謝が活発な臓器のひとつであり、神経活動に伴って活性酸素が多く発生します。
>>チームは今回、20人の健康な成人を対象に、特殊な装置を用いた実験を実施しました。
>>被験者は真っ暗な部屋に座り、頭には脳波計を装着。
>>その周囲には、光電子増倍管（PMT）と呼ばれる極微弱な光を検出する装置が配置されました。
>>そして被験者には、目を開ける／閉じる、あるいは音楽（120BPM）を聴くといったシンプルなタスクを行ってもらい、その間のUPEと脳波の変化を同時に測定したのです。
☆>>まず、脳からのUPEは背景光（周囲の空気中のノイズ）とは明確に異なる変動パターンを持つことが判明したのです。
>>とくに後頭部（視覚野）と側頭部（聴覚野）から検出された光は、安静時でも一定のリズムと変動性を示し、他の部位とは異なるスペクトル的特徴を持っていました。
>>さらに目を閉じたときに増える「アルファ波」と呼ばれる脳波の活動と、UPEの強さが同期していることも発見されました。
>>これはつまり、脳の電気的な信号（脳波）と、化学的な代謝反応（UPE）が連動していることを意味します。
>>この成果は、従来のfMRIやPETスキャンのような「重装備で高コスト」な装置を使わずとも、非侵襲・低刺激で脳機能の状態を“光”から読み取る可能性を示すものです。
>>研究者たちはこの新しい手法を「光脳波記録（photoencephalography）」と名付けました。

[957 デフォルトの名無しさん 2025/06/22(日) 12:58:47.51 ID:LDKwjazM]

>>955
パニックのレベルじゃなく処理単位の特性だけどUnwindSafeがある

[958 デフォルトの名無しさん 2025/06/22(日) 23:16:05.62 ID:fHVyA0qw]

無限ループがあれば、終了しないスレッドや呼ばれないデストラクタもありうる
bottomもabortもpanicも、無限ループよりはマシだから禁止されない

[959 デフォルトの名無しさん 2025/06/22(日) 23:59:22.53 ID:ohTY4CfY]

exitよりもpanicが優れている
多くのメリットがある

[960 デフォルトの名無しさん 2025/06/23(月) 15:14:34.98 ID:Lo0+xYyX]

無職や転職をしたい
上記の方を紹介していただけませんか？

誰でも歓迎❣
未経験でも40歳まで採用しています⭕

ぜひご相談ください🙏

https://i-c-i.jp/members/

電話番号
03-6459-0063

[961 デフォルトの名無しさん 2025/06/23(月) 15:14:44.43 ID:Lo0+xYyX]

株式会社アイ・シー・アイ
野村総合研究所が設立した、信頼と実績のあるIT企業です。
未経験でも大丈夫！40歳までの方ならどなたでもご応募いただけます。
日本の大手大企業のソフトバンク、キャノングループ、富士産業で働けます！
雇用形態は無期雇用派遣。一つの現場で最低5年間じっくりインフラ運用監視の経験が積めます。

年収は280万円、賞与は年3回と安定した待遇をご用意し、「社員の人生を幸せにするため」の福利厚生も充実しています。

当社はまだまだスタートアップ。数年後には事業規模、
会社規模を倍増させたいと考えています。
その際、あなたには会社の中核メンバーとして、一緒に会社を引っ張っていただきたいのです。

[962 デフォルトの名無しさん 2025/06/23(月) 18:22:32.34 ID:uX2oVrQ8]

人売りの奴隷集め

[963 デフォルトの名無しさん 2025/06/23(月) 21:09:50.86 ID:0odK9WS3]

Z世代の皆様にしっかり稼いで頂きたいという思いから、高収入案件をご紹介させていただいております。

[964 デフォルトの名無しさん 2025/06/24(火) 22:23:36.74 ID:KcGBlJeb]

Rustへ移行のためのドキュメント「C++ to Rust Phrasebook」発表
https://techfeed.io/entries/683ccb678fc2c0556f0d68d0

C++でおなじみのイディオムや設計パターンを、Rust流にどのように書き換えるかを体系的に示したリファレンスである。
各章は具体的なコード例と、それに伴う設計上のトレードオフについての解説で構成される。
「C++ならこう書くがRustでは？」と行き詰まった場面で索引的に参照する使い方も想定されている。

[965 デフォルトの名無しさん 2025/06/25(水) 23:33:16.67 ID:zC2X3VO4]

>>964
「C++ to Rust Phrasebook」
https://cel.cs.brown.edu/crp/

[966 デフォルトの名無しさん 2025/06/26(木) 23:30:50.97 ID:IZtnbrew]

https://facet.rs/

[967 デフォルトの名無しさん 2025/06/27(金) 22:34:08.47 ID:9/4Hvrnc]

所有権を返すfoo()で&foo()をそのまま使える時と
エラーとなるためlet tmp = foo(); してから&tmpを使わされる時と
temporary lifetime extensionルールが関係しているの？

[968 デフォルトの名無しさん 2025/06/27(金) 23:03:36.64 ID:1LWAsQhh]

>>967
おそらくそうだけどコード見ないことには何とも

[969 デフォルトの名無しさん 2025/06/28(土) 00:59:51.80 ID:CvmYv9Uy]

躁鬱が激しいな

[970 デフォルトの名無しさん 2025/06/28(土) 13:45:14.63 ID:YWzO1cVn]

つるつるわれめ

[971 デフォルトの名無しさん 2025/06/28(土) 21:59:50.08 ID:cIKPEg+8]

RPITでもTAITでもないimpl Traitは何と呼ばれているの？

[972 デフォルトの名無しさん 2025/06/29(日) 02:06:59.79 ID:9bVKBGV1]

Announcing Rust 1.88.0
https://blog.rust-lang.org/2025/06/26/Rust-1.88.0/

[973 デフォルトの名無しさん 2025/06/29(日) 02:41:16.16 ID:712DhJe3]

>>964-965
boost使いまくってたら

[974 デフォルトの名無しさん 2025/06/29(日) 02:43:51.09 ID:712DhJe3]

わろす
https://uchan.hateblo.jp/entry/2018/08/24/234334

[975 デフォルトの名無しさん 2025/06/29(日) 03:42:04.63 ID:FAAHlPSo]

まだ中３女子がいた時代か…

[976 デフォルトの名無しさん 2025/06/29(日) 23:21:46.38 ID:kcK1wtsO]

>>972
便利になったなー

if let Channel::Stable(v) = release_info()
　&& let Semver { major, minor, .. } = v
　&& major == 1
　&& minor == 88
{
　println!("`let_chains` was stabilized in this version");
}

[977 デフォルトの名無しさん 2025/06/30(月) 21:42:35.77 ID:Xr9zaQtP]

if文を分けなくてよくなったんか
letした変数を次の条件で使えるのは便利だな

[978 デフォルトの名無しさん 2025/06/30(月) 23:28:37.87 ID:Ewx8aV4S]

let else でもチェーンできるのかな

[979 デフォルトの名無しさん 2025/07/01(火) 01:45:34.56 ID:RyiUYuGe]

let chainとかtryブロックとか時間かかりすぎで将来が心配

[980 デフォルトの名無しさん 2025/07/01(火) 08:40:30.66 ID:WjfKubzq]

ぶっちゃけクソsyntaxだろw

[981 デフォルトの名無しさん 2025/07/01(火) 08:56:09.16 ID:WFD2epuk]

プログラミングしたことある人ならば
>>976のようなケースがよく出てくることがわかる
この構文がないと多段ifで可読性が落ちる

[982 デフォルトの名無しさん 2025/07/01(火) 13:13:02.59 ID:wS9kOuak]

むしろなんで最初から用意しようとしなかったのか不思議で仕方がない機能

>>976の例は説明用とはいえ中の人がSemverをChannelで包むのはいただけない

[983 デフォルトの名無しさん 2025/07/01(火) 23:18:30.26 ID:fT6MdngX]

>>976
最近まともな進化がなかったが、久しぶりにいい変更点が来た感じする

[984 デフォルトの名無しさん 2025/07/02(水) 08:10:37.08 ID:h5Fr+SaE]

ガイジプログラマーだけど質問あるガイジ？
ガイジガイジガイジ死んだ方が良いガイジ地頭悪いガイジ
死ぬガイジ虚言だから死なないガイジガチで死んだ方が良いガイジ

[985 デフォルトの名無しさん 2025/07/02(水) 08:12:19.09 ID:h5Fr+SaE]

後輩が気を使って僕に席を譲ってくれたガイジ…死んだ方が良いガイジ…死にたいガイジ…

[986 デフォルトの名無しさん 2025/07/02(水) 14:18:35.20 ID:jzgTyLq2]

>>976
if文の途中でパターンマッチングできてlet等で変数宣言できるようなプログラミング言語は他にありますか？

[987 デフォルトの名無しさん 2025/07/02(水) 15:55:37.03 ID:J+FNqJjG]

>>984
ガイジガイジよいしょよいしょ

[988 デフォルトの名無しさん 2025/07/02(水) 18:49:24.09 ID:NOqRQoPr]

>>986
いくらでもあるだろｗ
なんでそれをRustスレで聞くんだよ
複…、バカなの？

[989 デフォルトの名無しさん 2025/07/02(水) 21:26:49.42 ID:Oh5RPAnK]

>>986
LISP 系や ML 系だと出来るのが多いと思う

[990 デフォルトの名無しさん 2025/07/02(水) 21:52:14.46 ID:oQJmxzOP]

>>986
今回の>>976のようなif条件内で連鎖できる言語はないが単純なものならある

[991 デフォルトの名無しさん 2025/07/02(水) 21:56:06.59 ID:VJuqxJR/]

C#でもisで出来るでしょ？もちろん&&でつなげられる

[992 デフォルトの名無しさん 2025/07/02(水) 22:41:30.16 ID:z9oJfvdC]

みなさんおわかりだろうか
>>976
↓
>>986
↓
>>990

[993 デフォルトの名無しさん 2025/07/02(水) 22:47:53.08 ID:upgcwtw3]

C#はようやくリストのパターンマッチングができるようになったところ

[994 デフォルトの名無しさん 2025/07/02(水) 23:40:48.12 ID:+kkKLbZ1]

>>982
仕様を定めるため慎重に議論されてきた
糖衣構文が定められたが既存のdrop順序と合わないと判明した
今年からのRust 2024 editionで新たに定めることで解決してこのたび導入された

[995 デフォルトの名無しさん 2025/07/03(木) 00:15:02.16 ID:Wcs1wXTl]

>>992
本人以外全員分かってると思う

そして…

[996 デフォルトの名無しさん 2025/07/03(木) 11:05:56.13 ID:FLjzPh5e]

時は動きだす

[997 デフォルトの名無しさん 2025/07/03(木) 11:33:08.05 ID:dZ3pJe+2]

シンタックスシュガーだから中途半端なんだよな

[998 デフォルトの名無しさん 2025/07/03(木) 16:19:31.79 ID:44NH8ILk]

パターンマッチングはユニフィケーションにまで発展しないかね。

[999 デフォルトの名無しさん 2025/07/03(木) 19:28:59.84 ID:OMTYLr6T]

>>986
Perl最強だぞ

[1000 デフォルトの名無しさん 2025/07/03(木) 19:58:10.70 ID:080rUSul]

おわり