Rust part30at TECH
Rust part30 - 暇つぶし2ch353:デフォルトの名無しさん
25/06/01 23:15:24.99 7HYVfiGT.net
Rustは安心安全
※ただしありえない使い方をしない時にかぎる

354:デフォルトの名無しさん
25/06/01 23:45:33.58 sQgPtell.net
ありえおじ

355:デフォルトの名無しさん
25/06/01 23:46:59.52 0CmIhd20.net
>>350
ありえない使い方をしても問題ないことをRust叩きしてる人が証明してくれた

356:デフォルトの名無しさん
25/06/02 00:05:41.71 fXikgHg9.net
ミニマム再現条件にすると滑稽ですが
好みの位置にウィンドウを持って来るのは普通の事なので(デスクトップ)
ありえない使い方と言うよりも、windowsでネイティブ日本人がテストしてないのか?品質に出ていますね

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

357:デフォルトの名無しさん
25/06/02 00:06:41.28 fXikgHg9.net
>>348
確認できたのはそのパターンです、自分は常用してないので他のバグ発生条件までは分かりませんね
(念のためPowerToysを落としても状況は同じだった)

Dioxus TodoM


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



359:デフォルトの名無しさん
25/06/02 00:07:15.73 fXikgHg9.net
>>332,335
ターミナルで日本語入力する事自体が稀なのでAlacrittyには70点あげても良いですが
Dioxusは「そっと閉じ」の方ですね

360:デフォルトの名無しさん
25/06/02 00:09:31.08 9UmaDGug.net
>>355
じゃあ、Dioxusでターミナル作ったら?

361:デフォルトの名無しさん
25/06/02 00:11:29.28 fXikgHg9.net
>>344
納得しましたw

362:デフォルトの名無しさん
25/06/02 00:13:19.40 fXikgHg9.net
>>355
Readmeみたらそっと閉じ

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

363:デフォルトの名無しさん
25/06/02 00:18:26.39 Z4CT4v88.net
Windowsを使う人は滅多にいないだろうしな
普通はLinuxかMac

364:デフォルトの名無しさん
25/06/02 00:33:24.53 FhxrXIqd.net
人間の頭から放電した場合は下記の経路になる
人間は電磁界【脳波8Hz~40Hz】【電線【60Hz】の電圧と同じ】なので周囲に影響を与えれる範囲が狭い

人体への雷撃パターン |身を守る| 雷の知識
URLリンク(www.franklinjapan.jp)
超低周波電磁界にばく露した人体に起きる電磁的現象
URLリンク(www.jeic-emf.jp)

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

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

365:デフォルトの名無しさん
25/06/02 01:35:42.19 d/cxZYnc.net
>>321
何を言ってるんだか。

366:デフォルトの名無しさん
25/06/02 02:03:54.92 wOJOfP6S.net
Windowsのtauriは余計なことしないでwebview2に丸投げすればIMEは普通に動きそうな気がするんだけど
クロスプラットフォームの抽象化があるから単純ではないのかな

367:デフォルトの名無しさん
25/06/02 07:27:24.42 GgLxuemZ.net
>>359
GUIアプリってプログラマでなく一般ユーザーに使ってもらうために作るものじゃないの?
シェア率が70%もあるWindowsを「滅多に使わない」?

368:デフォルトの名無しさん
25/06/02 08:02:49.76 zmXNsHtd.net
どちらかというとIME切り替えながらウィンドウ動かす、というのがないかな…
数年間毎日使って気付かなかったし正直どうでもいい
直してくれるならそれに越したことはないけども

369:デフォルトの名無しさん
25/06/02 08:51:42.98 h4tRZExf.net
いや、ウィンドウズはほぼ毎日使うよ
会社でも同じだわ

370:デフォルトの名無しさん
25/06/02 10:49:02.15 XWrf3Dm6.net
IDEなら編集しながらコンパイルしてるから不愉快な挙動をするのは火を見るより明らか

371:デフォルトの名無しさん
25/06/02 11:11:49.92 NteO/GBi.net
>>293
Rustに限らずZigとかC#とか、extern cできる言語ならなんでもAndroidで使えるよ
Androidのjniやndkに全部C互換があるから

372:デフォルトの名無しさん
25/06/02 11:15:54.47 aX5lnsqr.net
出来るけど公式にサポートしているもののほうが楽ではある。

373:デフォルトの名無しさん
25/06/02 12:21:45.02 yqv+vYMm.net
Amazon Aurora DSQLは当初はJavaVM上のKotlinで開発されたものの、バグの混入を避けるためなどの理由でメモリ安全なRust言語での開発に切り替えたところ、それだけで性能が約10倍向上したとも説明されています。
URLリンク(www.publickey1.jp)

374:デフォルトの名無しさん
25/06/02 12:27:33.61 XWrf3Dm6.net
オールド公式とニュー公式どっちを選ぶかは結局自分で判断するしかない

375:デフォルトの名無しさん
25/06/02 13:03:04.42 cfmG04/d.net
再現方法を見てウィンドウ動かさなければ問題ないだろうと考える人は経験が浅すぎるわな
そういう感覚で物作ってると行き着くところは「複オジ品質基準」だぞ

376:デフォルトの名無しさん
25/06/02 13:17:30.01 aX5lnsqr.net
わかった上で重大ではない (から放置で良い) と判断することはあるだろうけど……
そういう小さなことが積み重なってよくわからん挙動を引き起こすこともそれなりにある話。

377:デフォルトの名無しさん
25/06/02 14:20:48.94 w8zlJvU9.net
>>369
困るとそれを貼り付けるね

378:デフォルトの名無しさん
25/06/02 14:21:05.82 czhP5p30.net
>>369
やはりサーバー分野はRustが最強だな

379:デフォルトの名無しさん
25/06/02 14:21:43.53 czhP5p30.net
>>373
どゆこと?

380:デフォルトの名無しさん
25/06/02 14:31:27.48 czhP5p30.net
373がなにを否定したいのかよく分からないがRustの並列処理は非常に効率がよい
Rustで再開発することによりこの恩恵を受けて大幅に性能が向上した
今回AWSが正式リリースしたAurora DSQLは並列処理に重きをおいたものだから特に高い効果を得られたのだろう

381:デフォルトの名無しさん
25/06/02 14:41:07.84 XWrf3Dm6.net
カオスは初期値だけで引き起こせるんだよね
途中の小さな積み重ねは原因ではなく結果

382:デフォルトの名無しさん
25/06/02 14:49:11.87 z+CFOxG+.net
KotlinというかJavaの並行処理はむっちゃ安全だけどその代わりにパフォーマンスが犠牲になってる。
C++のはパフォーマンスが良いけどみんなご存知のように安全性がゴミ。
Goのはパフォーマンスも安全性もいいからRustかGoのどちらを使うかでRustが選ばれたんでしょ知らんけど。

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

Just make it scale: An Aurora DSQL story
URLリンク(www.allthingsdistributed.com)

384:デフォルトの名無しさん
25/06/02 15:31:24.30 AD6qUyw7.net
そんでこれはオープンソースなのか?

385:デフォルトの名無しさん
25/06/02 15:53:39.10 z+CFOxG+.net
CLI部分はオープンソースだよ

386:デフォルトの名無しさん
25/06/02 15:55:37.90 3XGAbOaK.net
本体をオープンソースにしろよw

387:デフォルトの名無しさん
25/06/02 15:58:30.64 bKFtipAC.net
>>378
単に会社の方針としてJavaかKotlinかC/C++かRustで、Goは選択肢にないんだろう
379の元記事読んだけど技術選定の際に社内実績をかなり重視してそうだし、そもそも制約がなきゃKotlinなんか選ばないでしょ

388:デフォルトの名無しさん
25/06/02 15:59:31.58 WAnrQ9FR.net
>>378
Goは同じくガベージコレクションのある言語だから厳しい

389:デフォルトの名無しさん
25/06/02 16:03:48.59 z+CFOxG+.net
やはり敵はガベコレにあり。

390:デフォルトの名無しさん
25/06/02 16:06:35.67 qTYmSia5.net
敵はオープンソース資産を食い逃げする企業だろ

391:デフォルトの名無しさん
25/06/02 16:28:08.28 owUgTJXK.net
>>384
GoのGCはJVMと比較すると低遅延だから、記事の通りGCによる停止が問題になっている状況なら選択肢になりうる

392:デフォルトの名無しさん
25/06/02 16:40:40.26 k0FlxjxP.net
>>387
GCによる害悪2つのうちレイテンシ悪化はGoで軽減できるが全体パフォーマンスはGoも悪化する

393:デフォルトの名無しさん
25/06/02 16:43:17.43 /ossn2s1.net
悲報!Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
URLリンク(www.memorysafety.org)

Macではもっと遅かったしRustじゃなくてGoで良い領域だな

394:デフォルトの名無しさん
25/06/02 16:49:07.25 /ossn2s1.net
>>236 >>243
Arc削除できないと返答してるな

395:デフォルトの名無しさん
25/06/02 16:52:44.19 Ca4PuVUf.net
シャープ、PythonによるAIデバイス向け高位合成ツールをオープンソースで公開
URLリンク(news.mynavi.jp)

博報堂メディカル、生成AIを用いた審査業務効率化ソリューションを開発 [
URLリンク(news.mynavi.jp)

「AIをより魅力的にする戦略」がAIチャットボットに「薬物使用を促す」といった有害な考えを強化させる可能性があると研究で判明
URLリンク(gigazine.net)

396:デフォルトの名無しさん
25/06/02 16:54:15.56 64YfA+90.net
Arcは所有者を増やすときのみカウンタ+1のオーバーヘッドがある
参照はderefによりコストゼロ

397:デフォルトの名無しさん
25/06/02 17:21:42.21 fJbPstNP.net
>>390
なるほど
幸先良くスタートしたけど分かっていても直せない箇所が出て来る訳ね

398:デフォルトの名無しさん
25/06/02 17:27:52.34 64YfA+90.net
所有者を増やしまくる愚を犯さない限りArcにデメリットはない

399:デフォルトの名無しさん
25/06/02 17:49:16.64 iSmTN9kp.net
>>379
Aurora DSQLは、データベース管理ソフト(DBMS)であり、データを収めているのは原則としてHDDやSSD。
だから、メインメモリーは、キャッシュのために少し使う、というのが基本のはず。
だから、データ集約に関係する高度なアルゴリズムはHDD/SSDに対して必要となるが、
メインメモリに対しては余り必要ない。だから、Rustが適す。

400:デフォルトの名無しさん
25/06/02 17:52:38.64 F42JmYRi.net
>>395
もうちょっと調べた方が良いよ、DB全般

401:デフォルトの名無しさん
25/06/02 17:59:35.62 iSmTN9kp.net
>>396
ちゃんとした言葉で反論してください。

402:デフォルトの名無しさん
25/06/02 18:02:50.08 owUgTJXK.net
>>397
Geminiに聞いてやったぞ

ご指摘のコメントは、データベースの仕組みとRustに関する理解に多くの誤解があるようです。
* DBのメインメモリ利用の認識違い: データベースはキャッシュだけでなく、データ処理やソート、インデックスなど、パフォーマンスのためにメインメモリを広範に活用します。「少し使う」というのは誤りです。
* Rust適用の理由が不適切: Rustはメモリを安全かつ効率的に制御できるため、DBのようなパフォーマンスが求められるシステム開発には適しますが、「メインメモリをあまり必要としないから」という理由は論理が破綻しています。
したがって、このコメントは技術的に見て多くの点で適切ではありません。

403:デフォルトの名無しさん
25/06/02 18:04:48.37 iSmTN9kp.net
>>398
DBMSの場合、メインメモリーに置いておく集約構造は、データの量が小さい。
だから、ある程度の速度性能が出れば、全体の速度には影響が及びにくい。

404:デフォルトの名無しさん
25/06/02 18:05:34.76 iSmTN9kp.net
そのGeminiの回答は、理解が浅い。

405:デフォルトの名無しさん
25/06/02 18:06:28.04 owUgTJXK.net
>>399
お相手の方の返信も、やはりデータベースのメモリ利用とパフォーマンスに関する誤解が続いていますね。
主な問題点
* 集約構造のデータ量は「小さい」は誤り: データベースは、高速化のために可能な限り多くの集約データや中間結果をメモリに置こうとします。データ量が多いほど、メモリを効率的に使う必要があります。
* 「ある程度の速度」で全体の速度に影響が出にくいは誤り: メモリ上の処理が非効率だと、それが全体のパフォーマンスのボトルネックになり、特に大規模データや高負荷環境では深刻な影響が出ます。少しの遅延でも、積み重なると大きな差になります。
データベースの性能は、メモリの効率的な活用に大きく依存します。

書き込む前にAIにチェックしてもらうことをお勧めする

406:デフォルトの名無しさん
25/06/02 18:08:30.83 iSmTN9kp.net
>>401
ただ、ネットで使うことが多い DBMSは、単位時間当たりの書き込み回数が小さい傾向がある。
そういう事まで含めて考えれば、あなたやGeminiの回答は理解が浅い。

407:デフォルトの名無しさん
25/06/02 18:11:00.40 iSmTN9kp.net
論理ではなく、トータルの必要時間を数式で考えないといけない。

408:デフォルトの名無しさん
25/06/02 18:13:55.93 64YfA+90.net
>>399
一番効果が大きいのはメモリ上のキャッシュ効果
そのキャッシュ構造管理もRustがベスト選択

409:デフォルトの名無しさん
25/06/02 18:16:26.41 iSmTN9kp.net
>>404
DBMSに必要な処理の特徴が、Rustとは相性がいいとは言えるかもしれないが、
DBMS以外のアプリではもっと別の特徴が必要となることが有る。

410:デフォルトの名無しさん
25/06/02 18:25:01.24 iSmTN9kp.net
>>404
「405」で「キャッシュ」という言葉を使ったが、CPUの中のキャッシュの事ではなく、
メインメモリー自体が HDD/SSDに対するキャッシュとみなせるという意味で使った。
混乱してはいけない。

411:デフォルトの名無しさん
25/06/02 18:32:11.04 iSmTN9kp.net
>>406
誤: 405
正: 395

412:デフォルトの名無しさん
25/06/02 18:40:12.36 KbudeIgC.net
次からスレタイ「複おじ Part31」に変えようぜ

413:デフォルトの名無しさん
25/06/02 18:42:37.74 64YfA+90.net
>>406
DBはそのHDD/SDDに対するキャッシュ効果が最も効く
そのキャッシュ管理にもRustが最適

414:デフォルトの名無しさん
25/06/02 18:44:18.26 iSmTN9kp.net
>>409
もちろん、KotlinやJavaよりは効くだろう。

415:デフォルトの名無しさん
25/06/02 18:50:00.32 uLOpbVD1.net
>>408
別にそれでもいいよw
普通にRustスレ立ててもおかしな人間がやって来て自説を繰り返すだけだから

416:デフォルトの名無しさん
25/06/02 19:31:43.37 a238vP89.net
それやっても自分でRustスレ立てて何事もなかったかのように振る舞うだけだと思う

417:デフォルトの名無しさん
25/06/02 20:32:38.85 ddfioDeu.net
>>389
GCがあり不便なGoは適用範囲がほとんどないのよ
Goが使われている領域の狭さを見つめてね

418:デフォルトの名無しさん
25/06/02 20:44:46.47 +aIkiiO4.net
将来的にオリジナルのdav1dと乖離させない様に出来るだけ1to1で移行するには良いのでは
TypeScriptコンパイラと同じ状況かと

419:デフォルトの名無しさん
25/06/02 20:51:40.32 +aIkiiO4.net
書いてあるね
URLリンク(github.com)
> 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

420:デフォルトの名無しさん
25/06/02 20:54:08.00 +aIkiiO4.net
Macの現状は7%差か
もう「significant」じゃない気がする

> Apple M3で8.8%遅かったのが7%になったとな
> 「5%遅い」はAMD Ryzenでの数字

421:デフォルトの名無しさん
25/06/02 20:56:39.33 OnNK0eHp.net
小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
するとしても回避策はある。
そんなことより Go の問題点はメモリ管理を自動化しておきながらメモリアクセス違反をあまり防げないことだな。
C/C++ から移行する分にはそんなもんだろと思えるが、メモリ安全性を期待したら失望すると思う。

422:デフォルトの名無しさん
25/06/02 21:00:04.05 +aIkiiO4.net
どの道テストはみっちり必要ですよ
コンパイル時のあの標語は罠かと

423:デフォルトの名無しさん
25/06/02 21:06:48.63 3VeAkVql.net
Goは各種安全性対策が中途半端でプログラマの自己責任だからな
Goに未来はない

424:デフォルトの名無しさん
25/06/02 21:18:44.47 3Ri7GR+v.net
>>396
禿同だな
>>395というか複おじはド素人なのになんで無理に変なコメントしようとするんだ?

425:デフォルトの名無しさん
25/06/02 21:28:48.01 uzsj2Y7F.net
>>417
>小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
真逆だろ

426:デフォルトの名無しさん
25/06/02 21:28:51.61 XWrf3Dm6.net
キリトリ記事禁止の呪いか
思いつたことはすべて公表しなければならないという

427:デフォルトの名無しさん
25/06/02 21:40:20.45 OnNK0eHp.net
>>421
確保しようとするメモリが大きくても小さくても一回あたりの確保・解放に必要な実行コストはあまり差がない。
大きさではなく回数が効いてくるので頻繁な確保・解放がないなら GC のコストは小さいよ。
画像処理関係は大きなデータは扱うがメモリを確保・解放する回数が大きいわけではない。

428:デフォルトの名無しさん
25/06/02 21:43:30.36 nIRomA7P.net
>>423
C/C++/Rustが絶対に勝つ利用法だ

429:デフォルトの名無しさん
25/06/02 21:48:51.08 GgLxuemZ.net
>>413
Dockerとか使ったことないの?

430:デフォルトの名無しさん
25/06/02 21:56:07.57 OnNK0eHp.net
Go の GC もヒープメモリの確保と解放のコスト自体は C と同程度じゃないかな。
生存しているか (参照が残っているか) どうかの判定にコストがかかっているので依存関係の複雑なデータ構造だと速度的には不利になる。
どうせそのあたりを意識しながら設計するなら Go より Rust のほうがいいかなぁとは思う。

431:デフォルトの名無しさん
25/06/02 22:01:25.40 OnNK0eHp.net
逆にもう手に負えないほど複雑なデータ構造になってしまったときは GC の実行コストを受け入れてでも任せてしまいたいということはあるかもね。

432:デフォルトの名無しさん
25/06/02 22:01:47.11 bKFtipAC.net
>>426
GC自体は軽い処理で、それ自体のコストが問題になることは少ない
問題は、現在主流のGCの実装では、予測困難なタイミングでGCによる比較的長時間のアプリケーションの停止が生じること
そもそも明示的なdeleteやRAIIや参照カウントのような方法も決してゼロコストではないわけで、そのコストを払うタイミングが違うんだよ

433:デフォルトの名無しさん
25/06/02 22:03:46.27 J5nAKj7S.net
>>425
Docker創始者が明言「WASM+WASIがあればDockerは不要」
URLリンク(twitter.com)
(deleted an unsolicited ad)

434:デフォルトの名無しさん
25/06/02 22:26:19.81 GjabKUPP.net
なお>>429 tweetから丸6年後の今

435:デフォルトの名無しさん
25/06/02 22:28:58.46 UNbfduAo.net
>>428
1行目から2行目で世界線が違うのか?

436:デフォルトの名無しさん
25/06/02 22:33:31.23 bKFtipAC.net
>>431
あなた以外には理解いただけているものと思うが、念のため補足すると、
GCの問題は処理コストの大きさではなく、そのコストを払うタイミングにある

437:デフォルトの名無しさん
25/06/02 22:44:13.11 ur17A/w2.net
>>432
要するにこれが良いと言う事か

> もうすぐGCが進化するからフリーランチ出来るね
> URLリンク(qiita.com)
> URLリンク(github.com)

新計測データが来てる

438:デフォルトの名無しさん
25/06/02 22:45:31.08 MPKk5iPb.net
>>432
GCはどの方式でも処理コストが高い
これがGC依存言語が遅い原因

439:デフォルトの名無しさん
25/06/02 22:48:22.30 MPKk5iPb.net
GCするなら一斉停止が最も低コスト
並行しながらGCは時間の分散ができる代わりにコストの増大を招く

440:デフォルトの名無しさん
25/06/02 22:59:32.23 ur17A/w2.net
Satori GC (No Gen0)は良さそうだから、さっさとGodotで試したデータを上げたら良いのに

441:デフォルトの名無しさん
25/06/02 23:06:29.24 ur17A/w2.net
godot使いが言っている最大レイテンシーが~5ms程度が実際に達成されるのか見て見たい

442:デフォルトの名無しさん
25/06/02 23:16:57.64 9HexqnhX.net
現実を無視して自己満足

443:デフォルトの名無しさん
25/06/02 23:35:07.57 e80Lnwqt.net
5msが本当ならゲームチェンジャー

>>434
GC言語が楽なのは分かるから
逆にGC憎くしだな

444:デフォルトの名無しさん
25/06/02 23:41:42.00 MPKk5iPb.net
>>439
GCを用いる以上はGCのコストを無くす方法はない
必ずペナルティが生じる

445:デフォルトの名無しさん
25/06/02 23:43:45.20 e80Lnwqt.net
>>440
そこはクライアント側CPUはあまっているから大丈夫

ゲームだとGPU律速
DB/IOがあればそれで律速

446:デフォルトの名無しさん
25/06/02 23:50:27.08 e80Lnwqt.net
というかJVMが取り入れたら世界線レベル
DSQLで1秒想定だったのが200分の1

447:デフォルトの名無しさん
25/06/02 23:52:03.77 w80jJ2EG.net
GCはメモリ消費量の問題もあるため論外
何をするにも不利

448:デフォルトの名無しさん
25/06/02 23:57:57.40 ab+RrVue.net
>>439
無学だな
GCコストを下げる魔法は存在しない

449:デフォルトの名無しさん
25/06/03 00:01:16.56 7WxgzsHE.net
>>420
Geminiの方が優秀だね

450:デフォルトの名無しさん
25/06/03 00:06:53.82 7WxgzsHE.net
見せて欲しい>>444氏の学とやらを

451:デフォルトの名無しさん
25/06/03 01:21:41.32 WkxEnd7y.net
node.jsでサーバー構築してるけどRustにしたほうがええんかなあ

452:デフォルトの名無しさん
25/06/03 09:39:37.51 xhVN3bhy.net
Rustの利点が活きるAPIサーバなら普通にいいんじゃないか
フロントもある普通のWebアプリケーションだったら辞めたほうがいいと思うが

453:デフォルトの名無しさん
25/06/03 10:20:07.21 cgHky4oh.net
もし移行コストに見合った効果が出るのであれば相当にトラフィックの多いサーバーだろうから、
なんとなくの雰囲気や好みじゃなくて論理的に判断すべきだろう
たぶんそうではないんだろうけど、その場合モチベーションは無益な徒労を続ける上で無視できない重要な要素だから、Rustを採用することでモチベーションが上がるならやればいいんじゃないか

454:デフォルトの名無しさん
25/06/03 10:46:12.79 97yIcMrS.net
>>423
arena使わないとRustがGC言語に速度で負けるのはどういう場合かな?
大昔ならいざ知らず現代のGCが問題になるのはそんな単純なケースじゃないよ

455:デフォルトの名無しさん
25/06/03 11:29:40.94 g1P4UzEL.net
>>450
arenaを使っていないRustプログラムがほとんど
もちろんGC言語より速い

456:デフォルトの名無しさん
25/06/03 12:38:00.30 SsEYb5J+.net
GC言語は速さと省メモリで勝ち目は一切ないため他の理由がある時のみ用いる

457:デフォルトの名無しさん
25/06/03 12:47:09.85 rqu5SnLS.net
>>449
構築コストはRustもNode.jsも覚えた人には同じ
省メモリと捌けるクライアント数はRustが圧倒的

458:デフォルトの名無しさん
25/06/03 13:01:58.34 Kt5mEPBd.net
>>453
クライアント数が増えたらサーバーの数を増やせばいいだけだ
一般に、Node.jsのエンジニアよりもRustのエンジニアの単価の方が平均的には高いから、
Rust採用による人件費の増加とサーバーのコスト低減効果のどちらが優位か?という金の問題に帰着する
先のAurora DSQLの例では明らかに後者が優位だが、>>447含め大多数のプロダクトでは状況は異なる
いやそうではない、Rustエンジニアの単価は安い、例えば俺のように、と主張するのなら話は別だかな

459:デフォルトの名無しさん
25/06/03 13:04:22.23 rqu5SnLS.net
>>454
Rustが使える人にとってそんなこと関係ない
Rustで書けばサーバ数も激減できる

460:デフォルトの名無しさん
25/06/03 13:09:50.21 /7yVoUF5.net
>>455
Rustはコーダーに好き勝手させないためのマネジメント向け言語だよ。

unsafeの扱いは問題あるけど、そのうちコーティング規約でライブラリアン以外はunsafe使えなくするケースが増えるんじゃないんかね。

461:デフォルトの名無しさん
25/06/03 13:19:44.29 VYRLmXgA.net
>>456
無知がデタラメ書くのは止めなさい
Webサーバー構築でunsafeなんて出て来ない

462:デフォルトの名無しさん
25/06/03 13:42:18.60 /7yVoUF5.net
>>457
「コーダーがunsafeを使わない」と「コーダーはunsafeを使えない」は別物。
マネジメントサイドはコーダーを信用しないから、禁止できるなら禁止するだろ。

463:デフォルトの名無しさん
25/06/03 13:57:30.31 VYRLmXgA.net
>>458
ほとんどの分野でunsafeは使われない
unsafeを使うなら関係者の合意形成が必須レベル

464:デフォルトの名無しさん
25/06/03 14:14:20.21 xhVN3bhy.net
unsafeって、必要もないのにやったところで何かが書きやすくなるような性質のものではないと思うが
C言語上がりだとおまじないみたいに全部unsafeして生ポインタ操作とか平気でやるのか?

465:デフォルトの名無しさん
25/06/03 14:29:03.14 idwVU/iA.net
後知恵で、やっぱ必要かなと思ったらやる
unsafeを使わなかった敗者がunsafeで復活するかもしれない

466:デフォルトの名無しさん
25/06/03 14:43:50.09 VYRLmXgA.net
熟練者になるまでunsafeの存在を忘れろ
初心者がunsafeを必要と思うのは無知と勘違いだ

467:デフォルトの名無しさん
25/06/03 17:45:47.84 ZZq2n2YO.net
IT土方にunsafeを使わせるな

468:デフォルトの名無しさん
25/06/03 17:51:28.94 +aVViU0f.net
FFIやるとunsafeはすぐ出てくる
webとは関係ないが

469:デフォルトの名無しさん
25/06/03 18:09:13.25 FQzY7vd6.net
unsafe禁止とか言ってないで真面目にレビューしろ

470:デフォルトの名無しさん
25/06/03 19:07:45.18 idwVU/iA.net
処刑されないこともあるが裁判にかけられる

471:デフォルトの名無しさん
25/06/03 20:15:54.93 E3wqr71x.net
>>464
FFIでも整備されていてunsafe不要な分野も多いね
未整備なら素人は手を出さない方が

472:デフォルトの名無しさん
25/06/03 20:26:02.65 /7yVoUF5.net
ほとんどの分野で使われないなら、なおさらunsafe禁止すべき。

膝を撃ち抜く自由を無くしたのがRustの利点なのだから、unsafeを使えないSafeRustのみのコーダーモードを用意すべきかと。
#![forbid(unsafe_code)]とかがデフォルトにならんかね。

473:デフォルトの名無しさん
25/06/03 20:50:43.22 idwVU/iA.net
正確な判断はunsafeが使われた後でしかできないよ
後で訂正や追加されるようなルールは守りたくないと思ってる者ほど事前にルールを確定しようとする

474:デフォルトの名無しさん
25/06/03 20:56:07.12 RCZNeyZK.net
そう
ソースを確かめず、アプリやサービスで判断する場合
今の Rust は SafeRust との明示がない限り
デフォルトは unsafe Rust だと言う事

475:デフォルトの名無しさん
25/06/03 21:05:31.59 E3wqr71x.net
safe = Rustコンパイラが安全性を保証する
unsafe = 他の言語と同じくプログラマ自己責任

476:デフォルトの名無しさん
25/06/03 21:09:34.02 gJYjdNIy.net
Cコードを呼び出すときはunsafeを�


477:gわざるを得ないけどな



478:デフォルトの名無しさん
25/06/03 21:19:12.46 KTSdNflr.net
> Cコードを呼び出すときはunsafeを使わざるを得ないけどな

△ Cコードを呼び出すとき
○ dll関数を呼び出すとき (その関数がRustで書かれていても)

ABI策定はどうなっているのか

479:デフォルトの名無しさん
25/06/03 21:33:34.20 NXfOWsak.net
いつの間にか serde_yaml のリポジトリがアーカイブされてる…

480:デフォルトの名無しさん
25/06/03 21:59:05.52 Ygo17qEp.net
>>474
URLリンク(doc.serdeyml.com)

481:デフォルトの名無しさん
25/06/03 22:11:40.12 Y8fW8uWd.net
>>475
0.0.12

Build Status FAILING

482:デフォルトの名無しさん
25/06/03 22:19:03.78 WkxEnd7y.net
Node.jsのNestJS使ってる
使いやすくてすばらしい
Rustでもこういうフレームワーク使いたい

483:デフォルトの名無しさん
25/06/03 22:42:41.40 5VWOQt07.net
>>473
Rust ABIはUndefined

484:デフォルトの名無しさん
25/06/03 22:50:13.08 /5P14uNg.net
>>474
Rustの�


485:宴Cブラリモデルの宿命だな



486:デフォルトの名無しさん
25/06/03 23:00:49.81 wy1dGgl0.net
>>474
これunsafe使いまくり
なのに今後何があっても直さないのか

487:デフォルトの名無しさん
25/06/03 23:24:47.93 ovxpNXrv.net
>>474
serde-yamlの管理人はsyn/proc-macro2やthiserror/anyhowなど幅広くやってるdtolnayだね

488:デフォルトの名無しさん
25/06/03 23:28:35.41 bSuEbnBN.net
それらも用心が必要という事態か?

489:デフォルトの名無しさん
25/06/03 23:29:41.66 bSuEbnBN.net
>>479
こんなに簡単にはしご外されるモデルなんだね

490:デフォルトの名無しさん
25/06/03 23:30:11.84 vFCBrwxa.net
yamlの仕様は闇が深いので関わらない方がいい

491:デフォルトの名無しさん
25/06/03 23:39:58.59 wc70ijSk.net
>>481
C++⇔Rust FFIのcxxも

492:デフォルトの名無しさん
25/06/03 23:47:22.51 C8xHrNgY.net
MS/editが外部crate依存が少ないのは納得した

493:デフォルトの名無しさん
25/06/03 23:49:19.18 j/0hkWys.net
>>486
それは不利だよ
自分で何もかもメンテしないといけない

494:デフォルトの名無しさん
25/06/03 23:50:49.03 C8xHrNgY.net
>>487
事実になっとくしただけだぞ

495:デフォルトの名無しさん
25/06/03 23:56:35.38 C8xHrNgY.net
前スレのバグのFixがリリースされてた
URLリンク(github.com)

他にもcrashするバグがあったのか
Pressing Alt followed by a non-English keyboard key will not crash Edit anymore (#244)

496:デフォルトの名無しさん
25/06/04 00:09:54.76 pcxtiJDU.net
>>480
unsafe依存なserde-yamlではなく
safeなyaml-rust2が今は主流

497:デフォルトの名無しさん
25/06/04 00:18:09.37 qT5RunOJ.net
やっぱシリアライズ形式はjsonだな

498:デフォルトの名無しさん
25/06/04 00:50:17.21 rKXA09I4.net
メンテがいなくなり
移行先もなく
自分で手を入れる必要で
ようやくローカルフォーク

499:デフォルトの名無しさん
25/06/04 00:52:07.22 rKXA09I4.net
逆に最初から全てを自分で持つのはメンテが辛いだけで不利

500:デフォルトの名無しさん
25/06/04 01:06:11.88 P1CiPc1i.net
GUIライブラリの話もそうだけどこうやっていろんなライブラリを調べたりアップデートに対応したりするコストがRustはバカ高いんだよね

メンテナンスが急に止まったりしない安心して使える鉄板ライブラリの塊が増えないとバカ高いコストを支払ってもお釣りが来るCloudfrare級のところ以外からは見放さされる

501:デフォルトの名無しさん
25/06/04 01:15:23.81 ekCnNhZO.net
メンテ必要なければ止まっていても何も困らない
必要になってから次策を考えればいい

502:デフォルトの名無しさん
25/06/04 02:00:11.13 NPEulGl+.net
>>494
鉄板ライブラリが充実してる言語は何おすすめ?

503:デフォルトの名無しさん
25/06/04 06:07:28.58 efmS46GF.net
>>496
どうせ論外論法なんだろ

504:デフォルトの名無しさん
25/06/04 08:00:19.73 k0G95ru9.net
Javaがエンタープライズで世界取ったのは、どこでも動くではなく
充実の標準&企業主体のデファクトスタンダードライブラリの存在によるところが大きいとは思う

505:デフォルトの名無しさん
25/06/04 08:14:31.76 G6dCwUPn.net
それを言っても卵が先か雛が先かになるから仕方がない
Javaがエンタープライズで勝った大きな根本要因の一つは、UNIXサーバーをターゲットとした開発をWindows上で問題なく行えるから
その意味では、どこでも動くからというのは極めて重要な性質

506:デフォルトの名無しさん
25/06/04 08:30:07.30 uvY60KW1.net
外のパッケージに依存すれば脆弱性も共有することになるし、サプライチェーン攻撃のリスク


507:もある crateのようなパッケージマネージャというのは完全に性善説で成り立っていて、 潜在的にはそこらのフリーソフトなんかより遥かに危険なのだが、 それを騒ぎ立てて経営層に問題として認識させることはエンジニアの間ではタブーとなっている



508:デフォルトの名無しさん
25/06/04 09:18:54.95 6ElB2UK6.net
Rustで使われてたjemallocが開発終了してしまった件

509:デフォルトの名無しさん
25/06/04 09:21:52.15 YYmNTYsA.net
広い意味では自動化に人気がないだけだな
手動のほうが良いというのがタブーになる

510:デフォルトの名無しさん
25/06/04 09:37:55.19 qT5RunOJ.net
AWS社員はもっとRustライブラリの保守に尽力しろ

511:デフォルトの名無しさん
25/06/04 09:38:26.06 XvRleYyH.net
>>501
終わってない。
facebook の管轄下に移動した。
URLリンク(github.com)

512:デフォルトの名無しさん
25/06/04 10:03:06.02 YYmNTYsA.net
「どこでも動く」の究極の形は計算機がなくてもできるカードゲームや将棋みたいなやつだ

513:デフォルトの名無しさん
25/06/04 13:04:56.35 k6hN7zFM.net
>>474
「アーカイブ」という言葉の意味は、メンテナンスしなくなったから、
書庫の様な場所に保管して開発を終える、という意味?

514:デフォルトの名無しさん
25/06/04 13:26:32.91 uvY60KW1.net
>>506
GitHubにおけるアーカイブは、開発終了したリポジトリを凍結する機能
引き続き読取は可能だが書込みは不可になる

515:デフォルトの名無しさん
25/06/04 14:18:22.24 l+TAz4MO.net
アーカイブされたのは2024年3月
serde_yamlを使いたい人は今後もそのまま使えて使われてる

516:デフォルトの名無しさん
25/06/04 14:20:34.09 l+TAz4MO.net
ただしserde_yamlはCから移植のunsafe_ libyamlが下請け
safeなyaml_rust2をベースがいいだろうね

517:デフォルトの名無しさん
25/06/04 16:14:01.87 YYmNTYsA.net
機械化(機械に責任転嫁)できないという点だけを見れば自己責任は禁忌だが

518:デフォルトの名無しさん
25/06/04 16:49:49.89 k6hN7zFM.net
Rust推進者って、Linuxもそうだったが、自分は変わらず
世界の方を変えようとしているから、ウザイ。
自分が(社会的地位が)上であることは絶対的にゆるぎないと思ってる気がするよ。

519:デフォルトの名無しさん
25/06/04 16:51:13.65 k6hN7zFM.net
むしろ、今までずっとそのようにしてきたことが社会を歪めておかしなことになって来た
事には気づいてない。

520:デフォルトの名無しさん
25/06/04 16:52:55.60 k6hN7zFM.net
C#も押し付けがましかったが、それがRustに変わろうとしているらしい。
その前はJavaだった。Kotlinもそうされそうになったが衰退したらしいが。

521:デフォルトの名無しさん
25/06/04 16:57:13.44 k6hN7zFM.net
中国人もそうなんだよ。民主主義で困ってないのに、民主主義や自由は
幻想だ。『日本や台湾は「幻想のバブルの中に」入る。
これからの時代は共産主義だ。だから、台湾の体制を中共に譲らなければ
ならない。それが人類にとって幸せだ。世界に赤い旗を立てる事が
人類の未来のためになるんだ』
などと言っている。Rustもそれに非常に似ている。

522:デフォルトの名無しさん
25/06/04 17:02:22.14 k6hN7zFM.net
「xxxはRustに書き直して高速になった。バグが減った」
って、EVや空飛ぶ車に対するChinaのプロパガンダにそっくり。

523:デフォルトの名無しさん
25/06/04 17:03:31.51 k6hN7zFM.net
イーロンマスクも南アメリカで17歳まで育ち、カナダから北米に渡り、
恥知らずにも中国で金儲けをし、Rustを宣伝している。

524:デフォルトの名無しさん
25/06/04 17:03:32.52 k6hN7zFM.net
イーロンマスクも南アメリカで17歳まで育ち、カナダから北米に渡り、
恥知らずにも中国で金儲けをし、Rustを宣伝している。

525:デフォルトの名無しさん
25/06/04 17:05:35.70 k6hN7zFM.net
南アメリカ-->南アフリカ

526:デフォルトの名無しさん
25/06/04 17:17:57.01 BCt/MqyZ.net
複オジの謎自演が湧いたから軌道修正

>>509
その理屈でこうなる

Cから移植の rav1d も意味ない

527:デフォルトの名無しさん
25/06/04 17:20:13.73 LMOj5Orj.net
イーロン・マスク、X表示名を「Gorklon Rust」に変更
URLリンク(jp.beincrypto.com)

528:デフォルトの名無しさん
25/06/04 17:24:03.91 k6hN7zFM.net
アホみたいだな。

529:デフォルトの名無しさん
25/06/04 17:24:04.89 k6hN7zFM.net
アホみたいだな。

530:デフォルトの名無しさん
25/06/04 17:24:12.07 LMOj5Orj.net
イーロン・マスクがRust製の次世代型メッセージングサービスXChatを発表
URLリンク(coinpost.jp)

531:デフォルトの名無しさん
25/06/04 17:58:41.63 vVWK76SG.net
>>501,504
Facebook/Metaは前々からforkしていて今現在 2 commits behind
Archiveの経緯やMetaが引き継いだ?メッセージが見つからない

532:デフォルトの名無しさん
25/06/04 18:32:54.69 LMOj5Orj.net
Rustで構築されたXChatは暗号化、消えるメッセージ、ファイル送信、音声・ビデオ通話の機能が含まれる

533:デフォルトの名無しさん
25/06/04 20:03:53.00 Ao4InlGx.net
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/

534:デフォルトの名無しさん
25/06/04 20:37:21.11 bNQu7sc4.net
>>501
jemallocは終了していない
URLリンク(crates.io)
毎日10万downloads

535:デフォルトの名無しさん
25/06/04 21:30:49.14 /YHraRZZ.net
ただのwrapper >>527

536:デフォルトの名無しさん
25/06/04 21:43:23.61 oPHHrTh9.net
上で話題になってた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出すの面倒だから放置するけど
現実問題として困ってたら参考にしてくれ

537:デフォルトの名無しさん
25/06/04 22:02:27.60 QHp7QW/E.net
>>519
同じCから移植でも
他言語からも使うためunsafeなC API維持と
Rustからのみでsafe可の違いが大きいでしょう

538:デフォルトの名無しさん
25/06/04 22:04:51.79 kc+wDMWW.net
>>529
この場だけでも直った事にしたいのかも知れんが

tauriで徹底的に動作確認してないという事は
業務アプリ類は言わずもがな、自作ツールさも作ってないという事になった

539:デフォルトの名無しさん
25/06/04 22:23:54.98 Y1VDH1cW.net
The Linux 6.15 kernel arrives - and it's big a victory for Rust fans!
URLリンク(www.zdnet.com)

540:デフォルトの名無しさん
25/06/04 22:39:19.54 1H7IBoRl.net
jemallocはトラブルの匂いがするな
serde-yamlと違って開発終了ってことはないから様子見だね

541:デフォルトの名無しさん
25/06/04 22:50:25.36 9UK4z5dz.net
jemallocは最新版が3年前でその前は6年前
C製だから穴発見があると危機だが

542:デフォルトの名無しさん
25/06/04 23:10:20.18 oPHHrTh9.net
>>531
興味本位で調べただけだよ
OSSだから多少の不具合は自分で調べて対応できる
tauriはまだ本格的に使ってないけど期待はしてる

543:デフォルトの名無しさん
25/06/04 23:13:27.02 DFQUCkBF.net
>WM_ENTERSIZEMOVEでMoveFocus呼んでる理由が分からんし

× OSSだから多少の不具合は自分で調べて対応できる
○ 迂闊にいじるとリグレッション

544:デフォルトの名無しさん
25/06/04 23:17:32.86 0rTSW7kB.net
>>523
次世代ツイッターもRust製なのか

545:デフォルトの名無しさん
25/06/04 23:19:17.30 xluCwGJp.net
>>535
自分で調べて

理由が分からん

調べてないのでは

546:デフォルトの名無しさん
25/06/04 23:26:53.32 YYmNTYsA.net
一部でアセンブラを使っていてもCで書いたとかRustで書いたとか自称しやがるから
アセンブラとCとRustはもう区別する必要ないのでは

547:デフォルトの名無しさん
25/06/04 23:33:17.12 oPHHrTh9.net
>>538
取っ掛かりとして必要な範囲は調べてるだろ
0-100思考の方?

548:デフォルトの名無しさん
25/06/04 23:36:30.76 a0td9I7l.net
>>540
という事でこれじゃあ未対応だな>>529

549:デフォルトの名無しさん
25/06/04 23:38:36.41 dxJlV5oD.net
イーロンマスクまでRust派になるとは驚いた

550:デフォルトの名無しさん
25/06/04 23:51:21.99 oPHHrTh9.net
>>541
「という事で」の意味が分からんけど対応されたら何か困るらしい
WM_ENTERSIZEMOVE消すだけだと破壊的だからfork限定でPRは出せんけどね

551:デフォルトの名無しさん
25/06/04 23:54:26.85 c3QvVbDl.net
>>542
マスクは経営サイドなんだから当然だろ。
自分でコードを書いているのならともかく。

552:デフォルトの名無しさん
25/06/04 23:57:54.43 0ZM3gFza.net
>>543
>WM_ENTERSIZEMOVE消すだけだと破壊的だから

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

553:デフォルトの名無しさん
25/06/04 23:59:22.16 VnO22Btn.net
各社どこでも新しいシステムはRustで作る時代になったね

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

555:デフォルトの名無しさん
25/06/05 05:52:19.18 9oMXEf1f.net
>>543,547
気が向いたら再現手順に落とし込むけど
>>529を適用したら見栄えが悪い状態が発生した
URLリンク(i.imgur.com)
URLリンク(i.imgur.com)

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

556:デフォルトの名無しさん
25/06/05 08:11:45.26 xg3puRce.net
IT土方用の言語としては最適だよな

557:デフォルトの名無しさん
25/06/05 08:57:28.49 /1HPheJz.net
Rustは無能判別機だからね
unsafe無しでコンパイルできる時点で価値のある人間だと分かる

558:デフォルトの名無しさん
25/06/05 09:21:04.56 6CqsT1b+.net
> 当初はJavaVM上のKotlinで開発されたものの、バグの混入を避けるためなどの理由でメモリ安全なRust言語での開発に切り替えたところ、それだけで性能が約10倍向上した
URLリンク(www.publickey1.jp)

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

559:デフォルトの名無しさん
25/06/05 12:34:43.00 h7HwLZOZ.net
「無能判別器」とかRust信者らしい物言いだよなぁ。
Linuxの時もそうだった。Linuxの良さが分からないのは無能だとか、馬鹿だとか、
そんなんばっかだった。

560:デフォルトの名無しさん
25/06/05 12:36:14.00 h7HwLZOZ.net
OSSが理解できないのは「古い」とかなんとか。
でもそう言ってる人の年齢は60歳超えてるとか。そんなことが多かった。

561:デフォルトの名無しさん
25/06/05 12:41:30.48 ivO6rPSc.net
>>551
Kotlinも結局GC言語だから限界があり遅いのは仕方ないかと

562:デフォルトの名無しさん
25/06/05 12:50:06.51 0IjP0LtT.net
>>551
新人のひよっこコードに負けるなんて屈辱だっただろうな

563:デフォルトの名無しさん
25/06/05 12:53:34.45 e7PyAJ/v.net
>>551
そういう真面目に改善に取り組んでいる企業や分野では全てRustへ置き換えられていくのだろうね

564:デフォルトの名無しさん
25/06/05 16:05:58.05 O/7ObmiI.net
Rust化が進むと聞くだけで不安感や不快感を感じる人も居るぞ。

565:デフォルトの名無しさん
25/06/05 16:31:04.08 si4Xw2Nw.net
Rustは安心感と速さの両立にプログラミングのしやすさが快適

566:デフォルトの名無しさん
25/06/05 16:51:58.44 VtwpHPUL.net
Rust化が進んだことと数値化が進んでいないことのギャップが不快なんじゃないか
良いことや悪いことをした瞬間にただちに報酬や罰が与えられることはない
時間差がある

567:デフォルトの名無しさん
25/06/05 18:39:37.18 O/7ObmiI.net
>>559
そもそも日本企業は「社会主義的」だから、何をやっても報酬は変わらず、
どんなに良い事をやっても給料が上がることはない。
あなたが何をしたかではなく、最終的に商品が売れればボーナスが僅かに上がる。

568:デフォルトの名無しさん
25/06/05 18:56:11.37 TVBzAcEZ.net
RustってWEBアプリのバックエンドでも使われることあるの?

569:デフォルトの名無しさん
25/06/05 19:09:12.79 zMAzVPRE.net
>>561
そこは他の言語と比べて最もRustが適している分野

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

571:デフォルトの名無しさん
25/06/05 20:21:52.92 P5XWUA/E.net
Rustを使えない人は高いリソースコストを負担
Rustを学んで使えば有利になる

572:デフォルトの名無しさん
25/06/05 22:08:00.36 YvayYtMq.net
別にそれだけならC++でもいいわけだが。

573:デフォルトの名無しさん
25/06/05 22:24:45.12 xITjGZKh.net
俺は一番得意なPetlで書くことが昔より減ってきた
お前らも同じような感じなの

574:デフォルトの名無しさん
25/06/05 22:30:17.30 DF0+msFz.net
>>565
残念ながらC++は大量の非同期タスクをマルチコアで回す基盤やその上のWeb処理など不便すぎて無理

575:デフォルトの名無しさん
25/06/05 23:49:02.97 F2pC0JZC.net
それらの基盤ライブラリが整っていて使いやすくクライアントを大量に捌けるRustが一番有利だね

576:デフォルトの名無しさん
25/06/06 09:25:11.44 XJlMjWKR.net
>>566
Petlであってる? Perl の事かな?

577:デフォルトの名無しさん
25/06/06 10:12:05.28 XJlMjWKR.net
>>567
それは言語ではなくライブラリで解決できそうだね。

578:デフォルトの名無しさん
25/06/06 11:26:05.53 Dh3sPLTt.net
リソースコストよりRustエンジニアを集める人件費の方が高くつく

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

579:デフォルトの名無しさん
25/06/06 12:05:30.99 tmoIxOYF.net
Rustで一番コストがかかるのはライブラリ周りなんだって

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

580:デフォルトの名無しさん
25/06/06 12:12:17.09 tmoIxOYF.net
外部ライブラリを考慮しなければ生産性は大きくても2〜3倍の悪化で済むからJVM言語のように常にヒープアロケーションする言語と比べれば処理内容によっては10倍くらいの性能差は普通に出るのでペイできると勘違いしやすい

581:デフォルトの名無しさん
25/06/06 12:14:48.45 A1tr0fpa.net
>>570
C++はそのライブラリが弱い
Rustで開発されるようになった理由はライブラリが充実しているため

582:デフォルトの名無しさん
25/06/06 12:16:57.67 hpIL6JTz.net
充実は違うな
C/C++の方が圧倒的に充実しているが、せっかくあってもそれを利用するのが難しい
Rustが流行った大きな要因はビルドやパッケージマネージャがcargoで統一されてること

583:デフォルトの名無しさん
25/06/06 12:19:54.83 A1tr0fpa.net
>>575
C/C++は大量の非同期タスクをマルチコアで回したりその上のWeb処理などまともなライブラリ群がない

584:デフォルトの名無しさん
25/06/06 12:20:50.82 hpIL6JTz.net
>>576
ある
でも知らないだろ?そこがRustとの大きな違い

585:デフォルトの名無しさん
25/06/06 12:22:41.80 A1tr0fpa.net
>>577
C/C++はまともなものがない
Rustは充実していて使いやすい
この差が決定的となった

586:デフォルトの名無しさん
25/06/06 12:27:00.11 1NKDBcTf.net
Web開発でRust笑

587:デフォルトの名無しさん
25/06/06 13:06:50.86 XmGFqaCQ.net
>>579
Rustは昔からWeb分野が最大コミュニティ
URLリンク(image.itmedia.co.jp)

588:デフォルトの名無しさん
25/06/06 14:29:45.68 C6RQeHrZ.net
むしろ Rust はウェブ以外の分野での躍進が思ったほどではないと解釈すべきなのかもしれない。

589:デフォルトの名無しさん
25/06/06 16:32:47.31 ju0XC4LS.net
>>574
>大量の非同期タスクをマルチコアで回す
シングルスレッドで書いたほうが楽だし、C++は速いのでそれで十分なことの方が多いから。

590:デフォルトの名無しさん
25/06/06 17:14:08.28 W6y55ttb.net
>>582
無知アホすぎてこのスレ出入り禁止

591:デフォルトの名無しさん
25/06/06 17:23:29.23 ju0XC4LS.net
Rustは現実的じゃないって事だな。

592:デフォルトの名無しさん
25/06/06 17:25:16.55 Gse28VZ2.net
C++なりPythonなりを一通りやったあと、
不満があってRustを始めた奴が多いから
他言語ニワカはすぐバレるんよな

593:デフォルトの名無しさん
25/06/06 17:42:57.80 J0042m2U.net
>>582
それは大昔の方法
今はRustやGoのように非同期タスクをCPUスレッド個数分の上で最大限効率的に回す

594:デフォルトの名無しさん
25/06/06 17:43:30.86 C6RQeHrZ.net
C++ も Python も必要なものはある。
けど楽にやれるかっていうとそうでもないところがしんどい。

595:デフォルトの名無しさん
25/06/06 17:54:58.69 ju0XC4LS.net
>>586
C++でも出来るようになっているが。

596:デフォルトの名無しさん
25/06/06 18:00:07.40 ju0XC4LS.net
>>586
特殊な処理以外はシングルスレッドで十分だし、逆にシングルスレッドで高速で
無ければGUIのレスポンスは遅くなる。

597:デフォルトの名無しさん
25/06/06 18:17:12.71 J0042m2U.net
>>588
C++にはRustやGoのような非同期タスクM:Nスケジューラがない
その上の各種ライブラリもない

598:デフォルトの名無しさん
25/06/06 18:23:14.91 J0042m2U.net
>>589
CPUのマルチスレッド数を活かせないのは今どき論外だよ
Webのサーバもブラウザも

599:デフォルトの名無しさん
25/06/06 18:24:57.87 ju0XC4LS.net
>>590
もし本当に無いなら作ればいい。そんなに難しいわけじゃないはずだ。

600:デフォルトの名無しさん
25/06/06 18:29:44.35 ju0XC4LS.net
>>591
プログラムの下手さをコア数の多さで誤魔化している例が多そうだが。

601:デフォルトの名無しさん
25/06/06 18:38:16.48 VxoAIN/b.net
C++はモダンな非同期に出遅れた
使い勝手も悪いまま他の言語と比較にならん

602:デフォルトの名無しさん
25/06/06 18:40:29.68 ju0XC4LS.net
>>594
非同期こそがJavaScriptが嫌われる理由であるといわれているが。

603:デフォルトの名無しさん
25/06/06 18:42:10.43 VxoAIN/b.net
>>592
各階層を非同期でライブラリ作り上げて普及させないと誰も使ってくれない

604:デフォルトの名無しさん
25/06/06 18:44:07.97 VxoAIN/b.net
>>595
Rust含めて主要言語すべてモダンな非同期に対応して利便性とパフォを両立させている

605:デフォルトの名無しさん
25/06/06 18:45:34.80 ju0XC4LS.net
>>597
>利便性とパフォを両立させている
ダウト

606:デフォルトの名無しさん
25/06/06 18:50:46.27 7glNIZb/.net
一部のOSがシングルタスクだった時代に
throwとcatchの方がexitよりも便利そうだとか、そもそもunix系ならexitで問題ないと
言われたんだろうな
現在はLinuxの良さが多少分かりにくくなった
C++の意味も分かりにくい

607:デフォルトの名無しさん
25/06/06 18:51:47.14 jK2Njv63.net
>>598
AWSやCloudflareなどもRustの非同期プラットフォームtokioの上に構築しているよ

608:デフォルトの名無しさん
25/06/06 18:52:44.07 ju0XC4LS.net
>>600
ほら、また、データセンターだ。バックエンドだ。

609:デフォルトの名無しさん
25/06/06 18:52:58.14 NfW6LToZ.net
C++の並行プログラミングはfuture(async-await)よりもアクターモデルが主流だね
Rustでも最高のスループットを追求するならアクターが有利だけど、Web上がりには取っ付きにくいから安易にfutureが選ばれがち

610:デフォルトの名無しさん
25/06/06 18:53:26.81 jK2Njv63.net
>>599
C++は時代遅れで不要だけど
今もLinuxの上にRustで構築されてるよ

611:デフォルトの名無しさん
25/06/06 18:57:09.31 jK2Njv63.net
>>602
C++で高性能が作れるものなら作ったら?
各社の新システムはRust futureモデルを採用しているから

612:デフォルトの名無しさん
25/06/06 19:08:08.67 +jg06n/J.net
Actixはアクターモデルだよ。複おじが知ってるわけないか

613:デフォルトの名無しさん
25/06/06 19:15:06.63 kCiJWJGk.net
ActixはRustのfutureの上に作られている
この分野はFuture/Promiseモデルが勝利した

614:デフォルトの名無しさん
25/06/06 19:21:48.66 ju0XC4LS.net
みんなよく見とけ。Rustは、他でもなくこういうようなニーズにぴったりな言語だという事だよ。

615:デフォルトの名無しさん
25/06/06 20:23:58.53 2KEuAQPx.net
実際みんな何がC++を捨てるきっかけだったん?
俺はMSVCのモジュール対応がいつまでたっても微妙なこと

616:デフォルトの名無しさん
25/06/06 20:31:21.71 bR69FDxG.net
actixとaxumで迷ってる
現時点のパフォーマンスならactixだとは思うんだけど
axumが追い上げてるよね

617:デフォルトの名無しさん
25/06/06 20:39:58.07 C6RQeHrZ.net
>>608
捨ててない。
選択肢が増えた。

618:デフォルトの名無しさん
25/06/06 21:10:39.44 h83wGeBI.net
>>609
設計の中身見ればactix一択。よく作り込んである

619:デフォルトの名無しさん
25/06/06 21:24:25.01 7glNIZb/.net
#[no_mangle]
pub extern "C" fn call_from_c() {}

620:デフォルトの名無しさん
25/06/06 22:47:40.65 r+7IJaB+.net
無料で配り出してからVisualStudioの評判が下がったかもしれない。
無料で配ると価値が分かってない人が入ってきてしまうことで、
顧客の忠誠心が下がったりクレームが多くなったり、ブランド低下に繋がると言われている。

621:デフォルトの名無しさん
25/06/06 22:50:14.29 r+7IJaB+.net
商品は高い価格をつけていると、よく吟味してから購入されるので
納得して買ったユーザーが多いため、クレームも少ない。
逆に安くしてしまうと、ニーズに合ってないのに買う人が現れるため、
文句ばっかり言うようになってしまう。それがC++に対しての現状の
評判低下に繋がったのかも。
になっているのかも知れない。

622:デフォルトの名無しさん
25/06/06 23:24:56.88 r+7IJaB+.net
VisualStudioは、C++とC#を分けて買うことが出来ないことも C++の人気低下に繋がったのだろう。
C#を目的でVSをインストールした人は、C++を試しに使っても悪い印象しか持たないだろう。
そもそも顧客ターゲットが違うのだから。その結果、C++の悪い評判が広まってしまったのではないか。

623:デフォルトの名無しさん
25/06/06 23:28:33.90 bR69FDxG.net
>>611
もちろんそうなんだけど
axumの方が今後伸びそうな気がしてるんよ
githubのstarももうすぐ並ぶ
仕様からして採用しやすいと思う
仮に今後パフォーマンスで並んだら完全にシェア奪われると思う

624:デフォルトの名無しさん
25/06/06 23:31:26.54 rGFHsXat.net
同感

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

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

626:デフォルトの名無しさん
25/06/06 23:40:14.11 3JEvODeg.net
ここはRust専用スレだよ

627:デフォルトの名無しさん
25/06/06 23:43:40.46 2KEuAQPx.net
actixって、1回作者がタダ働きしないことに誹謗中傷や罵倒を繰り返す乞食連中にブチギレてクローズしちゃったよね
今は平気な体制なのかな?

628:デフォルトの名無しさん
25/06/06 23:53:57.13 QDWb4oK8.net
>>616
多少性能を犠牲にしても安心感をとる => axum
多少安心感を犠牲にしても性能をとる => actix-web

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

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

629:デフォルトの名無しさん
25/06/06 23:57:17.71 E71NqYZh.net
axumは本流の安心感が大きいね

630:デフォルトの名無しさん
25/06/07 05:06:43.11 fIXrFGqI.net
C++のムーブとRustのムーブは根本的に異なる
C++では失敗しemplace_backなどが別途必要となった

631:デフォルトの名無しさん
25/06/07 07:57:16.81 D5LAHAi0.net
早くRustで仕事できる優秀な人で溢れて、単価安い世界になって欲しい。そうすれば楽ができるはず。

632:デフォルトの名無しさん
25/06/07 09:22:57.46 CnK/EgX1.net
AI以下の人材は要らなくなるけどな
コーディングはAIの領域になっていくから

633:デフォルトの名無しさん
25/06/07 09:42:27.95 evsGciRN.net
n=1よりも邪悪なのはn=0
統計学者にはそれが分からんのです

634:デフォルトの名無しさん
25/06/07 11:15:27.05 BgBV5HNm.net
AIファーストでいうと、Rustは素材が少ないからただの補完でもパッとしないし
本当にAI時代になると膨大な学習資産があるCのほうが優れた言語として扱われそう
脆弱性は人間より優れているAIならそもそも踏まないし

635:デフォルトの名無しさん
25/06/07 11:32:51.12 4dOcWkyN.net
>>627 ディープラーニングは大量の学習元データを必要とするけれどある程度を越えると性能の伸びは急激に鈍化する。 つまり際限なく多くのデータを投入すれば良いというわけではないし、学習データとして使うには充分な分量はあるよ。



637:デフォルトの名無しさん
25/06/07 11:49:58.62 rtfJQBOq.net
プログラミング言語ってのは機械にも読めるようにした人間が読み書きするための言語
書く部分を代理してもらったところで人間が読まなきゃいけないことには変わりない

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

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

638:デフォルトの名無しさん
25/06/07 12:45:57.58 xi57kquP.net
>>627
Cの言語仕様ではAIがどんなに賢くても静的に安全性を保証できないよ
AIに吐かせるならRust

639:デフォルトの名無しさん
25/06/07 12:50:15.19 xi57kquP.net
>>629
現存する言語でデータ競合まで安全を保証して抽象的で可読性のいいRustが使われるね

640:デフォルトの名無しさん
25/06/07 13:01:57.88 bjSjMKW4.net
>>629
とはいうものの、プログラミング言語が�


641:ゥ然言語で書かれるようなことにはならず 検証のために何らかの論理的整合性を保った記法で書かれる必要があるし それを読んで理解できるセンスを持った人はある程度は限られるので プログラミング言語の読みやすさという点では、あまり現状と変わることはないんじゃないかな 人間の方が進化すれば別だけど ただ、Rustが保証するメモリ管理については、AIが後から適切な箇所に解放処理を挿入してくれるようになって、 GCを使っていないがGC言語のようにコードを書けるようになる、ということはあるかもしれない



642:デフォルトの名無しさん
25/06/07 13:11:57.59 xi57kquP.net
>>632
最後のその仕組みがRustだよ
AIですら静的に解決できる情報が必須でそれがRust

643:デフォルトの名無しさん
25/06/07 13:26:22.04 hQgu9D5P.net
それは明らかに誤り
現に極めて高い精度で適切なタイミングでリソースを解放するRustコードをAIは生成できているのだから、
AIが前提であればそのような情報は省略可能であることは自明

644:デフォルトの名無しさん
25/06/07 13:38:44.17 xi57kquP.net
>>634
それは静的に解決できるRustの言語仕様のおかげで様々な安全性が保証される
人間もAIも立場は同じ

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

646:デフォルトの名無しさん
25/06/07 13:58:37.96 xi57kquP.net
>>636
架空の言語?既存の言語?
Rustの肝はその言語仕様にあるから既存の言語には無理だよ

647:デフォルトの名無しさん
25/06/07 15:58:12.17 D5LAHAi0.net
>>633
rustは、メモリ管理を人に強制してるじゃん。>>632の言いたいことは、違うと思うけれどな。

648:デフォルトの名無しさん
25/06/07 16:21:03.28 xi57kquP.net
>>638
その「適切な箇所に解放処理を挿入してくれる」はRustやC++の仕様で実現されてる
他の言語には無理

649:デフォルトの名無しさん
25/06/07 18:36:37.64 evsGciRN.net
言語仕様を既に理解している者にRustは何も強制しない
逆に言えば強制とは理性のない物体を操る技術とか、それを人間にも当てはめるしぐさのこと

650:デフォルトの名無しさん
25/06/07 18:53:43.86 nANhvbt8.net
究極の理想系は Python みたいな軽い言語で雑に書いて、それを AI が最大限効率的なコードに変換するようなものだろうな
ヒープ不要な変数はスタックに、他と共有しないデータは変数のスコープと共に破棄されるように、共有されるデータはArcに、循環参照してるものは寿命の短い方を判断して weakref に、というふうに

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

651:デフォルトの名無しさん
25/06/07 19:02:14.18 xi57kquP.net
>>641
Rust以外の既存の言語の仕様でそれは不可能

652:デフォルトの名無しさん
25/06/07 19:07:24.49 WTKqP7i+.net
>>641
循環参照が必要なケースはだいたいアリーナでいいんじゃないかな
アリーナのスコープはだいたい人間の意図をそのまま反映するのでAI向きだと思う

653:デフォルトの名無しさん
25/06/07 19:07:29.04 evsGciRN.net
誰でもいいからPythonをRustに変換してもらうのが雑なやり方
AIを指名するのはちょっと細かいことにこだわり過ぎている

654:デフォルトの名無しさん
25/06/07 19:10:35.54 xi57kquP.net
>>641
AIであろうと論理的に無理なことはできない
AIも人間と同様で魔法を使えない

655:デフォルトの名無しさん
25/06/07 20:18:46.50 nANhvbt8.net
単純な構文解析では無理だけど、AIがコードの意味や呼び出し関係なども含めて解析できるようになれば可能性あるんじゃない?
2-3年後にとは思わないけど、5年や10年後ならそういう未来もあって良いように思う
最近のAIの発展は凄まじいし

Rustは良くも悪くも低レベルの事情が見えすぎるんだよな
Option, Result や enum のような型はビジネスロジックの表現に役立つし、他の言語でも欲しい人はいるだろうけど、SendやSyncなんかはちょっと違う
これらはC++経験者にとって嬉しいだけで、多くの人からすれば、そういうものは意識せずに済む方がずっと便利なはず

656:デフォルトの名無しさん
25/06/07 20:22:33.18 nANhvbt8.net
意識することは必要かもしれないけど、そのための面倒くささを減らせるなら、その方がいい的な話

657:デフォルトの名無しさん
25/06/07 20:27:29.58 8xDjgwkI.net
>>646
>これらはC++経験者にとって嬉しいだけで
勝手に妄想すんな。

658:デフォルトの名無しさん
25/06/07 20:32:13.92 xi57kquP.net
>>646
そんな方法ロジックが存在するなら現在AI関係なく実現できる
AIと言えども無理

659:デフォルトの名無しさん
25/06/07 21:03:48.33 nANhvbt8.net
実際面倒でしょ
GCのある言語ではとっくに解決済みの問題だし、パフォーマンスのためという理由さ


660:え無ければ、そんな面倒は無い方がいい 人間が書くコードはビジネスロジックに注力して、最適化などの面倒な部分はAIが頑張る、みたいな未来を夢見ても良くない? 「世界中の初級〜中級プログラマがみんなRustを書ける時代」よりは、「初級〜中級プログラマが書いたコードがRust並みに高パフォーマンスに動く」の方が有り得そうに思う 大手ITとか新進気鋭のスタートアップならともかく、世の中のレベルってそんなに高くないと思うので



661:デフォルトの名無しさん
25/06/07 21:18:42.39 xi57kquP.net
>>650
既存の言語の仕様では不可能
もし手段があるならAI関係なく今すぐ実現させる

662:デフォルトの名無しさん
25/06/07 21:34:29.01 nANhvbt8.net
言語の限界というより、現状のコンパイラが行なっている構文解析という手法の限界じゃないの?
他の言語で書かれたプログラムを (人間が時間をかければ) Rustに移植できる、と言えるなら、それは将来AIにもできる可能性のある仕事だと思う
「理屈上どうやってもC/C++/Rustでは実現できないロジック」とかがあるなら無理だけど、そういうのはおそらく滅多に無いだろうし

663:デフォルトの名無しさん
25/06/07 21:50:46.86 4dOcWkyN.net
現代の方式での AI の能力というのは言語モデルに縛られる。
プログラミング言語間で移植するには仕様をより抽象的な言語 (人間がやるなら自然言語?) で抽出してから再実装という工程を経ることになる。
仕様抽出のときにどの挙動が仕様でどこが仕様ではない (再現しなくてもかまわない) のかはプログラムの字面だけからはわからず、ドメイン知識が要るだろう。

664:デフォルトの名無しさん
25/06/07 22:08:05.95 WTKqP7i+.net
そんな複雑なビジネスドメインでRust採用しちゃうようなタイプのエンジニアとAI、
どっちがドメイン知識があるか、客からヒアリングしたドメイン知識に真面目に向き合えるかな
俺はAIだと思うね

665:デフォルトの名無しさん
25/06/07 22:13:16.92 V3GF7XBg.net
RDBだとSQLを渡せば構文解析という手法を通してるけどオプティマイザが最適と思われる実行プランを作ってくれる
今までは用途の限られたDSLでしかこういうことはできなかったがAIを使うことで汎用プログラミングの広い用途で同じようなことが近い将来にできるようになる可能性が高い

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

666:デフォルトの名無しさん
25/06/07 22:28:32.11 noiqQ3+R.net
>>655
できないことを皮算用せずに
その新言語をさっさと作ればよくね?

667:デフォルトの名無しさん
25/06/07 22:31:19.97 5EbSwuA7.net
>>654
顧客からのヒアリングは担当AIになると言われてるね
あとはAIがRustコード吐いて人類がチェック

668:デフォルトの名無しさん
25/06/07 22:36:04.29 evsGciRN.net
マークアンドスイープも仮想関数も低レベルだった
どっちも要らない可能性に気がついた奴は低レベルの縛りが少ない
そんなこと考えたこともない奴が偉そうにしても意味がない

669:デフォルトの名無しさん
25/06/07 22:46:23.09 x0Lmj2vj.net
>>652
元言語のT型のオブジェクトをArc<Mutex<T>>型にすれば変換できるけど意味ないでしょ

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

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

672:デフォルトの名無しさん
25/06/08 00:08:40.08 T2dNb6GD.net
>>661
そんな制限の仕方ができるのは特殊なものだけ
コードは人間がレビューして責任を持つしかない

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

674:デフォルトの名無しさん
25/06/08 00:59:52.80 FT4pj4FW.net
>>663
それだと極めて特殊な入力が来た時だけ特別な実行をAIに仕込まれて人類が詰むパターン

675:デフォルトの名無しさん
25/06/08 09:07:30.09 xGbxg89a.net
脆弱性をAIに仕込まれる時代がそろそろ現実味を帯びてきたな

676:デフォルトの名無しさん
25/06/08 09:32:59.28 PLM9xjLn.net
突き詰めるとRustはいらない言語ってことになっちゃうな

677:デフォルトの名無しさん
25/06/08 09:58:01.31 LY0YSAF3.net
何もいらなーいー

678:デフォルトの名無しさん
25/06/08 11:19:05.81 SVsPPZLo.net
C++とGCとAIの話しかしていない
誰もRustに興味無いんだろうな

679:デフォルトの名無しさん
25/06/08 11:21:32.51 l86SYNjx.net
>>668
そもそも以前から続く傾向として、Rustの自慢話と、C++を貶す話が多いな。

680:デフォルトの名無しさん
25/06/08 13:04:11.80 wHU1y2Cy.net
レスの半分以上は複オジだからな
残りの半分の半分くらいは数学100点オジ

681:デフォルトの名無しさん
25/06/08 14:35:33.97 Dz6RrxG4.net
>>666
AIに吐かせるコードは速くて省メモリで安全で抽象的に可読性のよいRustしかないでしょ

682:デフォルトの名無しさん
25/06/08 15:20:07.80 +Shzj2Ty.net
Pythonは使われているけど、作ったプログラム自体が商品にはならないみたいだよね。
Rustも同じ道を行ったりなんかして。

683:デフォルトの名無しさん
25/06/08 15:24:49.87 +Shzj2Ty.net
Linuxも似ているんだけど、なぜか分かるかな?
それはオープンソースだからだよ。

684:デフォルトの名無しさん
25/06/08 16:16:30.27 d1+aCZ76.net
>>668
Rustに興味ある層は誰かさんがみんな追い出したからね
残ったのは表面的ないいねとよくないねの噛み合わない応酬だけ

685:デフォルトの名無しさん
25/06/08 16:29:29.68 +Shzj2Ty.net
Rustは、プライドの高い趣味プログラマと、AWSのような超大手
独占企業だけが使う言語になるのではないか。

686:デフォルトの名無しさん
25/06/08 16:41:23.46 EeOpsjtM.net
Rust書けない敗者アンチが居座っていつも負けてる

687:デフォルトの名無しさん
25/06/08 17:01:39.88 RG5MF58/.net
【次号予告】2025年6月18日発売『Software Design 2025年7月号』
Rust大特集
URLリンク(pbs.twimg.com)

688:デフォルトの名無しさん
25/06/08 17:02:33.93 +Shzj2Ty.net
cargoを使ってるだけでも企業秘密が漏れる。

689:デフォルトの名無しさん
25/06/08 17:08:20.00 /WNe1XQ9.net
>>677
入門記事っぽいな
でも買うよw

690:デフォルトの名無しさん
25/06/08 17:08:59.52 xGbxg89a.net
>>677
ええやん

691:デフォルトの名無しさん
25/06/08 17:13:54.67 RauPWj2e.net
>>677
この記事面白そう。ますます使う人増えるだろうな

692:デフォルトの名無しさん
25/06/08 17:15:21.24 PLM9xjLn.net
>>671
でもRustってすげ遅いじゃん

693:デフォルトの名無しさん
25/06/08 17:18:00.36 +Shzj2Ty.net
cargoは、開発過程を盗み見るために仕掛けられた仕組みだ。

694:デフォルトの名無しさん
25/06/08 18:02:26.47 2c7Ydjne.net
4大機能w

695:デフォルトの名無しさん
25/06/08 18:45:25.24 RzO7Dv3B.net
4大機能の中では構造体が最弱か
構造体はラムダ式あたりに置き換えてマクロを袋とじに入れればちょうどいい

696:デフォルトの名無しさん
25/06/08 18:57:00.03 m6lUw4i5.net
>>675
安全とプライドは似ている
激安の米を食べないのはプライドかもしれないし安全のためかもしれない

697:デフォルトの名無しさん
25/06/08 19:40:32.20 +Shzj2Ty.net
>>686
アセンブリ言語でも安定性の高い物を作れる人は作れる。
Rustを選択したから賢いわけではないのに賢いと思っているところが
プライドが高いといっているんだよ。

698:デフォルトの名無しさん
25/06/08 19:58:30.87 m6lUw4i5.net
正しさが暴走するとか賢さが暴走するとか回りくどいんだよ
暴走するな安全運転しろって言えばいいのに

699:デフォルトの名無しさん
25/06/08 20:48:40.11 RG5MF58/.net
>>685
他の言語との差異の4大だから
不要なクラスを排除して構造体で正しいかと

700:デフォルトの名無しさん
25/06/08 21:20:42.43 m6lUw4i5.net
家族以外を排除するために家を建てる

701:デフォルトの名無しさん
25/06/08 23:04:46.55 /WNe1XQ9.net
マクロは複雑なこともできるけど複雑なことには使わない方が良い
それ以前に使わない方が良い

702:デフォルトの名無しさん
25/06/08 23:09:16.64 RG5MF58/.net
>>691
標準ライブラリも各有名クレートもマクロだらけだよ
可読性の向上はよいこと

703:デフォルトの名無しさん
25/06/08 23:32:37.62 /WNe1XQ9.net
あなたのコードは継続的に誰かに使われるのですか?

704:デフォルトの名無しさん
25/06/08 23:40:52.99 nJlppiBy.net
紛らわしいとの声が挙がっていたMicrosoftの新テキストエディター「Edit」、名称変更へ?
URLリンク(forest.watch.impress.co.jp)

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


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch