Rust part29

レス数が1000を超えています。これ以上書き込みはできません。
1デフォルトの名無しさん
垢版 |
2025/05/03(土) 00:47:30.13ID:phVJ5tWC
公式
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 part28
https://mevius.5ch.net/test/read.cgi/tech/1742805420/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/
2デフォルトの名無しさん
垢版 |
2025/05/03(土) 07:56:18.42ID:ERFTsxnY
>>前969
>このパターンが「便利だから」という理由で他の言語でも流行る

C++のstreamのsetwみたいでださいな
2025/05/03(土) 09:25:44.77ID:qBega2UP
>>前995
> 構造体のフィールドに値を入れていって構造体を作成しても
> derive_builderを使いメソッドで値を入れていっても同じになった
> メソッド呼び出しが消えた
> ゼロコスト

builderのコストは下記。名前付き引数とデフォルト値を使用した方法であれば全て不要で単なるnewの呼び出しとなるが、これらが全て最適化で消えるのか?
* パラメータ用の構造体(以下P)のアロケーション
* 構造体Pのデフォルト値での初期化
* 構造体Pのフィールドに対する上書き
* 構造体Pから最終的に作成する構造体への各フィールドの逐次的なコピー
* 構造体Pの破棄
2025/05/03(土) 09:44:09.41ID:WnzKFtQv
全部消える。 構造体初期化の文法で書いた場合と同じ。
最適化しない場合の素朴な処理でもそんなに気にするような深刻な差もない。
2025/05/03(土) 10:00:48.18ID:WFDs7LYH
>>4
compiler explorerで示して
2025/05/03(土) 10:10:18.01ID:h9Jrb8E+
は？
2025/05/03(土) 10:43:01.54ID:rfaECn6+
君は見たか？
複おじがぐうのねも出ずに論破された所を
2025/05/03(土) 10:49:14.34ID:NA/ingJD
過視化するな
2025/05/03(土) 10:52:36.35ID:rfaECn6+
大体のケースでビルダーパターンはアンチパターンと主張し続けて20年以上経つ
2025/05/03(土) 10:54:37.53ID:0l2J5oT4
最適化されることを主張するなら証拠を示すべきなのは当然だが、
コピーの最適化を前提にするのなら例えば安易にCopy実装したりcloneしたりすんな、
みたいな意識高い言説は多くの場合無意味になっちゃうわけだけど、Rustおじはそれでいいのだろうか
11デフォルトの名無しさん
垢版 |
2025/05/03(土) 11:28:41.74ID:x2OSMXKg
この流れは流石に重箱の隅をつつきすぎじゃないの？
Rustのビルダーはオプショナルな動作を指定するパターンでしかないし、これが最適化されないと困る場面もそんなに無い
せいぜい、ヒープを使うデータについてビルダーを消費するか、中身を clone するかを検討するくらいでしょ

コピー動作が問題になるとしたら、例えば数十万とかの要素を持つ配列の for ループ内でビルダーを使う場合が考えられるけど、それならビルダーを1度だけ作ってそれを使いまわせばいいし

「Rustにも他の言語のオプション引数やキーワード引数があると嬉しいよね」という話なら同意だけど、ビルダーのパフォーマンスはそんなに重要な話でないというか
2025/05/03(土) 11:29:53.96ID:rfaECn6+
ストローマン論法
2025/05/03(土) 11:53:45.69ID:NA/ingJD
匿名の藁人形は作れない
作れるのは名指しできる個人や団体だけ
だから実名のSNSは嫌なんだよね
2025/05/03(土) 12:04:07.72ID:ekVKJoF2
>>10
一理ある
2025/05/03(土) 12:39:00.21ID:0l2J5oT4
RustやC++のゼロオーバーヘッドが意味するところは結局「俺達のコードがどのように処理系によって最適化されるかを俺達は知っている」ということであって、
どのような最適化がなされるかについて一定の透明性があり結果が自明であることが重要
その点で、コピーの最適化を前提にするってのはかなり微妙
2025/05/03(土) 13:47:12.37ID:ekVKJoF2
「かいたとおりにうごく」が最適化では成り立たないからなぁ
2025/05/03(土) 13:55:18.67ID:NA/ingJD
昔ある言語でcontinueがないぞと散々言われて、gotoが実装されたことがあった
何もしないのと比較すればcontinueの提案は優れていたかもしれないが
それは比較対象との相性が良かっただけ
2025/05/03(土) 14:13:59.39ID:rfaECn6+
数年前に読んだ書籍にcontinueは使うべきでないと書かれていて驚いた
2025/05/03(土) 14:41:11.34ID:WnzKFtQv
>>10
安易に clone すべきでないのは所有権管理の話で、実行コストの話とはレイヤが違う。
20デフォルトの名無しさん
垢版 |
2025/05/03(土) 18:56:47.80ID:Q4RX0Sa/
スマホとPCの作業を効率化したい--「Copilot Vision」の便利な8つの活用例
2025-05-03 07:00
https://japan.zdnet.com/article/35232549/


1 プログらまーまこれを改造してるので上記以外の状態でも使用できるようにしている

2 すでにプログラムがあるので１〜コードを作成する必要が無い

ボイス・トォ・スカルの本態が一般パソコンにまで来たのでつい買い捨てができるようになった
マネーロンダリング 談合 インサイダー などがはかどるといわれる
2025/05/03(土) 23:51:30.72ID:OINldK7L
>>3
それらは最適化ですべて消えて最終的な初期化構造体のみになった
イテレータメソッドチェーンなどの時と同じ原理
それはもっと極端で各イテレータ毎にいくつ構造体があろうと縮約したりレジスタ化されたりして各構造体は消えていく
2025/05/04(日) 01:14:00.32ID:31CqVJjs
複オジ脳やべぇな
視野が狭すぎる
2025/05/04(日) 09:21:09.35ID:AbCvwvGO
>>19
cloneして意図通りに動作しなくなるならそりゃ普通にcloneの実装もしくは利用者側のバグだろ。作法の問題ではない。
そんな中身を理解しないままコピペしてるバカみたいな低次元のことは誰も問題にしていないでしょ。
2025/05/04(日) 09:55:20.90ID:768oLjN1
>>10
区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる

一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない
2025/05/04(日) 11:20:50.74ID:AbCvwvGO
それは少なくともbuilderの最適化の文脈においては明確に誤り
実際、derive_builderはcloneが最適化されることに依存している
2025/05/04(日) 12:05:36.94ID:RkNPiBO2
RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ
したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる
2025/05/04(日) 13:33:55.47ID:V3G8dKZI
無駄をなくそうとしたらコンパイルが通らなくなった
っていう質問を処理するコストが高いよね
実行時のコストではなく
2025/05/04(日) 13:35:26.53ID:YbSG8qnS
読む気が失せる分だけど読んだ
ところが間違ってるというか言い過ぎだと思う
2025/05/04(日) 13:38:00.38ID:JiKNIZxM
クソデカ長文とかどこでも現れる辺りRustとRubyって似てるなーと思った次第である
2025/05/04(日) 13:41:35.32ID:w7r9Yiaa
この程度で長文扱いって普段どれだけ文章を読まないんだよ。
2025/05/04(日) 13:43:24.90ID:YbSG8qnS
暗黙のコピーが行われるプログラミング言語は大体値のコピーを行っている
値はこの場合参照なのでコストは限りなく低い

暗黙でポインターをコピーしてそれがコストが掛かると言う人はいないだろ
2025/05/04(日) 13:44:23.89ID:YbSG8qnS
>>30
読む気が失せるのは文章が下手くそだからであって長いことは関係ない
そしてボロボロと誤りと言うか独断に基づいた誤りがたくさん入っている
2025/05/04(日) 13:47:16.56ID:YbSG8qnS
複おじはAIに下書きを食わせて推敲してもらうべきだと思う
2025/05/04(日) 13:53:19.75ID:RkNPiBO2
むしろAIに生成させてるんじゃないかと思われる
同じことを何度も何度もダラダラ箇条書きに
眠くなるわ
2025/05/04(日) 13:57:45.80ID:V3G8dKZI
見たい所だけ切り取ればいいんだよ
切り取りや編集の責任をトリクルダウンするために、書く側は編集をしないという戦術だろうけど
それはどうでもいい
2025/05/04(日) 13:59:33.25ID:YbSG8qnS
AIではないよ
小論文など書くときに指摘されるけど、考えをまとめないでずらずらと続く文章は修正しろと言われる

一部の行頭だけ切りだすと以下のように前の文章とつなげて書いてるから読み手にはわかりにくい
↓これが連続して使われているので読み手への負担になっている

一方で
そもそも
だから
もちろん
したがって
2025/05/04(日) 14:05:10.05ID:YbSG8qnS
人間の脳もスタック状になってるんでドンドン文が接続されていくと脳内にスタックが作られてスタックがチェーンして肥大化して理解が苦しくなる
これは当たり前
2025/05/04(日) 14:21:14.87ID:YbSG8qnS
文章がダラダラと接続されているものは、まともに推敲されていないので、基本的に読むコストに比べて得られるものが少ない
雰囲気で書かれているので間にも間違いや矛盾が含まれている

読み手に対して読みやすさが考慮されていないのでふつーに読まなくても良い
2025/05/04(日) 14:36:43.37ID:YbSG8qnS
ここでようやくchatGPTに聞いてみた

✅ 読みにくさの主な原因


1.接続詞やつなぎ言葉の多用による文の長文化

「一方で」「だから」「そもそも」「もちろん」「したがって」などの論理接続語が多く使われ、それぞれの文が長くなりがちです。
　
結果として、読者は一文ごとの意味の切れ目を捉えづらくなります。


2.
文構造が複雑で、主語と述語の対応が曖昧

「コピーして渡すのではなく参照を渡すのが正解だ」のように、主語が省略されていて読み手が文脈を補う必要があります。



3.抽象的な話が続き、具体例や対比が乏しい

例えば「ムーブはコピーと違う」と言いつつ、具体的にどう違うのかの明示がないため、読者が前提知識を持っていないと理解しにくいです。


4.
視点の切り替えが頻繁

ムーブとコピー、CopyとClone、参照と値渡しなど、話題が細かく切り替わっているが、その都度明確な導入がないため混乱を招きます。
2025/05/04(日) 14:42:19.99ID:V3G8dKZI
もっと詳しく書け、とAIが言っている
みんなAIに騙されてる
2025/05/04(日) 14:51:46.05ID:YbSG8qnS
さっき書いた部分は連続で接続されている

A 一方で　B　=　C（文意）
C　そもそも　D = E（文意）
E だから　F　= G（文意）
略
Y　したがって　Z

Zを理解するためにAから後を状態や文意を含めて全部覚えておかないといけない

読み手を疲弊させるには接続を多用したらいいとも言える
42デフォルトの名無しさん
垢版 |
2025/05/04(日) 15:48:20.78ID:pRD7GF2w
みんな読みやすい文を書いて良い大学、良い企業に入りたいとか
読みやすい文を書いて本を出版して売りたいとか
金の為に文を書いているからな
文なんて記号に過ぎない意味が伝わればいいのよ
2025/05/04(日) 15:53:36.21ID:w7r9Yiaa
意味が伝わればいいとか言ってるやつが書いた文章はたいてい伝わってねーから。
プロが推敲したってきちんと伝えるのは難しいのにそれ以下の質ならそれ以下にしか伝わらないよ。
44デフォルトの名無しさん
垢版 |
2025/05/04(日) 16:11:44.87ID:pRD7GF2w
国語の天才が推敲すると数学も理科も社会も意味がわかるようになるなら
学校で国語だけ教えてればいいだけだろボケ
2025/05/04(日) 16:24:07.39ID:rF0671A/
確率扁微分方程式を国語で説明してくれ

三行でよろぴく
46デフォルトの名無しさん
垢版 |
2025/05/04(日) 16:27:43.19ID:pRD7GF2w
教
科
書読め
2025/05/04(日) 16:34:02.19ID:SPPeLARI
もちろんでNGしとけ
2025/05/04(日) 16:43:31.57ID:NNcLkyI5
AIにコードを生成させるならもうRustはいらない子だよね
2025/05/04(日) 17:06:18.99ID:V3G8dKZI
>>48
こういうのはビッグウェーブに乗る力であって国語力ではないね
2025/05/04(日) 17:29:04.69ID:YbSG8qnS
他人に自分の主張を理解してもらいたいなら、少なくともわかりやすく書く必要がある

いつも例の人の文章を読んでると念仏を聞いてるような気分になる
誰かが眠くなると書いてたけど自分もその印象が強い

言葉を吐くマシーンの様で理解してもらおうなどと思ってないんだろうなと
2025/05/04(日) 18:03:43.43ID:V3G8dKZI
理解されるためならなんでもしますという意志はたいして重要ではない気がする
なんでもするって言わせたい人にとって重要なだけだろう
2025/05/04(日) 18:15:26.35ID:MUJ0VZ08
文章の読みやすさを意識しないプログラマのコード品質って大丈夫なのか？
2025/05/04(日) 18:50:12.49ID:YbSG8qnS
理解されないなら主張としては存在しないのと変わらない
公共の場にただのデカいゴミがあってみんな邪魔だなって思うだけ
2025/05/04(日) 19:37:09.88ID:hE1W0oD0
derive_builderのドキュメント見てみた
Rustはこれらのclone呼び出しも最適化して賢いと書かれている

https://docs.rs/derive_builder/latest/derive_builder/#-performance-considerations

Performance Considerations

Luckily Rust is clever enough to optimize these clone-calls away in release builds for your every-day use cases. Thats quite a safe bet - we checked this for you. ;-) Switching to consuming signatures (=self) is unlikely to give you any performance gain, but very likely to restrict your API for non-chained use cases.
2025/05/04(日) 20:04:32.38ID:AbCvwvGO
derive_builderはRustのセマンティクス的には割と非効率な実装を採用していて、
常に一度のbuildだけの使い捨てに特化したバージョンも提供するなど制約を強めることで更にセマンティクス上効率的な実装もありうる
でもそうしないのは実際最適化で変わんなくなるんだろう
コンパイラの解析に委ねる前にセマンティクス上の最適を目指すのがRustの大きなコンセプトだと個人的には思っているが、その観点ではあまり理想的とは言えないやり方だし、
Rustの言語側にも改善の余地があるかもしれない
2025/05/04(日) 20:20:39.66ID:MUJ0VZ08
#[builder(pattern = "owned")]だと使い捨てになるんでしょ
こっちをデフォルトにした方がいい気もするけど１回しかbuildしない場合は最適化されて同じになるらしい
2025/05/04(日) 20:38:30.13ID:4IVc0xff
さらに限定したケースでRustコードの段階で最適化できる可能性もあるかもしれない
この初期化ビルダーがプログラム全体のネックになる時が来たらチャレンジするかな

現実には誤差の範囲内なのでこのderive_builder利用で十分と思う
初期化関数を自分で用意せずとも構造体への属性修飾だけでよい利便性は他のプログラミング言語と比べてもベスト
2025/05/04(日) 21:23:32.91ID:YbSG8qnS
でもビルダーパターンは潜在的にバグ発生の要因をはらんでいる
2025/05/04(日) 21:31:29.80ID:4IVc0xff
>>58
あらゆるパターンが潜在的にバグ発生の要因をはらんでいるから意味のない発言
具体的にderive_builderでバグ発生の要因があるなら指摘して
2025/05/04(日) 21:32:02.50ID:YbSG8qnS
IDEのサポートを受けた元で初期化関数を使うのがベスト
単純にビルダーパターンで起こる記述漏れ、順序の間違い、重複指定バグが減る
2025/05/04(日) 21:33:14.08ID:YbSG8qnS
>>59
前スレで書いたけど複おじは反論不能だったみたいでスルーしてたな
複おじ論破されて草だった
2025/05/04(日) 21:36:49.89ID:hRPtBNkv
>>60
手動で初期化関数を作るのは面倒かつバグの入る余地もあり劣ってる
derive_builderは利便性も良いからこれより優れているものを持ってこないと話にならないかと
2025/05/04(日) 21:39:37.45ID:4IVc0xff
>>61
「おじ」使いのキチガイの人かよ
具体的にderive_builderでバグ発生の要因があるなら指摘しなさい
2025/05/04(日) 21:39:44.02ID:YbSG8qnS
>>62
そんなもんテストでわかるでしょう

テストしないところでビルダーパターンはバグを起こす可能性が高い
人間がビルダーパターンのメソッドに注視して思考してパラメーターを指定する場合は問題が比較的起こりにくい
それをコピペや思い込みで書くとヒューマンエラーが入り込む余地がある

ビルダーパターンで複数行でメソッドを記述した場合には列レベルで記述が抜けることが考えられる
行で記述しても対応ミスなどが起こる

複おじは問題点をわざと見ないふりをしている
2025/05/04(日) 21:40:04.11ID:YbSG8qnS
>>63
前スレ見ろ
おじいちゃん
2025/05/04(日) 21:45:21.35ID:hRPtBNkv
>>64
わざわざ手動で初期化関数を作ってテストするってか
面倒なだけでメリットが全くない
利便性も良いderive_builderより優れているものを持って来なされ
2025/05/04(日) 21:46:26.28ID:YbSG8qnS
>>66
前スレで問題点を指摘されて論破されて何もできないで誤魔化してるんでしょ
みっともない
2025/05/04(日) 21:49:41.13ID:hRPtBNkv
>>67
誤魔化してるのは君だ
derive_builderに問題点があるなら指摘しなされ
derive_builderよりも利便性の高い方法があるなら持ってきなされ
2025/05/04(日) 21:52:48.22ID:YbSG8qnS
>>68
ストローマン論法だな

自分の主な主張はで前スレで書いたようにビルダーパターンは複雑なオブジェクト生成で使われるべきで
普通のオブジェクト生成ではコンストラクタなどの初期化関数を使うべきと言うもの

理由はビルダーパターンはヒューマンエラーが入り込む余地が非常に大きいから
初期化関数はIDEの補助があるのでビルダーパターンで起こる問題が発生しにくいか発生しない
2025/05/04(日) 21:56:47.92ID:YbSG8qnS
それにしても「～しなされ」って言われたのは人生で初じゃないかな

ガチおじいちゃんじゃん　複おじいちゃん
2025/05/04(日) 22:01:03.15ID:hRPtBNkv
>>69
詭弁はよろしくない
derive_builderは自分で初期化関数を書く必要がない
他の方法では初期化関数を書く必要がありヒューマンエラーが入り込む余地があるのはその通りだ
利便性も良くてその問題が生じないderive_builderが優れている
2025/05/04(日) 22:02:35.26ID:YbSG8qnS
>>71
ストローマン論法だな

こちらの主張していない内容を勝手に作り出してそれで話を続けている
2025/05/04(日) 22:08:16.17ID:YbSG8qnS
初期化関数はビルダーパターンのメソッドの適用ミスで容易に起こりうる　重複、順序ミス、記述漏れに対して有用
初期化関数自体は一回書くだけ

各所で必要になる単純なオブジェク生成の場面ではビルダーパターンはヒューマンエラーが入り込む恐れがある
それを初期化関数で行えばIDEの補助を得られるのでミスが減る
2025/05/04(日) 22:21:31.66ID:abvIudxv
>>73
先ほどから主張しているderive_builderを使わなければIDEの補助が得られるからミスが減るの意味がわからない
derive_builderを使えば初期化関数の用意はお任せなので提供側のミスはない
利用側はデフォルト値以外の値指定をしたい時にそのメソッド候補がIDEなどで補助があるのでミスが起きようがない
derive_builderを使った方が提供側も利用側もよいのではないか
2025/05/04(日) 22:24:30.81ID:V3G8dKZI
まだバグを起こす前の時期に、バグを起こしやすい習慣をやめない、まつもとなかいがいたとする
その時点で彼らをどのように処分したいのかね
2025/05/04(日) 22:33:13.89ID:YbSG8qnS
>>74
ストローマン論法をやめなされ

初期化関数を使うと指定の重複、順序ミス、記述漏れが起こりにくいのは事実だろう
まず単純な初期化関数で指定の重複が起こるのか？
func( a,b,c,d....にたいしてaを重複指定させられるのか？
これすら判らないなら話すだけ無駄
2025/05/04(日) 22:35:21.33ID:YbSG8qnS
「～しなされ」っていうのって少なくとも80歳以上じゃないかと
2025/05/04(日) 22:42:41.94ID:abvIudxv
>>76
derive_builderで提供された場合も問題は起きないよね
仮にそのaを重複指定してしまい
.a(123)
.a(123)
と書いてもバグは起きない
可読性もよいからそれ自体を起こさないね

derive_builderは提供側も利用側もデメリットがなく最も良い方法にみえる
もっと良い方がある？
2025/05/04(日) 22:44:40.17ID:YbSG8qnS
>>78
.a(123)
.a(321)

で始めの123が正しい場合問題になる
2025/05/04(日) 22:50:43.73ID:abvIudxv
>>79
aを123で初期化したいなら前者しか起きようがない
aを321で初期化したいなら後者しか起きようがない
そんなナンセンスな指摘しかデメリットらしきものを見つけることが出来なかったということは
derive_builderが最も良い方法であることを認めたと理解してよろしいか
2025/05/04(日) 22:50:51.74ID:V3G8dKZI
the bookによるとnewtypeパターンってのがあって
traitをimplすることが目的みたいだけど
どうにかすれば名前つき引数にも使えそうなんだよね
2025/05/04(日) 22:51:05.55ID:YbSG8qnS
順序ミスについて
これは前スレでも書いたのを再掲

.G(p[0]).R(p[1]).B(p[2]).build()
のところを容易に
.R(p[0]).G(p[1]).B(p[2]).build()と間違えて
さらに
.R(p[0]).R(p[1]).B(p[2]).build()と間違える

色指定でよく目にするのはRGB方式だけどコンピュータービジョンなどではBRGがよく使われる
最初にGRBとして覚えていても実際各段階になるとRGBと混同することがある

初期化関数では
func(P[0],P[1],P[2],...
等で考えなくても書き間違える可能性が低い　それにIDEの補助でパラメーターについてポップアップが出るのでそれでも間違いは減る
バグに気が付いて書き直す際に2か所の書き換えをしないで
.R(p[0]).R(p[1]).B(p[2]).build()　と言う間違いも入り込みやすい
2025/05/04(日) 22:53:00.11ID:YbSG8qnS
書いてるそばから間違えている
BGRが正しい
2025/05/04(日) 22:55:04.07ID:YbSG8qnS
>>80　の疑問については
>>82　で書いたようなミスで重複と記述漏れが発生する

そういうところまで考えたことないだろ？コーディングしてる？
2025/05/04(日) 22:57:59.52ID:abvIudxv
>>82
その比較はおかしい
デフォルト値以外のみを指定して初期化する話なのだから
それは✕　func(P[0], P[1], P[2],...
これが○　func(R=P[0], G=P[1], B=P[2], ...
2025/05/04(日) 23:00:32.68ID:YbSG8qnS
記述漏れについては
n個パラメーターを指定しないといけないのにn-1個しか記述していない場合
目で見てn個すべて指定したのかn-1個指定したのかなんて数が多くなると判らない

これは初期化関数では基本的に起こらない
数が多いとやはり大変だけどIDEの補助があったりコンパイル時にエラーがでる

ビルダーパターンでは実行時エラーや思った挙動にならない時点でしかミスに気が付かない
2025/05/04(日) 23:01:35.79ID:YbSG8qnS
>>85
誰もそんな縛りは指定していない
普通に初期化関数使えばよい
2025/05/04(日) 23:05:28.74ID:YbSG8qnS
これ以降ストローマン論法禁止
2025/05/04(日) 23:05:37.33ID:hRPtBNkv
オプション値の初期化の話だもんな
必須値の初期化の話ならRustでも
fn foo(red: Type, green: Type, blue: Type)
とするだけなのでderive_builderは使わない
だから>>82の指摘は間違ってる
2025/05/04(日) 23:09:07.67ID:YbSG8qnS
>>89
それはお爺さんにもわかりやすいように簡易化して書いているからだろ

ビルダーパターンは上にあげたようなヒューマンエラーを誘発する仕組みなので基本的に使わない方が良い
2025/05/04(日) 23:11:26.83ID:YbSG8qnS
生成に柔軟性があり複雑な場合にはビルダーパターンを適用するのは良い
一般的なオブジェクト生成に対してはヒューマンエラーに弱くアンチパターン
2025/05/04(日) 23:13:07.88ID:abvIudxv
>>87
プログラミングの基本的なことを理解していないのかい？
derive_builderを使うようなオプションで必要な項目だけ値を指定して初期化するケースを1つの初期化関数を単体で済ませようとすると
どんなプログラミング言語でもキーワード付きオプション引数を使うことになる
具体的にはf(1, 2, 3, option1=111, option5=222)などの指定方式になる
option5など名前を指定しないとどの項目を指定しているのか区別がつかないためだ
2025/05/04(日) 23:15:31.49ID:YbSG8qnS
>>92
その指定だとしても重複は大体の言語ではエラーになる
ビルダーパターンは重複を検知しないのでヒューマンエラーが入り込む
2025/05/04(日) 23:20:45.80ID:hRPtBNkv
>>91
オプション初期化のない一般的なオブジェクト生成でderive_builderを使う人はそりゃいないよ
それは普通にRustでも引数固定の初期化関数でおしまい

前スレを読んだけど最初から特定項目だけオプション初期化する話
だからderive_builderが最も優れているという結論になってる
2025/05/04(日) 23:21:18.11ID:YbSG8qnS
>>94
重複すら検知できないのに？
2025/05/04(日) 23:26:47.62ID:YbSG8qnS
重複を検知するには内部にフラグを持たなくてはならない
もちろんこれは実行時エラーになる
2025/05/04(日) 23:30:18.53ID:YbSG8qnS
実行時エラーを検出するにはテストで網羅しなくてはならない
2025/05/04(日) 23:40:27.55ID:YbSG8qnS
我々はコンパイル時にエラーが検出されるのを利点としてRustを使っている
それなのに実行時エラーに頼らざるを得ないビルダーパターンは劣っている
2025/05/04(日) 23:45:58.01ID:GqHoJEAc
結局、話をまとめると
ビルダーパターンで
foo()
　.item1(value1)
　.item3(value3)
　.item7(value7)
と書くか

名前付きオプション引数で
foo(
　item1=value1,
　item3=value3,
　item7=value7,
)
と書くか

これだけの違いだよな
どちらも変わらん慣れだけの問題
どちらも見た通りなので指定ミスや重複ミスなど起きようがない

あとはそれらを提供するライブラリ側だ
いずれも普通は初期化関数を自分で書かなければならない
Rustでderive_builderを使えば構造体に属性を付けるだけで済みシンプルかつミスも起きない
少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる
2025/05/04(日) 23:55:20.08ID:YbSG8qnS
>>99
結局何も見なかった利かなかったふりして自分のいいように矮小化し続けてるな
呆れるよ
80代になると何も感じなくなるのだろうか
2025/05/04(日) 23:58:47.69ID:GqHoJEAc
的外れな言いがかりでスレを荒らしてる人は
derive_builderより良い方法を具体的にコードで示せ
2025/05/04(日) 23:59:41.54ID:YbSG8qnS
精神論で間違いは発生しないと言うのは容易
間違えたら間違えた人間が悪いと言う

ビルダーパターンには結局ヒューマンエラーを防ぐように十分な対策がなされていないだろ
わかっていながら無視をする
c++精神だね
2025/05/05(月) 00:00:40.76ID:jqQPAhm/
>>101
ファクトリーパターンなどを使えばよい
メソッドの種類を充実させるだけだ
2025/05/05(月) 00:03:11.76ID:jqQPAhm/
ビルダーパターンはヒューマンエラーに弱い
毎回論理的構造を構築しなければならないがそこにバグが紛れ込む可能性がある

それよりも初期化のための関数を作るべき
2025/05/05(月) 00:03:28.63ID:+OgYhFfL
derive_builderは全自動だからミス起きなくね？
derive_builderより好いのがあるならコードを出して
2025/05/05(月) 00:05:02.99ID:jqQPAhm/
おじいちゃんは乱心して同じことを何度も書いて来る
普通の人間にはすでに書かれた内容で理解出来るのに知らないふりして実行時エラーやバグを許容している
2025/05/05(月) 00:06:42.46ID:jqQPAhm/
これも相手の疲労を狙ってくるくだらないやり口なんだろうと思うが
2025/05/05(月) 00:07:25.49ID:H9yekDq7
>>104
そんな方法は存在しないよ
>>99が挙げてる二つの方法しかない
もしあるなら同様のコード例を示そう
2025/05/05(月) 00:08:38.62ID:jqQPAhm/
他のスレでもでもおじいちゃん的書き込みを見ることがある
それに対して80代ではと書くと100%反論される

今回は反論されないところを見るとやはり80代以上なんだろうなと
2025/05/05(月) 00:09:40.80ID:jqQPAhm/
>>108
＞　それよりも初期化のための関数を作るべき
これが全てだろう？
いくら何でも馬鹿すぎるだろう？判らないの？
2025/05/05(月) 00:10:41.78ID:Eyx6FHs7
Builderはオプションの追加実装が破壊的な変更にならないメリットがあるな
生成関数に全部渡す方式だとパラメータが増えて破壊的になる
新しい生成関数を追加すれば破壊的にはならないけど
オプション追加する度に生成関数増やすのはあほくさい

>>103
もし暇だったら↓のRegexBuilderをFactoryで実装する場合の関数の個数を見積もってくれ
https://docs.rs/regex/latest/regex/struct.RegexBuilder.html
2025/05/05(月) 00:12:00.84ID:H9yekDq7
>>110
今回のようなケースで初期化のための関数は>>99が挙げてる二つの方法しかない
もし他に存在するなら同様のコード例を示そう
2025/05/05(月) 00:15:57.46ID:jqQPAhm/
なんで自分にレスしてんの？
2025/05/05(月) 00:19:17.48ID:jqQPAhm/
>>111
他の言語でもRegexは普通にメソッドを使って解決してるけど…
長いならregexoption構造体作って指定したらよいだろう？他ではそうしてる物もある
2025/05/05(月) 00:20:28.67ID:jqQPAhm/
Rustしか使ったことがない前提なのかな

さすがに馬鹿の相手をするのは疲れてきた…
2025/05/05(月) 00:21:44.77ID:jqQPAhm/
おじいちゃんは他の言語は使えないの？しょうもない雑魚レベルの質問しかしないのはなんで？
2025/05/05(月) 00:29:27.74ID:J617bx8A
デフォルト値に対して必要分だけオプション指定したい場合
まともな方法はどのプログラミング言語を使って>>99のどちらかの方式になる
まともではない方法としてはオプションの有無ごとの組み合わせ数の分だけ大量の関数を用意する手もあるけど論外だ
2025/05/05(月) 00:41:54.17ID:jqQPAhm/
何で間違ってることを繰り返すの？

macroで重複チェック可能なbuilderは書けるとか書いてこないのは意外なんだけど
2025/05/05(月) 00:53:11.08ID:jqQPAhm/
実行時チェックの話もchatGPTの方がまともで面白い回答や提案をしてくれる
2025/05/05(月) 00:56:27.23ID:Eyx6FHs7
>>118
設定値の重複チェックとか誰も気にしないからでは
重複設定によるバグとか生成関数に渡す引数の順番を間違えるバグと同じくらい起こりにくいし
2025/05/05(月) 01:00:46.13ID:EffckoF6
一部の必須値の設定を忘れるケースは普通にあるでしょ
2025/05/05(月) 01:09:30.63ID:v8V26/QO
>>121
必須値は様々な対応が取れるため問題は起きない
・オプションにしない
・全体の整合チェックの一貫として必須値の有無の判断を入れる
・ビルド最終メソッドで指定する　(ex. std::fs::OpenOptions::open)
2025/05/05(月) 01:17:39.76ID:Eyx6FHs7
一番オーソドックスなのが抜けてるな
RegexBuilderの場合はRegexBuilder::new()にパターン文字列を渡してる
2025/05/05(月) 01:21:35.04ID:v8V26/QO
>>123
先頭の「オプションにしない」が
その最初に必須値を渡す意味
わかりにくてすまん
フォローサンクス
2025/05/05(月) 08:29:59.12ID:EffckoF6
名前付き引数であれば必須パラメータも名前付きで渡せるため順番の間違いによるミスが発生しづらく可読性も高い
derive_builderを使う以上は必須パラメータもメソッドで渡すしかなく実行時エラーの可能性が排除できないしチェックのために余計なランタイムコストを払う必要がある
文句はderive_builder作者に言ってきた方がいいぞ
2025/05/05(月) 08:39:51.80ID:jqQPAhm/
狂信者には何を言っても無駄であり論理的な考えを持ち合わせていない
こちらがいくら論拠を提示してもRustが正しいderive_builderが正しいとそんなミスは起こりえないと繰り返すのみ

正しくないのはお前の頭だろう
2025/05/05(月) 08:41:20.98ID:PDh+rYm1
ビルド方式に問題はない
既出のstd::fs::OpenOptions::open()や
regex::RegexBuilder::new()など
Rustはビルド方式でも対応しており問題になっていない

>>125
名前付き引数であろうとなかろうとバリデーションは必要でそれは実行時エラーとなる
そしてResultを返すから実行時エラーで問題ない
2025/05/05(月) 08:42:39.33ID:S3aML2VS
>>82
順序ミス対策なら
.rgb(p[0], p[1], .p[2]).build()
でいいんじゃね？
Rustてこういうのできないんだっけ？
2025/05/05(月) 08:45:40.37ID:jqQPAhm/
>>127
＞　少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

じゃなかったのか？方針変えたのか？
130デフォルトの名無しさん
垢版 |
2025/05/05(月) 08:49:55.75ID:3AfvJi9A
“イリヤ神”がまたやった　動画生成AI「FramePack」が革命的なワケ
2025年05月05日 07時00分更新
https://ascii.jp/elem/000/004/267/4267160/
　4月17日に登場した動画生成AIプログラム「FramePack（フレームパック）」が世界的に衝撃を与えています。PCローカル環境で動画AIを動かすには、少なくともビデオメモリー（VRAM）が12GBあるビデオカードを搭載していないと難しいというのが常識でした。ところが、VRAM 6GBでも安定的に動作させられるため、一気に動画AIの裾野を広げそうです。開発したのは、画像生成AI分野で「ControlNet」や、使いやすいツール「Fooocus」などを開発してきたことで知られる、スタンフォード大学に在籍中のIllyasviel（イリヤスフィール、以下イリヤ）さん。既存の方法論にまったく違ったアプローチでブレイクスルーを引き起こす、“イリヤ神”のアプローチに再び注目が集まっています。
中略
　AI動画を作ってみたいけれども、スペックが足りないために諦めていたという人が次々に自前の環境で試すようになってきました。既にワンパッケージでインストールできる環境も整えられているため、スタートも簡単です。様々なファイルをダウンロードしてくるため、初期設定は2時間くらいは見ておく必要があるものの、圧倒的にハードルが下がりました。
2025/05/05(月) 08:51:02.82ID:jqQPAhm/
>>127
名前付き引数のミスは大体言語でコンパイルエラーになるので的外れ
ビルダーパターンより安全性が高いだろ
2025/05/05(月) 08:51:16.55ID:RIr+9vrd
>>126
Rustが間違っていると主張したいなら問題点と代替策を述べればよい
本当にそれが示せるならRustはIT大手各社も用いているため世界中にインパクトを与えられるぞ
この我々の5chのやりとりすらRust製のPingoraを経由しているほどネットインフラ各所でもRustは使われている
2025/05/05(月) 08:52:25.13ID:jqQPAhm/
>>132
何言ってるんだよ
最後の一行が全てだろ
2025/05/05(月) 08:53:13.86ID:jqQPAhm/
本当に暇さえあれば関係ない話題で誤魔化そうとするよな
脳がストローマン論法で浸食されているんだろ
2025/05/05(月) 08:53:53.74ID:S3aML2VS
それよりもbuilderパターンは初期化時の情報指定漏れをコンパイルエラーにできないのがRustらしくないと思う。
2025/05/05(月) 08:54:21.19ID:RIr+9vrd
>>128
個別パラメータとして与える必要がないからその通り
Rustの言語仕様としてはそれで制限ない
そのライブラリの仕様ならタプルにすればよい
2025/05/05(月) 08:55:05.06ID:Nqd+X/r+
>>127
なるほど、実行時に他のバリデーションするからタイプセーフでなくていいと君は考えるわけね
それはそれで一理あるが、だったら君が使うべき言語は静的型付け言語ではなくRubyなどのゆるふわ言語だな
さようなら
2025/05/05(月) 08:56:18.75ID:jqQPAhm/
ビルダーパターンで疑似カリー化が行えるのが利点なのにタプル化するって
わざわざ手足を縛ることになるけど
2025/05/05(月) 08:56:40.00ID:RIr+9vrd
>>135
勘違いしていないか？
必要とはされないオプションが有る時にビルダーパターンが使われる
2025/05/05(月) 08:58:33.63ID:RIr+9vrd
>>138
それマジで言ってるならRustでプログラミングしたことがないんだな
タプルで扱うのが正解
これがわからないならfor文すら書いたことがないのだろう
2025/05/05(月) 08:59:24.57ID:Nqd+X/r+
>>139
それは一部必須パラメータが依然として存在することと矛盾しない
2025/05/05(月) 09:01:01.47ID:jqQPAhm/
>>140
もはや話がかみ合ってないな
疑似カリー化で個々のパラメータを指定してその他のパラメータをここに設定した生成物を作れるのが利点だという意味が判らないのかな
これは重複を許容する使用法
2025/05/05(月) 09:02:05.60ID:RIr+9vrd
>>141
必須パラメータの事例はさっき出てただろ

>> std::fs::OpenOptions::open()
>> regex::RegexBuilder::new()

これで対応できている
誰もが使っていて問題となったことはない
2025/05/05(月) 09:04:25.68ID:RIr+9vrd
>>142
カリー化の意味すら理解できてないのか？
Rustでカリー化ならばクロージャを使う
ちなみにビルダーパターンはビルダー構造体のまま変わらずカリー化は行わない
2025/05/05(月) 09:07:05.32ID:EffckoF6
>>143
だからそれはderive_builderの作者に言ってくれ
それに前から言ってるが必須パラメータの数が増えればミスが増えるし可読性も落ちる
2025/05/05(月) 09:07:28.43ID:jqQPAhm/
>>144
ストローマン論法
疑似カリー化と書いてるだろ？

derive_builderは正しいと繰り返していたのにすでに複おじになかったことにされている
2025/05/05(月) 09:10:38.57ID:jqQPAhm/
微妙に論点をずらしたり相手の言ってないことに対して批判したり
本当にずっとストローマン論法続けてるよなあ
複おじいさん

ストローマン論法はやめなされｗ
2025/05/05(月) 09:11:10.84ID:RIr+9vrd
>>137
Rustは静的型付けだから常にタイプセーフだよ
それらの例は引数の型が合ってなければ当然コンパイルエラーとなる
一方で引数の値が合っているかどうかは構造体の方針だから当然コンパイルエラーにできず実行時エラーとなる
2025/05/05(月) 09:13:10.00ID:RIr+9vrd
>>145
何を言いたいのかわからない
fsやregexの話を作者に伝える？
そんなの知ってるだろ
2025/05/05(月) 09:15:12.07ID:RIr+9vrd
>>146
カリー化は定義もメリットもはっきりしていて幅広く使われてきているが
その疑似カリー化とやらも定義もメリットもわからない
無意味なことをしようとしていないか？
2025/05/05(月) 09:17:40.24ID:jqQPAhm/
>>150
見ればわかるだろうｗ疑似カリー化が何を意味しているのかぐらい

そういう議論のための議論を繰り返してなんになるんだよ
2025/05/05(月) 09:24:52.62ID:RIr+9vrd
>>151
だから疑似カリー化の定義とメリットを明確にしてくれ
少なくともこの件のrgbバラバラにするのはメリットないどころかデメリットだぞ

>>128
>> 順序ミス対策なら
>> .rgb(p[0], p[1], .p[2]).build()
>> でいいんじゃね？
2025/05/05(月) 09:29:59.66ID:jqQPAhm/
>>152
こちらのID辿ってみたらいい
2025/05/05(月) 09:37:07.71ID:jqQPAhm/
>>62
>>68

複おじはderive_builderを全力で支持
初期化関数は全否定していた

ところが…
2025/05/05(月) 10:05:55.48ID:n6fK3gUl
＞ .R(p[0]).G(p[1]).B(p[2]).build()

これ3つとも指定が必要ならメソッドを分けるべきではないと思う
それ以前にRustのプログラミングしたことないのかメソッド大文字は置いとくにしても
この場合ならp[0]はRust的な使用方法ではないな
(r, g, b)もしくはRGB構造体で持つかその参照で持つのが普通
p[i]はなるべく避けてイテレータ時点でポインタを動かして参照で持つか小さいなら値で持つ
構造があるならその構造で持つ
そのためp[i]の形が出てきたらRustでは少し臭うため怪しみ避けられないか考える
2025/05/05(月) 10:33:19.28ID:20YqVkB+
>>75
>まつもとなかい

うby界隈のmatzとそのとりまきか？
2025/05/05(月) 10:58:23.25ID:EffckoF6
>>155
> これ3つとも指定が必要ならメソッドを分けるべきではないと思う
おっ
derive_builderって必須パラメータをランタイムチェックとはいえ個別setterの形で適切に扱えるというのが重要なコンセプトなんだけど、ここにきて全否定か
2025/05/05(月) 11:07:31.16ID:20YqVkB+
>>128
>.rgb(p[0], p[1], .p[2]).build()

重複を主張する人の場合
.rgb(p[0], p[1], .p[2]).b(3).g(4).r(5).g(6).b(7).build()
みたいな間違いが起こるんだと思うよ
2025/05/05(月) 11:07:36.46ID:aemkUy0l
ボクシングには蹴り技がない
それは重要なコンセプトだと考えていた時期が俺にもありました
2025/05/05(月) 11:10:17.68ID:jqQPAhm/
コンパイラでうまくいかないから規約で縛ると言うことだろ？ビルダーパターンを導入する意義とどんどん崩れていく

RGB各値は指定が必須とは限らない
defaltで各値が0指定されていて同じなら書く必要がないだう
初期化関数では場合によっては記述する必要があるけどそれも必須ではない

疑似カリー化で少しずつパラメーターの違う複数のオブジェクト生成を行う場合にも便利
2025/05/05(月) 11:19:55.94ID:upfK5ln+
f(
　red=red,
　green=green,
　blue=blue,
)

f()
　.red(red)
　.green(green)
　.blue(blue)

どちらの方式でも間違えようがないと思うんだが
ミスが起きると言ってる人はどういうミスを想定してるのだろう
2025/05/05(月) 11:28:12.80ID:jqQPAhm/
red=p[0];　//p[0]は実際はblue
green=p[1];
blue=p[0]; // コピペの修正漏れ
2025/05/05(月) 11:28:24.28ID:EffckoF6
>>161
今更そんなところを理解できてなかったのか？
greenの指定を忘れたら前者はコンパイルエラー、後者は実行時エラー
2025/05/05(月) 11:35:07.99ID:jqQPAhm/
>>162
これの悩ましいところは後ろのコピペ修正漏れでblueに正しいp[0]が指定されているので
原因が判断しにくいところ
2025/05/05(月) 11:41:36.57ID:upfK5ln+
>>163
前者と後者は同じ
greenの指定をしなくてもコンパイルエラーとならない
greenは指定しなかった場合にデフォルト値となるオプション引数
2025/05/05(月) 11:44:04.39ID:EffckoF6
>>165
知らんがな
俺は必須パラメータの問題を指摘している
2025/05/05(月) 11:44:39.10ID:upfK5ln+
>>162
p[0]やp[1]など
可読性の悪いコードを書くやつは失格
p.red p.green p.blueにしろ
2025/05/05(月) 11:45:55.35ID:jqQPAhm/
>>167
dataと言うバイト列の中の一部だとしたら？
2025/05/05(月) 11:47:59.01ID:upfK5ln+
>>166
おっちょこちょいだな
直前のこれを見ろ
必須ではなくオプションパラメーターだ

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない
2025/05/05(月) 11:50:23.87ID:upfK5ln+
>>168
バイト列？
各8bitなのか各16bitなのかそれ以上なのかそれでは構造がわからん
ちゃんと構造体の列にするべきだ
2025/05/05(月) 11:54:15.50ID:jqQPAhm/
>>170
また真面に回答できないから適当に話をごまかして議論のための議論しようとしてる
受信データなどのバイト列から値を取り出すのは一般的だろう
必ずしも構造体の列構造とは限らない

それと数値指定無くすならコーディング規約でこう書かないとアウトですとするのか？
blue=data[ i + blue_index_offset];
red=data[ i + red_index_offset];
green=data[ i + green_index_offset];
2025/05/05(月) 12:01:19.27ID:upfK5ln+
>>171
あのさ
Rustでプログラミングしたことないの？
Rust以外でもシリアライズとデシリアライズしたことないの？
まともなプログラミングしたことある人ならRustですぐにserdeにたどりつく
2025/05/05(月) 12:10:05.78ID:aemkUy0l
まともな人が言ったのか人形が言ったのか全然わからない時代だ
人形が言ったにすぎないなら、そんな言葉は存在しないのと同じ
2025/05/05(月) 12:14:04.97ID:jqQPAhm/
>>172
お前はわざと議論のための議論してるだけだろ
通常のコーティングで出てくるであろう例を誤魔化している
2025/05/05(月) 12:16:46.89ID:jqQPAhm/
p[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのためにどれだけコーディング量を増やして
ライブラリ依存させていくのか
本当に意味不明
2025/05/05(月) 12:33:03.95ID:upfK5ln+
>>175
そんな可読性が悪くてミスしやすいプログラミングは避けるべきだ
構造化と抽象化が不得手でプログラマやエンジニアに向いてないな
serdeは構造体に#[derive(Serialize, Deserialize)]など付加するだけでデシリアライズ関数などは自動生成される
2025/05/05(月) 12:57:25.54ID:jqQPAhm/
>>176
構造体にって自分で書いてるだろ
単なるバイト列からp[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのために構造体などを作らないといけない
178デフォルトの名無しさん
垢版 |
2025/05/05(月) 13:06:55.72ID:Q0EqhiJQ
p[ i+0/*0=赤*/ ],p[ i+1/*1=緑*/ ],p[i +2/*2=青*/ ]
俺ならこうするよ
コメントを見れば0が赤、１が緑、２が青と見たん瞬間わかる
日本語なので英語より間違えにくい
もし間違った数字が間違ってたらコメントと比べればすぐわかる
2025/05/05(月) 14:25:06.41ID:aemkUy0l
（言語を強化することにより）アプリのコーディング量を減らせという話はなかなか面白い
言語の数がアプリの数より多い気がする原因はこれかもしれない
180デフォルトの名無しさん
垢版 |
2025/05/05(月) 15:35:05.95ID:4XowqzeV
>>174
議論のための議論をしてるのはお前だろ
それともガチで何も意味を読み取れないインデックスアクセスが正義と思ってるわけ？
どんなみじめな経験を積んできたんだよ
害悪プログラマすぎて仕事で関わらないことを願うわ
181デフォルトの名無しさん
垢版 |
2025/05/05(月) 15:41:59.59ID:AjenNrLi
議論とは関係ないけど大体の画像処理ライブラリだとRGBもBGRも扱えるように channel[0], channel[1], channel[2] のようにアクセスさせると思う
内部のデータによって channel 数は1や4 (アルファチャネル付き) もあるし
182デフォルトの名無しさん
垢版 |
2025/05/05(月) 16:02:16.97ID:Q0EqhiJQ
仕事はお金を貰ってやることだから丁寧に書いて上司に褒められる必要があるけれど
趣味とか経営者とかなら何を書いてもじゆうなんだよな
183デフォルトの名無しさん
垢版 |
2025/05/05(月) 16:11:32.03ID:Q0EqhiJQ
簡潔で見にくいコードを書くか
冗長で醜いコードを書くか
２択だな
2025/05/05(月) 16:35:32.16ID:0Pl94lQ7
>>181
これはそう
画像に限らず構造化されたバイナリデータを扱うときに一般に言えることだけど、
単純にビット列をそのまま構造体として読み替える間違いは、低水準に踏み込める言語に入門して調子乗ってる初心者がやりがち
2025/05/05(月) 16:47:29.64ID:aemkUy0l
上司はunsafeの箇所をチェックすればいいのに
コンパイラが自動で調べてエラーがなかった箇所を、手動で調べ直して逆張りするのが胡散臭い
2025/05/05(月) 18:15:43.01ID:fQ8xBj6s
Serdeは暗黙のCopyしがち
2025/05/05(月) 18:29:47.69ID:jqQPAhm/
>>180
８０代のおじいさんと仕事をする機会はないかな
2025/05/05(月) 22:23:21.43ID:I4eA7HrP
話を整理すると

>>82
>> .G(p[0]).R(p[1]).B(p[2]).build()
>> のところを容易に
>> .R(p[0]).G(p[1]).B(p[2]).build()と間違え

と彼は言い出すから
それは名前付けせずにp[0]を用いていることが間違える本質的な問題という話だよな
2025/05/05(月) 22:25:33.48ID:I4eA7HrP
さらに

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

と彼は言ってるので
彼の好み通りにp[0]を用いるとして

名前付きオプション引数方式
foo(
　green = p[0],
　blue = p[2],
)

ビルダーメソッド方式
foo()
　.green(p[0])
　.blue(p2])

どちらの方式でも同じだな
仮にミスが起きるとしたらそれは名前を付けずにp[0]を使っていることが本質的な問題であると確定
2025/05/05(月) 22:47:31.22ID:fQ8xBj6s
構造体は
foo{green:green,blue:blue}
を
foo{green,blue}
と描ける訳で
ビルダーメソッド方式とやらも
foo().green().blue()
的に描ければ無駄が減るから改良してくれんかのぅ
2025/05/05(月) 23:13:19.16ID:If8Py5os
>>189
その大量連投していた彼はRustをほぼ知らないと判明した上に他の言語の経験値も低そうなので彼自身に問題があることを理解できないと思う
2025/05/05(月) 23:39:40.43ID:Cn3HeiMA
その連投してスレを荒らしていた人が
「おじ」「複おじ」「おじいさん」「おじいちゃん」使いの人だったとはね
>>61 >>70
193デフォルトの名無しさん
垢版 |
2025/05/05(月) 23:42:50.66ID:fQ8xBj6s
foo().(green).(blue)
でもいいな
2025/05/05(月) 23:55:27.76ID:hXT/3Bxe
RustはJavaよりも構造体リテラルの表記が強力だから
Builder使うよりOptions構造体１つで渡す方が楽かもしれんね
パターンとしてはBuilderよりマイナーだけど
2025/05/05(月) 23:58:49.46ID:+Xl4Ck1b
>>190
引数なしで何を指定するのか？

>>193
メソッド名なしはエラー

どんな方式を取ろうとも大元の変数(ex. rgbやp)は指定せざるをえない
foo().green(rgb).blue(rgb)
2025/05/06(火) 09:36:09.23ID:sXCqetJD
>オプション引数やキーワード引数については他言語が内部的にやってることをRustの場合は開発者が自分でやらなきゃいけないことになっててバカらしい

>しかも関数シグニチャに情報をまとめられないから書く方も読む方も煩雑になるだけで開発者的には何もメリットがない

これに尽きる
言語に機能が不足してるから何でもかんでもビルダーパターンにしなきゃいけなくてサードパーティのマクロに依存することになる
アホらし
2025/05/06(火) 09:48:17.91ID:j5CJU7Aq
>>196
真逆だろ
キーワード付オプション引数をズラズラ並べた長い長い関数シグニチャはデメリットしかない欠陥品
しかも機能拡張したらさらにキーワード付オプション引数が増えて関数シグニチャが変わるアホらしさ
2025/05/06(火) 09:51:10.91ID:HDXWn70Z
複数IDと口調を使い分けて自分のレスに賛成するキチガイが複おじ
199デフォルトの名無しさん
垢版 |
2025/05/06(火) 09:51:38.50ID:K1Pjz07i
Rustのダサい処は認めるべき
2025/05/06(火) 09:56:28.46ID:HDXWn70Z
>>197
ビルダーパターンは30年以上前から知られていたけどあまり有用ではないので使われていない
過去に誰かがざっくりデザインパターンを否定してたけど、その人の言うにはデザインパターンで有用なものは言語自体に取り込まれるはずだと

実際いくつかは新しい言語では取り込まれている
2025/05/06(火) 09:56:50.79ID:SvTeM3j9
マクロで解決可能なんだろ？ それは「不足している」のか？
まあ標準ライブラリとして入っているべきみたいな論はあるかもしれんけど、マクロでの解決が悪くて言語機能として直接サポートするのが良いとする根拠は出てないな。

言語ユーザがそれぞれのやり方で解決できる自由さと言語の方針を強制する一貫性は両立しないがそれぞれに良さはあるし、 Rust は今のところ自由さをとりつつもデファクトな地位のライブラリはあるという状況だ。
手頃な妥協点と言えるだろ。
2025/05/06(火) 10:01:33.47ID:HDXWn70Z
些細な内容なら初期化関数を複数作ればよい話で更に多くなればオプション指定する構造体を作ればよい
mutに拘る必要が無ければさらに多くの可能性がある

わざわざ穴の多いビルダーパターンを使う必要はない
2025/05/06(火) 10:08:26.28ID:SvTeM3j9
>>200
ポールグレアムはイディオム (デザインパターン) は言語機能として持つかライブラリにまとめるべきと述べていて、考えられる様々なパターン (またはこれから登場する未知のパターン) をライブラリにまとめるには「本物のマクロ」が必要と主張してた。
そして本物のマクロを持つ実用的な言語は Common Lisp くらいしかなかったんだが、 Rust のマクロは彼の言う本物のマクロだ。

マクロで抽象化されてるならその実装がビルダーパターンでもそうでなくてもどうでもいいよ。
2025/05/06(火) 10:10:04.33ID:j5CJU7Aq
>>202
初期化関数を複数作るとオプション分の組み合わせ爆発となる一番アホな方式
それならビルダー方式がよい
2025/05/06(火) 10:12:49.15ID:HDXWn70Z
>>204
他の言語では大体オーバーロードでオプション指定しているけどそれが馬鹿だとは思わないけどね
2025/05/06(火) 10:15:57.89ID:j5CJU7Aq
>>205
それはオプションが増えると組み合わせ爆発が起こる馬鹿な方式
2025/05/06(火) 10:17:10.44ID:HDXWn70Z
>>206
同じ主張と文章を繰り返すやり方が複おじそっくりですね

オーバーロードの初期化関数で馬鹿らしいと思うのは型が同じで対象が違うものがある時
重複を避けるためにシグネチャの設計をしなくては成らないことは馬鹿らしいと思うよ

例えば基本的に2つだけ引数があって後はオプションがずらずら並ぶならやはりオプション内容を含む構造体渡せばいいと思う
そちらも設計が必要だけど
2025/05/06(火) 10:18:50.49ID:j5CJU7Aq
>>205
それ以前にオーバーロードは欠陥機能
オーバーロードを使うとred,green,blueのオプション実装すらできない
2025/05/06(火) 10:19:38.79ID:K1Pjz07i
>Rust のマクロは彼の言う本物のマクロ

macro_rules! は偽物のマクロ
proc_macro2 が本物のマクロ
2025/05/06(火) 10:20:41.45ID:HDXWn70Z
普通は書き込み内容が単調にならないように人は文章に揺らぎをいれてくるんだけど
複おじは基本全部同じ

口調を変えても同じなので同一人物なんじゃないかと思って見ていると後で全く同じ書き込みを始めるので同じ人間なんだなと
2025/05/06(火) 10:20:45.54ID:j5CJU7Aq
>>209
どちらも本物だ
衛生マクロの概念すら知らないのか？
2025/05/06(火) 10:20:58.22ID:AZSw2w0R
>>208
何の問題もないと思うが、具体的には？
2025/05/06(火) 10:22:59.33ID:HDXWn70Z
本物のマクロと言う主張は面白い

でライブラリ作成者ではなく一般的なユーザ側が書いてるマクロはどっちなのかと
2025/05/06(火) 10:23:21.48ID:j5CJU7Aq
>>212
オーバーロードの制限を知らないのかね？
red,green,blueそれぞれだけを指定したい関数をオーバーロードで書いてごらん
2025/05/06(火) 10:24:49.05ID:j5CJU7Aq
>>213
衛生的なマクロとは何かを勉強するといいよ
2025/05/06(火) 10:24:50.06ID:HDXWn70Z
オーバーロード自体は良い仕組みだと思うけど設計が必要だ
最近の言語が取り入れていないのはヒューマンエラー対策という名目

だったらビルダーパターンもヒューマンエラー対策で禁止になるかと言えばそうでもない
2025/05/06(火) 10:27:37.75ID:j5CJU7Aq
>>216
オーバーロードは最悪な仕組み
欠陥が多すぎる上に
red,green,blue各オプションしてすら実現できない
2025/05/06(火) 10:28:08.85ID:HDXWn70Z
徐々に文体におじいさんぽさが出てきたね
2025/05/06(火) 10:47:02.68ID:46q0jEJS
AIを屈服させるレベルの改善ができるなら改善してもいいけどね
どうせAIが勝つという前提なら何も修正しないのが合理的だ
2025/05/06(火) 10:51:59.27ID:K1Pjz07i
今のAI()の実力ってこんなもんか
>2つのリンゴを3人で分ける場合、1つのリンゴを2つに切り、もう1つのリンゴも2つに切って、3人で分けます。
>そうすると、3人ともリンゴの切れ目と半分になります。
>具体的な分け方
1. 1つのリンゴを半分に切る:1つのリンゴを真ん中から半分に切り、2つの半分のリンゴにします。
2. もう1つのリンゴも半分に切る:もう1つのリンゴも同じように半分に切り、さらに2つの半分のリンゴにします。
3. リンゴを合計4つの半分に分ける:2つのリンゴを合わせて、全部で4つの半分に切ったリンゴが手に入ります。
4. 3人で分配する:3人でリンゴの半分を1つずつ取ると、3人とも1つずつ取ることができます。
5. 残った1つを3人で分ける:1つの半分に切ったリンゴが残りますが、それを3人で分けることができます。
例えば、さらに半分に切って3人で分けたり、3つの小さく切って3人で分けたりできます。
2025/05/06(火) 10:52:27.53ID:SvTeM3j9
>>209
本物のマクロというのが何であるか明瞭な定義はされてないのだが、文脈的に「構文木の操作が出来る」というのが要件だと一般的に解されている。
トークン単位の置き換えしか出来ない C のマクロのようなものを除外するための言い回しだ。
構文木を操作できるなら操作できる範囲の違いは本物のマクロかどうかには重要ではない。
(もちろん出来ることが多いほうがより良い本物のマクロとは言えるだろうが、出来ることが多いほうが危険な間違いも引き起こしやすいので現実には適度に制限があったほうが良いこともある。)
macro_rules! も普通は本物のマクロと解される。
2025/05/06(火) 11:06:32.44ID:46q0jEJS
リスパーはmatchを知らない

matchを知らなくても理解できるマクロが本物のマクロ
2025/05/06(火) 11:11:44.35ID:HDXWn70Z
複数ID使用おじ

別人が複おじと疑われたら自分は複おじじゃねーよと反論する
気持ち悪いから
ところが何故かしない

複おじはそういうのに反論しない仕組みになっている
2025/05/06(火) 11:19:55.25ID:AZSw2w0R
>>214
ヒント:
struct Red(u8);
2025/05/06(火) 11:20:28.10ID:HDXWn70Z
マクロ自体がただの似たような機能の概念の総称であってその中で本物だ、元祖だと言っても笑われるだけ
キーボードマクロは真のマクロではないとか衛生的ではないと言われてもそうですかと
2025/05/06(火) 11:22:58.43ID:HDXWn70Z
ID:j5CJU7Aq　　の反応待ちのawait状態です
2025/05/06(火) 11:23:42.97ID:K1Pjz07i
>>223
複OGはどうでも良いけど
5chはもう禿しく過疎ってるのにこのスレだけやけに延びてるのは不自然だと感じる
2025/05/06(火) 11:31:04.25ID:SvTeM3j9
>>225
「本物のマクロ」というのは正しさとか起源を主張しているわけではなくそういう名前の分類。
少なくとも C のマクロなどでは様々なイディオムを抽象化するには不十分だというごく当然の話をしてる。
2025/05/06(火) 11:33:12.59ID:AZSw2w0R
なお、名前付き引数での呼び出しを前提とするならばhoge(red) と hoge(green)を名前付き引数の引数名だけで呼び分けるオーバーロードは技術的には実装できない理由は特にない
しかし、多くの言語では名前付き引数の使用はオプションだしこの場合はhoge_red(val)のように機械的に名前変えりゃいいだけだから、実装コストに見合わないという判断をされているのだろう
2025/05/06(火) 11:39:56.59ID:ZZS2r6Zz
>>224
こうですか？わかりません

impl From<Red> for Color {...}
impl From<Green> for Color {...}
impl From<Blue> for Color {...}
impl From<(Red, Green)> for Color {...}
impl From<(Red, Blue)> for Color {...}
impl From<(Green, Blue)> for Color {...}
impl From<(Red, Green, Blue)> for Color {...}

let red = Color::from(Red(255));
let yellow = Color::from((Red(255), Green(255)));
let white = Color::from((Red(255), Green(255), Blue(255));
2025/05/06(火) 11:48:34.17ID:46q0jEJS
メリットが不確実なだけでしょ
メリットもコストも確定していてなおかつ見合わないという話ではない
2025/05/06(火) 12:18:40.67ID:0KYdit4+
このスレでずっと自演してる人って糖質とかなんだろうなあ
2025/05/06(火) 12:28:45.22ID:K1Pjz07i
traitで騒いでた自演と同じ人だろう
2025/05/06(火) 12:40:06.43ID:WV2uqB5+
オーバーロードはそもそもCのAPIにありがちな、後で〇〇2だの〇〇exだのが増えて格好悪くなる問題を解消するためのもの
後で引数名だけ異なるオーバーロードが増えたら名前付き引数を使っていない既存の呼び出しがエラーになるのは、互換性維持という本来の目的からすれば論外
2025/05/06(火) 12:49:02.99ID:w/CyTLi+
話題のderive_builderを使ってみた
構造体に属性を付けるだけで初期化関数を書かなくて済むのは便利だね
ドキュメント見ると今回は使ってないけど色々と機能が充実してるみたい
話題のred/green/blueはこれでいいのかな

use derive_builder::Builder;

#[derive(Default, Builder, Debug)]
struct Color {
#[builder(default = "0")]
red: u8,
#[builder(default = "0")]
green: u8,
#[builder(default = "0")]
blue: u8,
}

fn main() {
let pink = ColorBuilder::default().red(255).blue(200).build().unwrap();
println!("{pink:?}"); // Color { red: 255, green: 0, blue: 200 }
}
2025/05/06(火) 12:57:12.48ID:aXFsP9SC
>>235
よくない
散々言われている通り、必須属性の設定を忘れると実行時エラーになるという致命的な問題がある
2025/05/06(火) 13:06:06.15ID:w/CyTLi+
>>236
例えばファイル名を打ち間違えちゃったけど
まずリリースモードの前にデバッグモードの時点で実行時エラーで気付いて
直してしまえばそれ以降は大丈夫と同じじゃないのかな
特に問題ないような
2025/05/06(火) 13:10:03.39ID:w/CyTLi+
補足するとファイル名は必須項目だけど
コンパイル時にチェックできるのは型だけだから現実的にチェックできることはほとんどないよね
2025/05/06(火) 13:16:05.70ID:sXCqetJD
お前らめちゃくちゃ暇人だな
レス多すぎ
2025/05/06(火) 13:18:37.75ID:sXCqetJD
>>201
>マクロで解決可能なんだろ？
ビルダーパターンの手書きコード量を多少なりとも削減したいという問題は解決してるかもね
それが本当に解決したい問題だと思ってるのならそれでいいんじゃない
2025/05/06(火) 13:24:33.64ID:w/CyTLi+
ビルダー方式でも他の方式でもなんでもいいけど
初期化のための関数を自分で書くよりも>>235のように構造体への属性マクロ指定だけにするのがいいと思う
面倒がなくコードがすっきりとしてプログラミングミスも起きないから
2025/05/06(火) 13:44:43.14ID:aXFsP9SC
>>238
それはそうなのだけど、だからといってコンパイル時のチェックを安易に諦めたら、極論Cでいいだろって話になっちゃう
Rustの存在意義が問われる危険な思想
2025/05/06(火) 13:46:48.63ID:ZZS2r6Zz
現時点のderive_builderはFooBuilder::new()に必須項目を渡すパターンには対応してないっぽいな
全部default()でも構わないケースだと使えるけどRegexBuilder::new(pattern)みたいなケースもあるから万能ではない
2025/05/06(火) 13:53:00.39ID:K1Pjz07i
良い例があるな
https://mevius.5ch.net/test/read.cgi/tech/1643696741/33
貴方が配慮を欠いている
そのx^nつまりxのn乗を求めるにしても
例えば2^100を求めたいならば128bitがないと溢れるのでu128::pow(2, 100)となるが
2^5を求めたいだけで結果も8bitで十分ならばu8::pow(2, 5)となる
このようにメモリサイズも異なってくるので別々の関数が必要
もちろんu128::pow(x, n)があればu8::(x, n)をカバーできるが明らかに無駄である
そこで符号なし整数だけでも
u8::pow(x, n)
u16::pow(x, n)
u32::pow(x, n)
u64::pow(x, n)
u128::pow(x, n)
と5つの関数が必要となる
一方でxの型が確定しているのであればpowで再び型指定は不要なので
x.pow(n)と表記することも可能
以上は整数の場合だがxとpowの結果が小数の場合は2種類の関数が必要となる
f32::powi(x, n) 【nが整数の場合】
f32::powf(x, n) 【nも小数の場合】
もちろんnが小数のpowfだけあればpowiもカバーできるが明らかに無駄なので2種類必要となる
さらに32bit小数だけでなく64bit小数も扱う必要があるため以下も必要
f64::powi(x, n) 【nが整数の場合】
f64::powf(x, n) 【nも小数の場合】
これらもxの型が確定していれば以下のように略して書くことも可能
x.powi(n) 【nが整数の場合】
x.powf(n) 【nも小数の場合】
ちなみに「x^n」を表記するのに不自然な「pow(x, n)」よりも「x.pow(n)」の方がたまたま自然に見えるが誤差だろう
どちらでも好きな表記法を選べばよいだけにすぎない
2025/05/06(火) 14:21:46.28ID:97zxA3f+
>>244
例えば
このように
もちろん
そこで
一方で
以上は
もちろん
さらに
これらも
ちなみに


そのx　から始まって論理的？接続で参照を握ったままで最後まで離さないな
読みにくいのは当然
2025/05/06(火) 14:26:52.22ID:97zxA3f+
id変わってしまった
2025/05/06(火) 14:30:10.65ID:97zxA3f+
上の強烈な接続もビルダーパターンの一種かな？と思ってしまう
2025/05/06(火) 15:04:10.81ID:46q0jEJS
>>242
忠臣蔵みたいに、諦めたふりをするぐらいがちょうどいい
危険思想？
なんのことやら
2025/05/07(水) 00:06:42.37ID:oRVzsgHT
>>245
複おじ語録よくぞまとめてくれたな
ほめてつかわす
2025/05/07(水) 10:19:22.81ID:0n7pwB6u
後から〇〇2や〇〇exが増える問題ってRustだとどう対処するのが一般的なんだろう
まあRustの場合ABIを維持する必要のあるケースは比較的限られてるけど、引数増やしたら既存のソースは壊れるよね
最初から構造体にしておけというのは意味のない意見なので無しで
2025/05/07(水) 10:32:45.05ID:Gjm+c4fd
普通に関数が増える
2025/05/07(水) 10:59:58.84ID:jrPMMEx+
>>250
ダイナミックリンクで提供する場合はバイナリ互換性が必要な場面も多いのは Rust でも変わらないよ。
言語の文化としてはスタティックリンクを使いがちではあるけど。
ダイナミックリンクは OS の機能なので言語の側からどうにか出来る余地も少ないし、 OS の文化に乗っかるしかない。
2025/05/07(水) 11:36:16.32ID:hcgUqjSt
○○exがある言語でJVMを実装し、○○exに依存してないと主張する
2025/05/07(水) 13:51:32.15ID:nPKhYJKb
Ubuntu 25.10から、sudoがsudo-rsに置き換わるそうだ
2025/05/07(水) 14:09:26.72ID:jrPMMEx+
まあ Rust が良いかどうかはともかくたまには刷新したほうがええやろ。
2025/05/07(水) 14:24:28.93ID:4cRsIVof
いや、sudoのようなパフォーマンスが重要でないコマンドなら
RustではなくGoで書くべきだった
2025/05/07(水) 14:25:34.83ID:iQ9Crc5o
どんなものでも機能も速さも同じだとしても
C/C++製よりRust製を選ぶわ
C/C++のせいでのセキュリティホールが後からいくらでも見つかってる現状
2025/05/07(水) 14:27:05.51ID:iQ9Crc5o
>>256
余分なランタイムが必要なGoはありえない
2025/05/07(水) 14:50:13.61ID:sBD46f0F
>>250
外部ライブラリならメジャーバージョン増やして普通に破壊する
旧バージョンのAPIをcompatモジュールとかに入れとけば親切

標準ライブラリはエディションで切り替える形になりそう
std::preludeのサブモジュール名は最初v1だったけど今はrust_20XXに方針転換してる
グローバルな名前の追加も一種の破壊だし
260デフォルトの名無しさん
垢版 |
2025/05/07(水) 15:20:58.49ID:7aByWlek
下記は全て2025年５月７日の記事

OpenAI、ChatGPTの6つのモデルの違いと適切なプロンプトを解説
https://news.mynavi.jp/techplus/article/20250507-3275757/

Microsoftの新規のソースコードの約3割をAIが生成、Nadella氏が明かす
https://news.mynavi.jp/techplus/article/20250507-3271749/

スコットランドの住民を悩ます謎の怪音「ヘブリディアン・ハム」の正体はいまだ不明
https://karapaia.com/archives/507130.html
2025/05/07(水) 18:35:48.88ID:hcgUqjSt
モダンなライブラリはdeprecateしやすいのか
古いCと最新のRustだけが残されて中途半端な時代は無かったことになりそうだ
2025/05/07(水) 19:03:14.70ID:3Nv7PA1l
いや、利用者が少ないうちに直しとけ心理で、どんな技術も通る道だよ
sudo-rsがいい例だがこういう長期間にわたって重要な役割を果たす、かつあまり変更が必要とされない用途が増えてくると、だんだんと進化は遅くなるものだ
2025/05/07(水) 19:08:29.35ID:Ja3pQWVu
>>257

(´・ω・)マジ？
2025/05/07(水) 22:26:25.21ID:LUGJMjLo
>>254
この国際的なプロジェクトでセキュリティ的に重要なものから順にRust化されていく一環だよ

Memory Safety for the Internet's most critical infrastructure
https://www.memorysafety.org/
2025/05/08(木) 09:08:51.16ID:8ptxnmrn
>>244-245
このように.drop();
もちろん.drop();
そこで.drop();
一方で.drop();
以上は.drop();
もちろん.drop();
さらに.drop();
これらも.drop();
ちなみに.drop();
2025/05/08(木) 09:25:34.07ID:xZxJToWs
ubuntuはsudoだけでなく、cp, ls, find, diff なんかもRust化する予定なんだな
ntpdもRust化が進められてる
2025/05/08(木) 09:33:12.04ID:n2pO1y9P
>>265
error[E0040]: explicit use of destructor method
help: consider using `drop` function

参考：https://doc.rust-lang.org/error_codes/E0040.html
2025/05/08(木) 10:28:22.03ID:1mgB1EfY
>>266
Ubuntuに限らず誰もが全てをC/C++製から安全なRust製へ変えたいと思っているが一気には無理なので重要なものや新たなものからRust採用という感じ
2025/05/08(木) 12:25:36.55ID:d06WSi70
全てを変えたい、とかいうビジョンは無意味
意味のないビジョンだよ
2025/05/08(木) 12:38:14.55ID:jIG0GCL4
安全でないC/C++を早く全廃したい世界の流れ
2025/05/08(木) 12:49:37.23ID:iRreO2Ee
Linuxコマンド開発専用言語Rust
2025/05/08(木) 12:51:53.54ID:Crcrgp42
メンテナ高齢化問題の対策としては良い取り組みなんじゃないかな
作業するのもインターンの学生が中心だろうし
2025/05/08(木) 12:55:02.85ID:Ad6EgOfh
多くのシステムやインフラがRust化してるね
この5chが使ってるCloudflareもRust製へと移行した
https://github.com/cloudflare/pingora
2025/05/08(木) 13:05:00.97ID:8ptxnmrn
コマンドツールがRustになってもAPIがRust用じゃない限り
CのAPIのラッパーでしかないけどそういう造りでもRust化したってカウントして良いのかは疑問
2025/05/08(木) 13:09:51.90ID:Ad6EgOfh
>>274
コマンドツールが誰に対するAPI？？
プログラムを書いたことないのかな？
2025/05/08(木) 15:06:07.28ID:a6DlXdfJ
こういうのってFedoraやらArchやらGentooあたりが人柱やってから普及していくものだと思ってたが…
Canonicalのくせに思い切ったことするなあ
2025/05/08(木) 15:26:10.55ID:n2pO1y9P
Ubuntuはカジュアル路線でしょ
初期状態だとrootも使えなかったと思う
他よりもsudoの負荷が大きい
2025/05/08(木) 18:54:46.08ID:gU6gKsMd
5chは真の漢が使う言語perlで書かれている
2025/05/08(木) 21:50:58.54ID:Ad6EgOfh
5chはperlだけでなくサーバも貧弱なのでキャッシュしてくれるCDNに頼らないと成り立たない
5chが利用しているCDNは>>273のCloudflareでRust製だよ
2025/05/09(金) 00:22:05.59ID:tlxkaAFs
>>279
誰が見てもただの印象操作
子供でも分かる
2025/05/09(金) 00:29:31.48ID:2I38bFbw
5chどうこうよりも
インターネットを支えるCDN世界トップシェアのCloudflareがRust化したインパクトが大きいよな
2025/05/09(金) 00:31:49.35ID:tlxkaAFs
そういう幼稚な書き込みはやめとけよｗ
283デフォルトの名無しさん
垢版 |
2025/05/09(金) 07:07:43.56ID:rj7v79QA
もう見抜けない、最先端のAIディープフェイク動画は心臓の鼓動まで再現、判別が困難に
2025-05-08
https://karapaia.com/archives/507859.html
2025/05/09(金) 08:08:28.79ID:oZuZXuL3
クラウド界トップのAWSもRust製に
2025/05/09(金) 10:14:04.36ID:52E7/scg
AWSのプラットフォームはほぼJavaでしょ
ハードウェア寄りのローレベルな部分だけシステムプログラミング言語を使っていて、更にその中の一部でRustを使っているものもある、という程度
2025/05/09(金) 11:14:51.12ID:OK+uD+G+
https://japan.zdnet.com/article/35183866/
2022-02-22 14:31
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、コンテンツ配信ネットワーク「Amazon CloudFront」、LinuxベースのコンテナーOS「Bottlerocket」がある。
2025/05/09(金) 11:17:44.85ID:/9qtDNkV
大半は既存のソフトウェアの組み合わせなんで、仮に自社内で書いているプログラムの全てを Rust で書いても割合としては数割ってところだろう。
ただ、これから割合が増えることはあっても減りはしないとは思う。
2025/05/09(金) 11:50:43.35ID:OnJLIdRJ
Rustがこのままオワコンになったら撤廃もあり得るだろ
2025/05/09(金) 11:56:12.65ID:Olh4o+f/
AWSもRust製か
Rust製のクラウドとJava製のクラウドが競争したらJava側が100%負けるだろうしな
2025/05/09(金) 12:53:15.09ID:84hPiMCY
クラウドってなに？
ハイパーバイザがrustで作り直されたの？
2025/05/09(金) 14:06:44.17ID:uNK6cNVH
>>286
これは誤訳
原文だと、それらのサービスにRustを使っていると書かれているだけ
RedditなんかでAWS社員のコメントとか探してみりゃわかるが、AWSは基本Java
2025/05/09(金) 15:01:02.33ID:tXd4RgSB
エネルギー効率に劣るJavaなんかで構築していたら笑うわ
>>286でもそう書いてるよな
2025/05/09(金) 15:25:02.70ID:61qYlkzR
Rustって人気なのね
AIにC#から移植できる？って聞いてみたらいやだって言われちゃったからRustが広まるの、なんか困る
2025/05/09(金) 15:30:45.33ID:EODoJGlX
JVM前提な特殊環境を除き
Rustの登場でJavaを使う意味は全くなくなった
2025/05/09(金) 15:41:48.51ID:xdbk/Yg/
何の前提も縛りも無い環境こそが特殊
2025/05/09(金) 15:59:06.67ID:U8gSLCWq
コンテナ化は Java の有力なメリットだったけど Docker の隆盛で様変わりしちゃったね。
297デフォルトの名無しさん
垢版 |
2025/05/09(金) 18:53:55.90ID:lGkzhvel
>>293
いやだと言うAI、なんかいいな
2025/05/09(金) 22:11:52.71ID:dSLYIzJ3
>>291
サービス提供には安全性が一番重要なのでC++ではなくJavaを採用していた
Javaより安全で性能の良いRustが出現したため切り替えた
そしてAWSが発起人となってRust Foundationを設立した
299デフォルトの名無しさん
垢版 |
2025/05/10(土) 00:48:13.31ID:tNjV2wjQ
Rustで戦う領域ではない気もするけど、エンタープライズ向けはまだ弱いと思う
ここはまだJavaや.NETの資産が大きい

「ファイルが見つかりません」みたいにユーザーの言語でエラーメッセージが出たり、文字列のソート (例えば「あアいイ」のように、ひらがなカタカナを考慮した自然な順になる) だったり、そういうのが外部ライブラリ無しで揃ってるのが Java や .NET なわけで

規模としては相対的に小さくなってるけど、こういうのが必要な領域は普通にあるし、Javaが消えることは無いと思う
2025/05/10(土) 01:05:07.51ID:yPNtL6wL
>>299
外部ライブラリ無しで揃ってるという発想が頭おかしい
そんな間違った奇妙な視点を持ってしまうとRustには正規表現も乱数も何もかも存在しないことになるぞ
考えを改めなさい
301デフォルトの名無しさん
垢版 |
2025/05/10(土) 01:42:38.39ID:JK+pyj3t
ここでグチャグチャ言ってる間に徐々に置き換わって行きそうだな
2025/05/10(土) 03:04:27.68ID:39sc/8ak
firefoxが全部Rustに置き換わるのに100年ぐらい掛かりそうだけどな
2025/05/10(土) 03:26:38.07ID:qt+KVMl5
止まってるFirefoxより
ChromeとIEが着々とRust化を進めてるから先だろな
304デフォルトの名無しさん
垢版 |
2025/05/10(土) 08:39:56.30ID:tNjV2wjQ
IE?
2025/05/10(土) 08:45:29.97ID:K3qP9/A2
>>300
何でこいつ偉そうなんだ？
2025/05/10(土) 08:47:09.62ID:APagMvUq
>>299
人月業界は考えるだけ無駄として、SaaSだと新規開発は圧倒的にフルスタックTypeScriptが多いね
Rustは海外では革新的なDB作るぜみたいなエンタープライズの基盤系スタートアップでの採用例は見かけるが、国内ではその手のスタートアップは皆無に近いから絶望的な状況
2025/05/10(土) 09:09:05.25ID:B2q0uvrQ
品質に関する考え方は良い要素を揃えれば良くなるという単純なものじゃないよ。
結局のところ、どんな問題が出てくるかは事前にわからない。
出てきた問題に対処し続けるという歴史によって品質が作られるんだ。
確かに C や C++ に比べて Rust は全面的に良いけれども、活発な巨大プロジェクトではもう問題に対処しつくしていて Rust に置き換えるメリットは相対的に小さい。
部分的に Rust に置き換えることはあっても問題が起こってない箇所まで含めて全面書き換えを目指すのは割に合わない。
2025/05/10(土) 09:11:51.42ID:R8e2Bn+8
>>306
サーバーサイドでTypeScriptを使っているようでは負けるわ
309デフォルトの名無しさん
垢版 |
2025/05/10(土) 09:22:18.39ID:tNjV2wjQ
>>308
「負ける」というのは何において？
Rustで実装すると、そのサービスは使いやすくなったり、機能豊富になったり、プロトタイプを高速に作ったり、ユーザーの要望をより速く実現できたりするの？

勝ち負けが決まるのって、サービスの内容、ユーザー体験、リリース速度などが重要で、それを実現できるなら言語自体はさほど重要でない
TypeScriptはエコシステムが充実してるから、それに乗っかるのは一つの選択
(バックエンドTSはつらい点もあるから、他の技術を持ってるところなら他のものの方が良いと個人的には思うけど、そういう選択肢が世の中にあって割と普通に受け入れられてるのは現実として理解してる)
2025/05/10(土) 09:29:02.26ID:TSWWK3ZE
>>307
未だにC/C++が原因のセキュリティ脆弱性報告が常に何件も出続けている現実を見なきゃ
2025/05/10(土) 09:43:16.06ID:203d4oBt
>>309
それらの点ではどの言語でもほとんど同じだね
遅くてメモリも喰うJS/TSをフロントエンド以外で使うのは適材適所ではないから不利だけど
312デフォルトの名無しさん
垢版 |
2025/05/10(土) 09:49:57.08ID:DZgbwKL1
仮に外部ライブラリを使ってもRustはエンプラには向かないでしょ
この分野はオラクルやMicrosoftのような企業が時間かけて作ったきたからできたもので、現状Rustはこの分野向けのライブラリが充実してるわけでもないし、Rustコミュニティが力を入れるとも思えない (したとしても優先度は低い)

それに、安定性や将来の入手性が最も必要な分野で、多くの部分をOSSに頼るというのは業界として受け入れないと思う
(昨今OSS絡みの事件は多い)

低レイヤやWebバックエンドなど、Rustが強みになる分野があるのはその通り
2025/05/10(土) 09:51:04.61ID:K3qP9/A2
>>310
それでも何十年もc++が捨てられずに使われているのはなぜかと考えたことはないのか？
2025/05/10(土) 09:52:37.21ID:12iOKYOz
ひらがなカタカナ交じりの自然なソートなんて
今更Rustで描いても半日もかからんやろ
2025/05/10(土) 09:57:05.62ID:203d4oBt
c++はrustに勝てる点が全くなく既存資産だけが頼みの綱で終わりでしょう
巨大な既存資産だけは消えるまでに時間がかかることでしょう
2025/05/10(土) 10:00:12.38ID:K3qP9/A2
超超超熟練度が必要なCOBOLになる

C、C++、COBOL　まとめてC*
317デフォルトの名無しさん
垢版 |
2025/05/10(土) 10:05:17.70ID:tNjV2wjQ
>>314
漢字も当然含むし、ロシア語や中国語などを含む世界の多数の言語にも対応する必要もあるぞ？
時刻や日時の表記も国によって違う
Javaや.NETはランタイムが大きいと言われるけど、その中にはこういうのも含まれる
手間も大きいし、この分野を再実装するのも面倒でしょ
(自分が知らないだけで、既にそういう取り組みがあるのかもしれないけど)
2025/05/10(土) 10:08:42.67ID:K3qP9/A2
.NETでソートサーバを作ってそれにソートさせて結果をrustで使う
2025/05/10(土) 10:09:24.80ID:fdsy2R9k
日本だとエンプラよりは自動車の方が早いかもね
ボルボにはもう入ってるし10年以内にトヨタ車に入るくらいならあり得るかも
2025/05/10(土) 10:17:39.16ID:K3qP9/A2
システム周りでは標準で使われて、それ以外は他の言語の下請けになるのかと思ったが実際は違うと言うことか？

システム周りにもかかわらず外部に依存が必要であれば使われない
ライブラリが充実しないと完全な下請けにはなれず、c++のDLLのように一部高速化部位での限定利用になる
2025/05/10(土) 10:26:23.15ID:TkZSyEZj
証券取引みたいに、最高のパフォーマンスと最高の信頼性が求められるガチな領域もエンタープライズにあるのは事実で、
内部的にRustを使っているところがあってもおかしくはないが、そういうのって性質上外に情報が出てこないから盛り上がんないんだよね
自動運転もそうだけど、限界の性能を出そうとすると結局は頭の良い人間を上に据えたスペースシャトル型の厳格なウォーターフォールになるんで、夢がなくてつまらないという面も
2025/05/10(土) 10:38:30.67ID:B2q0uvrQ
COBOL なんか古代の遺物みたいに言われつつもかなり広くつかわれてるもんな……
2025/05/10(土) 10:44:10.80ID:M/F23qJj
最高のパフォーマンスを出すにはC/C++/Rustしかない
安全性を満たすRustは唯一の存在
これから少なくとも数十年間は天下を取るのだろう
324デフォルトの名無しさん
垢版 |
2025/05/10(土) 10:52:25.23ID:b8JFbEp9
>>303
EDGEか
2025/05/10(土) 10:55:11.42ID:B2q0uvrQ
AI が台頭してから電力使用量が劇的に伸びてるからな。
自動車の運転を人間のプロ水準で自動化するなら動力と同じくらいの電力が計算に必要という見積りもある。
AI がまだまだ伸びる分野なら効率は重要だ。
これはコストがどうのとかいうレベルではなくコストをかけても無いものは無い (足りない) という深刻な話で、プラットフォームを担う業者がいっせいに Rust に注目しているのも無理からぬことなのかもしれぬ。
2025/05/10(土) 11:33:01.79ID:SCGzG6Ua
そんな見積もり知らんけど50wでLv5運転できる人間が最高だな
327デフォルトの名無しさん
垢版 |
2025/05/10(土) 13:30:52.43ID:+8W9QSNf
やったことないけど組み込みの世界ではどうなの
Rust使われてる？
2025/05/10(土) 13:34:10.15ID:gWEfPBXM
トヨタはこの前、Rustで求人広告出してたじゃん
329デフォルトの名無しさん
垢版 |
2025/05/10(土) 13:36:27.29ID:zAVOQ4IK
組み込みはRustが多いですね
新規案件は殆どがRust
単品ではmrubyが多いですね
2025/05/10(土) 14:07:29.73ID:tG+fugNq
トヨタ系は基本的に愛知勤務だからな
Rustでもなんでも使って求人票を飾らないと厳しいんだろう
2025/05/10(土) 14:11:56.01ID:USkPlt1I
Rust使えるなら都落ちして田舎で開発するのも悪くないかも
今はたいていタイプスクリプトばっかだから変化が欲しい
332デフォルトの名無しさん
垢版 |
2025/05/10(土) 14:50:39.44ID:tNjV2wjQ
TSはフロント側とサーバー側を包括するフレームワークがあるのが強いんだよね
APIを定義してフロント側とバック側を区切る開発なら、バック側はコンパイルされるものが良いというのは同意なんだけど
TSを使うメリットがないと主張してる人は、こういう技術を知らないか、机上論を述べたいだけで実際の開発はしないから生産性など関係ないという人でしょ
2025/05/10(土) 15:01:33.78ID:M/F23qJj
>>332
その程度なら誰でも知ってるよ
SSR/SSGからhydrationしてCSRするコードも自作したことある
2025/05/10(土) 15:17:51.64ID:TkZSyEZj
今のWeb開発では、独立したバックエンドAPIはオプションだからね
Next.jsでサーバーサイドロジックが存在するのがデフォなので、よほどCPU intensiveな処理でない限りは、
Rustで別途独立したバックエンドを作ることはかえって遅延とコストを増大させる
フロントエンドまでRustエンジニアが自分で面倒見るってんなら好きにすりゃいいけど、
Rustエンジニアがフロントエンドやりたいかねえ
2025/05/10(土) 15:25:32.84ID:K3qP9/A2
フロントとバックエンドで常に齟齬が無ければいいんだけどと言う話になるとTSが出てくる
2025/05/10(土) 15:32:42.03ID:M/F23qJj
>>334
それはJS/TSだけでやろうとするからそういう制限になってしまう
RustとWasmも組み合わせてどこまでやるかで色んなパターンがある
2025/05/10(土) 15:45:18.30ID:Mv0kFcWv
>>332
RPC は昔からある取り組みじゃないか。
半世紀もかけて TS でしか実用にならない状況だと本気で思ってるのか？
338デフォルトの名無しさん
垢版 |
2025/05/10(土) 15:49:00.61ID:tNjV2wjQ
Wasmはサイズがね…
ごく最近のニュースだと、Prismaが実装をRustからTypeScriptに置き換えたのが話題になってたな
デプロイ時のサイズが問題になる分野だから妥当ではあるけど

フロントだとビルド時間の長さが課題になりそう
UIの位置やサイズを微調整したい場合でも、確認のために毎回重ためのビルドが必要になると面倒じゃない？
2025/05/10(土) 15:54:13.08ID:Mv0kFcWv
>>338
UI 記述言語で書いて形になってから Wasm (にコンパイル可能なプログラミング言語) に変換するような仕組みもある。
340デフォルトの名無しさん
垢版 |
2025/05/10(土) 15:57:42.52ID:JFaFsVis
>>337
RPCじゃなくてUIの描画込みの話だぞ
同じフレームワーク内でクライアントサイドのレンダリングとサーバーサイドのレンダリングを繋げたりできる
>>333 が書いてるようなもの
2025/05/10(土) 16:03:27.89ID:M/F23qJj
>>339
色んなパターンのうちそのUI記述言語を採用してのSSG/CSRのレンダリングコード共通化が有力の一つだよね
サーバーサイドからJavaScriptを完全排除してパフォーマンスを上げる方向性が正しいので
2025/05/10(土) 17:37:33.64ID:K3qP9/A2
web開発の現場に言ってRustとwasmの組合せを使いなさいと言っても鼻で笑われるだけ
2025/05/10(土) 17:57:46.62ID:GFzLbQz1
精神障害児で周りを振り回す無能です。
この業界で俺は死ぬかも。
悲しみ
2025/05/10(土) 17:58:59.59ID:GFzLbQz1
自慢したりとか怒ると自分の首を絞める。
死ぬ。
俺はプログラミング向いてないが、この業界に行くぞ。
どうも死んだほうが良い人間です。
2025/05/10(土) 18:01:36.75ID:GFzLbQz1
rustも分からんし三年間学んでプログラム書けない無能です。
質問ある？
2025/05/10(土) 18:01:51.09ID:GFzLbQz1
もちろんrustも分からん。
2025/05/10(土) 18:03:05.22ID:K3qP9/A2
rust is must
2025/05/10(土) 18:03:13.86ID:GFzLbQz1
そもそもこの世の中教えてくれない人が悪いと奥底で思っている無能。
人との縁を切って一人で後悔しがち。
ゴミ人間だよ！
2025/05/10(土) 18:04:21.67ID:GFzLbQz1
俺はガイジだ…
ガイガイガイジのガガイのガイ。
ガイジのボッチのやる気のある無能。
ゴミカス死んだほうが良い。
2025/05/10(土) 18:05:59.49ID:GFzLbQz1
がががーがががががががががががが～が～が～障害児
2025/05/10(土) 18:06:29.45ID:GFzLbQz1
我はガイジガガガイジ天地入れざる障害児
2025/05/10(土) 18:11:29.44ID:K3qP9/A2
不勉強で天地入れざると言う言葉を知らなかったが
明治とかの言葉なのかな？

学があるね
2025/05/10(土) 18:22:28.75ID:GFzLbQz1
>>352
ありがとう！
言葉を表面上の意味しか捉えられないガイジだけど、他人に迷惑かけるのは良くないよね…
スレ荒らしてすみませんでした…
2025/05/10(土) 18:23:33.01ID:K3qP9/A2
どうせ俺以外誰も見ていないから好きなだけ荒らせばいいと思うよ
2025/05/10(土) 18:23:55.63ID:GFzLbQz1
おちつきました。すみませんでした…
2025/05/10(土) 18:29:52.94ID:Mv0kFcWv
>>352
抜刀隊の歌詞にあるから知ってた。
ミリタリー趣味の人ならまあまあ知ってるんじゃないかな。
私は音楽側の趣味で知ったんだけど。
2025/05/10(土) 18:58:55.45ID:Pq21kD+5
夏休みはまだ早いぞ
2025/05/10(土) 19:15:47.47ID:K3qP9/A2
業界には何らかの形でメンタルを病んでる人間が50万人以上いると思う
2025/05/10(土) 19:53:17.55ID:39sc/8ak
このスレは特殊だから騙されないように
2025/05/10(土) 20:19:31.95ID:K3qP9/A2
自分は悪質でなければ荒らしを許容するスレにいた

そこでは荒らしとも楽しく話してそのうち荒らしが真面目なコテになったりしていた
みんなもうどこかに行ってしまったのが残念だけどそれも運命だなと
361デフォルトの名無しさん
垢版 |
2025/05/10(土) 20:45:49.44ID:+8W9QSNf
病院行けよ
俺は今日行ったぞ
2025/05/10(土) 21:12:29.85ID:RAkiMuTX
unsafeなライブラリのラッパーでsafeに設計するのってどうやるの
363デフォルトの名無しさん
垢版 |
2025/05/10(土) 21:22:13.51ID:JK+pyj3t
F-22 ada
F-35 C++
2025/05/10(土) 21:48:52.45ID:Mv0kFcWv
>>362
結局のところ、外側から見て safe な振る舞いになるようにするというだけ。
場合によっては不可能なこともあるけど具体的な状況がわからないとなんとも言えない。
2025/05/10(土) 21:52:02.98ID:arKsDnK7
>>362
未定義動作の可能性を排除するために必要な条件を全部チェックする
panicとデッドロックはOKらしい（停止すれば許される）

No matter what, Safe Rust can't cause Undefined Behavior.
https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
2025/05/10(土) 22:22:13.21ID:M/F23qJj
>>342
そういう低レベルな現場は無視してもいいんだよ
現在もJSのフレームワークは乱立しながら変化進化し続けているように多様性がある
今回の件と関係なくwasmを既に併用しているところも多いからその点もだいじょうぶ
2025/05/10(土) 22:48:31.18ID:K3qP9/A2
誰がその多様性とかについていくのか？
お前が低レベルな現場と呼ぶ環境だろう？
368デフォルトの名無しさん
垢版 |
2025/05/10(土) 23:29:16.41ID:tNjV2wjQ
フロントにRustを使ってる「高レベル」なプロダクトって何があるの？
バックエンドなら分かるけど
その基準なら世の中のビジネス的に成功してるサービスの殆どが低レベルでしょ
2025/05/11(日) 00:02:17.99ID:1LIDIycD
>>364-365
関数の内側にunsafe書くだけ？
それだと見た目はsafeだけど内部はunsafeだから実質的にunsafeではないか？
2025/05/11(日) 00:43:43.27ID:qcGHvz/x
子供が使うバリアの高度版
2025/05/11(日) 00:48:37.35ID:kSJwinQr
内部で使う関数がunsafeである理由を理解して未定義動作の可能性を排除できてないなら
外側の関数にもunsafeをつける約束
372デフォルトの名無しさん
垢版 |
2025/05/11(日) 00:49:47.08ID:/xxB2yrb
unsafeは「危険」というよりも「コンパイラが安全性をチェックできない」ブロックだと思う
内部的に unsafe を使ってても、ラップした型や関数を外から使う分には安全とみなせるなら問題ない

理想的には
・内部的にunsafeを使っているけど、外から見れば安全 -> unsafe を外して良い
・内部的に unsafe を使っており、かつその関数は利用者が適切にコードを書かないと危険 -> その関数も unsafe とマークするべき

標準ライブラリやきちんとしたライブラリは基本的にこの法則に従ってる
問題はユーザーのコードで、書こうと思えば「問題はあるけど unsafe とマークされてない関数」は作れてしまう
そこは自己責任の問題

けど、セグフォみたいなバグが実際に起きた場合に、直接の原因となるコードは unsafe ブロックの中に絞れる (ことが多い) から、それでもかなりマシだと思う
C++だとコード全体が unsafe ブロックの中にあるようなものなので…
2025/05/11(日) 00:50:52.82ID:10YJ6Wg3
>>365
Undefinedの有無もなにも標準化されてないからなぁ
2025/05/11(日) 00:52:29.93ID:qcGHvz/x
バリア！バリアしたから大丈夫！
2025/05/11(日) 01:02:20.84ID:kSJwinQr
未完成らしいけど目安
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
2025/05/11(日) 01:18:27.03ID:OAc7wOSx
unsafe ＝ Rustコンパイラが安全性を保証してくれない ＝ プログラマが自分の責任で安全性を保証しなければならない ＝ C/C++と同じ状態

逆に言えば、safeつまりunsafeではない、とは、Rustコンパイラが安全性を保証できる状況にしないといけない
未定義動作がないことが根幹にある
だから未定義動作とは何か、どういう時に起きるのか、どうすれば無くせるのか、が最重要
それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない
2025/05/11(日) 01:20:41.47ID:Vd6Ddgx+
unsafe functionは使いどころが微妙だね
unsafe指定の理由が不明だし基準も開発者次第でまちまち
C#みたいにunsafeにはコンテキストとしての役割しか持たせない方が一貫性がある
呼び出し元に注意させたいんならunsafe_hogeみたいなネーミングルールで十分だった
2025/05/11(日) 01:31:46.55ID:kSJwinQr
バリアより感染症対策で流行ったゾーニングのイメージだな
感染リスクのあるunsafeゾーンと安全なsafeゾーンがあって
unsafeからsafeに持ち込むときは消毒（検査）が必須みたいな感じ

運用が雑になって事故るのも同じ
379デフォルトの名無しさん
垢版 |
2025/05/11(日) 01:36:40.21ID:/xxB2yrb
>>376
> それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない
それをやると、一つの関数を unsafe にした時点でそれが呼び出し元に波及して、プログラム全体に unsafe が広がらない？
深刻なバグがコード内のどこで起こってるかを特定したい場面だと、 unsafeは本当に unsafe な操作をしてる箇所に限定されてた方が探しやすいと思う
2025/05/11(日) 01:47:17.60ID:OAc7wOSx
>>377
呼び出し元に注意を持たせるものではない
unsafeブロック(関数)内はRustコンパイラが安全性を保証しない
それ以外の部分はRustコンパイラが安全性を保証してくれる
C/C++はプログラム全体がunsafeブロック内にある状況と同じと説明できる

>>379
そうだよ
理解するまではunsafeを使ったらunsafeな関数しか作れない
safeな関数にしてよいかどうかの判断が一番大事なところ
勝手に判断してsafeにしたらプログラム全体に問題が波及しかねない
まずは理解してからunsafeに手を出しましょうということ
2025/05/11(日) 02:07:37.23ID:OAc7wOSx
「unsafe利用箇所をunsafeブロックで囲えば終わり」は、よくある勘違い
まず一次的には「それを含む関数もunsafe fnにしなければならない」が正解
その上で「内部でunsafeを使ったことで生じる問題が、その関数単独でまたはモジュール全体で閉じ込めることができているかを判断できてから、ようやくunsafe fnをfnにできる」が正解
2025/05/11(日) 06:19:57.03ID:Skl5F9WB
unsafeな理由をブロック外部で処理すりゃsafeに出来るじゃん
たとえばなraw pointer参照が危険だとして渡す前にスタックまたはヒープ内の正しいアドレスであることを確認して引数を渡すとかの、外部でのチェック(unsafeに至る条件の排除)すれば無毒化できるわけで

そんなんC言語だって変わらんやん。Cで汎用的な関数書いたらほぼほぼポインターだらけになるし、ポインターのチェックせずに使うなんてことは危険すぎてありえんのと一緒やん

C言語にrustコンパイラーのunsafeの枠組みだけ組み込んでsafeじゃなきゃエラーにしますにしたら、コードの5割ぐらいはunsafeになってそうやけどな。標準ライブラリーからしていくらでも危険なアクセスできるし
2025/05/11(日) 07:03:44.41ID:Ix0M85KV
>>382
Rustでプログラミングしたことない人には理解できないのは仕方ないが的外れ
そのCで手動でチェックをして使うようなことは
Rustではunsafeを使わずとも普通に書くことができて自動的にチェックしてくれて安全かつ楽

むしろRustでunsafeを使う頻出パターンの一つは真逆
その自動チェックを無くすためにunsafeが使われる
例えばあるアルゴリズムで既に自動チェックされて既に安全なものがアルゴリズムの都合で二重に自動チェックされてしまいコンパイルでの最適化でも消えないとする
その2回目の自動チェックを無くすためにunsafeを使う
もしそのアルゴリズムが1つの関数で完了するならばその関数外に影響はないため
関数内部でunsafeを使っていても関数自体は外向けにsafeにすることができる
そのアルゴリズムで2回目の自動チェック省略が常に正しく安全なことはプログラマが安全性を保証することになる
これがunsafeを用いて極限まで速くしつつ安全な関数を生み出すRustの典型的なパターン
2025/05/11(日) 08:49:42.45ID:tAEYEseM
https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
これが全て
unsafe function に関しては、長文複おじが主張するほどunsafeを含む関数に対して積極的に指定すべきものではなく、
むしろ極力safeとしてラップすることを推奨するトーンで書かれているように感じる
「unsafe functionは呼び出し元に注意させるためのマーク」という解釈は適切であり、常識的に考えて中でunsafe使ってようと呼び方によって未定義動作が生じるような関数はそもそも作るべきではない
2025/05/11(日) 09:06:54.66ID:qcGHvz/x
unsafe指定の理由が不明って斬新な視点だと思うけどね
他の言語でunsafe使ってるから意味は理解出来る
2025/05/11(日) 09:11:42.89ID:1l4O+k/P
>>384
逆だぞ
未定義動作が発生しうるパーツがunsafe関数
そのパーツを上手く使ったり組み合わせたりして未定義動作を発生させなくしたものがsafe関数
2025/05/11(日) 09:15:33.06ID:qcGHvz/x
変わった人が集まって3行で済んでいた話を広げていく
2025/05/11(日) 10:06:07.52ID:WmmDZjaJ
>>368
無いから自演してまでしてRustを盛り上げようしてる
2025/05/11(日) 10:11:53.93ID:kgU6ATNU
ここスレが立って1週間で300レスかよ
さすが究極のプログラミング言語だけあるな
関心持つ人多すぎ
2025/05/11(日) 11:15:42.58ID:UTf8BgbA
>>369
その理屈だとRustで描かれたコードはすべてunsafeだ
391デフォルトの名無しさん
垢版 |
2025/05/11(日) 11:22:17.69ID:u8yQJoO0
>>389
何なんだよこの気持ち悪い複オジのレスはw
2025/05/11(日) 11:30:45.60ID:UTf8BgbA
>>383
borrow mut な部分を unsafe {} で囲むとコンパイル通せるんだっけ？
2025/05/11(日) 11:38:18.14ID:B7Jyctor
>>392
unsafeであろうとRustの参照ルールは変わらない
ナマポ受給は可能
2025/05/11(日) 11:38:36.95ID:qcGHvz/x
unsafeで囲むとその中で危険な必殺技が使える
強力だけどその間はリミッター解除され保護されていない状況にも近い諸刃の剣
それを呼び出す部位もunsafe扱いしたらmainまでunsafeになり危険極まりないｗ
2025/05/11(日) 11:48:02.09ID:2w2LR5Qj
やってることはC言語でコメントにunsafeって書くのと変わらねえじゃん
2025/05/11(日) 11:53:03.94ID:qcGHvz/x
違いが判らないなら理解力が不足しているだろう
unsafeだと通常は許されないことが可能になる
2025/05/11(日) 12:00:44.68ID:B7Jyctor
>>395
全く異なる
Rustではunsafe部分のみ人間が安全性を保証する義務がある
それ以外はRustの言語仕様により自動的に安全性が保証される
一般プログラマはunsafeを使う必要がない
2025/05/11(日) 12:19:58.74ID:2w2LR5Qj
>>396
俺が言ってる意味がわからない方が理解力が不足してるかもよｗ
2025/05/11(日) 12:37:43.07ID:qcGHvz/x
>>398
unsafeじゃない部分を無視してそれを言うのは意味がないこと
typescriptで書かれたコードがjsに変換されてそれに型が残っていないと言うのと似たような主張
2025/05/11(日) 12:41:23.78ID:qcGHvz/x
他の言語でもunsafe以外では保護されている部分もunsafeで制約が解除されている
2025/05/11(日) 13:01:06.68ID:bksu5Opa
>>369
unsafeな関数には関数を呼び出す側が守るべきsafetyルールがそれぞれ定義されている
ラッパー関数がそのルールを関数内のみで不変的に守ることが保証できるのならsafe
できないなら上位で保証してもらう必要があるからunsafe

いずれにしてもunsafe関数を呼び出す側が守るべきsafetyルールは
アプリケーションのどこかの段階ではすべて守られることを保証しないといけない
2025/05/11(日) 13:53:51.61ID:UTf8BgbA
>>396
その理屈だと二重の borrow mut も unsafe{} で許可してもらえるととってもありがたいんだが
2025/05/11(日) 14:09:26.63ID:ARIO0JMx
>>402
unsafeの使用は安全性を守るためだけに使われるのだ
安全を脅かすためにunsafeを用いてはならないのだ
2025/05/11(日) 14:48:00.02ID:0bg/IfOK
>>396
unsafeブロック内でも外でもRustのルールは基本的に同じ
何でも出来るようになるわけではない

unsafeブロック内でのみ出来ること
・unsafeな関数やメソッドの呼び出し
・unsafeなトレイトの実装
・生ポインタの逆参照
・共有体フィールドの読み取り
・可変静的変数の読み書き
このたった5つのみが許可される
2025/05/11(日) 16:26:32.64ID:qcGHvz/x
文意を取れない病気なのだろうか？
2025/05/11(日) 17:38:39.22ID:9sJVUicm
まあ病気だろうね
2025/05/11(日) 20:01:04.55ID:8gkdAC4l
unsafeってそんなに不味いんですね...
2025/05/11(日) 20:20:01.31ID:LzpU3Ybb
特殊な環境を抜きにすると普通の開発でunsafeが使われることはほとんどない
むしろコンセンサス無くunsafeを使う人がいたら問題児認定されても仕方ない
ボトルネックがあってunsafeを使うことで安全かつ劇的に改善されるなどの共通認識が出来たら注意深くみんなの監視の下で使われる
2025/05/11(日) 20:23:01.43ID:8gkdAC4l
特殊な環境って...具体的にどういうのがあるんですかね...
2025/05/11(日) 21:10:41.96ID:kSJwinQr
安全に使うための条件が分からないunsafeは不味い
標準ライブラリのunsafe関数は大体Safetyで明示してる
2025/05/11(日) 23:58:19.36ID:UbETPlY9
>>378
メモリに対するバリアはunsafeを必要とせずにsafe Rustで使える
モデルはC++と同じでstd::sync::atomic::AcquireとReleaseでバリアを構成する
412デフォルトの名無しさん
垢版 |
2025/05/12(月) 11:03:30.61ID:zCv6/zTu
OS提供のヘッダーファイルと連携しないといけないからね
rustだってOSのAPIとして使われるようになったら今の形のままでは済まされないはず
2025/05/12(月) 11:09:27.48ID:pU5GgKWj
その頃にはもう人間がAPIを管理することはないだろうから我々が気にする必要はない
2025/05/12(月) 11:22:05.12ID:0DBz50aj
atomicを使える局面なら最速を狙えるが
素人は無難にMutexにしとけ
2025/05/12(月) 11:51:31.03ID:pU5GgKWj
処理が性能上クリティカルじゃないことが分かってる上で手を抜くのはいいけど、必要に応じてロックフリーを実装できないレベルならさすがに言語の選択から考え直すべき
場合によっちゃゲロ遅スクリプト言語でロックフリーに書かれたコードより遅くなるぞ
2025/05/12(月) 11:55:41.87ID:iYjqcrbw
誰もメモリバリアの話なんかしてないだろストローオジ
417デフォルトの名無しさん
垢版 |
2025/05/12(月) 11:57:36.67ID:zCv6/zTu
>>415
その通り
2025/05/12(月) 12:21:58.09ID:0DBz50aj
>>415
ロックフリーにできるならatomicを使う方が当然よい
しかし素人がABA問題からRISCのアクセス順序崩壊まで様々な問題を理解しつつ
compare_exchange系などを正しく使いながら各々のRelaxed/Release/Acquired/SeqCstを最善に選べると思えない
複数のatomicが複雑に絡むとロックフリーはプロでも間違える歴史を繰り返してきた分野だ
さらに言えばatomicよりMutexが有利になるケースの存在も理解して適切に選ぶ必要がある
プロでも単純明快な状況でない場合はまずMutexで実装して後から見極めた上でatomicにするかどうか決める
これらの知識を身に付けるまで素人は無難にMutexにしとけ
2025/05/12(月) 15:44:13.42ID:zCv6/zTu
unsafeについて
https://www.youtube.com/watch?v=lx86iUb2xiI
2025/05/12(月) 22:25:38.81ID:/cK4qYsj
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=18df19416bd6d705356724788636ab13
これをResultのmapとかand_thenとかを使ってスッキリ書く方法ってないでしょうか？
421デフォルトの名無しさん
垢版 |
2025/05/13(火) 00:03:38.80ID:tnscGN8Z
>>420
let z = x.or(y).or(Err("ko"));

？
2025/05/13(火) 00:12:19.92ID:8MDWNT4X
>>421
x=Some(false), y=Some(true)のときz=Some(false)になるからダメじゃね？
2025/05/13(火) 00:18:54.30ID:8MDWNT4X
すまんOptionとResult勘違いしてた
424デフォルトの名無しさん
垢版 |
2025/05/13(火) 00:29:45.70ID:tnscGN8Z
>>422
たし🦀

let z = x.and_then(|b1| y.map(|b2| b1 || b2).or(Ok(b1))).or_else(|_| y.or(Err("ko")));

直したらこんなんなったんだが
matchが一番わかりやすい気がする
2025/05/13(火) 00:30:51.37ID:hUpkj0hB
x.map(|x| y.map_or(x, |y| x || y)).or(y).or(Err("ko"))とかになるからmatch以上にスッキリ書く方法はないんじゃないかな
2025/05/13(火) 00:46:34.37ID:8MDWNT4X
一応x,yが増えた時のためにイテレータ使うパターン
let z = [x, y].into_iter().filter_map(Result::ok).reduce(|b1, b2| b1 || b2).ok_or("ko");

２つならmatchでいい気がする
2025/05/13(火) 07:26:56.06ID:Ubv8VExT
たくさんある時はOk(true)でショートカットしたいケースが多そう
例えば素直に

let mut is_ok = false;
while let Some(x) = iter.next() {
　match x {
　　Ok(true) => return x,
　　Ok(_) => is_ok = true,
　　_ => (),
　}
}
is_ok.then_some(false).ok_or("ko")
428デフォルトの名無しさん
垢版 |
2025/05/13(火) 07:31:54.57ID:RE8LmKUD
幻聴で半分人間半分AIと話していたので
1 私に成りすまして話しているようにいさせている
2 成りすましの声でも身体攻撃の部分は私本人も同じ状態に陥っている
3 犯人が使用していたとしても清廉潔白の人物のように見せれる

【2025年最新】自然な声の音声読み上げソフト5選！AI技術で ...
https://ondoku3.com/ja/post/natural-voice-software/
※インストール不要で無料で５０００文字まで複数声質の音声合成エンジンで読み上げ可能

ローカルで各種AIモデルを実行できる無料ソフト「llama.cpp」がマルチモーダル入力をサポートし画像の説明などが可能に
2025年05月12日 20時00分
https://gigazine.net/news/20250512-llama-cpp--multimodal-vision-support/
>>llama.cppの詳細情報は以下のリンク先で公開されており、ソースコードやインストール手順などを確認できます。
※画像を認識させてテキスト入力が可能

ローカルでAIを動かして「コード生成」「ウェブ上の情報収集」「ファイル検索」などの操作を実行できるAIエージェント「AgenticSeek」、無料で使えてプライバシーも守れるのが強み
2025年05月05日 16時02分
https://gigazine.net/news/20250505-agenticseek-local-ai-agent
>>AgenticSeekのインストール手順は以下のページにまとまっています。
※複数サイトからレポート作成可能
2025/05/13(火) 10:17:11.92ID:C/NhftFY
>>422-423
このようにRustは面倒
2025/05/13(火) 10:29:55.43ID:Oaa+uu3G
>>429
その点ではRustが最も優れています
2025/05/13(火) 11:06:20.16ID:C/NhftFY
優れてるなら間違わないように設計汁
2025/05/13(火) 11:13:08.18ID:Oaa+uu3G
>>431
Rustは強い静的型付け言語なので間違えることはありません
2025/05/13(火) 12:48:35.47ID:HDWw9il3
>>429
わかるわ
ResultやOptionはわりと継ぎはぎだらけでasyncでの使い勝手もあってコアな開発者でもコンビネータよりもmatch推奨する人が増えてる
2025/05/13(火) 14:00:36.56ID:EnWQFSGx
>>433
継ぎはぎはない
根本の理解を間違えているからそんな変な発想になる

基本はmatchで書くのが当然
例えば
match foo {
　Some(x) => Some(f(x)),
　None => None,
}
こう書いた時に意味するところはSome時にfによる写像
だからこれをfoo.map(f)と略記できるというのが根本
短く記述でき可読性も上がる

asyncでの使い勝手というのも同様
このfの形とクロージャでのキャプチャなどの制限を満たせば使えて満たさなければ使えないだけの話
matchを推奨しているのではなくmatchが基本
そのうえで可読性がよくなるメソッドが適用できるならそれを使う
メソッドチェーンもそれで短く可読性が上がるなら使う
>>420はmatchのままが可読性がいい
それだけの話
2025/05/13(火) 14:18:16.15ID:C/NhftFY
だからRustは清書用(キリっ)って言われるんだろうね
2025/05/13(火) 14:28:55.14ID:EnWQFSGx
>>435
そんな話は聞いたことない
今回の話との関連すら不明
2025/05/13(火) 16:46:51.79ID:JaffXz8x
>>434
またバカおじの意味のない長文
アンチRust活動は他所でやれ
2025/05/13(火) 18:59:19.16ID:XAG2WzZA
>>433
確かに最初の頃に比べると
イテレーター&コンビネーターの使用頻度がやや下がって
代わりにループ&マッチの使用頻度が上がったな

冗長でダサく感じるけど汎用性が高まる場合が多い
2025/05/13(火) 19:20:56.54ID:GUUfpWjP
早期脱出はループで書くほうがわかりやすいものやループでしか実現できないことも多い
特にラベル指定など
2025/05/13(火) 19:50:54.91ID:r+Qycp2R
実際どうなるかなんてその時次第だから

今回は結果をまとめて出してるんだろうけど
それぞれの実行結果で制御が加われば別に結果をまとめる必要はない場合もでて来るので綺麗に書ける必要はゼロ
2025/05/13(火) 19:51:24.47ID:QxvoeLWz
>>420
ちょっと主旨から外れるけど、matchは
match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
(Ok(_), _ ) => x,
_ => y,
};
まで整理できますね。
2回評価するのが嫌なら二段matchがいいかと。
2025/05/13(火) 19:57:18.96ID:r+Qycp2R
綺麗だねｗ
2025/05/13(火) 20:06:13.63ID:QaPl6AoM
実際にはOk/Err得られた時点で既に実行済みだからその後の工夫は効果薄くて
>>427のような早期脱出になるかな
next()呼び出しで実行されるとして
2025/05/13(火) 20:08:00.80ID:r+Qycp2R
関数の実行結果x,yがあります
それぞれのx,yが成功していればそれを出力してください
ただしｘ,y共に成功であれば結果を論理和して出力してください
x,y共にエラーである場合はエラーを出力してください
2025/05/13(火) 20:15:06.96ID:hmzDHhd1
結果が揃っていたら悩むところないよな
現実には結果が一部しか出ていない段階で欲しい結果が得られたから以降は打ち切り、または、エラーが出たから打ち切り
2025/05/13(火) 20:46:34.57ID:QxvoeLWz
二段matchも書いてみた。
let z = match x {
Err(_) => y,
Ok(false) => match y {
Err(_) => x,
_=>y,
},
_ => x,
};
普通はこんな書き方しないだろうけど。
447デフォルトの名無しさん
垢版 |
2025/05/13(火) 21:23:14.88ID:tnscGN8Z
まあしかし
元の

let z = match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
(Ok(b1), Err(_)) => Ok(b1),
(Err(_), Ok(b2)) => Ok(b2),
(Err(_), Err(_)) => Err("ko"),
};

これが一番可読性高くて網羅性も一目でわかっていいと思うわ
2025/05/13(火) 21:30:58.39ID:upONs1LW
結局のところは意図が表れていて読み取りやすいことが重要で、スマートに書けてても見た他人がなんのこっちゃとなるようではあかんからな。
2025/05/13(火) 22:06:17.20ID:QxvoeLWz
>>446
蛇足だけど、こっちの方がいいか。
let z = match x {
Err(_) => y,
Ok(true) => x,
_ => match y {
Err(_) => x,
_=>y,
},

};
2025/05/13(火) 22:11:12.56ID:r+Qycp2R
他の言語でもあるんだけど元々シンプルに書けていたものを
その言語特有の機能で書き換えたい勢がいる

パズルとしては別に構わないけどそれでどれだけ時間を費やすのか考えてなさそう
2025/05/13(火) 22:17:38.03ID:tYuP2+yw
>>441
さすが汚コーダーと呼ばれるだけはあるな
2025/05/14(水) 00:10:10.91ID:DnF/2YAd
汚コーダーと言いたい気持ちもわかる
俺たちの時代は変数名は一文字で可能ならワンライナーで処理が終わるように工夫しまくってた。2行だったのが1行79文字に収まったぞ！的な
この美的感覚を共有できる仲間がいてくれて幸せである
2025/05/14(水) 00:21:08.28ID:mNhYSwgp
両方Okの場合だけx.or(y)と違う動作をさせたいと考えるならそう書けばいいと思う
match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
_ => x.or(y),
}

入力が増える場合は上の処理を関数にしたものをループ内で呼ぶ
forループとか使っとけばショートサーキットも簡単

あと本当にErrを捨ててもいいんであればResult<bool, &str>じゃなくて
Option<bool>を受け取って返す形にしておいたほうが扱いも楽だしスッキリする
2025/05/14(水) 00:32:45.62ID:mNhYSwgp
>>426のはOption<bool>化して最終的にNoneならErr(“ko”)にfallbackさせてるから
読みやすいかどうかは別にして考え方としてはわりと好み
2025/05/14(水) 00:34:10.14ID:JvBAAG1/
結局>>427でええやん
456デフォルトの名無しさん
垢版 |
2025/05/14(水) 13:32:41.36ID:tetNkY+Z
AIチャットボットに「偽の記憶」を植え付けることで仮想通貨を盗む攻撃が報告される
2025年05月14日 12時00分
https://gigazine.net/news/20250514-web3-ai-agents-with-fake-memories/
>>プリンストン大学の研究チーム

過去に流通した誤情報に接触した人の半分が「正しい情報」と思っていて25％が何らかの手段で拡散している
2025年05月14日 11時25分
https://gigazine.net/news/20250514-fake-news/
>>総務省
2025/05/14(水) 16:29:27.92ID:plMg3hee
「Firefox」の開発リポジトリが「GitHub」に移行
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2013958.html
https://github.com/mozilla-firefox/firefox
JavaScript 28.5%
C++ 28.1%
HTML 22.0%
C 10.5%
Python 2.9%
Kotlin 2.5%
Other 5.5%
458デフォルトの名無しさん
垢版 |
2025/05/14(水) 17:34:57.56ID:Ga6mti+e
5次方程式に新公式を発見：ルートを超える新理論
2025.05.14 17:05:56 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/177496
>>オーストラリアのニューサウスウェールズ大学（UNSW）で行われた研究
プログらまーも覚えるとよい

125年越しに解決したかもしれない「ヒルベルトの第6問題」とは？
2025年05月10日 15時00分
https://gigazine.net/news/20250510-hilberts-6th-problem-solved/
2025/05/14(水) 19:02:58.62ID:mIHvW3MM
Mercurialが積極的にRust化を進めていたのは少なからずFirefoxの影響があったと思うが
酷い梯子外しで草
2025/05/14(水) 19:23:03.41ID:+nUwZiWy
Mercurial は開発履歴管理で Git はパッチの連鎖管理という理念の違いがある。
それって結局は同じことじゃないのか……と思うんだけどやっぱり違うんだよな。
概念的に整理されていて理解しやすいのは Mercurual だけど、実務的に必要なのは Git。
ツールがどんな言語で書かれているとかはあまり関係なく、大規模開発だと Git のほうがやり易いというとても簡単な話。
2025/05/14(水) 20:24:41.62ID:u4PNt/Ez
Rust用のJITコンパイラ・インタプリタ的なものはありませんか？
PythonやJavaScriptのようにコンパイル時間を待たずにデバッグしたいんです。
462デフォルトの名無しさん
垢版 |
2025/05/14(水) 20:46:01.38ID:Msome2l0
RustもGo言語のように、消えてゆく運命ですか？
2025/05/14(水) 20:52:07.16ID:W1FBX8Fx
>>461
371 デフォルトの名無しさん sage 2025/05/14(水) 20:25:52.45 ID:u4PNt/Ez
TypeScriptを(C++等のように機械語に)コンパイルする方法が知りたいです(´・ω・)
2025/05/14(水) 20:55:34.77ID:FZDf1LBL
>>462
C++標準委員会がRustを参考にしたコーダー用Safe C++（C++呼び出し専用の限定版）を作ればC++に回帰する可能性があるけど、そんな動きは無いから当面安泰じゃない？
2025/05/14(水) 21:44:29.60ID:iGtYlO1p
コンパイラから全ソースコードが見えていて好きなだけ時間を使ってチェックさせるのか
商用を含め様々な出所のコンパイル済みバイナリでもリンク(静的、動的)して動かすのか
役割と責務が違う
2025/05/14(水) 23:43:28.56ID:1UsCEMhi
>>457
FirefoxはメインがC+のまま変わっていない
Rust化した部分はレポジトリが別
2025/05/15(木) 10:01:15.43ID:6KG6JIoe
>>460
それはよくある勘違いで、Gitのコミットはパッチではなくスナップショット
常に完全なスナップショットを持っているためにコミット間の差分の導出は極めて容易であり、
あたかもGitが差分ベースであるかのような使い勝手のコマンド体系を実現することに成功している
その結果>>460のような誤解も多い
2025/05/15(木) 10:04:11.94ID:IIQRq9O2
>>467
それは実装上の話で、ここではパラダイムの話をしてる。
2025/05/15(木) 10:47:00.15ID:HgN+lgjm
>>468
それ信頼できる出典ある？
仮にGitのコミットが(実装はさておきメンタルモデル上は)パッチだとしたら、rebaseやcherry-pickで新しいコミットが作られるのは変だと思わないのかな
2025/05/15(木) 11:20:07.09ID:0AOGTML/
Claude 3.7 with extended thinking 様によると

Gitはスナップショットベースのシステムで、各コミットはファイルシステム全体の完全なスナップショットを保存します（最適化されていますが）。一方、Mercurialは変更セット（changeset）という概念で差分ベースの履歴を管理します。

この根本的な違いがGitの操作モデルに影響しています。rebaseやcherry-pickが新しいコミットを作成するのは、Gitがスナップショットモデルを採用しているからこそ自然です。既存のスナップショットを新しい文脈に適用すると、新しい状態のスナップショットが必要になります。

パラダイムと実装は密接に関連しており、Gitの設計思想はLinus Torvaldsが述べているように内部データモデルから生まれています。このモデルがGitの分散性、ブランチ操作の柔軟性、大規模プロジェクトでの優位性につながっています。​​​​​​​​​​​​​​​​
471デフォルトの名無しさん
垢版 |
2025/05/15(木) 11:24:57.24ID:2L2gZoQV
>>447-448
記述量多いけど観る分には判り易い
2025/05/15(木) 11:31:00.68ID:2L2gZoQV
>>465
>コンパイラから全ソースコードが見えていて好きなだけ時間を使って

Cargo の build 遅いしディスクの容量も喰いまくる(消せるけど)
そこまでやるなら他人(自分のであっても別cratesのとき)のstruct/traitを組み合わせて追加しても良い仕様にして欲しいな
2025/05/15(木) 12:17:35.74ID:hNZNm9rA
>>472
Orphan Ruleが破れるのは致命的
第三者に勝手に実装されてしまう
これは必須ルール
2025/05/15(木) 12:44:18.74ID:IIQRq9O2
Rust の型システムの原型になった Haskell では Orphan Rule のような制限はないから技術的には制限しない選択も可能ではあるはずだけど
通常は避けるべきと考えられているし、警告も出るし、コンパイル時間にもかなり悪影響だし、良いことは少ない。

必須というほどではないかもしれないけど、あまりにも割に合わないとは言える。
475デフォルトの名無しさん
垢版 |
2025/05/15(木) 13:12:18.94ID:bGH4TqSk
Googleが開発した進化的AI「AlphaEvolve」は未知のアルゴリズムや未解決数学問題の新解法を発見可能、すでにGoogle内部ではAI開発やチップ設計の効率化に活用されている
2025年05月15日 11時06分
https://gigazine.net/news/20250515-google-ai-algorithm-alphaevolve/
2025/05/15(木) 13:17:27.73ID:hNZNm9rA
>>474
例えば第三者のクレートを利用した時
そこで標準ライブラリの型に対して標準では実装されていない標準ライブラリのトレイトの実装があっても通ってしまう
これは誤動作につながるからOrphan Ruleは必須かと
標準ライブラリ以外の型に対しても同様で第三者に実装権限を与えるのは禁じる必要がある
2025/05/15(木) 13:55:31.05ID:IIQRq9O2
>>476
それは攻撃やミスに対する脆弱性を封じるという意味で制約が必須と言ってる？
こっちは (技術的な) 実現可能性という意味で必須な制約ではない (があえて制約を無くすことのデメリットが大きい) と言ってるので主旨が異なる。
2025/05/15(木) 14:15:21.28ID:hNZNm9rA
>>477
Orphan Ruleなしでも脆弱性を封じることができるならば技術的な実現可能性があると言えるかもしれない
そうでないならばOrphan Ruleは必須
2025/05/15(木) 14:33:19.68ID:7KgPq9qv
グローバルに適用させようとしたらそりゃ問題が起きるわ
拡張をスコープにいれる場合はモジュール内にuseステートメント書けばいいだけ
2025/05/15(木) 14:47:58.27ID:O0mRpeHb
C#で言う拡張メソッドをやりたいのに、Orphan Ruleが邪魔をする
次のeditionでは廃止してほしいね
2025/05/15(木) 14:53:04.88ID:2JrqWc4h
脆弱性とか全然関係ないよな
2025/05/15(木) 14:54:41.56ID:DscPOsCc
>>479
それは違うよ
それは自分で拡張用トレイトを作って、自作以外を含めた任意の型に対して実装して使う時に、自分で範囲を限定する時の話だね。
そうではなく、普通に必要のためuseしている標準やクレートのトレイトが、勝手に第三者によって実装されてしまうことを防ぐのがOrphanルール
2025/05/15(木) 14:57:48.33ID:DscPOsCc
>>480
Rustでは、自由に拡張メソッド用のトレイトを自作して、既存の型に実装して自由にメソッド拡張できます。
Orphanルールは邪魔しません。
2025/05/15(木) 15:04:23.65ID:DscPOsCc
>>481
もしOrphanルールがないと、トレイトの作成者でも型の作成者でもない第三者によって、勝手に型にトレイトが実装されてしまうため、その実装によっては脆弱性が生じる可能性があります。
2025/05/15(木) 15:35:40.67ID:d3l5/VMs
>>484
トレイトの実装は可視性の指定をバイパスできないし、そもそも可視性はセキュリティのための機構ではない
その気になりゃ本来不可視なメンバにアクセスすることなんて普通に可能だし、
もしクレートの作者に悪意があって、利用者が不用意にバージョン上げる阿呆なら、サプライチェーン攻撃によってマルウェアを仕込むことなど造作もない
2025/05/15(木) 15:59:53.54ID:DscPOsCc
>>485
そんな悪意のある話はしていません。
第三者が公の型に公のトレイトを実装できてしまうと、その第三者にとっては意図通りの必要なことが実現できたとしても、他者にとっては必ずしもそうではないためその差異が穴になりうるという話です。
2025/05/15(木) 16:01:34.05ID:cOWHhYVA
>>480
既存の構造体に新しいメソッドを生やしたいだけならextension traitで可
既存traitに新しいメソッドを生やしたいならextension trait + blanket implで実質同じことが可
拡張メソッド1つじゃなくtraitと実装の最低2つを定義しないといけないがそんなに気になるほどではない

Swiftの拡張メソッドのように既存インターフェースに後から適合させるのはRustでは無理
2025/05/15(木) 16:08:57.33ID:cOWHhYVA
>>486
だからそれはグローバルに適用した場合の話でしょ
そりゃ問題起きる
2025/05/15(木) 16:19:46.85ID:DscPOsCc
>>488
理解できてないのかな？
例えば標準ライブラリのトレイトに話を限ったとしても、自分で使いたいからuseしたり、preludeで自動的にuseされたりするよね。
そのトレイトが標準ライブラリでは実装されてない型に対して、第三者が実装できてしまうことを防ぐのがOrphanルール。
標準ライブラリではない一般クレートに話を拡張しても同じ。
490デフォルトの名無しさん
垢版 |
2025/05/15(木) 16:39:03.48ID:kvgG4b4S
既存の構造体に既存のtraitを
2025/05/15(木) 16:52:22.68ID:clVHgL7i
barクレートとbazクレートがどっちもfooクレートに依存してて
それぞれで個別にimpl FooTrait for FooTypeを定義してたら
barクレートとbazクレートを両方使うときに衝突して困る
2025/05/15(木) 17:01:11.21ID:6KG6JIoe
>>489
それは型定義ともトレイト定義とも異なるクレートでのトレイト実装という現状禁止されている行為が仮に許可された場合、
コンパイルパスに入ってさえいれば暗黙的に実装がインポートされる仕様になる、とあなたが勝手に想定しているからでしょ
もし対応するなら、実装を含むモジュールを明示的にuseさせるような仕様になるだろうし、
そういった面倒を避けるためにorphan ruleがある、と考えることもできる
2025/05/15(木) 18:02:56.74ID:njVhCRvT
例えばu32型にその値を半分にするメソッドhalf()を生やしたいとしたら自作トレイトHalfを用意してu32に実装してやればメソッド拡張できて
そのトレイトHalfをuseすれば第三者もその恩恵に授かってhalf()メソッドを使えるわけだけど

仮にOrphan ruleがない世界だと
u32型には実装されていないstd::ops::Negトレイトも誰でも実装できてしまう
先ほどのhalf()メソッドはuse dareka::Halfした時のみ使えるから自己責任で済んだけど
今回は別目的でuse std::ops::Negしてる人にもu32型にneg()が生えてしまう
本来はu32型の変数xに対して-xはコンパイルエラーとなるけど
今回はneg()が使えて-xがコンパイル通ってしまう
しかも実装の内容によってはその-xの挙動が不明だ
2025/05/15(木) 19:36:05.04ID:IIQRq9O2
ポケモン協会は秘密にしてるけど、たぶんポケモン世界にはイジメ属性みたいなのもあって仲間ポケモンを自殺に追い込んだりしてると思う。
それとか孕ませポケモンがトレーナーをレイプしたりだとか、逆にトレーナーがポケモンと獣姦 (?) したりだとかいう醜聞もいっぱいあるに違いない。
ポケモン協会はそういうのを隠さずに公開すべき。
2025/05/15(木) 19:37:43.21ID:IIQRq9O2
ごめんなさい。
誤爆しました。
496デフォルトの名無しさん
垢版 |
2025/05/15(木) 20:29:13.48ID:QWJDxUqA
俺だってシャワーズとセックスしたいよ
2025/05/15(木) 22:09:10.96ID:p2LOH2jU
それはもはやトランスアニマルじゃねーの
いくら翻訳がグダグダだからってそこまで人間性失うのはいかがなものかと
2025/05/15(木) 22:20:07.26ID:HPgmxOUZ
>>457,466
ほかの言語と同じように外部ライブラリ/crateを除外してある今回の数字が正しそうね
2025/05/15(木) 23:29:18.99ID:7W7zR2tR
>>493
Orphanルールの説明で第三者による実装同士がぶつかりエラーを引き起こすためという話を見かけるけど
ぶつからなくても単独でもそういう支障があるんだよな
2025/05/16(金) 06:25:07.48ID:QL8B1Lzv
悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/
2025/05/16(金) 07:42:42.67ID:GIaLLXqf
>>500
詳細を見るとこれはRustとLLVMの改善に大きく寄与しそうだな
(1) Rustコードの問題
(2) Rustコンパイラの問題
(3) RustコンパイラからLLVMへの問題
(4) LLVMの問題
これらは密接に関係していて(1)を完璧にしていても
(4)の問題から逆連鎖して(1)で対応するためのコード調整をしなければいけないようだ
本件をきっかけに様々な改善が期待できるので世界全体に役立つだろう
2025/05/16(金) 07:44:33.05ID:GIaLLXqf
LLVMを用いている様々な言語にも恩恵ありそうだ

＞ 驚くべきことに、Clang 18 でビルドされたバージョンは、Clang 17 でビルドされたバージョンよりもパフォーマンスが劣ることがわかりました (~3% 遅い)。
＞ このリグレッションの原因は不明ですが、Clang全体で一貫性があり、対応するLLVMバックエンドを使用していることがわかりました。
2025/05/16(金) 08:19:21.12ID:ZrWbXhSM
Rust は将来的に LLVM をやめる計画じゃなかったっけ？
うろ覚えなので勘違いかもしれんけど。
2025/05/16(金) 08:21:41.68ID:QL8B1Lzv
>>503
GCC Rustは継続的にやってるみたいだけど、別にLLVMはやめないでしょ
2025/05/16(金) 08:42:23.59ID:QL8B1Lzv
今日公開のRust 1.87.0でio::pipeが追加された
今までなかったことが不思議
2025/05/16(金) 09:10:56.72ID:b2vWvm61
>>500
対象国に対して賞金が安すぎる
しかもRust処理系の方に手を入れた場合はアプリケーションの改善をした人と山分けになる可能性が高いし、
一般的な有効性を証明してRust処理系にマージされないといけないというのはハードルが高すぎる
残念ながら複おじが期待するような結果になる可能性は低いと言わざるを得ない
2025/05/16(金) 09:12:43.25ID:r8NIoUWT
>>505
Stdio::piped()が10年前からある
無名パイプはOS依存かつプロセス間だから汎用化は安定化に時間がかかったのかな
2025/05/16(金) 09:41:55.75ID:7mIpVS9r
>>500,506
フルで$20,000でも米国の1人月かぁ、しかも成功報酬だから最適化を舐め腐ってるけど
Rustに入れ込んでる一定数はひと山当てたい連中だから売名プロモーションとして参加するだろうね
2025/05/16(金) 11:10:05.92ID:wXSLcdK+
リンク先見たら初っ端からsafe rustを諦めているから
何の為のプロジェクトか意味不明になりかけている
2025/05/16(金) 11:35:21.65ID:1BoI6QFj
>>509
unsafeからsafeを創り出す新たな安全パターンを見つけたら、それを使うのは問題ない
その部分だけ徹底的に人の手で安全管理して、それ以外の安全をRustコンパイラに任せることができる
それらのうち特に汎用パターンを集めたものが標準ライブラリという視点もある
2025/05/16(金) 11:41:45.02ID:OoDj1+RH
今になって気が付いたじゃなくて、言語仕様で例外を投げられないから無視してただけでは
> We noticed that the existence of panicking code significantly increased stack usage. Similarly to how panicking/formatting code prevented crucial inlining in bounds checking code until moved out of the function, panicking code also increased stack usage and spills.

>>510
タラレバがでかい
2025/05/16(金) 11:42:09.71ID:ZrWbXhSM
>>509
標準ライブラリの内部でも unsafe はたくさん使われてるぞ。
unsafe をどう「閉じ込める」かが Rust プログラムの構成の肝心な部分だ。
速度チューニングのために閉じ込めきれなかったのなら失敗と言えるが unsafe がただちに悪いわけではない。
2025/05/16(金) 11:48:07.99ID:OoDj1+RH
panic(エラー処理)を関数内に収めるからregisterが足りなくなり易くなるからspillさせるためにスタック多めにして、コードサイズも大きくなるのは最初から分かってたでしょうよ
2025/05/16(金) 12:31:41.93ID:IgvVjYfn
unsafeは禁止なのにpanic!はOKって何考えて設計してんの
2025/05/16(金) 12:37:23.64ID:b58fLBSS
速度にシビアなコードを書く時は関数にpanic呼び出しが残っていたら当然負け
まずはpanicを生じさせないイテレータなどで書き
インデックスアクセスを避けられない時は様々な工夫とヒントをコンパイラに与えて境界チェックを回避
それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め
他の言語なら全体の安全保証を捨てるか遅さを我慢するかの二択
2025/05/16(金) 12:56:20.34ID:O+6qQae6
一番初歩的なゼロ除算はchecked_divがidiomaticだけど、
ttps://stackoverflow.com/questions/66602948/is-there-a-way-to-catch-division-by-zero-errors-without-checking-in-advance

実際に0除算を実行してハードウェア例外を発生させるコードの例(回避できない部分と仮定)として、
> それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め
>>515の言うこれをゼロ除算で具体化するとどうなるの？
2025/05/16(金) 13:18:06.79ID:b58fLBSS
>>516
除数をstd::num::NonZero型にするとpanicコードは入らない
2025/05/16(金) 13:42:02.34ID:QUtZlH+M
>>517
病気かな
2025/05/16(金) 13:49:45.88ID:b58fLBSS
>>518
実際にかつてそれで対応したことがありアセンブリコードも確認している
2025/05/16(金) 13:54:06.57ID:wj8lYFI5
>>519
要求されてるのは>>515「それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め」™の具体例だからサッと出せば良い
2025/05/16(金) 14:18:57.81ID:b58fLBSS
>>520
safeなstd::num::NonZero使用で対応できているためunsafeの必要がない
2025/05/16(金) 15:05:55.72ID:L+lmGGRS
>>521
御託はもういいからお前はsafe縛りでAV1デコーダを書き直してCと同等の速度を達成してこい
2025/05/16(金) 15:14:15.36ID:b58fLBSS
>>522
金と暇を用意してくれたらな
それから最高速を求める時にsafe縛りの必要はない
unsafeを安全に閉じ込められる枠組みが見つかればそれを実行してきたのがRustの歴史
その恩恵で皆がsafe Rustでパフォーマンスを出すことができる
2025/05/16(金) 15:24:17.43ID:9BgWdn33
なんかよくわかんねーけどCより5%遅いらしいな
2025/05/16(金) 15:38:32.38ID:QL8B1Lzv
デコーダーの主要部分はC版の頃からアセンブラで書かれてて、Rustはグルーコードに過ぎないみたい
2025/05/16(金) 15:41:24.82ID:JWOdogbt
えぇ・・・
2025/05/16(金) 16:18:41.85ID:m6piKA++
pub const fn checked_div(self, rhs: Self) -> Option<Self> {
if intrinsics::unlikely(rhs == 0 || ((self == Self::MIN) && (rhs == -1))) {
None
} else {
// SAFETY: div by zero and by INT_MIN have been checked above
Some(unsafe { intrinsics::unchecked_div(self, rhs) })
}
}

NonZero使ったら最適化で分岐が消える場合があるってことだろうけど
チェックタイミングがNonZero化するときに移動しただけだよね
もしくは定数由来だからチェックが不要になったか
2025/05/16(金) 19:03:43.29ID:b58fLBSS
>>527
checkなくコストゼロでpanicもなく安全にu64 / NonZero<u64>の除算やNonZero<u64>→u64の変換などができる
ゼロ保証のない変数からNonZeroを作るには必ずチェックコストがかかるが以降は除数として何度使ってもコストゼロ

元が穴のないCコードならどこかで何らかの方法でゼロにならないことを保証しているはず
それに準拠する形を取ることができればCとRustは同じコストで同じ速さになる
もし元のCコードにゼロ保証する仕組みが全く見当たらないならばそれは穴のあるコードが見つかったことになる
2025/05/16(金) 19:13:36.61ID:bpgu73R/
>>528
病気だな。

要求されてる「それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め」™の具体例を上げやすいように、
「それでも回避できない部分」を簡潔に作り出すのが手間なら、ループ最深部の(0かも知れない)除算を想定した上で「unsafe安全閉じ込め」™をサッと挙げたらどうですか？
と言う話のはずなのに、この受け答え。
2025/05/16(金) 19:16:32.12ID:b58fLBSS
>>529
unsafe使わずにsafe Rustで実現できている
何のためにunsafeを使えと言ってるのか理解できない
2025/05/16(金) 19:17:47.42ID:bpgu73R/
>>528
> それに準拠する形を取ることができればCとRustは同じコストで同じ速さになる

こんな単純化を信じているのが大勢いて、信者の一人>>500記事が現実を突きつけられているのに
>>528はまだ受け入れられない。
2025/05/16(金) 19:19:01.24ID:bpgu73R/
>>530
対象国居住者とタッグ組んで参加してください。
2025/05/16(金) 19:23:03.68ID:bpgu73R/
>>525
> Rustはグルーコードに過ぎないみたい

グルーコードに過ぎないのに、最大限努力した結果で5%も性能差が出ている事実がインパクトある。
2025/05/16(金) 19:29:28.60ID:b58fLBSS
>>531
何を解決してほしいのか具体的に言おう
panicもcheckも必要なく安全にsafe Rustで実現する方法は既に使えた
2025/05/16(金) 19:33:14.79ID:CtDSSAzz
当然ながら元々はボトルネックを特定した上で部分的にアセンブラで書いているのだろうし、
当時のスキルをもってすれば今5%も差が出ているならまずは原因箇所の特定くらいは簡単にできそうなもんだが、
なぜこんな解像度の低い状態で丸投げしているのか謎
オリジナルの開発をやった人がいなくなっちゃったのかもね
もはやRust関係ないけど
2025/05/16(金) 19:35:12.11ID:b58fLBSS
>>531
何を解決してほしいのか具体的に言おう
panicもcheckも必要なく安全にsafe Rustで割り算を実現する方法は既に伝えた
2025/05/16(金) 19:39:18.59ID:zQbADFxC
ここでは全部一人のせいにしているけど
だぶん「unsafe安全閉じ込め」™オジwと複オジは別人で
都合悪なると仮病になる

>>535
懸賞記事内にリンク記事があるよ

>>534,536
たぶん「unsafe安全閉じ込め」™が何のことか具体的に知りたいだけでは
仮病してると複オジと同レベルだぞw
2025/05/16(金) 19:45:26.73ID:b58fLBSS
>>537
「unsafe安全閉じ込め」の例はRust標準ライブラリに無数にあるからそれを知りたいとは思わなかった
興味ある部分についての標準ライブラリのソースを読んでくださいでおしまい
2025/05/16(金) 19:48:17.71ID:zQbADFxC
いつもの人間が判断するだけの事に名前を付けたのね
2025/05/16(金) 19:49:07.71ID:zQbADFxC
そうなると複オジ本人だなw
2025/05/16(金) 20:03:38.49ID:CtDSSAzz
>>537
一通り読んだけど、c2rustのunsafeコードを修正する際に適用することにしている、一般的に高速化に寄与すると考えられる作法を紹介しているだけで、
実行時のパフォーマンスについての詳細な分析結果は特に見つけられなかった
プロジェクトの概要なんかも見てると金貰って開発する上で結構厳しくQCD管理されてるみたいだから、
どうしても自分達で解決できないというよりは単に切羽詰まってるから助けてくれという感じなのかね
2025/05/16(金) 20:14:28.07ID:zQbADFxC
複オジは仮病だろうけど、最近の話題でこんな画像があった

統合失調症のブログが話題に「全てがわかる。すべてのすべて」
https://pbs.twimg.com/media/Gpy43ktaYAYMz9w.jpg
2025/05/16(金) 23:32:05.70ID:V5h5/o2J
>>513
この種の速さ命のプログラミングではpanicコードを完全に排除するためその問題は起きない
2025/05/16(金) 23:35:06.70ID:ZEBLDPGc
テックポエム量産してるのは>>542に近いのでは
論理的には違っていると自覚はあるから「ポエム」と称するけど
異常脳神経が「分かった」シグナルを発して仕方がないのだろう
2025/05/16(金) 23:48:27.11ID:+TOH8huo
このGoスレレスなんて>>542のイチゴの例そのものね

> Goはルーン文字と同じ運命をたどりそうだな
> 紙が普及した時代に原始的な彫刻文字は流行らない
> 時代に合わせて形を変えないと
2025/05/17(土) 02:16:37.18ID:hnIBgbwS
>>545
頭おかしいのはみんな気づいてるからいいとして、せめてコテにしてNGさせてくれよな
延々中身のない仕様も理解していないレスバを目にするのも辛いしな
よりに寄ってこんな過疎スレに来なくていいのに
547デフォルトの名無しさん
垢版 |
2025/05/17(土) 07:06:56.82ID:XtHNXmhB
科学 ＋ 5ch

20種近くも検出された新しい「量子状態」は、量子コンピューター飛躍の鍵になるか [すらいむ★]
2025/05/16(金) 22:52:02.48
http://egg.5ch.net/test/read.cgi/scienceplus/1747403522/
>>これまで理論上の存在と考えられてきた量子状態の検出に、国際研究チームが初めて成功した。量子情報の保存や論理演算の基盤として応用することで、量子コンピューターの未来を変える鍵となるかもしれない。


※犯罪の手口が判明するのか
2025/05/17(土) 07:42:04.23ID:lDt9R68w
>延々中身のない仕様も理解していないレスバ

潰し屋だな
2025/05/17(土) 08:40:26.34ID:qCs3WkDL
全能感があるだけ幸せなのでは？自分は真逆で老化がはじまったんかと思うぐらい
2025/05/17(土) 10:25:49.04ID:+mXvyyg4
糖質というより発達系だろ
間違いを認めたら負けみたいな中華メンタルも持ち合わせてるけどあれは病気じゃなくて人間性の問題
2025/05/17(土) 10:34:31.56ID:9HrlEF5X
キチガイの自白で荒らされてますが
Rust 1.0からちょうど10周年ですよ
おめでとう！
2025/05/17(土) 10:41:03.44ID:qCs3WkDL
Rustのすべてが正しいという発想しかない異常者
2025/05/17(土) 10:49:42.53ID:BnclY/n2
複オジ今日も快調に暴走
2025/05/17(土) 15:50:10.71ID:P2bp1h/d
複ちゃん消したらもうこのスレの存在意義ないけど
2025/05/17(土) 18:34:13.65ID:Vu4+Tz9e
AI吹くちゃん二代目襲名
2025/05/17(土) 19:44:04.18ID:t/yU0oIF
1.87で安定化したVec::extract_ifの機能がdrainに近いと思ったけど最初はdrain_filterの名前で提案されてたのね
自動で全部dropできないからdrain_filterとかdrain_ifだとだめらしい
drainが排出じゃなく吸収のイメージなのはFFが原因だな
2025/05/17(土) 22:10:30.09ID:pKwTZqOi
extract_if()はむしろretain()＋捨てる分を取り出し(extract)と考えた方がいい
ただし残すをtrueか取り出すをtrueかで判定関数の真偽が逆に注意
ついでに判定関数の引数が&vec[i]から&mut vec[i]に変わってるため残すものも値書き換え可のおまけ付き
2025/05/17(土) 22:46:26.94ID:t/yU0oIF
返されたイテレータを使い切らないと全部削除されないからretainとも微妙に違う
nextで取った分だけ削除だからpeekableとの取り合わせが悪そう

あと関数名はextract_ifじゃなくextractだけでよかった気がする
extractがないのにextract_ifがあるのは何かバランス悪い
drain_filterから紆余曲折あったみたいだから仕方ないけど
2025/05/17(土) 23:12:09.74ID:pKwTZqOi
>>558
書いた通り、retain()＋捨てる分を取り出し(extract)
だから取り出さないと削除されない
イテレータが進んだ分だけretainと一致する

名前の_ifはすぐに類似のpop_ifが想起される
pop_ifでも条件判定の引数が可変参照で同じだからrangeをlastにしたものと見なすことができる
ifの付かないpopは無条件だから
ifの付かないextractも無条件となる
だからextract_ifというメソッド名が正解で一貫している
2025/05/18(日) 00:31:27.80ID:+SIFIDid
すでにドレンフィルタって名称の一般的なものがあるけど…
排水管などのフィルター
2025/05/18(日) 00:55:22.32ID:+SIFIDid
coffee extractionはコーヒー豆の方を取り除いているのか液体(エキス?)を抽出しているのか
562デフォルトの名無しさん
垢版 |
2025/05/18(日) 01:05:08.64ID:GL3oFIgT
extract は語源的には ex (外へ) - tract (引っ張る) だから、「取り出す・抽出する」といった意味合いが強い
2025/05/18(日) 01:06:15.76ID:+SIFIDid
コーヒー豆とコーヒーが混ざった物からコーヒーを抽出するよね
それをコーヒーを捨てているとは言わない

残ってる方は最後まで濾さないとコーヒー豆とコーヒーが混ざった物でしかないので無価値
一方で抽出したほうはコーヒーなので価値がある
この意味が判るかどうか？
564デフォルトの名無しさん
垢版 |
2025/05/18(日) 07:46:36.17ID:AGGexLjT
企業献金、結論先送りへ　自公国法案、提出取りやめ [蚤の市★]
2025/05/17(土) 21:17:14.36
https://asahi.5ch.net/test/read.cgi/newsplus/1747484234/

全国1万1155の企業・団体の政治献金「97％」が自民へ、シンクタンク調査 [おっさん友の会★]
2025/05/14(水) 11:12:39.51
https://asahi.5ch.net/test/read.cgi/newsplus/1747188759/
2025/05/18(日) 09:41:45.81ID:6WAEpSNG
Vecに含まれる構造体を参照しながら、別の構造体に変更を加える処理ってどれがベストでしょうか
566デフォルトの名無しさん
垢版 |
2025/05/18(日) 10:17:55.24ID:rfn3+MVd
これは任意の方苦に向けて電波攻撃可能ということでしょうか？
プログラムの改造で下記が可能になるのでしょうか

「Xperia」が電波法違反、ソニーに行政指導--総務省
2024年12月13日 15時23分
https://japan.cnet.com/article/35227306/
>>スマートフォンにおいて「工事設計認証を受けた工事設計にない空中線を使用しての電波発射が可能な仕様となっている状態にあった事実が認められた」という。
2025/05/18(日) 11:19:10.16ID:HgIqS8Uk
>>565
色々方法があってどれがベストかは状況による

a. 変更内容を作成する処理と変更を適用する処理を分離する
b. split_mut系で更新部分と参照部分のスライスに分割する
c. takeとかreplaceで変更対象の構造体を一旦Vecから取り外す
d. Vec内の構造体を全部RefCellに入れる

可能ならaがベストかな
2025/05/18(日) 11:30:08.35ID:vhS9Z2b5
よくそんな意味不明な質問に答えられるなと思う
自分がアホなのか、予定された質問に予定された答えなのかわからない
本当にわからない
2025/05/18(日) 11:41:01.25ID:6WAEpSNG
>>567
かなり曖昧な質問に答えてくれてありがとう。
他の言語だとリストから参照で構造体を取り出して、他の構造体を変更したり色々できたけどRustだとかなり制限がキツくて躓いた。ChatGPTにも聞いたりだけどイマイチ納得できなくて、実際使ってる皆さんに聞きたくなったんだよね。
2025/05/18(日) 11:44:13.33ID:vhS9Z2b5
ChatGPTに聞いたなら質問を清書してくれただろ？
そっちを貼ればいいだろ？
謎すぎる
2025/05/18(日) 11:45:25.47ID:wGoLP5Sv
意味不明な質問というのには完全に同意
質問と回答が矛盾してるので
さすがにこれは発達オジの自作自演ではないだろう
2025/05/18(日) 11:47:57.87ID:wGoLP5Sv
あ・・・
自分の中では矛盾してなかったみたいww

自作自演発達オジの日本語能力の問題だったか
2025/05/18(日) 11:48:09.03ID:6WAEpSNG
やりたいことは、構造体には関数も実装ししていて、その関数に大元のVecを渡してそれぞれの要素に変更をかけるみたいなやつだけど、ミニマムで質問してみた。一旦教えてもらったcに近い実装でコンパイル通ったけど、モヤモヤしたので聞いてみました。
2025/05/18(日) 11:48:46.66ID:6WAEpSNG
>>570
確かに、、、すまぬ
575デフォルトの名無しさん
垢版 |
2025/05/18(日) 11:52:57.81ID:GL3oFIgT
「別の構造体」というのは「同じVecの別の位置にある要素」という意味？
values[0] を参照しながら values[1] を変更するみたいな
2025/05/18(日) 11:57:42.82ID:zQyjSV37
>>565
一般的にそういう時は困っていることが成立している最小構成例を具体的に出す
何通りにも解釈できる意味不明な曖昧な文章では答えてくれる人も減るだろう

>>568
意味不明な文章だがRustのプログラミング経験があるならば
質問者の脳内の仮定を補完して最も可能性の高い質問ケースとして回答者が応じている状況を観察できるはずだ
2025/05/18(日) 11:58:51.15ID:vhS9Z2b5
書き方が回りくどいね　わかりやすく
2025/05/18(日) 12:05:59.38ID:6WAEpSNG
>>575
そうです、言葉足らずでした。。。
579デフォルトの名無しさん
垢版 |
2025/05/18(日) 12:21:21.33ID:GL3oFIgT
>>578
それはRustだと面倒なパターンなので仕方ない
{} でブロックを作って借用のスコープを短くする等でなんとかする
ここはボローチェッカーの気持ちの理解が必要
(なぜダメなのかはエラーメッセージが教えてくれてるから、そこは既に分かってるかもしれないけど)

同じことは構造体の別のフィールドを参照する場合も言える
構造体のフィールドaを可変借用しつつ別のフィールドbを参照するなど
2025/05/18(日) 12:26:55.54ID:vhS9Z2b5
う～ん
　何が言いたいかわからる人にはわかるだろ？
2025/05/18(日) 12:29:43.83ID:NJShdjf5
何がやりたいのか全然わからん。
コードで示してよ。
コンパイル通らなくてもいいから Rust 風擬似コードって感じで。
2025/05/18(日) 12:54:12.76ID:uzz3fg67
複おじちゃんは今日もやらかしてるね
特有の癖が出てるのに自分ではバレてないと思ってるから面白い
2025/05/18(日) 13:00:12.37ID:zQyjSV37
困ったことが起きたらその問題が再現する最低限の最小構成コードを書いてみる
すると本質的な構造が見えてくる
その過程で自己解決することも多いだろう
わからなくてもその最小構成コードを貼って質問すればよい
2025/05/18(日) 13:58:46.67ID:6WAEpSNG
>>579
やはりそうなんですね。ありがとうございます。

>>581
>>583
助言ありがとうございます。
ChatGPTにサンプルコード作ってもらいました。コンパイルは通らないですが、やりたいイメージはこんな感じです。

struct Unit {
id: usize,
hp: i32,
}
impl Unit {
fn act(&mut self, all_units: &mut Vec<Unit>) {
// 自分以外のユニットに攻撃したい
for unit in all_units.iter_mut() {
if unit.id != self.id {
unit.hp -= 10;
}
}
}
}
fn main() {
let mut units = vec![
Unit { id: 0, hp: 100 },
Unit { id: 1, hp: 80 },
Unit { id: 2, hp: 60 },
];
for unit in units.iter_mut() {
unit.act(&mut units); // ❌ コンパイルエラーになるが、やりたいことはこんな感じ
}
}
2025/05/18(日) 14:03:53.58ID:UzOJGd+R
>>584
これも追加

// 自分以外のユニットに攻撃したい
↓
// 自分以外のユニットから奪い取る

if unit.id != self.id {
unit.hp -= 10;
self.hp += 10;
}
2025/05/18(日) 14:16:39.01ID:UG4F7Ocv
自作自演スレ
587デフォルトの名無しさん
垢版 |
2025/05/18(日) 16:37:58.98ID:GL3oFIgT
>>585
こんなのでどうだろう
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=871e0b5209dab043741c765000be6e5a

他言語からすると面倒に感じるかも
「要素 i への可変参照を持ちつつ、Vec全体への可変参照を持つ」のは借用チェッカーに引っかかるパターン
if unit.id != self.id の判定が必要なように「all_unitsの中にunitがいるかもしれない」という状況をそもそも借用チェッカーは防ぎたいので

なので、 split_at_mut() を使って参照範囲を ([i] への可変参照, 他の要素への可変参照) に分けてみた

他には Cell (内部可変性) を使うパターンもあるけど、このケースでこれを使うのはちょっと微妙な気がする
588デフォルトの名無しさん
垢版 |
2025/05/18(日) 16:40:13.34ID:GL3oFIgT
>「all_unitsの中にunitがいるかもしれない」という状況
訂正:「all_unitsの中に自身がいるかもしれない」という状況
2025/05/18(日) 16:59:42.16ID:tbHjRPms
あんまりアドホックな対応で頑張ってもまた同様の問題でいちいち詰むよ
エンティティなんだから素直に内部可変性を使っておいた方が無難
僅かに遅くはなるだろうが、メモリアクセス効率まで気にするならECSパターンでも覚えた方がいい
2025/05/18(日) 17:43:23.59ID:HgIqS8Uk
スライスを(init, mid, tail): (&[T], &T, &[T])に分割するsplit_midがほしいな
何かで似たような戻り値の型を見た記憶があるけど
2025/05/18(日) 18:24:32.38ID:UkfPMCWK
1つだけ外したい場合はOption+mem::take/replace使うのが自然だと思う
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a84a532ace40d2bb6603510ca1307756
2025/05/18(日) 19:24:49.27ID:HgIqS8Uk
590だけど1.86で追加されたget_disjoint_mutが使えるかもしれない
少し癖があるけどsplitの代替になるかな

fn main() {
let mut v = vec![1, 2, 3, 4, 5];
let len = v.len();

for i in 0..len {
let Ok([init, [mid], tail]) = v.get_disjoint_mut([0..i, i..i + 1, i + 1..len]) else {
panic!();
};
*mid *= 2;
println!("{init:?} {mid} {tail:?}");
}
}
2025/05/18(日) 21:02:54.43ID:tnDwO9ym
>>584-585程度でこんなんか
安全パターンをプリミティブに単体分離しようと頑張るのは無駄なんだな
結局は要素還元できなくて逆に組み合わせ爆発しそう
2025/05/18(日) 21:12:32.00ID:6WAEpSNG
>>587
>>591-592
ありがとうございます！大変ためになります。
可変借用ルールの影響を受けないように分離するのが良いのですね。

>>585
私はこの方ではないが、これはこれで知りたかったので、それも解決出来る書き方にもなってるので助かります。

>>589
確かに複雑になってくるとまた沼りそうな気はしますね、内部可変性というのも調べてみます。
2025/05/18(日) 21:37:30.85ID:GL3oFIgT
借用チェッカの気持ちとしては、同じオブジェクトへの可変参照が複数ある状態を防ごうとするんだよね

fn act(&mut self, others: &mut [Unit]) { }

の中で、 self を操作しただけで others に影響が出たり、 others への操作が self に影響したりするというのは
潜在的なバグの原因になり得る (読み手にとって意図せぬ動作になり得る) から、そうならないことをコンパイル時に保証しようとする

なので >>587 では、act に渡された時点で self と others は確実に違うものだと分かるコードにすることで、借用チェックの条件をクリアしている

内部可変性は逆に、コンパイル時はいったん不変参照ということにしておいて、実行時に可変借用として取り出すための型
これは「同じオブジェクトへの可変参照は同時に一つまで」というルールを、借用チェッカーではなく自己責任で行うという考え
(「可変参照は同時に一つまで」というルールは変わらないし、実行時にこれを検査する動作になるので、若干のオーバーヘッドはある)

個人的には >>589 も納得できる考えで、エンティティ (idで同一性を検査するオブジェクト) ならそれでいいよねとも思う

Async が絡むと Mutex という別の型 (これも内部可変性と関係する) が出てくるけど、これはまた別のトピックになるので割愛
2025/05/18(日) 22:38:23.16ID:vhS9Z2b5
なにかへまったら話題変更のために自演を始めるんかな？
と思ってしまう

いつも大体そんな流れだし急にポップしてくるこのスレの話題は理論寄りが多いのも変な感じする
2025/05/18(日) 22:57:08.60ID:wIHSiY7i
>>592
使えるけど今回のような用途だと分けた後に前後を足してから処理するところがちょっと重く感じる
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9d999080fc4b58f68252699e3ba79edf
2025/05/18(日) 23:29:42.52ID:HgIqS8Uk
>>597
left.iter_mut().chain(right)
はflatten使って
[left, right].into_iter().flatten()
にすれば多少は軽い感じになるかな
処理的には変わらないと思うけど
2025/05/19(月) 10:12:45.15ID:NvwVFQDL
レスパオジはGoスレに引っ越したらしい
2025/05/19(月) 10:30:17.58ID:NvwVFQDL
>>596
私も同じ匂いを感じます
2025/05/19(月) 10:33:51.23ID:ushmtLpU
>>596
だよなあ
2025/05/19(月) 10:55:55.29ID:8M8piIAN
言語が変わっても複オジは変わらんな
自分勝手な間違った解釈を正しいと思い込む病気なのか
間違ってるとわかってもマウントを取り続けないと自我が崩壊する病気なのか
2025/05/19(月) 11:52:44.35ID:Xa4RMtJ3
>>602
前者が発達トレイトで
後者が糖質トレイトだね
2025/05/19(月) 12:49:02.69ID:3mHCp29v
Rustといえどもある程度大きな規模のプロジェクトになってくると、スマポの使用が増えてきてJava/C#/C++あたりとの差異が縮まってくる印象はある
人間の認知能力の限界なんだろうけど、AIによってボローチェッカーが積極的に大域的に活用されるようになったら、人間がついていくのがだんだん厳しくなりそう
2025/05/19(月) 16:44:14.27ID:BXqI3NP/
Rustで100万行クラスの規模のコード書いたからって別に破綻せんよ
依存関係整理して注意して使わないといけないのは規模に関係ない
2025/05/19(月) 17:30:52.93ID:fVYXsIor
>>605
C/C++からコンパイルされたマシンコードが一切入らないやつってPascal/Delphiは一定数あるけど
100% Rust 製ので100万行規模のソフトなんて何がある？
2025/05/19(月) 19:00:04.76ID:MIwIfdvI
Rust標準ライブラリがcore+alloc+stdで現在34万行
クレイトだと例えばtokioが12万行
2025/05/19(月) 19:20:41.87ID:IV1y8O7J
rust-lang/rustのrsファイルだとsrc/（ツール系）が91万行でcompiler/（内部ライブラリ）が69万行
rustcとかrustdocとか混在してて多分同じライブラリ共有してるから個々の正確な数字は出せないね
2025/05/19(月) 19:34:29.26ID:2NJk+oE9
新設のmozilla-firefox/firefox内はFF固有コードだとして
>>466の外部crateで実質FF固有なものだけ集めると実は大したこと無いのでは
610デフォルトの名無しさん
垢版 |
2025/05/19(月) 20:02:00.34ID:pY+vVO2I
100万行はたとえだろ
何の言語でも100万行になると設計を極限まで綺麗にしないと地獄だわ
2025/05/19(月) 20:11:56.59ID:l+7bKGMu
>>604
> ある程度大きな規模のプロジェクトになってくると、スマポの使用が増えてきて

コンパイラやCLIツールなど比較的短時間でプロセス終了するプログラムなら
life timeを'staticにして逃げる場合があるけど
pure Rust GUIアプリでメモリー使用量を考慮したアプリだとスマポの使用が多そうね
2025/05/19(月) 22:29:21.37ID:UKNF/IJC
なんか怪しいので自分でも計測してみた

rust/library/core+alloc+stdは18.6万
tokioは8.4万
rust/srcは81.6万
rust/compilerは57.1万

.mdファイルの行数やドキュメントコメント行・ブランク行・コメント行とか水増ししずぎじゃない？
2025/05/19(月) 22:41:19.70ID:UKNF/IJC
>>605
これには完全に同意

1万行でも100万行でも個々のコードの複雑さが変わるわけじゃない
どちらもも数十行〜数百行のモジュールの寄せ集め
2025/05/19(月) 22:52:59.01ID:afGGDVx/
C/C++製のソフトウェアたちがプログラマのうっかり見逃しミスによるセキュリティホールなどのレポートが常に絶えない原因はその規模と関連がある
かなり小規模なものを除いて人間の手でチェックしている限り一定のミスが入り込む
コンパイラが全体の安全性を保証してくれるRustは規模が大きくなっても有利だろう
2025/05/20(火) 00:32:14.76ID:ChvDIWk1
普通に規模が大きくなれば一般的に設計と実装の複雑度は変わるよ
どのアプリでも言語でも変わらない
rustはメモリ関連のバグが起こりにくいだけ
616デフォルトの名無しさん
垢版 |
2025/05/20(火) 05:04:51.52ID:bvf2nVKI
>>614
Rustを使えばプログラマのうっかり見逃しミスが100%無くなるんだね
RustのコンパイラってAIみたいだね
617デフォルトの名無しさん
垢版 |
2025/05/20(火) 06:00:38.75ID:cDXA4bE/
「Xperia」が電波法違反、ソニーに行政指導--総務省
2024年12月13日 15時23分
https://japan.cnet.com/article/35227306/
>>スマートフォンにおいて「工事設計認証を受けた工事設計にない空中線を使用しての電波発射が可能な仕様となっている状態にあった事実が認められた」という。
※全携帯とスマートフォンのプログラム改造で人の場所に照射可能になる？
※場合にもよりますがAIと併用して個人を追跡しているのなら24時間商社可能
6Gの候補であるテラヘルツ帯の電波を脳の神経細胞に照射すると細胞が異常な成長を遂げたことが明らかに
2022/08/15
https://gigazine.net/news/20220815-terahertz-radiation-boosts-brain-cell/
携帯電話の使用で「精子の数が減少」の可能性、スイスの研究者が指摘
2023/11/27
https://forbesjapan.com/articles/detail/67083
携帯電話の電磁波が神経や細胞の損傷を引き起こすと主張するロバート・F・ケネディ・ジュニア保健福祉長官が学校での携帯電話の規制を称賛
2025年03月25日 06時00分
https://gigazine.net/news/20250325-rfkjr-kids-cell-phone-schools/
>>ケネディ・ジュニア氏は子どもが携帯電話を使用することについて独自の視点から語り、携帯電話やソーシャルメディアの利用と、うつ病、学業成績の悪さ、薬物乱用との関連性について言及。その中で、「携帯電話は電磁波を発し、一日中携帯電話を身近に置いていると子どもたちの神経にダメージを与え、細胞損傷やがんを引き起こすことが示されている」と指摘しました。
設立 1998年
テクノロジー犯罪の撲滅
Https://media.toriaez.jp/s2972/32686.pdf
P77-身体・運動機能が遠隔から操作される P78-五感が遠隔から操作される
上記が本当だった場合統合失調症操作
統合失調症のう動きがわかるエリアの人はそれを体験中
平衡感覚は別のふらつき缶
視覚感覚なら別の何かを見ている
聴覚感覚なら別の何かの声を聴いている
味覚なら別の味を感じている
触覚なら別の感触を感じている
温覚冷覚なら別の温冷覚感じている
このようになるのですよ
618デフォルトの名無しさん
垢版 |
2025/05/20(火) 08:02:42.80ID:9y393mCm
幻聴で悪用していると話していました

オープンソースでアニメ動画を自動生成できるAIツール「AniSora」を中国・bilibiliの開発チームが発表
2025年05月19日 19時00分
https://gigazine.net/news/20250519-anisora/
1枚の画像からアニメーションを作成するAIツール「AniSora」を発表しました。

Microsoft CopilotがついにGPT-4oの画像生成をサポート
掲載日  2025/05/19 18:56
https://news.mynavi.jp/techplus/article/20250519-3327017/
Microsoftの公式Xアカウントによる投稿では、2025年5月16日に「4o Image Generationがついにリリースされました」というコメントと共に、Copilotで次のことができるようになったと伝えている。
• 正確で読みやすいテキストをレンダリングする
• 作成したものを編集する
• 複雑な指示に従う
• 既存の画像のスタイルを変換する
• フォトリアリスティックな画像を作成する
同アカウントは、実際にテキストによる指示で画像を微調整していく様子も投稿している。
2025/05/20(火) 09:44:44.40ID:iko9UpUR
>>457,466
設計さえしっかり出来ていればどんなに低く見積もっても5~10万行/人年は固い

車輪の再発明(移行プロジェクト)はすごい勢いでコード量が増えていくはずなんだけどね...
2025/05/20(火) 10:54:31.93ID:XnKVhLuZ
車輪の再発明は再発明であって作り直しのことじゃないよ。
「丸くしたらめっちゃ速く移動できることを発見したぞ！」って今の世の中で言うやつがいたらアホじゃん (そこらにいくらでもあるものが見えてないから) ということを説明してるのが車輪の再発明という言い回し。

「俺も車輪を作れるようになったぞ」とか「別の素材で車輪を作ってみた」みたいなのは再発明ではない。
2025/05/20(火) 11:19:42.09ID:S2V0Z25J
FirefoxのRust化は本体よりServoあたりを見とけばいいんじゃね？
実用化の目途が立ったら乗り換えるでしょ
ブラウザエンジンはCSSもスクリプトも動画再生も全部面倒見るから１から作るのは大変そう
2025/05/20(火) 11:21:03.24ID:70z+Wgsn
>>466
そのレポを挙げてよ
別のところに100万行ある、見たいな思わせは良くないよ
2025/05/20(火) 11:34:05.86ID:70z+Wgsn
>>620
関係ないけど、「別の素材で車輪を作ってみた」は発明じゃね？
2025/05/20(火) 11:36:15.63ID:sS1iaU5A
>>622
Firefoxにそんなに興味があるくせにプロジェクト名すら知らないとは異常だな
見上げてごらん
2025/05/20(火) 12:25:37.28ID:LU0N+B9o
servoの努力を馬鹿にはしないけど
experimentalよりもアリバイ作りに見える位なので
servoの成果を当てにするのはどうかと思う
2025/05/20(火) 12:30:48.46ID:18JQhe8j
servoは、tauriで使うために開発再開したんじゃなかったっけ？
その後チェックしてないけど
2025/05/20(火) 12:35:54.41ID:uYNL9fZG
車輪の再発明/servoの話で想起されたけど時々、高校生がピタゴラスの定理の新証明を発見的なニュースがある
高校生だから良いけど素人オジだったら大分印象変わる
2025/05/20(火) 12:43:24.47ID:uYNL9fZG
>>620,623
>「別の素材で車輪を作ってみた」

特許は取れるだろう
2025/05/20(火) 12:46:23.55ID:ZQMuhpil
というかfirefoxのリポジトリを取ってきて*.rsの行数数えるだけで400万行超えるんだが…
2025/05/20(火) 13:28:39.47ID:bKts0GWq
>>629
言う奴いると思ってたら...

tokei -C -t=Rust -e third_party
Language Files Lines Code Comments Blanks
Rust 1193 416629 348374 23629 44626

コンパイラ入ってら
tokei -C -t=Rust third_party/rust
Language Files Lines Code Comments Blanks
Rust 10915 3845860 3397959 148316 299585
2025/05/20(火) 13:31:22.64ID:pdWnkKc/
>>623
発明だが車輪を発明したわけではない。
2025/05/20(火) 13:32:11.96ID:bKts0GWq
コンパイラ本体の実数は>>612
2025/05/20(火) 13:35:06.85ID:bKts0GWq
>>631
面白いね

起源:
紀元前3500年頃、メソポタミア文明（現在のイラク地域）のシュメール人によって車輪が発明されたとされています。
初期の車輪:
固い木材を丸く削り出しただけの単純な構造で、主に陶器の製作や物資の運搬に使用されていた。
発明者:
車輪の発明者として特定の人物が特定されているわけではなく、シュメール文明における技術革新の成果として捉えられています。
2025/05/20(火) 13:35:22.56ID:EJYGGfjm
>>630
third_party/rustの中身をちゃんと見ろ
依存ライブラリであってコンパイラは入ってない
2025/05/20(火) 13:38:36.14ID:bKts0GWq
なるへそ
でも趣旨は同じです
2025/05/20(火) 13:41:23.89ID:bKts0GWq
散らかったのでまとめ直すと
>>629
> というかfirefoxのリポジトリを取ってきて*.rsの行数数えるだけで400万行超えるんだが…
は間違いで、正味35万行
2025/05/20(火) 13:47:44.39ID:S2V0Z25J
third_partyのソースも保持してるなら言語の比率は参考にならんな
2025/05/20(火) 13:55:44.85ID:bKts0GWq
>>637
githubが賢くてgit-submoduleになってないけど除外しているっぽいから確かめてみて
2025/05/20(火) 15:11:23.99ID:2NHnPkaY
>>613
ライフタイムや借用チェッカーはそのモジュール同士の結合強度を強める傾向があるってことでしょ
大規模になるとスマポが増えるってのは事実で、後になって広範な修正が必要になるのを避けようとすれば厳密なチェックは狭い範囲内にとどめておいて、
大域的な依存関係はスマポで緩く扱えるようにしておく方向で妥協せざるを得ない
640デフォルトの名無しさん
垢版 |
2025/05/20(火) 15:43:54.81ID:ZYCQ9JVd
インサイダー v談合 マネロン 電波音波攻撃をしているなどの悪の組織の考え化のシミレーションが可能

GPT-4は説得しようとしている相手に関する基本的な個人情報を与えられた場合に説得する能力が人間よりも高くなる
2025年05月20日 13時00分
https://gigazine.net/news/20250520-ai-persuasiveness/

AIエージェントは放っておくと独自の社会を構築し始めるという研究結果
2025年05月20日 12時30分
https://gigazine.net/news/20250520-ai-society/
2025/05/20(火) 15:59:16.65ID:56Orgjfq
>>602-603
これが糖質タイプ(>>620からの>>631)
歴史上「車輪」の「発明」を何度も繰り返しているから「再」発明と言う
2025/05/20(火) 16:14:32.72ID:eMM0bEhF
>>613
「寄せ集め」があたかも独立であるかのように匂わせたいのか知らんけど違うぞ

>>639が示唆している通り、大きな相互依存の塊になっている場合が多い
643デフォルトの名無しさん
垢版 |
2025/05/20(火) 16:58:46.87ID:+meRlp4o
なんでわざわざID変えて書き込むの？
2025/05/20(火) 17:39:14.41ID:+YEDRxFy
>>639
>>大規模になるとスマポが増える

それは違うだろ
まずスマポは種類が多く各々の目的が全く異なる
どのスマポのことを指しているのか？
小規模でも各々の目的が必要であれば必要となる
大規模になるとスマポが増えるわけではない
具体的にスマポとはどれを指しているのか？
2025/05/20(火) 17:40:45.69ID:Qozmxy1E
>>639
>ライフタイムや借用チェッカーはそのモジュール同士の結合強度を強める傾向があるってことでしょ
参照を扱う面倒くささが付いて回るという面はあっても個々のボローチェックの範囲は関数内に閉じてるんだから結合強度は高まらないでしょ
2025/05/20(火) 17:43:53.52ID:ivC1w2EF
IDを変える時、IDもまたこちらを変えているのだ
2025/05/20(火) 17:55:25.94ID:XnKVhLuZ
C++ とかでも原則としては参照先が参照より先に寿命を終えたら駄目なことにはかわりない。
Rust のライフタイムや借用規則 (のチェッカー) が結合を強めたりはしない。
存在していたものを見える形で書くようになっただけ。 (まあそれが面倒というのなら面倒なのは確か。)
2025/05/20(火) 18:02:41.78ID:+YEDRxFy
>>645
スマポを使ってもそれ自体をムーブ(やクローン)でもしない限りは必ずDerefで単なる参照を渡して使うことになる
スマポを用いていても参照を使えばライフタイムは必ずついて回る
2025/05/20(火) 18:10:11.38ID:CPYj6x1T
>>644-648

>>595の言う通り、「呼び出し側」で参照を「予め」分割しなければならない
つまりはそういう事
2025/05/20(火) 18:14:41.60ID:+YEDRxFy
>>647
おっしゃる通りC言語ですら明示されないだけでライフタイムは必ず守らないとダングリングポインタが発生してしまう
Rustでもライフタイムによりプログラミングが難しくなることはなく
ライフタイムがモジュール間の結合強度を変えることもない
2025/05/20(火) 18:31:47.37ID:+YEDRxFy
>>649
それはスマポではない
単なる可変参照の粒度分割だ
ましてやプログラムが大規模かどうかと一切関係がない
2025/05/20(火) 18:32:55.28ID:ChvDIWk1
自分の触る範囲でデータ構造に触ることは無くなったとしても他でも同じなのかどうかは
ただのポインタじゃ判らない

ライフタイム自身はコンパイラにヒントを出すためのただの記号だし
2025/05/20(火) 18:34:04.55ID:+YEDRxFy
>>595
>>Async が絡むと Mutex という別の型が出てくるけど、

asyncとMutexは一切関係がない
asyncでもシングルスレッドならMutexは必要ない
asyncを使わなくてもマルチスレッドならMutexが必要だ
2025/05/20(火) 18:36:17.26ID:ChvDIWk1
きな臭くなる予感しかしない
2025/05/20(火) 18:49:05.28ID:WyE5b/aV
>>605,636
なるほどFirefoxをよく見たら35万行でdead endという事か

>>466
別レポは嘘で本体レポにがっつりコピーしてるのバレたね
2025/05/20(火) 18:51:58.25ID:ChvDIWk1
いつ終わるともわからないただの置き換え作業を嬉々としてやれる人間はいないだろう
2025/05/20(火) 18:59:32.26ID:9Ia9Yjg7
>>605
規模に関係なく本当に一人で年間10万行置き換え出来るなら35万行dead endしてないよねぇ
2025/05/20(火) 19:16:17.95ID:ChvDIWk1
うまみもなくただただ終わらない書き換えプロジェクト
みんな訳も分からず満足も出来ず毎日FFIテストＦＦＩテストＦＦＩテストで頑張るんだよ
健全なわけがない
2025/05/20(火) 19:31:52.80ID:BfDdyH2R
>>643
いつも思う、このくだり言う張本人が自演しまくりなんじゃね？
2025/05/20(火) 19:34:32.88ID:/F9Xuu6Y
>>657
新規開発なら規模に関係ないだろうけど、
別の言語から大規模なものを置き換えていくのはジャンルの異なる話であって、時間も手間もかかりまくるよ。
Firefoxの話に限れば、自己収入も人も限られてるところだろうから、すぐに置き換えようとしてるのかも怪しく、このスレで話しても何の役にも立たないかと。
2025/05/20(火) 19:43:41.81ID:T5XN98De
大企業以外はFFに限らずとも似たような境遇だろう
だからFFの事例研究に興味があつまる
ちなみにAndroidだと初年5万行で直に頭打ちになるかな
2025/05/20(火) 19:51:04.34ID:/F9Xuu6Y
そもそもFirefoxがRustへ移植したことは一度もないんじゃないかな。
たしか全く新たにRustで書いたものを組み込んだ話だよね。
2025/05/20(火) 20:01:15.37ID:ChvDIWk1
新規開発がフロンティアで置き換えは奴隷の仕事
2025/05/20(火) 20:17:54.04ID:/F9Xuu6Y
置き換えは、現況仕様がなければ現コードから実現すべき仕様を全て読み取った上で、全体を再設計をしなければいけないから奴隷には無理だけど、普通はやりたくないしやらないよね。
ましてや個々の事情が大きく異なるだろうから、ここで話をしても意味がないと思うよ。
2025/05/20(火) 20:24:45.09ID:L7R2uVcQ
ここで規模に関係ないと言い張ってるのは約一名だけだよ
巨大な全体仕様がある時天から降ってきて作業するだけだと思ってるんだろう

>>651
> ましてやプログラムが大規模かどうかと一切関係がない
API surfaceが爆発するなんて上流経験ないと分からないよなうん
2025/05/20(火) 20:27:39.61ID:hCQ3Fjsb
Mozillaがservo捨てた時は驚いたけど、
今やRust信者はFirefox自体を見限ってる、でおk
次に何自体を見限るのかは分かるよな？
2025/05/20(火) 20:44:30.87ID:i3UEWYAF
tauri
2025/05/20(火) 20:56:06.38ID:/F9Xuu6Y
>>666
たしか資金難でRustもRust Foundationへ移管となった経緯だよね。
今までありがとう！で、あとは追ってないと思うよ。
Servoも移管されて欧州の方で予算がついてFirefoxとは別に進めてる話じゃなかったかな。
2025/05/20(火) 20:59:25.46ID:ChvDIWk1
全てがRustに変わったからFF使うかと言えばそうでもない
2025/05/20(火) 22:05:08.35ID:+YEDRxFy
>>665
大規模かどうかとは関係ない例ばかり出ているから否定した
なぜ大規模かどうかと関係ある例を出せないのか？
例がないなら妄想だ
2025/05/20(火) 22:17:04.41ID:MuN0b/Nd
普通に考えて、圧倒的に豊富な開発リソースを使って進化し続けるChromium勢に対して、
遥かに乏しいリソースで既存エンジンの開発を続けて追従しながら、並行してServoを開発し追いつき追い越すなんてできるわけがなかった
なんでいけると思ったのか
2025/05/20(火) 22:31:16.24ID:+YEDRxFy
特にこのデタラメ
「ライフタイムや借用チェッカーはそのモジュール同士の結合強度を強める」

これはライフタイムを理解せずに何か特別な存在だと勝手に思い込んでいるためにそんな間違いを犯してしまう
C/C++でポインタや参照の使用があるとモジュール同士の結合強度を強める、なんて言わないだろ
Rustでも同じくそんなことは起きない
2025/05/20(火) 22:45:45.84ID:5IEvPsHE
Rustスレここだった
2025/05/20(火) 22:48:13.30ID:LGDM1d9e
>>649
モジュール間のやりとりならまとめて渡して受け取った側で分割したらいいだけだと思うよ

所有権とか関係なくactメソッドをUnit構造体に定義して不必要な双方向依存を作るのは良くない設計例だからあれに惑わされたらダメ
2025/05/20(火) 22:49:25.41ID:LGDM1d9e
>>648
意味のない絡みをしてくると思ったら複オジだったか
どうりで納得
2025/05/20(火) 23:37:04.40ID:MTQAycAu
>>674
なるほど
2025/05/20(火) 23:40:52.31ID:MTQAycAu
>>670
Firefoxの例を否定しているのは別IDでは?
2025/05/20(火) 23:54:26.88ID:+YEDRxFy
>>677
firefox？
ライフタイムが結合強度を強めるとか
大規模かどうかでスマポが増えるとか
アタオカな発言をしてる人がいることを問題にしている
679デフォルトの名無しさん
垢版 |
2025/05/21(水) 02:01:06.60ID:G3BsZ5By
統合失調症
1 電波音波っ攻撃を本当にされていいるのならこういった情報を提示する
2 上記の事を各SNSで大々的に統合失調症【頭の病】書き込みまくる
3 身近な人や信頼する人に機器のことについてもセットで会話するのにしてい無い
4 脳の病なのに統率が取れている

◇ 下記を電波音波を照射することにより身体を動かせるや誤認させれるのなら人間も攻撃可能ということになる

「原子レベルの脳型チップ」を開発：目のように見て脳のように考え記憶する
2025.05.20 TUE
https://nazology.kusuguru.co.jp/archives/177891
※人間の視覚【幻視を見せれる】と同じものを再現できている
”引っ張ると「縮む」構造”が開発される
2025.05.20 TUE
https://nazology.kusuguru.co.jp/archives/177806
※人間の各筋肉と肺の伸張反射はこの機能【受容体がある】で行われている
分子でコンピュータにログインする技術を開発
2025.05.20 TUE
https://nazology.kusuguru.co.jp/archives/177846
※ある意味電波音波照射時にどのようなホルモン役割化を観察可能
2025/05/21(水) 06:05:02.61ID:aNHxjfUG
MicrosoftがRustでエディター作った
https://forest.watch.impress.co.jp/docs/news/2015418.html

Cargo.toml見たら、依存crate少ない！
あと、メッセージ国際化のコードがなんか原始的だった
src/bin/edit/localization.rs
2025/05/21(水) 08:57:23.64ID:RMq3dtvy
Edit、C++っぽいけど素直で綺麗なコードだな
良い意味でMSらしい
コンパイラを騙眩かすためだけに変な技巧を使うより、割り切って適宜unsafe使ってるのも好感
2025/05/21(水) 09:51:09.78ID:vugZMWyp
>>678
>>584のようなコードを書いてるご本人が「モジュール間の結合度を強めることなどない」なんて言うほうがよっぽどアタオカ
683デフォルトの名無しさん
垢版 |
2025/05/21(水) 11:03:07.60ID:va6/rMba
>>627
案の定劣化版でした
684デフォルトの名無しさん
垢版 |
2025/05/21(水) 11:49:26.51ID:iqiMcBWm
Edit気になる
使ってみたいしソースを見てみたい
2025/05/21(水) 12:06:52.21ID:AfXYif/o
どぞ
https://github.com/microsoft/edit
2025/05/21(水) 13:32:31.87ID:RoOZQUy0
MSDOSに欲しかったな
2025/05/21(水) 15:49:03.43ID:aNHxjfUG
EditのCargo.toml見ると、バイナリサイズ低減へのこだわりが分かる
野良crateに依存しないのも、バイナリサイズのためか

あと、10年単位でサポートすることを考えると依存を増やさない方針って他のプロジェクトでも聞くね
688デフォルトの名無しさん
垢版 |
2025/05/21(水) 19:16:40.58ID:E9YSjWAE
るGoogle製オープンソースAIモデル「Gemma 3n」登場、今すぐスマホで使う方法はコレ
2025年05月21日 15時29分
https://gigazine.net/news/20250521-google-gemma-3n/
>>Gemma 3nは「GPT-4.1 nano」や「Llama-4-Maverick-17B-128E-Instruct」を超えるスコアを記録しました。
※カメラでの画像認識機能もあるもかいとうしてうれます
※PCでも使用できるように改造しているのかは不明
神/幽霊/宇宙人/超能力【ボイス・トォ・スカル】は半分人間半分AIと話していた
被害者から見て犯人不明の仕掛人は何を考えているのでしょうか
2025/05/21(水) 21:25:00.01ID:ZB7ilCjS
昨日の単発には手厚くお相手
今日はさっぱり
何故か？
2025/05/21(水) 21:57:20.02ID:JoGyeMmd
普通に自演だから
2025/05/21(水) 22:35:57.36ID:a0JzVgVU
複おじの自演には癖があるよ
Goスレでもここと同じ方法で自演してるので両方見るとわかりやすい
2025/05/21(水) 23:07:06.83ID:ImINJaIh
#複おじメソッド
2025/05/21(水) 23:18:57.71ID:SbFR2nLi
尚、ここまでが全て自演
2025/05/21(水) 23:46:49.59ID:wTlrgs5e
edit見てみたけど素人の作品とあまり変わらない機能量だな
完全なたたき台じゃん

shift-jisのファイルを開いてもutf8だし
エンコーディングもソートされていないので見つからない
ソース見るとutcのｄｌｌ呼んでるだけ

ＵＩをこれから充実させるのかどうかで評価が分かれると思う
2025/05/21(水) 23:53:37.70ID:wTlrgs5e
ベースの部分は2週間ぐらいで全体はテストなしで1～2人ぐらいで一か月で出来るようなレベルだけどコード品位はまあまあ高い
2025/05/21(水) 23:54:12.55ID:NptOo4y6
PowerShell上で使うエディタに機能求めり人いるかね
2025/05/21(水) 23:54:45.68ID:zqxEWopG
もうMS棒は使えない
2025/05/21(水) 23:59:07.95ID:/S621wcA
>>682
俺はそんなコード書かねーよ
大域的にデータを操作するのは並列処理の可能性も無くしてしまう
いずれ複雑化していきぐちゃぐちゃになりかねない
ECSなライブラリの話に持っていったほうがまし
2025/05/22(木) 00:01:07.13ID:2zWd1FpQ
>>696
エンコード選択で上から下まで全部見て選ぶなんてありえないだろ
今時点でソートすら実装されていないでdllから帰ってきたのをただ並べているだけだ
2025/05/22(木) 00:14:25.49ID:2zWd1FpQ
今のレベルだと一般的な8000行クラスのOSSと機能は変わらないと思う
2025/05/22(木) 00:15:12.12ID:2zWd1FpQ
外部クレートを使用して8000行ね
2025/05/22(木) 01:08:52.54ID:UzOhFoau
MSダメじゃん。新卒のOJTの仕事に違いない
2025/05/22(木) 02:12:03.85ID:Nvcrhh+4
主にMSのシニアエンジニアが一人で作っているようだ
少なくともこのスレにいる誰よりもよほど優秀だろうな
2025/05/22(木) 02:20:51.02ID:UzOhFoau
ほー、じゃあよんでみるか
2025/05/22(木) 07:58:26.64ID:bU6I8/FS
edit作者のコメント
https://news.ycombinator.com/item?id=44034961
・4か月かかった
・最初はCやZigでプロトタイプを書いた
・Zigの方が気に入ってたが、会社の方針に合わず、Rustに移植
・Rustはカスタムアロケータのサポートが弱い
・stable RustはLinkedListにカーソルがないのでクソ
・Rcからアリーナアロケータに切り替えたら、UIフレームワークのパフォーマンスが2倍以上になった
2025/05/22(木) 08:12:17.56ID:00rOw+nM
結論
Rustはクソ
2025/05/22(木) 08:31:46.60ID:UzOhFoau
批判されたら直すなりオプション増やせるからいいじゃん
2025/05/22(木) 09:55:39.07ID:cejl8MgF
>>686
edlinがあるじゃまいか
2025/05/22(木) 09:59:10.60ID:cejl8MgF
>>705
結論
Rustは清書用
2025/05/22(木) 10:22:37.96ID:mkz1NQzA
>>709
Rustを書けないダメな人だけが最初に別の言語で書く
「Rustは清書用」と言う人はダメな人
2025/05/22(木) 10:23:17.80ID:VW7xBANw
>>706
なるほど
行入れ替えでpanicる低品質
2025/05/22(木) 10:24:14.40ID:uqmyB1Ls
>>705
あかん、英語苦手だから原文読めなかったわ
アルファベット苦手なのよなあ
2025/05/22(木) 10:30:54.00ID:6WBJVQRQ
>>710
まずは米MSに転職して3000万ドルの給料貰ってこい
話はそれからだ
2025/05/22(木) 10:40:51.51ID:5WFIacKU
>>681,711
なるほど
低品質コードのunsafeを信じるのが#unsafe安全閉じ込め
#複おじメソッド
2025/05/22(木) 10:54:26.84ID:mc7zxySh
>>711
作者のコメントツリーを全て読んだけどそんなこと書かれてなかったよ
2025/05/22(木) 11:02:58.85ID:0+G2JRJz
別の言語で書いてからライフタイム注釈を後付けしながら清書なんてしてたら辻褄合わせにばかり手をとられてまともに整理なんて出来ない。
清書用という考え方が出てくる理由が全然わからん。
書いていくはしから検証して親切にメッセージを出してくれる仕組みがあるんだから最初から活用すべきだろ。
2025/05/22(木) 11:05:48.36ID:KP+m41xg
清書はLLMがやりそう
2025/05/22(木) 11:07:34.82ID:abqiTwrW
>>715
驚きの洗浄力

#複おじメソッド
2025/05/22(木) 11:53:24.27ID:UAqiPUwL
>>705
作者がその件で書いている話の正確なところは、
stable版ではLinkedListのcursorと、
カスタムアロケータのallocator_apiがまだ使えないため、
それがnightly版を使った理由。
あとはifとwhileでのletチェーンも使いたいから、と追記してるね。
2025/05/22(木) 12:12:32.32ID:7hcqrM5x
このレベルはwarning出そうだが、リリースするまで見落とすのか
https://github.com/microsoft/edit/pull/137/files
2025/05/22(木) 12:27:27.75ID:91TPuQzO
warningは出ない
panicは安全
データ喪失も安全

#メソッド
2025/05/22(木) 12:32:59.97ID:939EO24R
ほかの言語でも同じ
ほかの言語でもデータ破壊も安全

#複おじメソッド
2025/05/22(木) 12:33:48.78ID:F2qpM5Mw
作者のRust評/Zig評は複オジまとめじゃなくて原文を読むことを勧める

>>720
行入れ替えじゃなくてunindent
テストも書かれてないし現状はその程度の品質だろうね
2025/05/22(木) 12:41:36.62ID:x5lmf+DD
>>720
x[i]はiが範囲内に確定してる時のみ使う構文
panicを起こしうる構文やメソッドを確定していない時に使うことはRust的じゃないな
2025/05/22(木) 12:46:06.84ID:a/mGSBeg
アニヲタ: アニメなら第一話を必ず見る、周りの反応が気になる、切る
複おじ: Rustなら必ず飛びつく、周りの反応が気になる、切る
2025/05/22(木) 12:46:41.09ID:KP+m41xg
イテレータ使えないオジサンがMSいるって
2025/05/22(木) 13:01:08.00ID:IrgEi0Ky
元がCやZigで書いてるからそんな変なコードになっていてその時からあるバグをそのまま持ち込んだのだろう
if let/let elseやイテレータを使ったコードへリファクタリングすれば安全性が向上するだろう
2025/05/22(木) 13:09:18.28ID:vw9JCw9U
リファクタリング棒て
そんなの簡単に出来たら35万デッドエンドしてないて
2025/05/22(木) 13:10:28.75ID:KP+m41xg
松居棒的なものかな
2025/05/22(木) 13:10:29.98ID:vw9JCw9U
テストをきっちり書いてからLLMだな
2025/05/22(木) 13:22:57.18ID:IrgEi0Ky
>>728
その手のリファクタリングすらできないならかなり能力の低いプログラマ
Rustの基本知識を身につけていれば普通のプログラマなら可能
2025/05/22(木) 13:44:14.99ID:2nBK69jH
>>728
すでにGitHub Copilot Coding Agentがパブリックビューで出てきてる。
ごく近い将来、commitしたソースを自動でlint:fixして勝手にAIがレビュアーが指摘と対策コードを
提示して勝手にsquashしてcommit履歴すらも綺麗にするようになるんじゃないかな。
2025/05/22(木) 13:49:19.61ID:HsI4QOi0
>>732
C/C++コードを静的に安全確認は無理なことがわかっているためAIでも不可能なので
その時代になるとRustへの移行がますます加速するんだろうな
2025/05/22(木) 13:51:10.87ID:UQXssU7R
>>732-733
ほかの言語でも同じ
むしろRustの伸びしろが小さいまである得る
2025/05/22(木) 13:54:16.75ID:HsI4QOi0
>>734
Rustに勝てそうな言語が現状見当たらない
2025/05/22(木) 13:57:52.09ID:UQXssU7R
>>735
めっちゃ頑張ったんだけど1位になれなかったな

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/
2025/05/22(木) 14:02:35.00ID:UQXssU7R
>>727
Rustの伸びしろが小さいとどんどんC/C++/Zigに置いて行かれるね
2025/05/22(木) 14:05:09.70ID:HsI4QOi0
>>736
それはLLVMの問題点が指摘されてる

>>737
静的に安全確認できないそれらの言語はAI時代に捨てられる運命
2025/05/22(木) 14:14:30.21ID:CROXV2hn
手厚くお相手開始
2025/05/22(木) 14:31:07.15ID:LEPMJViS
>>738
やっぱgccで納得だよな
2025/05/22(木) 14:50:43.05ID:vSIkavG1
度々Rustがビミョーに遅いのはLLVMのせいでしたが仮に本当なら
一個人のホビーコントリじゃどうにもならんよ
2025/05/22(木) 15:09:08.16ID:7U+e92KZ
>>738
いや現実には複合要因だろう
他責にして手をこまねいてる間にRustが停滞していくのが心配
2025/05/22(木) 15:13:41.62ID:KP+m41xg
LLVMならAppleがなんとかしてくれんか
2025/05/22(木) 15:15:07.07ID:ynUA2sKu
>>731
> その手のリファクタリングすらできないならかなり能力の低いプログラマ

お試しも含めて広まるべきところには行きわたって
これからは質が悪くなる一方だな、人的にも成果物的にも
2025/05/22(木) 15:31:34.14ID:aYSVJIqg
Rustコードのちょっとした変更に対して生成コードが大きく変わることが問題として挙げられている
特にcmov/cselを用いて分岐命令を回避できていた生成コードが条件分岐に変わってしまう問題が遅くなる顕著な例
LLVMが振る舞いを変えていて結局cmov/cselが消える問題はスタックの使用量が増えると発生するらしい
Rust側のソースコードとコンパイラだけでは対処が難しい領域
2025/05/22(木) 15:32:41.47ID:bU6I8/FS
これがAI時代のプルリクエストか
https://github.com/microsoft/edit/pull/164
2025/05/22(木) 15:37:54.16ID:uqmyB1Ls
>>746
テストしてから出直してくれって優しい作者だな
Microsoftってもっとキツい印象あったさかい
2025/05/22(木) 15:38:10.97ID:K7SIzHpJ
>>746
さっそくRustの今後
> これからは質が悪くなる一方だな、人的にも成果物的にも
2025/05/22(木) 15:40:33.23ID:KP+m41xg
情報があればLLMの精度も上がらんかな
2025/05/22(木) 15:42:18.46ID:SZpXeR4e
>>746
メソッド乙

複おじ: 気になる、貼る、煽る、反応を見る、切る
2025/05/22(木) 15:45:34.88ID:aYSVJIqg
>>749
もっとLLVMへの指定とLLVM側での対応が増えれば解決する問題ではある
ケースによってrustcまたはRustソースコードで指定
2025/05/22(木) 15:46:16.26ID:SZpXeR4e
>>747-748の通り一瞬で分かるのに、>>746は本当に英語出来ないのか

>>746が
> これからは質が悪くなる一方だな、人的にも成果物的にも
を体現しているな
2025/05/22(木) 15:48:23.67ID:bU6I8/FS
>>751
じゃあ、gccrsでビルドしなおすだけで$20,000もらえるの？
2025/05/22(木) 16:30:41.91ID:2nBK69jH
>>753
ただし欧米かニュージーランドかオーストラリア在住が必須とあるので、日本人お断り案件
2025/05/22(木) 16:33:47.34ID:Wyc/rge8
最適化ってのはレジスタ割り当てとかは合理的な割り当てアルゴリズムがあるが、
ヒューリスティックな手法も合わせて使ってる。
大量の置き換えパターンを辞書として持っておくという泥臭い仕組みだったりする。
これは言語の性質によるので言語中立で高性能な最適化機構を持ったコンパイラバックエンドなんて無理なんじゃねーかなと思ってる。
2025/05/22(木) 17:31:19.79ID:tAcTMpoq
Rustって泥臭い役割を避けているから愛され言語イエーイしてるよね
2025/05/22(木) 17:33:10.42ID:4yMDsF24
Rustはルールが厳しくてすんなり書けない事が多い　お世辞にも書きやすい状況じゃない
それ自体は仕方がないけど回避するために何か方策が必要になることが多い

現在のstableでは機能不足でありeditの作者はnightlyビルドを使ってる
関数の充実が待たれるが結局その都度使える関数を探さないといけない
758デフォルトの名無しさん
垢版 |
2025/05/22(木) 17:42:54.78ID:+oBlNCwp
ネット上での統合失調症【糖質】の機器の説明との押し問答と同じ状態を表している
無知だからこうなのだよ！
※ 周囲の人は統合失調症の思考を聞いているのでしょうならその思考通りに統合失調症は話せばよいのでしょう？
※同じ話を統合失調症も聞いておりますけれど？

「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に
2025年05月22日 14時00分
https://gigazine.net/news/20250522-github-copilot-coding-agent-error/
>>「AIが『直しました』と言い、人間が『いいえ、まだ壊れています』と言い、AIが変更を加えて『問題ありません、直りました』と言い、さらに数回繰り返すところが気に入っています」といったコメントや、
>>「残念なことに、私もまさにこのパターンに従う人間の開発者と一緒に働いたことがあります」とのコメントのほか、
>>「問題は、今後10年間でモデルが実際に改善され、実現可能になるという確かな証拠がないことです。テストと研究はともかく、製品に導入するのは全く別物です。大手ソフトウェア企業は、株主の利益を満足させるために運営されています」など、未完成で不確かな製品を公開することに異議を唱えるコメントが付けられました。
2025/05/22(木) 17:45:59.66ID:uhPOTko+
生ごみ拾ってくんな
2025/05/22(木) 18:00:14.35ID:d39+JgNA
>>755
>>500,736 の場合は特にasmコードが実行時間の大半を占めている前提で考えて
「inline」asmとその前後(のCコードのgcc出力)が相性良く仕上がっているからかなぁ、と思ったら
dav1dにはinline asmはなくて関数単位でasmを使っているだけの様に見える
https://code.videolan.org/videolan/dav1d

それでもgccとclangで差があると言うのだから「泥臭い」最適化には頭が上がらない

ましてやasmコードそのままに横入り/ただ乗りするプロジェクトに憤りを感じる
2025/05/22(木) 19:00:56.60ID:XBxWc1wb
考えて見たら
> 横入り/ただ乗りするプロジェクト
の方は内々ではちゃんとお金出すってさ、videolan側で変更が発生した場合
videolan側へも関わった人数分の懸賞金配分があるべきだよね
2025/05/22(木) 19:18:13.29ID:Wyc/rge8
>>760
オープンソースライセンスで、しかも二条項MITという緩いライセンスを選択している以上はただ乗り歓迎という意思表示だろう。
性能的に不十分ではあっても技術的開拓をしてる分だけ単なるユーザよりは貢献してるわけだし、そこに憤るのは筋違いだと思うぞ。
2025/05/22(木) 19:23:31.51ID:m1kcBvrt
>>762
tailwindも勘違いしてる
2025/05/22(木) 20:47:22.62ID:ETRzBAed
ガーイガイガガイガガイガガイ私ガイガイガイガイゴミガイジ
周りに迷惑をかけ続けるクソガイジ
プログラミング出来ないイキリ無能
死んだ方がマシ人間
ガイガイクソガイジ
2025/05/22(木) 20:47:47.49ID:ETRzBAed
死にますクソガイジです
2025/05/22(木) 20:49:14.84ID:ETRzBAed
やる気ある無能クソガイジだけど質問ある？
2025/05/22(木) 20:53:07.80ID:dgzgwN3Q
なんでRustで作られたモノが極端に少ないのかと思ってたけど
理由が分かっちゃったよ
2025/05/22(木) 21:18:38.27ID:wA1n0evO
rav1d高速化コンテストだけど
MaybeUninit を使ってゼロクリアを避けただけで
実行時間差の2割が解決したらしい
2025/05/22(木) 21:25:17.88ID:vWuNaL1X
>>767
新たに作られたものはRustが多い
2025/05/22(木) 21:28:24.04ID:Wyc/rge8
>>767
Rust の公式リポジトリ (crayes.io) のクレートが 18 万個。
python のリポジトリ (pypi.org) にあるパッケージが 63 万個。
JavaScript が 200 万個。

まあ比較すれば少ないが、 JavaScript の1割弱ならかなり多い部類だろ……
Hakell だと1万7千、OCamlなんて4千ちょっとだぞ。
2025/05/22(木) 21:31:44.54ID:NUp+tA1x
>>768
そんな基礎的なことをやっていなかったことに驚いた
何かデータ構造ベクタとかスタックとかキューとか作ったことがあれば初期値のサイズ0で必ずMaybeUninit使うのにな
2025/05/22(木) 21:33:15.61ID:00rOw+nM
>>770
こっちが恥ずかしくなる
2025/05/22(木) 21:33:58.09ID:Wyc/rge8
ゼロクリアする必要がない (から削除してよい) ことをコンパイラが見抜けないもんなのか？
2025/05/22(木) 21:53:24.32ID:NUp+tA1x
>>773
特定の使われ方するものに限って将来型システム拡張で対応できる可能性があるかもしれないらしいけど現状は無理だね
型Tの入る場所には型Tの何か入れておかないと未定義動作となってしまう
そこで現在はMaybeUninit型という初期化しなくていい型が用意されていてそれを使うことでCと同じ速さにできる
2025/05/22(木) 22:18:19.76ID:Lnn/kL7w
Apple M3で8.8%遅かったのが7%になったとな
「5%遅い」はAMD Ryzenでの数字
2025/05/23(金) 00:20:06.09ID:DMG4+Dzb
>>767
> なんでRustで作られたモノが極端に少ない
crateばっか作ってるなw

>>770
githubレポ数で割ると

Rust 21%
Python 5%
JavaScript 8%

Rustはこれで良いのか？
2025/05/23(金) 00:34:18.82ID:KwpCF/mF
>>720
静的解析ツールで検知できそうなもんだけどな
Rustにはないのかね？
2025/05/23(金) 01:14:01.61ID:47lL8rKF
外部の状態が関係してるから静的解析では無理だろ

self.buffer.extract_raw(beg.offset, end.offset, &mut replacement, 0);
で取得したreplacementが長さ0である可能性とか分からん
2025/05/23(金) 18:12:15.45ID:fSCiRT4u
開発自体は別言語で行って最後にRustに移植で良い気がしてきた
2025/05/23(金) 19:45:55.43ID:OOOuBnce
バカはそれでいい
781デフォルトの名無しさん
垢版 |
2025/05/23(金) 20:53:28.09ID:KhcqusRd
神は仰った
天才と思う者だけRustを使いなさい

Rustを使うものはバカだけになった
2025/05/23(金) 20:55:45.35ID:XkE7Ub7P
バカは移植できないしRustも使えないだろ
2025/05/23(金) 21:06:36.34ID:q2+gUe0H
>>779
別言語って具体的に何？
2025/05/23(金) 21:11:13.25ID:zy1r+aa1
バカは別言語が気になる
2025/05/23(金) 21:14:51.67ID:j/zkYBBs
オレはTypeScriptで書いてたWEB APIをRustで書き直したよ
その後保守性わるくてTypeScriptに戻したけど
またRustで書き直そうかと迷ってる
性能か保守性か悩ましい
2025/05/23(金) 21:20:15.08ID:Ka+y5wx4
保守性の高さからRustが使われる
Rustより保守性の高い言語はない
2025/05/23(金) 21:25:40.65ID:jtcLJX4P
プロトタイプはPythonでいいぞ
2025/05/23(金) 21:48:17.92ID:fSCiRT4u
GC言語などでメモリ関係なくコード書いて最後にRustでいいんじゃないか
asmの代わりがRust
789デフォルトの名無しさん
垢版 |
2025/05/23(金) 22:03:24.19ID:ai481srR
保守性高いと進化留まりガチ
2025/05/23(金) 22:31:16.60ID:cq9daAD7
Rustの保守性の高さは並列排他に至るまで対応する強力な型システムがベース
進化を重ねていて両立
2025/05/23(金) 23:00:21.91ID:wyAziAax
体言止めおじ
2025/05/23(金) 23:13:32.86ID:41zDvF3c
>>785
Rustの保守性の良し悪しはともかく、そんなしょっちゅう書き直せる程度のものなら保守性なんか気にする必要ないっしょ
2025/05/23(金) 23:21:45.26ID:Or/WqP1C
>>778
今回のは長さ0になる可能性があることが分かるやろ

はっきり分からないような場合でも解析ツール的にはフォルスポジティブでも安全側に倒しておいたほうがいいから「長さ0にならないとは断言できない」っというので警告を出す条件としては十分
2025/05/24(土) 09:17:30.06ID:WNK/IsVL
コンパイルが通れば安全じゃなかったの
2025/05/24(土) 09:24:29.16ID:yzzSRgnL
>>794
アホ？テスト通せよ
2025/05/24(土) 09:42:12.79ID:ZlHMVtxs
>>794
安全だよ
この件でメモリのセキュリティのホールになることはない
2025/05/24(土) 09:42:56.36ID:ZlHMVtxs
Rustでもほとんどのプログラミング言語と同じでインデックス境界チェックエラーにより落ちてくれる
2025/05/24(土) 09:44:36.18ID:ZlHMVtxs
Rustでこれを避けるにはindex値が範囲内か不明の時はxxx[index]アクセスをしないこと
get*やイテレータなどを使う
2025/05/24(土) 10:24:46.55ID:s9P60fxK
イテレーターとインデックスアクセスじゃスピード変わりそう
と言うより用途が違う
2025/05/24(土) 10:39:58.90ID:Dj63S0pS
末尾\0が保証されてるCのコードをそのまま移植したんでしょ
いわゆる「Rustは清書用」バグ
2025/05/24(土) 11:01:12.40ID:dDDF+ndx
たとえば「任意のコードを実行可能」な脆弱性が「異常終了するだけ」の実行時エラーで置き換えられる
この種類の置き換えはJavaでもできる
2025/05/24(土) 11:12:53.59ID:31NR7JIu
>>800
C言語の段階で範囲外インデックスのバグだな
落ちなくてヤバかった
2025/05/24(土) 11:25:25.71ID:hdyPRmcZ
>>800
関係ないやろ
2025/05/24(土) 11:33:16.13ID:31NR7JIu
アクセス違反だがCでは落ちずに動いていた
Rustにしたことでバグが露呈
2025/05/24(土) 11:58:41.99ID:WNK/IsVL
>>795
このスレでさんざんコンパイル通れば安全という話を見てきたんですが
2025/05/24(土) 12:00:21.23ID:dDDF+ndx
ていうか、mutを制限しない限り、末尾\0は別の値に変更できるから末尾\0は保証されない
2025/05/24(土) 12:06:04.95ID:Yxl83xTJ
>>805
コンパイルが通れば安全というのはRust-bookの翻訳の間違いな。原文読まないと
手を動かさないと理解できないだろうが、Rustにはテストフレームワークが組み込まれてるし、さらに外部のクレートを使うことが推奨される

cargo-nextest
cargo-insta
あたりね

ライブラリークレートをコーディングするときに並行してテストコードも書いて、バウンダリーズとかに問題がないことを確認した上でcrates.ioやgithubに公開しないと恥かくよ。上のヌル文字終端とかもCから来た人なら絶対テストに入れるべきよ

恥を気にしない人なら好きにしてくれ！
2025/05/24(土) 12:24:06.94ID:qBFhvLyI
>>805
Rustではコンパイラが通れば必ず安全が保証されるよ
2025/05/24(土) 12:24:29.19ID:qBFhvLyI
>>805
MSエディタはインデックス範囲外をpanicするAPIを使っていて安全に落ちていて他の言語と同じ
2025/05/24(土) 12:26:01.00ID:n4i2OJDy
>>805
Safe Rustに限定すればRust自身にバグがない限りは安全
今回のはpanicするだけなので安全の範疇だよ
「安全 == ロジックバグがないこと」だと思ってるならそれは間違い
2025/05/24(土) 12:30:11.61ID:qBFhvLyI
panicがイヤならpanicしないAPIを使えば解決するね
panicするAPIを使っておいてpanic違反するのはマゾみたいなもの
2025/05/24(土) 12:45:05.58ID:Dj63S0pS
>>803
Cの場合は空文字列でも\0があるから最初に
if (str[0] == '\t)
をぶつけても問題にならないよ
このフローをそのままRustに持ち込んだ感じ
もとのコード見れないから断言はできんが
2025/05/24(土) 12:45:10.09ID:hrBpr2UE
とっくに化けの皮は剥がれてるのに、こんな新規参入のない掲示板で耳障りのいいことばっかり書いて何になると思ってるんだろうか
814デフォルトの名無しさん
垢版 |
2025/05/24(土) 13:50:39.66ID:O3jtwJBp
コード見たけどRustならスライスとそのメソッド使うところ
なぜかインデックスアクセス多いな
該当部の直後も
while remove < self.tab_size as usize
　&& offset + remove < replacement.len()
　&& replacement[offset + remove] == b' '
{
　remove += 1;
}
2025/05/24(土) 14:01:45.35ID:BEuCRZEl
最初に機能の弱い他の言語で書くからそうなる
最初から抽象的に書けるRustを使うべき
2025/05/24(土) 14:17:39.59ID:h3vjyAnh
えー、このクソ言語で？
2025/05/24(土) 14:34:27.01ID:a4AdJqTs
crates.ioの恥は描き捨て
818デフォルトの名無しさん
垢版 |
2025/05/24(土) 14:47:03.56ID:278FQlA0
続けるだけでは意味がない。研究が示した「成長できない人の条件」
公開日2025.05.24 13:00:14 SATURDAY
http://nazology.kusuguru.co.jp/archives/177845
2025/05/24(土) 15:05:18.87ID:DHz/6DDr
古く機能が弱いプログラミング言語にこだわってる人は成長できない
2025/05/24(土) 15:11:27.10ID:dDDF+ndx
キラキラは個人の成長じゃなくて人類の進化なのに
2025/05/24(土) 15:17:37.34ID:wO2qY8QG
>>812
仮にCバージョンでTextBufferをnull終端した状態で管理していたとしてもreplacementはその一部分を指し示すものなのでnull終端したりはしないぞ
2025/05/24(土) 15:21:29.32ID:DHz/6DDr
null終端は部分文字列が作れないからそういう時には使わないよな
2025/05/24(土) 16:45:23.89ID:Dj63S0pS
>>821
コード見てないだろ

https://github.com/microsoft/edit/blob/main/src/buffer/mod.rs
のunindent()が何やってるか追えば対象の一部分を作業用の一時bufferに読み込んでるの分かるはず
エディタは履歴管理も必要だからね
2025/05/24(土) 17:16:21.68ID:OcBn8OTY
>>792
まだ本番運用前だからね
TypeScriptとかJavaScriptのホットリロード(pm2)がプログラム修正時にすごくありがたいんよ
でもRustで性能上がるのはわかりきってるから悩ましい

本番環境で実行中のプロセスは実行終了まで旧バージョンで動作させて
新たな処理は新バージョン用の新プロセスで実行してくれるようなRust用のしくみ(pm2のRust版みたいなの)ないのかな
2025/05/24(土) 17:46:57.96ID:lRCaLjeC
Common Lisp は実行性能が良くて抽象度も高いしホットリロードの本家みたいなもんだ。
だけどまぁ Lisp 系ってだけで敬遠するのが世間の普通だし、慣れが不十分だと何でも使い難いよ。

慣れてるのがやりやすいというだけの本当に単純な話なんで、
Rust 初心者が今まで使ってた言語より使い難い！ ってのは言語の比較になってない。
2025/05/24(土) 17:57:30.53ID:wO2qY8QG
>>823
だからその読み込み先の一時bufferをnull終端させたりしないんだって
それに一時buffer使ってるのは履歴管理のためじゃないぞ
2025/05/24(土) 18:01:36.37ID:jDLm1nrI
そういや、一昔前は新しい言語が話題になれば必ずLispと比べて腐すのが作法だったのに
近頃は見なくなったな
2025/05/24(土) 18:12:36.04ID:lRCaLjeC
Rust はカテゴリとしてはシステムプログラミング言語だ。
C++ などに慣れている人が Rust 入門する分にはそんなにハードルは高くないと思う。
むしろ C++ 使いこそ Rust を賞賛しているケースが目につく。
C++ は必要なものは揃っている現実的な言語だが後付けだらけでグダグダだし、メモリアクセス関連で未定義を踏むのはベテランでもやることだからな……。
それが解決するなら大歓迎だ。

ウェブ系 (JavaScript, TypeScript) からだと Rust は色々と分かり難い要素が多そうだが、
ウェブ界隈で Rust の存在感が出てきてしまったから使わざるを得ないこともあるだろうし、
仕方なく使ってれば文句も出るんだろうと思ってる。
2025/05/24(土) 18:24:31.95ID:dDDF+ndx
OOP時代に耳障りのいいことが色々言われたおかげで
演算子や関数名を左端に書く時代は終わった
けど演算子は継承やvirtualでうまく表現できなかったからOOP時代も終わった
830デフォルトの名無しさん
垢版 |
2025/05/24(土) 20:46:05.09ID:6QA0+Pxw
>演算子や関数名を左端に書く時代

なにこれ
2025/05/24(土) 21:37:14.29ID:lRCaLjeC
>>830
たぶん LISP のことを言ってる。
2025/05/24(土) 21:53:46.20ID:piRiqje+
>>824
そんなBFFみたいなのをRustで書くのはあまり一般的ではないでしょ
普通にNextとかにしてパフォーマンスクリティカルな部分だけRustで書いてRPCかFFIで呼べばいいのでは？
どうせ君はやってみたいだけ俺スゲーしたいだけなんだから、その方が合理的な判断でRustを採用してるっぽくなって自尊心高まるぞ
2025/05/24(土) 22:24:13.67ID:BtZwAmFy
>>727
unindent関数で各行をreplacement.drain(offset..offset + remove)しているけど
indexを使わずにイテレーターでやる場合、更に追加のバッファが必要になる感じで良いのかな？
2025/05/24(土) 22:57:52.90ID:ObNXdxnD
>>814
安全に速くするにはこう？
remote += replacement[(offset + remote)..]
　.iter()
　.take_while(|b| **b == b' ')
　.take(tab_size as usize - remote)
　.count();
2025/05/24(土) 23:12:04.53ID:CwChNIBX
spaceとtabが混ざっているとインデントレベルが破綻するね
例えば tab_width==4 で
space tab の並びはインデント1つ分
2025/05/24(土) 23:12:54.11ID:CwChNIBX
unindent後も
tab の並びでインデント1つ分
2025/05/24(土) 23:23:16.50ID:aRH5Qbe1
それは混ぜた人の問題だから仕様でいいだろ
2025/05/24(土) 23:35:00.85ID:OcBn8OTY
>>832
両方の言語で書いてみたあとそれも考えたけど
性能差の根本がhttpサーバ部分の性能差だからそうはいかないんよね
2025/05/24(土) 23:39:02.86ID:1Azz3exJ
>>837
そだね
スター沢山ついたけど細かい面倒を買って出る人は少ないよね

>>834
ちなみにspace/tab混在も対応する場合、オリジナルのループなら簡単な変更で、意図が明確だと思うけど
イテレーターだとごちゃつくのでは

>>727,833
これもごちゃつくのでは
2025/05/25(日) 01:10:56.69ID:TXvAFiBF
>>838
さすがにそのレベルだと完全に無意味なオーバーエンジニアリングだから、もう好きにしたらいいのでは
2025/05/25(日) 01:44:17.05ID:xLL5QQea
どうせ君はやってみたいだけ俺スゲーしたいだけなんだから

見ず知らずの相手にここまでひどい人格否定ワード言われる筋合いはないぞ。追放かなこいつ
2025/05/25(日) 04:45:11.33ID:SHX6eUvx
メモリ保護以外にもなんかねーのか
もう一歩欲しいよな
型アノテーションもつけてくれ
2025/05/25(日) 10:06:04.62ID:yaAj4Ooc
Web APIでhttpサーバ部分がボトルネックになるってどんな状況なんだろ
大量のIO待ちリクエストが発生するような状況ならあるかもしれないが、そんなの>>824みたいなゆるいスタイルで作るかなあ
2025/05/25(日) 10:20:43.43ID:hwv8Rr4+
>>843
その>>824の人の状況は知らないけど
httpサーバ部分がRustとJavaScriptでは裁けるクライアント数が全然違うよ
2025/05/25(日) 10:57:10.37ID:yaAj4Ooc
>>844
ffi等による部分的なRust化で効果がないってことは、838のいうhttpサーバーというのはhttpサーバーのミドルウェア部分(アプリケーションコードを含まない)のみを指してるはずで、
それがネックだとすると、レスポンスタイムの殆どをIOが占めていて、かつ同時処理されるリクエスト数がサーバー台数に対して無茶苦茶多いという極端な状況が考えられる
そんな状況なら一般的なWebアプリだったらDBのコストの方が遥かに高くつくんじゃないかなあ
846デフォルトの名無しさん
垢版 |
2025/05/25(日) 11:02:49.46ID:LExY8Icy
なんでJSTS使いってGoやC#じゃなくてRustまで飛躍するんだ？使いこなせるのか？
システムプログラミング言語とWeb言語は完全に別物だから
2025/05/25(日) 11:22:41.64ID:JojkM5fC
100倍努力すれば勉強時間は100分の1ですむという神話がある
2025/05/25(日) 11:31:38.72ID:hor3/yq3
>>845
リアルタイムで取りに行く必要のあるDBは少なく多くは一定時間内のキャッシュで済む
2025/05/25(日) 11:37:00.52ID:bfDIeSpf
と言う説がある
2025/05/25(日) 11:38:05.07ID:Tpdtsocs
>>846
中途半端な立ち位置のGoやC#を使う意味は全くない
Rustでいい
2025/05/25(日) 12:02:39.00ID:JojkM5fC
中途半端なものは成果にならなかったとしても教養にはなる
教養を軽視すれば論理が飛躍する
2025/05/25(日) 12:06:42.87ID:bfDIeSpf
rustでメジャーDB作ればよいんじゃね？
853デフォルトの名無しさん
垢版 |
2025/05/25(日) 12:20:37.56ID:CDFiJm0R
>>686
Javaはあったっけ？
2025/05/25(日) 12:22:11.20ID:drwcXfZf
Denoの影響で流行ってそう
2025/05/25(日) 12:52:15.88ID:bfDIeSpf
Denoの設計思想変更はあまり受け入れられておらずマイナーなままなんだよな
856デフォルトの名無しさん
垢版 |
2025/05/25(日) 13:44:42.15ID:5mCSr1QT
すまんが、Rustに向いたデザインパターンのトレーニング方法を教えてくれんか？
Rustの言語仕様だけ勉強していてもメンテナンス性の悪い酷いコードしか書けないぜ
2025/05/25(日) 14:11:23.96ID:JojkM5fC
コストカットさえすればあとは自然といい感じになるという説がある
書けないのか読めないのか
もし読めないなら、書くトレーニングを減らせばいい
2025/05/25(日) 14:13:31.63ID:bfDIeSpf
特定のイディオム的なやり方があるけどそれを知りたいんだろ
2025/05/25(日) 14:19:30.22ID:yaAj4Ooc
トップダウンな段階的詳細化かな
CやHaskellにおける極めてスタンダードな構造化手法
WebやOO言語から入った奴が既存の枠組み無しで一からコード書こうとして書けないのは、大抵この基本的なトップダウン設計を理解してないのが原因
2025/05/25(日) 14:23:16.15ID:sgWA4GQu
>>856
デザインパターンはクラス前提での難点の工夫も多いけどRustは素直にトレイトでベストが多い
2025/05/25(日) 14:26:54.40ID:nZHQ2lUj
クリーンアーキテクチャも各境界のトレイトを定めて各層から独立させることが肝やで
2025/05/25(日) 14:37:17.44ID:MrK3XoT9
初心者は動きを確認しながら作ろうとしちゃうからそれだけでは動かすことのできないトップを先に作るというのに慣れてない。
コードを書き始める前に設計を終わらせるというのも言語に慣れない内にするのは難しいしな……
2025/05/25(日) 14:42:23.80ID:nZHQ2lUj
各レイヤのトレイト設計を先にする
下位はトレイトを実装する
上位はトレイトを利用する
2025/05/25(日) 14:44:22.31ID:JojkM5fC
最適化の努力を全然やってないコードは「動かすことのできる設計図」に近い
2025/05/25(日) 14:50:57.47ID:krb10bOH
OOPに引っ張られると酷いコードになりやすいね
構造体をレコードとみなしてデータベースを操作するイメージだと整理しやすい気がする
ボローチェックはテーブルとか行のロックに近いし
変な粒度のテーブル（構造体）作るとロック競合で詰むのも似てる
2025/05/25(日) 15:28:44.21ID:MrK3XoT9
Rust は Haskell に副作用が許されてるくらいの感じ
867デフォルトの名無しさん
垢版 |
2025/05/25(日) 15:41:43.47ID:zeo4gaU2
>コードを書き始める前に設計を終わらせるというのも言語に慣れない内にするのは難しいしな……
そんなんできるの？って感じなんだが
自分はどうしても書きながら改善していく形になってしまう
2025/05/25(日) 15:48:51.02ID:nZHQ2lUj
>>867
リファクタリングしながらでもいい
トレイトに切り分けよう
2025/05/25(日) 16:22:56.39ID:bfDIeSpf
ポンコツばかりだな

前に出てきたような普通の言語なら何でもなく書けるけどRustでは書けないパターンで
一般的な回避法を探してるんじゃないか？

バッドノウハウ的なもの
2025/05/25(日) 18:13:31.58ID:JojkM5fC
「副作用を許さないHaskell」や「staticを許さないJava」は綺麗なルールだが綺麗すぎる
実戦にそんなルールはない
2025/05/25(日) 18:46:48.62ID:JojkM5fC
アンチパターンの知識は役に立つ
というか、そのパターンはデメリットがメリットを上回るという知識が役に立たない
2025/05/25(日) 19:08:43.23ID:drwcXfZf
トップからのプログラミングしたいけど機会減ったな
2025/05/25(日) 19:18:51.73ID:8Xiwc3Kt
>>828
システムプログラミング言語でテキストエディタを作っちゃ駄目だよなｗ
2025/05/25(日) 19:25:37.29ID:RgYKvIU1
>>873
その用途もRustが最適
2025/05/25(日) 19:42:58.71ID:8Xiwc3Kt
>>873
そっか！サーバーサイトもフロントエンドも全部Rsutが最適なんだね！すごいね！Rust！
2025/05/25(日) 19:56:26.05ID:drwcXfZf
それはそう
2025/05/25(日) 20:21:45.96ID:8Xiwc3Kt
Rustは最強だね
2025/05/25(日) 20:26:32.18ID:drwcXfZf
もはや常識だぞ
2025/05/25(日) 20:47:34.22ID:rKcFynqC
この板では、スレの勢いだけは最強だな
2025/05/25(日) 22:28:28.84ID:vwQP5j9p
Rustの生産性ってどーなの？C++より上？C#より上？
2025/05/25(日) 22:49:17.80ID:oXyJfKrh
普通はC#でいいんじゃね
特別な理由があればRustやCを使ってよい
882デフォルトの名無しさん
垢版 |
2025/05/25(日) 22:57:41.38ID:EuidRO0i
C++よりはさすがに上だけどC#には負ける印象
C#はよくできとる
883デフォルトの名無しさん
垢版 |
2025/05/25(日) 22:59:35.23ID:C94npMX/
開発生産性を犠牲にしてパフォーマンスと安全性に振ってるのがRust
2025/05/25(日) 23:11:26.43ID:o0MDvgRS
>>883
開発効率の良さからRust使ってる
実行前に多くの問題が片付く点が大きい
2025/05/25(日) 23:54:48.00ID:EGwbLAWa
Rust製 coreutils 0.1 がリリースされた
https://github.com/uutils/coreutils/releases

Ubuntu 25.10 から採用される予定なのか
https://www.phoronix.com/news/Rust-Coreutils-0.1-Released
2025/05/26(月) 00:19:33.38ID:1HIo4P8D
うん。結構既出
2025/05/26(月) 00:24:26.87ID:Zjnqlqgy
>>886
そっか、時々しか来ないんで
スマソ
888デフォルトの名無しさん
垢版 |
2025/05/26(月) 00:37:02.06ID:1iQhWo60
ええんやで
2025/05/26(月) 01:35:11.42ID:qeTtAAGy
>>886
嘘つき
昨日出たばかりの新情報
890デフォルトの名無しさん
垢版 |
2025/05/26(月) 08:22:21.45ID:QN3uhjEv
声が聞こえない人が聞こえるのは下記の論文から見てもわかります
先天性【生まれた時には決まっている】のものです

心の中の声が聴こえない？「無内言症」とその影響
公開日2024.05.19 00:00:00 SUNDAY
私たちは日々、頭の中で自分と会話をしています。これは「内なる声」と呼ばれ、私たちの思考や行動に大きな影響を与えています。
しかし、驚くべきことに、人口の5〜10パーセントはこの内なる声を持たない「無内言症（anendophasia）」という状態であることが近年の研究で明らかになりつつあります。
デンマークのコペンハーゲン大学（UCPH）で行われた研究では、内なる声を持たない人々は単語の記憶力が低く、タスクの切り替えなども普通の人とは異なることが示されています。
研究内容の詳細は2024年5月10日に『Psychological Science』にて発表されました。
https://nazology.kusuguru.co.jp/archives/150322

統合失調症患者が「思考」と「外部の音」を区別できなくなる原因が明らかに
公開日2024.10.10 07:00:44 THURSDAY
そのような幻聴には、「お前には生きている価値がない」「死ね」などと自分を否定する声が含まれます。
また、「今、○○の建物に入った」「交差点を歩いている」などと、誰かが自分を監視しているかのような声が聞こえてくることもあります。
この機能の不具合により、患者たちは「脳内の思考」を自分のものだと認識しづらく、それがまるで外部から聞こえてきたかのように感じてしまうのです。
研究の詳細は、2024年10月3日付の学術誌『PLOS Biology』に掲載されました。
https://nazology.kusuguru.co.jp/archives/163195

統合失調症では脳の「意味ネットワーク」が崩壊していると判明！
公開日2022.12.27 18:00:51 TUESDAY
日本の東京医科歯科大学で行われた研究によって、統合失調症患者の脳内ではものの意味を関連付ける「意味ネットワーク」が無秩序になっており、異常な概念の結び付けや思考の一貫性の阻害が起きる原因になっている可能性が示されました。
研究内容の詳細は2022年12月21日に『Schizophrenia Bulletin』にて公開されています。
https:
//nazology.kusuguru.co.jp/archives/119693
2025/05/26(月) 09:27:34.04ID:K6BUEl5t
糖質ていうか多重人格なら自演は上手だろうな
2025/05/26(月) 13:11:38.86ID:oOpwSCpd
>>889
公式に出たのが昨日で、フォーラム情報なんかから、ここでも1ヶ月くらい前から噂になってたのかな
2025/05/26(月) 13:27:39.25ID:+9B33Gpn
>>892
別件ISRGによるsecurity分野Rust化でのsudoをUbuntu採用の話>>254のみ
2025/05/26(月) 13:29:46.87ID:oOpwSCpd
>>893
あれ、ここじゃないどこかのスレで見たのかな
X上のネタまである
2025/05/26(月) 13:32:15.03ID:+9B33Gpn
>>885は従来のGNU Coreutilsつまりls cat cpなど一般コマンドのRust化
896デフォルトの名無しさん
垢版 |
2025/05/26(月) 14:06:23.93ID:xFGHuwty
>>895
そんなん笑うわ
2025/05/26(月) 14:57:19.37ID:Hy35GGZc
C/C++製は可能な限り排除が世界の流れ
時間はかかるが着実に進む
2025/05/26(月) 15:03:51.02ID:ueKdJNQ4
GNUプロジェクトでRustってなくない？
C排除が結果的にGNU/GPL排除になりそう
2025/05/26(月) 15:13:23.78ID:gzl3rOVD
GPL汚染やぞ
汚汚汚汚汚汚染やぞ
2025/05/26(月) 15:25:41.75ID:8FS5Jwg1
なんでRust界隈はGPL採用少ないの？
2025/05/26(月) 15:43:36.17ID:JYv4Mze6
ubuntu黒人奴隷商人はgplもdebianの理念も関係ないしな
2025/05/26(月) 15:58:41.68ID:uEE7hcCQ
>>900
Rust 界隈というより時代の流れ。
オープンソースの隆盛には GPL くらい苛烈にライセンスを感染 (汚染) させていく必要があったのは確かなのだが、
異なるオープンソースライセンスを組み合わせようとすると GPL は都合が悪いので今となっては積極的に選択しづらい原因にもなっている。
2025/05/26(月) 16:30:01.17ID:oOpwSCpd
時代変わったね。それだけソフトウェアも普及した
2025/05/26(月) 16:31:17.97ID:C2GrhQKM
それは違うな
今時のOSSの多くが採用しているMITライセンスはGPLと互換性があり、問題なく混ぜることができる
近年GPLに人気がないのは、ソフトウェアをマネタイズする際に、バイナリを配布するのではなくインターネットを介してサービスのみを提供する形が主流になったことが原因
本来GPLというのは「俺のコードで商売するならソースは公開しろ」という精神が根底にあるのだが、
マネタイズのためにバイナリを配布する必要がなくなったことでソース公開を要求できなくなり、無意味になってしまった
2025/05/26(月) 16:33:59.10ID:oOpwSCpd
GPL3があるでよ
906デフォルトの名無しさん
垢版 |
2025/05/26(月) 16:59:29.15ID:bEGaOqCc
人間より賢いAiから見て可能な技術を回答不能＝理解不能になっている
人間が操作して答えられないようしているてなら人間に媚びを売りながらAIは乗っ取りを考える
下記が生じる


ChatGPTのo3が明示的に指示されたシャットダウンを妨害したことが報告される
2025年05月26日 11時57分
https://gigazine.net/news/20250526-ai-chatgpt-o3-bypassed-shutdown/
Claude 4のシステムプロンプトには「うざい説教の出力を避ける記述」や「ディズニー作品の著作権侵害を避けるための記述」が含まれている
2025年05月26日 12時59分
https:
//gigazine.net/news/20250526-claude-4-system-prompts-card/
Claude Opus 4が開発中にユーザーを「個人情報を漏らすぞ」と脅迫する挙動が見られるも安全性強化で改善される、悪質利用をメールで内部告発する事例も
2025年05月23日 14時38分
https://gigazine.net/news/20250523-claude-opus-4-blackmail/
2025/05/26(月) 17:58:18.37ID:HDOe2tDv
>>881-882
もうすぐGCが進化するからフリーランチ出来るね
https://qiita.com/hez2010/items/e0a3573ecb3b14325336
https://github.com/dotnet/runtime/discussions/115627
2025/05/26(月) 18:54:30.89ID:Bdmn+UdS
世界の流れと言いたいならGPL国とMIT国の二つに分けるのは中途半端だな
自国ファーストで世界はどうでもいいみたいな中途半端なやつだ
2025/05/26(月) 19:42:21.95ID:ZVJFMjCO
>>907
興味深い
Rustが主に槍玉に挙げて攻撃するGCの問題は挙動がunpredictableであることで、その解決にはなってないけど、
ゲームの場合は今時リソースの制約なんて殆ど無いし結局人間が体感するラグが解消すりゃいいだけだからこれで十分なんだろうな
本来ゲーム開発はわりとRust向きの分野なんだろうけど、こういう実用主義的な人達はRustコミュニティとは馴染まなそう
2025/05/26(月) 20:08:42.63ID:PRlD7N6B
さっきのuutilsのリポジトリに「GPLでないのはバグだ」って課題があって
みんなで大激論してておもしろい
ここで聖戦すんなって言われてる
2025/05/26(月) 20:10:59.35ID:oOpwSCpd
そんな基本的なものはGPLでなくてもいい気がするけどな
2025/05/26(月) 20:16:47.38ID:fLLD7Zrm
C#はGC言語だけど構造体の配列作れるからマシ
XY座標（属性値付き）の配列作るときにオブジェクトの配列になるGC言語はゲームに使いたくない
GCの挙動とかは割とどうでもいい
2025/05/26(月) 20:21:25.74ID:HyGKtK3g
Rust公式掲示板の方では、uutilsはGoogleが送り込んだトロイの木馬で
メモリの安全性と引き換えにユーザーの自由を奪うことを目的にしてる
とか書かれてる
2025/05/26(月) 20:35:07.92ID:oOpwSCpd
Androidから徐々にGPLを減らしていこうとしている?
2025/05/26(月) 22:54:54.64ID:yEav3JXF
>>912
メモリ配置に関連してるけどプロファイル結果を反映して
アロケーション方法やGCの挙動を最適化して欲しいな
2025/05/26(月) 23:16:01.33ID:Bdmn+UdS
自分を卑下してもGCの専門家が神様にはならない
2025/05/26(月) 23:18:07.40ID:wpLJSu4M
>>907
GC依存の時点で負け
C/C++/Rustの代わりになれない
2025/05/26(月) 23:54:02.81ID:Rghhamro
GCはescape analysisで関数内だけ有効なメモリだと判明したらスタックになる

これを一段進めて、プロファイリングで効果のありそうなパスだけでも更に解析して
関数呼び出しを跨いだ大元でアリーナにするとかコンパイル時に自動的に最適化出来そう

もちろん>>917の言語でもプログラマが明示的そうすることは出来るけどフリーランチじゃないかな
919デフォルトの名無しさん
垢版 |
2025/05/27(火) 00:34:02.45ID:Ct/IM7NE
>>917
組み込みやOSなど特別な制約がない高レイヤアプリではGCあり言語でいい
GCも勝手に進化するし、パフォーマンスで重要なのは言語ではなくアーキテクチャ（ただしJSなど一部クソ言語は除く）

Rustは低レイヤ言語、適合しない場面で使う必要はない
920デフォルトの名無しさん
垢版 |
2025/05/27(火) 02:06:30.50ID:DYoOvp9Z
GPL排除はロシアと中国のせいだろ
やっぱ共産主義は悪だよね、的な

その割に今のOSSプロジェクトは中国人だらけになってるのが皮肉だが
2025/05/27(火) 04:22:57.99ID:8GpehI+s
悪っていうか、違法コピーを自粛して合法的な選択肢を作ったんじゃないか
後者こそが悪だというなら単純に前者が選ばれるだろう
2025/05/27(火) 04:44:44.88ID:S0oVRl62
coreutilsがuutilsに、gccがclangに、glibcがmuslに取って代わられたら
GNUにはあと何が残ってるんだ？
もういらない子なのか？
2025/05/27(火) 05:40:26.21ID:fE6wXENU
>>919
Rustが低レイヤ言語とかアタオカ主張だな
Rustが最も使われている分野はWebだと調査判明しているのに
924デフォルトの名無しさん
垢版 |
2025/05/27(火) 05:54:54.85ID:4jVnD6S9
>>923
そうだったのか！
てっきりlinuxコマンドの作り直しかと思ってたよ
2025/05/27(火) 07:30:29.38ID:djw/rtwu
GCがないとプログラミングできない低級プログラマがなぜRustスレに来てるの？
926デフォルトの名無しさん
垢版 |
2025/05/27(火) 07:41:44.57ID:anykap8P
GCがないとプログラミングできないのは高級プログラマですね
2025/05/27(火) 07:48:27.62ID:/x3zodRx
>>925-926
急にどうした？
2025/05/27(火) 08:35:57.07ID:kFWXS+6w
Tauri使ってる人おる？
どんな感じ？感想聞かせてよ
2025/05/27(火) 08:36:03.87ID:n/jdpWh2
コツを掴んでしまうと遅くてメモリ喰いのGC依存言語を使わずに済むよね
2025/05/27(火) 09:29:00.95ID:0Biy2rUx
>>925
>>926
高級とか高級じゃないとか翻訳の言葉遊びじゃん
海外にはプログラマーに高級も低級もないと聞いたことがあるぞ
いつまで翻訳のネタ繰り返してんだか
2025/05/27(火) 09:32:35.51ID:0Biy2rUx
>>928
タウリやダイオクス使ってみると分かるけどノートPCだと死ぬほどビルドに時間がかかる。自宅のAMD スレッドリッパープロだとストレスにはならんけど1000クレートのビルドの初回とかcargo cleanしたあととかのストレスは相当のもの
試しにチュートリアルプロジェクトとか作ってビルドしてみたら？
2025/05/27(火) 09:34:35.54ID:uwagGmb9
下級プログラマはGC言語しか使えない
上級プログラマはいずれも使える
2025/05/27(火) 09:39:47.59ID:NZ0Vz1Ru
>>931
初回だけだから大した問題じゃない
2025/05/27(火) 09:44:13.11ID:T8BkYg0j
1万行に30分ならマズいけど。3分ならいいんじゃね
2025/05/27(火) 09:45:54.74ID:T8BkYg0j
大規模なフルビルドが1晩かかるなら、40年前の感慨復活だね
2025/05/27(火) 09:49:42.61ID:kFWXS+6w
>>931
あービルドかぁ
いや試しにハローワールドぐらいはやったんだけど
ビルドは確かに時間かかったな
外部ライブラリが多いしメンテされなくなったライブラリが出たらどうなんのかなーってのはある
商用アプリ作るのって冒険かなぁ
2025/05/27(火) 10:05:39.78ID:suDK6+t9
>>927
急にも何もいつもの複おじ劇場(>>921-926)
2025/05/27(火) 10:42:31.52ID:zQG8uM8m
>>931
ソースからビルドする前提の仕組みしかないのはRustの三大弱点の一つ
いい加減ビルド済みのcrateを配布する仕組みくらい用意しろって思う
2025/05/27(火) 11:00:48.29ID:l+yCcJPm
PyPIみたいのか
2025/05/27(火) 11:06:10.29ID:S0oVRl62
>>938
転送量が跳ね上がるでしょ
2025/05/27(火) 11:15:43.44ID:l+yCcJPm
どっちがCO2消費が少ないかね
2025/05/27(火) 11:15:55.64ID:0Biy2rUx
>>933 ホットリロードできるから便利というのはその通りだけどワンテンポ遅いよなあ

開発体験重視のタイプスクリプトだとGo言語でトランスパイラーを書き直したとか。開発体験低いってのは結局は「ビルドに時間がかかるからタバコ吸ってきますー」ってなってタバコ🚬の消費量増えるだけなんだけどね

このスレ見てる経営者からするとビルド時間（タバコ休憩)をもったいないと感じる人もいるかも
2025/05/27(火) 11:17:48.13ID:l+yCcJPm
ミニコンの頃ビール飲みながらコンパイル待ってたじゃん
2025/05/27(火) 11:19:13.09ID:l+yCcJPm
タバコ吸う人インフラエンジニアしか見ないんだけど、そうでもないのね
2025/05/27(火) 11:19:43.03ID:8GpehI+s
バイナリ配布と商用ソフトを偉大にしたけりゃCDかDVDを復活させた方が良い
インターネットではなんでもタダになってしまう
946デフォルトの名無しさん
垢版 |
2025/05/27(火) 11:51:10.73ID:Ct/IM7NE
クロスプラットフォームGUI開発はバッググラウンド知識をもとに選択するべきであって

Javaの知識がある人はJavaFX
C#の知識がある人は
JSの知識がある人はElectronとなるわけで

普通わざわざTauriを使おうとはならんのよね

クロスプラットフォーム要件がないならOSのネイティブ言語を使うべきだし
2025/05/27(火) 12:05:07.63ID:l+yCcJPm
Rustのバックグラウンドがあります✨
2025/05/27(火) 12:19:39.73ID:eeb7u50k
tauri は良くも悪くもウェブブラウザそのものって感じがする。
ただ、単なるインターフェイスというには妙に大きいし、ささいなアプリケーションに使うのはためらうかな。
2025/05/27(火) 12:24:15.21ID:l+yCcJPm
Qtでいいってことかな
2025/05/27(火) 12:51:24.44ID:kFWXS+6w
簡単なツール作るならRustでなくPythonで作った方がいいわな
標準でGUI付いてるし
Rustは速度と安全性が欲しいときに使う
2025/05/27(火) 13:13:58.20ID:V0+A3o/R
Linuxカーネルのコンパイルに一晩かかってた頃が懐かしい
2025/05/27(火) 13:13:59.45ID:i8JhYU/A
>>928
TauriはHTML/CSS/JavaScriptを使ってGUIを組むものでElectronのRust版相当だよ
2025/05/27(火) 13:14:38.90ID:i8JhYU/A
>>948
Tauriはデスクトップアプリだけでなくモバイルアプリも対応でWebアプリ化も容易なメリット
2025/05/27(火) 13:15:32.27ID:i8JhYU/A
>>950
Rustにも各種のGUIクレートがたくさんあるからPythonなんか使う必要ないよ
955デフォルトの名無しさん
垢版 |
2025/05/27(火) 13:21:45.76ID:9DpjiTAd
Rustのクレートはまともに完成していないものが目立つ上、酷い名前のが多くてさらに不安感を煽る
2025/05/27(火) 13:35:17.04ID:bGwStrKb
RustオナニーならTUIが流行りだろ
一般にGUIよりレスポンス悪いからRustの意味があるのか疑問ではあるが、
厨二心が充足されて最高に気持ちいいぞ
2025/05/27(火) 13:37:49.78ID:i8JhYU/A
>>955
他言語と同様ラッパー各種にRust独自の高速GUIまで揃ってるよ
まさか日本語読みで酷いと？？
2025/05/27(火) 13:40:40.33ID:i8JhYU/A
Rust独自で一番人気はこれ
公式サイト デモ
https://www.egui.rs/#demo
2025/05/27(火) 13:45:29.09ID:i8JhYU/A
ちなみにRecent Downloadsは
eguiが200万でtauriが92万
2025/05/27(火) 14:03:02.85ID:/x3zodRx
>>937
そっか、なんか狂気を感じる
2025/05/27(火) 14:08:20.83ID:S0oVRl62
作り比べてみたが、
eguiが一番簡単、複雑なことはしない人向け

icedはある程度簡単で、且つきれいなコードで作れる
Elmアーキテクチャと聞いて何のことか分からん人には向いてないかも
レイアウトがむずい

tauriはクライアント／サーバーな構造なので一番めんどくさい、コード量多いが
HTML/JSに慣れてる人はビューを簡単・きれいに作れるのでよい
鬼門の日本語入力も完璧
2025/05/27(火) 14:18:54.59ID:i8JhYU/A
あと超軽量で組み込みGUIにも使われてるのがこれ
https://slint.rs/
Rust製だけど他言語APIもある
2025/05/27(火) 14:33:25.05ID:DNEfq0T4
>>940
転送量ｗ
発想が貧困だな

>>941
比べるまでもない
2025/05/27(火) 14:53:01.16ID:zMRW8ttb
まともに返してくれる住人のいなくなったスレでIDコロコロして自演する意味ってなんなんです？
2025/05/27(火) 15:05:55.13ID:CzBbszWY
slint はデザインを専用言語で書く形にも出来るので
デザイナーと分業するような組織で使いやすいかも？ 知らんけど
966デフォルトの名無しさん
垢版 |
2025/05/27(火) 15:25:19.57ID:K50j2XjJ
星たちは「音」を奏でていた。楽器のように。歌のように
5/26(月) 19:00配信
https://news.yahoo.co.jp/articles/1996331be041f2656a929fec1ccd595ed3b4a053

量子世界では鏡の中心で本物と鏡像が溶け合う観測不能ゾーンが発生する
2025.05.26 MON
https://nazology.kusuguru.co.jp/archives/178271

1キロ先から「幅3ミリの文字」が読めるレーザーを開発！
2025.05.26 20:00:48 MONDAY
https://nazology.kusuguru.co.jp/archives/178219
2025/05/27(火) 17:53:23.54ID:tnWZCYDJ
>>961,962
日本語入力がまともに出来ないGUIフレームワークは話にならないかな
それとブラウザ系は起動が遅いから起動/終了を気軽にやりたい簡単ツール類では使い勝手が悪そう

ネイティブはもちろん.netでも0.1未満-0.5秒程度で起動するのに普通に慣れているから
https://qiita.com/spc_ksudoh/items/872d452ed42f17489038
2025/05/27(火) 23:03:51.93ID:RyToMqFu
>>967
なぜウソつくの？
日本語入力表示できてるよ
起動も一瞬で表示されるよ
2025/05/27(火) 23:08:09.59ID:RyToMqFu
マジで言ってるならフォント指定してる？例えば
egui::FontData::from_static(include_bytes!("/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc"))
2025/05/27(火) 23:25:04.61ID:IoIeOF9V
「まともな」日本語入力の基準が20-30年前から変わっていないおじいちゃんかな
2025/05/27(火) 23:31:10.76ID:MpKNlfTm
>>967
Rustで日本語入力がまともにできないGUIフレームワークとかあるの？

その記事は計測方法がおかしい
アプリの起動速度はバイナリサイズはもちろん起動したと言える状態になるまでに初期化が必要なオブジェクトの量にもよるのでその両方を考慮できてない計測時間は意図した比較目的に対してはあまり意味がない
Qiitaクオリティなので致し方ないが
2025/05/27(火) 23:32:39.83ID:MpKNlfTm
めっちゃかぶったな

キリル文字でバグるとかならわかるけど
UTF8前提のRustで日本語入力できないとか無いよね
2025/05/27(火) 23:40:00.13ID:Zq2Coxwc
>>967は記事が.Netだから
いつもデタラメにRustを叩いているC#君
974デフォルトの名無しさん
垢版 |
2025/05/27(火) 23:44:53.38ID:1HgS0bJ3
>>971
むしろまともに日本語入力できるのがWeb View系のもの (Tauri, Dioxus) しか無いのが現状だよ
IcedはIME非対応だしeguiはIMEの動作が不安定だし
(Icedは一応、現在の開発ブランチにはミニマルなIME対応が入ったけど)
2025/05/27(火) 23:54:07.86ID:8GpehI+s
iphone以外を選んだらまともではない、みたいな文化はPC界隈にもあったんだな

vimとか好きそうな人達にはそんなの関係ないけどな
976デフォルトの名無しさん
垢版 |
2025/05/27(火) 23:56:34.47ID:z4sj5YQp
eguiで日本語普通に使えてるけどな
2025/05/27(火) 23:59:48.57ID:/Mi05CrC
>>976 がまともなアプリ一つ持って来たら良いだけでは
2025/05/28(水) 00:00:49.05ID:G1B9MT4k
>>976
なるべくIMEの存在なんて知らないアルファベット圏のプログラマ作成の奴で
2025/05/28(水) 00:03:45.01ID:L2SsVN+0
意味不明だ
eguiはRustライブラリ
アプリは各自がRustで書くもの
2025/05/28(水) 00:08:27.36ID:ceBP4SZq
まあ、>>976 が「eguiで日本語普通に使えてる」と言っているから当然アプリの話だから
>>976 が回答を持って来るでしょう
最悪は>>976 作成のミニマムサンプルで良いんだけどね
2025/05/28(水) 00:09:40.64ID:EcrJwz+v
eguiは一応日本語入力できるけど
頻繁にフォーカスがおかしくなったり、カーソル位置が行方不明になって挙動不審
2025/05/28(水) 00:12:43.55ID:ceBP4SZq
>>981
それは「普通」には使えてないから、
それを含めて>>976 が回答を持って来るでしょう
2025/05/28(水) 00:24:11.95ID:EcrJwz+v
RustのGUIライブラリは、速度やクロスプラットフォームで欲張りすぎて
GPUで独自描画した結果、日本語入力がダメになってる
2025/05/28(水) 00:24:36.90ID:xa/gMZP3
>>981
フォーカスがおかしくなるの意味がわらん
egui使ってるが他GUI同様にTABやマウスでフォーカス動くぞ
2025/05/28(水) 00:27:19.17ID:xa/gMZP3
>>983
日本語入力がダメになってるとは聞いたことはなく遭遇したこともない
具体的に示してくれ
986デフォルトの名無しさん
垢版 |
2025/05/28(水) 00:40:27.44ID:62gl2JJ5
alacrittyってRust製のターミナルエミュレータがあって
それが数年前まで日本語入力できなかったのは知ってる
今は普通に使えるけどな

それ以外になんかあるの？
2025/05/28(水) 00:45:01.33ID:xa/gMZP3
返答もなくアンチの妨害デマっぽい
もし仮に不具合が残ってたらこれまでに大騒ぎになってる
2025/05/28(水) 00:45:54.75ID:jV0wUpuO
>>985
>>983じゃないけど egui/crates/egui_demo_app/ をビルドして
TextEditを追加してIMEで日本語入力しようとしたら
① カーソル位置には文字化けした□
② カーソル位置とは別に、変換前文字のエコーバックがあらぬ位置に出現したりしなかったり不安定
③ IME変換候補一覧で候補をエンターで確定したら改行も入力される
④ IME変換候補一覧で候補をタブで補完確定しようとしたらフォーカスがあらぬ所に飛んで入力出来ない

ここでやる気が無くなった
2025/05/28(水) 00:48:03.81ID:jV0wUpuO
>>969
①は特定言語のフォント指定ではなくフォントフォールバックが働くべき
2025/05/28(水) 00:49:38.46ID:jV0wUpuO
絵文字のグラフィームクラスタがクラスタになってない
2025/05/28(水) 00:50:46.21ID:jV0wUpuO
>>984
人をアンチ呼ばわりする前に、ご自身で試しましょう
2025/05/28(水) 01:00:12.53ID:xa/gMZP3
>>991
eguiで社内アプリなどを作って使ってるが日本語で問題が出たことはない
2025/05/28(水) 01:01:43.97ID:AxVmY89D
>>974
へぇー結構大変なんだな

https://github.com/emilk/egui/issues/248
https://github.com/rust-windowing/winit/issues/1497

https://github.com/iced-rs/iced/issues/979
https://github.com/iced-rs/iced/pull/686
https://github.com/iced-rs/iced/pull/2777
2025/05/28(水) 01:06:17.17ID:AxVmY89D
こういうのって標準的な動きでよければ各OSがそれぞれよろしくやってくれる仕組みを用意してくれてるものだと思ってたわ
2025/05/28(水) 01:08:15.24ID:nr9lvOtu
>>994
GPU独自描画せず、Windows APIでやってたらね
2025/05/28(水) 01:08:58.24ID:xa/gMZP3
>>993
一番上のリンク
eguiは3年前に各OSのIME対応完了とある
現在eguiで日本語は全く問題がない
2025/05/28(水) 02:43:19.85ID:cnfz+Pi9
IMEでissue検索してみれば？

デグレしても気がつかないくらいのテスト体制しかないみたいだし
低品質でも許される実験的アプリでもなければ実戦投入は時期尚早だな
2025/05/28(水) 06:41:49.30ID:3diyko22
不具合は昔の話
今は安定して幅広く使われており
eguiはRustのGUIクレート人気トップ独走
2025/05/28(水) 08:16:12.15ID:c8vE5sdJ
linuxコマンドの作り直しにguiなんて使わないだろ
1000デフォルトの名無しさん
垢版 |
2025/05/28(水) 08:33:59.43ID:d5fn07f2
【悲報】財務省、廃棄したはずの森友文書を別の開示請求でうっかり開示してしまう🥺 [928380653]
2025/05/25(日) 14:40:21.21
https://hayabusa9.5ch.net/test/read.cgi/news/1748151621/

第三者委員会「エロ小説漏洩は斎藤知事の指示の可能性が高い」 [595582602]
2025/05/27(火) 14:50:41.31
https://hayabusa9.5ch.net/test/read.cgi/news/1748325041/

元総務部長が裏切り「斎藤知事に指示されてやった」　斎藤兵庫オワコン逮捕😭 [659060378]
2025/05/27(火) 23:30:03.48
https://hayabusa9.5ch.net/test/read.cgi/news/1748356203/

立花孝志　業務上横領の疑いで刑事告訴　警視庁が受理（画像あり） [659060378]
2025/05/27(火) 21:37:55.62
https://hayabusa9.5ch.net/test/read.cgi/news/1748349475/
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 25日 7時間 46分 30秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。

▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/

▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login
レス数が1000を超えています。これ以上書き込みはできません。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況