Rust part28

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

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part27
https://mevius.5ch.net/test/read.cgi/tech/1733146370/

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

**デフォルトの名無しさん** · 2025/04/26(土) 17:51:31.23

コード書きなよ。そして考える。読んで考える

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

>>678
これは割と効いてくるので良い方針だと思う。
いまどきは Ruby でも JavaScript でも JIT でかなり高速化してるんだけど、 JIT だと何度も通過する内にだんだんネイティブコードに置き換わっていく仕組みだからガッと動いてすぐ終わるようなコードだとぜんぜん JIT の恩恵がない。
それでいてそこそこ大きいランタイムのロードには時間がかかるからあまり向いてないんだよね。

**デフォルトの名無しさん** · 2025/04/26(土) 18:05:29.29

>>672
そんなもん完成形は目の前にあるんだから、頻繁に大規模な手戻りが発生するようなら設計した奴が無能なだけ
スタートアップなんかでのガチで新規性の高い開発ってのは、そもそも作っているものに価値が無い可能性が高い
そのような性質の開発にRustは適していると思う？
俺自身の意見はともかく、現状その問いにYesと言えるだけの実績がRustに無いのは事実だ

**デフォルトの名無しさん** · 2025/04/26(土) 18:06:58.12

WebブラウザWasm、CDN Edge、クラウドなどもRustが言語筆頭候補の領域

**デフォルトの名無しさん** · 2025/04/26(土) 18:21:45.82

rustから他の言語に書き直すのは大変そう

**デフォルトの名無しさん** · 2025/04/26(土) 18:50:24.41

>>658
RubyのYJITはC言語で書かれていたMJITを単にRustへ移植したのではなくて全く別のアプローチ
YJITを作ったShopifyの研究開発チームがYJITの論文も発表しているよ

>>683
スタートアップが新規に開発でRustなら既に話題になってるPythonのruffやuvも該当するね

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

YJITやuvやruffが新規なのか
別に煽るつもりも否定するつもりもないのだけど、平均的なRust開発者の認識がそうなんだとしたら、Rustは実際にそういう言語なんだろうね

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

276,406行のC++コードを捨ててRustへ移行したスタートアップの技術的決断
https://zenn.dev/rwcolinpeng/articles/14760991836800

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

Cからrustへの書き換えはわりとうまく行きそうだけどC++からだとしんどそう

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

スタートアップでも開発効率の高いRustを採用する方が当然有利ってことだな

**デフォルトの名無しさん** · 2025/04/26(土) 21:18:45.78

試行錯誤ってカーゴカルトを正当化するんだな
滑走路作ってみな
飛ぶぞ

**デフォルトの名無しさん** · 2025/04/26(土) 21:47:38.26

別の視点でスタートアップであろうとなかろうと
競合相手がいて他の条件がほぼ同等ならRustを採用した方がおそらく有利っぽい
速度の面でも使用リソースの面でも

**デフォルトの名無しさん** · 2025/04/26(土) 22:16:38.86

開発者が優秀だからじゃないか
同じ人が開発する時の速度に影響するかなあ

**デフォルトの名無しさん** · 2025/04/26(土) 22:43:45.38

kindle 日替わり500円

**デフォルトの名無しさん** · 2025/04/26(土) 23:08:38.66

Cのままだとライセンス違反になりそうなグレーゾーンをRustで書き換えて解決ってか

**デフォルトの名無しさん** · 2025/04/26(土) 23:13:16.03

言語を書き換えてもライセンス抵触なら無意味
それ以前にいまどき落とし穴の未定義動作だらけにC言語なんて使うのはコンパイラ指定な特殊な組み込み環境くらいだろ

**デフォルトの名無しさん** · 2025/04/26(土) 23:22:10.41

>>689
その通りなんだがC++の機能にどの程度依存してたかだな

**デフォルトの名無しさん** · 2025/04/26(土) 23:40:40.79

>>695
freebsdカーネルは完全にgcc捨ててllvm化が終わってる

**デフォルトの名無しさん** · 2025/04/27(日) 05:42:31.77

>>688
C++エキスパートなら、必要なスキルが揃っているから移行コストが少ない、というのがデカイね。

逆にC++で大規模開発するのにコーティング規約を決めてなかったみたいだから、コーダーが好きにやって破綻している感じもある。
C++標準化委員会は標準的なコーティング規約を決めた方がいいんだろうけど、宗教戦争になりかねないから難しいか。

**デフォルトの名無しさん** · 2025/04/27(日) 06:03:34.96

C++を完全に捨てるしかなかったな

>>688
>>C++ はプログラマーに多くの柔軟性を与えますが、それには代償が伴います。バグを埋め込むのが非常に簡単であり、その多くは非常に厄介です。しかし、それ以上に C++ プログラムのデバッグは非常に困難です。特に並行プログラミングにおいてはなおさらです。

>>依存関係の管理が面倒です。たとえば CMake のように、C++ プロジェクトのコンパイルを自動構成するツールはありますが、開発者は依存ライブラリの構成やインストールを手動で行う必要があります。

>>標準テンプレートライブラリ（STL）は、たとえばネイティブなコルーチンのサポートなど、モダンプログラミングの一部ツールに対応していません。その結果、開発者は多くのコミュニティプロジェクトに依存せざるを得ず、これらの多くは長期的なサポートがありません。

>>品質保証が難しいです。C++ は非常に多機能な言語であるがゆえに、開発者ごとにまったく異なるコーディングスタイルで C++ を書いてしまう傾向があります。異なるバックグラウンドを持つ開発者がチームに増えると、コードの可読性を維持できなくなりました。さらに、C++ コードのバグは簡単には特定できず、コードレビューが非常に困難になる原因でもありました。

**デフォルトの名無しさん** · 2025/04/27(日) 06:08:20.98

>>688
C++エキスパートかどうかは何も痕跡がないな
むしろJava屋さんじゃね(Initial commit)
https://github.com/risingwavelabs/risingwave/tree/cb527ae81e9d9f51010da4b16ad9101447b7670b

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

>>688
こういう極端な例しか出て来ないよね

**デフォルトの名無しさん** · 2025/04/27(日) 06:23:06.49

>>688
今となっては何もかも劣るC++を使うメリット無いからな
ましてやそのような最近のシステムなら非同期並列が必須なのでC++だと茨の道

**デフォルトの名無しさん** · 2025/04/27(日) 07:51:33.32

libuvを使うのじゃ
全くおすすめできない

**デフォルトの名無しさん** · 2025/04/27(日) 07:52:41.59

非同期並列並行が標準装備なんて恵まれた言語ばかりになってグスン

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

設計の見直しがあるとRustは辛いよなぁ
Goのほうが柔軟な気がする

**デフォルトの名無しさん** · 2025/04/27(日) 09:24:24.45

Kotlin もよろしく

**デフォルトの名無しさん** · 2025/04/27(日) 09:26:48.67

Oracle怖いので

**デフォルトの名無しさん** · 2025/04/27(日) 10:46:11.91

> 開発者は多くのコミュニティプロジェクトに依存せざるを得ず、これらの多くは長期的なサポートがありません。

これを理由にしてRustへ行くのはちょっと本末転倒感あるけどなあ
数年後には、古くなったcrateに縛られてモダンでクールな〇〇をイントロデュースするのベリーハードだぜフ〇ックとかブツブツ言ってるだろうな

**デフォルトの名無しさん** · 2025/04/27(日) 10:48:58.05

処理系のサポートは重要だよね
IntelのCコンパイラ使ってるプロジェクトあったな
最適化の都合かもしれんけど

**デフォルトの名無しさん** · 2025/04/27(日) 11:29:27.41

新しいものの方が魅力的に映るのは当然のことだが、当面の最大のリスクはRustより魅力的な言語が出現したときにどうなるか、だな
>>688の例でも必死に言い繕っているように、新しいものを使いたかっただけではなく真の合理的判断の結果であれば問題にならないはずだが、果たして本当にそうだったのかはそのときに明らかになる
Rustがいかに優れていようと、その時はいずれ必ず来るわけだが、Rustエコシステムは未だそれを経験していない

**デフォルトの名無しさん** · 2025/04/27(日) 11:31:45.33

それを言ったら、CもJavaも出だしの頃は散々使えないって言われてたので。自己責任で腹を据えるしか無い

**デフォルトの名無しさん** · 2025/04/27(日) 11:33:37.49

zigは難しいし、まあRustの20年が始まるよ。

**デフォルトの名無しさん** · 2025/04/27(日) 12:18:30.81

RustのようにCと同等の速さを出すことが可能で
Rustよりも安全な言語は当面出現しそうにない
C言語からRust出現まで43年間かかった
そしてC出現から53年たった現在もCも使われているように
50年後もRustは使われているだろう

**デフォルトの名無しさん** · 2025/04/27(日) 12:39:43.81

実現したとしてもRustと同程度の2番煎じじゃ意味ないのよね
Rustでは出来ない問題を解決しなきゃ

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

＞　Rustでは出来ない問題

未知の新言語に誰にでも使える容易さがあればRustは消えることになる

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

50年後かな

**デフォルトの名無しさん** · 2025/04/27(日) 13:55:43.56

>>709
Rustも放置cratesだらけだよな

**デフォルトの名無しさん** · 2025/04/27(日) 14:05:22.78

少なくともC/Rustと同等の速さ省メモリでRustの安全性を満たす言語というのが最低限の条件だから超難関だよな
今のC/Javaの立ち位置と同様に数十年間はRustの時代が続きそうだ

**デフォルトの名無しさん** · 2025/04/27(日) 14:17:14.93

これからの言語でダングリングやメモリリークが容易に解消できるようなAIエディタかAIコンパイラが出てきたら
Rustは安泰なのだろうか？

c++は人間には早すぎたし記述性が悪いけど記述性が良くてメモリを完全に制御可能なAIコンパイラを持つ言語が出てきたらどうなるのかは不明

**デフォルトの名無しさん** · 2025/04/27(日) 14:28:13.70

>>720
そのダングリングやメモリリークが容易に解消できるようにしたコンパイラがRust
その記述性が良くてメモリを完全に制御可能な言語がRust
AIにコードを書かせるならばRustが最も望ましく相性も良い
可読性も良いから人間がチェックしやすくメンテもしやすい

**デフォルトの名無しさん** · 2025/04/27(日) 14:37:02.73

超高水準言語から直接（人間による理解や編集を意図した中間表現を介さないという意味で）実行可能バイナリを生成するAIが、
Rustをパフォーマスや信頼性で凌駕する日はそう遠くないだろうね
パイプラインにおける内部的な中間表現としてRustが採用されることはありうるが、もはや人間にとってはどうでもいいことだ

**デフォルトの名無しさん** · 2025/04/27(日) 14:38:49.51

>>720
そりゃいつか次の覇権言語は出てくるよ。
ずっとというのはあり得ないというのは当然の前提。
でも、やらなきゃいけないことは目の前にあって今ある言語から選定しなきゃしょうがないだろ。

**デフォルトの名無しさん** · 2025/04/27(日) 14:43:44.86

>>722
人類がAIに支配されないためには必ず人類がチェックできる形で運用される
AIに吐かせる最善の言語Rustを読み書きできるかどうかが今後の生き残るプログラマの必須条件となる
AIに遅い言語のコードを吐かせても無意味

**デフォルトの名無しさん** · 2025/04/27(日) 15:00:33.83

AIちゃんに夢観過ぎ
Rustを課題評価し過ぎ

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

当面 (半世紀くらい) のAI は人無しでそこそこの規模のプログラムを自律的に完成させられるほど高度にはならないと予想する。
単純にコストに対して割に合わないから。
人に教育したほうがマシだし、現状の AI 程度でも補助として使えばかなりハードルは下がっている。
AI に必要な電力がかなり大きいことがわかってきて、理論の発展で計算量を抑えられる余地もあまりないのでより発展させるにはより多くのエネルギを投入するしかない。

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

後のAI時代でもそれまでの現在でもRustが最適な点で強いね
速さと使いやすさと安全性で他に代わるものがない

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

>>721
それを人間じゃなくてコンパイラやエディタが自律的に解消できるようになるのが次世代言語だと思う

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

>>728
言語はそのままRustでいいよね
他に候補でもあるの？

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

コンパイラ以前に他人と言葉が通じない人間がいる

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

AIがRustプログラミングの補助やコード生成するわけだろ
Rustより良い言語の候補でもあるの？

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

コードは書くだけじゃなくてコードリーディングする必要がある
現在のrustのままだと結局学習しなくてはならないから一般人には向いてない

**デフォルトの名無しさん** · 2025/04/27(日) 17:02:23.79

>>732
全くの素人まで読めるべきなんてのは無理だろ。
日本人だって A4 一枚程度の日本語で書かれた契約書を読めないのがかなりの割合でいる。

**デフォルトの名無しさん** · 2025/04/27(日) 17:03:14.27

次世代の言語が出るとしたら「AIの支援を多く受けられる」を標榜するものになると思う
けど、「次の言語」はもう出ないのではないかという見方もある
みんながAIを使うようになると、AIが良いコードを生成しやすい言語が選ばれるようになり、現時点でAIが未学習の新言語はますます選ばれないだろうという見方
未来は分からないけど、今後どうなるんだろうな

**デフォルトの名無しさん** · 2025/04/27(日) 17:03:49.55

>>733
javaやjsレベルで良い言語に置き換わると思う
それを避けるためにはrust自体が形を変える必要がある

**デフォルトの名無しさん** · 2025/04/27(日) 17:22:21.32

>>732
可読性と保守性に優れているRustより良い言語があるなら教えて

>>735
呆れた
なぜそんな古くて使いにくいJavaやJavaScriptに戻るんだ？

**デフォルトの名無しさん** · 2025/04/27(日) 17:25:13.85

はいはいrust最強

**デフォルトの名無しさん** · 2025/04/27(日) 17:40:43.10

>>730

**デフォルトの名無しさん** · 2025/04/27(日) 17:45:37.44

ちょっと前に「Rustが嫌いです」ってZennであったけど，Rustの弱点をうまく捉えてたな
このスレで「Rustで書けば理論上バグは混入しない」とか言ってるエアプよりしっかり勉強してるんじゃないかな

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

ロジック的なバグだけになる。ということだから、Cレベルのしょうもないバグを直した人しかその意味は捉えられないと思うよ

**デフォルトの名無しさん** · 2025/04/27(日) 18:19:07.13

>>735
モダンな言語を理解して使いこなせる普通のプログラマーから見るとjavaやjsは悪い言語
javaやjsを良い言語と書いてるあなたはモダンな言語を理解できていない低質なプログラマー
このスレに来る資格すらない老害

**デフォルトの名無しさん** · 2025/04/27(日) 18:19:57.09

>>739
あの人はガベージコレクション前提の言語しか使いこなした経験のない浅いプログラマーだった
そのためあのような見当外れな疑問や不満が生じた
記事にRustの弱点は書かれていない

**デフォルトの名無しさん** · 2025/04/27(日) 18:24:19.35

対話は必要不可欠ではないけどね
特に、被造物ではないものを理解するとき、
作者を特定して作者と対話（ディール）するという方法はナンセンスになる

**デフォルトの名無しさん** · 2025/04/27(日) 18:24:21.34

>>741
モダンと言うのはだいたいC++が持ち出して来た概念であって
それに当てはまらないなら遅れているとか悪いとか言うのは見当違いだとわかるはず

**デフォルトの名無しさん** · 2025/04/27(日) 18:37:48.95

>>744
「モダンはC++が持ち出してきた概念」はウソでしょ
例えばC++20のrange導入などでようやくC++も他より遅れてモダンになってきたけど
C++プログラマーのほとんどはまだ理解していなくて使えないよね

**デフォルトの名無しさん** · 2025/04/27(日) 18:42:03.43

C++以外の言語でもモダンという表現は使うぞ
モダンJavaとかモダンC#という表現は聞くし

「古い言語に追加された新しい書き方」という意味でなく、本当に新しい言語かつ人気のものとなると Go, Rust, TypeScript, Kotlin くらいじゃない？
どれもだいぶ特性の異なる言語だから、「モダンな言語では〜」といって共通認識になる概念ってあまり無いと思う

**デフォルトの名無しさん** · 2025/04/27(日) 18:47:36.67

それだけ理解していればモダンな言語と言うのは虚像だとわかるはず

**デフォルトの名無しさん** · 2025/04/27(日) 18:48:57.82

それに今気が付いたけどおじいちゃんは勘違いしてる
javaやjsを良い言語だとは一言も言ってない

**デフォルトの名無しさん** · 2025/04/27(日) 18:50:47.27

Rustの一番の弱点は学習に時間がかかること

**デフォルトの名無しさん** · 2025/04/27(日) 18:55:49.11

そのへんのモダンなGC言語の知識と
C++11でいいからmoveからshared_ptrまでのメモリ管理の知識さえあれば
Rustに難しい面は何も無いと思うんだけど
Rustの学習が難しいと主張してる人は何が難しいの？？

**デフォルトの名無しさん** · 2025/04/27(日) 18:57:07.46

>>749
それはあなたがC++11のメモリ管理もモダンな言語も理解できていないからでしょ？

**デフォルトの名無しさん** · 2025/04/27(日) 18:57:50.17

可読性ならGoは高い
あれは「読み手に優しい」と言われる言語で、書く分には冗長で面倒だけど、そこをAIにやらせるなら読みやすさやレビューしやすさは強みになる

Rustは型の表現力が強くて、型がドキュメントになる
それ自体は強みだけど、理解するまでは大変
Arc<Mutex<_>> とか impl FnOnce とか、分かる人にとっては meaningful だけど、そこに至るまでにはある程度の素養と時間が必要ではある

**デフォルトの名無しさん** · 2025/04/27(日) 19:05:12.57

>>751
「お前らバカにはRustを理解できまい」みたいな思想があるなら、それこそRustの弱点じゃないの？
あなたのいう「良い言語」って、例えば「ジュニアクラスの開発者も含むチームで、どの技術を使うとサービスを開発・保守しやすいか」みたいな観点での価値判断をまるっきり排除してるでしょ？

**デフォルトの名無しさん** · 2025/04/27(日) 19:09:59.10

おじいはいくら言われても言葉が通じないから無駄

**デフォルトの名無しさん** · 2025/04/27(日) 19:10:10.15

>>753
大昔の「C++11のメモリ管理」と
今普通に使われている「モダンな言語」を理解できていれば
Rustの学習に困ることは何も無いんだよ
それらを理解していてRustの学習で困った人はいないよ

**デフォルトの名無しさん** · 2025/04/27(日) 19:13:10.29

Rustを使うには様々な概念及び実際のコーディングテクニックを習得しなくてはならない
それがハードル

そのハードルを恐らく可能な限り低くするか無くすで在ろう存在がAIなどの補助を受けた次世代言語

**デフォルトの名無しさん** · 2025/04/27(日) 19:15:07.05

Javaにたとえると
intはObjectではないとかintはポインタではないとかが難しいね

整数もオブジェクトにしてしまうスクリプトが最もユーザーフレンドリー

**デフォルトの名無しさん** · 2025/04/27(日) 19:32:31.58

>>757
そういう全ての型をオブジェクトへのポインタとして扱う言語は非効率なのでRustに勝つことはを絶対に不可能だよん

**デフォルトの名無しさん** · 2025/04/27(日) 19:37:46.28

Fn, FnMut, FnOnce とか Box, Rc, Arc の区別って、GCのある言語ならそもそも必要のないものだからな
Rustのメモリモデルでは必要だけど、無くて済むならその方が楽だろ
GCを避けたい人のための言語であって、簡単さや分かりやすさを目指した言語ではないよ

**デフォルトの名無しさん** · 2025/04/27(日) 19:46:27.37

Rustは他の言語で苦労しないと存在意義が分からない要素が多くて学習曲線が絶壁になってる
別言語を踏み台にしないと登れないレベル

Goはシンプルな言語だけどC++/Javaが例外を導入した経緯を無視して例外を取っ払ったから
例えばchdirの成否判定を忘れたまま処理を継続するようなC言語時代のバグを復活させてしまった
（RustもResultのmust_useで警告出すだけだから警告無視勢は救えないけど）

**デフォルトの名無しさん** · 2025/04/27(日) 19:46:33.19

>>759
Rustを置き換えることのできる言語の話をしている場でそんなアホな意見はない
GC言語しか使えないお子様プログラマーはお呼びでない

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

>>759
あと、FnとFnMutの違いは環境キャプチャ参照が不変か可変の差なのでGCの有無は関係ない
RcとArcの違いは並列時のアトミック性の保証の差なのでGCは関係ない

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

世界中のプログラマが容易にRustを理解出来るならジジイが今すぐ世界を回ってすべてのプロジェクトを止めさせて
Rustで書けと言って回ればいいじゃないか？

特にC++とか

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

>>714
WindowsではMicrosoftがネイティヴ・コードを生成するC#コンパイラを作ればC#がそうなる。
MacではSwiftが既にある。

>>736
Rustは可読性が低すぎるだろ。COBOLとアセンブリ言語を混ぜて、ゴテゴテした記号を散りばめたような感じ。

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

>>764
C#はGC言語だから無理だよ

Swiftはリファレンスカウンタ方式なのでGC言語の1種と見ることもできるね
C++/Rustから見るとshared_ptr/Arcを常用する重い方式なのでSwiftが遅いのはそのため

Rustは可読性が高いよ
どの言語もその言語を知らない人にとっては呪文に見えるのは当たり前だよ
可読性の高い低いはその各言語を使いこなせる人にとってどうかが判断基準だよ

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

読むときにノイズが多いのは事実だと思うよ
BoxとかArcとかdynとかはコードの機能的な側面だけをざっと理解したいときには鬱陶しく感じる

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

>>735
まあ仮に、仮にそれくらいのレベルの言語を AI が人向けに生成するのをスタンダードにしたら低レイヤは全然書けないことになる。
結局は用途によって使い分けるしかない。

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

>>766
それはRustのコーティングしたことがないから勘違いしてるんじゃないかなー
RustではBoxであろうがArcであろうがスタック上の値であろうが、区別は一切なく他の関数に渡す時は単なる参照＆Tになるからコード上でノイズにならないんだよ
Boxを作って返す時またはBox固有の機能を使うというレアケースのみBoxが出てくるだけだね

**デフォルトの名無しさん** · 2025/04/27(日) 21:28:49.41

このスレで実際に自分のいる組織やチームの開発言語をRustに変更できた人ってどれくらいいるの？
小さいプロジェクトや個人なら好きにできるけど、実際なかなか難しいのでは

**デフォルトの名無しさん** · 2025/04/27(日) 21:34:07.27

PHPからGoにするのも難しいよ。Pythonは皆出来る

**デフォルトの名無しさん** · 2025/04/27(日) 21:38:12.88

5chもperlやめてRUSTで書き換えてくれ

**デフォルトの名無しさん** · 2025/04/27(日) 21:39:18.11

まだperlで消耗してるのｗ
アラフィフだけどもう使わないし読めない

**デフォルトの名無しさん** · 2025/04/27(日) 21:50:42.18

>>734
パイチョンとかblackでガチガチにコードスタイル決めてるからaiが扱うコードとしては有利だろうな

**デフォルトの名無しさん** · 2025/04/27(日) 23:35:08.03

>>769
今まであちこち見たり体験したりしてきてると
どの言語でもどのフレームワークやサービス類でも言われて義務的に学習し始める人が多い環境はダメ
良さそうなものが出た時に興味を持って自分から学習し始める人が多い環境は行ける
後者はまだ手を出してない新たなものに対しても対応力が高い
前者の環境でくすぶってる人は抜け出した方がよさそう

**デフォルトの名無しさん** · 2025/04/27(日) 23:38:14.26

後者は変態だね。変態揃ってます。という採用アピールしよう

**デフォルトの名無しさん** · 2025/04/28(月) 00:33:05.01

ノイズが多い説が面白いのは、ノイズを学習する義務なんてあるわけがないから
そんなことを知っているのは物好きだけだと言えるところ

**デフォルトの名無しさん** · 2025/04/28(月) 02:54:28.25

>>751
>それはあなたがC++11のメモリ管理もモダンな言語も理解

C++もモダンな言語もそれらはそれら自身でメモリ管理もモダンな処理も理解出来るのに
RustはRust以外のC++やモダンな言語で先にそちの理解を済ませないとRust自身で理解が完結出来ないと言ってるんですねわかります
Rustの欠陥じゃまいか

**デフォルトの名無しさん** · 2025/04/28(月) 05:10:35.52

>>777
どちらも各々は容易に学習できる
だから片方を知っていればRustの学習は容易く問題になっていない

もちろんどちらも知らない人たちも多いのだ
別方面のその二つを同時に学習することになるため難易度が高くなる
そのためRustは難しいと感じてしまう
しかしそんな無茶な学習方法をするのが悪いのだ

良い学習方法は段階的に学習することだ
そこには様々なやり方がある
例えば

**デフォルトの名無しさん** · 2025/04/28(月) 05:15:04.65

>>778の続き
良い学習方法は段階的に学習することだ
例えばヒープを一切使わずに数値型と配列だけでも非常に多くの学習と練習ができる

イテレータメソッドチェーンでクロージャを渡して処理するなどの経験をしたことがなければ学習できる
さらに自分でイテレータを作るのもIteratorトレイトのメソッド実装という良い学習になる
さらに自分定義のトレイト作ってその自作イテレータをメソッド化するのも良いだろう
次はそれらをi32型などで作ってきたところの型を整数型一般にジェネリック化をすることでトレイト境界の意義もよくわかるだろう

このようにヒープを一切使わなくても数値型と配列だけでもRustの学習をどんどん進めることができる
以上の制約があまりにキツいならcollectでVecを生成するなどならばヒープを使ってもメモリ管理まで気にしなくて済む

そしてRustの機能を一通り学んだ後にようやくヒープを本格的に用いてメモリ管理分野の学習に入ればよい
段階的に学べばRustは難しくない

**デフォルトの名無しさん** · 2025/04/28(月) 06:40:53.40

境界知能の次はコレ？

**デフォルトの名無しさん** · 2025/04/28(月) 08:33:19.21

将来のAI前提なら、無駄に抽象度の高いコードは廃れて把握しやすいグラフ中心だろ。

ユースケース図くらいかせいぜいUMLで、フローチャートレベルの実装詳細はライブラリアンくらいしか触らないんじゃないんかね。