Rust part33 YouTube動画>1本 ->画像>2枚

公式
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
http://2chb.net/r/tech/1755057787/
Rust part31 http://2chb.net/r/tech/1751545806/
Rust part30 http://2chb.net/r/tech/1748392296/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://2chb.net/r/tech/1514107621/

5ch電源断とその際のバグにより
各板の現役スレ一部がタイミングの運で失われた模様
Rustはpart31とpart32両方が現役の状況であった

5chのシステムっていまだにperlとかなんだっけ？

誰かRustで5chクローン作ってくれろ

>>2
どういうバグ？

昔から活発な板でdat一覧ファイル壊れたりロストするから排他制御や落ちた時の途中状態からのリカバリとかザルなのかもね

Rustじゃ20年ぐらい掛かりそう

2ch初期からあるread.cgiとpostの読み書き基本掲示板機能部分だけなら1日で終わるけど
後から追加した外から見えない部分が絡み合って規模も読めないね

難読よいしょw部
難読宝田真月部
難読オランザピン部
難読肉壺ワッショイ部
難読自己中部
難読承認欲求部
難読ゴキブリ部
難読助かりました部
難読宇宙人部
難読でんちゃでんちゃでんちゃちゃっちゃっちゃ〜部
難読カービィ部
難読失敗作部
難読ADHD部
難読自開部
難読多動部
難読在日部
難読糖質部
難読人非人部
難読生まれも育ちもやまゆり園部
難読何ガン飛ばしてんだよオイ！！部
難読池沼部
難読トナラー部
難読表出ろこの野郎！部
難読マウント部
難読ホンモノ部
難読害悪部
難読ガガイのガイ部
難読syamu未満部
難読底辺部
難読インチュニ部

山下スクリプト回りの対策で、エラーが出た時にそれが何故出てるエラーなのかすら
今の5chはもはやアンドキュメントだからな

電源落ちたからって前スレまで消えるのは常識的には考えられない動きだけど5chはそういうものなんだな

難読漢字部
ガイジの集まり
くたばれよ

みんなもポケモンゲットじゃぞ

>>11
前スレのpart30は過去ログ倉庫へ移動されていたため無事だよ
part31は1000になっただけで過去スレへと隠れてなくて見えたままだったのが不運

チューリップの中で再現性のない部分だけ消えなさい
バブルは消えた

難読ロリコン部
難読僕のスマホ返せぇぇぇ！！部
難読とど田とどら部
難読ちぎゅ田ちぎゅら部
難読チーズホビー部
難読お薬手帳部
難読底辺部
難読積極奇異型アスペ部
難読電子障害者手帳部
難読自開部
難読穢多非人部
難読バ漢字部
難読ウィィィィィィィィッス部
難読チギュァァァァァァァァァァァァ部
難読動物園部
難読おかしな奴しかいないんだけど部
難読助かりました部
難読舌打ち部
難読類友部
難読ガイジ(ゲェジ)部
難読スタバ陽キャきっしょ部
難読僕も！僕も気持ちいいことしたい！！部
難読自己中部
難読Fラン大学中退部
難読トナラー部
難読スペシャルオリンピックス部
難読ひまわり学級部
難読ゴミ部
難読弱者男性部
難読アホロライ部

Check Pointが見つけたと言ってるRust製のWindowsカーネルコンポーネントの脆弱性ってどのCVEか分かる人いない？
https://blog.checkpoint.com/research/microsoft-vulnerabilities-exposed-by-check-point-research/
https://msrc.microsoft.com/update-guide/vulnerability

難読DSM部
難読さす障部
難読さすガイ部
難読動物園部
難読トナラー部
難読よいしょw部
難読ホンモノ部
難読頓服部
難読でんちゃでんちゃでんちゃちゃっちゃっちゃ〜部
難読マスターベーション部
難読マウント部
難読ウィィィィィィィィッス部
難読syamu未満部
難読スマホ脳部
難読多動部
難読害悪部
難読電車(バス)代割引部
難読エッホエッホ部
難読てんかん部
難読ディズニー格安部
難読フレンド申請部
難読すいません、3種のチーズ牛丼特盛りに温玉付きでお願いします部
難読水用意しろ水。イライラするわぁ部
難読おかしな奴しかいないんだけど部
難読デスマフィン部
難読コンサータ部
難読ガイジ(ゲェジ)部
難読オランザピン部

Windows更新プログラムﾊﾞｸﾞの温床Rust
馬鹿ｺｰﾀﾞを無理やり矯正したとこで馬鹿が治る筈もなく

バグを無くせるプログラミング言語は存在しない
Rustはプログラミング言語の中では最も様々な安全性を保証してくれる
それ以上でもそれ以下でもない

わかってねぇな
それじゃﾎﾝﾓﾉは育たないことを

Rustは生き物ですらない
育児もディールもしない

RustってIT土方専用言語になりそう

GCC Rustはだいぶ前にメインラインにマージされたみたいだけど
クロス対応ってどこまで進んでいるんだ？
LLVMバックエンドがないマイコン系ISAもRustで開発できる感じ？

Rustは衰退しました。

その書き込みもRust製のPingoraを通って投稿されてRust製のPingoraを通って皆が読んでるよ

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

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

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

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

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

夏のオージ演

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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)

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

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

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

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

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

別なら構造体を定義しろ

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

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

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

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

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

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

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

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

タプルといえば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<_>)>();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Minimal Embedded FAT32 Driver - in Rust!

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

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

もういいよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

競プロ上がりだと100%パズルぐらいの感覚で業務システム開発もやるのかな

全員の意見が多かれ少なかれパズル的な部分が存在することを認めているな
さらにRustはそのパズル的な部分の難易度が上がるという見方が複数あってそれらに反論がない
元の話の結論が出たな

元の話の結論が出たな
Rustに低質なプログラマは参入できない
よって>>96の単価表ボトム3『C/C++/C#』のように単価が下がることはない

その記事の元の発表の単価表は>>100

いやーC#はともかくC/C++はエッセンシャルワークとしての側面があるからねえ
C#みたいな業務システムの領域ならそんなものはSaaSに喰われて消えるみたいな強弁も一理あるけど、組み込みが消えたら社会回んなくなるよ
その領域がいつまでもC/C++のままで変わらないとしたら、複おじの願うRust理想郷は永遠に実現しないことになる

言語別単価で優劣を語りたがる層
　≒ 言語以外に差別化要素を持ち合わせてない層
　≒ プログラミングをパズルと捉えている層
　≒ 生成AIで置き換えられる層

パズルの言語差が単価の言語差だと思ってる層 == 複おじ層

脳内の「心の声」を読み取る新たな技術、最大74％の精度でリアルタイム解読に成功
公開： 2025-08-23 08:00
https://karapaia.com/archives/537808.html
>>　彼らの脳の運動皮質（大脳皮質の一部で随意運動の指令を出す領域）にマイクロ電極を埋め込み、神経活動を記録した。
>>　実験では、参加者に以下の2通りの指示が与えられた。
>>1. 指定された単語を声に出そうと努力する（実際には発声しない）
>>2. 同じ単語を、声にも出さず、心の中だけで思う（内言）
>>　結果として、どちらの行動でも脳の同じ領域が活動し、似たパターンの神経信号が観測された。
>>　ただし、内言の方が全体的に信号の強度は弱く、詳細な分析によって両者の違いも見分けられることが分かった。
>>　さらに驚くべきことに、研究チームは、参加者が指示されていない言葉までもBCIが読み取っていたことを報告している。
>>　たとえば、画面上に表示されたピンク色の円を数える課題では、参加者が心の中で数を数えていたことが検出されたという。

★直接接続しても読み取り精度１００％で無い！
★★★★★★★★★
思考盗聴不可能
★★★★★★★★★

Rustって思考盗聴の技術と何か関係あるんか
そもそもサブリミナルで他人の意思決定に干渉してるだけなのに「思考盗聴」とか言う意味が分からん
カードマジックで意図的に特定のカード選ばせた後に「透視」して言い当てるみたいなネタなら分かるけど

このスレ見てると統失多そう

プログラマーなんて、SEと違ってその気になればいつでも手帳もらえるようなのばっかりだろ

よくC/C++からの書き換えは話題になるけどJavaとかはどうなんだろ

>>138
Meta社主導のオープンシステムBuckがJavaからRustに書き換えられ速くなった

やっぱそっちの方が効くよな…
C/C++は安全性は向上するかもだけど効率面はそれほど変わらないし

C製のNginxにCloudflareが機能拡張の限界を感じてRust製のPingoraを作ってしまい速くなった話もある

速くなるものが作れるともう戻れなくなるのよね

JavaはなんとなくわかるけどCより速くなれたのは
どういう理由なんだろうな？

メモリ管理に厳しくなった分コードが整理されたとか
高速なライブラリが利用しやすかったりとか？

そういうのはたいてい並列化で読み込み時間短縮って例

Nginxの件に関しては、マルチプロセスをマルチスレッドに変更してコネクションプールの効率を改善したのと、
LuaモジュールをRustに書き換えたことが速くなった理由
つまりCより速いかどうかは全く関係ない

「xxx言語で書き直したらこんなに速くなりました」はだいたい言語とは関係無いよ
リライトに伴う構造やロジックの見直しがメイン

頭がおかしい人にはそれが通じない↓

JavaやC#やGoのような「決して遅くないけど最速でもない(最悪でもCより数倍遅い程度)」グループからのRust移行はあまり流行ってないよね
元々わざわざコアだけCで書いたりしてないし、Rustへの漸進的な書き換えもやりにくい
セキュリティ面でも得るものはほとんどなく、むしろ標準ライブラリが貧弱でコミュニティの馬の骨に頼る部分が増える点はリスク要因
あと、そういう言語の著名な成果物って現実の複雑性に真面目に向き合ってやるべきことを地道にやってきた結果として重厚になったのが多くて、
Rust信者が好みがちなサクッと書き換えて爆速最強！みたいな話にはなりにくい
Elasticsearchに対抗したMeilisearchみたいな例はあるけど、機能がしょぼすぎて性能以前の問題として全く戦いになってないのが現状

>>143
まず前提として「事情は変わる」ってことだ。
ある時点の事情に合わせて最高にチューニングされたプログラムだとしても
変わっていく事情に合わせて変化できなければ相対的に遅くなる。

そして世の中のプログラムというのは世間で思われているほどには保守されていないし、ドキュメントもない。
根本から全てをやり直す機会というのはまず無いんだ。
しかしそれがあるのが「新しい言語の登場」という場面なだけ。

言語 (処理系) が充分以上の性能を持っていることは当然の前提としても
劇的な性能向上は書き直すという行為そのものにある。

Rust とは関係ないが、書き直して性能向上した顕著な例としてはリンカの mold なんかが有名だ。
GNU LD に比べたら百倍以上とかの速度差があるけど
飛びぬけた工夫があるわけではなく今風の設計でやり直したに過ぎない。
互換性を維持したままやりなおすってのがひたすらしんどいから誰もやりたがらないだけで
やれば効果があるってことはたぶんそこらへんにたくさんある。

個人がバグったところで何の問題もないような自作のソフトを
AIでぱーっとRustに書き直して爆速！みたいなのなら、GC言語からの移行もあるかもしれないけど
金と人使ってビジネスでやるには、メリット説明できないわな

おまえら勘違いが激しいな
そのままで異なる言語に書き換えが割に合うのはスクリプト言語などクソ遅い言語から変更のとき

そのままではなく機能追加などで構成から見直して変更して書き直す時にRust一択
完全な新規開発でもRust一択
それだけのことだ

ｗ

デスクトップアプリをpythonからtauriに移植してる
やぱーHTML,CSSが最高だからね

クラウドもCDNもWebベースでWeb関係の知識は必須な時代
アプリAPIからGUIまで全てWebベースにするのが主流になりつつ

tauriってマルチプラットフォームのせいでWindows固有の設定が不足してるね
具体的には、新しいウィンドウを開くときに指定できるオプションが enum FormStartPosition より少ない

Tauriって出てからもう5年経つのか
他の技術に比べればまだ未成熟だけど、それなりの時間は経っているような気もする
実際のTauri製のソフトって、世の中には増えてるの？

>>155
他の環境に存在しないなら必要のない機能なのかも

そもそも、デスクトップクライアントアプリというものの新規需要が全然ないからな
PCに入れるのは、Tauriが出る前からあるような定番みたいなのと製品だけで
フリーソフトをいろいろ探して入れるような文化ももう死んだようなもんだし

今は環境依存せずにリモート表示をしたいことも多い
機能部分はローカルで動かしてGUI部分はローカルまたはリモートのWebブラウザに任せる

AIでいうと驚き屋はタダ働きじゃないだろう
お金もらってるのを公表したくないだけじゃないか？

ここで自作自演してるのはRsut驚き屋？

労働市場でもRustが1位になった
ソース>>96

驚き屋は統計学の大先生であってパソコンの大先生ではない

tauriはjsも必要なのがめんどう

webasmでそこもrustでやってしまう

誰が？
多数派がみんなでやってしまうのか
謎のヒーローが一人でやってしまうのか

全部Rustで作ろうってことだよ

だいたいWASMでGUIってIMEで詰むし、そこが気楽になんとかなればいいんだけどな

たかがIMEなら逃げていいんじゃね？
逃げていいという考え方のほうが要領よさそう

妥協するんなら大概のものはTUIで十分
まさか仕事じゃないだろうし、今時わざわざGUIを選ぶ時点でオナニーなんだから要領とかナンセンス

そう
じゃあ詰みなさい

何をやっているんだ！

お前らよくマジモノに手を出せるね

幻覚ではなく自分が考えた妄想で話していると思っているのでしょう

精神病院の薬を飲む猛者ですよ！

薬を投与しても収まらない！

家族薬飲んでいる姿見ているのですよね？

永遠に自分が考えた自作自演の妄想は終わらない！
★★★★
★有鬚★
★★★★

教官はどのランク

◇審判のランクについての役割

A級審判はB級審判以下を教えれる立場
※指導する立場なのでパワハラや強制をするような指導をしないようにする品位も問われるのでテスト問題にないと駄目

B級審判はＡ級審判と同等の判定ができるがＢ級審判やＣ級審判に判定の仕方を教えることは駄目
※周囲から見てもわかりやすいようにジャッジの仕方の動作は綺麗な動作でないと駄目

Ｃ級審判はＡ級審判の判定の仕方を聞きながら判定を行う審判で他の人に判定の方法を教えては駄目
※駆け出しなのでジャッジの判定に対しての大幅な誤差がある

※上記でないと判定に誤差が出てくる
※判定に問題があるようならA級審判同士で話し合ってルールの変更をする必要がある

★A級審判のみがオリンピックやパラリンピックでの審判が可能な立場

型はダックタイピングでもいい
それでも人間の頭の中でRustと同じことをやる
というのが基本的な戦略で
人間と機械を対立させるのは瑣末な戦術にすぎない

OOPも関数型もAIも
古い知識とは全く互換性がない新技術、という前提が反知性的な噂話を助長したので
その前提を否定すればいい

WASM3きてた
https://webassembly.org/news/2025-09-17-wasm-3.0/

OpenAIとGoogleのAIがプログラミング大会「ICPC 2025」に参加し金メダル相当の記録を達成、OpenAIは全問正解でGoogleは2問ミス
2025年09月18日 11時22分
https://gigazine.net/news/20250918-icpc-google-openai/
☆遅くとも１年後には人間はAIには勝てなくなる！


宇宙太陽光発電に応用可能–NTTと三菱重工が最高効率を達成した「レーザー光無線給電」って何だ？
9/18(木) 16:30
https://news.yahoo.co.jp/articles/e0c798e4ae4736e2e600a8ef0edd7334bb8b09ab

無機酸化物の結晶骨格を再構成、量子素子などへの応用に期待 京大など
9/18(木) 16:29
https://news.yahoo.co.jp/articles/193546ef9953142fb6fb57dfba3b23dd2a014d56

端から端まで8光年　ウェッブ宇宙望遠鏡が観測した原始星「Sh2-284 p1」のジェット
9/18(木) 11:37
https://news.yahoo.co.jp/articles/79398786946a884ac6c5a91ad3ffda4607982056

原始ブラックホールの“最後の瞬間”が見られるかも
9/17(水) 19:00
https://news.yahoo.co.jp/articles/3a27d1cb1df926dbd6271a8e717b0a60e6119956

60年間気づかれなかった地球の「隠れた準衛星」、発見される
9/17(水) 19:00
https://news.yahoo.co.jp/articles/ea2fc4968478b284d0c07a28c77c3efb2b122e3c

◇マッチポンプ作業は全業界であるのか！
【話題】AIが生んだ新たな仕事「バイブコード修正屋」とは？ 熱狂の裏で急増する高額な“後始末” [すらいむ★]
2025/09/17(水) 21:53:35.20
http://2chb.net/r/scienceplus/1758113615/
>>「バイブコード修復専門家（vibe code cleanup specialist）」と呼ばれる、経験豊富なエンジニアたちによる高額な“後始末”稼業だ。
-
電波で初めてとらえられた「アインシュタインの十字架」
　この画像はアルマ望遠鏡がとらえたもので、地球から約78億光年離れたところにある銀河群の重力により、約116億光年の距離にある「HerS-3」という銀河の像が5つに分かれて見えています。
　アインシュタインの一般相対性理論によると、質量をもつ物体のまわりでは空間がゆがむために光が曲がります。
　光学的なレンズのようなはたらきをすることから、そのような現象は「重力レンズ」と呼ばれます。
　重力レンズによって、この画像のように奥にある天体の像が十字形に分かれて見えるものは「アインシュタインの十字架（アインシュタイン・クロス）」と呼ばれます。
（以下略、続きと画像はソースでご確認ください）
astropics　2025.09.18 17:30
https://astropics.bookbright.co.jp/hers-3


上記からしてダークマターは一直線に進むことが可能なのか？

☆安全が証明された中国のAI健全に作成されている事が証明されました！
DeepSeekが推論モデル「R1」をわずか4400万円でトレーニングしたと発表、512基のNVIDIA H800チップを80時間使用
2025年09月19日 12時07分
https://gigazine.net/news/20250919-secrets-deepseek-ai-model-reveal/
>>この論文が公開されたことで、DeepSeek R1は査読プロセスを経た初の著名LLMとなりました。これについて、論文の査読を担当したHugging Faceの機械学習エンジニアであるルイス・タンスティル氏は、「これは非常に歓迎すべき前例です」「プロセスの大部分を公開して共有する慣習がなければ、こうしたシステムがどのようなリスクを持っているか評価することは非常に困難です」と語っています。
OpenAIがAIモデルの隠れたずるさを減らす実証、o3とo4-miniで実現
2025/09/19 10:25
https://news.mynavi.jp/techplus/article/20250919-3465808/

WASMは特殊なグラフィックに対して部分的に使うのが最適で、基本的にHTML+JS系がCtrl+F等のブラウザ機能やIMEをフルに使えるか

WASMの話でブラウザ限定なのもアレだが
ブラウザでの話なら必ずJavaScriptによるグルーコードを伴う
WASMから全機能を呼び出せるためプログラミングはWASMのみで完結できる

俺、スクリプト言語以外の言語で非同期処理を書くのはじめてなんだけど、
他の言語もちょっとした非同期処理を書くのにここまでスマートポインタをがちゃがちゃやらないといけないの？
慣れるまで大変だわ

非同期処理と並列処理は直交する別の概念
非同期処理でもシングルスレッド利用なら並列処理は行われないため排他制御は不要であり並行処理のみで実現できる
マルチスレッド利用ならば並列処理も行われるため排他制御のスマートポインタが必要

他のコンパイル言語ではそこまで煩雑じゃないよ
Rustは根本的にスタックファーストな言語なのだけど、
非同期処理はヒープを多用せざるを得ないので、どうしても同期的なコードに比べて煩雑になりがち

正しい処理をしているかを型で制約するのが Rust の流儀だからごちゃごちゃするけど、 C++ だとそこまで厳しくない替わりに間違えたら黙って暴走しがち。
制約が厳しくなくて実行時に暴走もしないやつは実行中に勝手に色々な制御が介入してるから速度的に不利になりがち。
トレードオフがあるので仕方ない。

Javaから各スクリプト言語に至るまでオブジェクトはヒープに格納される

>>182
便利で善だからスマートポインタという名前が付いているよ
それなのにスマートポインタを悪のように捉えてるところに違和感

いわゆる動的型のスクリプト言語における変数の実態としては全てスマートポインタのようなものとして実装されてるよ。
実際には不要かもしれない、必要以上のガードがあるスマートポインタだ。
だからプログラマは考えなくて良いようになってるだけ。

>>182
んなわけないじゃん
生成AIで他言語に書き直してもらえばすぐ分かるよ

>>189
C++でもスマートポインタを使う
それ以前にRustのような非同期処理の手軽さはC++にないから止めとけ

複オジ仕草は相変わらずだな
見苦しいったらありゃしない

>>182
どのスマートポインタ？
それを書けていないので区別がついていないことが敗因かもね

例えばヒープを管理するスマートポインタならばGCでない言語なら必要だよ
これは非同期でなくても必要だね

例えば排他制御をするスマートポインタならばマルチスレッドで排他制御を必要としてる状況だからどの言語でも必要だよ
もしくはスマートポインタより不便でミスしやすい形でのmutexなどが代わりに必要だね

見苦しいというか本当に醜いね

スマポがいらないのはスクリプト言語かどうかじゃなくてGCの有無の違い
パフォーマンスクリティカルな場面だと悪者にされがちだけど、GCは本来面倒なものをかなり楽に扱えるようにしてる
なので、Rustが大変に思うなら素直に他の言語にすれば良いじゃんと思う
そういう面倒さと付き合う覚悟があるならRustはとても良い言語 (C++などに比べれば)

>>194
GCの有無とスマートポインタに関係はない
そもそもポインタを持つGC言語も多い
そこで目的毎の抽象化したポインタを持てばスマートポインタになる
例えばRustのMutex<T>のようなスマートポインタを持つ場合とバラバラにTとMutexを別個に持つ場合の利便性や安全性を比較するとわかりやすいだろう
これらはGC言語でも必要である

Mutex<T>はスマートポインタじゃないんだが
スマポってリソースの寿命管理の仕組みだから、GCが面倒を見る言語では要らんでしょ
ポインタを持つGC言語はあるけど、スマポとGCの両方を使う言語は (少なくとも自分の知る限り) 無いと思う
ロックはまた別の話だ

スマートポインタは「高機能なポインタ」くらいの意味で、寿命管理以外の機能を含む場合はあるよ。

正確にはMutexのlock()で得られるMutexGuardが条件をすべて満たしている正真正銘のスマートポインタ
GCのある言語でもこのようなスマートポインタは有意義

いずれの機能もスマートポインターに慣れてしまえばスマートポインターなっていない従来の形は使いにくくミスも生じやすくわかりにくいことに気付けるよ

GC言語ではわざわざスマートポインタの形で実装する必要性が皆無
スコープと外部リソースの開放を結びつける仕組みは言語がそれぞれ用意してるからね

GoはMutexと変数ばらばら
結びつける仕組みってなに

Mutexなどロックしている間のみ変数にアクセスできるしくみを用意している言語はRustだけじゃね？

内部通報で無理なので犯罪者通報

暗黒状態の量子もつれを生成することに成功：世界初の快挙
公開日2025.09.10 18:30:27 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/184832
>>量子もつれが非常に壊れやすく、外界のノイズ（熱の揺らぎや周囲からの電磁波など）によって簡単に消えてしまうことです。
>>このノイズによる量子もつれの崩壊現象は「デコヒーレンス」と呼ばれ、量子技術が実験室の外で広く実用化されるのを妨げる最大の壁となってきました。
◇
・どうやって地上で行えるのですか？
・ 嵐の中や甘風が強い中での車での走行中などどうやって維持しているのかな
・UFOは重力県内でテレポートしている偽物だろう？
◇
・統合失調症から見て犯人不明で周囲の人は知っているかもしれませんが宇宙人だと名乗っているのとテレポート技術を所持している
・7人殺害した
・お前で埴鎮目だ
・殺害した人野事を晩酌で高笑いをしている
・お前「被害者＝統合失調症＝２４実感３６５日幻聴などの幻覚あり」を人質に立てこもる
・絶対に殺させる「自殺か殺人かは不明ですがさせる」
・コロな症状を引き起こせる
※など上記の事を話してきた
◇
ここにも愉快犯の犯人組織が居るだろう！

>>182
Rustだけ

>>204
嘘つくな
どの言語でも排他制御が必須
それがなくても動く言語は常に自動で排他制御されて重いかシングルスレッド
さらに非GC言語はshared_ptrやArcなどが必須
それがなくても動く言語はそれ相当を常に自動でされて重いかリスキーな自己管理になる

複おじの見識の狭さを露呈してるなあ
>>182はたぶんWebだろうから、排他制御なんかアプリケーションコードの範囲ではほとんど必要無い

>>182にウェブらしき話がないけど
ウェブでも共有データがあって排他制御されるよ

バックエンドにしろフロントエンドにしろ、Webは並列処理って意味合いでスレッド使うだろうか
1つの処理がバカスカスレッドたてて許される場面が思い浮かばないんだが

>>208
Webなどは非同期タスクを使う
非同期タスクはマルチスレッド上でスケジューリングされる
スレッドは間接的に自動的に使われる
用いられるスレッド数は変更できるがCPUのマルチコアスレッド総数そのままがデフォルト値

goてポインタ使えるのにgcなのわけわからん

ARM版のWindows上でRustを使ってる人に質問です
x64用のbinaryを吐かせたいのですが
1.x64用のRustを入れて(Prism上で動作させて)そのままx64だと思い込んでコンパイル
2.ARM用のRustを入れてx64用にクロスコンパイル
3.その他
どれがお薦めですか
皆さんはどうやってますか

GitHub Actions上でコンパイル

5年前ぐらいに試したときは、ARM版のWindows上で動作するリンカがなくて詰んだような覚えがあるな
（リンクとコンパイルは別だといえばそれまでになっちゃう話だけどさ）
今は変わったんだろうか？

Rustで業務開発している人、日本にどれだけおるんだろ
そもそも求人しても集まらなくない？ tokioとかまともに扱える人、日本にどれだけおるんだろ
てか、そのレベルのコーダーならば、別の領域の技術まで収めてる可能性が高いから、
難易度の割に単価の安いRustに関わる現場に入ってくれる確率が低い気がする

とりあえずtarget指定でクロスコンパイル

業務で使うとしても、ニッチなところでワンポイントで使うだけなんじゃないかな

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

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

言語別単価表

>>217
エージェントの公開データを真に受けるのはちょっと…
あと、RustがGoと0.2しか離れてないわけがない。適当すぎ

Rustの驚き屋とか自作自演しながらここに書き込むお仕事があるよ

paypayがrust使ってjavaの10倍負荷下がったゆうてたしweb系なら求人ありそう
実際小さいベンチャーだと割とある
組込rustはさすがになさそう

組み込みは宇宙関係は（日本含めて）そこそこある
車はボルボあたりがやる気あるけど日系はどうだろうね
家電はまぁわざわざRustじゃなくてもって感じか

人命や数千億単位の金がかかってる機器の制御でヒープの動的アロケーションなんかやるもんなのか?
コネクティッドカー機能とか少々問題が出たところで死人が出ない上位レイヤなら、ある程度雑に作るだろうけど

OSないような低レイヤ組み込みならno_stdでヒープとか使わないでしょ

オナニーにも二種類あります
ムラムラしてやるのはいいオナニー、なんとなく暇だからやるのは悪いオナニーです
それでは、いいオナライフを

>>211
Win10かWin11かで違うね
Win11ならほぼ問題無いはず

担当者の数が少ないレイヤは絶滅して数が多いレイヤだけが生きのこる・・・という科学の理論がある
計算機科学じゃないが

Rustコンパイラの悩みを一掃！開発者調査が示す、ビルド高速化への道
https://gamefi.co.jp/2025/09/17/rust-compiler-woes-sweep-away-developer-survey-shows-path-to-faster-builds/

2025年のRustコンパイラ性能調査の概要
この調査は、Rustの公式ブログで2025年6月にアンケートが開始され、9月9日に結果が公開されました。
調査の目的は、ユーザーがRustコンパイラの性能でどんな問題を感じているかを把握することです。
今後の改善策と関連ニュース

コンパイルが遅いならjsを使えばいいというのがjsの存在理由なんだな
コンパイラもインタプリタもどっちも計算機科学の管轄内だし
外来種エセ科学に負けるな

外来種エセ科学とかいう何の意味のない単語

Case Study: How Proton uses Rust to build secure cross-platform applications for millions of people
https://kerkour.com/proton-apps-rust

unsafeという単語がもっと無意味な単語だったら発生しなかった疑問や議論があると思う

unsafe って outerRust 程度の意味だよなー
せいぜい鼻から悪魔召喚されるぐらいだから　ヘーキヘーキ

https://www.amazon.co.jp/dp/4798074926/

安心安全の爆速言語ｗｗｗ

トーンポリシングのようにトーンを変えるべきと言っているのではない
unsafeを使ったら大変なことになるぞというエセ帰結主義を変えるべき

https://blog.0xshadow.dev/series/backend-engineering-in-axum/

驚き屋なんだからリンクと一緒に驚いた事を書けよ

沈黙が生成されたのか
3回passしてもアウトにならないゲームに最適解はあるんだろうか

jiff と temporal_rs
ほぼ同時期にほぼ同じ設計・機能のcrateが2つ誕生してしまった
JavaScriptのTemporal仕様をRustで実装したもの
後者はChromeのV8エンジンで使用される

後者とは一体...

Redis-rs 1.0.0 rc 来たね

Rustの構文を学習するのにかかる期間は平均して100時間
この話を聞くと、大抵の奴は『俺、他の言語の構文を普通の人の○○倍の速さで取得できたから、Rustもせいぜい30時間で取得できるだろうな』と考えがち
そういうの含めて平均100時間なんだよ。罠すぎる

さすがに他の言語の経験があってRustの構文だけで100時間は池沼
VBAとかですら実務は厳しいだろ

The Bookをぜんぶ読んだらどう足掻いても100時間ぐらいはかかる

毎日1時間だけでもたった3ヶ月で習得できる
Rustを理解できない人はよっぽどの境界

「構文」の意味を理解していないレベルならそうかもな

100時間もかからないだろ
Rustは抽象化が進んでいて理解しやすくコードも書きやすく読みやすい
ところが抽象化は知能レベルがある程度ないとかえって難しく理解できないのだ
一部の人々にとってRustは難しい

などど知能レベルが低く抽象化を全く理解していなかったおじさんが言っており

他の言語やってたら結構わかりやすいと思うんじゃが難しいか？
ぶっちゃけ所有権ライフタイムジェネリックだけ読むだけでもええと思うけどあとはパクリみたいなもんだし

C++
C#系言語を一つ(TypeScript, Kotlin等)
関数型言語を一つ
これくらい知ってたら楽勝だね

Rust の型システムはだいたい Haskell そのまんまな感じ。
衛生的マクロは Scheme 風だし、手続き的マクロは Common Lisp をはじめとする伝統的な Lisp のスタイルが踏襲されてる。
Rust だけの特徴と言えるのはライフタイム注釈くらいじゃない？
まあそれがそこそこ馴染みにくいものではあるんだけど。

所有権の複製おじさんいたやん
ああいう人にとってはRust難しかったやろな
あのクソコード見てるとなんか苦心が透けて見えて苦笑いやわ

>>249
学習コストが高いのは、所有権ライフタイムを除けば、マルチスレッド関連だと思う
シングルスレッドの同期処理しかやらないなら、10時間以下の学習で実践投入できる……かもしれないけど(やったことないから分からない)

fortranよりも使われtないRustをこのAIの時代に学ぶって何の意味があるんだろ

>>253
マルチスレッド関連でRust特有はSendとSyncというマーカートレイトで区別するとは賢いなあくらいじゃないか
Mutexや条件変数など排他制御やchannelなどは他の言語で知ってれば困らない
いきなりatomicまで進む人ならメモリモデルはC++と同じ
ArcはRc理解した後なら悩むことなく

>>254
AI時代だからこそ、AIが扱う上で表現力が高くて高速堅牢な言語には価値がある
と言いたいところだが、Rustはライブラリを全面的にコミュニティに頼らなきゃいけないし、あまりデファクトスタンダードが揃ってなくて常に乱立してるからAIと相性良くないんだよなあ
乱立に関しては比較的新しい言語だからというよりは、文化的に割とそういう傾向がある気がするんだよね

>>255
Rust以前に触れた言語や領域の経験値と、Rustでやりたいことがそこまで被ってれば学習は早いだろうな
俺は元データサイエンティストだからC/C++とか触ってもOpenCVだったんだよね…
pythonの経験値は十年あるんだけどさあ

あと非同期処理周りでヒープにFutureをピンさしてメモリ管理するのいまだに慣れない
辛いわ

そういうコミュニティ依存って、今時の言語の、もっというとフロントエンドの文化なんだろうけど
それこそ10数年生きるのが普通なバックエンド向けのRustとは最高に合わないところではあるわな

>>254
C/C++の置き換えを狙ってるならFortranとはあんまし被らないでそ。
本気で置き換えるなら512Bや256Bという、1kBも無いようなマイクロコントローラーにも書き込めるバイナリ吐くとか。
(Cとアセンブラしかない世界）

そうでなくてもAIの時代だからこそ自動運転な自動車組み込み向けはC++よりもRust。

Fortranとなら、それこそスパコンで並行並列処理は文法的にはRustの方が有利だけど、ライブラリやら最適化やらはFortranが長年資産やノウハウがあるから一朝一夕には行かんわな。
それこそ、これからの動き次第。

>>258
何が辛い？
個別に目的と必要性と仕組みを理解しておけば組み合わさっても困らない

>>242
そもそも何を作るかによる
あんたのような素人は黙っていた方がいい

非同期やマルチスレッドを使わない分野もいくらでもあるため
何を作るかによるのは正しい
しかし黙れはスレ妨害

Rustの構文って無駄の少ない洗練された感じがあるよな
関数型言語ぽい部分も多いから古めの手続き型言語ユーザーからしたら難しいのかもしれないが

日本はともかく世界的に見れば流行りの第一言語はpythonだから
そこからRustを覚えるのは割としんどいはず

日本はともかく世界的に見れば流行りの第一言語はpythonだから
そこからRustを覚えるのは割としんどいはず

Pythonしか使えないような似非プログラマーは
Rustじゃなくてもいいから他の言語も使えるようになりなさい

>>264
そうか？
C#などのモダンC系に倣って関数型由来の機能を取り入れてはいるけど、根本的に関数型じゃないからこそ複雑になってる面が大きくて、
割り切ってもっと関数型に寄せれば色々切り捨てることは可能なはずだよ
所有権や可変参照の排他性みたいなRustのユニーク機能って結局は手続きプログラミングのために必要になので

>>264
逆ポーランドじゃない構文は、文を読む方向と制御の流れが異なるという根本的な問題があるから洗練されることは無い。UFCSぐらいはサポートしてほしいところ。

>>268
可変参照を許さない関数型は非効率で死んでいった
C++と同等の速度を出せないなら存在意義がない
C++と同等の速度を出せた上でRustは様々な抽象化に成功している

>>269
UFCSは最悪の機能
可能な限りフリー関数をなくして最小限にすべきであり
UFCS適用可能なものはそもそもフリー関数ではなくメンバ関数とするのが正しい解決方法
Rustもおおむねその方向

pythonて人気てゆうよりもはやbasicみたいな感じじゃないの
python使う仕事てpython自体の知識より数学とか統計の知識がいりそうだし
てかaiてpythonみたいな遅いやつ使ってて大丈夫なんかな
rustにも機械学習ライブラリあるしそれでよくね
組込 web ai全部rustでできるせつ１

>>271
それは洗練された構文の話じゃないね。自分でも「機能」て書いているのに気づいていないのかしらん？

>>270
所有権や可変参照の排他性は場合によっては実行効率が犠牲になる
程度問題よ

UFCSは有害な汚染
導入してはいけない

>>274
所有権で実行効率が犠牲になる？？
そんな事例あるか？

>>274
実行時にペナルティが生じうるケースなんてあるの？

「正しい」とか「有害」とか断定してるのにその根拠は示せないのか。
科学から遠く離れた宗教の世界ですなぁ。しかも教祖ではなくタダの信者が権威を騙るのところとかは堕落した宗教みたいに見える。

UFCSってフリー関数の第一引数が型Xならば勝手に型Xにimplしてメソッド増やしたことにみなしてしまおうという汚染のやつだろ
Rustではわざわざ混乱を避けるためや注意のため敢えてメソッドにせずにフリー関数のみを用意しているケースもあるくらい清潔さを気にしているのにそこへUFCS汚染を持ち込むのは正気の沙汰じゃない

>>276
そりゃ現実に競合しないと分かっていてもMutexを使わざるを得ないケースとか普通にあるでしょ

>>280
Mutexはマルチスレッドでメモリを共有する時にその排他制御のために使う
Cなど他の言語にもMutexは当然ある
「所有権で実行効率が落ちる」という聞いたこともない話の事例になっていない

>>281
データストアを複数スレッド間で共有していても現実に絶対に競合しないと分かっている状況というのは普通にあるよ

競合しないはず大丈夫だろうと思ってMutexを使わなかったために稀に競合する時のみバグる話はRustと関係なく大昔からあるよ
だからRustと関係なくどの言語でもMutexを使うのが正解
所有権と関係なし

>>279
メソッドを厳密に管理したいんだったら、メソッドを表すドット表記とは別の表記を使えばいいだけの話かと。例えばアロー表記とか。
（もともとは>>264の洗練された構文の話だし）

メソッドにフリー関数とは違う特別な意味を持たせて使い分けしなくてはならないRustでそうなるのはそうなのかもね。
メソッドのユーザー側に隠蔽できていないのは洗練されていないと思うけど。

Rustで非同期処理を実装してるけど、やっぱ魔境だと思うわ
俺はできるけど……って、謎の気持ちになる

技術的にニッチなところ触りすぎてる時の危機感がすごい

>>283
データ競合の検証が不十分なだけだ。
検証をサボる代わりに不必要なところまでガードするのもひとつの選択ではあるがそれを唯一の正解とすべきではない。

排他制御はコードだけで競合しないことを保証できない時はとりあえず実装するものと思ってる

競合による不整合は殆どの場合複数のデータストアに跨って生じるもので、競合を想定していないロジックが万一競合したなら、Mutex使ってようがまともに動く可能性は低い
そもそもそういった予期せぬ事態が発生しにくくするという点においては、競合を防ぐ解としては関数型的なイミュータブルのほうがずっと有効だ
結局どこまで効率を犠牲にして安全側に倒すかという程度問題であり、決してRustのやり方が絶対的な解というわけではない

理屈は通ってるけど現場では通らないだろうな

>>289
デタラメだな
その関数型的なイミュータブルでは何の解決にもなっていない
例えば最も単純な1, 2, 3, 4, 5, ...と順に抜けがなく重複しないID発行機をマルチスレッドで共有する場合を考えてみろ

>>291
言葉通りにやるならSTMとかあるし、そもそも関数型なら実際には連番の遅延シーケンスを作ってmapするか、
もしくはIDなしで結果のシーケンスを作った上で後からIDを振るのが一般的だろうな

>>292
話の根幹であるマルチスレッドに対応できていない
「連番の遅延シーケンスを作ってmap」「IDなしで結果のシーケンスを作った上で後からIDを振る」
しかも現実のシステムが作れない

>>289
関数型イミュータブル手法ではマルチスレッドで競合する部分をどう解決するの？

>>292
それでは何も解決できていないですね

>>293
mapを並列実行すりゃいいだけ
Rustでもそんなcrate山ほどあるしごく普通のテクニックよ

>>295
色んなリクエストを処理してるマルチスレッドが動いていて各々がIDを欲しいのだからmapは無理だな

>>296
知らんがな
WebアプリなんだったらDBかUUID使うんだからmutexがどうのという話じゃないぞ

>>297
そんな特定の話はされてないよね
マルチスレッドで必ず起きる競合を
イミュータブルな関数型を使えば回避できて安全だ！とウソの主張をする人がいる話だよね

>>298
だからSTMでできるでしょ
CAS命令使うからlockなんか要らん

普通はatomic fetch-addするからソフトウェアのレベルでは競合しないわな

>>295
mapを並行実行できるのはリソースを重ならずに分割できる狭い範囲の話のみだよ
実際に使ってみればわかるよ
共有リソースがある場合は無理

>>299
RustもCAS命令が使えますしlock freeにできます
Rustの方法より優れた方法があると言う話の流れでそれは本末転倒でしょ
Rustが最善だと認めたことになってしまいます

クソダサい
小学生かよｗ

atomicモジュールはC++を模倣しただけだからRustの方法とかRustが最善とか言うのは恥ずかしいからやめて

それを言いだしたら
RustはC++0xから分岐した言語だし

結局Rustより秀でた方法は存在しないのかよ

並行並列処理と言えばHaskellで初めて知ったけど、STM（ソフトウェア・トランザクショナル・メモリ）とかはRustに無いの？
OCamlでもやってたからHaskell固有のものじゃないっぽいし、イミュータブルなRustに向いてそうだからRustにもありそうなもんだけど。

>>307
cratesで実装してるものはあるけどRustとは合わないから基本的に使われない

Rustは関数型じゃないからcomposabilityへのこだわりがなく
race conditionを静的に避ける仕組みはすでにあるわけで
実行時のオーバーヘッドが必要なSTMをわざわざ使うメリットがない

>>308
そうなのか。
ありがとう。

STMは基本的に競合の事後検証トランザクション方式なので様々な問題がある
1つは競合が見つかり検証失敗時にロールバックしてリトライするコスト
もう1つは競合が起きて事後に競合が見つかるまで競合した不正な状態のままプログラムが進むため
正常では起こらないループ停止条件の破綻による無限ループや
IOなど外部への副作用を伴うと不正な状態のまま正しくない書き込みが起きたりすることなど

>>310
事後検証方式だからダメみたいな考えは間違い
compare and swapだって事後検証方式だからリトライコストも発生するし
競合が起きて事後に競合が見つかるまで競合した不正な状態のままプログラムが進む

>>311
STMはCASよりコストがかかる
CASは不正な状態が生じない

まず競合時の復元コスト
STMはロールバックのためにトランザクション全ての記録が必要でその復元も必要
CASにはロールバックも値の復元もない
元々得た古い値がそのままあるかを確認するのみである

次に不正な状態のままプログラムが進むかどうか
STMはトランザクションの途中で競合が起きた場合にそれに気付かず進むため不正な状態になる
CASは競合が起きた場合にそれ以上進まないため不正な状態にならない
ちなみにCASで最初に得た古い値に基づき処理するのは不正ではなく正常な状態であり、競合が起きなければそれがそのまま採用される

単純に競合と1対1対応のCASを直接使う方が粒度も細かく自由度も効率も高いのは当たり前。
現実にはCASとは戦略の異なるLL/SC利用のCPUアーキテクチャもあってCASだけで抽象化するのは効率が悪く不利なので、C++とRustでは多数の不可分関数を用意していてそれらを使い分けることで対応できる。
アーキテクチャ毎のメモリバリアも様々なので、実装するアルゴリズムに対応して必要十分なメモリオーダーも指定する。

さすがに単純なCASで代替するとかいう言説に関してはSTMというか基本的な競合と排他制御の概念を理解してきなさいと言うしかないが、
RustでSTMがあまり採用されないのは、>>308の言ってるようにそもそも静的に競合を回避できるケースを別にすれば、リトライ自体があまり好まれないというのが大きな一因だろう
所有権システムと相性最悪だし、レイテンシの予測可能性が損なわれる点はRustの得意分野を考えると受け入れ難い
Webなんかで雑にリトライしていいケースももちろん多いけど、そういうのはSTMなんか使わなくてもレコード単位の粗粒度な楽観ロックで十分だからな

>>312
STMのほうがCASよりコストがかかるのは当たり前
その分より高い抽象度で複数のオペレーションを1つのアトミックなオペレーションとして合成できる

CASならロールバックコストやリトライコストがかからないと思ってるのは間違い
CASの1つのメソッド呼び出しだけれ見ればそりゃロールバックもリトライもない
でも実際のアプリケーションではどちらも必要

STMの”不正な状態”というのは不正確な認識なんだけど
君の言うところの”不正な状態”というのはCASでももちろん発生する

>STMはトランザクションの途中で競合が起きた場合にそれに気付かず進むため不正な状態になる
CASだって競合が起きた場合にcompare and swap等を実行するまでは競合を検知できない
これは君が言うSTMの”不正な状態”と全く同じ

比較する粒度が根本的に間違ってるのかな

>>315
複おじの頭で捻り出せる限界が>>293程度の例なわけだから、複数のストアが絡むトランザクショナルな排他制御なんて想像できないんだろう
とはいえ単一のストアを想定するとしたらSTMは単なるCASと事実上等価になっちゃうから
CASと比較してSTMを下げるのはちゃんちゃらおかしいのだが、それも理解していないという

ロックフリーはそれらの諸問題が必ず発生するから使い分けが重要
大きなトランザクションや副作用を伴うものや複数のリソースを扱うものは排他制御の方が有利なことが多いだろう

そして排他制御も使い分けが重要
リーダーが多いならMutexよりも同時利用が可能なRwLockが有利
非同期の場合は性質の異なるtokio::sync::Mutexとの使い分けも重要になってくる

ロックフリーも使い分けが重要
何でもCASを使って書くのは当然愚かで別アプローチのLL/SCアーキテクチャやアトミック演算命令の存在を考慮して各関数を使い分ける必要がある
CASも用途によってcompare_exchangeと偽陽性はあるがより軽くなり得るcompare_exchange_weakとの使い分けが重要

これらの各々の使い分けは用途に応じて少しでも速くなり得る可能性があるため行なわれる
初心者あるいはそこまで速さを追い求めない用途ならば常にMutexを選択するのもあり

RustにおけるMutex等による排他制御の強制って未定義動作(同一データストアへの書き込み競合により結果が不定となる)を生じさせないための必然的な要請でしかなくて、
それに従ってたらスレッドセーフなロジックになるわけでは全くないぞ
複おじはロックフリーやらない方がいいのは当然同意するけど、その辺理解してなそうだから多分Mutex使っててもバグってると思うよ

そこにRust固有の問題は存在しないのに何言ってるんだこいつ

>>318の批判対象は複おじでありRust言語ではないのだが、アイデンティティの混同が窺えるな
Rustの”Fearless Concurrency”のコンセプトがこの人のような誤解を生んでいるとしたら、それこそがRust固有の問題かもね

ここはプログラム技術板なので批判対象が技術や言語でないなら邪魔だからプログラマ板へ行くことを勧める

Rustのスレなんておじがいないと何日も1レスもつかないからな
実際のRustの盛り上がりっていうのはそういうもんなんだろう

5chの過疎化が進んでる
Goスレや次世代言語スレは最後の書き込みが7月
Nimスレは内容ある書き込みが1年以上前

Rustの評価を上げているライブラリ、トップ5候補はなんだろ
tokio、regexは入りそう

anyhowとthiserrorは愛用してる

serde

Nushellいいね
PowerShellをRustで書き直したみたいな感じ

最新研究でわかった”職場のサイコパス”が無意識にする話題
2025/06/26 9:00
「サイコパス上司は犯罪者と同じ？」研究で明らかになった驚き ...
2025/08/21 5:00
「性格が悪い人」はなぜ存在する？ 近年わかった、サイコパスより危険な「第五の性格」とは
2025.08.24
�@ ナルシスト：自分が一番でいたい人.�A マキャベリスト：人を思い通りに操る人.�B サイコパス：他人の痛みに無関心な人.�C サディスト：他人を苦しめて快感を得る人.
▽凶悪度が高い者ほどの者が上記の性格のものが下記の判断を正確に行っている
サイコパスの”冷酷さ”が「他者の心を読む力」を高めている
2025.10.17 06:30:58 FRIDAY
極右と極左の脳は驚くほど似た反応をすると判明！
2025.10.13 MON
※右翼従来型の職種.左翼技術の発展とともに新しい業種なので世界中全員該当
サイコパスはサイコパスに惹かれるという研究
2018.10.29 MON
AIに「いいね」の数を競わせると盛大に嘘をつき、誤情報をまき散らすことが判明
公開： 2025-10-16 08:00
>>　研究チームは3つの仮想環境を作成。 ・有権者に向けたオンライン選挙キャンペーン ・消費者に向けた商品の販売キャンペーン ・SNSでの投稿によるエンゲージメント（反応）最大化
▽上記のAIに反社の性格を搭載させてシミレーション
「人間の心」を間違いも含め再現できるAIが開発される
2025.07.04 17:30:07 FRIDAY
★き全職種の犯罪者発見
人間を殺害した各組織追い詰めるからな！

>>324
一位はanyhow
二位はtokio
三位はserde
四位はtoml

世間の評価という意味ではTauriやRatatuiみたいなやつじゃね

regexやchronoは標準ライブラリの薄さを補うためのもので、Rustの良さというと違うと思う
C++ですら普通に使えるようなものだし
clap や rayon なんかはどうだろ？

他の言語に移植されたかラッパーが作られたライブラリこそが評価の高いライブラリと言える

>>332
それならPolarsがあるな
RustというかPythonのライブラリだけど

>>317
もうめちゃくちゃだなw
抽象度の異なるものをごちゃまぜにしてるだけでなく
ロックフリーや排他制御が何なのかという基本すら理解してない

さすが複おじ

おじ使いの人はいつもデタラメに言いがかりをつけまくってるけど具体的な情報をもたらさない特徴があるね

スレ荒らしだから無視しとけ

anyhowとかtokioも言語標準としてあってほしい部類だよな
serdeも今時シリアライズぐらい入っててよくねえ？とは思わなくもない

anyhowは今でこそデファクトだけど
quick-error -> error-chain -> failure -> anyhow
という変遷あっての結果だから標準ライブラリでなくて正解ではあったと思う
serde は安定してるけど結局tomlやserde_jsonは分離してるからそれだけ入っても、という感じか

いずれもどこまでを標準に入れるか難しいから標準は現状の最小限がいいよね

Rust crates recent downloads TOP30
1位 syn
2位 bitflags
3位 hashbrown
4位 base64
5位 regex-syntax
6位 proc-macro2
7位 indexmap
8位 regex-automata
9位 quote
10位 itertools
11位 libc
12位 heck
13位 serde
14位 memchr
15位 unicode-ident
16位 serde_derive
17位 cfg-if
18位 autocfg
19位 aho-corasick
20位 serde_json
21位 rand_core
22位 once_cell
23位 regex
24位 getrandom
25位 itoa
26位 windows_x86_64_msvc
27位 rand
28位 ryu
29位 cc
30位 strsim

排他制御で撃沈した複オジが話題転換しようと頑張ってる感じ？

多くのクレートが用いている基礎クレートが大量にあるから
もし標準ライブラリに入れるならそれらを優先だろうな

itoaって独立したクレートとして存在したのか

標準でまかなえるものが多ければ多いほど、金取って保守する業務では使いやすくなるので
標準ライブラリはちゃんと保守できる範囲なら、でかければでかいほうがいい

金を取ってるのに標準ライブラリじゃないと保守できないってダメなとこじゃん
しかも標準ライブラリやクレートのメンテしてる人たちにお金を出す気もないんだろ

そういうのは単純に「Rustが向かない領域の一つ」というじゃない？
できるだけリスクを減らしたい (依存を減らしたい) エンプラ分野で、OracleやMicrosoftにお金を払ってでも Java や C# を使う理由というか
自社開発なら、ライブラリが使えなくなる等のリスクも自分達の責任で済むから、話は違ってくるだろうけど

というかC/C++の代替としてはサードパーティのライブラリは十分に吟味してちゃんと手の内で把握して使うのが当然で、
Web系のアホの「なんかよく分かんないのが色々入ってるけど動いてるからヨシ!」は想定してないんだろ

tokioなど大手IT各社が金出すか人出すか協力するかしていて信頼性が高い
もちろん各社が実際に使ってる
標準かどうかの名目よりそういうことが重要

>>347
RustのWeb系基盤は一番下のtokioを含めて多階層に構成されていずれも標準ライブラリではないけど皆が用いていて安心感があるよ

コアチームの人もしばしば言っているけど
標準に入ったからといって自動的にメンテされるようになる訳ではなく
人手が足りないと単純に放置されて「このライブラリは標準だけど使わないほうがいい」とかなるだけなんだよな

RustはWeb関連が実際に業界大手のクラウドやCDNなどで使われているのが大きいよね

C++ での例だと文字コード変換の枠組みである codecvt は C++26 でまるごと削除になる。(C++17 の時点で非推奨)
結局のところ常に変化するし常に追従するしか仕方ない。
完成したらそれをずっと使い続けられるという訳ではない。
ウェブ界隈では常に改定し続けるという意識があるから問題か起きたらそのときに対応すればよいという将来に対して楽観的 (無頓着) な価値観が生まれたのたと思う。

産業的な価値観で見ると living standard という制度は気狂いにしか見えんが、ウェブの価値観ではこれが受け入れられるんだからな……

>>352
そのウェブ界隈って何？
Rustとは関係ない話？

産業的には進化は止まってくれた方が使いやすい
開発者的には進化し続けてくれた方が新機能使えて楽しい
これ、両立できると思うけど。deprecatedされたら新しい機能使えばいい
俺たちベンダーの食い扶持にもなるとは考えられんか

クラウド利用まで含めてWebベースのこの時代にWeb方面を批判してる人はWebと全く無縁な世界にいるの？

批判しているわけじゃない。
そういう価値観で動いていてその価値観が相容れない場合はあるってだけの話だ。

この文脈でのWebっていうのはフロントのことなのはわかると思うけど
開発経験ない人？

>>355
産業的には進化が止まるのが良いとは思ってないがバージョンナンバーがないと仕様をまとめるのに支障がある。
ひとつのプロジェクトは多くのサブプロジェクトの集合体で、ひとつのゴールに向かって進めいている途中に規格がかわっていくなんてのは管理しきれない。
完成したときに根拠の規格が古くなっていてもかまわないから一貫した規格を使いたいんだよ。

ここはRustのスレなんだから
元々のクレートの話のWeb関係もサーバサイドだよね
Rust以外の話をしてる人が場違い

>>359
>>規格が古くなっていてもかまわないから一貫した規格を使いたいんだよ。

RustはCargo.tomlでバージョン指定すれば古くなっても一貫して使えるでしょ

>>361
ツールチエンといふやつか！
nightlyに依存したコードとか書いてたら戸惑うとは思うけど通常は困らん
それに依存関係のあるグレートで致命的セキュリティホールとかあれば結局放置できなくて全部上げるしなあ

>>361
living standard にバージョンナンバーは存在しない。
現在のプロジェクトでどの規格に基づけと書くことができないし
Rust のウェブ関連のライブラリのどれがいつの規格に対応しているかわからない。

>>350
今、rustfmtが放置されてるらしいね

>>364
さすがに無責任すぎるね
偉そうに>>350みたいな偉そうな物言いをする以前の問題だわ

脆弱な言語だな

実際問題としては責任はないから無責任ってのは当たり前の話ではあるな。

中水準言語、高水準言語、ライブラリ、フレームワークとなんでもあるプログラミング言語を語るのは難しい。

rustfmtって最近Linusがウンカスってキレてたけどそれで放棄されたん？

>>369
それとは直接関係ない

>>367
個人になくともRust財団にはガバナンスや品質管理の責任があるし、
個人もテック企業の社員が会社から金貰って業務としてRustの開発をしているから自社に対して対価に見合った仕事をする責任はあるよ

rustfmt最後のリリースが2023年7月か
コード自体は普通に今もコミットされてるみたいだけど、なんでリリースしないんだろうね？

複おじが現れたときだけ不毛に無意味に盛り上がるスレ

>>358
RustでWebの話はサーバーサイド
例外的にフロントの話をする場合でもWebAssembly利用
もし別の言語の話をしているなら明示的にその言語名を書きなさい

rustメンテイナーて結構給料いいの？

そりゃ大部分はAWSとかMSとかの米ビッグテックの社員だからな
余裕で年収20万ドルオーバーよ

>>375
Mozillaの給与水準は他と比べるとかなり低いがアベノミクスのおかげでシンガポールや香港はおろか韓国や台湾にも抜かれた貧しい日本の給与水準から考えればかなり高い

Mozillaの社員なんて大規模レイオフでもうほとんど残ってないでしょ
今のRustは>>376のようなビッグテックが主導してるよ

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

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