Rust part29

**デフォルトの名無しさん** · 2025/05/05(月) 11:44:04.39

>>165
知らんがな
俺は必須パラメータの問題を指摘している

**デフォルトの名無しさん** · 2025/05/05(月) 11:44:39.10

>>162
p[0]やp[1]など
可読性の悪いコードを書くやつは失格
p.red p.green p.blueにしろ

**デフォルトの名無しさん** · 2025/05/05(月) 11:45:55.35

>>167
dataと言うバイト列の中の一部だとしたら？

**デフォルトの名無しさん** · 2025/05/05(月) 11:47:59.01

>>166
おっちょこちょいだな
直前のこれを見ろ
必須ではなくオプションパラメーターだ

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

**デフォルトの名無しさん** · 2025/05/05(月) 11:50:23.87

>>168
バイト列？
各8bitなのか各16bitなのかそれ以上なのかそれでは構造がわからん
ちゃんと構造体の列にするべきだ

**デフォルトの名無しさん** · 2025/05/05(月) 11:54:15.50

>>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.27

>>171
あのさ
Rustでプログラミングしたことないの？
Rust以外でもシリアライズとデシリアライズしたことないの？
まともなプログラミングしたことある人ならRustですぐにserdeにたどりつく

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

まともな人が言ったのか人形が言ったのか全然わからない時代だ
人形が言ったにすぎないなら、そんな言葉は存在しないのと同じ

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

>>172
お前はわざと議論のための議論してるだけだろ
通常のコーティングで出てくるであろう例を誤魔化している

**デフォルトの名無しさん** · 2025/05/05(月) 12:16:46.89

p[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのためにどれだけコーディング量を増やして
ライブラリ依存させていくのか
本当に意味不明

**デフォルトの名無しさん** · 2025/05/05(月) 12:33:03.95

>>175
そんな可読性が悪くてミスしやすいプログラミングは避けるべきだ
構造化と抽象化が不得手でプログラマやエンジニアに向いてないな
serdeは構造体に#[derive(Serialize, Deserialize)]など付加するだけでデシリアライズ関数などは自動生成される

**デフォルトの名無しさん** · 2025/05/05(月) 12:57:25.54

>>176
構造体にって自分で書いてるだろ
単なるバイト列からp[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのために構造体などを作らないといけない

**デフォルトの名無しさん** · 2025/05/05(月) 13:06:55.72

p[ i+0/*0=赤*/ ],p[ i+1/*1=緑*/ ],p[i +2/*2=青*/ ]
俺ならこうするよ
コメントを見れば0が赤、１が緑、２が青と見たん瞬間わかる
日本語なので英語より間違えにくい
もし間違った数字が間違ってたらコメントと比べればすぐわかる

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

（言語を強化することにより）アプリのコーディング量を減らせという話はなかなか面白い
言語の数がアプリの数より多い気がする原因はこれかもしれない

**デフォルトの名無しさん** · 2025/05/05(月) 15:35:05.95

>>174
議論のための議論をしてるのはお前だろ
それともガチで何も意味を読み取れないインデックスアクセスが正義と思ってるわけ？
どんなみじめな経験を積んできたんだよ
害悪プログラマすぎて仕事で関わらないことを願うわ

**デフォルトの名無しさん** · 2025/05/05(月) 15:41:59.59

議論とは関係ないけど大体の画像処理ライブラリだとRGBもBGRも扱えるように channel[0], channel[1], channel[2] のようにアクセスさせると思う
内部のデータによって channel 数は1や4 (アルファチャネル付き) もあるし

**デフォルトの名無しさん** · 2025/05/05(月) 16:02:16.97

仕事はお金を貰ってやることだから丁寧に書いて上司に褒められる必要があるけれど
趣味とか経営者とかなら何を書いてもじゆうなんだよな

**デフォルトの名無しさん** · 2025/05/05(月) 16:11:32.03

簡潔で見にくいコードを書くか
冗長で醜いコードを書くか
２択だな

**デフォルトの名無しさん** · 2025/05/05(月) 16:35:32.16

>>181
これはそう
画像に限らず構造化されたバイナリデータを扱うときに一般に言えることだけど、
単純にビット列をそのまま構造体として読み替える間違いは、低水準に踏み込める言語に入門して調子乗ってる初心者がやりがち

**デフォルトの名無しさん** · 2025/05/05(月) 16:47:29.64

上司はunsafeの箇所をチェックすればいいのに
コンパイラが自動で調べてエラーがなかった箇所を、手動で調べ直して逆張りするのが胡散臭い

**デフォルトの名無しさん** · 2025/05/05(月) 18:15:43.01

Serdeは暗黙のCopyしがち

**デフォルトの名無しさん** · 2025/05/05(月) 18:29:47.69

>>180
８０代のおじいさんと仕事をする機会はないかな

**デフォルトの名無しさん** · 2025/05/05(月) 22:23:21.43

話を整理すると

>>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.48

さらに

>>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.22

構造体は
foo{green:green,blue:blue}
を
foo{green,blue}
と描ける訳で
ビルダーメソッド方式とやらも
foo().green().blue()
的に描ければ無駄が減るから改良してくれんかのぅ

**デフォルトの名無しさん** · 2025/05/05(月) 23:13:19.16

>>189
その大量連投していた彼はRustをほぼ知らないと判明した上に他の言語の経験値も低そうなので彼自身に問題があることを理解できないと思う

**デフォルトの名無しさん** · 2025/05/05(月) 23:39:40.43

その連投してスレを荒らしていた人が
「おじ」「複おじ」「おじいさん」「おじいちゃん」使いの人だったとはね
>>61 >>70

**デフォルトの名無しさん** · 2025/05/05(月) 23:42:50.66

foo().(green).(blue)
でもいいな

**デフォルトの名無しさん** · 2025/05/05(月) 23:55:27.76

RustはJavaよりも構造体リテラルの表記が強力だから
Builder使うよりOptions構造体１つで渡す方が楽かもしれんね
パターンとしてはBuilderよりマイナーだけど

**デフォルトの名無しさん** · 2025/05/05(月) 23:58:49.46

>>190
引数なしで何を指定するのか？

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

どんな方式を取ろうとも大元の変数(ex. rgbやp)は指定せざるをえない
foo().green(rgb).blue(rgb)

**デフォルトの名無しさん** · 2025/05/06(火) 09:36:09.23

>オプション引数やキーワード引数については他言語が内部的にやってることをRustの場合は開発者が自分でやらなきゃいけないことになっててバカらしい

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

これに尽きる
言語に機能が不足してるから何でもかんでもビルダーパターンにしなきゃいけなくてサードパーティのマクロに依存することになる
アホらし

**デフォルトの名無しさん** · 2025/05/06(火) 09:48:17.91

>>196
真逆だろ
キーワード付オプション引数をズラズラ並べた長い長い関数シグニチャはデメリットしかない欠陥品
しかも機能拡張したらさらにキーワード付オプション引数が増えて関数シグニチャが変わるアホらしさ

**デフォルトの名無しさん** · 2025/05/06(火) 09:51:10.91

複数IDと口調を使い分けて自分のレスに賛成するキチガイが複おじ

**デフォルトの名無しさん** · 2025/05/06(火) 09:51:38.50

Rustのダサい処は認めるべき

**デフォルトの名無しさん** · 2025/05/06(火) 09:56:28.46

>>197
ビルダーパターンは30年以上前から知られていたけどあまり有用ではないので使われていない
過去に誰かがざっくりデザインパターンを否定してたけど、その人の言うにはデザインパターンで有用なものは言語自体に取り込まれるはずだと

実際いくつかは新しい言語では取り込まれている

**デフォルトの名無しさん** · 2025/05/06(火) 09:56:50.79

マクロで解決可能なんだろ？それは「不足している」のか？
まあ標準ライブラリとして入っているべきみたいな論はあるかもしれんけど、マクロでの解決が悪くて言語機能として直接サポートするのが良いとする根拠は出てないな。

言語ユーザがそれぞれのやり方で解決できる自由さと言語の方針を強制する一貫性は両立しないがそれぞれに良さはあるし、 Rust は今のところ自由さをとりつつもデファクトな地位のライブラリはあるという状況だ。
手頃な妥協点と言えるだろ。

**デフォルトの名無しさん** · 2025/05/06(火) 10:01:33.47

些細な内容なら初期化関数を複数作ればよい話で更に多くなればオプション指定する構造体を作ればよい
mutに拘る必要が無ければさらに多くの可能性がある

わざわざ穴の多いビルダーパターンを使う必要はない

**デフォルトの名無しさん** · 2025/05/06(火) 10:08:26.28

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

マクロで抽象化されてるならその実装がビルダーパターンでもそうでなくてもどうでもいいよ。

**デフォルトの名無しさん** · 2025/05/06(火) 10:10:04.33

>>202
初期化関数を複数作るとオプション分の組み合わせ爆発となる一番アホな方式
それならビルダー方式がよい

**デフォルトの名無しさん** · 2025/05/06(火) 10:12:49.15

>>204
他の言語では大体オーバーロードでオプション指定しているけどそれが馬鹿だとは思わないけどね

**デフォルトの名無しさん** · 2025/05/06(火) 10:15:57.89

>>205
それはオプションが増えると組み合わせ爆発が起こる馬鹿な方式

**デフォルトの名無しさん** · 2025/05/06(火) 10:17:10.44

>>206
同じ主張と文章を繰り返すやり方が複おじそっくりですね

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

例えば基本的に2つだけ引数があって後はオプションがずらずら並ぶならやはりオプション内容を含む構造体渡せばいいと思う
そちらも設計が必要だけど

**デフォルトの名無しさん** · 2025/05/06(火) 10:18:50.49

>>205
それ以前にオーバーロードは欠陥機能
オーバーロードを使うとred,green,blueのオプション実装すらできない

**デフォルトの名無しさん** · 2025/05/06(火) 10:19:38.79

>Rust のマクロは彼の言う本物のマクロ

macro_rules! は偽物のマクロ
proc_macro2 が本物のマクロ

**デフォルトの名無しさん** · 2025/05/06(火) 10:20:41.45

普通は書き込み内容が単調にならないように人は文章に揺らぎをいれてくるんだけど
複おじは基本全部同じ

口調を変えても同じなので同一人物なんじゃないかと思って見ていると後で全く同じ書き込みを始めるので同じ人間なんだなと

**デフォルトの名無しさん** · 2025/05/06(火) 10:20:45.54

>>209
どちらも本物だ
衛生マクロの概念すら知らないのか？

**デフォルトの名無しさん** · 2025/05/06(火) 10:20:58.22

>>208
何の問題もないと思うが、具体的には？

**デフォルトの名無しさん** · 2025/05/06(火) 10:22:59.33

本物のマクロと言う主張は面白い

でライブラリ作成者ではなく一般的なユーザ側が書いてるマクロはどっちなのかと

**デフォルトの名無しさん** · 2025/05/06(火) 10:23:21.48

>>212
オーバーロードの制限を知らないのかね？
red,green,blueそれぞれだけを指定したい関数をオーバーロードで書いてごらん

**デフォルトの名無しさん** · 2025/05/06(火) 10:24:49.05

>>213
衛生的なマクロとは何かを勉強するといいよ

**デフォルトの名無しさん** · 2025/05/06(火) 10:24:50.06

オーバーロード自体は良い仕組みだと思うけど設計が必要だ
最近の言語が取り入れていないのはヒューマンエラー対策という名目

だったらビルダーパターンもヒューマンエラー対策で禁止になるかと言えばそうでもない

**デフォルトの名無しさん** · 2025/05/06(火) 10:27:37.75

>>216
オーバーロードは最悪な仕組み
欠陥が多すぎる上に
red,green,blue各オプションしてすら実現できない

**デフォルトの名無しさん** · 2025/05/06(火) 10:28:08.85

徐々に文体におじいさんぽさが出てきたね

**デフォルトの名無しさん** · 2025/05/06(火) 10:47:02.68

AIを屈服させるレベルの改善ができるなら改善してもいいけどね
どうせAIが勝つという前提なら何も修正しないのが合理的だ

**デフォルトの名無しさん** · 2025/05/06(火) 10:51:59.27

今の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.53

>>209
本物のマクロというのが何であるか明瞭な定義はされてないのだが、文脈的に「構文木の操作が出来る」というのが要件だと一般的に解されている。
トークン単位の置き換えしか出来ない C のマクロのようなものを除外するための言い回しだ。
構文木を操作できるなら操作できる範囲の違いは本物のマクロかどうかには重要ではない。
(もちろん出来ることが多いほうがより良い本物のマクロとは言えるだろうが、出来ることが多いほうが危険な間違いも引き起こしやすいので現実には適度に制限があったほうが良いこともある。)
macro_rules! も普通は本物のマクロと解される。

**デフォルトの名無しさん** · 2025/05/06(火) 11:06:32.44

リスパーはmatchを知らない

matchを知らなくても理解できるマクロが本物のマクロ

**デフォルトの名無しさん** · 2025/05/06(火) 11:11:44.35

複数ID使用おじ

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

複おじはそういうのに反論しない仕組みになっている

**デフォルトの名無しさん** · 2025/05/06(火) 11:19:55.25

>>214
ヒント:
struct Red(u8);

**デフォルトの名無しさん** · 2025/05/06(火) 11:20:28.10

マクロ自体がただの似たような機能の概念の総称であってその中で本物だ、元祖だと言っても笑われるだけ
キーボードマクロは真のマクロではないとか衛生的ではないと言われてもそうですかと

**デフォルトの名無しさん** · 2025/05/06(火) 11:22:58.43

ID:j5CJU7Aq　　の反応待ちのawait状態です

**デフォルトの名無しさん** · 2025/05/06(火) 11:23:42.97

>>223
複OGはどうでも良いけど
5chはもう禿しく過疎ってるのにこのスレだけやけに延びてるのは不自然だと感じる

**デフォルトの名無しさん** · 2025/05/06(火) 11:31:04.25

>>225
「本物のマクロ」というのは正しさとか起源を主張しているわけではなくそういう名前の分類。
少なくとも C のマクロなどでは様々なイディオムを抽象化するには不十分だというごく当然の話をしてる。

**デフォルトの名無しさん** · 2025/05/06(火) 11:33:12.59

なお、名前付き引数での呼び出しを前提とするならばhoge(red) と hoge(green)を名前付き引数の引数名だけで呼び分けるオーバーロードは技術的には実装できない理由は特にない
しかし、多くの言語では名前付き引数の使用はオプションだしこの場合はhoge_red(val)のように機械的に名前変えりゃいいだけだから、実装コストに見合わないという判断をされているのだろう

**デフォルトの名無しさん** · 2025/05/06(火) 11:39:56.59

>>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.17

メリットが不確実なだけでしょ
メリットもコストも確定していてなおかつ見合わないという話ではない

**デフォルトの名無しさん** · 2025/05/06(火) 12:18:40.67

このスレでずっと自演してる人って糖質とかなんだろうなあ

**デフォルトの名無しさん** · 2025/05/06(火) 12:28:45.22

traitで騒いでた自演と同じ人だろう

**デフォルトの名無しさん** · 2025/05/06(火) 12:40:06.43

オーバーロードはそもそもCのAPIにありがちな、後で〇〇2だの〇〇exだのが増えて格好悪くなる問題を解消するためのもの
後で引数名だけ異なるオーバーロードが増えたら名前付き引数を使っていない既存の呼び出しがエラーになるのは、互換性維持という本来の目的からすれば論外

**デフォルトの名無しさん** · 2025/05/06(火) 12:49:02.99

話題の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.48

>>235
よくない
散々言われている通り、必須属性の設定を忘れると実行時エラーになるという致命的な問題がある

**デフォルトの名無しさん** · 2025/05/06(火) 13:06:06.15

>>236
例えばファイル名を打ち間違えちゃったけど
まずリリースモードの前にデバッグモードの時点で実行時エラーで気付いて
直してしまえばそれ以降は大丈夫と同じじゃないのかな
特に問題ないような

**デフォルトの名無しさん** · 2025/05/06(火) 13:10:03.39

補足するとファイル名は必須項目だけど
コンパイル時にチェックできるのは型だけだから現実的にチェックできることはほとんどないよね

**デフォルトの名無しさん** · 2025/05/06(火) 13:16:05.70

お前らめちゃくちゃ暇人だな
レス多すぎ

**デフォルトの名無しさん** · 2025/05/06(火) 13:18:37.75

>>201
>マクロで解決可能なんだろ？
ビルダーパターンの手書きコード量を多少なりとも削減したいという問題は解決してるかもね
それが本当に解決したい問題だと思ってるのならそれでいいんじゃない

**デフォルトの名無しさん** · 2025/05/06(火) 13:24:33.64

ビルダー方式でも他の方式でもなんでもいいけど
初期化のための関数を自分で書くよりも>>235のように構造体への属性マクロ指定だけにするのがいいと思う
面倒がなくコードがすっきりとしてプログラミングミスも起きないから

**デフォルトの名無しさん** · 2025/05/06(火) 13:44:43.14

>>238
それはそうなのだけど、だからといってコンパイル時のチェックを安易に諦めたら、極論Cでいいだろって話になっちゃう
Rustの存在意義が問われる危険な思想

**デフォルトの名無しさん** · 2025/05/06(火) 13:46:48.63

現時点のderive_builderはFooBuilder::new()に必須項目を渡すパターンには対応してないっぽいな
全部default()でも構わないケースだと使えるけどRegexBuilder::new(pattern)みたいなケースもあるから万能ではない

**デフォルトの名無しさん** · 2025/05/06(火) 13:53:00.39

良い例があるな
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.28

>>244
例えば
このように
もちろん
そこで
一方で
以上は
もちろん
さらに
これらも
ちなみに

そのx　から始まって論理的？接続で参照を握ったままで最後まで離さないな
読みにくいのは当然

**デフォルトの名無しさん** · 2025/05/06(火) 14:26:52.22

id変わってしまった

**デフォルトの名無しさん** · 2025/05/06(火) 14:30:10.65

上の強烈な接続もビルダーパターンの一種かな？と思ってしまう

**デフォルトの名無しさん** · 2025/05/06(火) 15:04:10.81

>>242
忠臣蔵みたいに、諦めたふりをするぐらいがちょうどいい
危険思想？
なんのことやら

**デフォルトの名無しさん** · 2025/05/07(水) 00:06:42.37

>>245
複おじ語録よくぞまとめてくれたな
ほめてつかわす

**デフォルトの名無しさん** · 2025/05/07(水) 10:19:22.81

後から〇〇2や〇〇exが増える問題ってRustだとどう対処するのが一般的なんだろう
まあRustの場合ABIを維持する必要のあるケースは比較的限られてるけど、引数増やしたら既存のソースは壊れるよね
最初から構造体にしておけというのは意味のない意見なので無しで

**デフォルトの名無しさん** · 2025/05/07(水) 10:32:45.05

普通に関数が増える

**デフォルトの名無しさん** · 2025/05/07(水) 10:59:58.84

>>250
ダイナミックリンクで提供する場合はバイナリ互換性が必要な場面も多いのは Rust でも変わらないよ。
言語の文化としてはスタティックリンクを使いがちではあるけど。
ダイナミックリンクは OS の機能なので言語の側からどうにか出来る余地も少ないし、 OS の文化に乗っかるしかない。

**デフォルトの名無しさん** · 2025/05/07(水) 11:36:16.32

○○exがある言語でJVMを実装し、○○exに依存してないと主張する

**デフォルトの名無しさん** · 2025/05/07(水) 13:51:32.15

Ubuntu 25.10から、sudoがsudo-rsに置き換わるそうだ

**デフォルトの名無しさん** · 2025/05/07(水) 14:09:26.72

まあ Rust が良いかどうかはともかくたまには刷新したほうがええやろ。

**デフォルトの名無しさん** · 2025/05/07(水) 14:24:28.93

いや、sudoのようなパフォーマンスが重要でないコマンドなら
RustではなくGoで書くべきだった

**デフォルトの名無しさん** · 2025/05/07(水) 14:25:34.83

どんなものでも機能も速さも同じだとしても
C/C++製よりRust製を選ぶわ
C/C++のせいでのセキュリティホールが後からいくらでも見つかってる現状

**デフォルトの名無しさん** · 2025/05/07(水) 14:27:05.51

>>256
余分なランタイムが必要なGoはありえない

**デフォルトの名無しさん** · 2025/05/07(水) 14:50:13.61

>>250
外部ライブラリならメジャーバージョン増やして普通に破壊する
旧バージョンのAPIをcompatモジュールとかに入れとけば親切

標準ライブラリはエディションで切り替える形になりそう
std::preludeのサブモジュール名は最初v1だったけど今はrust_20XXに方針転換してる
グローバルな名前の追加も一種の破壊だし

**デフォルトの名無しさん** · 2025/05/07(水) 15:20:58.49

下記は全て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.88

モダンなライブラリはdeprecateしやすいのか
古いCと最新のRustだけが残されて中途半端な時代は無かったことになりそうだ

**デフォルトの名無しさん** · 2025/05/07(水) 19:03:14.70

いや、利用者が少ないうちに直しとけ心理で、どんな技術も通る道だよ
sudo-rsがいい例だがこういう長期間にわたって重要な役割を果たす、かつあまり変更が必要とされない用途が増えてくると、だんだんと進化は遅くなるものだ

**デルフォトの名無しさん** · 2025/05/07(水) 19:08:29.35

>>257

(´・ω・)マジ？

**デフォルトの名無しさん** · 2025/05/07(水) 22:26:25.21

>>254
この国際的なプロジェクトでセキュリティ的に重要なものから順にRust化されていく一環だよ

Memory Safety for the Internet's most critical infrastructure
https://www.memorysafety.org/

**デフォルトの名無しさん** · 2025/05/08(木) 09:08:51.16

>>244-245
このように.drop();
もちろん.drop();
そこで.drop();
一方で.drop();
以上は.drop();
もちろん.drop();
さらに.drop();
これらも.drop();
ちなみに.drop();

**デフォルトの名無しさん** · 2025/05/08(木) 09:25:34.07

ubuntuはsudoだけでなく、cp, ls, find, diff なんかもRust化する予定なんだな
ntpdもRust化が進められてる

**デフォルトの名無しさん** · 2025/05/08(木) 09:33:12.04

>>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.03

>>266
Ubuntuに限らず誰もが全てをC/C++製から安全なRust製へ変えたいと思っているが一気には無理なので重要なものや新たなものからRust採用という感じ

**デフォルトの名無しさん** · 2025/05/08(木) 12:25:36.55

全てを変えたい、とかいうビジョンは無意味
意味のないビジョンだよ

**デフォルトの名無しさん** · 2025/05/08(木) 12:38:14.55

安全でないC/C++を早く全廃したい世界の流れ

**デフォルトの名無しさん** · 2025/05/08(木) 12:49:37.23

Linuxコマンド開発専用言語Rust

**デフォルトの名無しさん** · 2025/05/08(木) 12:51:53.54

メンテナ高齢化問題の対策としては良い取り組みなんじゃないかな
作業するのもインターンの学生が中心だろうし

**デフォルトの名無しさん** · 2025/05/08(木) 12:55:02.85

多くのシステムやインフラがRust化してるね
この5chが使ってるCloudflareもRust製へと移行した
https://github.com/cloudflare/pingora

**デフォルトの名無しさん** · 2025/05/08(木) 13:05:00.97

コマンドツールがRustになってもAPIがRust用じゃない限り
CのAPIのラッパーでしかないけどそういう造りでもRust化したってカウントして良いのかは疑問

**デフォルトの名無しさん** · 2025/05/08(木) 13:09:51.90

>>274
コマンドツールが誰に対するAPI？？
プログラムを書いたことないのかな？

**デフォルトの名無しさん** · 2025/05/08(木) 15:06:07.28

こういうのってFedoraやらArchやらGentooあたりが人柱やってから普及していくものだと思ってたが…
Canonicalのくせに思い切ったことするなあ

**デフォルトの名無しさん** · 2025/05/08(木) 15:26:10.55

Ubuntuはカジュアル路線でしょ
初期状態だとrootも使えなかったと思う
他よりもsudoの負荷が大きい

**デフォルトの名無しさん** · 2025/05/08(木) 18:54:46.08

5chは真の漢が使う言語perlで書かれている

**デフォルトの名無しさん** · 2025/05/08(木) 21:50:58.54

5chはperlだけでなくサーバも貧弱なのでキャッシュしてくれるCDNに頼らないと成り立たない
5chが利用しているCDNは>>273のCloudflareでRust製だよ

**デフォルトの名無しさん** · 2025/05/09(金) 00:22:05.59

>>279
誰が見てもただの印象操作
子供でも分かる

**デフォルトの名無しさん** · 2025/05/09(金) 00:29:31.48

5chどうこうよりも
インターネットを支えるCDN世界トップシェアのCloudflareがRust化したインパクトが大きいよな

**デフォルトの名無しさん** · 2025/05/09(金) 00:31:49.35

そういう幼稚な書き込みはやめとけよｗ

**デフォルトの名無しさん** · 2025/05/09(金) 07:07:43.56

もう見抜けない、最先端のAIディープフェイク動画は心臓の鼓動まで再現、判別が困難に
2025-05-08
https://karapaia.com/archives/507859.html

**デフォルトの名無しさん** · 2025/05/09(金) 08:08:28.79

クラウド界トップのAWSもRust製に

**デフォルトの名無しさん** · 2025/05/09(金) 10:14:04.36

AWSのプラットフォームはほぼJavaでしょ
ハードウェア寄りのローレベルな部分だけシステムプログラミング言語を使っていて、更にその中の一部でRustを使っているものもある、という程度

**デフォルトの名無しさん** · 2025/05/09(金) 11:14:51.12

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.85

大半は既存のソフトウェアの組み合わせなんで、仮に自社内で書いているプログラムの全てを Rust で書いても割合としては数割ってところだろう。
ただ、これから割合が増えることはあっても減りはしないとは思う。

**デフォルトの名無しさん** · 2025/05/09(金) 11:50:43.35

Rustがこのままオワコンになったら撤廃もあり得るだろ

**デフォルトの名無しさん** · 2025/05/09(金) 11:56:12.65

AWSもRust製か
Rust製のクラウドとJava製のクラウドが競争したらJava側が100%負けるだろうしな

**デフォルトの名無しさん** · 2025/05/09(金) 12:53:15.09

クラウドってなに？
ハイパーバイザがrustで作り直されたの？

**デフォルトの名無しさん** · 2025/05/09(金) 14:06:44.17

>>286
これは誤訳
原文だと、それらのサービスにRustを使っていると書かれているだけ
RedditなんかでAWS社員のコメントとか探してみりゃわかるが、AWSは基本Java

**デフォルトの名無しさん** · 2025/05/09(金) 15:01:02.33

エネルギー効率に劣るJavaなんかで構築していたら笑うわ
>>286でもそう書いてるよな

**デフォルトの名無しさん** · 2025/05/09(金) 15:25:02.70

Rustって人気なのね
AIにC#から移植できる？って聞いてみたらいやだって言われちゃったからRustが広まるの、なんか困る

**デフォルトの名無しさん** · 2025/05/09(金) 15:30:45.33

JVM前提な特殊環境を除き
Rustの登場でJavaを使う意味は全くなくなった

**デフォルトの名無しさん** · 2025/05/09(金) 15:41:48.51

何の前提も縛りも無い環境こそが特殊

**デフォルトの名無しさん** · 2025/05/09(金) 15:59:06.67

コンテナ化は Java の有力なメリットだったけど Docker の隆盛で様変わりしちゃったね。

**デフォルトの名無しさん** · 2025/05/09(金) 18:53:55.90

>>293
いやだと言うAI、なんかいいな

**デフォルトの名無しさん** · 2025/05/09(金) 22:11:52.71

>>291
サービス提供には安全性が一番重要なのでC++ではなくJavaを採用していた
Javaより安全で性能の良いRustが出現したため切り替えた
そしてAWSが発起人となってRust Foundationを設立した

**デフォルトの名無しさん** · 2025/05/10(土) 00:48:13.31

Rustで戦う領域ではない気もするけど、エンタープライズ向けはまだ弱いと思う
ここはまだJavaや.NETの資産が大きい

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

規模としては相対的に小さくなってるけど、こういうのが必要な領域は普通にあるし、Javaが消えることは無いと思う

**デフォルトの名無しさん** · 2025/05/10(土) 01:05:07.51

>>299
外部ライブラリ無しで揃ってるという発想が頭おかしい
そんな間違った奇妙な視点を持ってしまうとRustには正規表現も乱数も何もかも存在しないことになるぞ
考えを改めなさい

**デフォルトの名無しさん** · 2025/05/10(土) 01:42:38.39

ここでグチャグチャ言ってる間に徐々に置き換わって行きそうだな

**デフォルトの名無しさん** · 2025/05/10(土) 03:04:27.68

firefoxが全部Rustに置き換わるのに100年ぐらい掛かりそうだけどな

**デフォルトの名無しさん** · 2025/05/10(土) 03:26:38.07

止まってるFirefoxより
ChromeとIEが着々とRust化を進めてるから先だろな

**デフォルトの名無しさん** · 2025/05/10(土) 08:39:56.30

IE?

**デフォルトの名無しさん** · 2025/05/10(土) 08:45:29.97

>>300
何でこいつ偉そうなんだ？

**デフォルトの名無しさん** · 2025/05/10(土) 08:47:09.62

>>299
人月業界は考えるだけ無駄として、SaaSだと新規開発は圧倒的にフルスタックTypeScriptが多いね
Rustは海外では革新的なDB作るぜみたいなエンタープライズの基盤系スタートアップでの採用例は見かけるが、国内ではその手のスタートアップは皆無に近いから絶望的な状況

**デフォルトの名無しさん** · 2025/05/10(土) 09:09:05.25

品質に関する考え方は良い要素を揃えれば良くなるという単純なものじゃないよ。
結局のところ、どんな問題が出てくるかは事前にわからない。
出てきた問題に対処し続けるという歴史によって品質が作られるんだ。
確かに C や C++ に比べて Rust は全面的に良いけれども、活発な巨大プロジェクトではもう問題に対処しつくしていて Rust に置き換えるメリットは相対的に小さい。
部分的に Rust に置き換えることはあっても問題が起こってない箇所まで含めて全面書き換えを目指すのは割に合わない。

**デフォルトの名無しさん** · 2025/05/10(土) 09:11:51.42

>>306
サーバーサイドでTypeScriptを使っているようでは負けるわ

**デフォルトの名無しさん** · 2025/05/10(土) 09:22:18.39

>>308
「負ける」というのは何において？
Rustで実装すると、そのサービスは使いやすくなったり、機能豊富になったり、プロトタイプを高速に作ったり、ユーザーの要望をより速く実現できたりするの？

勝ち負けが決まるのって、サービスの内容、ユーザー体験、リリース速度などが重要で、それを実現できるなら言語自体はさほど重要でない
TypeScriptはエコシステムが充実してるから、それに乗っかるのは一つの選択
(バックエンドTSはつらい点もあるから、他の技術を持ってるところなら他のものの方が良いと個人的には思うけど、そういう選択肢が世の中にあって割と普通に受け入れられてるのは現実として理解してる)

**デフォルトの名無しさん** · 2025/05/10(土) 09:29:02.26

>>307
未だにC/C++が原因のセキュリティ脆弱性報告が常に何件も出続けている現実を見なきゃ

**デフォルトの名無しさん** · 2025/05/10(土) 09:43:16.06

>>309
それらの点ではどの言語でもほとんど同じだね
遅くてメモリも喰うJS/TSをフロントエンド以外で使うのは適材適所ではないから不利だけど

**デフォルトの名無しさん** · 2025/05/10(土) 09:49:57.08

仮に外部ライブラリを使ってもRustはエンプラには向かないでしょ
この分野はオラクルやMicrosoftのような企業が時間かけて作ったきたからできたもので、現状Rustはこの分野向けのライブラリが充実してるわけでもないし、Rustコミュニティが力を入れるとも思えない (したとしても優先度は低い)

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

低レイヤやWebバックエンドなど、Rustが強みになる分野があるのはその通り

**デフォルトの名無しさん** · 2025/05/10(土) 09:51:04.61

>>310
それでも何十年もc++が捨てられずに使われているのはなぜかと考えたことはないのか？

**デフォルトの名無しさん** · 2025/05/10(土) 09:52:37.21

ひらがなカタカナ交じりの自然なソートなんて
今更Rustで描いても半日もかからんやろ

**デフォルトの名無しさん** · 2025/05/10(土) 09:57:05.62

c++はrustに勝てる点が全くなく既存資産だけが頼みの綱で終わりでしょう
巨大な既存資産だけは消えるまでに時間がかかることでしょう

**デフォルトの名無しさん** · 2025/05/10(土) 10:00:12.38

超超超熟練度が必要なCOBOLになる

C、C++、COBOL　まとめてC*

**デフォルトの名無しさん** · 2025/05/10(土) 10:05:17.70

>>314
漢字も当然含むし、ロシア語や中国語などを含む世界の多数の言語にも対応する必要もあるぞ？
時刻や日時の表記も国によって違う
Javaや.NETはランタイムが大きいと言われるけど、その中にはこういうのも含まれる
手間も大きいし、この分野を再実装するのも面倒でしょ
(自分が知らないだけで、既にそういう取り組みがあるのかもしれないけど)

**デフォルトの名無しさん** · 2025/05/10(土) 10:08:42.67

.NETでソートサーバを作ってそれにソートさせて結果をrustで使う

**デフォルトの名無しさん** · 2025/05/10(土) 10:09:24.80

日本だとエンプラよりは自動車の方が早いかもね
ボルボにはもう入ってるし10年以内にトヨタ車に入るくらいならあり得るかも

**デフォルトの名無しさん** · 2025/05/10(土) 10:17:39.16

システム周りでは標準で使われて、それ以外は他の言語の下請けになるのかと思ったが実際は違うと言うことか？

システム周りにもかかわらず外部に依存が必要であれば使われない
ライブラリが充実しないと完全な下請けにはなれず、c++のDLLのように一部高速化部位での限定利用になる

**デフォルトの名無しさん** · 2025/05/10(土) 10:26:23.15

証券取引みたいに、最高のパフォーマンスと最高の信頼性が求められるガチな領域もエンタープライズにあるのは事実で、
内部的にRustを使っているところがあってもおかしくはないが、そういうのって性質上外に情報が出てこないから盛り上がんないんだよね
自動運転もそうだけど、限界の性能を出そうとすると結局は頭の良い人間を上に据えたスペースシャトル型の厳格なウォーターフォールになるんで、夢がなくてつまらないという面も

**デフォルトの名無しさん** · 2025/05/10(土) 10:38:30.67

COBOL なんか古代の遺物みたいに言われつつもかなり広くつかわれてるもんな……

**デフォルトの名無しさん** · 2025/05/10(土) 10:44:10.80

最高のパフォーマンスを出すにはC/C++/Rustしかない
安全性を満たすRustは唯一の存在
これから少なくとも数十年間は天下を取るのだろう

**デフォルトの名無しさん** · 2025/05/10(土) 10:52:25.23

>>303
EDGEか

**デフォルトの名無しさん** · 2025/05/10(土) 10:55:11.42

AI が台頭してから電力使用量が劇的に伸びてるからな。
自動車の運転を人間のプロ水準で自動化するなら動力と同じくらいの電力が計算に必要という見積りもある。
AI がまだまだ伸びる分野なら効率は重要だ。
これはコストがどうのとかいうレベルではなくコストをかけても無いものは無い (足りない) という深刻な話で、プラットフォームを担う業者がいっせいに Rust に注目しているのも無理からぬことなのかもしれぬ。

**デフォルトの名無しさん** · 2025/05/10(土) 11:33:01.79

そんな見積もり知らんけど50wでLv5運転できる人間が最高だな

**デフォルトの名無しさん** · 2025/05/10(土) 13:30:52.43

やったことないけど組み込みの世界ではどうなの
Rust使われてる？

**デフォルトの名無しさん** · 2025/05/10(土) 13:34:10.15

トヨタはこの前、Rustで求人広告出してたじゃん

**デフォルトの名無しさん** · 2025/05/10(土) 13:36:27.29

組み込みはRustが多いですね
新規案件は殆どがRust
単品ではmrubyが多いですね

**デフォルトの名無しさん** · 2025/05/10(土) 14:07:29.73

トヨタ系は基本的に愛知勤務だからな
Rustでもなんでも使って求人票を飾らないと厳しいんだろう

**デフォルトの名無しさん** · 2025/05/10(土) 14:11:56.01

Rust使えるなら都落ちして田舎で開発するのも悪くないかも
今はたいていタイプスクリプトばっかだから変化が欲しい

**デフォルトの名無しさん** · 2025/05/10(土) 14:50:39.44

TSはフロント側とサーバー側を包括するフレームワークがあるのが強いんだよね
APIを定義してフロント側とバック側を区切る開発なら、バック側はコンパイルされるものが良いというのは同意なんだけど
TSを使うメリットがないと主張してる人は、こういう技術を知らないか、机上論を述べたいだけで実際の開発はしないから生産性など関係ないという人でしょ

**デフォルトの名無しさん** · 2025/05/10(土) 15:01:33.78

>>332
その程度なら誰でも知ってるよ
SSR/SSGからhydrationしてCSRするコードも自作したことある

**デフォルトの名無しさん** · 2025/05/10(土) 15:17:51.64

今のWeb開発では、独立したバックエンドAPIはオプションだからね
Next.jsでサーバーサイドロジックが存在するのがデフォなので、よほどCPU intensiveな処理でない限りは、
Rustで別途独立したバックエンドを作ることはかえって遅延とコストを増大させる
フロントエンドまでRustエンジニアが自分で面倒見るってんなら好きにすりゃいいけど、
Rustエンジニアがフロントエンドやりたいかねえ

**デフォルトの名無しさん** · 2025/05/10(土) 15:25:32.84

フロントとバックエンドで常に齟齬が無ければいいんだけどと言う話になるとTSが出てくる

**デフォルトの名無しさん** · 2025/05/10(土) 15:32:42.03

>>334
それはJS/TSだけでやろうとするからそういう制限になってしまう
RustとWasmも組み合わせてどこまでやるかで色んなパターンがある

**デフォルトの名無しさん** · 2025/05/10(土) 15:45:18.30

>>332
RPC は昔からある取り組みじゃないか。
半世紀もかけて TS でしか実用にならない状況だと本気で思ってるのか？

**デフォルトの名無しさん** · 2025/05/10(土) 15:49:00.61

Wasmはサイズがね…
ごく最近のニュースだと、Prismaが実装をRustからTypeScriptに置き換えたのが話題になってたな
デプロイ時のサイズが問題になる分野だから妥当ではあるけど

フロントだとビルド時間の長さが課題になりそう
UIの位置やサイズを微調整したい場合でも、確認のために毎回重ためのビルドが必要になると面倒じゃない？

**デフォルトの名無しさん** · 2025/05/10(土) 15:54:13.08

>>338
UI 記述言語で書いて形になってから Wasm (にコンパイル可能なプログラミング言語) に変換するような仕組みもある。

**デフォルトの名無しさん** · 2025/05/10(土) 15:57:42.52

>>337
RPCじゃなくてUIの描画込みの話だぞ
同じフレームワーク内でクライアントサイドのレンダリングとサーバーサイドのレンダリングを繋げたりできる
>>333 が書いてるようなもの

**デフォルトの名無しさん** · 2025/05/10(土) 16:03:27.89

>>339
色んなパターンのうちそのUI記述言語を採用してのSSG/CSRのレンダリングコード共通化が有力の一つだよね
サーバーサイドからJavaScriptを完全排除してパフォーマンスを上げる方向性が正しいので

**デフォルトの名無しさん** · 2025/05/10(土) 17:37:33.64

web開発の現場に言ってRustとwasmの組合せを使いなさいと言っても鼻で笑われるだけ

**デフォルトの名無しさん** · 2025/05/10(土) 17:57:46.62

精神障害児で周りを振り回す無能です。
この業界で俺は死ぬかも。
悲しみ

**デフォルトの名無しさん** · 2025/05/10(土) 17:58:59.59

自慢したりとか怒ると自分の首を絞める。
死ぬ。
俺はプログラミング向いてないが、この業界に行くぞ。
どうも死んだほうが良い人間です。

**デフォルトの名無しさん** · 2025/05/10(土) 18:01:36.75

rustも分からんし三年間学んでプログラム書けない無能です。
質問ある？

**デフォルトの名無しさん** · 2025/05/10(土) 18:01:51.09

もちろんrustも分からん。

**デフォルトの名無しさん** · 2025/05/10(土) 18:03:05.22

rust is must

**デフォルトの名無しさん** · 2025/05/10(土) 18:03:13.86

そもそもこの世の中教えてくれない人が悪いと奥底で思っている無能。
人との縁を切って一人で後悔しがち。
ゴミ人間だよ！

**デフォルトの名無しさん** · 2025/05/10(土) 18:04:21.67

俺はガイジだ…
ガイガイガイジのガガイのガイ。
ガイジのボッチのやる気のある無能。
ゴミカス死んだほうが良い。

**デフォルトの名無しさん** · 2025/05/10(土) 18:05:59.49

がががーがががががががががががが～が～が～障害児

**デフォルトの名無しさん** · 2025/05/10(土) 18:06:29.45

我はガイジガガガイジ天地入れざる障害児

**デフォルトの名無しさん** · 2025/05/10(土) 18:11:29.44

不勉強で天地入れざると言う言葉を知らなかったが
明治とかの言葉なのかな？

学があるね

**デフォルトの名無しさん** · 2025/05/10(土) 18:22:28.75

>>352
ありがとう！
言葉を表面上の意味しか捉えられないガイジだけど、他人に迷惑かけるのは良くないよね…
スレ荒らしてすみませんでした…

**デフォルトの名無しさん** · 2025/05/10(土) 18:23:33.01

どうせ俺以外誰も見ていないから好きなだけ荒らせばいいと思うよ

**デフォルトの名無しさん** · 2025/05/10(土) 18:23:55.63

おちつきました。すみませんでした…

**デフォルトの名無しさん** · 2025/05/10(土) 18:29:52.94

>>352
抜刀隊の歌詞にあるから知ってた。
ミリタリー趣味の人ならまあまあ知ってるんじゃないかな。
私は音楽側の趣味で知ったんだけど。

**デフォルトの名無しさん** · 2025/05/10(土) 18:58:55.45

夏休みはまだ早いぞ

**デフォルトの名無しさん** · 2025/05/10(土) 19:15:47.47

業界には何らかの形でメンタルを病んでる人間が50万人以上いると思う

**デフォルトの名無しさん** · 2025/05/10(土) 19:53:17.55

このスレは特殊だから騙されないように

**デフォルトの名無しさん** · 2025/05/10(土) 20:19:31.95

自分は悪質でなければ荒らしを許容するスレにいた

そこでは荒らしとも楽しく話してそのうち荒らしが真面目なコテになったりしていた
みんなもうどこかに行ってしまったのが残念だけどそれも運命だなと

**デフォルトの名無しさん** · 2025/05/10(土) 20:45:49.44

病院行けよ
俺は今日行ったぞ

**デフォルトの名無しさん** · 2025/05/10(土) 21:12:29.85

unsafeなライブラリのラッパーでsafeに設計するのってどうやるの

**デフォルトの名無しさん** · 2025/05/10(土) 21:22:13.51

F-22 ada
F-35 C++

**デフォルトの名無しさん** · 2025/05/10(土) 21:48:52.45

>>362
結局のところ、外側から見て safe な振る舞いになるようにするというだけ。
場合によっては不可能なこともあるけど具体的な状況がわからないとなんとも言えない。

**デフォルトの名無しさん** · 2025/05/10(土) 21:52:02.98

>>362
未定義動作の可能性を排除するために必要な条件を全部チェックする
panicとデッドロックはOKらしい（停止すれば許される）

No matter what, Safe Rust can't cause Undefined Behavior.
https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html