Rust part21
レス数が950を超えています。1000を超えると書き込みができなくなります。
それ複オジがよく書いてたやつだけど
そうやって書くと型の違いと変数のmutabilityの違いを混同しちゃうから良くないんだよね fn main() {
let mut foo = String::from("foo");
let mut bar = String::from("bar");
let a1 = &foo;
// a1の値も参照先（foo）も変更できない
// a1.push('o'); // 不可
// a1 = &bar; // 不可
println!("{a1}"); // foo
let a2 = &mut foo;
// a2の値は変更できないが参照先（foo）は変更できる
a2.push('o');
// a2 = &mut bar; // 不可
println!("{a2}"); // fooo
let mut a3 = &foo;
// a3の値は変更できるが参照先（foo）は変更できない
// a3.push('o'); // 不可
a3 = &bar;
println!("{a3}"); // bar
let mut a4 = &mut foo;
// a4の値も参照先（foo）も変更できる
a4.push('o');
a4 = &mut bar;
println!("{foo} {a4}"); // foooo bar
} >>815
先にfirefox互換のブラウザをRustで作れよ >>815
ついにRustで書き切ったカーネルが出たか
素晴らしい😎 JythonみたいにRinuxとか呼ばれる様になるんかね >>850
＞可変な不変参照 mut &T
＞可変な可変参照 mut &mut T
そこは
mut& T
mut& mut T
のほうが良くないか？ >>857
なんでmut& Tやmut& mut Tのほうがいいと思うの？ 変数は不変 参照先も不変
【Rust】 let ptr: &i32 = ...
【C/C++】 const int* const ptr = ...
変数は可変 参照先は不変
【Rust】 let mut ptr: &i32 = ...
【C/C++】 const int* ptr = ...
変数は不変 参照先は可変
【Rust】 let ptr: &mut i32 = ...
【C/C++】 int* const ptr = ...
変数は可変 参照先も可変
【Rust】 let mut ptr: &mut i32 = ...
【C/C++】 int* ptr = ... プログラミングをしていて最も出現頻度が高いのがその4つのうちこのパターンだな
＞変数は不変 参照先も不変
＞【Rust】 let ptr: &i32 = ...
＞【C/C++】 const int* const ptr = ...
したがって可変部分のみmutを付加するRust方式が理に適っている C/C++のconstとRustのletを対比するなよ
コンパイル時の定数と変数は違うから C/C++のconstはコンパイル時の定数とは限らない
> 変数は不変 参照先も不変
C++はconst int*で定義した変数経由では参照先を変更出来なくても他から参照先が変更されることがあるので「参照先が不変」とは言えない >>861
コンパイル時の定数は
Rustではconst
C/C++ではconstexpr C/C++のconstはコンパイル時の定数となることもあるのがややこしいところ
constexprはそれを矯正するもの
1対1の単純な比較では抜け落ちるものが多すぎる イミュータブルの観点でこの対応は合ってる。
Rust: let foo: &i32 = ...
C++: const int* const foo = ...
ただし違いとしては、
Rustではfooが生きている間は参照先が(内部可変性を除いて)真に書き変わらない保証がある点が異なる。 この件はC++と比較しても刺激が少ない
mutがない関数型言語と比較するほうがいい ミュータブルを無くすと美しく見える反面
ガベージコレクションが多数発生し効率が悪くなる
アルゴリズムも制約を受けてしまい効率が悪くなる Linuxカーネルについに実用的なコードが
マージされたと話題になってるな >>868
新規追加するドライバにだけ採用とか前に言ってなかったっけ？ >>867
ガベコレが多数発生することをRust風に言うと、
実行時の参照カウントが激しく増減する >>870
ミュータブルがない関数型言語との比較の話だから
ミュータブル非導入で起きていることは使い捨て一時ガベージの大量発生 cloneに似た処理をしてからオリジナルをdropするんだよね RustはカーネルやOSコアの開発で存分に活躍してくれ🙏 そもそもrustを使う場面があるか？って話
wasmは始まる前からオワコンだし、組み込みシステム開発してる人なんて割合で見ればプログラマの中でごく一部だし >>879
ごく一部だというのが仮に事実だとしても、少ないからって要らないってわけでもないだろ。
そこそこの規模だと C よりは Rust のほうがいいわ。 >>875
ちゃんとリンク貼れ無能
スキルアップしたい言語はPythonとJavaScript、不動の不人気言語はCOBOL
安藤 正芳 日経クロステック／日経コンピュータ
https://xtech.nikkei.com/atcl/nxt/column/18/02670/112900003/ 「実際に仕事で使われているプログラミング言語」（2023）
https://qiita.com/mmake/items/b346cb32ccc3bcb5d03f
日本でのRustの使用実態が全く見られないの笑えるな 使われてる言語ランキング見てると、CやC++、Rustみたいな組み込み開発用言語は全体から見ればもはやプログラミングの中でもマニアックな分類なんやね
ブログラマといえばWebサービス関連の人ってイメージになっちゃった とはいえそれを支えるホスト環境 (OS) や処理系は大抵の場合に C とかで書かれてるんだけどな。 RustがC/C++の代わりになるのは間違いないのだけれどね
富士通さんはRustの普及をもっと頑張ってくれよ >>885
C/C++からRustへの書き換え作業は大変だからね
脆弱性の解消のために徐々にRustへの置き換えが進んでるから2030年頃にはだいぶ完了してるっしょ 有名どころだと
ProssimoがsudoやzlibのRust実装を頑張ってるよね
https://github.com/memorysafety デバイスドライバとかは C のほうが楽だけど
言語処理系くらいのレイヤだと大部分は Rust で書いたほうが楽そうだなーとは思う。 そろそろ実装に入れそうだけど。Rustを勉強したことを少し後悔ぎみ
オブジェクト指向言語しか触ったことなかったから取得するのにガチで一ヶ月(130時間)かかった
chatgptに聞いた感じだと、これでも割と早い方らしい。おとなしくC/C++を使えばよかった 【AI】Googleの医療面接特化AI「AMIE」は人間よりも正確な診断が可能＆患者への印象に優れるという研究結果 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583722/l50
【AI】Google DeepMindが数学オリンピックレベルの幾何学問題を解けるAIを発表、人間の金メダリストに近い性能を発揮 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583476/l50
【AI】大学入試共通テスト、3つのチャットAIに解かせてみたら？ GPT-4はバケモノだった [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705585402/l50
【ナゾロジー】「株価の変動を粒子の振動として理解」量子力学で株式市場の法則を読む！ [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583580/l50
【AI】NTT、自分の分身AIを低コストで作る技術。自分の合成音声を簡単に作れる技術も [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583313/l50
ボイス・トォ・スカルのコアプログラムの一部は上記を統合している >>890
130時間はサンクコストなので0時間の時点における正解は現時点でも正解
ってAIは教えてくれなかったの？ C/C++, java, pythonの経験があるから、Rustを取得するのに50時間かからないだろうと思ってた時期が僕にもありました
ヌルポが怖いからRustを使うけど……歯を食いしばって捻出した130時間を投資回収できるかは神のみぞ知る C/C++ の経験があってそんなに時間かかるか？
「習得」というのがどの程度の基準で見るかにもよるけど
いわゆる the book を一通り読んだ後なら
コンパイラがあまり助けてくれないところ (unsafe) を除けば
マニュアルを見ながら書けばだいたいなんとかなる程度には使えそうなもんだと思うんだが。 C/C++を適当にやってたせいでRustでつまづくってのはありそう >>894
最近はpythonで仕事する機会が多くて、C/C++を4年ほど触ってなかったのと、
仕事の後に疲れた頭で勉強したから体力的にキツかったのと。。。
the bookを読むだけで90時間はかかったわ。検索モジュールを開発しようと思ってるんだけど
いきなり実装に入るより読経した方がマシな感じで、regexのコードを読んでる
既に10時間読経に捧げて、あと10時間は追加の読経が必要な感じ
この後、形態素解析エンジンのコードも読む必要があるから、追加で20時間はお勉強する予定であわせて130時間
……重いです >>896
the bookでの90時間の中身がわからないので何とも言えないかな
bookだけを読んだのか
それともdocsやreferenceと行き来して読んだのか
サンプルコードくらいのことを書けるようになっただけなのか
それとも各機構や機能を本質的に理解したのでdocsなど見ればbookに書かれてないことも書けるようになったのか
などピンキリだよね >>890
一般的にですが、
自分が使いたい新たな言語の学習で、辛いとかキツいとか後悔とか感じる人はプログラマーに向いていません。
プログラマーに向いてる人たちにとっては、新たな学習や会得はワクワク楽しくてその時間を後悔することもありません。 件の人は質問がどれもバカっぽかったから習得からは程遠い印象 Rust の個々の機能が難しいとは感じないけど
綺麗に噛み合うように全体を設計するのは C++ とは違う感覚が要るから
大きいプログラムを綺麗に設計しようとしたら最初はしんどいかも。
ボトムアップ的なスタイルで書いていくのをオススメする。 逆かな
みんなリファクタリングが機能しないからRustだとボトムアップじゃだめだと分かっかんだよ the bookを頭から読むやつなんているんだ
大してわかりやすくもないし
説明が冗長な感じだからChatGPT使った方が良いぞ 初心者にとって知らんことが書いてあるんだからそんなにスラスラとは読めないのは当たり前だし、文章自体に問題があるようには感じないな。
改善すべき点がゼロなわけではないが、少なくとも C++ を分かっているくらいの人が最初に読むには十分すぎるほどに良書じゃないの。 説明対象がもつ難易度より分かりやすい説明があったとしたらその説明は嘘であるか不足しているってことだ。
本来の難易度は後にならないと分からないから学習者本人には見分けられない。 ガリ勉完璧主義者ほど隅から隅まで理解しようとするけど
要領よくChatGPTを使いこなすチャラ男に天然GPTとしてカモられている 天然GPT本人はマウントして気持ち良くなりたいから他のみんなと勉強会じゃなくて家でガリ勉なんだ 作りたいものを決めてそれを実現するための知識をChatGPTで調べるというやり方のほうがはるかに効率が良いよ
多少間違ったこと教えてきたり
古かったりするけどそれはもう気にしてたら仕方がないので
無視してどんどん手を動かすほうが良い The Bookは簡潔にまとめるために説明をやや端折り気味
書いてる内容自体が難しいわけじゃないけど深い理解には至らないから腹落ち感を得にくい
あんまり期待しすぎず無料で読める基本チュートリアルとして捉えておくべき ところでこのスレには組み込み開発でRustを使ってる人はいるの？ 組み込みは頭おじいちゃんが支配してるからRust使える人いないよ そう組み込みも重要な分野だから、これにRustが皆無な時点で大手では大々的に採用されていないって事、せいぜい窓際
「実際に仕事で使われているプログラミング言語」（2023）
https://qiita.com/mmake/items/b346cb32ccc3bcb5d03f そうだ窓際追い出し目的でおじいちゃんにRustやらよう そうだ窓際追い出し目的でおじいちゃんにRustやらせよう
本当にあるな >>903
Rustでもリファクタリング前提で書き始めるのがいいよ
早すぎる構造決め打ちや早すぎる最適化などはせずリファクタリングで対応 >>899
んなアホな。
一般的というなら「石の上にも三年」とも「下手の横好き」とも言うから、嫌いだからと言って不向きとは言えない。 自分がこうだから他人もこうあれ
って考えは時代にそぐわない老害感がある >>896
Rustは絶壁の学習曲線だから、段階的な学習は難しい。少なくともスタックフレームの動きを意識できないとキツイと思う。
Rustを使った開発も、小さく始める段階的開発とかきついんじゃない？ひたすらスクラップ＆ビルド繰り返しそう。 >>924
スタックフレームはコンピュータの基礎知識であってC言語でも必須でありそれをRustの問題にする人はいない
段階的開発がキツいという主張もそんなことはなく根拠もない 全体を綺麗に構成することはしづらくても小さなモジュール単位でならそれなりに構成できるからそれを繰り返せばいい。
全体の構成を考えてから作るよりは汚いだろうけど、綺麗な全体の構成を考えるなんていう出来もしないことをやるよりはそういうボトムアップ方式のほうが少なくとも途中まではまあまあに出来る。
もちろんちゃんと全部をまともに構成できるだけの能力を身に付けられるならそれに越したことはないよ。
でも実際問題として初心者にはできないじゃんと思ったからボトムアップ方式のほうが(初心者の内は)よさそうと考えてる。 >>924
意識するのはヒープじゃないか？
スタックフレームは解放されるんだから意識しないで良いんだぞ 変数の寿命と連動するから意識するよ。
C/C++ の世界だと当たり前のことだから意識してる自覚すらないレベルで自然に考えてるけど。 人格をもたない書物は効率が悪いという風潮は面白い
人格がなければ報酬とか私刑とかができないってことだろうか 進行が早くなったのでいつもの
次スレはなしで既存のﾜｯﾁｮｲスレにしよう
過疎るのは既定路線なので頃合いでしょ 「スタックフレームを意識する」というのはどの程度を指してるんだろう。
どれがスタックに積まれるかとどうスタックに積まれるかは違うわけで。 >>924
スタックフレームの動きってプログラミング初心者でも何の問題もなく理解できるやろ
学習曲線めちゃ緩やかじゃん オラから『Rustの練習帳』って新刊が出るんだね
タイトルがエモい ミスチルはわかるんだ
ミスター・チルドレンは長いから
サザンもサザンオールスターズは長いからわかる
マクドもマクドナルドは長いからギリわかる
オライリーをオラは無いだろ
たかが2文字略すなと思った
ま、どうでもいいんだがな スクリプト言語出身者が増えたせいだよ
スタックフレームやヒープなんてCSやってりゃ習うでしょ
コンパイラかコンピュータアーキテクチャでやる
スクリプト言語はスタックフレームの開放も全てGCがやることになるから
全く意識しないんだよな スクリプト言語に限らず、C/C++を書かなければそこら辺に気を使う機会はないよ GCありでパフォーマンスも関係ないなら、スコープだけ気にしていれば困らないしね。 webサービスまわりは全部スクリプト言語かGCランタイム付き言語だもんなあ 最近は組み込みもC/C++を使う理由がないことが多い オラは「Rust for Rustaceans」の訳書出さないな
本格的にRustやるなら必読書なんだけどな スクリプト言語はともかく静的にコンパイルする言語ならGC言語でもスタック/ヒープは意識するけどね >>945
CPU時間(ミリ秒)あたりで課金されるからこそのRustだよ オンプレミスでも同じ
Rustで書くかスクリプト言語で書くかでサーバーやメモリの必要量が何倍も変わる
電気代も節約できRustはエコにも貢献 そう、CO2排出量を考えたら、Rust以外で書くのは社会にとっての悪 レス数が950を超えています。1000を超えると書き込みができなくなります。
