[過去ﾛｸﾞ]
Rust part30 (1002ﾚｽ)
Rust part30 http://mevius.5ch.net/test/read.cgi/tech/1748392296/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
641: デフォルトの名無しさん [sage] 2025/06/07(土) 18:53:43.86 ID:nANhvbt8 究極の理想系は Python みたいな軽い言語で雑に書いて、それを AI が最大限効率的なコードに変換するようなものだろうな ヒープ不要な変数はスタックに、他と共有しないデータは変数のスコープと共に破棄されるように、共有されるデータはArcに、循環参照してるものは寿命の短い方を判断して weakref に、というふうに 現在はまだ無理だからGCレスが必要な場面にRustを使うけど、 &T や Arc<Mutex<T>> みたいな型はメモリ管理のためでしかないし、AIが自動的にうまく変換してくれるならその方が進化だと思う http://mevius.5ch.net/test/read.cgi/tech/1748392296/641
646: デフォルトの名無しさん [] 2025/06/07(土) 20:18:46.50 ID:nANhvbt8 単純な構文解析では無理だけど、AIがコードの意味や呼び出し関係なども含めて解析できるようになれば可能性あるんじゃない？ 2-3年後にとは思わないけど、5年や10年後ならそういう未来もあって良いように思う 最近のAIの発展は凄まじいし Rustは良くも悪くも低レベルの事情が見えすぎるんだよな Option, Result や enum のような型はビジネスロジックの表現に役立つし、他の言語でも欲しい人はいるだろうけど、SendやSyncなんかはちょっと違う これらはC++経験者にとって嬉しいだけで、多くの人からすれば、そういうものは意識せずに済む方がずっと便利なはず http://mevius.5ch.net/test/read.cgi/tech/1748392296/646
647: デフォルトの名無しさん [sage] 2025/06/07(土) 20:22:33.18 ID:nANhvbt8 意識することは必要かもしれないけど、そのための面倒くささを減らせるなら、その方がいい的な話 http://mevius.5ch.net/test/read.cgi/tech/1748392296/647
650: デフォルトの名無しさん [] 2025/06/07(土) 21:03:48.33 ID:nANhvbt8 実際面倒でしょ GCのある言語ではとっくに解決済みの問題だし、パフォーマンスのためという理由さえ無ければ、そんな面倒は無い方がいい 人間が書くコードはビジネスロジックに注力して、最適化などの面倒な部分はAIが頑張る、みたいな未来を夢見ても良くない？ 「世界中の初級〜中級プログラマがみんなRustを書ける時代」よりは、「初級〜中級プログラマが書いたコードがRust並みに高パフォーマンスに動く」の方が有り得そうに思う 大手ITとか新進気鋭のスタートアップならともかく、世の中のレベルってそんなに高くないと思うので http://mevius.5ch.net/test/read.cgi/tech/1748392296/650
652: デフォルトの名無しさん [] 2025/06/07(土) 21:34:29.01 ID:nANhvbt8 言語の限界というより、現状のコンパイラが行なっている構文解析という手法の限界じゃないの？ 他の言語で書かれたプログラムを (人間が時間をかければ) Rustに移植できる、と言えるなら、それは将来AIにもできる可能性のある仕事だと思う 「理屈上どうやってもC/C++/Rustでは実現できないロジック」とかがあるなら無理だけど、そういうのはおそらく滅多に無いだろうし http://mevius.5ch.net/test/read.cgi/tech/1748392296/652
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.041s