Rust part23

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 09/05 00:55 / Filesize : 257 KB / Number-of Response : 1014
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part23

1 名前：デフォルトの名無しさん [2024/02/23(金) 17:37:52.13 ID:CheDQupm.net]: 公式
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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/
142 名前：デフォルトの名無しさん [2024/02/27(火) 12:18:37.87 ID:Q3TDZDiV.net]: >>136
*selfはそれでいいけど、**selfはそれじゃ説明付かんぞ
143 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 17:59:37.59 ID:KfBq61Mu.net]: >>139
&T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない
144 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 18:12:58.39 ID:lr8nToMg.net]: Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？
Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・
145 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 18:13:56.86 ID:7nYMkiDR.net]: >>133
まず基本を理解しよう
deref coreceは必ず参照から参照へのみ起きる
Box自体は当然deref coreceされない

その例だと
let b = Box::new("Hello".to_string());
まずc0は単なるBox参照
let c0: &Box<String> = &b;
このc1とc2がderef corece
let c1: &String = &b;
let c2: &str = &b;

そのc1とc2を明示的に書くとこうなる
let c1: &String = &**(&b);
let c2: &str = &**(&**(&b));
この暗黙に適用される&**がderef corece

この自動適用のおかげでstrのメソッドが使える
assert!(b.starts_with("He"));
フルに書くとこうでもちろん対象はbではなく&b
assert!(str::starts_with(&b, "He"));
この&bが前述の通り自動的に&**(&**(&b))となり&str型へcoreceされている
146 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 18:33:30.42 ID:p5E54fv2.net]: >>141
圧縮アーカイブならzipクレート
圧縮ならlibflateクレートなど
147 名前：デフォルトの名無しさん [2024/02/27(火) 19:01:36.79 ID:MCZ6xJKz.net]: >>133
＞ coercion

横から素人がすまん、これ何て読めばいいの？
148 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 19:26:56.87 ID:kSGISY6y.net]: Rustもちょっと前の熱狂はなくなってしまった感じ
入込数が減ってると思う
149 名前：デフォルトの名無しさん [2024/02/27(火) 19:39:57.60 ID:ptyRkm62.net]: まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは
150 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 19:51:34.77 ID:gLAGJv50.net]: >>144
発音[US] kouə́ːrʒən ｜ [UK] kouə́ːʃən
カナ[US]コウアァジョン、[UK]コウアーション

参考：https://eow.alc.co.jp/search?q=coercion

自分はコアジョン派
151 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 20:18:10.37 ID:p5E54fv2.net]: >>144
コアーション派
152 名前：デフォルトの名無しさん [2024/02/27(火) 20:23:00.40 ID:20aYglde.net]: >>147
サンクス。愛してる
153 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 21:54:58.65 ID:Tx+RemT0.net]: Tのスマートポインタの参照 -> Tの参照
文字の配列の参照 -> 文字のスライス
一連の流れを見るとみんなポインタに熱狂している
154 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 22:22:03.42 ID:TDjpaGuA.net]: >>150
そこはポインタと参照の根本的な違いを理解しできるかどうかかな

「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが
「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ
したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる
だからスマートポインタの参照を渡すことになる
一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない
しかし参照＝ポインタではなく参照は抽象的なものなのだ
155 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 22:43:38.35 ID:NfALWDmT.net]: Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。
C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、
参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。
156 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 22:57:53.18 ID:FQe9Y4YD.net]: その橋渡し役がDeref coercion
&Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが
Box<T>→TのDerefがあるため
&Box<T>→&TとDeref coercionが適用できる
静的にコンパイル時点で行われるため実行時コストはかからない
157 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:09:15.00 ID:xLBlGeUv.net]: >>142
この辺り最初理解するまで訳分からんかったな
理解すると大したことはないのだが
158 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:37:04.57 ID:IkmURqSK.net]: >>142
>deref coreceは必ず参照から参照へのみ起きる
&**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね

それは別にいいんだけど書いてる内容を見る限り
Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく
実際に&**が適用されると思ってるみたいに感じるね
だとしたらそれは完全な間違い

derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ
Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし
159 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:45:58.16 ID:Tx+RemT0.net]: とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね
160 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:58:10.03 ID:cJjIIFX3.net]: Derefは*
Deref coercionは&**
前者は明示が必要な点が違い

x: &Box<T> とすると
*x: Box<T>　(by Deref &T→T)
**x: T　(by Deref Box<T>→T)
&**x: &T　(xのDeref coercion結果)

x: &Vec<T> とすると
*x: Vec<T>　(by Deref &T→T)
**x: [T]　(by Deref Vec<T>→[T])
&**x: &[T]　(xのDeref coercion結果)

x: &String とすると
*x: String　(by Deref &T→T)
**x: str　(by Deref String→str)
&**x: &str　(xのDeref coercion結果)
161 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 00:29:07.11 ID:ZZ90UZAT.net]: >>157
とりあえずDerefの定義が

pub trait Deref {
type Target: ?Sized;

// Required method
fn deref(&self) -> &Self::Target;
}
（https://doc.rust-lang.org/std/ops/trait.Deref.html）

でderef()の戻り値には自動的に&がつくから
*x: Box<T>
*x: Vec<T>
*x: String
はDeref traitと関係ないことを抑えておこう
そこに（by Deref…）を書かれると話がおかしくなる

*Tができることの一部をDeref traitではできない
正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない
162 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 00:41:03.68 ID:PK7EwTQ6.net]: こうだろ

x: &Box<T> とすると
*x: Box<T>　(by Dereference)
**x: T　(by Deref Box<T>→T)
&**x: &T　(xのDeref coercion結果)

x: &Vec<T> とすると
*x: Vec<T>　(by Dereference)
**x: [T]　(by Deref Vec<T>→[T])
&**x: &[T]　(xのDeref coercion結果)

x: &String とすると
*x: String　(by Dereference)
**x: str　(by Deref String→str)
&**x: &str　(xのDeref coercion結果)
163 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 00:49:10.38 ID:ZZ90UZAT.net]: なんかゲシュタルト崩壊してきたんだがｗ

関係ないけど微積のdxとかdyを思い出してしまった
164 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 01:22:37.90 ID:0HAFGBLs.net]: C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ
165 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 01:32:01.63 ID:upo0sX/6.net]: Deref coercion &**のうち
右側の*は参照に対する参照外しで
左側の*はDerefで定義(実装)されてるものなのね
166 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 04:46:46.07 ID:EOw65cJZ.net]: let s = String::from("xyz");
let x: &str = &s;
let x: &str = &&s;
let x: &str = &&&s;
これ全てコンパイル通ってderef coercionされるから
『by Deref &T→T』も適用されていると思うぞ
167 名前：デフォルトの名無しさん [2024/02/28(水) 11:30:56.58 ID:eNJqE6SH.net]: >>163
&&T→&Tのことを&T→Tとは書かないわな
前者の用途にDeref for &Tは存在してる
168 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 17:44:48.30 ID:8gSKFNHr.net]: >>156
演算の名前はdereference
derefはDerefトレイトに定義してあるメソッドの名前

>>157
>Derefは*
違う
Derefはトレイト
*はdereference operator

>Deref coercionは&**
違う
Deref Coercionとはcoercionが行われる場合に「&Tを&<T as Deref>::Target」にcoerceすること
Deref Coercionと*などの演算子は全く別の独立したものとして扱われている
それぞれの処理の一部で必要に応じてDerefに定義されたderefメソッドを活用してるというだけ
片方がもう片方に依存してたりもしない

Deref Coercionの処理の一部として呼び出されるderefメソッドを
演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが
前述のように定義が循環してるだけでなく再定義する価値を見いだせない
169 名前：デフォルトの名無しさん [2024/02/28(水) 18:08:21.49 ID:8fminEVJ.net]: なるほどね。勉強になるわ。
170 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:17:32.89 ID:8gSKFNHr.net]: >>164
&&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない？
171 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:20:50.27 ID:nghz9NTX.net]: >>164
Deref coercionの定義を理解しよう
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
&String→&str　(by Deref String→str)
&Vec<T>→&[T]　(by Deref Vec<T>→[T])
&Box<T>→&T　(by Deref Box<T>→&T)
&&T→&T　(by Deref &T→T)
これらはすべてDeref coercion
172 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:22:38.09 ID:nghz9NTX.net]: >>165
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される

U＝*T
↓　&Tから出発すると
U＝**(&T)
↓　両辺の参照をとると
&U＝&**(&T)
つまり
Deref coercionとは&**の自動適用のこと
173 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:49:11.26 ID:T3/1RdIi.net]: *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている
174 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 19:13:20.58 ID:fjfA+uEG.net]: >>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない
175 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 20:06:21.19 ID:ZLPgyFVM.net]: 判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？
176 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 20:12:51.73 ID:eWXh2LH7.net]: これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか
177 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 21:00:40.37 ID:ZLPgyFVM.net]: これが分かりやすいと思ってる人間には聞いてないよ
178 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 21:10:22.04 ID:RYfxXFlC.net]: 他の言語でこれより良いものが存在しないね

RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作
179 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 23:39:05.31 ID:T3/1RdIi.net]: >>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ
180 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 23:49:09.85 ID:ZZ90UZAT.net]: Derefなのに&が消えてない（小並感）

背景を理解しないと引っかかりやすいRustの七不思議候補
181 名前：デフォルトの名無しさん [2024/02/29(木) 01:04:43.74 ID:rccXx8PF.net]: この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性

このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿
182 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 01:16:58.91 ID:s7mEAt1S.net]: この仕組みがない方が良いということ？
下手で全部書くべきと？
183 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 01:51:37.80 ID:zTVrVDmh.net]: RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される

これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも
184 名前：デフォルトの名無しさん [2024/02/29(木) 03:43:48.10 ID:JSOAwYd/.net]: https://manishearth.github.io/blog/2017/01/10/rust-tidbits-box-is-special/
Boxのまほう
185 名前：デフォルトの名無しさん [2024/02/29(木) 10:19:46.23 ID:IetxPnTw.net]: >>179
>下手で全部書くべきと？
どこかの方言？
186 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 12:07:39.99 ID:/e0OxROz.net]: >>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。
187 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 12:33:18.56 ID:sM99e4qp.net]: Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？
188 名前：デフォルトの名無しさん [2024/02/29(木) 12:41:20.92 ID:JSOAwYd/.net]: そんなに比較したいならﾜｯﾁｮｲスレ行けばいいんじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1701997063
189 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 13:11:40.55 ID:WGw1+Mi1.net]: 検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能
190 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:11:14.15 ID:s7mEAt1S.net]: >>182
この仕組みがない方が良いということ？
191 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:14:12.31 ID:s7mEAt1S.net]: 単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし
192 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:15:14.41 ID:s7mEAt1S.net]: 誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない
193 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:15:53.86 ID:s7mEAt1S.net]: 全く相手にすべき人間ではないと判断する
よって今後無視する
194 名前：デフォルトの名無しさん [2024/02/29(木) 14:45:30.61 ID:NVSKcdtL.net]: >>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない
195 名前：デフォルトの名無しさん [2024/02/29(木) 14:51:42.06 ID:bXdMb/7T.net]: 技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂
196 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:52:32.46 ID:sM99e4qp.net]: Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？
197 名前：デフォルトの名無しさん [2024/02/29(木) 15:05:04.64 ID:Sa1lr1bM.net]: >>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう
198 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 17:17:49.66 ID:WGw1+Mi1.net]: 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか
199 名前：デフォルトの名無しさん [2024/02/29(木) 17:44:22.90 ID:JSOAwYd/.net]: や、そもそも「人の心」の認識が無いのだろう
200 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 18:01:07.55 ID:OWFCi11w.net]: わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな
201 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 18:25:15.72 ID:uwbVoB9N.net]: >>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった
202 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 18:37:38.45 ID:OsB1rmqt.net]: ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど
203 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 20:49:33.50 ID:NE3ms/ho.net]: impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど
204 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 23:55:24.58 ID:uwbVoB9N.net]: >>199
*演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ
205 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 08:46:23.47 ID:SBTwWOM0.net]: derefの仕方は状況によって使い分けかな
例えばVec<T>からスライス&[T]にする場合

// deref operatorを使う方法
// 一番短く頻出
let slice = &*vec;

// RangeFull Indexを使う方法
// Rangeを変えて汎用的に範囲指定ができるメリット
let slice = &vec[..];

// deref coercion先の型を明示する方法
// 関数呼び出しは引数の型が明記されてるのでこのパターン
let slice: &[T] = &vec;

// deref()メソッドを使う方法
// ただしDerefトレイトのuseが必要
use std::ops::Deref;
let slice = vec.deref();
206 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 09:18:59.78 ID:LWQ/+31h.net]: uv、めちゃ速いな
今までの処理時間はなんだったのか
これはRustの印象を良くするツールになるわ
207 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 10:14:36.96 ID:gvn/awFT.net]: uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが
そのuvはRust製のPythonパッケージマネージャーなのか
208 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 11:06:37.60 ID:C9bgbnyF.net]: 速さの定義はわかりやすさの定義よりもわかりやすい
209 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 16:15:12.75 ID:lzR4RBgp.net]: JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速
210 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 19:02:46.24 ID:I+/u+ffT.net]: Pythonの管理ツールまたなんか出たの！？という気分
211 名前：デフォルトの名無しさん mailto:sage [2024/03/02(土) 00:14:54.94 ID:F+x2UUkM.net]: uvはPython版のcargoを目指しているらしい
212 名前：デフォルトの名無しさん [2024/03/02(土) 16:13:07.16 ID:bMlzFBHT.net]: nvidiaのど汚なさを理解してなさげで不安しかないわ
213 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 04:09:58.03 ID:n3bQlkHC.net]: RustでDB使う時の定番ライブラリって何ですか？
214 名前：デフォルトの名無しさん [2024/03/05(火) 04:14:48.62 ID:nMHII26b.net]: ORMが好きならdiesel
ORMが嫌いならsqlx
215 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 06:15:07.43 ID:Uplx2IYd.net]: >>211
それRDBじゃん
216 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 11:41:51.93 ID:6drsihdZ.net]: RDBじゃないDBの定番とか聞かんだろJK
217 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 12:54:04.64 ID:iKkb/Eo4.net]: RDBMSが定番だからね。
218 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 23:56:12.66 ID:blmx074I.net]: 最近RDB以外のDBの存在を知った人にありがちな反応だよな
219 名前：デフォルトの名無しさん mailto:sage [2024/03/07(木) 15:14:21.16 ID:/no0RfP4.net]: Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな
220 名前：デフォルトの名無しさん mailto:sage [2024/03/07(木) 15:28:53.82 ID:5c4tHUTp.net]: しゃぶれよ
221 名前：デフォルトの名無しさん mailto:sage [2024/03/07(木) 17:13:51.21 ID:NLgNYFMG.net]: >>216
Rust for Rustaceans
222 名前：デフォルトの名無しさん [2024/03/10(日) 13:14:05.30 ID:XsimGsv7.net]: Rustはデフォルトのhashが遅いという罠
223 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 20:35:08.28 ID:8NU5B5F+.net]: >>219
Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全
もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる

type Hasher = std::hash::BuildHasherDefault<FxHasher>;
let mut map = HashMap::<Foo, Hasher>::default();
224 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 20:38:28.49 ID:8NU5B5F+.net]: こうね
HashMap::<Key, Value, Hasher>
225 名前：デフォルトの名無しさん [2024/03/10(日) 21:21:36.22 ID:yMMzzxd+.net]: 解決案としてはそうなのだが、デフォルト挙動が罠すぎる
デフォルトいらなかったのでは
226 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 21:26:04.39 ID:hwVh1yHa.net]: Rustは利用者はアホだと思ってる
だから徹底的に厳しくしてくる
227 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 21:33:53.98 ID:hwVh1yHa.net]: 雨が降ってなくても傘を持つように言って来て外出すらさせてくれない
228 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 00:11:06.91 ID:H3LWtGm6.net]: デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ？
そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし
まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが
229 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 00:47:18.65 ID:2r+51Qz1.net]: Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし
逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし
この2種類のトレイトを標準で用意してくれているRustは非常に好環境
230 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 00:59:26.53 ID:lga6QF6v.net]: 「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。
状況に合わせて選択できたり自分で作れたりする人はそうするんだから、
デフォルトではそうでない人を想定するだろ。
231 名前：デフォルトの名無しさん [2024/03/11(月) 02:43:53.87 ID:aDyedTxf.net]: いやそもそもデフォルトいらんくね？
なんでデフォルト欲しいんだ？
232 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 11:06:00.19 ID:WfvY/WS3.net]: 掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ
233 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 11:06:34.84 ID:WfvY/WS3.net]: 誤爆した！
234 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 14:30:36.32 ID:emAmKvKR.net]: デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな
rustの場合は何事も「安全」に基づいて設計されてると認識してる
235 名前：デフォルトの名無しさん [2024/03/11(月) 15:25:18.07 ID:WOvDUzj/.net]: 適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな
ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない

HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな
236 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 19:01:47.22 ID:srElBTmD.net]: HashMapで使われるHashに重いものを使う必要がある局面は限られてる
でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう
237 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 20:05:38.98 ID:3y0FGSJo.net]: 僕が美少女とセックスするためのプログラムはRustで作れますか
238 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 21:13:52.07 ID:2r+51Qz1.net]: >>233
ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい
用途により異なるならば安全側に倒すか指定する方法を提供すればよい
239 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 21:28:56.93 ID:vmVry2mm.net]: とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？
Rustだとなんか問題あるんだっけ？
240 名前：デフォルトの名無しさん [2024/03/11(月) 21:31:16.84 ID:aDyedTxf.net]: >>236
ライブラリのハッシュを差し替えられない
デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく
241 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 21:41:07.80 ID:6xtSsnXH.net]: ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい
そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい
RustコンパイラもFxHashを用いている
https://github.com/rust-lang/rustc-hash
242 名前：デフォルトの名無しさん [2024/03/11(月) 21:44:11.78 ID:uBu+z/S9.net]: 安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ
これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ
243 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 22:02:54.43 ID:2hCRIQro.net]: 言語とは関係ない
外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須
そうでない部分には攻撃耐性は必要ない
各プログラムの中にこれら両者はは共存しうる
この使い分けができているかどうかは各言語の問題ではない
244 名前：デフォルトの名無しさん [2024/03/11(月) 22:17:15.26 ID:1Ss4PFRT.net]: ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる
やはりエコシステムやそこにある資産も含めての言語の評価だろう

それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる
245 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 22:22:30.50 ID:2hCRIQro.net]: >>241
C++だけでなくスクリプト言語であろうがすべて同じ
攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム
246 名前：デフォルトの名無しさん [2024/03/11(月) 22:24:26.89 ID:1Ss4PFRT.net]: >>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ
247 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 22:32:51.13 ID:Zfy+Gd54.net]: >>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？
248 名前：デフォルトの名無しさん [2024/03/11(月) 22:38:01.21 ID:1Ss4PFRT.net]: >>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か
249 名前：デフォルトの名無しさん [2024/03/11(月) 22:39:37.27 ID:1Ss4PFRT.net]: スクリプト言語だと速度は求められないという了解があるし
250 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 22:53:49.00 ID:lga6QF6v.net]: Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。
251 名前：デフォルトの名無しさん [2024/03/11(月) 23:24:30.57 ID:pnxYU4a7.net]: あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい

この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切

Rustはこの適切な仕様となっている
252 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:26:28.61 ID:srElBTmD.net]: 雨の降らない日に傘をさしてるのがRust
253 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:31:49.34 ID:srElBTmD.net]: 外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust
254 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:39:22.87 ID:H3LWtGm6.net]: 雨が降る日のためにいつでも傘をさしてるだけだろ…
255 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:47:29.47 ID:1gRl0SR3.net]: デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う
256 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:47:55.83 ID:eCeLdHKW.net]: >>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよ
257 名前：い いやーそれはどうだろう？ ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？ stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切 []: [ここ壊れてます]
258 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:55:39.88 ID:srElBTmD.net]: hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明
259 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 23:59:34.73 ID:o1bdd8gz.net]: Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？

Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？

さらにRustの標準ライブラリはなるべく小さくする方針ね
260 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:02:16.02 ID:YqCvYydB.net]: >>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない

重いハッシュ関数がデフォルトになってるのがどうなのかと言う話
261 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:06:26.32 ID:hhdv8qp2.net]: 普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？
262 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:07:45.67 ID:YqCvYydB.net]: 攻撃の可能性のある部分をチューンナップ
263 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:10:05.78 ID:hhdv8qp2.net]: >>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん
264 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:10:10.84 ID:YqCvYydB.net]: 江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった
265 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:11:17.84 ID:YqCvYydB.net]: >>259
攻撃されないのに攻撃態勢をつける馬鹿
266 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:13:45.61 ID:c71xUORt.net]: みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ
267 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:15:25.47 ID:YqCvYydB.net]: IDコロコロ全肯定君

攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする

そもそもその人が設計ミスってるんだろう
268 名前：デフォルトの名無しさん [2024/03/12(火) 00:15:58.38 ID:ltF5NefG.net]: SafeSlowHashMapみたいな名前にすれば良いのに
269 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:16:19.18 ID:YqCvYydB.net]: >>264
少なくともこれかな
270 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:27:26.16 ID:hEPMmb8p.net]: >>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する
271 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:32:47.44 ID:YqCvYydB.net]: >>266
HashMap::new()すらしたことないのかな？
272 名前：デフォルトの名無しさん [2024/03/12(火) 00:33:47.12 ID:P8rBcnCc.net]: >>266
誰もそんな話してないやろ
これだから複クンは
273 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:35:30.45 ID:YqCvYydB.net]: こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ
いつもおかしなことを言ってる
274 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 00:36:58.41 ID:4FnCuSr/.net]: ripgrepとかuvとかの既に実用が始まってるRust製アプリでは
デフォルトのハッシュ関数使ってるの？
275 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 01:00:19.76 ID:hEPMmb8p.net]: >>267
やっぱりRustを使ったことないんだな
impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため
HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う
276 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 01:04:13.79 ID:YqCvYydB.net]: ほらこんな壊れたレスしかできないんだよ
脳が死んでる
277 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 01:05:51.45 ID:YqCvYydB.net]: 常に論点ずらし
何の生産性もない
278 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 01:42:25.91 ID:O5aTP+Ks.net]: いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ
279 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 09:25:30.86 ID:2ftxmqwc.net]: 「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる
280 名前：デフォルトの名無しさん [2024/03/12(火) 15:42:43.44 ID:qP6Ph9LT.net]: 『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い
281 名前：デフォルトの名無しさん [2024/03/12(火) 16:02:50.20 ID:O51IPiXd.net]: ほんとどうでもいいな
自転車置き場というより豚小屋の議論
282 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 16:28:46.76 ID:6k71yQCv.net]: プログラムしかしない人はこういうことしか考えることがないんよ
283 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 17:33:47.15 ID:+dm3OZRm.net]: 知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。
284 名前：デフォルトの名無しさん [2024/03/12(火) 18:00:43.49 ID:ZUpYWJV7.net]: デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな
285 名前：デフォルトの名無しさん [2024/03/12(火) 18:49:06.95 ID:hIsWcrJS.net]: >>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね
286 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 18:51:51.27 ID:wv71s4mp.net]: 弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。
287 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 19:50:55.41 ID:WtXn1sYk.net]: 攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。
288 名前：デフォルトの名無しさん [2024/03/12(火) 19:59:05.75 ID:1eKk9IjK.net]: >>283
同意
289 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 20:00:13.63 ID:uVbV4a/I.net]: RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる
290 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 20:49:08.64 ID:NxLZ8TT6.net]: Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ
291 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 20:49:29.65 ID:+yrdVDIt.net]: 他の言語たちがRustを参考に同じように後追いしているのね

＞Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。
＞その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。
＞Rust や Ruby からは数年遅れましたが、Pythonもデフォルトの文字列ハッシュアルゴリズムがSipHash13に切り替わりました。
292 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 20:56:37.07 ID:Bo/PtDeL.net]: >>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている
293 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 22:08:56.94 ID:qGjx1B49.net]: >>274
人にキチガイと言う前に自分の脳を使って考えたら？

どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ
294 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 22:13:42.86 ID:qGjx1B49.net]: Python　Ruby　スクリプト系言語
295 名前：デフォルトの名無しさん mailto:sage [2024/03/12(火) 22:30:53.75 ID:QLhbtBPI.net]: 他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹
296 名前：デフォルトの名無しさん [2024/03/13(水) 01:06:52.67 ID:l12NsVZP.net]: 他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう
297 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 01:36:16.81 ID:yq4Sx3eg.net]: Swiftも同じSipHash13だよ
298 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 06:48:44.81 ID:vtWyM3VT.net]: >>292
じゃあRustの思想は？
299 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 07:26:54.50 ID:W15vpPlq.net]: >>283
判断できない人まで言語側で救う必要性が分からない。

それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。
300 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 08:05:27.17 ID:7ftIQ2tM.net]: 必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？
301 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 11:53:59.71 ID:k71lJTPU.net]: 安全と速度は両立するかそれともトレードオフか
トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね
有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない
302 名前：デフォルトの名無しさん [2024/03/13(水) 13:08:21.45 ID:zcdQDtji.net]: Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな
賢いならRustなんかやらない
303 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 13:52:10.04 ID:k71lJTPU.net]: 自由があればデフォルト設定を強制されないのは自明な事実
ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか
そもそも「所有している」というのはただの感想なのか客観的事実なのか
304 名前：デフォルトの名無しさん [2024/03/13(水) 15:08:41.44 ID:EtYMYlMl.net]: アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな
305 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 17:12:52.60 ID:2jYqKDsd.net]: 本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。
5chでRust使ってるって言ってるやつらはそんなもの
306 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 17:32:48.34 ID:k71lJTPU.net]: 不毛の判断が早いなあ
後世の歴史家が判断するという定型文に縛られないから早いんだな
307 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 17:40:34.76 ID:EfEhvhMh.net]: 安全と速度を両立させたのが
RustやPythonなどが採用しているSipHash13
308 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 18:38:09.42 ID:9N462qty.net]: >>295
いや、unsafeは判断できる人が使うものだろ。
309 名前：デフォルトの名無しさん [2024/03/13(水) 21:22:31.53 ID:cNV/vVTe.net]: >>300
分かってるんならﾜｯﾁｮｲ付きRustスレの盛り上げに協力してくれんかえ
310 名前：デフォルトの名無しさん [2024/03/13(水) 21:54:19.69 ID:Ay/UTMuM.net]: ワッチョイなんか盛り上がる訳ねえ
そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的
311 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 22:31:42.96 ID:/twoPXVD.net]: 高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話
312 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 22:39:35.15 ID:vtWyM3VT.net]: 30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ
313 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 22:42:16.17 ID:6IE1D2aF.net]: 出世出来ましたか？
314 名前：デフォルトの名無しさん mailto:sage [2024/03/13(水) 22:52:25.45 ID:/twoPXVD.net]: 能力が低下してコーディングできないのとしないのでは大違い
315 名前：デフォルトの名無しさん mailto:sage [2024/03/14(木) 00:41:25.89 ID:2hurvpo9.net]: 結局スクリプト言語で書かれた原作が必要か
他のジャンルでも原作なしのオリジナルは難しそうだろう
316 名前：デフォルトの名無しさん mailto:sage [2024/03/14(木) 12:30:54.13 ID:HuCxvvOv.net]: Rustで書き直してパフォーマンスが上がったので注目浴びる！みたいなプロダクトはなんか白けるよな。
JSとかPythonの基盤ツールをRustで書き換えて激速！みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。
317 名前：デフォルトの名無しさん [2024/03/14(木) 12:34:38.63 ID:GaNa4vYx.net]: 日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。
318 名前：デフォルトの名無しさん mailto:sage [2024/03/14(木) 13:45:31.80 ID:zTrHTca+.net]: おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。
歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて
速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。
(それは C++ で書かれてるんだけどね。)
商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。
リンカを作ってるところはこぞって高速化に努めた。
リンカ以外にもその機運が波及しているのが今。

で、高速化のキモはデータ構造であるというのが明瞭になったんだけど
メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。
Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。
319 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 00:47:31.57 ID:eu7fnAy5.net]: コードを書けない
プログラムできなくなるとこういうことしか書けなくなると言う見本
320 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 10:43:30.71 ID:5CgUbd5q.net]: だが読むより書くほうが優れているという前提から
原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる
321 名前：デフォルトの名無しさん [2024/03/15(金) 11:53:24.75 ID:94MXVgRN.net]: 春だなぁw
322 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 18:26:51.96 ID:5N0PtL1J.net]: ai bot
323 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 20:40:42.93 ID:W8LQpOAr.net]: >>315
辛辣で草
そういう似非技術者系おじいちゃんおちょくると
怒って自分が唯一知ってる知識振り回してくるから面白いぞ
324 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 21:07:06.30 ID:8+Y0uCh5.net]: Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい
ここはRust専用スレ
325 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 21:26:31.60 ID:PnOJWcC7.net]: コーディングが出来なくなると人生はつらいと思うけどな…
326 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 21:36:49.30 ID:3GkeGGWK.net]: できなくなるんじゃなくて
元々できてないんよね>>314みたいな人は
というより単に職業マじゃないのかもな
趣味でプログラム触ったことあるパソコン少年的な
327 名前：デフォルトの名無しさん mailto:sage [2024/03/16(土) 00:23:32.44 ID:/iia2JvS.net]: 人はいつか何もできなくなって死んでいくんだよな
つまらないね
328 名前：デフォルトの名無しさん mailto:sage [2024/03/16(土) 08:54:22.01 ID:aeWu0EgX.net]: 肉屋がレッドオーシャンになれば豚はブルーだからこれでいい
329 名前：デフォルトの名無しさん [2024/03/17(日) 19:33:58.02 ID:1VtyMVPz.net]: Rust書けるやつ集めるの大変すぎ
330 名前：デフォルトの名無しさん mailto:sage [2024/03/17(日) 22:06:35.75 ID:BMZldfUE.net]: Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな
ただしまともなプログラマーしか使い　　こなせない
331 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 09:59:50.17 ID:ySp1yGcK.net]: むしろ変なやつしか使ってない感じだけど…
332 名前：デフォルトの名無しさん [2024/03/18(月) 10:20:48.83 ID:JObkxwF0.net]: しょーもないこだわり持ってるやつしか使ってない
333 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 13:49:12.09 ID:lCCxn1Q7.net]: 今後の仕事考えたらRustだね
334 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 14:26:36.03 ID:1+ObkRXf.net]: メモリ安全性ってなんなの？
335 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 14:49:59.91 ID:RRSB5dTk.net]: 無効なアドレスを参照しない
運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる

無効なアドレスを更新しない
運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる

メモリリークは割とどうでもいい
336 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:00:45.39 ID:ZJ4hMg34.net]: >>330
メモリ安全性のうち特に重要な一つがメモリ競合の安全性
まだ使っている値を意図せずに書き換えてしまい矛盾してしまう
プログラミングで起こるバグの代表的な一つ
Rustではこれを防ぐことができる []; [ここ壊れてます]
338 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:02:35.53 ID:1+ObkRXf.net]: >>331
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました……
339 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:07:28.37 ID:1+ObkRXf.net]: >>332
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね…
340 名前：デフォルトの名無しさん [2024/03/18(月) 18:35:36.34 ID:utey1W8X.net]: セルフコントならもう少し面白いやつを頼む
341 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 01:19:02.24 ID:6E76csi8.net]: WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。
ttps://www.security-next.com/154875
342 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 05:37:59.51 ID:wTR4SIFK.net]: デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。

2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。
パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。
343 名前：デフォルトの名無しさん [2024/03/20(水) 12:50:32.15 ID:/slJg93x.net]: >>336
そういうのRust関係ないからわざわざここに書かなくてもいいよ
344 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 13:00:27.22 ID:3fTCja3E.net]: 関係無いわけないでしょｗ
rustで書かれてたら安全なんじゃなかったん？ｗ
345 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 13:48:07.28 ID:i9d3tzeg.net]: ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ
346 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 14:22:40.25 ID:HLjoI2yW.net]: これは「メモリ安全」の外の話？中の話？
347 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 16:11:18.74 ID:sC/F3tDJ.net]: unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない
348 名前：デフォルトの名無しさん mailto:sage釣 [2024/03/20(水) 16:33:56.60 ID:pz7pPV/0.net]: jsonの方も？
349 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 17:50:49.65 ID:w9jt/Hdz.net]: コード見てみたが言語関係なくダメな書き方の見本ってだけだな
ttps://github.com/wasmi-labs/wasmi/commit/f7b3200e9f3dc9e2cbca966cb255c228453c792f
ttps://github.com/wasmi-labs/wasmi/blob/v0.31.0/crates/wasmi/src/engine/stack/values/mod.rs#L158-L163

修正コードは毎回境界チェックしてるのと同じ
extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない
350 名前：デフォルトの名無しさん [2024/03/20(水) 18:13:46.74 ID:ASk8Mk2n.net]: extendという名前も実体と違ってバクの素
351 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 18:19:15.64 ID:sC/F3tDJ.net]: 修正コードはhotfixでしょ
masterブランチの方は結構手が入ってると思う
352 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 18:27:22.61 ID:ihbrcjwp.net]: その知識やスキルを活かして出世して欲しい
353 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 20:04:41.25 ID:TrbgWl+Z.net]: ダメな書き方でもコンパイルが通れば安全なはずなのではｗ
354 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 20:32:22.01 ID:sC/F3tDJ.net]: んなこたない
ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる
355 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:05:26.83 ID:CBfowBe/.net]: 直接の原因はunsafeなメソッドをsafeメソッドにしたこと
unsafeのsafe wrapperの質は大事
今のコードもunsafeの使い方が怪しくて信頼できない

fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue {
debug_assert!(index < self.capacity());
// Safety: This is safe since all wasmi bytecode has been validated
// during translation and therefore cannot result in out of
// bounds accesses.
unsafe { self.entries.get_unchecked_mut(index) }
}
356 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:39:19.40 ID:t5wrhqh7.net]: >>350
俺んとこもそのコードはよく書くけれど
今回の敗因は引数のindexが生のusizeであること
そこをusize直接ではなくそのラッピングの専用型にする
そしてその専用型が動く範囲が必ず範囲内であることを保証する形で
get_uncheckefのunsafeを使う関数をsafeに仕上げる
357 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:05:54.93 ID:QWnK+qvS.net]: unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？
358 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:57:12.18 ID:7RDAu5V5.net]: 全然そういう事

Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい
359 名前：デフォルトの名無しさん [2024/03/21(木) 20:09:58.67 ID:gM/gTjZ5.net]: >>353
それ言うなら

無闇に「ヤバい」を使うぐらいヤバい

じゃね
360 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:26:53.11 ID:1l7zk65j.net]: 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！
361 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:28:39.30 ID:7RDAu5V5.net]: >>354
それだと単なる自己言及だから352に対する答えとして不十分では
362 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:45:04.06 ID:t5wrhqh7.net]: 少なくとも>>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる
363 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:05:14.02 ID:7RDAu5V5.net]: NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイムで条件と関連付けるのも限界がある

結局テストパターン増やしてdebug_assert踏むしかない
364 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:44:37.76 ID:t5wrhqh7.net]: >>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる
365 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:18:44.86 ID:cOunjWn7.net]: unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです
366 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:27:42.27 ID:WuGieKPN.net]: 結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど
367 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:07:15.31 ID:7RDAu5V5.net]: unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない
368 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:12:07.53 ID:v/mpoJJ8.net]: >>361
unsafeを使わなれば自動的に安全が保証される
unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される
C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない
369 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:22:25.34 ID:WuGieKPN.net]: いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど
370 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:58:23.31 ID:z414Bs3I.net]: > Rustであれば安全と思ってる人が多そう

いや一応言っとくけど多くはないよ流石にｗ
一部の人が連呼してるだけ
ほかの人はもっと現実的だろな
371 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:21.08 ID:t5wrhqh7.net]: 原則はunsafeを使うな！
これだけだ

理解できていてunsafeを使う場合も
とにかく閉じ込めろ！
専用のクレートを作れ
専用のモジュールを作れ
専用の型を作れ
372 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:51.15 ID:XJ9dJAV6.net]: unsafe使わなければ安全
373 名前：デフォルトの名無しさん [2024/03/22(金) 09:16:28.77 ID:IQ7X1X+j.net]: まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。
374 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 10:19:34.77 ID:avPqaarP.net]: ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。
チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。
そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ……
普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。
375 名前：デフォルトの名無しさん [2024/03/22(金) 11:58:26.79 ID:7Rs7masV.net]: >>358
0～127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど

サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本
それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない
>>359のやり方はそれができてないように感じる
376 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 12:34:01.41 ID:TbCMvv+/.net]: 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える
377 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:04:42.65 ID:ZrfX32kv.net]: Rustは失敗言語
378 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:10:55.04 ID:ceR9yHkM.net]: 今回の件でRustの安全性が確実になったのが興味深いよな
アンチが必死に探してきた問題も>>350でunsafe利用だった
379 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 16:00:31.63 ID:JqYXTM4B.net]: >>371
「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど
実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ
unsafeにする意味がない
380 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 17:14:19.13 ID:vuLWDWdh.net]: >>374
実行時コストをかけないためにget_uncheckedを使うのが一般的
その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)
381 名前：デフォルトの名無しさん [2024/03/22(金) 19:27:28.32 ID:G6tKD1fj.net]: Adaなら特定の範囲の型作れるみたいよ
382 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 20:07:18.97 ID:vuLWDWdh.net]: 今回は範囲が固定ではなく変わり得る
383 名前：デフォルトの名無しさん mailto:sage [2024/03/23(土) 23:29:45.64 ID:eeq00BcS.net]: 誰にでもunsafeが使えてしまうのが問題なのでは？
原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。
384 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 00:34:36.37 ID:iaJ2USO3.net]: Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。
まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。
385 名前：デフォルトの名無しさん [2024/03/24(日) 10:55:06.56 ID:UXqlkypu.net]: >>375
「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350の引数のindexをその型に変えたところでsafeにしたらダメだよ
386 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 11:08:34.82 ID:BHU0SFkf.net]: なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？
387 名前：デフォルトの名無しさん [2024/03/24(日) 11:48:11.45 ID:uu8/yG2s.net]: indexの境界チェックが律速になるようなコード書いてみてえな
388 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 20:37:14.59 ID:YsO86RjG.net]: >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー　配列もその範囲指定で自由に作成できる。
389 名前：デフォルトの名無しさん [2024/03/24(日) 20:45:58.90 ID:Rrl8qRWO.net]: >>383
定数じゃなければ結局実行時にチェックするってことだよね
390 名前：デフォルトの名無しさん [2024/03/25(月) 01:12:47.74 ID:yMlw6u5B.net]: >>384
新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。
391 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 07:21:41.59 ID:CNajD+3j.net]: >>384 何十年も前なのですまそ
array(-2)とかarray(6)をアクセスしたら例外発生　array(-1)はOK

type Month is range 1..12
type Month_Array is array(Month) of Integer;
ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12);

for m in ma'first..ma'last loop // カウンタは1から12
ma(m) = m;
end loop;
392 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 14:37:28.19 ID:x/lXcXel.net]: 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど
そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね
393 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 16:23:44.40 ID:9GDk/VLW.net]: How much does Rust's bounds checking actually cost?
https://blog.readyset.io/bounds-checks/
394 名前：デフォルトの名無しさん [2024/03/25(月) 17:27:16.04 ID:MT/jL+52.net]: こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。
問題は浮動小数の取り扱いだっての。
395 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 21:23:48.62 ID:x/lXcXel.net]: unsafeは可能な限り避けるべきで
safe Rustでの改善をまずすべき
その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える

現実にはsafe Rustでの改善ができてないことが多い
例えばよく見かける例としては
iが動いていくのにa[i]でアクセスしてしまう
これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern
参照(ポインタ)化することで範囲checkを1回に減らせる
396 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 15:06:55.14 ID:g9hYSxJr.net]: unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね

unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事
397 名前：デフォルトの名無しさん [2024/03/27(水) 15:29:03.70 ID:pFQTMi8v.net]: 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」
が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので
398 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:02:47.08 ID:BwG0n/Az.net]: unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。

unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？
399 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:59:36.71 ID:LwoOYerE.net]: >>393
そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。
400 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:05:39.09 ID:6Vj8sISV.net]: >>392
センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ
今はそれが全然できてないから>>350のような基本的なミスを犯すやつが後を絶たない
401 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:08:09.55 ID:6japDZ8y.net]: windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。
402 名前：デフォルトの名無しさん [2024/03/27(水) 18:09:17.85 ID:345wycOn.net]: >>395
～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。
403 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 18:27:03.05 ID:3NgGdhlw.net]: >>397
問題点の指摘や解決策の提案と
問題解決のために実際に誰が動くのかという
2つの異なるものを混同したらだめだよ
マネジメント101
404 名前：デフォルトの名無しさん [2024/03/27(水) 18:54:43.86 ID:nHNmKGrp.net]: その素晴らしい提案がなぜされていないのか考えよう
そしてなぜ自分は実行から逃げているのか考えよう
405 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 20:42:45.86 ID:deTzlgug.net]: >>394
Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。
406 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:06:58.89 ID:LwoOYerE.net]: unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。
危険な操作も含まれるけど危険な部分を分けれてるわけではない。
もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。
407 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21 ]: [ここ壊れてます]
408 名前：:18:47.87 ID:deTzlgug.net mailto: >>401
安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。
デフォルト禁止でもいいくらい。 []: [ここ壊れてます]
409 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:31:01.25 ID:LwoOYerE.net]: >>402
だからそうしたいならそうすりゃいいって話をしてる。
あなたが裁量権をもつプロジェクトでは。
私が反論してるのは「そのためのものだ」という部分に対して。
410 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:44:58.62 ID:deTzlgug.net]: >>403
Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。
unsafeはデフォルト禁止でいいよ。
411 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:49:49.48 ID:Fy0R0co2.net]: 理想をいえばunsafeなんて無いならサイコーだったんだろうね
rust陣営もしゃあなしでunsafe導入したんやろうし
unsafeなしですべてがセーフで効率的だったら
そりゃあrustは本当に素晴らしい文句なしの言語だったやろな
412 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:08:33.46 ID:toZsv7uT.net]: 生ポインタすなわちCPUによるメモリアクセスはunsafe
そこが出発点

unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる
それがsafe Rustの基本原理

つまりunsafeに行き着くためunsafe無しでは何もできない
これが真理

一方で
unsafeを閉じ込めたライブラリ利用可を前提にすれば
unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実
413 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:24:02.18 ID:cgbLYCC5.net]: >>406
だったらデフォルトunsafe禁止で良い。
どこでもunsafe okはやっぱりチグハグ。
414 名前：デフォルトの名無しさん [2024/03/27(水) 22:52:47.09 ID:qNf/D02g.net]: そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？
415 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:57:38.14 ID:LwoOYerE.net]: >>404
「そうであって欲しいと自分は思っている」なら別にいいよ。
ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。
416 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 23:02:28.02 ID:toZsv7uT.net]: #![forbid(unsafe_code)]
を宣言すればいい

もちろんすべてはunsafeへ行き着くため
unsafeを禁止できるのは自分のコード部分だけ
417 名前：デフォルトの名無しさん [2024/03/27(水) 23:55:45.93 ID:pFQTMi8v.net]: unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな
平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する
418 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 07:44:09.91 ID:OabXy/xk.net]: >>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。

>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？
419 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:15:17.48 ID:wHq/ItvK.net]: rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう
420 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:34:31.08 ID:5loDhjzb.net]: >>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]

>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません
421 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:48:28.49 ID:OabXy/xk.net]: >>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。
422 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 09:00:19.29 ID:5loDhjzb.net]: >>415
これでunsafeが使用禁止となり安全なsafe Rustになる
#![forbid(unsafe_code)]
コンパイラがunsafeをエラーとして弾く
423 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 10:37:24.50 ID:dWo+4s1T.net]: 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな
424 名前：デフォルトの名無しさん [2024/03/28(木) 14:03:58.90 ID:61/ABBlz.net]: まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。
425 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 17:41:01.08 ID:Li+1uESY.net]: unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる

もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない
426 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 18:27:15.03 ID:OabXy/xk.net]: >>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。

Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。
427 名前：デフォルトの名無しさん [2024/03/28(木) 18:35:39.73 ID:2Ez7VURh.net]: unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう

でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ
428 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 18:56:54.80 ID:Hx0Q8eMq.net]: 必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい

他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
https://rust-lang.github.io/api-guidelines/
429 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 19:45:10.84 ID:OabXy/xk.net]: >>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？
430 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 20:08:10.91 ID:uNPCtnZO.net]: forbidもunsafe_codeもrustcのlintの一部だな
doc.rust-lang.org/rustc/lints/levels.html#forbid
doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code
431 名前：デフォルトの名無しさん [2024/03/28(木) 21:59:19.02 ID:vhhc95Ef.net]: Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。
432 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 22:34:58.42 ID:jTiWvkZ+.net]: どの開発でも
#![forbid(unsafe_code)]が原則

どうしてもunsafeが必要なら
その安全ロジックを関係者で協議後に
#![deny(unsafe_code)]へそのモジュールのみ変更し
許可する部分のみを
#![allow(unsafe_code)]として監視対象
といった感じが一般的かと

監視対象を極一部に限定できて
全体はコンパイラにより保証できるため
他のプログラミング言語より扱いやすい
433 名前：デフォルトの名無しさん [2024/03/28(木) 22:41:56.41 ID:8+kd1npI.net]: >>420
一般とそうでない奴は誰がどうやって区別するのさ？
434 名前：デフォルトの名無しさん [2024/03/28(木) 22:42:31.88 ID:8+kd1npI.net]: >>421
正解
435 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 23:58:52.21 ID:KGiLR8kg.net]: 時間がない時はunsafe使っていいよ
436 名前：デフォルトの名無しさん [2024/03/29(金) 00:05:51.94 ID:B//2x2dm.net]: 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう
437 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 00:19:58.75 ID:Rgc3qInF.net]: >>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない
438 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 00:24:32.79 ID:Rgc3qInF.net]: >>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全
439 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 01:57:50.63 ID:EplliVDI.net]: 壊れたレコードオジ怖い
440 名前：デフォルトの名無しさん [2024/03/29(金) 02:36:16.29 ID:B//2x2dm.net]: >>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？
441 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 07:36:27.65 ID:9Pm5HVgJ.net]: 雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな
442 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:25:13.35 ID:bd1Zch8f.net]: >>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。

デフォルトunsafe禁止は何回か話題に出てきているのな。
443 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:27:22.40 ID:bd1Zch8f.net]: >>426
それぐらいやらないとRust採用するメリット無さそうだよな。
444 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:41:03.04 ID:ev5kqnbp.net]: 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？
445 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 09:16:34.82 ID:cTkAvXQI.net]: そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい
446 名前：デフォルトの名無しさん [2024/03/29(金) 09:24:57.68 ID:vaG7EqUh.net]: >>436
じゃunsafe使うな、で済む話じゃん。
447 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 09:49:54.05 ID:AosFf04R.net]: >>440
そうだね
で？
448 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:01:08.74 ID:8PtB/vi4.net]: rustもプログラマがザコだと使いこなせない言語なんだろ？
人材確保すら苦労するってメジャーになれるのかよ
449 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:23:44.57 ID:34VMnlB4.net]: unsafeでサッと書いたほうが出世できるぞ
450 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:49:42.05 ID:ZM8BmiyA.net]: たしかにプログラムの品質がいいから出世するって見たことないわ
逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな
451 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:53:12.39 ID:opHbD1qf.net]: unsafeは面倒
Rustで書いていてunsafeを使いたい気分になることがない
さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない
452 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:54:18.08 ID:K6ErCtbZ.net]: >>442
メジャーになれなくて何か問題あるの？
453 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:08:03.79 ID:6hM9S6Vd.net]: 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。
454 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:08:08.24 ID:GuqFwMZD.net]: >>440
PMやったこと無いの？
unsafe使うなと管理するより、そもそも使えない方が遥かに楽。
455 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:13:58.45 ID:E/kaNL72.net]: >>442
C++ とかだと使いこなせてないのになんとなく動いちゃったりするから……
使えてないなら使えないほうがちょっとマシなんだよ。
456 名前：デフォルトの名無しさん [2024/03/29(金) 12:15:29.32 ID:vaG7EqUh.net]: >>448
言語機能的にunsafeって書かなければそもそも使えないじゃん。
457 名前：デフォルトの名無しさん [2024/03/29(金) 13:21:21.11 ID:l8m+nc89.net]: >>446
時間の無駄
458 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 13:35:34.69 ID:ZM8BmiyA.net]: >>448
そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね
459 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 16:25:54.97 ID:34VMnlB4.net]: unsafeでサクッと終わらせてどんどん仕事取ろうぜ
safeでチンタラやってる無�
460 名前：\に仕事を回すな []: [ここ壊れてます]
461 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 17:20:13.23 ID:Cl3C8AEw.net]: アンチはunsafeを使うと早く書けると誤解しているのが面白い
早くもなければ楽でもないので普通は使わない
462 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 17:36:40.68 ID:cTkAvXQI.net]: 「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね
463 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 17:56:14.07 ID:uhU4IUEm.net]: このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが
464 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:02:08.48 ID:uhU4IUEm.net]: 正常なコミュニケーション力を持った優秀なエンジニア
→こいつらは出世するのでプログラミングスキルは生かされない方向に進む

正常なコミュニケーション力がない優秀なエンジニア
→こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない

どうしたら優秀なエンジニア揃えられるんや…
465 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:06:18.85 ID:fG0MAqjd.net]: ｶﾁｮｰ「では進捗を報告してください」
unsafe_man「ｱﾉｰ、ﾁｮｯﾄ時間かかってｵﾘﾏｼﾃ、ｱﾝｾｰﾌが、ｿﾉｰ（怒涛の勢いで難しいことを話し続ける）」
ｶﾁｮｰ「???」
466 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:22:45.54 ID:TAofIzHh.net]: >>457
放っておいても勝手に集まるから心配しなくていいよ
そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど
467 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:29:23.69 ID:/REVrZ9A.net]: >>459
すまん、集まってるとこの実名あげてくれんか？
468 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:20:01.67 ID:GuqFwMZD.net]: >>458
いきなり人格攻撃かよ？Rustらしいな
469 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:31:34.50 ID:wqpOcL9O.net]: NとかFとかは優秀な人がいるイメージがない
470 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:54:25.38 ID:M7FjmHlu.net]: unsafe使う機会ってほぼないよな
よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか
471 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:58:01.23 ID:wqpOcL9O.net]: 優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人
でunsafeを使いこなせるかどうかなんか無関係

これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人
472 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:59:06.31 ID:0Uoml8t7.net]: システムプログラミング用途も売りにしてなかった？
Cと同等のことをしてみせようってんなら
unsafeくらい当たり前に常用するやろ？しらんけど
ボクは使いません！みたいな意見は誰も求めてないからｗ
473 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 20:37:55.25 ID:TAofIzHh.net]: unsafe使うと変更する時にだるくなるからできるだけ使わない
グローバル変数使うのと同じ気分

「グローバル変数くらい当たり前に常用するやろ？しらんけど
　ボクは使いません！みたいな意見は誰も求めてないからｗ」
とか言われたら知らん
474 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 20:41:59.79 ID:wqpOcL9O.net]: 誰にも影響及ぼさないなら勝手に使えばいい
475 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 20:47:48.55 ID:0Uoml8t7.net]: 使う必要があるからunsafeってもんがあるんであって
使う必要がない人の意見や感想は求められてないんよ

使うべきとか使うべきじゃないとか
普通はどうとか普通はどうじゃないとか
無意味な応酬はやめよう
476 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:08:57.87 ID:bd1Zch8f.net]: コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。
477 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:45:08.79 ID:DW6NdCQ6.net]: >>451
君の時間の無駄ってこと？
こんなところで毎日無駄な時間過ごしてるのに？
それって君がやらなければいいだけだよね
478 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:46:36.17 ID:wXELlTG7.net]: >>468
一連のunsafeコントで初めてまともな意見だな
479 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:52:31.85 ID:TAofIzHh.net]: エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで
Rustが普及する日は来るんだろうか
上の方でも言われてたけどコーダー集まらない問題に直面しそうだが
480 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:06:45.92 ID:wqpOcL9O.net]: Rustはコーダーは集まらんだろ

普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる
ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる

大手だとこれの繰り返しだがRustはそれが難しい
481 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:29:09.47 ID:wqpOcL9O.net]: 意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと
増えるわけがない
javaやpythonじゃないんだから

野良Rustコーダーなんて存在しない
使える人間は100%C++使いなので引っ張ってこれない
482 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:30:50.06 ID:UmT7/PmU.net]: エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな
483 名前：デフォルトの名無しさん [2024/03/29(金) 22:35:31.54 ID:B//2x2dm.net]: まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう
484 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:48:02.40 ID:0Uoml8t7.net]: それよりもホントにシステムプログラミングできてんのかが興味あるわ
CからはOSならばUnixやLinuxやWindowsが生まれてきたけど
Rustからは一体どんな素晴らしいものが生まれてくるんだろうか？
Cより書きやすくて？　安全なんだよね？　期待していいんよね？

Systems programming
https://en.wikipedia.org/wiki/Systems_programming
e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications
485 名前：デフォルトの名無しさん [2024/03/29(金) 23:01:23.64 ID:B//2x2dm.net]: 今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある
でも期待するのは自由だ
Rustファンはみんな期待している
486 名前：デフォルトの名無しさん [2024/03/29(金) 23:11:14.94 ID:JKQcuRe5.net]: >>477
interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境（Cとアセンブラの独壇場。C++不可の世界）で組み込みRust使う記事とかあったよ。

ビジネスになるかはともかく、技術的には余裕なはず。
487 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 23:55:56.73 ID:VDRjyKLu.net]: 既にネットインフラは次々とRust製
ソースは>>51
488 名前：デフォルトの名無しさん [2024/03/30(土) 00:06:31.16 ID:v9pXWAWc.net]: >>472
Rustは仕様や周辺ツールが飛びぬけて優秀な故
JavaやPHP等他の言語と違って素人でも適当に書いても
大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると
大規模開発現場で普及する事はこれからも無いよ。
489 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 01:01:10.58 ID:7ofxl8DK.net]: それで守られるのはITコン猿の立ち位置じゃね？
エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが
490 名前：デフォルトの名無しさん [2024/03/30(土) 01:46:17.09 ID:v9pXWAWc.net]: 知ってる人間は黙ってRustの恩恵を受けておけば良くて
人売りサル業界は人/月だコミュニケーションスキルだと
喚いていれば良い。
491 名前：デフォルトの名無しさん [2024/03/30(土) 07:28:24.91 ID:6WvjgMqi.net]: C++が流行った経緯知ってる奴なら想像できるだろ。
C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。
でも流行ったのはC++。
492 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 13:15:43.05 ID:Kpt9p6/a.net]: C++はわかりやすく拡張されたCだからさ
ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった

NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない
日本語の書籍がないのが一番つらかった
493 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 20:58:56.17 ID:IReUP+am.net]: 当時NeXTに触れてたやつおるん？
たまげたなぁ
俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ
いつごろだったかなぁ日本語のやつあったけどなぁ
まさかmacOSで脚光浴びるとは思いもせずに
494 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 21:08:50.38 ID:Kpt9p6/a.net]: 研究室にあったんよ
当時でももう型オチででも予算無いからリプレースも出来ず
MOのデータを消しながら使ってた

古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで

自分は図書館に埋もれたModulaの本を読んでた
495 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 21:14:51.55 ID:IReUP+am.net]: 羨ましい
俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ
あー羨ましい
496 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 22:32:19.21 ID:VLAlfJh3.net]: モーモーちゃんに入れている人は居たな
497 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 11:42:27.74 ID:lJUXuXT4.net]: C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。
結局は C のままでいくと判断した。
良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。
言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。
C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。

Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、
今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。
そもそも ABI が C を基準にした仕様だったりするので
他の言語と接続するときは皆が C に合わせる形になる。

もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。
498 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 15:29:48.98 ID:dXzgmT0X.net]: ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う
499 名前：デフォルトの名無しさん [2024/03/31(日) 16:44:42.12 ID:PaHOJUqO.net]: >>490
Rustで書いたOSが大流行でもしない限りCと同じようにはならない。
ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。
そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。
もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。
500 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 19:15:56.54 ID:r1rO2LMH.net]: ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない
多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する
501 名前：デフォルトの名無しさん [2024/03/31(日) 19:55:09.30 ID:T95JlUSJ.net]: ABIこそ良い奴が出たら置き換えられそうだけどな
現状良い奴がないだけで
502 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 21:03:45.67 ID:rhKYEfc8.net]: >>493
何言ってんのwww
相変わらず無知が過ぎる
503 名前：デフォルトの名無しさん [2024/03/31(日) 22:06:47.20 ID:HimKkZni.net]: いやまあ1%もいないんじゃない？
504 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 23:37:37.59 ID:PUonJ710.net]: そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど
505 名前：デフォルトの名無しさん [2024/04/01(月) 19:53:32.69 ID:QJf4H8j7.net]: そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。
506 名前：デフォルトの名無しさん mailto:sage [2024/04/01(月) 20:06:07.63 ID:lQvViLVK.net]: C++より多いから問題ない
507 名前：デフォルトの名無しさん mailto:sage [2024/04/01(月) 22:56:49.63 ID:wqqAiPYQ.net]: 「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html
508 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 08:53:54.00 ID:i0O60K8Z.net]: >>500
メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。

c++標準も、Safe Rust に倣って
c++ subset for safe programming
とか作ればいいのに。
509 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 09:19:58.94 ID:D6QICSr8.net]: メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。
510 名前：デフォルトの名無しさん [2024/04/02(火) 09:39:48.87 ID:EeET/S7r.net]: java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。
511 名前：デフォルトの名無しさん [2024/04/02(火) 11:06:55.03 ID:lti1kN7b.net]: >>503
安全じゃ無いぞ
512 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 14:49:37.59 ID:b3hi6lw5.net]: >>501
C/C++はプログラム全体がunsafe空間なので難しい
safeにしようとすると全く別言語になってしまう
結局C/C++を捨てるのが正しい
513 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 17:14:03.69 ID:kERS+9TD.net]: >>503
nullポイントがある時点で…
一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど，だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ
514 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 17:14:28.23 ID:kERS+9TD.net]: nullポインタだ
ごめんなさい
515 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:23:13.98 ID:mnREx4SD.net]: ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される
nullから何かを読み出して動き続けると危険
516 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:43:54.77 ID:0YGJ2wff.net]: >>508
Someである保証がある時のみunwrap()を使う
保証がないのにunwrap()する人はクビ
517 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:54:06.54 ID:mnREx4SD.net]: メモリ安全の文脈だからそういう次元の話ではないのだが
518 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:55:57.61 ID:i0O60K8Z.net]: >>505
コーダー向けだから別言語でいいよ。

new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。
operator関数定義も禁止でいいんじゃない？
519 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 19:03:35.75 ID:mnREx4SD.net]: ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね
520 名前：デフォルトの名無しさん [2024/04/02(火) 19:19:41.72 ID:qL7KDCYj.net]: rustって楽しい？
521 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 19:20:30.34 ID:kERS+9TD.net]: どの言語にも共通するけど，書けるようになってくると楽しいよ
522 名前：デフォルトの名無しさん [2024/04/02(火) 19:40:54.12 ID:lti1kN7b.net]: でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね
523 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 19:43:54.71 ID:ptOw8ylO.net]: >>512
あ、未定義と定義されているのも全部禁止ね。
524 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 20:13:32.30 ID:+hiVU8fL.net]: >>500
これでRustの知名度も上がるし普及も加速しそう
525 名前：デフォルトの名無しさん [2024/04/02(火) 20:26:12.86 ID:lti1kN7b.net]: >>517
結構前にもNASAが同じ様な事言って今やんw
526 名前：デフォルトの名無しさん [2024/04/02(火) 20:31:06.25 ID:EeET/S7r.net]: rustを無理に使ってまですることがぬるぽ対策とかアホだよね
527 名前：デフォルトの名無しさん [2024/04/02(火) 20:45:15.37 ID:lti1kN7b.net]: >>519
まあ戦争によるサイバー攻撃に備えろってのは分かるんよ
日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね
528 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 21:20:14.32 ID:+5bQ5ala.net]: >>518
NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね
間違いなく日本も追随することになる
529 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 21:56:04.08 ID:mnREx4SD.net]: Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがｗ
ONCDは健全なのかな
530 名前：デフォルトの名無しさん [2024/04/02(火) 22:51:50.04 ID:ZP8DsSPi.net]: >>518
NASA？NSAじゃなく？
NSAはNASAじゃないぞ。
531 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:24:29.45 ID:JjgiIhmH.net]: ワロタ
NSAとNASAの区別もできんとはｗｗ

メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か
2022/11 NSA
2023/09 CISA
2023/12 CISA+NSA,+FBI+Five Eyesの各機関
2024/02 White House(ONCD)
532 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:39:08.04 ID:/KZzSXx2.net]: とりあえず良いcrateが増えまくってほしいな
533 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:51:33.79 ID:DOFjhDY0.net]: >>524
あとは日本がどれだけ遅れるかだな
数ヶ月か、1年か、数年か、
534 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:57:17.27 ID:ULMcj34Q.net]: 外部のお墨付きを欲しがる時点でオワっとるんよ
言語として
ここでそういう話題使って必死で盛り上げようとして
消えそうな火に風送ってるつもりかしらんけど
535 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 00:07:33.86 ID:xB8sPKZQ.net]: IT大手ライバル同士が
GAFAMからHUAWEIまで一致団結して
Rust Foundationを設立した時点で未来は確定していた
そしてRustに対抗できるライバル言語の芽が今も存在しない
536 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 05:31:15.82 ID:SWmJ9bDO.net]: >>527
話題にも上がらないよりまし
537 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 07:36:47.52 ID:ClJR5oeK.net]: Rustの代替になる思想の言語が全くそれ以降全く見ないからな。
今のところGCレスでメモリ安全に向き合った唯一の言語でねえの？

後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。
538 名前：デフォルトの名無しさん [2024/04/03(水) 08:17:45.92 ID:OgaFV8I4.net]: >>527
欲しがってるかね？
むしろ外部が乗っかろうとしてる感じ。
539 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 08:58:53.93 ID:7dkIXzmY.net]: >>530
メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。
過去互換性のせいで徹底できないけど。

それよりもRustはスタックフレーム指向であることに価値がある。
スタック is god, 再帰 is god.
540 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 11:38:42.38 ID:TbyA9/um.net]: >>515
まあ標準ライブラリがかなりミニマムだなぁって感じるときはある
乱数くらい用意しておいてよ…
541 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 11:38:56.67 ID:zWYr6uc2.net]: >>530
ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている
で別の言語Bが作られる

その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない
542 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 13:08:37.11 ID:VOIzFFgw.net]: >>534
>その言語Bが普及しきっていなければ容易に弱点を変更できる
これが真とは限らない
容易に変更できる場合もあればそうでない場合もある
543 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 13:33:20.93 ID:7LWlVk3J.net]: Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか

wikipedia
> 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。
544 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 21:45:24.20 ID:ClJR5oeK.net]: GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。
545 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 22:40:40.78 ID:7LWlVk3J.net]: 後発言語？？？
546 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 03:50:23.61 ID:6dtGhNgR.net]: >>537
所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。
適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。

ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。
547 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 04:13:47.93 ID:KZy/sIny.net]: Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ
とりあえず動くように雑に書いて動かしてみて
次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など

このようなリファクタリング過程で
他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが
Rustではコンパイル通せばそれらの心配がなくリファクタリングできる
548 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 08:02:04.20 ID:KuogGH/c.net]: そもそもGC無しの言語ってニッチじゃない？
当面は、Rustで充足されて安泰な気がする。
549 名前：デフォルトの名無しさん [2024/04/04(木) 08:06:01.77 ID:wZ/e8tnl.net]: うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。
関数型言語にも良いのあるけど、普及しなさそうだしね…。
（OCamlとか次世代HaskellらしいIdrisとか）

それにCとアセンブラしかない分野（C++不可なくらい低スペックな組み込み）でC++以降のモダンな言語が使えるのは大きい。
550 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 08:41:03.15 ID:VIrJEXhK.net]: 学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど
メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。
LLVM が C/C++ を前提にしてるところもあるし、
Rust もそれに合わせる形になってるところもある。

C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。
551 名前：デフォルトの名無しさん [2024/04/04(木) 12:25:37.65 ID:Gnl54rZ8.net]: すまんが↓これが動く理由を教えて欲しいんだけどさあ
https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w
一見
552 名前：すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・ これって5行目が借用に推定されてるの？ それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな？ へるぷみい []: [ここ壊れてます]
553 名前：デフォルトの名無しさん [2024/04/04(木) 12:36:31.67 ID:xh1kANkn.net]: マクロだからセーフ
554 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 12:40:39.97 ID:yz59nStO.net]: >>544
値とその所有権が複製されて関数fに渡される分とそのまま残る分の2つになる
555 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 12:49:08.15 ID:w8P1RFve.net]: 値が複製されて、複製された値の所有権が関数fに渡るだな。

所有権の複製とかいうクソワードは避けてくれ。
556 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 14:09:00.66 ID:VIrJEXhK.net]: >>544
i32 は Copy トレイトが実装されてる。
普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。
557 名前：デフォルトの名無しさん [2024/04/04(木) 14:21:30.05 ID:Gnl54rZ8.net]: そう言うことなのか、ありがとう！
理由が分からなかったから不気味だったぜ
558 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 15:21:14.87 ID:AF0jRQyM.net]: >>547
>値が複製されて、複製された値の所有権が関数fに渡るだな。
複製された値の所有権は最初から関数fのスコープの中で発生するものなので
「関数f」に渡るという表現には少し違和感を感じる
559 名前：デフォルトの名無しさん [2024/04/04(木) 15:34:13.46 ID:1vyOHDUL.net]: 「違和感を感じる」という表現に違和感を感じる
560 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 18:59:50.97 ID:mbQWc9lN.net]: >>551
滑ってるぞ
561 名前：デフォルトの名無しさん [2024/04/04(木) 19:04:00.82 ID:mNkWQBjH.net]: 感じてるから違和「感」だからね

要は頭痛が痛いと同じ
562 名前：デフォルトの名無しさん [2024/04/04(木) 19:08:09.03 ID:v0TcrcAn.net]: 違和感がある。これでどうだ
563 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 19:17:51.63 ID:v7LceGlx.net]: >>553
感じるを感じるメタ表現だろ。

ポインタのポインタみたいなもんだ。
564 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 20:07:49.07 ID:xDxHg+AD.net]: >>542
embedded 対応アーキ少なくね？
565 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 23:05:07.77 ID:94OMF7T7.net]: >>553
「違和感を感じる」は「頭痛が痛い」とは違って重言ではないよ
https://togetter.com/li/2067771
https://www.nhk.or.jp/bunken/research/kotoba/20240101_4.html
566 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 23:18:56.70 ID:94OMF7T7.net]: >>557
重言ではあるけど間違った日本語ではない
といったほうがよかったね
567 名前：デフォルトの名無しさん [2024/04/05(金) 00:09:35.95 ID:Lw8p7kTG.net]: >>556
少ないね。
でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。

それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。
568 名前：デフォルトの名無しさん mailto:sage [2024/04/05(金) 00:21:09.11 ID:dub3Z8tI.net]: 後発言語？
569 名前：デフォルトの名無しさん [2024/04/05(金) 00:50:16.55 ID:Lw8p7kTG.net]: 少し前まで次世代言語と言われてた程度には後発。

鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。
むしろ崩し始めることすら無理だと思ってた。
570 名前：デフォルトの名無しさん mailto:sage [2024/04/05(金) 05:07:52.53 ID:CPVE6BHF.net]: >>559
状況も追い風なのかもね。
二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。

先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな？
571 名前：デフォルトの名無しさん [2024/04/05(金) 08:11:28.72 ID:Lw8p7kTG.net]: Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。
複数言語使えますってだけでもアピールになるしね。

Rustは多分仕事自体はまだ多くない。
これからアピールして増やしていく感じなので、両方使えてた方がいい。
572 名前：デフォルトの名無しさん mailto:sage [2024/04/06(土) 22:48:03.64 ID:4i1Gvjc8.net]: rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ
573 名前：デフォルトの名無しさん mailto:sage [2024/04/06(土) 23:06:32.76 ID:7kpWL/Du.net]: Rustが実用的になったのは2020年
それ以降の新規案件はRustになっている
574 名前：デフォルトの名無しさん [2024/04/07(日) 01:26:10.29 ID:Hmt7T+4v.net]: Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前
575 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 10:55:29.15 ID:QD1FKAnH.net]: 絶壁の学習曲線。
貧弱なライブラリと人材。
早すぎる最適化。

しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。
576 名前：デフォルトの名無しさん [2024/04/07(日) 14:17:46.28 ID:vzw88H1n.net]: P系言語の糞思考に染まっていない初心者こそ
最初にRustを学ぶべき
577 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:04:59.36 ID:Sj2oLPpI.net]: >>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
578 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:05:33.79 ID:nD4MmBKu.net]: 初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか
579 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:09:00.76 ID:Sj2oLPpI.net]: >>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる
Rustでも同様でほとんどがそれら含む新たな案件
580 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:16:09.73 ID:TV6Dkj8m.net]: >>567
早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ
そしてRustを叩きたいためにウソを散りばめる
581 名前：デフォルトの名無しさん [2024/04/08(月) 02:24:45.08 ID:BHlkyWwA.net]: >>567
貧弱なライブラリとかエアプかよ
そしてRustを叩きたいためにウソを散りばめる
582 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 03:09:59.48 ID:BqmMXmQi.net]: 単なる感想を必死にウソ扱いして何がしたいんだコイツw
583 名前：デフォルトの名無しさん [2024/04/08(月) 11:48:22.86 ID:hzcejt90.net]: ライブラリはPythonと比べると流石に貧弱
特に数値計算とか物理・機械学習系

簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している
もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない
584 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 12:32:47.46 ID:64QjhTLf.net]: >>575
キチガイアンチ
すべての分野でライブラリが充実している言語は存在しない
ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前
そういう無意味なことをして叩いて楽しいか？
585 名前：デフォルトの名無しさん [2024/04/08(月) 13:16:14.61 ID:JoalanBl.net]: >>576
貧弱なことを指摘するのは叩きではない
俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ
586 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 14:02:16.22 ID:7wfBslr8.net]: >>576
そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。
587 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 14:10:54.87 ID:7wfBslr8.net]: >>570
絶壁の学習曲線だから無理だろ。

moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない？
588 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 14:43:36.67 ID:IC0NBj1d.net]: Crypto分野はRustが他言語よりも充実してるかもね
589 名前：デフォルトの名無しさん [2024/04/08(月) 15:06:06.34 ID:rjHvzTUw.net]: ライブラリの多さってイコールでユーザの多さなんだよ
更にいうとその言語開発者の意欲の表れでもある

ライブラリが少ないという事はユーザが少ない
更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね
590 名前：デフォルトの名無しさん [2024/04/08(月) 15:43:54.88 ID:JoalanBl.net]: いやまあ数はあるんよ数は
意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな
資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う
591 名前：デフォルトの名無しさん [2024/04/08(月) 16:39:42.51 ID:9qnuy4NE.net]: てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。
そんなんで数値計算ライブラリが入るわけがない。
592 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 17:11:27.78 ID:7wfBslr8.net]: 初心者向けのSimplified Rustと、
c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。
Safe Rustじゃ難しそうだし。
593 名前：デフォルトの名無しさん [2024/04/08(月) 17:54:43.90 ID:JoalanBl.net]: ゼロからプログラム書くならSafe rustが一番簡単だよ
こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける

まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが
594 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 19:05:28.67 ID:ifgKIXku.net]: C++を完全に理解した者のための言語それがRust
故に誰も
595 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 20:39:36.28 ID:cqL1RV99.net]: C++を使ったことないけど
Rustで困ったことないな
Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな

所有権は単なるヒープ解放責任だから大したことではない
所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話
非常にシンプル
596 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 21:02:11.65 ID:YkdU7kgc.net]: 所有権を複製するとか間違った事を言い続けてる人が良く言うわw
597 名前：デフォルトの名無しさん [2024/04/09(火) 00:09:53.71 ID:pItuq1gX.net]: >>588
それは俺じゃないぞ
598 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 02:45:12.09 ID:hsAXyuRl.net]: >>589
誰だよお前。
599 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 09:16:17.69 ID:OXfvzIgi.net]: 今のところ>>458が一番面白い
600 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 10:16:36.65 ID:Po0ZJOeT.net]: 昭和ギャグ？
ちょっと意味がわかりません
601 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 11:01:29.74 ID:cj+QXWpg.net]: 今どきイジりを面白いとか、イジメ肯定派かよ。
602 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 13:18:19.32 ID:9AcR/8+u.net]: 進化論肯定派じゃないの
人を淘汰することを志している
603 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 17:18:23.86 ID:+rnauHt3.net]: ｶﾁｮｰ「???」じゃなくて
ｶﾁｮｰ「で?」なら共感できたかも
604 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 01:14:02.81 ID:/k7xUJZy.net]: rustだいぶ分かってきたつもりだけど
ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理
好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる
605 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 08:03:56.89 ID:ltqciZ07.net]: >>592
進捗報告相手が課長というのが昭和かもな
そんな会社で働きたくない
606 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 11:01:40.54 ID:5Js//1cu.net]: >>596
moonbit くらいならどうかな？
607 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 11:35:35.51 ID:AS+TZoYk.net]: >>596
それぞれ理解していれば組み合わさって困ることはないんじゃないかな
Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど
608 名前：デフォルトの名無しさん [2024/04/10(水) 16:55:22.63 ID:yZA7mDLP.net]: Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか？めんどいんですけど
609 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 17:30:31.18 ID:Fk7YBwaR.net]: メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。
610 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 17:38:51.91 ID:t7JkSWKp.net]: self/ mut self/&self/&mut selfの区別もいるしな
self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では
611 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 17:52:25.08 ID:5Js//1cu.net]: C++ の ref-qualifier とか無理のある文法だもんな。
そこに書くんか!? という変な驚きがある。
引数の一種ということにしたほうがかなり単純でよい。
実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された｡ (deducing this)
612 名前：デフォルトの名無しさん [2024/04/10(水) 17:58:48.34 ID:Q64PiueS.net]: RustでPython実装すりゃ良いんじゃね
613 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 18:34:01.75 ID:3h5gXXiJ.net]: >>602
普通に全部ダサいんだよなあ
何とかならなかったのかとならなかったのかとならなかったのかと…
614 名前：デフォルトの名無しさん [2024/04/10(水) 19:34:40.80 ID:8DE+tVvz.net]: selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか
615 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 19:44:04.66 ID:y0DX5npz.net]: ぜひとも >>605 の考える最高にイケてる構文を教えてほしい
Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし
616 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 19:47:55.68 ID:IjfZ+vUr.net]: >>605
nimの関数呼び出しルール
関数名(第一引数,第二引数...)
第一引数.関数名(第二引数...)
で第一引数がself相当
が一番スマートかと。
617 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 20:06:03.20 ID:AS+TZoYk.net]: >>605
むしろ>>602はそれらの区別のためにもselfは必須と言ってるようにみえる
さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい
現状のRustの仕様がベストかな
618 名前：デフォルトの名無しさん [2024/04/10(水) 21:28:15.02 ID:8DE+tVvz.net]: selfじゃくてthisならC++マニアも納得
619 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 21:34:35.54 ID:6SjCdg5T.net]: >>608
nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね

Vec::push(&mut vec, 123);
(&mut vec).push(123);
vec.push(123);

この&mutを省略できてRust便利
620 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 21:37:52.75 ID:Mpv09JwO.net]: thisはたまにselfの代理で使われてるな
Rc::into_innerとか
621 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 23:19:28.12 ID:AS+TZoYk.net]: deref後のinto_inner適用と区別のため
敢えてself使わないことでメソッド呼び出し形式をできなくして
明示的にRc::into_inner呼び出しさせるパターンだね
622 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 23:45:41.84 ID:Fk7YBwaR.net]: メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は
LISP 用に作られたオブジェクトシステム new flavors でやってた。
623 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 02:11:03.37 ID:4f6XcC0j.net]: それは同一視というか構文が1つしかないだけでは
624 名前：デフォルトの名無しさん [2024/04/11(木) 02:14:15.06 ID:7FNbL3Xb.net]: 呼び出し時には与えない引数って紛らわしくね？
625 名前：614 mailto:sage [2024/04/11(木) 02:45:03.24 ID:C4qhk0zm.net]: >>615
メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。
new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど
new flavors で改良 (かどうかわからんけど) された。
626 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 04:57:52.23 ID:r6y9Ju0a.net]: >>616
むしろ逆かな
target.method(arg1, arg2, ...)という
targetへのメソッドコールを実現するのを関数で表すと
method(target, arg1, arg2, ...)とする言語が多い

Rustでも同じでこのtargetをselfと書く
targetは送る側から見た視点
selfは受け取った側から見た視点
各実装は受け取った側でなされるためself
627 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 08:24:38.80 ID:McLA6Ner.net]: UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな
レシーバとして扱われるなら構文上も特別であってほしい
628 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 08:39:59.21 ID:UjbgXeUt.net]: >>619
何が気持ち悪いのかさっぱりわからない
まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね？
次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね？
ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
629 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 08:49:57.16 ID:azFLg2co.net]: 言うほどほとんどの言語がこれか？
pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ
これがPythonいまいちだなって思うところ
c++も似た様な理由でstaticでthis

後発で考慮する余裕あるのにそれを引っ張ってる
630 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:02:17.34 ID:NXydgA7G.net]: >>621
君の感性がおかしいんじゃね？
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)
631 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:02:43.98 ID:7FNbL3Xb.net]: >>618
なるほどちょっと納得した
632 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:11:33.28 ID:azFLg2co.net]: >>622
実質Pythonフォロワーを含めて言われても…
633 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:14:09.83 ID:azFLg2co.net]: C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた
それがOOP言語になって指定不要になった
それがまたC言語時代に逆戻り
634 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:15:22.73 ID:NXydgA7G.net]: >>624
何を言ってるのかわからん
文句を言うなら望ましい代案を出してみて
635 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:17:05.47 ID:azFLg2co.net]: あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは
receiverがNullの可能性がある場合でそう設計されてただけ
636 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:20:43.92 ID:NXydgA7G.net]: 代案を出せないってことはRustに言いがかりをつけてるだけだな
637 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:24:05.56 ID:azFLg2co.net]: 別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ
その表記は時間をかけて考えたらいい
638 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:30:34.30 ID:cvuvfjXO.net]: >>625
レシーバは必ず必要
Goでも
func (receiver ReceiverType) Foo(引数…) {
　return receiver.xxx + receiver.yyy
}
と書く
レシーバ指定不要という主張は理解できない
639 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:45:56.75 ID:gYo8nOa5.net]: レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな
selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい
640 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:51:28.66 ID:azFLg2co.net]: いやいやｗ
無知って怖いねとしか…
641 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:52:17.20 ID:azFLg2co.net]: >>630
642 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 10:19:57.47 ID:UmgPKlgb.net]: UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの

>>619はそれを分かった上でNimについて書いてるのかもしれないけど>>620や>>622は明らかに誤解してる
643 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 10:33:59.60 ID:Nlu6ipA3.net]: >>631
そう言われるとRustの仕様がベストなのかな
レシーバに名前を付けないと名前空間の分離ができなくて
レシーバに名前を自由に付けられると読みづらくて
644 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:00:57.82 ID:azFLg2co.net]: IDころころお爺さんは明らかに話を理解できないな
645 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:23:46.71 ID:CaCoKmZ3.net]: Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな
型指定にSelfやSelf::Itemなど使えるだけでなく
Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる
Selfによって自分自身であるとわかりコードが読みやすい
型名変更の影響も受けず読みやすいメンテしやすい

ダメな言語だと以下のダメなパターンがある
・Selfの代わりに型名を書かなくてはいけない言語　(自分自身だとわかりにくくメンテ性も悪い)
・Selfの代わりにself(やthis)を用いてしまう言語　(値と型の区別がつかない)
・Selfを使わずに名前空間の区別がない言語　(間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)
646 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:57:27.19 ID:17a5lmDN.net]: 関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……
647 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:57:34.08 ID:6x2Zth+c.net]: 複オジは見えてる範囲が狭過ぎる
だから長文になればなるほど勘違い度や害悪度が高まる
648 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 12:47:47.10 ID:ZruVErXu.net]: 自分が使ってきた特殊な仕様の言語に慣れ親しんでいると
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている
649 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 12:59:00.66 ID:AZdBjU6j.net]: >>640
Rustに無いからといってUFCS叩くのはさすがにアホかと。
650 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 13:15:55.80 ID:4f6XcC0j.net]: そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん
651 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 15:57:20.01 ID:R8LZpbjl.net]: >>642
エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない
652 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 15:59:23.14 ID:v1XXdeLJ.net]: くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い
653 名前：デフォルトの名無しさん [2024/04/11(木) 16:41:03.54 ID:KhnNkcJ8.net]: まともな質問にいつものノリで適当に答えて嘘だったら良くないしね
654 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 17:01:08.25 ID:TWMZ6q+3.net]: そっか
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て
655 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 17:41:58.72 ID:McIjmFt1.net]: Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環？
656 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 17:48:38.15 ID:McIjmFt1.net]: 動き出した
サーバー側の問題っぽいな
https://github.com/rust-lang/rust-playground/issues/831
657 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 18:55:11.06 ID:4f6XcC0j.net]: downcastなんて別にしないからいらねーよって思ったけど

そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう
658 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 19:06:32.42 ID:VFM//2+p.net]: 複おじはc++も使ってなかったんだな
659 名前：デフォルトの名無しさん [2024/04/11(木) 20:25:23.50 ID:81s1BzdD.net]: >>641
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
660 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 20:52:12.80 ID:AZdBjU6j.net]: >>651
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。

それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
661 名前：デフォルトの名無しさん [2024/04/11(木) 21:02:41.98 ID:81s1BzdD.net]: >>652
Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。
そのためUFCSのような愚かな方式を採る必要がない。
662 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:15:01.99 ID:mF0oHAZm.net]: 答えを教えてもらっているのにヒントありがとうというオジさんw
663 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:16:29.71 ID:2g+gCFiF.net]: メソッド名空間www
664 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:54:13.50 ID:AZdBjU6j.net]: >>653
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。

せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
665 名前：デフォルトの名無しさん [2024/04/11(木) 23:54:23.85 ID:A4VQpdsZ.net]: アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ
アラビア語おすすめ
666 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 00:40:05.77 ID:fvGN/jjJ.net]: >>656
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい

UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている

ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
667 名前：デフォルトの名無しさん [2024/04/12(金) 00:44:02.94 ID:tVNhffJ+.net]: モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
668 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 02:47:17.34 ID:DYhqcHWh.net]: それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない
AddAssignやSubやShlなど多くの演算は非対称
669 名前：デフォルトの名無しさん [2024/04/12(金) 04:21:38.21 ID:tVNhffJ+.net]: いや別にSubでもDivでも左のみに紐づいているのはキモい
670 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 04:49:28.47 ID:rUQyilnM.net]: >>658
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ？

グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
671 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 05:26:42.25 ID:CIaMPOtu.net]: >>662
トレイルではなくトレイト
トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ
672 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 07:31:40.11 ID:rUQyilnM.net]: >>663
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
673 名前：デフォルトの名無しさん [2024/04/12(金) 12:27:40.08 ID:OadUyd3M.net]: >>659
＞モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ

同意
674 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 12:33:34.40 ID:rAepnpk2.net]: >>664
Rustはそうやってきちんと管理できつつ便利でいいよなー
他の言語も導入すればいいのに
675 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 12:43:39.99 ID:6xQx5uEa.net]: >>665
オブジェクト指向を全否定するキチガイか
クラスのある言語もクラスのないGoやRustなどの言語も
一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
676 名前：デフォルトの名無しさん [2024/04/12(金) 13:04:32.76 ID:qd6Rxygz.net]: とりあえず感覚で一行目から罵倒する人
677 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 15:24:23.71 ID:XC+pkKeZ.net]: >>667
>一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
オブジェクト指向前提思考？
678 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 16:22:22.83 ID:RDQRwL9V.net]: >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな？
679 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 17:02:05.38 ID:oSrgtnnN.net]: それらの件でもRustの仕様が優秀すぎ
680 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 20:51:13.79 ID:NYkXEvAJ.net]: "); //]]>-->
681 名前：72/670" rel="noopener noreferrer" target="_blank" class="reply_link">>>670
虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ []: [ここ壊れてます]
682 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 22:18:23.28 ID:HgYc1X5O.net]: おじいちゃんは昼だけ起きてて
夕方を過ぎると寝てしまう
683 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 22:50:23.70 ID:3nYhUDoK.net]: RUSTがトレンドに！！
684 名前：デフォルトの名無しさん [2024/04/12(金) 23:58:18.71 ID:lpyrPPhz.net]: >>667
つジェネリック
685 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 04:39:15.20 ID:0YGiYUZr.net]: ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか
686 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 07:36:48.57 ID:beXAxXwF.net]: トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ？

柔軟性のために外延性は欲しいところ。
687 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 08:07:59.96 ID:S51MIqUj.net]: 異なる型間の共通項をトレイトとして切り出すだけでよく
コードを美しく整理して保守性を高めやすい
688 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 13:32:34.24 ID:OrtqC7Lq.net]: 敬称ないせいで苦労してるんだってな
689 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 13:36:34.54 ID:F3jinTSj.net]: 143 デフォルトの名無しさん 2024/04/07(日) 19:27
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない

それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
690 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 16:56:52.49 ID:L60jXWVE.net]: 継承がなくても構造体にメソッドついてたら実質クラスだろ
関数に構造体渡してたらそれはクラスじゃないけど
691 名前：デフォルトの名無しさん mailto:sage [2024/04/14(日) 23:56:10.96 ID:RjsA2T1t.net]: >>681
構造体にメソッドが付くことはカプセル化と言う
クラス＝カプセル化＋実装継承　なのでクラスとカプセル化は異なる

このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる

正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない
692 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 00:05:55.58 ID:R9iMDmBn.net]: 用語も色々。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。

Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。
693 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 00:26:07.32 ID:rd9697wK.net]: 型クラスとクラスは全く異なるので混乱しない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない
694 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 01:47:00.44 ID:YLFAz6O4.net]: クラスとは何か？継承とは何か？
こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい

>>681が一番まとも
695 名前：デフォルトの名無しさん [2024/04/15(月) 01:58:25.85 ID:CPtYka/u.net]: 話は非常に単純
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い
696 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 02:39:20.65 ID:zOelqs9y.net]: RustにはJavaのクラスはありません
RustはJavaではないからです

あたまいいね
697 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 03:16:04.95 ID:0QcDOjSQ.net]: Javaの生みの親であるJames Goslingも、
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
698 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 08:31:26.40 ID:Mqs/ngjj.net]: クラスのようなものでいいよ
699 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 10:16:50.96 ID:dcBtWsLv.net]: バカの一つ覚えの相手をしても時間の無駄
700 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 12:54:52.68 ID:f4iHJAq/.net]: クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな
701 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 21:09:43.00 ID:97bFGSba.net]: それは単に使い分けが出来ない馬鹿な子向けの説明だぞ
702 名前：デフォルトの名無しさん [2024/04/16(火) 07:27:41.72 ID:10PaZXAR.net]: >>691
言語仕様としてあった方が良いということ。
703 名前：デフォルトの名無しさん [2024/04/16(火) 07:42:24.51 ID:KU96szRc.net]: 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ
704 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 08:43:42.78 ID:OvO8gS8m.net]: Javaの生みの親も言ってるようにクラス継承の機能はない方がいい
なくても困らない
あると問題を引き起こす
705 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 09:30:25.53 ID:YlYBNC7y.net]: そういうのは話半分に聞いておけばいいよ
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ

javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
706 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 09:50:49.42 ID:pgei3+18.net]: >>696
interfaceにデフォルト実装を後から入れたので問題なくなった
そうなるとclass継承は不要
707 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 09:55:41.24 ID:YlYBNC7y.net]: 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから

今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか

NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
708 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 10:21:05.77 ID:pgei3+18.net]: 今となってはclass継承は廃止でいい
709 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 11:59:36.87 ID:NkOUpCFP.net]: インターフェイスにも集合で言うところの外延性は欲しいところ。
710 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 13:49:22.28 ID:DzgCvS5T.net]: そういうの使いたいならTSがいいよ
711 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 14:56:34.55 ID:vP0l1V0c.net]: 具体的なデメリットって何なの？
712 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 15:29:25.10 ID:ePcpSD5e.net]: ダサい
713 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 20:45:11.55 ID:scEyspJl.net]: そういう感覚的なもの？
714 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 22:20:54.32 ID:pbIQ4i0L.net]: 基底クラスで保証してる内部条件を継承クラスで壊されやすい

Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない
715 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 08:15:23.25 ID:eua5YI/M.net]: Unreal EngineがRist対応するんだってね
716 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 16:42:11.69 ID:eua5YI/M.net]: Ristってなんだ、Rustだた
717 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 21:06:33.89 ID:ZcFRYo3q.net]: Rast
Rist
Rest
Rost
718 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 21:31:42.40 ID:O0zLY4aF.net]: Risp
719 名前：デフォルトの名無しさん mailto:sage [2024/04/18(木) 23:48:18.11 ID:mul2o/Jt.net]: >>706
時代の流れだな
720 名前：デフォルトの名無しさん [2024/04/19(金) 17:19:41.25 ID:QdSz4ItG.net]: 隙間作って床下チェスト収納ってできなくなった？動画みてるけどうまくできん
721 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 17:39:26.03 ID:pCmD4UWo.net]: shift-jiｓのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない
全部読んでデコードして\nで切り分けるしかないの？
722 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 17:53:01.46 ID:AAPU1iqE.net]: read_lineはutf-8じゃないと無理だけどread_untilならバイト列で１行ずつ取れそう
723 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 22:11:31.95 ID:pZNdwQSZ.net]: >>712
encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る
あとはreader.lines()で同じ
724 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 22:28:20.55 ID:pZNdwQSZ.net]: std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines()
725 名前：デフォルトの名無しさん mailto:sage [2024/04/21(日) 07:15:48.69 ID:QKVewSeW.net]: BufReaderもFile::openもそのまま使える点がいいね
726 名前：デフォルトの名無しさん mailto:sage [2024/04/21(日) 10:23:00.52 ID:Be3/0qjS.net]: >>715
ありがとうございます
動作確認しました

ちょっと仕組みがむずかしいですね
727 名前：デフォルトの名無しさん mailto:sage [2024/04/21(日) 18:25:05.39 ID:GAd5jyBU.net]: decoderが挟まるだけだよ

// UTF8の場合
let file = File::open(path)?;
let reader = BufReader::new(file);
for line in reader.lines() {

// SJISの場合
let file = File::open(path)?;
let decoder = DecodeReaderBytesBuilder::new()
　.encoding(Some(SHIFT_JIS))
　.build(file);
let reader = BufReader::new(decoder);
for line in reader.lines() {
728 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 06:09:19.12 ID:kZ9sSSe5.net]: バッファリングせず丸ごと贅沢にメモリ使っていいなら単純
let bytes = fs::read(path)?;
let (s, _, _) = SHIFT_JIS.decode(&bytes);
let reader = BufReader::new(s.as_bytes());
for line in reader.lines() {
729 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 20:07:02.52 ID:g+YSHIF5.net]: コマンドラインからファイル名取るようにしたらパニック
windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい
730 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 20:46:10.62 ID:ZfX6SpnE.net]: 何を言ってんのw
731 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 21:19:42.71 ID:g+YSHIF5.net]: 知らないとそういう反応するんだろうけど
std::env::args_osを使ってOsStringを取って対処する必要があるんだよ
勉強になっただろ？
732 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 21:24:48.26 ID:g+YSHIF5.net]: 日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える
アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう

世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている
733 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:12:07.98 ID:ljq3CdpU.net]: >>722
チュートリアルレベルの基礎を
バッドノウハウwとか
積み重ねでいかないといけないwとか
言ってるから何言ってんのwになる
734 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:32:38.83 ID:cr/ZTax6.net]: >>720
Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある
さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる
まずは基礎知識を身につけよう

>>722
std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある
さらに対処方法はargs_osを使えと明記されている
ドキュメントを見よう
735 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:35:51.77 ID:g+YSHIF5.net]: >>724-725
こういう低能がありがたがるんだろうな
信者としか言いようがないｗ
736 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:42:55.88 ID:g+YSHIF5.net]: リリースした後の実行時のpanicを有り難がる信者

Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本
737 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:57:01.81 ID:kZ9sSSe5.net]: >>722
Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから
その関数のドキュメントのpanicの項目を見れば明記されてる
他の言語と比べても良い環境
738 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 00:03:29.34 ID:aheV4X/O.net]: 馬鹿と話しててもらちが開かない

世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実
お前らそれを一個一個プルリク送ったりしてるのか？
739 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 00:13:45.98 ID:aheV4X/O.net]: 所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ
世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる

非合理的
740 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 00:34:48.42 ID:tNw43TTr.net]: そんなことより The Embedded Rust 読み始めたんです。
冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね？と言わんばかりの内容。
おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。
741 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 09:44:34.04 ID:SlAsUTut.net]: 公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる
プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す
ヤバすぎね？
742 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 11:06:58.83 ID:PMnHeW+x.net]: >>725
なんでコンパイル時にエラーにできないんだろう？

Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは？
c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。
743 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 12:06:18.33 ID:cfnwg7MD.net]: panicは安全ですヨ
744 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 12:11:09.83 ID:r76fNggU.net]: >>734
緊急停止して「安全ですよ」はちょっと……
745 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 12:14:00.43 ID:jXQ0V2HY.net]: >>733
セキュリティホールにならない
異常データに対して止まり動作を続けない
746 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 15:43:54.29 ID:3Xc7JqWG.net]: >>733
>なんでコンパイル時にエラーにできないんだろう？
出来るわけないだろw
実行時に与えられる外部入力�
747 名前：Rンパイル時にどうやって判定するんだよw バカすぎる []: [ここ壊れてます]
748 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 16:19:44.91 ID:1rwyWp7B.net]: しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス
もう治る見込みはないからargs_os()を使おうねってだけだけど
749 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 16:52:58.90 ID:Kbb8det7.net]: 一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど
特に提案もなさそうだし誰も困ってないんじゃないかな
そもそもほとんどのケースでclapとか使うだろうし
750 名前：デフォルトの名無しさん [2024/04/23(火) 17:20:16.94 ID:jbFpiEtG.net]: >>733
＞>>725
＞なんでコンパイル時にエラーにできないんだろう？

むしろ何でできると思ってるんだろう。謎
751 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 17:22:13.22 ID:SM3r9/qB.net]: 環境変数もvarとvar_osがあるから慣れろとしか言えない
OS標準が全部utf-8になる未来もありえるし
752 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 17:48:20.12 ID:x1LuxzDZ.net]: >>741
紛らわしいけどvar/var_osとvars/vars_osは別物だよ
varはinvalid UTF-8でもエラーハンドリング可
varsはpanic

argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど
varsはそんな前提をおける状況はほぼなくてよりたちが悪い
753 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 18:06:35.01 ID:DF4k8ks3.net]: >>741
>OS標準が全部utf-8になる未来もありえるし
10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない
もう10年経ったとしても状況は変わらないと思う
754 名前：デフォルトの名無しさん [2024/04/23(火) 19:06:07.68 ID:rRGY+2Qg.net]: >>732
公式チュートリアルまともに読めるならC++で良いからな
755 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 20:01:34.96 ID:+uJAOtCC.net]: よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？

どう考えてもstd::env::argsを非推奨にしろとは思うけどね
欧米人がつくるとこんなことになるんだ

普通は2種類の扱いがある
・実行環境に合わせて自動的に内部での標準形式に変換
か
・何もしない
何もしないならOSから受け取ったままOSに渡して置けば大体問題はない

第三の愚策がRust
受け取ったままそのままOSに渡してもコケる
Rustは何もしないように見えるけど何かしてるからコケるのでは？
756 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 20:52:29.82 ID:xiHKhQOf.net]: >>745
間違いだらけだな
世界の標準はUTF8
ウェブももちろんUTF8
RustもUTF8

Rustがこの件でコケることはない
きちんと各関数の仕様が明記されていて常に正確に動作している
757 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 21:05:41.35 ID:ykVY4Q8s.net]: Rustのパニックは綺麗なパニック
いいね？
758 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 21:12:51.81 ID:xiHKhQOf.net]: >>747
一般的なパニックは色んな意味合いがあるけど
Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた
ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない
だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる
759 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 23:35:29.98 ID:v0qt2UCV.net]: >>745
勘違いしてることが多すぎてもう笑うしかないwww
760 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 23:41:39.78 ID:x1LuxzDZ.net]: >>745
>よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな？
(UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど)

↓これが15年くらい前のUTF-16に対する一般的な認識
https://softwareengineering.stackexchange.com/questions/102205/
761 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 00:43:41.33 ID:5EZEwmZn.net]: utf-16はUnicode 2.0（1996年7月）のサロゲートペア導入でutf-8に逆転されたな
しばらくはBMPしか使われなかったから耐えてたけど
1990代前半に始動したJavaは運が悪かった
762 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 01:21:01.63 ID:YBOQY0J9.net]: >>749
そう書きながら何もまともなレスすらできないレス乞食
763 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 01:23:24.26 ID:YBOQY0J9.net]: Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど
Rustが正しいRustが正しいと繰り返すばかり
764 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 12:36:38.15 ID:A+y4lqIx.net]: >>737 >>740
windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。

そもそもargは廃止していい。
765 名前：デフォルトの名無しさん [2024/04/24(水) 12:47:56.41 ID:HIQuAly7.net]: すげーどうでもいい話だな
766 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 12:47:57.96 ID:A+y4lqIx.net]: >>746
なるほど。
「RustはWindowsをケアする気が無い」
ということですか。
767 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 12:58:45.05 ID:GRRi3Rgr.net]: >>754
Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能
まぁ廃止していいには同意するけども
768 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 13:18:14.84 ID:meF6WBmz.net]: Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。
今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。
保証としてはあてにならん。
769 名前：デフォルトの名無しさん [2024/04/24(水) 13:18:30.26 ID:HIQuAly7.net]: コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。
770 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 14:25:14.78 ID:up+AoO7k.net]: >>754
無知にもほどがある！

unicodeとUTF-8が区別できない
Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない
771 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 15:25:54.44 ID:65hs2nTl.net]: >>760
そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。
Rustはメモリ安全しか興味無いんかね。
772 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 15:53:48.65 ID:gLaneKFw.net]: 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。
773 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:02:42.64 ID:zvblwt+/.net]: どうでもいい話でもめてるな
Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題
こちらはUTF8環境でしか使われないのでargs()のみ利用している
774 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:05:40.76 ID:AQu1Dr63.net]: https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905
関係する議論はこのあたりかな
もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが
無視や置換はセキュリティ上問題になる可能性があるので却下
varsは将来的にdeprecatedにするかもと言っている
なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね
775 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:26:19.27 ID:MMJHgfnp.net]: 正しく使え論は暴論だな

それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる
776 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:40:56.16 ID:zvblwt+/.net]: >>765
生ポインタは安全ではないから全く違う
argsは常に安全
777 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:44:59.20 ID:MMJHgfnp.net]: 常に自動変換したほうが安全だけどな
開発者が特別コードを書く必要もない
778 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:05:56.77 ID:MMdiZvh6.net]: Rustはファイル名も自動変換なんかしていないように
変換するかどうかは各自の自由裁量であるところが非常に良い点だよ
自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど
779 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:17:38.15 ID:MMJHgfnp.net]: >>768
ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい
780 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:21:01.52 ID:MMJHgfnp.net]: ファイルの引数だけ標準では何もしない
普通のキーボード入力などでは変換している
781 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:23:28.05 ID:D1bqYp6J.net]: >>770
え？？
782 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 18:26:14.33 ID:AQu1Dr63.net]: >>768
自動変換は正直意味不明だが（変換元の文字コードが判定不能なのに何を変換するのか？）
argsは今RFC出したらResultにしろって突っ込まれると思うし
1.0であまり深く考えずに入れちゃった気はするよ
783 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 18:50:02.66 ID:5HDpMmrb.net]: Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う

argsじゃなくてargs_utf8onlyとか名前をダサくして
逆にargs_osを元のargsに戻しとけば
リファレンスをよく読まない人たちがつまづく可能性を下げられる
784 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:00:18.55 ID:65hs2nTl.net]: こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。

Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。
785 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:01:34.27 ID:MMJHgfnp.net]: >>772
自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない
786 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:14:39.18 ID:9A8KMAyG.net]: 自動変換とかそんなアホなこと言ってるのはあんただけやで
そんなものは無いし必要ない
787 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:18:07.57 ID:MMJHgfnp.net]: こいつOsStringの概念が分かってないのか
本当に知能レベルが低すぎる
788 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:45:20.62 ID:AQu1Dr63.net]: OsStringはOSから渡されたバイト列をそのまま格納するだけで
EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが…
789 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:49:39.48 ID:MMJHgfnp.net]: 想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる

結局内部で使う場合は簡単にutf8に変換してる
なにからutf8に変化するか指示も必要がない
ただのボイラープレート
790 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:58:53.67 ID:ArOBrbBE.net]: >>777
自動変換なんてものはない
むしろ自動変換を避けるために用意されているのがOsString
もちろん自動変換は行われない
791 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 20:02:00.63 ID:MMJHgfnp.net]: 人間じゃなくて壊れたロボットに話しているようだな
いくつになろうとこんなダメな人間になってはいけないな
792 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 20:16:20.94 ID:il94IOIF.net]: ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって
どんなエンコーディングの文字列でも統一的に扱うことができましゅ
Rustもまだまだでしゅね
793 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 20:44:42.25 ID:xJ62MSkB.net]: ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる
もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある
794 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 21:30:38.14 ID:nN1vQ+Ae.net]: 文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。
795 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 21:49:41.83 ID:tlaf0qkO.net]: めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？
複オジは昔の自分を諭してる気分じゃないか？
796 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 22:41:53.26 ID:MMJHgfnp.net]: Rustが正しいの一点張りの狂人
797 名前：デフォルトの名無しさん [2024/04/25(木) 01:24:12.71 ID:fpMjozoS.net]: >>0774
お前の着眼点は凄えよ！感動した。
その通り、Rustは初心者/素人御用達言語だよ。
798 名前：デフォルトの名無しさん mailto:sage [2024/04/25(木) 07:30:11.27 ID:xsazBswH.net]: おじいちゃん誰にも相手にされず寂しくなったんだねw
799 名前：デフォルトの名無しさん [2024/04/27(土) 03:20:12.65 ID:nhA0znD3.net]: 聞き分けることができない。
https://kanji.reader.bz/pronunciations/last,lust,rust
800 名前：デフォルトの名無しさん [2024/04/27(土) 21:28:13.67 ID:+PotGQRe.net]: crates.io が死んだときはどうすれば良い？
801 名前：デフォルトの名無しさん mailto:sage [2024/04/27(土) 21:31:55.69 ID:Ik8q0/YE.net]: cargo run --offline
802 名前：デフォルトの名無しさん mailto:sage [2024/04/28(日) 09:02:55.08 ID:nHdP2D/h.net]: ミラーサイトとか無いんだっけ？
803 名前：デフォルトの名無しさん [2024/04/29(月) 14:17:37.62 ID:wZNa4EA4.net]: 5chが荒らされてる時はどうすれば良い？
804 名前：デフォルトの名無しさん [2024/04/29(月) 16:10:30.59 ID:E9KMHG2x.net]: 取り敢えずアゲとけばいいんじゃね？
805 名前：デフォルトの名無しさん mailto:sage [2024/04/30(火) 02:47:45.81 ID:Mf3BeDX5.net]: したらば掲示板あたりに避難所作っておけばいかが
806 名前：デフォルトの名無しさん [2024/04/30(火) 03:09:09.37 ID:LM/x1iE2.net]: 落ち着いてpanicしよう
807 名前：デフォルトの名無しさん mailto:sage [2024/04/30(火) 07:30:51.55 ID:QURaxzoQ.net]: core吐きそう
808 名前：デフォルトの名無しさん mailto:sage [2024/05/01(水) 23:17:38.38 ID:7162bhB/.net]: python みたいに何でも格納できる辞書型ってC++には無いよね？
809 名前：デフォルトの名無しさん mailto:sage [2024/05/02(木) 02:40:57.58 ID:VpjL2uZS.net]: enumも弱いなあ
810 名前：デフォルトの名無しさん mailto:sage [2024/05/02(木) 18:14:15.88 ID:MEkFc6Ha.net]: anyとmap組み合わせればいいんじゃね？
ここRustスレだけど
811 名前：デフォルトの名無しさん mailto:sage [2024/05/02(木) 20:59:19.04 ID:AhHSwsoc.net]: Rustで辞書型はHashMap
複数の型を格納したかったらenumかdyn Trait
TraitをAnyにするならdowncastして使う
実際には共通に処理したい目的があるはずなのでそのTraitを用意すればdowncastしなくて済む
812 名前：デフォルトの名無しさん mailto:sage [2024/05/03(金) 11:35:32.62 ID:nLK8l4in.net]: pythonみたいにだからclassがわりなのかも

p["name"]="yamada taro";
p["age"]=25;
みたいなのかな
いずれにしてもC++じゃないので
813 名前：デフォルトの名無しさん mailto:sage [2024/05/03(金) 23:02:14.16 ID:NBKkZegt.net]: 静的型付けの有用性が大きく上回るから
そのケースならstructにするだろうし
色んな型を横断的に扱いたいケースならtraitかな
814 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 04:23:28.64 ID:hKZu/p+3.net]: https://pbs.twimg.com/media/GLs31gXbYAA6xIr.jpg
815 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 09:38:11.89 ID:dspjTuTH.net]: GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ？
816 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 12:00:07.75 ID:GFUvMaSe.net]: tauri?
817 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 12:04:17.00 ID:WHGnbjEl.net]: UIはもうネイティブにこだわらなくてもいいんじゃないかな
昔からwebでしかUI提供してないソフトはゴロゴロある
818 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 15:02:31.51 ID:UtcYFhat.net]: 用途次第
WebベースのUIでは反応速度が遅すぎる場合もあるしサイズが許容できない場合もある
819 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 15:44:19.83 ID:oqQ8V/k0.net]: Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽……
みたいな言説もあるが、 WebView の種類・バージョンを固定できないから変化に追従する必要が生じる。
そもそもウェブの世界は変遷が激しい。
Living Standard ってなんやねん。普通の産業の感覚では信じられんようなことをしやがる。
元からウェブ系のスキルセットを持っている人が開発してメンテナンスもするってのなら
Tauri は良い選択肢だと思うが、それなりにデメリットもあるよ。

ただ、多言語 (というか Unicode) に隅々まで対応しているようなフレームワークってことになると
ウェブ系の基盤がめちゃくちゃ整備されているのでそこらへんは唯一無二だわ。
820 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:01:23.73 ID:WHGnbjEl.net]: 即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって
そうでない場合は普通にhtmlで
821 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:07:02.02 ID:lP1zz7vp.net]: 実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい
常駐の軽いアプリを作りたい場合なんかは特に
822 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:07:49.70 ID:oqQ8V/k0.net]: UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。
元はドキュメント記述用だったのに html5 から大幅に路線変更してアプリケーション基盤として再編したけどどう見たって無茶苦茶だ。
ウェブの人が使う分にはこれでいいことは否定しないけど、 UI 記述の「普通」ではない。
823 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:17:08.35 ID:5ROxz5B4.net]: UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ

MFCやCocoaやGTK的なものが今では逆に「普通」ではない
824 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:22:01.06 ID:WHGnbjEl.net]: html5は死んだ
もうどこにも存在しない
825 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:22:16.16 ID:oqQ8V/k0.net]: >>813
宣言的がどうこうとかいう問題ではなく html が「普通」ではないと述べてる。
これが良いとか悪いとか言ってるわけではないよ。
まず第一に選ぶべき「普通」だとする論を否定してる。
826 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:58:29.96 ID:uscJJ1KS.net]: じゃあslint?
827 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 18:05:18.74 ID:uscJJ1KS.net]: 何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな…

tauriは環境構築する段階でnodeのバージョンやら依存ライブラリの不備でエラーがでてしまい結構時間が掛かってしまった
828 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 18:12:14.00 ID:WHGnbjEl.net]: デスクトップアプリのここにグラフ出してくださいって言われて
対応できる環境は少ない
829 名前：デフォルトの名無しさん [2024/05/04(土) 19:49:33.93 ID:kEH6RwVz.net]: 他にいい表現方法があるなら自分で作って使ってりゃいいじゃん
830 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 21:10:45.57 ID:D/qKI/dJ.net]: dioxusはあんま使われてない感じ？
831 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 23:00:15.61 ID:ycOsd5I6.net]: iced.rs
832 名前：デフォルトの名無しさん [2024/05/05(日) 10:17:39.98 ID:k5d9I+SK.net]: >>821
Elm Architectureの設計パターンを覚える必要があるけどなかなかいいですね
833 名前：デフォルトの名無しさん mailto:sage [2024/05/05(日) 18:52:14.60 ID:k5d9I+SK.net]: 試してみたけど導入のカウンタの例がいきなりビルド出来ない…

バージョンの変更にドキュメントが追いついていないのは残念ですね…
834 名前：デフォルトの名無しさん mailto:sage [2024/05/05(日) 23:14:06.38 ID:XwodnLf4.net]: freyaはどう？
835 名前：デフォルトの名無しさん mailto:sage [2024/05/09(木) 16:51:54.63 ID:7kteiv59.net]: https://blog.logrocket.com/state-rust-gui-libraries/
836 名前：デフォルトの名無しさん mailto:sage [2024/05/09(木) 22:53:04.47 ID:mHp10mC4.net]: 一覧
https://lib.rs/keywords/cross-platform-gui
837 名前：デフォルトの名無しさん mailto:sage [2024/05/10(金) 22:11:46.56 ID:R/1AnZ57.net]: Edera
838 名前：デフォルトの名無しさん [2024/05/11(土) 15:19:35.98 ID:7ZNhzC0A.net]: https://loglog.games/blog/leaving-rust-gamedev/
Rustはゲーム開発に向いてないという記事
C/C++を置き換えるという目標がまた一つ遠のいてしまったな
839 名前：デフォルトの名無しさん [2024/05/11(土) 16:10:55.98 ID:cPH9qnwk.net]: Rust製ゲームエンジンが未成熟なんだから当たり前だろ😅
840 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 17:53:51.16 ID:PRiIqFBU.net]: Web開発は素早い実装と更新が必要だから
Rustは向いてない動的型言語が向いてる
みたいな記事は昔あった気がする
841 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 18:07:19.67 ID:YXABt1rM.net]: >>828
＞Rustが上手くなれば、これらの問題はすべて解消されます。
＞Rustは大規模なリファクタリングに優れているため、
＞borrowチェッカーのほとんどが自業自得の問題を解決します。
＞十分な経験を積めば、ユーザーは考えずにそれらを完全に予測し、生産的になります。
＞私はRustでさまざまなユーティリティやCLIツールを書くのをとても楽しんでいますが、
＞数行のコード以外はPythonよりも生産性が高いことがわかりました。
＞「コンパイラ駆動開発」をどこまで進めて、実際に成功できるのかと驚いたことが何度もあります。
＞Rustの最大の強みは、Rustにふさわしいコードを書いていると、物事が非常にうまくいき、
＞言語がユーザーを正しい道に導いてくれることです。
842 名前：デフォルトの名無しさん [2024/05/11(土) 19:27:53.90 ID:3IwrsNfE.net]: >>828
この記事、ゲーム開発においていかにUnityがすばらしいかを伝えたいだけじゃん
843 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 06:43:20.67 ID:k1k0SaOB.net]: >>831
エキスパート専用、初心者お断り
というRustのいつもの欠点。
844 名前：デフォルトの名無しさん [2024/05/12(日) 11:56:37.24 ID:WctoPZ5N.net]: ずいぶん過疎ってるけどどんぐりのせいなんかね？
845 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 12:01:04.30 ID:ReOJFzuL.net]: c++を完璧に使いこなせばrustは不要とか
いうのは欠点ではないの？
846 名前：デフォルトの名無しさん [2024/05/12(日) 12:04:43.22 ID:qXz8Kn6F.net]: それは本人の練度の問題やんけ
847 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 12:33:17.76 ID:ybg7kEk2.net]: >>835
政府レベルで脱C/C++推奨してるのよ
ソース記事>>500
848 名前：デフォルトの名無しさん [2024/05/12(日) 13:10:14.91 ID:ytouLwn1.net]: 政府のお墨付きは強いカードだ
849 名前： 警備員[Lv.1][新初] mailto:sage [2024/05/12(日) 15:34:04.32 ID:bb5m7yXX.net]: 書き込めない
850 名前：デフォルトの名無しさん [2024/05/12(日) 17:53:27.59 ID:YZSMKp1R.net]: tauriがだいぶ普及してrustに手を出す人が増えたね
いい傾向だ
851 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 23:38:46.27 ID:dSHQVPuW.net]: Tauriで流入した人の多くはフロント側 (JavaScript, TypeScript) の技術者な気がする
「ほぼRust書かずにTypeScriptでできますれ」みたいな言説も見かけるくらいだし
実際そのアプローチはありだろうしRustの認知度にも寄与するだろうけど、純Rustのフレームワークも成熟して欲しいところ
852 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 23:46:56.69 ID:y8qBeNSM.net]: ガワをRustで書いただけで何が嬉しいことでもあるんか？
私はRust使ってますって言えるから？
853 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 00:38:30.52 ID:DdLtk1MY.net]: 繰り返しになるが GUI 記述として html ベース、ウェブベースの制御はそんなに筋が良くない。
根本的に GUI に対する要求が複雑だから万能を目指したフレームワークはだいたいそうなるものではあるんだが
逆に言えば万能でなくてよいときに使うにはウェブウィジットはリッチすぎる。

それとウェブ世界の living standard という体制に不信感がある。
ウェブ世界ではそれで良いにしてもどこでもその考え方が通用するわけではない。
854 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 02:02:04.61 ID:TEcr6tUj.net]: >>843
抽象的な欠点あげつらうのは役に立たないんで
今普及してるguiツールキットでおすすめと
その理由は？
855 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 02:21:51.83 ID:DdLtk1MY.net]: >>844
Tauri がウェブフレームワークに依存しているのが悪いというのは具体的ではないんか？
それが良い場合もあるので何が良いかは結局のところ場合によるとしか言えない。
そりゃそうだろ。
ウェブフレームワークを活用できることとウェブフレームワークに縛られることは表裏一体で
活用しつつ欠点から逃れるなんていう都合の良い話はないというごく普通のことを言いたいだけ。
856 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 02:31:51.65 ID:TEcr6tUj.net]: >>845
ウェブguiの欠点が全く具体的じゃないし
場合によるというなら役に立つ場合に使えばいいよね
で話はおしまいなんで何も役に立たない
話だね
857 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:08:04.24 ID:DdLtk1MY.net]: >>846
ウェブフレームワークの欠点なんかいまさら説明せなあかんようなこと？
役に立つ場合には使えばいいってのは当然の大前提で、
話題の流れとしては >>842 に対して「全ての」場合に Tauri がマッチするわけない
(ので色々な選択肢が出てくるに越したことは無い) って話じゃん。

これから生まれる (生まれていない) 色々なプロジェクトのどれがどういう状況で役立つかなんか事前にわかったら苦労はないわ。
色々出て来て色々消えるのも当然のことで、
Rust スレなんだから純 Rust で出来るものも有って欲しいという期待は自然なものだろ。
858 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:11:17.53 ID:7xLbVW9j.net]: QtレベルのフレームワークがRustで書けるならそれは嬉しいけどね
開発者のモチベが続かないような気がする
あまりにもゼロから実装しなきゃならんし
859 名前：デフォルトの名無しさん [2024/05/13(月) 03:11:29.07 ID:To2vSRYZ.net]: デザイン系の人の大多数がウェブアプリ開発をできるからTauriは高需要でいいと思う
そもTauriはRustが主役のフレームワークじゃないんだからあーだこーだ言う必要なし
世間の知名度が上がる道具になってくれれば十分ってもんよ
860 名前：デフォルトの名無しさん [2024/05/13(月) 03:17:53.91 ID:+k5+3Net.net]: デスクトップアプリ自体需要低下が著しいわけで、いまさら新しいGUIフレームワーク作りましたって誰も使わんわ
WPFすら将来性が怪しまれてるのに
861 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:26:50.43 ID:7xLbVW9j.net]: ちなみに全てゼロから実装してるGoのGUIフレームワークのgokiは6年以上開発しててまだ完成しない
描画から全部作ってる
そしてついに開発者が飽きた

同じくgoのfyneも5年ぐらい開発してこちらもOpenGLでゴリゴリやってるようだが
すでにOpenGLは時代遅れだし
すでに開発者が飽き気味
862 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:46:12.80 ID:FJrB7Dif.net]: ウェブまわり自体がクソってのには賛同するけど、これまでの莫大な資産や個々の経験の後押しが需要を押し上げるんだから仕方ない
どれだけRust由来のGUIフレームワークを望んだとしても負ける未来しかないんだ
WPFもWinUI3もFlutterもComposeも頑張ってるけど勝てないんだ
863 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 06:53:31.41 ID:NqUrzczE.net]: >>825
Rust GUI framework performance comparison
lukaskalbertodt.github.io/2023/02/03/tauri-iced-egui-performance-comparison.html
864 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 08:41:01.54 ID:1UkfuR6U.net]: 可能性があるとすると組み込み系かなぁ
車載GUIにUnityとか検討してるとこはあるみたいだけど、多少描画がバグってもいいゲームとは違うし
Rustの安定性が求められる領域ではあると思う
slintなんかはそちらを目指しているように見える
865 名前：デフォルトの名無しさん [2024/05/13(月) 10:36:48.17 ID:gtcOXaAe.net]: フロントについてこういうカッチかちの言語でうまくと思ってるやつは実際にコード書いてないのがバレバレだよ
866 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 11:03:56.17 ID:TEcr6tUj.net]: >>847
こういうアプリ作りたいならウェブ技術・
tauriは論外くらい言ってくれよ
867 名前：デフォルトの名無しさん [2024/05/13(月) 11:12:58.92 ID:2BkgcWoG.net]: >>848
QtのRustバインディングがもっと進歩すればなあ。
JS系はreact圧倒的に強いからQMLなんて絶対流行らんだろうに
868 名前：デフォルトの名無しさん [2024/05/13(月) 11:14:38.81 ID:BwU1QaNs.net]: RustのGUIフレームワークを気になって色々見てたけどどれもよくあるレンダリングエンジンのWebGPU、Vulkan、OpenGL、SkiaをRustラップしてるだけじゃんね
純粋なRust製レンダリングエンジンはどこだよ
869 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 12:01:14.07 ID:7xLbVW9j.net]: >>858
今時自前で描画なんてやる訳ないだろ
なんのためにGPUがあるんだ
870 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 12:47:01.47 ID:nhWWGTo5.net]: WebGPUの参照実装であるwgpuは純Rust製だと思ってるけど違うんかね？
871 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 13:02:11.22 ID:LO420and.net]: >>858
少なくともOpenGLとVulkanはグラフィックAPIなんだからラップするのは普通でしょ
872 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 15:33:49.11 ID:Y2zR27Yz.net]: tauriはロジック部分をrustで書きやすいんでしょ？理想的じゃないか
フロントとバックで得意分野の棲み分けができてて賢いフレームワーク
873 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 16:08:29.50 ID:DdLtk1MY.net]: だから Tauri が悪いという論じゃないんだ。
他の選択肢がいっぱいあると嬉しいねって話なんだってば。
874 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 21:28:07.97 ID:59wZgx8n.net]: 神学論争じゃなくてエンジニアリングとして
tauriではこんなアプリ作るべきじゃない
理由はこんな欠点があるからという
話してくれれば良いだけなんだが
875 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 22:14:06.95 ID:ZPj3lkv2.net]: GUIといっても多種多様に分かれて共存しておりRustでも色々なライブラリがある
slintのように軽量重視もあれば
eguiのように(一般的な保持モードとは異なり)即時モード採用もあったり
tauriのようにWebと同じ枠組みを使うことで同じ知識の活用とWebアプリとの共通化をはかるものもあり
他にも様々なものがある
前提環境抜きで特定のものを批判してる人はおかしい
876 名前：デフォルトの名無しさん mailto:sage [2024/05/14(火) 07:45:48.78 ID:6cY0CvIK.net]: みんな違ってみんな良い
877 名前：デフォルトの名無しさん mailto:sage [2024/05/14(火) 08:57:53.35 ID:xCwyd0xz.net]: slintは素直でとっつきやすかったな
icedは変化が激しいのか入門もさせてもらえない…
878 名前：デフォルトの名無しさん mailto:sage [2024/05/14(火) 23:21:46.80 ID:hA3mS4wv.net]: LambdaはRustで書くのが定番になってきたな
879 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 00:25:29.32 ID:pg7m6itF.net]: 何より悲しい一人ランバダ
880 名前：デフォルトの名無しさん [2024/05/15(水) 04:42:11.15 ID:NcaIPB0V.net]: わしウェブ系技術ってのが嫌いやねん
881 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 06:07:55.49 ID:HCR4HRqT.net]: 具体的に指摘できない人は単なる無知か落ちこぼれ
882 名前：デフォルトの名無しさん [2024/05/15(水) 09:47:09.65 ID:qxOWZ5PZ.net]: tauriは�
883 名前：@く要素が特にない electronのデメリットを克服しつつも既存の普及済み技術を集合させた感じなんだもの tauri導入における敷居の低さはあっぱれとしか言いようがない ウェブ技術やってない人はこれを機会にreactを勉強したらいいよ []: [ここ壊れてます]
884 名前：デフォルトの名無しさん [2024/05/15(水) 11:23:11.20 ID:z848GXEz.net]: なんかもう面倒臭いしバックエンドもnode.jsでいい気がしてきた
885 名前：デフォルトの名無しさん [2024/05/15(水) 14:38:34.92 ID:h8Rmia3E.net]: 結局最初はrailsでokみたいなのが最近の流れでしょ。
そこから開発規模に沿ってどう分割していくかってのが最近のテーマではあると思うけど。
最初からかっちり開発しましょうなんて20年前のお花畑理論でしかないわな。
886 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 15:28:41.91 ID:aizlqnqQ.net]: ネイティブGUIアプリの話にRails関係ないだろ

Web開発でもとりあえずRailsのピークは過ぎ去ってるぞ
887 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 15:31:56.50 ID:5ypavdrK.net]: tauriはデータの受け渡しが遅すぎる
888 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:29:56.86 ID:0QhUyids.net]: モダンなGUIアーキテクチャでRust書きたいよ
今のは全部古すぎる
889 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:33:24.96 ID:V9iVMFnF.net]: >>875
ネイティブGUIアプリじゃなくてデスクトップGUIアプリやろ
まさかTauriはネイティブ扱いとか言わんよな？
890 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:39:14.07 ID:aizlqnqQ.net]: >>878
何言ってるのか意味わからんので
あなたのネイティブGUIアプリと
デスクトップGUIアプリの定義と
その違いを説明してくれ
891 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:42:32.92 ID:0QhUyids.net]: デスクトップGUIはWebViewを使ったガワアプリも含まれるって意味だろ
892 名前：デフォルトの名無しさん [2024/05/15(水) 17:30:27.13 ID:hv8buZEp.net]: めんどくさいからデスクトップアプリでいいよ
893 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 18:24:29.03 ID:xsUSdCEo.net]: >>879
一般的にネイティブアプリとは各プラットフォームでネイティブとされてるUIコンポーネントや開発ツールを使って作られたもの
デスクトップアプリはWindows・macOS・Linuxなどのデスクトッププラットフォーム上で実行されるアプリ
(どちらも基本的にGUIアプリについてのみ使われる言葉)

例えばJavaで作ったデスクトップアプリは一般的にネイティブアプリとは呼ばれないが
Java(とJetpack Compose)で作ったAndroidアプリはネイティブアプリと呼ばれる
894 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 18:30:24.12 ID:4Z0tBK25.net]: Visual Studio Codeはネイティブアプリですか？
895 名前：デフォルトの名無しさん [2024/05/15(水) 18:35:01.39 ID:NOtrSmJC.net]: >>883
ガワアプリです
896 名前：デフォルトの名無しさん [2024/05/15(水) 19:01:08.64 ID:xxmBp0ld.net]: tauriはフロント側をrustで書けないのがきつい
yewとかで頑張ればrustでやれなくはないけど素直にjs使った方がいいし
897 名前：デフォルトの名無しさん [2024/05/15(水) 19:44:27.90 ID:bSYaxLzm.net]: フロントは成熟したフレームワークを使いたいからhtmljs仕様なのはむしろ助かることない？
898 名前：デフォルトの名無しさん [2024/05/15(水) 19:49:50.25 ID:rWGs03Ps.net]: TauriはOS付属のWebViewを下地にして動くことを売りにしてるんだからRustでフロント書きたい人は最初からお客様じゃないぞ
本気でYewでひーひー言いながら書くつもりか？
899 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 23:50:43.95 ID:s3H9dEcY.net]: フロントエンドをHTML/CSS/JavaScript以外で書く人がもうほとんどいない
ただしJavaScriptを直接書かなくてもWebAssemblyで好きな言語で書くのは構わないし同じWeb枠組みの範囲内の話
900 名前：デフォルトの名無しさん [2024/05/16(木) 00:16:06.21 ID:1J3uYj1b.net]: >>888
結局これだよな。JS以外のクロスプラットフォームなフロントエンドってほとんど無いんだからそこはもう諦めたほうが
901 名前：デフォルトの名無しさん [2024/05/16(木) 00:39:52.36 ID:OUQcYMxX.net]: そもそもrust推すやつはフロントエンドなんて全く好きじゃないだろ。
902 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 00:53:56.65 ID:hXehBl/a.net]: フロントエンドだけでは何もできなくて
バックエンドや裏はRust採用がリソースコストを最小にできる
そのためのクラウドでのコードもクラウドインフラ自体もRustで記述
さらにCDNインフラ自体もCDNエッジでのコードもRustで記述
903 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 01:44:19.55 ID:i/RRcUKc.net]: >>872
何にしたって否応なくトレードオフはある。
Electoron のデメリットを克服したといっても
その替わりに Electoron に無かったデメリットも生じてる。

たとえば WebView を抱え込まない (実行環境にあるのを使う) のは
実行環境のエコシステムとの連携が必須ってことだ。
基本的にはちゃんとサポートが続いているバージョンの実行環境を使えって話ではあるけどさ、
そうもいかんこともあるのも現実なんよ。

Tauri を叩いてるやつなんていないよ。
まさか「あらゆる」 UI を Tauri でなんとかできると思ってるわけじゃないだろ？という話。
比較的には有力とは言えるだろうけども。
904 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 01:56:21.83 ID:g8xzkHEo.net]: 仮想のtauri狂信者を叩いてるのが一人いるのはわかった
905 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 02:15:18.77 ID:8s3HDjEn.net]: そんなに熱くならんでも良い
Tauriガワ＋Rustビジネスロジックな本格的定番デスクトップアプリが
未だに存在しないから察しろ
906 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 15:17:12.19 ID:DDVd9f//.net]: 察しろって歴史が浅いだけでは
907 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 18:07:35.69 ID:2492rnzS.net]: >>891
そこまで行くのに何十年掛かるんだろうなぁ
908 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 18:37:15.15 ID:hXehBl/a.net]: >>896
既にRustで記述されているという現在の話だぞ
Rustで記述されているソース記事は>>51
909 名前：デフォルトの名無しさん [2024/05/16(木) 23:54:35.57 ID:4W8w/h2s.net]: 何十年かかろうがRustが普及するのは事実
乗り遅れるなよ？
910 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 23:57:43.65 ID:sN6tl8jZ.net]: 既にそれらクラウドやCDNのインフラはRust製へ切り替わっていってるし
その上で動くユーザーコードも従量制コストのためRustが採用されてるね
911 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 00:37:51.70 ID:lOJfePdD.net]: Rust2024次第や
912 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 14:37:51.89 ID:R46RaGVX.net]: >>898
そうやって何十年騙されてきたんだろう
913 名前：デフォルトの名無しさん [2024/05/17(金) 17:27:00.95 ID:fyAXY6lw.net]: Rustって、学習コストていうか、習得難易度が高いらしいね
914 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 18:13:44.03 ID:63RUfPPA.net]: 本来ちゃんと考えなきゃいけないものをランタイムがやってくれるからって
思考放棄してた部分が表に出てきただけなんだよね
例えば優秀な人はCでもポインタ一つとってもその意味するところが何か、所有するのか、弱参照なのかを意識するし
オブジェクトの管理に参照カウントを実装しているだろう
実際至高のCプログラムであるlinuxカーネルはそのような作りになっている
優秀な人は凡人に見えていないものが見えてるんだよね
915 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 18:50:38.58 ID:x3ZQoGKy.net]: >>903
>実際至高のCプログラムであるlinuxカーネルはそのような作りになっている
>優秀な人は凡人に見えていないものが見えてるんだよね
そして年間数百個の脆弱性を生む結果となっている
真に優秀なら当然そんな結果はもたらさない

自分が優秀だと勘違いしてる人は凡人にすら見える当たり前ことが見えてないんだよね
916 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 19:03:33.62 ID:63RUfPPA.net]: >>904
脆弱性ゼロというのはありえないというのはわかる？
917 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 19:06:03.74 ID:FyQgq0p4.net]: >>903
そのランタイムに任せて非効率になる道と
人が頑張って効率的になるが脆弱性も生じる道の2つしか従来なかったところに
第3の道として効率的かつ安全が保証されるRustが登場して解決した
918 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 19:45:03.26 ID:S7DVNM0H.net]: >>899
Rustが向いてそうなOSやハイパーバイザが
まだまだじゃない？
919 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:17:03.89 ID:Bzly/lr+.net]: それなら有志団体のProssimoあたりがRust移植を資金調達しながらやってるじゃない
焦らんでも数十年後にはRustがそれなりに普及してるよ
920 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:33:12.91 ID:Bflq38Ga.net]: 初心者向けRustが無ければ無理じゃない？
921 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:36:48.91 ID:ljCa+132.net]: マンガで読むrust入門とか小学生向けの本が出れば本格的普及かな
922 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:39:02.47 ID:Bflq38Ga.net]: 最初にスタックフレームの説明から入るのか。

胸熱だな。
923 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:01:30.45 ID:xPWhJeFc.net]: バカと初心者は遅いバカ向け言語でいいんだよ
バカでなければその後にRustに行き着くから
924 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:10:07.25 ID:FOdKNTRJ.net]: 単に sudo を rust で書き直すのにもわりかし時間かかってるよな。
925 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:18:42.19 ID:63RUfPPA.net]: 昔のCでよくある
hoge = update_hoge(hoge);
みたいなプログラムはRustに移植するのがクソ大変なんだよ
古いプログラムだとこの手のコードが大量に出てくる
実質データ構造から全て書き直しになって移植に時間がかかる
926 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:23:31.52 ID:MaibK+2h.net]: >>914
>クソ大変

なんで?
927 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:25:38.04 ID:ljCa+132.net]: rustを選民意識で使ってる奴とかいる？
928 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:26:53.82 ID:5wpOXFHi.net]: インターネットドメインの無償TLS証明書であるLet's Encryptなどを運用している非営利団体ISRG (Internet Security Research Group)のProssimoプロジェクトは二つの目標を掲げている。
「私たちの目標は二つある。1つは、インターネットを支えるソフトウェアインフラをメモリ安全のコードに書き換えること。もう1つは、メモリ安全性に関する人々の考え方を変えることだ。『C』や『C++』のようなメモリ安全ではない言語で書かれたソフトウェアを展開するのは危険だという証拠があるにもかかわらず使われ続けており、人々がそのリスクを十分に認識し、メモリ安全性をソフトウェアの要件と見なすようにしたい。」
このソフトウェアインフラのメモリ安全性向上に向けて取り組むProssimoプロジェクトの一環として、suやsudoなどのセキュリティユーティリティーを「Rust」で再実装して広める活動も行われている。
929 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:29:19.78 ID:qNukMIkl.net]: コンピュータリテラシーの低い人を増やしまくった結果セキュリティ事故祭りになっているのでは？
930 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:44:22.72 ID:GF5EVhbY.net]: >>914
>> hoge = update_hoge(hoge);

その例だけなら以下で終わるから説明不十分
update_hoge(&mut hoge);

もちろんこれはメソッド化して
impl Hoge {
　fn update(&mut self) {
呼び出しはhoge.update()

これで終わる話だから
おそらく元のC言語コードがグローバル変数を使うなど酷い状態なのだろう
931 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:49:13.20 ID:6kFr2fm8.net]: >>917
C/C++を捨てる方向でどこも同じか
>>500で米政府も表明してるしな
932 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:24:35.35 ID:63RUfPPA.net]: >>915
当たり前だがhogeはヒープで確保されており
あらゆるところで参照、保持、変更されうる場合がある
よってRcにて管理する必要がある
当然Rcの中のオブジェクトを変更できないと意味がない
つまりCellなりRefCellが必要となる
そして循環参照の問題もあるので弱参照を考えなきゃならん
このようにちょっとしたコードでも単純に移植することが難しい
rust wayな方法で書き直すしかない
933 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:35:22.67 ID:mTdFoxaI.net]: sudoが時間かかってるのは単にそれなりの規模だからってだけだと思うけどな
あとsudo風の代替品ではなくてそのまま入れ替え可能なものを目指してるから
仕様の把握と一致検証にも時間がかかるだろうし
934 名前：デフォルトの名無しさん [2024/05/17(金) 22:36:32.50 ID:JB0Glcw4.net]: ゲーム開発に向かないからC/C++が残ることが確定してしまった
935 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:37:07.66 ID:GF5EVhbY.net]: >>921
Rcは必要ない
Rcは所有者が複数になった時のみ登場
936 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:38:27.40 ID:5wpOXFHi.net]: >>923
そんな話は聞いたことがない
937 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:42:58.17 ID:cCnlY4YV.net]: Rustゲームエンジン開発なんざ勝手にやっとけって感じ
セキュリティ脆弱性が致命的になる分野でのRustへの移植が大事なんだから
938 名前：デフォルトの名無しさん [2024/05/17(金) 22:44:28.89 ID:JB0Glcw4.net]: >>925
ゲーム会社でRustを採用しようとするところが全然出てこない
それが答えだよ
939 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:58:43.56 ID:BR1qVngc.net]: 巨大なC/C++遺産ですぐに動けないだけでおそらく少しずつ進めているのだろう
もし何ら対策しないところがあるとすればそのゲーム会社だけ取り残されるのだろう
940 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 23:17:51.68 ID:+PGm3s9t.net]: ゲームなんていう表層的な分野でRustは採用なんてされてないだぁ！って駄々をこねられてもねえ
941 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 23:57:11.09 ID:BR1qVngc.net]: 分野によって対応の時間差が出るだろうけど
C/C++排除の流れは止まらない
942 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 00:25:26.98 ID:Hzmk0zu+.net]: 少なくともアメリカの軍事分野の制御システムは>>500の声明のとおり最優先でC/C++からRustへの置き換えられるのが確定してるし民間に広まるのは時間の問題
943 名前：デフォルトの名無しさん [2024/05/18(土) 00:35:56.17 ID:woQdAE7H.net]: DirectX、OpenGL、Vulkanといった主要なグラフィックスAPIがC/C++で作られてるし
ゲーム分野が仮にRustに置き換わるにしろ数十年はかかりそう
944 名前：デフォルトの名無しさん [2024/05/18(土) 06:54:07.34 ID:CGudIpEF.net]: ポインタの概念を経由しないでrustから入るってほぼ無理だと思うけどね。
rustから入ればc/c++はいらないって人はその辺を誤魔化しすぎてんだよ。
945 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 09:05:31.34 ID:knMB7JYq.net]: ポインタの概念の理解は必要だけど C の構文は理解困難なのよね。
946 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 10:36:57.70 ID:Fx9Rd4Sf.net]: rustがメインで使われるようになろうとも、組み込み系の最初の学習教材としてはC言語が一番扱いやすいから大学で組み込み系での実践言語として今後も使われていくよ
一定数ははじめからRustを教えたりJavaを教えるところもあるかもだけど
947 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 10:48:07.73 ID:XduL+8Iy.net]: なんか勝手に組み込みの話にされてるけどゲームはC/C++が残り続けるよ
Rustでゲームを作るのは流行らない
948 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 18:43:24.68 ID:Olj0jDDg.net]: 政府レベルで勧告しているから少なくともビジネスレベルやその製品まではC/C++が排除されてRustへ置き換わる
ゲームのような枝葉末節は知らん
949 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 19:54:53.77 ID:JFC2kl3y.net]: ゲーム作る人大半の人は、言語じゃなくて、
どんなゲームエンジンを使うかしか意識しないでしょ。

まずは、メジャーなゲームエンジンに、
Rustが採用されるところからじゃない。
950 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 20:34:58.97 ID:knMB7JYq.net]: Rustでゲームは向かないみたいな記事はあったけど、あれもゲームエンジンのレイヤとかではなくてもっと上のゲーム固有のロジックを記述する時にRustは向かないというだけの話じゃなかったか？
951 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 08:21:11.59 ID:J8UPACIo.net]: ゲーム固有の言語と汎用の低級言語の二つを採用するのが良い
でも上のレイヤはGUIとかデータ記述言語とかで置き換えられ
ロジックを記述する言語は一つしか採用されないみたいな思想の人もいるかな
952 名前：デフォルトの名無しさん [2024/05/19(日) 13:44:20.88 ID:UOsr9CB4.net]: >>938
まともなゲーム会社はエンジンを内製するんで何の言語使うかとても意識するけど
953 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 14:21:47.30 ID:9ppbKK2j.net]: 改造とかカスタマイズはするかもしれんが、まともなところイコール内製は成立しないんじゃないかな。
954 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 14:58:26.82 ID:9JWy2KZh.net]: 数年前にもRustはゴミ。使う奴なんていないみたいなことを言っている奴がいた気がするが
955 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 15:44:35.31 ID:J8UPACIo.net]: じつはLLVMのインフラを捨てずカスタマイズしたのがRust
逆に、プロトコルの互換性はあっても
古い実装と古いコンテンツを捨ててしまうのがインターネットでしょ
956 名前：デフォルトの名無しさん [2024/05/20(月) 11:59:29.58 ID:yyhnuWrn.net]: でもお前ミドルウェアとか全く書かないじゃんってやつばっかなのになぜかrust使おうとするやつ
957 名前：デフォルトの名無しさん mailto:sage [2024/05/20(月) 18:43:29.11 ID:4ugUfB32.net]: 似たような理屈で
循環参照を全くやらないやつはmark&sweepを禁止される
958 名前：デフォルトの名無しさん mailto:sage [2024/05/22(水) 21:52:53.58 ID:0G81pYpr.net]: JetBrains開発Rust用IDEのRustRoverが安定版リリースに向けてライセンス体系を発表したけど非商用無料で使わせて貰えるみたい
ttps://blog.jetbrains.com/rust/2024/05/21/rustrover-is-released-and-includes-a-free-non-commercial-option/
959 名前：デフォルトの名無しさん [2024/05/23(木) 02:03:24.72 ID:zV267ZMC.net]: おお　(^－^)
960 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 06:59:30.95 ID:nsNudoX6.net]: RustRover 優秀そうだけど、デファクトになってほしくないんだよなぁ。LSPベースの rust-analyzer と開発体験を分断されたくない。

Kotlin みたいに JetBrains 製品にお布施しないとまともな開発者体験を得られない言語に成り下がられるのはゴメンだ。
961 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 07:38:03.27 ID:gde9MjoR.net]: JetBrainsのRustIDE、完全有料になるかと思ってたわ
962 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 08:30:48.75 ID:nvuBPJ3U.net]: どうせ頃合いを見て有料化するだろ
963 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 09:03:01.21 ID:pOxW5wqV.net]: > 開発体験を分断されたくない。
後発にしては厳しい無料条件なので心配しなくても良いかと

正式な開発でなくても(リモートワークも含めて)仕事時間中に使えば
"regular direct or indirect income"に該当するから"non-commercial license"は適用違反

"non-commercial license"はテレメトリーをオプトアウト出来ないので要注意
964 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 11:44:30.79 ID:on9rPJCX.net]: >>949
KotlinはintellijのCommunity版では駄目なの？
965 名前：デフォルトの名無しさん [2024/05/23(木) 19:28:45.95 ID:BdcLV1xd.net]: >>912
とバカが申しております
966 名前：デフォルトの名無しさん [2024/05/23(木) 19:58:53.15 ID:6Gn5p/CD.net]: バカにはスクリプト言語でまともなコードを書くのは難しい
967 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 22:37:27.54 ID:jrJOBQ7e.net]: >>831の反Rustの人ですら
数行のコード以外はスクリプト言語よりもRustの生産性が高いと認めてるもんな
968 名前：デフォルトの名無しさん [2024/05/24(金) 11:24:20.14 ID:56Y1qcJr.net]: 10行以内かつ実行時間10秒以内のスクリプトだけはPythonの方が生産性が高い
969 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 12:56:31.70 ID:nrXjP27l.net]: 四半期に一回、特定のひと一人で、実行時間1分みたいな、たくさん動かないやつはJVMか.NET系で買いてるかな～

Rustで書くスキルも無いが。
970 名前：デフォルトの名無しさん [2024/05/24(金) 17:03:15.24 ID:2N4ieM97.net]: >>956
んなこたない。適当なAPI叩いて結果保存するくらいのことでわざわざrustなんか使わねーよ。
971 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 18:06:34.32 ID:kgcJienR.net]: シェルスクリプトでいいわな
972 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 18:25:46.80 ID:/GRQnPSE.net]: 俺もbashスクリプトで辛くなったらRust使ってる
973 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 18:33:51.22 ID:4a8mskew.net]: シェルスクリプトはもう古い
クソ文法すぎる
これからは google/zx だよ
974 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 20:29:44.37 ID:JvVkOY+P.net]: いまawsやるならrustがベスト？
975 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 20:31:15.62 ID:wR0icTOd.net]: 何でもシェルスクリプトでやろうとするガイジが昔湧いてたなぁ
976 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 21:19:59.79 ID:XJ5j6TX/.net]: AppImageはギルティ？
977 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 21:51:51.21 ID:/GRQnPSE.net]: >>963
CPUメモリリソース料金を下げるためにRust利用がベストチョイス
978 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:15:30.97 ID:s3G1nQRJ.net]: やりたいこと次第だけどシェルの代替はPythonでほぼ事足りると思う
ファイル操作、文字列のパースやフォーマット、プロセスの呼び出しなどは簡単にできるし読みやすい
979 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:15:34.63 ID:s3G1nQRJ.net]: やりたいこと次第だけどシェルの代替はPythonでほぼ事足りると思う
ファイル操作、文字列のパースやフォーマット、プロセスの呼び出しなどは簡単にできるし読みやすい
980 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:31:06.67 ID:y1+3vies.net]: シェルスクリプトとRustで十分
Pythonは不要
981 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:53:57.26 ID:fBactBUY.net]: wslが使い物になるようになってから全部シェルスクリプトでよくね？ってなっちゃった
982 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:59:24.64 ID:y1+3vies.net]: ある程度以上はRust利用
983 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 06:44:35.86 ID:J0svnUgO.net]: >>967
Pythonは文法がなぁ。Python使うならNimの方がいい。

RustScriptとかどうなんかね。
984 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 08:48:10.16 ID:vDhIrX/5.net]: Pythonってライブラリ資産が豊富でマルチプラットフォームなスクリプトだから使われてるだけでしょ
985 名前：デフォルトの名無しさん [2024/05/25(土) 09:34:12.56 ID:q+P8yrMm.net]: >>973
その通りだけどそれが重要じゃん
だからRustはユーザ少ないし流行らないし消えそうじゃん
986 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 09:57:20.38 ID:0KAJWBX2.net]: これだけネットインフラのRust化が進んでいて「流行らない」と言い出す人
987 名前：デフォルトの名無しさん [2024/05/25(土) 10:30:11.54 ID:q+P8yrMm.net]: じゃあ数字で出してよ

pythonが流行ってるとしてRustはどうなのか？
ユーザ数でもプロダクト数でも何でも良いから比較数値を出して見てよ
988 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 10:45:29.87 ID:Ok/Wj9Ar.net]: >>976
分野に定着すれば数が少ないことは「消えそう」という根拠にはならない。
総合的な判断なので一部の数値を見るのはあまり意味がないが……。
事実上の標準であるリポジトリ PyPI と crates.io のパッケージ数はそれぞれ 543556 と 146503 。
Python のほうがかなり数は多いが Rust が消えそうなほど弱小ということはない。
エンドユーザーに近いほうが数は多いのが自然だし。
989 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 10:57:59.92 ID:566/PNRT.net]: The Best Blogs and Websites - Feedly
ttps://feedly.com/i/top/rust-blogs
990 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 11:20:17.33 ID:jCqkIMgy.net]: TIOBEとかgithubとか色々でてるじゃん
どう判断するかはあるけどそれくらい探せよ
991 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 11:24:55.77 ID:CqoBbhiM.net]: >>973
十分普及しているからさらに使われれるという面もあるな。
配布するスクリプトは昔ならわざわざ実行環境入れてもらうハードルがあるから標準の sh や bat を書いてたけど
今は安心して python 一本だな。
992 名前：デフォルトの名無しさん [2024/05/25(土) 11:48:54.94 ID:q+P8yrMm.net]: >>980
数は正義だからね
993 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 11:49:54.05 ID:7FqN5d/t.net]: ここはRustスレだ
バカはクズ言語Pythonを使っていろ
しかしバカはここから出て行け
994 名前：デフォルトの名無しさん [2024/05/25(土) 11:57:26.64 ID:q+P8yrMm.net]: 俺がRustを使ってないと何時から錯覚した？

他の言語も使うがRustも普通に使ってるぞ
995 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 12:08:10.83 ID:0t71UrW4.net]: 例えばJavaが消える最大の原因はKotlinだろうから
JavaとPythonを比較するのは無意味だと思う
RustとPythonも同じ
996 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 21:06:08.47 ID:KcOF6HNo.net]: >>972
rust-scriptってあったんだな
なんかpostscriptみたいな響き
997 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 23:37:23.93 ID:0t71UrW4.net]: >>983
それは投票する側が2倍以上努力してるだけだからね
投票される側の正義とは言えないよ
998 名前：デフォルトの名無しさん [2024/05/26(日) 05:37:36.04 ID:3cUpvkRQ.net]: pythonが定着するとかイヤだなぁ・・・
pythonとかjsとか使わざるをえないからイヤイヤ使う言語ってほんとイヤ
999 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 11:36:19.22 ID:7yHeuCrc.net]: ネイティブコンパイラはOS依存を強制される説があって
javaとかjavascriptとかは強制がないとされていた

最近はネイティブではなくunsafeが悪いみたいな話になってるね
1000 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 16:24:52.23 ID:yRNPjL2P.net]: >>987
残念ながら普通の人はpython使ってる
その中身をrustで書く
こうなっていくと思う
普通の人が直接rust書くのは無理かと
C/C++とおんなじ
1001 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 17:48:00.24 ID:VjGSgwTY.net]: プログラムを書くのがプログラミングの専門家ってわけじゃないのが現代だからね。
学者ならどの分野にしても多少はプログラミングも (専門家レベルでは全くないにしても) 学んで欲しいが
事務員とかアーティストが使うことを想定したらかなりハードルを下げるのはしょうがない。
1002 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 19:02:26.55 ID:hB5FbGHx.net]: Pythonの最も速くて使いやすいパッケージ管理ツールRye+uvはRust製
Python⇔RustはPyO3で相互呼び出し可能
今後のPythonはツール面でもライブラリ面でもRustの助けを得て進んでいく
1003 名前：デフォルトの名無しさん [2024/05/26(日) 21:48:57.66 ID:qVdh8/fj.net]: CPythonじゃなくてRustPythonになるのは歓迎
1004 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 22:56:51.38 ID:XmfdYoG9.net]: つまりPythonを使っていると思ったら実はRustを使っているということか
1005 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 23:19:03.24 ID:E+Olvt9B.net]: PythonもJavaScriptも今どきのイケてるパッケージはRustで書かれてるよ
RubyやPHPは知らん
1006 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 23:47:36.53 ID:qyBtaRPy.net]: X言語でX言語用のツールを作ってたけど
遅いとか色々問題が出てきたのでrustで作り直しました
という事例がそこそこ出てきたけどそこで
c++という事例あるかな？
1007 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 00:44:37.08 ID:5v+U6kmL.net]: >>994
RubyのYJITはRust製でしょ
1008 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 00:45:25.77 ID:5v+U6kmL.net]: >>980
スレ立てよろ
1009 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:40:16.06 ID:T4AFD1f4.net]: 立てるよ？
1010 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:41:53.55 ID:T4AFD1f4.net]: 次
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/
1011 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:43:57.69 ID:T4AFD1f4.net]: 馬
1012 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 93日 13時間 6分 6秒
1013 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef