Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
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 part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

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

**デフォルトの名無しさん** · 2025/08/18(月) 22:00:15.90

横長のGUIが衰退したら次は縦長のGUIが再発明されたりする
じゃあ再発明しても変化しない仕様はなんだ
0で割り算できない仕様とか

**デフォルトの名無しさん** · 2025/08/19(火) 19:22:34.36

COBOLみたいに固定長レコードを基本として基本的に動的アロケーションをしない方向のモダンな言語もあっていいと思う
Rustを待たずとも、あれはあれでメモリ安全の究極の形の一つ

**デフォルトの名無しさん** · 2025/08/23(土) 19:14:03.74

>複数の値 (いわゆる多値) を関数が返せる言語はそれほど多くない。
>LISP 系は多値のサポートがあることが多いけどそれ以外だと Go くらいじゃないかな？

Rustの()は値0個で(a,b,c)は値3個の多値
という認識で合ってますか？

**デフォルトの名無しさん** · 2025/08/23(土) 19:50:48.28

>>28
いいえ。
多値ではなくタプルです。

**デフォルトの名無しさん** · 2025/08/23(土) 21:56:54.53

夏のオージ演

**デフォルトの名無しさん** · 2025/08/23(土) 22:15:56.19

多値の取り扱いの仕方の一つがタプル
そしてRust公式にも Functions can use tuples to return multiple values. と明記されている
>>28の引用文についてRustは関数で多値を返すことができる言語の一つ

**デフォルトの名無しさん** · 2025/08/23(土) 22:45:01.43

Rustのタプルは多値で合っているが、言語によってはタプルというオブジェクト[のポインタ]を1つ返す場合もある。
そのような言語ではタプル≠多値で、Rustではタプル=多値。
Rustで関数がタプルを返す時に、各環境で可能なら複数のレジスタを使って返し、レジスタ返しの数を超えていれば、例えば呼び出し元スタックフレームの指定領域に直接書き込んで返す。
したがってRustは多値返しをサポートする言語。

**デフォルトの名無しさん** · 2025/08/24(日) 06:23:07.67

分野によって用語の意味にブレがあるからそういうのを厳密に考えてもあんまり意味ない。
狭義の多値は継続 (continuation) に複数の値が渡ることをいうのでたぶん >>28 はその意味で言ってて、その意味ではタプルは多値ではない。
単なる言語ユーザの目線ではタプルにまとめて受け渡すことと複数の値を受け渡すことには何も違いはないから同一視しても何も困らないよ。
形式論理とかの世界の話。

**デフォルトの名無しさん** · 2025/08/24(日) 06:51:31.37

重要なことはオーバーヘッドの有無
タプルをオブジェクトの一種として扱う言語はオブジェクトを用意してそのアドレス単値のみを渡すため間接アクセスのオーバーヘッドが生じる
タプルを多値として扱うRustは多値として渡せるためオーバーヘッドが生じない
もちろんRustではタプルをBoxに入れることでアドレス単値のみ返すことも可能でオブジェクト方式の言語は常にそれをしていることになる

**デフォルトの名無しさん** · 2025/08/24(日) 07:38:29.67

アーキテクチャによって ABI は違うかもしれないけど一般的な実装としては
関数の返却値が大きい時は呼出し側でメモリを確保してそれを隠れた引数として渡すようなメカニズムになってる。
返却値はスタックを介さない。
これは C++ でも同じ。

**デフォルトの名無しさん** · 2025/08/24(日) 07:52:38.38

>>35
ほぼ合っているが一部だけ違う
間違ってる部分は「スタックを介さない」
正解は「スタックを介す」ことで高速に引き渡す

サイズの大きな値を返す場合
具体的には呼び出し元でスタックポインタを増減することでスタックフレームを拡大してその確保領域のアドレスを隠れた引数としてレジスタ渡しする
呼び出された関数側ではその確保領域に直接書き込んで値を返す

ヒープ領域を確保して受け渡す方式と比べるとメモリ領域確保のコストがない点とスタック上でそのままメモリキャッシュに乗る点で有利

**デフォルトの名無しさん** · 2025/08/24(日) 07:56:09.24

ちなみにRustでx64アーキテクチャの時
16バイトまでならレジスタ渡しになり上記スタック領域は使われないため更に速い

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

ごめん、肝心なところ書き間違えてる
✕ 16バイトまでならレジスタ渡し
○ 16バイトまでならレジスタ返し

**デフォルトの名無しさん** · 2025/08/24(日) 10:58:20.04

言語が多値返却をサポートしてるかどうかというのは文法としてサポートしてるかどうかという意味

文法的にはサポートしてないけど「〇〇使えば多値返却できる」のは当たり前
一般的なプログラミング言語で「Functions can use 〇〇 to return multiple values」の〇〇に当てはまるものがない言語は無いので意味がない

文法的にサポートしているかどうかと内部実装がどの程度最適化されるのかはまた別の話

**デフォルトの名無しさん** · 2025/08/24(日) 11:01:04.53

多値が返せるか？の意味なんて、ユーザ的には戻り値の分割代入ができるか？ってだけだし
ダラダラ言わずに返せますで終わりでよくね

**デフォルトの名無しさん** · 2025/08/24(日) 11:17:14.32

Rustは多値を返す機能があるだけでなく
その実装も本当に多値を返すため効率よく実行も速いことが特徴

**デフォルトの名無しさん** · 2025/08/24(日) 11:34:24.43

>>40
仕様を読むときは言語の理屈や用語をわかってないとちゃんと読めない。

複数の要素をひとつにまとめたもの (タプルや構造体) をひとつ返すというのと複数の値を返せるというのは違うことなんだが、
Rust では同一視することにしたというならそれはそれで同一視しているという理屈をわかってないといけない。

**デフォルトの名無しさん** · 2025/08/24(日) 11:46:57.61

>>42
それは屁理屈
プログラマとしては多値を返せる機能があればよいわけで、
それがタプルという形で実現されていようが困ることは何一つない
逆に、タプルをサポートしていればそれだけで十分であり、
タプルでない多値をサポートするメリットが何もない

**デフォルトの名無しさん** · 2025/08/24(日) 11:50:38.02

>>43
実際に (複数の要素をタプルなどにまとめるのではなく) 多値をサポートしてる言語はあるわけだが、ディスってんの？
言語の理屈の構成の仕方の話であって言語としてのメリットの話なんかしてない。

**デフォルトの名無しさん** · 2025/08/24(日) 11:58:39.52

多値をサポートしてる言語の例としてGoが上で挙げられているけどさ
Goはタプルがなくてみんな困っている
タプルがある言語では多値がなくて困った話は聞かれない
機能として『タプル ⊃ 多値』だからだよ

**デフォルトの名無しさん** · 2025/08/24(日) 12:05:10.36

Goでタプルがなくて辛いという話は聞いたことがないな
最適化の観点抜きで機能的に他でカバーできるから不要と言ってしまうと、
例えばオブジェクトは全部ヒープに置いてスマポの所有権移動だけにしてしまえば複雑なムーブは不要となり遥かにシンプルになる
それはそれで一つの考え方だが、Rustはそういう言語ではないと思っているのだろう？

**デフォルトの名無しさん** · 2025/08/24(日) 12:08:19.32

返却された値がスタック上でどう扱われるかというのは言語仕様でなく最適化の問題だから、そこはRustではなくLLVMの話
言語仕様としては「Rustではタプルを簡単に作れる」「タプルの中身を別々の変数に束縛できる」というだけ
多値返却の目的からすればこれで十分だし、多くの言語はこれに相当する

Goは本当に多値返却という仕様で、これはタプルを返すのとは違う
そもそもタプルが言語仕様になくて、関数の返り値でだけ多値を返せるという変わった仕様
だから、2つの戻り値を返す関数を1変数で受け取ることができなかったりする
(Rustでいえば「戻り値を分解せず1つのタプル変数 t で受け取る -> t.0, t.1 のようにアクセスする」という書き方がGoではできない)

だから言語仕様としての話をしたいのか、「関数から複数の戻り値を返す」という目的の話をしたいのかで話は変わる
後者については、最近の多くの言語ではサポートしてるし、そんなに話がズレることもない
前者の意味でなら、Rustは多値返却の構文を持つ言語とは違う

**デフォルトの名無しさん** · 2025/08/24(日) 12:16:23.06

Goの多値とRustのタプルは同じ
どちらも実装は多値として返すため多値レジスタ返しが可能ならばそうするため効率が最も優れている
関数定義もほぼ同じ
func foo() (type1, type2) {…
fn foo() -> (type1, type2) {…

**デフォルトの名無しさん** · 2025/08/24(日) 12:16:31.50

バカなやつほど抽象度の区別ができない
バカなやつほどオレオレ定義で用語を使う
バカなやつほど主語を書かない

本当に相手にする価値があるか考えよう
改善の見込みがないバカなら何を書いても時間の無駄でしかない

**デフォルトの名無しさん** · 2025/08/24(日) 12:26:32.12

多値を抽象化して機能を強化したものがタプルだもんね
だから多値でできることは全てタプルでもできるんだよ
タプルを持つ言語は機能の低い多値を別途持つ必要がない

**デフォルトの名無しさん** · 2025/08/24(日) 12:50:55.19

「タプルがあれば十分」は殆どのケースでは同意するけど、Goに限ってはそうする理由があるんだよ
エラーを多値で返す仕様かつ、エラー処理を明示的に書かせる思想の言語だから
value, err := foo()
のように err がコード上に表れるようにする必要があって、これはタプルだとまずい
t := foo() と書けてしまうと「タプルの2要素目がエラー」というのが見えなくなる

これは割とGo特有の事情で、Result型や例外を使う言語だとタプルでも困らない

言語仕様というのは他の部分も含めた全体的なデザインとして考えるものだから、「Rustではタプルで困らない」が正しくても、他の言語含めて全てそうだとは言えない

**デフォルトの名無しさん** · 2025/08/24(日) 12:56:30.01

>>49
>バカなやつほど抽象度の区別ができない
>バカなやつほどオレオレ定義で用語を使う
>バカなやつほど主語を書かない

汚コーダーの特徴が濃縮されてるね
3番目は「書かない」というより「書けない」だと思う

**デフォルトの名無しさん** · 2025/08/24(日) 13:02:12.19

原始的な剥き出しの多値を扱う必要のない言語においては、タプル多値があれば多値をサポートしているという結論でいいんじゃないかな

**デフォルトの名無しさん** · 2025/08/24(日) 13:07:02.23

Rustはnamed tupleもanonymous structもなくunnamed tupleで位置でアクセスするか事前に定義した型で名前でアクセスするかしかないから利便性ではモダンな他言語に一段劣る

**デフォルトの名無しさん** · 2025/08/24(日) 13:18:17.18

>>54
これ便利だと思う？

# まずnamedtuple関数をインポートします
from collections import namedtuple

# 次にNamed Tupleを定義します
Point = namedtuple('Point', ['x', 'y'])

# そしてインスタンスを作ります
p = Point(10, 20)

# 名前でアクセスできるようになります
print(p.x) # Output: 10
print(p.y) # Output: 20

**デフォルトの名無しさん** · 2025/08/24(日) 13:28:22.18

>>51
いや、エラーに限らずt.0とか普通に可読性最悪だからね
多値をタプルとして実装するなら、即時の分割代入を必須とするか、もしくはC#のようにpositionalなタプルと互換性のあるnamed tupleとするか、どちらかは必須

**デフォルトの名無しさん** · 2025/08/24(日) 13:41:09.97

必要となるまでは1つのまとまりとして一括して扱えたほうが有利
必要になったところでパターンマッチングさせて個別に用いる

**デフォルトの名無しさん** · 2025/08/24(日) 13:49:22.14

Rustは必要なところではパターンマッチングできるから不便なことはないよな

**デフォルトの名無しさん** · 2025/08/24(日) 13:56:11.80

取得から消費までのコード上の距離が離れるほど人間の短期記憶の負担になり可読性が低下する
複おじは特に頭悪いから実感してるんじゃない？

**デフォルトの名無しさん** · 2025/08/24(日) 14:11:41.28

let (unko, chinko) = unkochinko
とか突然出てきてunkochinkoの宣言が離れてたら、合ってるのか不安を感じてつい宣言までスクロールしちゃうわ
離れた場所での位置依存は普通に可読性最悪

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

>>56
ジェネリックに意味を持たない局面もあるからそこでt.0を使うのは適してる
意味がある局面なら例えばfor (index, name) in ...や|(index, name)| ...のように使われるから名前でアクセスできる

**デフォルトの名無しさん** · 2025/08/24(日) 14:15:37.70

>>56
C#も分割代入しない書き方はできるじゃん
その場合の可読性はPythonもC++もC#もそう変わらないかと (t[0], get<0>(t), t.Item1)

意味のある名前を付けたいなら、それはRustでもstructを定義すれば済む話だし
C#の匿名クラスの便利さもまあ分かるけど、あれば嬉しいくらいで、個人的には必須とまでは思わない

**デフォルトの名無しさん** · 2025/08/24(日) 14:18:45.06

>>62
C#には匿名型とは別にnamed tupleがあって、positional tupleと互換性を持ったままフィールドに名前を付けられる

**デフォルトの名無しさん** · 2025/08/24(日) 14:23:02.15

>>55
named tupleの定義が面倒＆カッコ悪いな

**デフォルトの名無しさん** · 2025/08/24(日) 14:40:44.45

Pythonの名前付きタプルは普通に使いにくいからな…
その用途なら dataclass にしとけ、というのが共通認識だと思う

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

>>55
それは文法としてnamed tupleをサポートしてないからだよ
サポートしてれば下のように書ける

def foo() -> (x: int, y: int):
　return (x: 10, y: 20)

p = foo()
print(p.x, p.y)
x, y = foo()
print(x, y)

**デフォルトの名無しさん** · 2025/08/24(日) 17:15:02.39

事実と意見を区別しろ
前提を明確に示せ
異なる前提に依存する結論を無理に適用するな

**デフォルトの名無しさん** · 2025/08/24(日) 17:48:30.01

>>66
これで済む話
let (x, y) = foo();

**デフォルトの名無しさん** · 2025/08/24(日) 18:53:52.96

>>66
筋がよくなく中途半端に感じる
その型を他でも用いるならば型に名前を付けて宣言したほうがよく
その場限りならば>>68

**デフォルトの名無しさん** · 2025/08/24(日) 19:23:45.82

let (manko, chinko) = foo(); // 本当のfoo()の返す中身は(chinko, manko)
が許されるから、それって嫌だよねって話じゃないの？

**デフォルトの名無しさん** · 2025/08/24(日) 19:32:58.00

>>70
そうそう
AIに生成させるにしても、fooが別のパッケージだったりするとシグネチャだけで要素の意味を推測できないのは辛いわな

**デフォルトの名無しさん** · 2025/08/24(日) 19:44:34.69

別なら構造体を定義しろ

**デフォルトの名無しさん** · 2025/08/24(日) 22:32:48.16

>>68
どっちかというと真逆でRustの場合は1mmでも名前でアクセスしたいと感じるものは構造体を定義しないといけない

>>69
中途半端に感じるのは当然
事前に構造体を定義しておくほどではないが要素には名前でアクセスしたいというものすごく中途半端な状況にこそ求められる機能だから

**デフォルトの名無しさん** · 2025/08/25(月) 06:47:36.11

>>59
>>60
それらは古典的プログラミングだから無関係な処理が間に挟まったり流れが乱されるため可読性が落ちる
Rustでは抽象化したプログラミングによりメソッドチェーンで繋ぐことが多い
チェーンの間はタプルのまま旅を続けたとしても一つの流れなので可読性は落ちない
チェーンの途中もしくは最後のforやfold系でパターンマッチングされてタプルが解消されればよい

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

多値戻しは_をサポートしてなければコーダーにとってはどうでもいい話じゃないんかね。
最適化機会を明示できるかどうかくらいじゃね？

**デフォルトの名無しさん** · 2025/08/25(月) 10:18:01.04

ながめてるとたしかに_多いな

＞fn f(init: &str, n: usize) -> String {
＞　let mut list = init.chars().rev().collect::<Vec<_>>();
＞　for _ in 1..n {
＞　　if let Some((pre_index, (_, old))) = list.iter().tuple_windows().enumerate().find(|(_, (pre, cur))| pre > cur) {
＞　　　let old_index = pre_index + 1;
＞　　　let (new_index, _) = list.iter().enumerate().find(|(_, cur)| cur > &old).unwrap();
＞　　　list.swap(old_index, new_index);
＞　　　list[..old_index].reverse();
＞　　}
＞　}
＞　list.into_iter().rev().collect()
＞}

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

タプルの片方は途中不要で最後に必要だが、もう片方はその逆とかよくあるある。
後者のfind()はposition()に置き換えられるが、二つのfindが対称形の処理ぽいのでそのままでもいいか。

**デフォルトの名無しさん** · 2025/08/25(月) 15:50:58.87

まだ多値の話してる・・・

**デフォルトの名無しさん** · 2025/08/25(月) 16:13:59.05

このスレはあくまで複おじのファンスレッドだから
複おじの興味が続けばその話題が続くんだよ

**デフォルトの名無しさん** · 2025/08/25(月) 21:09:46.97

ファンじゃなくて自演スレだから

**デフォルトの名無しさん** · 2025/08/27(水) 18:45:58.51

タプルといえばzipとmultizipの方針の違いでVec指定の与え方が微妙差
let (counts, chars) = str.chars().sorted().dedup_with_count().unzip::<_, _, Vec<_>, Vec<_>>();
let (counts, chars) = str.chars().sorted().dedup_with_count().multiunzip::<(Vec<_>, Vec<_>)>();

**デフォルトの名無しさん** · 2025/08/28(木) 10:55:22.21

抽象なんて「見たいものだけを見る」という程度の意味だからね
もしメモリ管理が最大の関心事なら
抽象度が最も高いIUnknownにリファレンスカウント機能をつけていい

**デフォルトの名無しさん** · 2025/08/28(木) 11:58:26.45

>>81
左辺に型を書けばいいんだよ
そのほうが読みやすいしタイプ数も少ない
あとunzip/multiunzipはcollectでも代用可

**デフォルトの名無しさん** · 2025/08/28(木) 15:40:44.35

なんで掛け算の引数には名前がないんだろう
順序を逆にできない理由が一目でわかるような名前があるなら名前をつけるべき

**デフォルトの名無しさん** · 2025/08/28(木) 20:43:02.31

>>81
unzipはトレイトを使っていないため余分なパラメタが露出してしまってる
multiunzipはトレイトMultiUnzipを
collectはトレイトFromIteratorを使っている

>>83
今年のRust 1.85からタプルもcollectできるようになったね

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

a * b * c
は b や c のすぐ隣に目印があるからキーワード引数は不要だ

mul(a, b, c)
(* a b c)
このような記法だけが、b c 付近で文法的サポートが不足している問題を抱えている

**デフォルトの名無しさん** · 2025/08/30(土) 23:22:46.71

>>55
namedtupleは廃れて今はdataclassを使う
Rustでの#[derive(Debug, Hash, Ord)]付き構造体相当
結局Pythonでもそのへんはちゃんとしてほしいことになった

**デフォルトの名無しさん** · 2025/08/31(日) 09:51:10.58

ハッシュ関数を使えば保守的GCが廃れる
確率を見たらカオスと思え

**デフォルトの名無しさん** · 2025/08/31(日) 10:00:25.50

>結局Pythonでもそのへんはちゃんとしてほしいことになった
誰か日本語に翻訳して

**デフォルトの名無しさん** · 2025/08/31(日) 10:52:20.39

足りない頭で必死に調べた複おじの努力を認めて差し上げろ
それはともかく、一般にスクリプト言語ではタプルはあまり好まれず、辞書が好まれる傾向がある
- ユーザーが辞書データ構造を使ってレコードを扱うことに慣れている
- 辞書を扱うための簡便な構文が存在する場合が多い
- 辞書と配列の速度やメモリ使用量の差が問題にならない
- 値が増えた場合にランタイムエラーを引き起こす
なお、dataclassは辞書に対する型付きのラッパーに過ぎない
あくまでこれはスクリプト言語の事情であり、Rustのような静的言語においてはレコードはタプル(構造体は名前付きのタプルの一種)として実装することが基本であることに注意しなければならない

**デフォルトの名無しさん** · 2025/08/31(日) 17:32:35.66

辞書かどうかは本質ではない
辞書として用いないことが圧倒的に多いため例えばV8では静的解析で判明するプロパティを構造体フィールドのように扱い実行するため辞書実装とは異なり速い

**デフォルトの名無しさん** · 2025/08/31(日) 18:15:49.65

また的外れなレスだなぁ
結局複おじにもそのへんはちゃんとしてほしいことになった

**デフォルトの名無しさん** · 2025/08/31(日) 18:20:32.10

>>91
V8のプロパティアクセスの最適化は基本的には静的解析に依存しないよ
同じプロパティが同じ順序で追加されたオブジェクトは同じ型と見做してキャッシュされたプロパティの位置を利用する
あくまで辞書データ構造を前提としたままでキャッシュ戦略を工夫しているに過ぎない

**デフォルトの名無しさん** · 2025/08/31(日) 23:19:02.35

魔法の数字ではなく
ちゃんとenumを使うことになった

**デフォルトの名無しさん** · 2025/08/31(日) 23:24:15.68

Minimal Embedded FAT32 Driver - in Rust!
https://www.youtube.com/watch?v=VcWXn8B9RoE

**デフォルトの名無しさん** · 2025/09/02(火) 22:34:52.76

「Rust」の平均単価が3カ月連続上昇　エン・ジャパンがフリーランス案件の分析レポートを発表
https://atmarkit.itmedia.co.jp/ait/spv/2508/21/news045.html

開発言語別では、比較的新しい言語「Rust」が3カ月連続で平均単価を伸ばし、87万4000円（2025年6月比で4.4％増）で1位となった。

**デフォルトの名無しさん** · 2025/09/03(水) 01:10:14.83

もういいよ

**デフォルトの名無しさん** · 2025/09/03(水) 06:18:41.58

Rustがトップになる予想が当たったね

**デフォルトの名無しさん** · 2025/09/03(水) 08:43:05.32

これからどんどん増えるで

**デフォルトの名無しさん** · 2025/09/03(水) 10:27:14.93

https://corp.en-japan.com/newsrelease/2025/42699.html
Goもそうだけどレベル低い人(特定言語の習熟度ではなく基礎的な技術力の観点で)お断り案件がほとんどだから単価が高く出る
つまり裾野が狭いことを意味するわけで、決して手放しに歓迎すべきことではない
特にRustがこれから食っていかなければならないのは最下位付近にいるC++とCの領域だから、普及していけば単価は大幅に低下する

**デフォルトの名無しさん** · 2025/09/03(水) 10:39:55.94

> 全体として、比較的新しい言語である「Rust」や「Go言語」、「Kotlin」などが高い単価を維持しており、市場での需要の高さがうかがえます。

これかなり違和感あるなあ
このへんのメンツの単価が高いのはつまるところ案件の難易度が高いからで、
下の方のコモディティ言語と同じように需給バランスで単価が決まると考えてるのは実態を知らないんだろうなと思う

**デフォルトの名無しさん** · 2025/09/03(水) 11:43:31.30

>>100
C系はバカでも書けるから安いんだよ
レベルが低い人はRustが難しいと感じて挫折や一部アンチ化
一方で今後求められつつあるのが安全で速いRust

**デフォルトの名無しさん** · 2025/09/03(水) 12:11:36.01

もしかしてRustを誰も使ってないのはレベル低い人だらけだから？

**デフォルトの名無しさん** · 2025/09/03(水) 12:41:52.63

>>101
案件の難易度というよりも
開発者個人に期待されてる技術水準だったり
言語に付随して求められる知識やスキルの水準と希少性による

それらが低い水準の技術者でも構わないという求人の多寡が
言語別平均単価を最も大きく左右する要因

**デフォルトの名無しさん** · 2025/09/03(水) 14:32:47.56

低い水準の技術者ほど言語別の単価を気にするのは他に差別化できるものがないからなんだよな
転職エージェントについても同じ事が言える

**デフォルトの名無しさん** · 2025/09/03(水) 14:55:10.39

納期を守るのと守らないのはどっちが供給不足か

デフレ脱却したいとして、供給を減らすのと増やすのはどっちが合理的か
ぜんぜんわからない
雰囲気

**デフォルトの名無しさん** · 2025/09/03(水) 20:52:42.81

関係ないよ
Pythonの単価が一番高かったころもあった
その時はみな稼いでいたんだろな

需要と供給のバランスが崩れてるところと言う視点だけだと思うけど

**デフォルトの名無しさん** · 2025/09/03(水) 23:36:04.43

何が関係ないのか全然わからん

**デフォルトの名無しさん** · 2025/09/04(木) 00:25:45.89

プログラミングは一種のパズルのようなもの
各言語の機能制約＋バグなく目的の実現という全体のパズルを解いていく
Rustの場合はメモリ関係や諸々の安全性などのための制約で他より難しいパズルになるため誰でも参入できるわけではない
代わりに速さ省メモリ安全性の両立という唯一の果実を得ることができる
構造的に単価の崩壊は起きそうにない

**デフォルトの名無しさん** · 2025/09/04(木) 00:35:53.93

プログラミングをパズルだと思ってるやつw説得力が違うww

**デフォルトの名無しさん** · 2025/09/04(木) 00:41:20.03

データや手続きの構造化はパズルそのもの

**デフォルトの名無しさん** · 2025/09/04(木) 02:30:07.00

それわかるわ
パズルを解く意識なく漫然と進めるとスパゲッティになりやすい
そうなるとバグや機能追加で辻褄合わせを重ねるダメなプログラミングになってしまう

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

ルールが不安定なパズル
ストライクを三回見逃したらアウトか？
それは実際に起きてから検討する

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

プログラミングの基本は段階的詳細化
設計のセンスない奴は逆にボトムアップで後から辻褄を合わせていくようなパズルになりがち
特にRustは細部に気を取られやすいから注意

**デフォルトの名無しさん** · 2025/09/04(木) 09:22:33.64

実現したい機能に対してトップダウン的に絵を描いていく過程も含めてパズルと言っているならいいが、
おそらく複おじが言っているのはそういうものではなくコードレベルの辻褄合わせのパズルだろう
いわば、自ら解く必要のないパズルをわざわざ作り出して必死にそれを解いている状況だ

**デフォルトの名無しさん** · 2025/09/04(木) 10:16:31.84

パズルではないわな
答えなんてないし

それぞれの事象に対してどう見るか　構造の把握
スケール感の問題

**デフォルトの名無しさん** · 2025/09/04(木) 10:23:41.49

ABCの処理があって普通に考えるとA、B、Cの順で処理するんだけど
よく考えるとC,A..BにしてCの段階で条件分岐や枝狩りしたほうがロジカルに効率が良いと気が付いて実装するけど
実務で使い始めて統計取ると特定のパターンばかり利用されててキャシュ効率上でBCAでやったほうが効率が良かったとか
パズルとは程遠い泥臭い世界

**デフォルトの名無しさん** · 2025/09/04(木) 10:44:44.47

Rustは他の言語よりパズル要素強めじゃね？

**デフォルトの名無しさん** · 2025/09/04(木) 10:56:34.58

明瞭な線があるわけではないグラデーションの中であえて「どちら寄り」かを言うならそうとも言えるかもしれない。

**デフォルトの名無しさん** · 2025/09/04(木) 11:02:42.07

外部の条件によって最適化のために条件分岐などが追加され複雑度が上昇する
そんなパズルなんてない

**デフォルトの名無しさん** · 2025/09/04(木) 11:26:54.96

プログラミングはぐちゃぐちゃの辻褄合わせになったら敗北
辻褄合わせにならないようにするという明確なゴールのパズルを解かなければならない

強引に辻褄合わせできてしまう言語ではその問題が潜在化して表面上はごまかす形になる
Rustでは辻褄合わせはコンパイルを通せないという形で顕在化してくれることが多くて好ましい
無理矢理にコンパイルを通すために無駄なコピーや不必要な内部可変性を用いるとコードレビューですぐに低質なプログラマであるとあぶり出せる

**デフォルトの名無しさん** · 2025/09/04(木) 11:29:28.26

そりゃ辻褄合わせと呼ぶラインをどこに引くかによって何とでも言える
優秀なエンジニアならコードレベルの試行錯誤は全て辻褄合わせだろう

**デフォルトの名無しさん** · 2025/09/04(木) 11:40:43.96

またそうやって擬似問題になりそうな話を

（wikipedia）パズルは、あらかじめ出された問題を、論理的な考察と試行錯誤によって解くことを目的とした、ゲームやクイズに似た娯楽の一種。

が世間一般の認識だから、解を用意していない問題はあんまりパズルとは言わん。

**デフォルトの名無しさん** · 2025/09/04(木) 11:56:06.31

プログラミングは制約条件を理解してないと解けないパズルかというとそうでも無い
テストさえ書けりゃ、どう解いてもいいパズルだから自由度は無限大
どこを妥協するか、どこを作り込むかだけの問題
もちろん、組み込みみたいに制約が厳しすぎて設計自由度のない世界もあるけれどそういう世界ではRustは使わない

**デフォルトの名無しさん** · 2025/09/04(木) 11:57:48.23

前スレから「辻褄合わせ」というプログラマーが大勢いるが、それは外部インターフェースとの整合とかの話だけでしょ
そんなの辻褄合わせして当たり前、仕様なんだから合格させようよ

**デフォルトの名無しさん** · 2025/09/04(木) 12:02:06.25

パズル的要素が皆無というわけではないんだが仕事としてのプログラミングの場合その割合はせいぜい全体の5％以下
プログラミングをパズルだと捉えている人は残りの95％が見えてないだけ