Rust part36

公式
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 part35
https://mevius.5ch.io/test/read.cgi/tech/1774514307/

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

wasm規格ちゃんと決まってgoogleとmozillaが実装したらフロントもrustの時代くるね

>>173
C#ほ食えないし危険だしノロい😩

JS経由してる限りWASM使う理由がない

>>172
よりチェックする方がいいなら100重チェックでも1000重チェックでもする方がいいってなるか？って話なんだが。

>>177
毎回進展してる
既に各ブラウザでJSオブジェクトをWasmを渡せるとこまで普及していて使えてる
そしてDOMを直接触れるようになるだろう

component modelが策定されてるからこれが決まればjs経由なしでdomいじれるようになるよん

全てがRustに有利になるよう進んでいってる

しかしフロントは素直にTSで書いたほうが楽じゃね

TSはクソ言語すぎて辛い
ウェブ関連以外で誰も使っていないのがその証拠

TSはクソ言語→わかる、ウェブ関連以外で誰も使っていない→わかる
だからフロントだっつってんだろ・・・アホなんか

フロントはrustの方がいいよー
dioxus てだとrsx! ブロックに全部突っ込めるし、まず誤動作しないからページ遷移早い自作のホームページだと絶対おすすめ

ページ遷移しないんならastro で作ってftpでいいけど退屈なページになるしな

>>185
SPAやCSRに向いてるのはdioxus？

icedの設計のほうが面白そうだがdioxusなのか？

egui, iced, leptosも今度試してみるね
タイプスクリプト嫌いだから色々お試し中

WEBだとだとIcedじゃなくてSeedってやつだわ

勢い見るとフロントも全部rustがくって行きそうだな

くたばれ、Electron！

reddit見てると流れてくるけど
Webフロントも捨ててTUIフロントのAll Rustでサービス作るのも流行ってるっぽい　バックはAxumとか
Discordみたいなコミュニティサービスとかあった

>>172
ツッコミどころ満載だけど一つだけ注意しておくと
async dropやLinearTypesが入ったところで
安全性を保証するのは今と同じくプログラマーの責任なので
100%安全になることはない

>>180
決まればな……
適当なホストを経由するほうがよほどスマートではないかという意見も根強くて Component model の存在意義すら疑問視する人もいる。

フロントもバックエンドも全部TSでいいよ
TSは完成された言語
Rust使って0.5％改善しましたとか趣味の世界でビジネスの世界じゃない

TSでunkonow使いまくる

TSがネイティブ言語ならなぁ

フロントは開発速く済むからTS使うけど
バックエンドはRustのほうが楽なのにわざわざTSで書くメリットってなんや

全てをRustが飲み込むのか🤔
そんな時代は地味にThe book周回とRustlingでひたすら基礎練してコンピュータサイエンスを学習するんや🤔

TypeScriptは安全性でも劣り速度でも劣り開発効率でも劣る
今となってはメリットは何もない

スタートアップみたいな少人数で高速に開発サイクル回していくところならフロントもバックもTypeScriptで統一する選択は全然ありだと思う
ある程度規模が出てくるとパフォーマンスや保守性レビュー容易性が必要になるからそのタイミングでリプレースすればいい

スタートアップでTS使うようなサービスは普通に生き残れなさそう

なんかみんなNext.jsとかHonoとか言ってて置いてかれてるわ

JavaScript は本来的には動的型だしプロタイプベースだからな。
それに後付けでクラス定義風の構文が付け加えられてグダグダだ。
TypeScript として静的型を付け加えようとしたって無理がある。
あくまでも JavaScript を直接に使うよりはちょっとマシかもしれないって程度。

でも、なんだかんだで言語がどうとかよりもライブラリの量がものをいうってところはある。
Rust でも C++ でもいいが TypeScript で書かれているのを置き換えるときに足りないライブラリがあって自分で書かなきゃならないのは嫌だろ。
言語に不満があってもライブラリが揃ってるのを選びたくなる。

Reactライブラリって突き詰めれば状態管理メンドクセーだから設計次第だと思う

ライブラリ依存による負債
それがC++😩

>>174
C++スレで揉めてる件か
後発言語だから当たり前とはいえRustが何もかも解決してるよなあ

>>207
あれは分かってない人が変なことを言ってるだけで、 C++23 以降は Rust の Display や Debug に近いデザインになってる。
std::format を特殊化するのが Rust で言うトレイトの実装のような役割を持つ。

C++23だとRustの後追い
しかも普及すると思えない
そういう新たな仕様を使いまくっていこうとする人たちはRustへ移っちゃった
残ってるC++プログラマーはC++11すら使えない使わない人たちも多く

C艹スレ行ってくれ

Rustは便利で上手くて速くて良い仕組みが最初から標準になっているという話だよね
恵まれすぎてる

ドヤするためにrustやってるなんて哀れよのう

逆やろ
わざわざ不便な古い言語を使う人が変人かドヤ

C++とか言語自体じゃないがメンテナンスモードだからな
新しいライブラリとかもうあんま出てきてなさそうだし
GPLとかうざいライブラリのあったり
Rustの方が幸せにらなれそう

結局のところCの正統後継言語はRustでいいの？
C++は長い歴史で太りすぎたしGoは何か最近下火だもんな

jsて元々10日間で設計されてるしまあしゃあない
goはunixの作者が作ってるしtinygoてゆう組込向けのやつあるけど影薄くなってりゅ

C は C のままで発展すると思う。
今まで保守的すぎた反動で C23 は結構思いきった改定もやったし、このまま廃れる気はなさそう。

ただ、 C が実は適切ではなかった領域というものはかなりあって、そこに様々な言語が入り込むようになっただけ。
どの言語も C の立場を引き継いだわけではない。

プログラミング言語のHare をやりたいと思うものの、なかなか触れないなぁ

AIに試して評価してもらえ
どうせ実際に書くのもAIなんだから

Cの立ち位置は高級アセンブラに回帰するというかしている

>>219
AI評価ってのは公式アピールと巷のブログ記事やSNSのまとめでしかない
しかも声のでかいやつが優先されるから本当のところどうなのかなんて分からない

CPU メーカー (が主導する業界団体) が策定する ABI は C を前提にしているし確実なので、たとえば Rust と Go のライブラリを接続するときでもそれを根拠にせざるを得ない。
Rust や Go を使っていても資料が C で書いてあるので読める必要があるみたいな状況はこれからもかなり長く続くと思う。

AI に評価してもらう場合にでも評価軸の与えかた次第で良し悪しの判断はどうとでも変わるよ。
漠然とした意識で評価してもらってもあまりあてにならないし、きちんとした評価基準があるなら AI に頼るまでもない。

結論として、**「Cは言語として学ぶな、インターフェース（接続口）の作法だけを学べ」**が最適解です。

### 最短対策の3ステップ
1. **「書く」学習を捨てる**: 自分でCコードを書く必要はありません。Cの文法書を読み込む時間は不要です。

2. **「繋ぐ」知識だけを得る**: 公式ドキュメントの「FFI (Foreign Function Interface)」の章だけ読み、RustからCを呼び出すルール（extern "C", unsafe, repr(C)）を理解してください。

3. **ツールに翻訳させる**: bindgen を使い、CのヘッダをRustの型定義に自動変換させてください。その「生成されたコード」を見ることが、Cの構造を理解する最も効率的な答え合わせになります。

### 本質的な割り切り
* **普段**: Rustの安全な世界で開発する。Cの存在は隠蔽する。

* **非常時**: 予期せぬエラーが出たときだけ、Cの定義を「読み物」として参照し、原因の特定にだけ知識を使う。

**結論：C言語は「習得する対象」ではなく、Rustから安全に利用するための「外部インフラ」と定義して距離を置くのが正解です。**
今後、RustでFFIを扱う際に「これだけは知っておくべき」という具体的なトラブル事例などについて詳しく知りたいですか？

今からならRustの次の言語のCarbon言語の勉強した方がよくね？

>>224
今となってはそれで正しい
しかもCなどの外部ライブラリを利用してRustライブラリを作る人にとってのみインターフェースとしてCのABIを理解が必要
そうではなくRustライブラリ利用のみの人ならその知識すら不要

>>225
どうでもよくね
必要なら、RustからCarbonに変換して、とAIにお願いすりゃ30分くらいで移行終わるよ

carbonとかhareとか見てきたけど関数名大文字にしなきゃいけないのとかがダサかった
rustのエコシステム超えれるわけないし流行るわけもないからやる意味ない
言語は手段なんだからrustとpyだけできればいい

Pythonとの理想的な接し方は、**「言語そのものを極める対象（ゴール）ではなく、普遍的な技術を試すための『強力なプロトタイプ環境』として扱う」**ことです。

具体的には以下の3ステップで運用してください。
1. **「不変の技術」を優先する**
アルゴリズム、データ構造、設計思想（アーキテクチャ）、データベース理論など、言語に依存しない技術を主戦場として学習してください。これらは一生使えます。

2. **Pythonを「検証エンジン」にする**
学んだ理論を、まずはPythonで素早く実装して動かしてください。Pythonの圧倒的な書きやすさは、理論を実験する際に最も摩擦が少ないからです。

3. **Rustへ「再構築」する**
Pythonでロジックが完成し、その技術に「恒久的な価値がある」と判断できた時だけ、Rustで書き直してください。これにより、Pythonの流行り廃りに左右されず、かつ最高峰の実行性能も手に入ります。

つまり、**「Pythonは『書き捨てて良い実験場』、Rustや設計論は『資産として残す場所』」**と割り切るのが最も合理的です。

>>229
そんな誘導質問するから変な結論になる
最初からRustで作ったほうが効率いい

両者の本質的な違いを端的にまとめます

### 1. 最初からRustで作るべき人（実装主導）
* **目的:** 言語習得そのもの、または極限のパフォーマンス。
* **メリット:** 言語の制約（型・所有権）が強制的に設計力を高め、手戻りのない強固な実装が完成する。
* **デメリット:** 「理論の試行錯誤」と「コンパイルとの戦い」が同時に発生し、開発効率と学習効率が著しく低下する。

### 2. Pythonで試作してからRustにする人（設計主導）
* **目的:** 普遍的な理論の理解、または失敗コストの最小化。
* **メリット:** Pythonの低摩擦環境で「何を作るべきか（理論）」を完成させ、その後に「どう正しく実装するか（Rust）」へ移行できるため、思考のボトルネックが消える。
* **デメリット:** 同じロジックを二度書く手間がかかる。

**結論:**
* **「作る対象」が明確で、すでに技術が枯れているなら「Rust」**。
* **「新しい概念」を学ぶときや、仕様が流動的なら「Python」**。
この二つを使い分けるのが、最も「賢いエンジニア」の生存戦略です。

>>227
tokioをCarbonで書き直してとAIにお願いしてみて
何分で移行が終わったか教えてねｗ

>>231
AIは質問者に沿って回答するのよ
そもそもPythonは小さなスクリプトを書くためのもので何かを開発するのに向いてるプログラミング言語ではないでしょ
さらに異なる言語へと書き換える二度手間コストはムダそのもの

>>232
CarbonはC++遺産を安全に置き換えるためだけの言語なのよ
最初から作るものはRustで書いたほうが良いとされているのに
RustからCarbonへと後退させる書き直しの意図は何？

結論から申し上げます。その主張は**現代の技術開発現場の実態とは異なります。**
理由は以下の3点です。
* **Pythonは大規模開発の標準言語:** AIやWeb開発において世界中で採用されており、その強力なライブラリ群は他の言語でゼロから構築するよりも圧倒的に効率的です。

* **「Pythonで書く」ことは戦略的な選択:** まずPythonで高速に開発して市場に出し、後にボトルネック部分のみ高速な言語（Rustなど）で最適化する手法は、現代の開発における「投資対効果」を最大化する標準的な戦略です。

* **適材適所のツール:** 言語は目的達成のための手段です。開発速度を優先するPythonと、実行性能を優先する低レイヤー言語を組み合わせることは「ムダ」ではなく「技術的合理性」に基づいた判断です。

開発において「言語の書き換え」が発生するのは、多くの場合「コストの無駄」ではなく、システムの性能向上や運用保守の最適化を目的とした**意図的なアップデート**です

AIがただしい

バカだな
何のために開発効率が劣るPythonで最初に書いて他の言語へ移植する必要があるんだ？？

動的型付け言語を使うと開発が速い！
なんて幻想を主張する人は下に見られる

サイクルが早いからトライ＆エラーは楽だよ
よく分からないデータの解析とかで便利

データ分析とかマシンラニングはpython一択だし
まあ裏でc fortran rustのライブラリ叩いてるだけなんだけど

しっかし、今のAIはコメントまでしっかり付けてくれるんだな。
組込みやっていると、AIコパイロットの有難みが沁みる。
C++ではコパなんか要らないが、Rustでは神様だ。

やはり囲い込まれてないWindsurfですわ

https://i.imgur.com/dWgQoMV.jpeg

他のスレもだけどAIペタペタする人増えたね

C#で食えなくなった😭

複おじAIに完全論破されとるやないかいｗ

Cが最強☆

結局AWSのSDK使ったりWASM PACK専用に作ったりでラックインするクネ

**結論 : これはRust特有の問題ではなく、「クラウドのマネージドサービスを使っている限り避けられない依存」です。他の言語（Go, Pythonなど）に書き換えても、AWS SDKを使っている限りロックインの状況は変わりません

AIはそれまでのやり取りと最後の質問の仕方で好きなようにAIの回答を左右することができる
ソフトな言い方をするとAIは人間に寄り添ってくれる
だからAIの回答を貼っても何の価値もない

世間話ならともかく専門性のある領域でAIに誤魔化しは効かない

AIコピペは完全に無視していい
そしてコピペした人はバカ扱いが妥当

C#で食えなくなった😭

最近はAIが回答したように見せかけて捏造や改変コピペもあるからなあ
信じる人は無知かお人好し

信じるもなにも論理的整合性が取れてるか否かだしなw

AIコピペ系は正規表現でNG入れろ、どの板でも役に立つ

Err

まともな人たちはAIを使ってもコピペすることは絶対ないからねえ
その場に合わせて要点だけ自分の言葉で書く
どの場でもAIコピペは頭のおかしい人がしてる

panic!

>>260
何が聞きたいのか言いたいのか分からんがとりあえずAIに聞いてみたらどうだい？

ペロッ…
うっ…これはスレ民の腕試し問題ッ…！
AIに頼ってる俺には分からないーー！！！😫

>>260
オーバーフローしてるだけやね～
big_int使えば行けるかと

play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=94a3bcf25d96bc2491f1b19fab0e0da8

>>263
どもです。そんなもんがあるとわ　勉強中mOm
でもpythonだとほとんど無限なのが凄いなぁみたいな。はい

なんだ普通の質問かよ
Rustは安全性主張してるの簡単に算術オーバーフロー起こせるってアンチが突いてきてるのかと身構えちまったわ

https://www.shoeisha.co.jp/book/detail/9784798189314
「独習Rust」が出る。

>>266
オライリーの本全部読んだ後だがこれも買うか
オライリーの本では効率的なRustが良かった

C#で食えなくなった😭

脳が萎縮してAIコピペしかできなくなったぉぢさんが社会問題になってるらしい

またシュバってきたのか
もうその話題は終わりですよ ^ ^

今どき言語学ぶのに本いる？

>>271
いらない
The book本編をAIで翻訳しながら周回すればいい

🤣
https://i.imgur.com/QdnVOt2.png

>>272
The book が本じゃないって？