Rust part27

**デフォルトの名無しさん** · 2024/12/02(月) 22:32:50.31

公式
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 part26
https://mevius.5ch.net/test/read.cgi/tech/1726838318/

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

**デフォルトの名無しさん** · 2025/03/23(日) 20:31:47.48

環境要因だけど、単価と工数でGC言語が勝ってるってさ

**デフォルトの名無しさん** · 2025/03/23(日) 20:35:34.98

>>932
単価？
GC言語だけやってる連中はバカだから給料が安いということか？

**デフォルトの名無しさん** · 2025/03/23(日) 21:25:09.29

実際そう
Goはジュニアクラスのエンジニアとシニアクラスのエンジニアとで書き方が変わらないのが特徴で、Googleのような大きな組織での開発効率のために産まれた言語
良し悪しとかでなく、そもそもの言語の目的の違い

パフォーマンスが重要な仕事にはRustが向くけど
、それなりの速度があれば十分という分野ならRustを使う意味はあんまり無い
IOが中心になる分野なら、Rustは多少は速くても「劇的な違い」にはならないと思う
非同期処理を書くのが難しくないとか、社内に知見があるとかの方が重要という場面も多い

もちろんRustが向く分野も多いので、そちらではRustを使えばよい
言語は目的や求められる要求に応じて選ぶという、ごく普通の話

**デフォルトの名無しさん** · 2025/03/23(日) 21:33:57.65

速度だけが重要ならjavaなんてなんて生まれていないしここまで大きな産業にもなってない
みんなc++を使えばよかった

実際はそうならなかった

**デフォルトの名無しさん** · 2025/03/23(日) 21:39:18.46

>>931
なんの勝ち負けの話してんだよww

**デフォルトの名無しさん** · 2025/03/23(日) 21:49:34.80

C++は平屋のCに何階も増築してきたから基盤はCのままで古い言語だからね
C++11でようやくunique_ptrとshared_ptrのスタートライン

一方でRustは現在の他のモダン言語と同等かそれ以上で何もかも快適
そして開発効率も抜群に良い
静的に最もバグを回避できる優れたプログラミング言語となっている
(もちろん原理的に回避不可能なアプリのロジックバグは除く)

**デフォルトの名無しさん** · 2025/03/23(日) 21:52:06.36

Rustの過剰な持ち上げは普通のRust開発者にとっても迷惑だからな
そういう輩のせいで「Rustは信者が煩い」みたいな意見を見るし、それに辟易する
向き不向きや求められる要求、組織の知見などを考慮して技術選定するという、開発者なら持つべき感覚を否定し続けてるのが理解できない

特定の言語だけを持ち上げる信者はGoやC#やTSにもいるし、そういうのは同様にうざったい

**デフォルトの名無しさん** · 2025/03/23(日) 21:55:17.62

2000年頃、サーバーの仕事なら、新人にはCのメモリ管理が無理だからってJavaでキャリアスタートしたよ。
その頃のオンプレはメモリ数GBだけどJavaが何とか動かせたんだ
そこからGC言語優位が続いたけど、サーバーレスやらで効率重視時代が戻ってきたんだね

**デフォルトの名無しさん** · 2025/03/23(日) 21:59:15.01

>>938
事実のみで過剰な持ち上げはないのに何を発狂してるのかね
もちろん別の言語の話を何度もしていたらウザいからやめるべきだと思うがここはRust

**デフォルトの名無しさん** · 2025/03/23(日) 22:07:56.77

>>939
効率重視とともにエコ面が重視されてるね
そのまま電気消費量そしてランニングコスト
もちろんCPU＆メモリリソース使用量を減らせばサーバーなど台数が減らせる面もエコと料金につながる
慣れたらどのプログラミング言語も大して変わらないのだからそれなら全てを少なくできるRustが向いてる

**デフォルトの名無しさん** · 2025/03/23(日) 22:12:37.78

Rustは独自性が無い
C+の知見を移植してるだけ

**デフォルトの名無しさん** · 2025/03/23(日) 22:20:47.30

いつもの某オジサン(嘘つき/実務経験無し)がesbuildで完全論破されて発狂してるだけ
Rustスレの平常運転だから気にしない気にしない

**デフォルトの名無しさん** · 2025/03/23(日) 22:23:33.24

>>942
C++では出来ていないこと(や、C++に後から入ってC++で普及していないこと)が、Rustには大量にあることが特徴。
むしろ他のモダン言語をやっていれば理解しやすいことも多い。
ただし、Rustが色んな言語の良い最先端な部分を採り入れてるため、少しだけ学習曲線が急な面はある。
それでもすぐ学習して理解できるから、それら機能の効果と利便性のため皆が満たされている。

**デフォルトの名無しさん** · 2025/03/23(日) 22:28:21.95

>>944
無いよ

**デフォルトの名無しさん** · 2025/03/23(日) 22:30:17.46

>>945
無いとは何のこと？

**デフォルトの名無しさん** · 2025/03/23(日) 22:36:44.14

学習曲線のグラフに原点がないんだろうなあ
0とは一体何がどう0なのだ

**デフォルトの名無しさん** · 2025/03/23(日) 22:40:46.98

スマートポインタやRAIIはC++由来だし、代数的データ型やパターンマッチは他の言語にもあるけど、所有権やライフタイムはRust独自
これはかなり強力な仕組みで、安全性という点ではとても成功してると思う
(同時に難しさの要因でもある)

書いておいて何だけど、言語の独自性はそこまで重要でもないと思う
TypeScriptなんかがそうだけど、仕組み自体は既にあるものでもバランスが良ければ十分に価値がある

**デフォルトの名無しさん** · 2025/03/23(日) 22:45:57.15

C/C++が一番ダメな点は大量の様々な未定義動作

**デフォルトの名無しさん** · 2025/03/24(月) 00:19:28.90

CのenumとRustのenumで全く似ても似つかないのとか何とかしてほしいわ
C出身のノリで使うと実装量多くてビックリするわ。たかが整数型定数とかいうのと全く違うもんなあ
ほかにも学習で大変なところ数多あるけど、コンパイルエラーを全部潰したらあとはアプリケーションロジックだけの問題になるのはRustならではで快便感ある。Cはコンパイル通ってからが鬼門だからな

**デフォルトの名無しさん** · 2025/03/24(月) 00:51:58.09

なんでenumって名前にしたんだろうな
adtとかdataとかtypeとかにしたら良かったのにと思わなくもない

**デフォルトの名無しさん** · 2025/03/24(月) 01:05:28.53

>>951
実際の使われ方からするとOption型、Choice型だよね。それだとネーミング的に予約語と競合してダメだけどマシな名前は考える余地あったよなあ
基本的に「よその言語から似た単語借りてくる」風習はどの言語にもフレームワークにもあるし慣れるしかないけどね

**デフォルトの名無しさん** · 2025/03/24(月) 02:41:57.49

plain enumとADT enumがあるだけでenumはenum
ADT enumをenumの名前で使えるのはRustに限った話ではない

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

HaskellもRustと同じくらい使われてると言われていたが
つまりすべての製品に使われてるようなことを言っていた

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

結局、駄目なものはどれだけ宣伝しても流行らないのでは？

**デフォルトの名無しさん** · 2025/03/24(月) 07:38:50.09

そんなに言われてなかったよ。
それは誤解か、誤解した人が大げさに吹聴してるな

**デフォルトの名無しさん** · 2025/03/24(月) 08:13:34.82

>>950
たぶんプログラミング言語一般的な型付けシステムに慣れてないんだと思う
enumはその名の通り列挙型だよ
それを整数型定数と誤認してるのが不思議
定数はその名の通りconstで当然何の型の定数なのかi64とかf64とかOptionなど型名を指定する必要があるよ
enumは列挙型だから名付けてenum Fooなどの別の型になる
内部的には整数で識別されるからその整数値を指定することもできるけどその整数の取れる値の範囲は列挙した分に限られるから別の型
制限はあるけど明示的にcastすれば整数型(i32とかusizeとか)へ変換できるよ

>>952
enumは列挙型だからSome(T)とNoneの2つを列挙できるenum Option<T>型も作れるだけの話だよ
ここでTは任意の型を指定できてジェネリック
もちろんトレイト境界を指定することもできて例えばCowの定義はこうなってるよ
enum Cow<'a, B>
where
　　B: 'a + ToOwned + ?Sized,
{
　　Borrowed(&'a B),
　　Owned(<B as ToOwned>::Owned),
}

**デフォルトの名無しさん** · 2025/03/24(月) 08:14:23.64

Haskellを宣伝してた人がRustを宣伝してる

**デフォルトの名無しさん** · 2025/03/24(月) 08:15:54.54

>>957
Trait制約では？

**デフォルトの名無しさん** · 2025/03/24(月) 08:16:12.40

言語なんて一長一短あるんだから万能な言語なんてないんだよね
たまにそのへんのことがわからない人が宗教戦争始めんだよ

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

>>958
これだろうね

**デフォルトの名無しさん** · 2025/03/24(月) 08:28:31.69

>>959
トレイト境界(trait bounds)だよ
制約(constraint)とは異なり区別
任意の型(の集合)がトレイトによってトレイト実装されてる型とされてない型に境界が引かれるよ

**デフォルトの名無しさん** · 2025/03/24(月) 08:33:32.13

>>960
それぞれの言語に特徴があるね
その中でもRustは様々な優れてる点があるけど

>>950さんの言う通り
>> コンパイルエラーを全部潰したらあとはアプリケーションロジックだけの問題になるのはRustならではで快便感ある。

それが一番大きいかな
他の多くの言語は実行時デバッグで無駄な開発時間を奪われてしまうから

**デフォルトの名無しさん** · 2025/03/24(月) 08:38:14.85

>>963
CやC++ぐらいだろ
普通に普及してる言語は大体GCありで考えなくて良い

**デフォルトの名無しさん** · 2025/03/24(月) 08:56:28.14

>>964
GCは関係ないよ
プログラミングしたことあるならわかってるはずだけど
まず強い静的型付け言語でないと実行時デバッグは山積み
Rustの場合はデータ競合まで型付けチェックで弾いてくれるからさらに助かるよ
あと一番ありがたいのはsingle writer XOR multiple readers ルール
このおかげで色々な罠にはまらなくて済むよ
それによって書き換え競合を意識するようになるからデータ書き換えのスパゲッティ構造も防げたり

**デフォルトの名無しさん** · 2025/03/24(月) 10:05:01.91

>>960
「言語」はそれでいいとして「データ」は万能ではないと指摘されたらAIが死ぬんだよな
まだかなあ

**デフォルトの名無しさん** · 2025/03/24(月) 10:15:12.89

ポエムで草

**デフォルトの名無しさん** · 2025/03/24(月) 11:58:19.75

>>962
>任意の型(の集合)がトレイトによってトレイト実装されてる型とされてない型に境界が引かれるよ
普通に考えたら無理があり過ぎるってわかるやろ

**デフォルトの名無しさん** · 2025/03/24(月) 12:23:21.76

>>966
何を言ってるの…？

**デフォルトの名無しさん** · 2025/03/24(月) 12:26:57.19

>>968
トレイト境界はそのイメージがちゃんとできると使えるよ
トレイト毎に境界があるからね

**デフォルトの名無しさん** · 2025/03/24(月) 12:35:54.16

Arena<T>とかRc<RefCell<T>>ってCの生ポに比べてどれくらいパフォーマンス落ちるの？

**デフォルトの名無しさん** · 2025/03/24(月) 12:42:11.30

>>949
何でも必ず初期化させる言語と実際に利用するまで初期化が必要無い言語との差は速度面で差が出る部分だと思う
(安全面はおいといて)

**デフォルトの名無しさん** · 2025/03/24(月) 13:26:19.03

Trait制約とTrait境界
どちらが正しいの？

**デフォルトの名無しさん** · 2025/03/24(月) 14:05:50.97

>>973
公式といえるものが存在しないので明瞭な結論はないが境界のほうがスタンダードという風潮はある。
真っ先に日本語訳を出したボランティアグループがそうしているから。
技術用語は原則として直訳するものなのでもしも JIS が Rust の規格を成立させたとしてもたぶん境界と訳すと思う。

制約派は有名な会社 (オライリー) が出している書籍で制約という語をあてていることを根拠としていて、ボランティアグループよりプロの翻訳家のほうが信頼できると主張している。

**デフォルトの名無しさん** · 2025/03/24(月) 14:07:50.39

ボウンズでいいよ

**デフォルトの名無しさん** · 2025/03/24(月) 14:32:08.72

>>973
訳さずトレイトバウンドと呼ぶのが好ましいけど日本語化したければトレイト制約
トレイト境界は勘違いと理解不足から発生した間違った訳語なので避けたほうが良い

どの辺が間違っているかはこのスレを読み返してくれ

**デフォルトの名無しさん** · 2025/03/24(月) 14:34:35.04

屋根の色は青が正しい！

**デフォルトの名無しさん** · 2025/03/24(月) 15:34:03.20

>>977
誤爆してるよ
お大事に

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

>>971
生ポと比較する意味がないよ
確実に自動解放するための枠組み
例えばRcは複数の所有者が生じる時に使われて、どれが先に消えても最後に残った側が自動解放するんだよ
Cで同じことを実現しようとしたら同じく参照カウンタが必要
C++でも参照カウンタを用いてshared_ptrが作られてるよ

>>972
初期化を仮定しないMaybeUninitがRustにはあるから大丈夫
ライブラリ等ではこれを使って不要な初期化を避けているよ
0でのmemset呼び出しが消滅

973
trait boundsはトレイト境界だよ
英語でも敢えてconstraint (制約)を使っていない意義を尊重
トレイト境界により型のとれうる範囲が狭まって型の制限いわゆる型制約が生じるよ

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

ああこれって王様を尊重すると言いながら
戦争していいかどうかは王様に相談してないパターンか

**デフォルトの名無しさん** · 2025/03/24(月) 18:08:22.30

「制約」は渡す側の視点でしか見てないからな
受け取る側にとってはトレイトの「保証」でもある
ジェネリクス型を受け取る関数を自分で書かないレベルに合わせるなら
「制約」で意訳しても構わないと思う

**デフォルトの名無しさん** · 2025/03/24(月) 18:38:13.55

>>981
そのレベルの人が上達してきたときに用語を切り替えるなんてわけにもいかんし、
「この制約のことを Rust 用語ではトレイト境界といいます」とでも一言あればそれで済む話じゃね？

入門者向けの便宜的な説明が後々まで尾を引いて混乱することはあるから喩えとか意訳とかは慎重にしたほうが良いと思う。

**デフォルトの名無しさん** · 2025/03/24(月) 18:44:54.15

>>981
レベルの話じゃないんだよね

両方の視点をもつのはいいんだけど型シグニチャは使う方との契約だから
作る側じゃなく使う側の視点によせるのが自然
作る側の視点で見る回数よりも
使う側の視点で見る回数のほうが圧倒的に多いということもある

仮に受け取る側の視点から見たとしても
トレイトの「保証」だから「トレイト境界」とはならないよね

not satisfiedとかとコロケーションが確立されてるのも
rustcの開発陣もみんな制約として見てるからなんだよ

**デフォルトの名無しさん** · 2025/03/24(月) 18:49:17.73

プレート境界とか軍事境界とか～境界の日本語での使われ方を考えてみたら？

プレートとプレートの境目だからプレート境界
西側の軍事と東側の軍事の境目だから軍事境界

トレイトとトレイトの境目ならトレイト境界は日本語として用意に成立する
でも実際はそうじゃないから

**デフォルトの名無しさん** · 2025/03/24(月) 18:54:56.12

『制約』という完全に意味を間違えている言葉でなければ
『境界』より相応しい範囲を表す何らかの言葉でもいいと思うよ
混乱しないようにトレイト境界のままでもOK

**デフォルトの名無しさん** · 2025/03/24(月) 18:59:58.08

boundsの意味もtrait boundsの用法も範囲の限界を意味しているわけだから
範囲の限界はすなわち境界だよね
範囲の限界を表すもっと良い言葉があるかどうか

**デフォルトの名無しさん** · 2025/03/24(月) 19:09:34.08

Boundsが制約だと思うスレ

**デフォルトの名無しさん** · 2025/03/24(月) 19:28:44.61

まだやっていたのかw

これが本当の境界○能だったらどうしよう

**デフォルトの名無しさん** · 2025/03/24(月) 20:22:18.74

「よ」とか「ね」とかの終助詞付けても主張が激しいから全然柔らかくなってない
特有の違和感を常に感じさせる文体

**デフォルトの名無しさん** · 2025/03/24(月) 21:58:28.76

>>984
プレートの際だからプレート制約
軍事の際だから軍事制約では？

**デフォルトの名無しさん** · 2025/03/24(月) 21:59:18.18

>>988
制約知能でも意味が通じる不思議

**デフォルトの名無しさん** · 2025/03/24(月) 22:12:24.41

>>986
>範囲の限界を意味しているわけだから
何の範囲の限界？
そこも含めて考えないと質の低い機械翻訳と同じだよ

>範囲の限界はすなわち境界だよね
違う
日本語における限界と境界の違いを理解してない

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

日本語での意味なんかどうでもいいよ。
Rust コミュニティの先導者が境界ということにしたのだし、コミュニティの状況を調べなかったか分断しようとするオライリーの質が低いってだけ。

**デフォルトの名無しさん** · 2025/03/24(月) 22:40:56.78

レイトマジョリティ自覚して先人に敬意払っとけ

**デフォルトの名無しさん** · 2025/03/24(月) 22:43:00.79

ID:a0wY9RFfは所有権を複製しそうだね

**デフォルトの名無しさん** · 2025/03/25(火) 04:40:05.04

残り3レスで問題と慈善事業をを要約してくれ

**デフォルトの名無しさん** · 2025/03/25(火) 07:36:07.50

日本語訳プロジェクトを乗っ取って「トレイト制約」で統一すりゃいいんじゃないんかな。
日本語訳プロジェクトは最新版に追随できていないから文句言うやつは居ないだろ。

**デフォルトの名無しさん** · 2025/03/25(火) 07:40:07.85

そういや、誰か標準ライブラリの日本語訳してなかったっけ？
あれどうなった？

**デフォルトの名無しさん** · 2025/03/25(火) 08:50:43.64

トレイトの神様降臨

**デフォルトの名無しさん** · 2025/03/25(火) 08:51:04.90

継ぎ
https://mevius.5ch.net/test/read.cgi/tech/1742805420/

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 112日 10時間 18分 15秒