25/08/15 17:59:47.23 N8TIzbWg.net
5ch電源断とその際のバグにより
各板の現役スレ一部がタイミングの運で失われた模様
Rustはpart31とpart32両方が現役の状況であった
3:デフォルトの名無しさん
25/08/15 20:39:09.07 55NQaS0p.net
5chのシステムっていまだにperlとかなんだっけ？
4:デフォルトの名無しさん
25/08/15 21:05:50.57 JdtfTdo0.net
誰かRustで5chクローン作ってくれろ
5:デフォルトの名無しさん
25/08/15 21:13:27.00 GcewhsmR.net
>>2
どういうバグ？
6:デフォルトの名無しさん
25/08/15 21:42:40.40 5gemkVLD.net
昔から活発な板でdat一覧ファイル壊れたりロストするから排他制御や落ちた時の途中状態からのリカバリとかザルなのかもね
7:デフォルトの名無しさん
25/08/15 21:48:40.45 XX86qaZt.net
Rustじゃ20年ぐらい掛かりそう
8:デフォルトの名無しさん
25/08/15 22:05:07.21 y6bONxHy.net
2ch初期からあるread.cgiとpostの読み書き基本掲示板機能部分だけなら1日で終わるけど
後から追加した外から見えない部分が絡み合って規模も読めないね
9:デフォルトの名無しさん
25/08/15 22:49:05.86 bbOcnQZV.net
難読よいしょw部
難読宝田真月部
難読オランザピン部
難読肉壺ワッショイ部
難読自己中部
難読承認欲求部
難読ゴキブリ部
難読助かりました部
難読宇宙人部
難読でんちゃでんちゃでんちゃちゃっちゃっちゃ～部
難読カービィ部
難読失敗作部
難読ADHD部
難読自開部
難読多動部
難読在日部
難読糖質部
難読人非人部
難読生まれも育ちもやまゆり園部
難読何ガン飛ばしてんだよオイ！！部
難読池沼部
難読トナラー部
難読表出ろこの野郎！部
難読マウント部
難読ホンモノ部
難読害悪部
難読ガガイのガイ部
難読syamu未満部
難読底辺部
難読インチュニ部
10:デフォルトの名無しさん
25/08/15 23:02:17.30 DXpoUqnv.net
山下スクリプト回りの対策で、エラーが出た時にそれが何故出てるエラーなのかすら
今の5chはもはやアンドキュメントだからな
11:デフォルトの名無しさん
25/08/15 23:41:07.28 GcewhsmR.net
電源落ちたからって前スレまで消えるのは常識的には考えられない動きだけど5chはそういうものなんだな
12:デフォルトの名無しさん
25/08/16 00:28:31.64 yx9F5+UN.net
難読漢字部
ガイジの集まり
くたばれよ
みんなもポケモンゲットじゃぞ
13:デフォルトの名無しさん
25/08/16 00:33:34.28 35qrMgqn.net
>>11
前スレのpart30は過去ログ倉庫へ移動されていたため無事だよ
part31は1000になっただけで過去スレへと隠れてなくて見えたままだったのが不運
14:デフォルトの名無しさん
25/08/16 11:34:10.89 27T353mi.net
チューリップの中で再現性のない部分だけ消えなさい
バブルは消えた
15:デフォルトの名無しさん
25/08/16 15:07:42.32 uzsALVJv.net
難読ロリコン部
難読僕のスマホ返せぇぇぇ！！部
難読とど田とどら部
難読ちぎゅ田ちぎゅら部
難読チーズホビー部
難読お薬手帳部
難読底辺部
難読積極奇異型アスペ部
難読電子障害者手帳部
難読自開部
難読穢多非人部
難読バ漢字部
難読ウィィィィィィィィッス部
難読チギュァァァァァァァァァァァァ部
難読動物園部
難読おかしな奴しかいないんだけど部
難読助かりました部
難読舌打ち部
難読類友部
難読ガイジ(ゲェジ)部
難読スタバ陽キャきっしょ部
難読僕も！僕も気持ちいいことしたい！！部
難読自己中部
難読Fラン大学中退部
難読トナラー部
難読スペシャルオリンピックス部
難読ひまわり学級部
難読ゴミ部
難読弱者男性部
難読アホロライ部
16:デフォルトの名無しさん
25/08/16 17:15:18.32 2ZRl/XaI.net
Check Pointが見つけたと言ってるRust製のWindowsカーネルコンポーネントの脆弱性ってどのCVEか分かる人いない？
URLﾘﾝｸ(blog.checkpoint.com)
URLﾘﾝｸ(msrc.microsoft.com)
17:デフォルトの名無しさん
25/08/16 22:23:23.06 uzsALVJv.net
難読DSM部
難読さす障部
難読さすガイ部
難読動物園部
難読トナラー部
難読よいしょw部
難読ホンモノ部
難読頓服部
難読でんちゃでんちゃでんちゃちゃっちゃっちゃ～部
難読マスターベーション部
難読マウント部
難読ウィィィィィィィィッス部
難読syamu未満部
難読スマホ脳部
難読多動部
難読害悪部
難読電車(バス)代割引部
難読エッホエッホ部
難読てんかん部
難読ディズニー格安部
難読フレンド申請部
難読すいません、3種のチーズ牛丼特盛りに温玉付きでお願いします部
難読水用意しろ水。イライラするわぁ部
難読おかしな奴しかいないんだけど部
難読デスマフィン部
難読コンサータ部
難読ガイジ(ゲェジ)部
難読オランザピン部
18:デフォルトの名無しさん
25/08/17 20:15:25.86 JE2V7bGm.net
Windows更新プログラムﾊﾞｸﾞの温床Rust
馬鹿ｺｰﾀﾞを無理やり矯正したとこで馬鹿が治る筈もなく
19:デフォルトの名無しさん
25/08/17 21:19:09.68 TxHGfZIC.net
バグを無くせるプログラミング言語は存在しない
Rustはプログラミング言語の中では最も様々な安全性を保証してくれる
それ以上でもそれ以下でもない
20:デフォルトの名無しさん
25/08/17 21:22:39.79 JE2V7bGm.net
わかってねぇな
それじゃﾎﾝﾓﾉは育たないことを
21:デフォルトの名無しさん
25/08/17 22:50:15.00 XH7kxkHq.net
Rustは生き物ですらない
育児もディールもしない
22:デフォルトの名無しさん
25/08/18 07:58:05.46 WV63/BRN.net
RustってIT土方専用言語になりそう
23:デフォルトの名無しさん
25/08/18 08:11:30.19 ilCqlqaZ.net
GCC Rustはだいぶ前にメインラインにマージされたみたいだけど
クロス対応ってどこまで進んでいるんだ？
LLVMバックエンドがないマイコン系ISAもRustで開発できる感じ？
24:デフォルトの名無しさん
25/08/18 21:19:44.54 xACiQreQ.net
Rustは衰退しました。
25:デフォルトの名無しさん
25/08/18 21:46:08.37 dnUOS2YV.net
その書き込みもRust製のPingoraを通って投稿されてRust製のPingoraを通って皆が読んでるよ
26:デフォルトの名無しさん
25/08/18 22:00:15.90 lyr3W+Wr.net
横長のGUIが衰退したら次は縦長のGUIが再発明されたりする
じゃあ再発明しても変化しない仕様はなんだ
0で割り算できない仕様とか
27:デフォルトの名無しさん
25/08/19 19:22:34.36 XX3oox1B.net
COBOLみたいに固定長レコードを基本として基本的に動的アロケーションをしない方向のモダンな言語もあっていいと思う
Rustを待たずとも、あれはあれでメモリ安全の究極の形の一つ
28:デフォルトの名無しさん
25/08/23 19:14:03.74 K0SmVlfv.net
>複数の値 (いわゆる多値) を関数が返せる言語はそれほど多くない。
>LISP 系は多値のサポートがあることが多いけどそれ以外だと Go くらいじゃないかな？
Rustの()は値0個で(a,b,c)は値3個の多値
という認識で合ってますか？
29:デフォルトの名無しさん
25/08/23 19:50:48.28 CHT0FIec.net
>>28
いいえ。
多値ではなくタプルです。
30:デフォルトの名無しさん
25/08/23 21:56:54.53 cDLDYI8A.net
夏のオージ演
31:デフォルトの名無しさん
25/08/23 22:15:56.19 vghJtGax.net
多値の取り扱いの仕方の一つがタプル
そしてRust公式にも Functions can use tuples to return multiple values. と明記されている
>>28の引用文についてRustは関数で多値を返すことができる言語の一つ
32:デフォルトの名無しさん
25/08/23 22:45:01.43 b43T5BM2.net
Rustのタプルは多値で合っているが、言語によってはタプルというオブジェクト[のポインタ]を1つ返す場合もある。
そのような言語ではタプル≠多値で、Rustではタプル=多値。
Rustで関数がタプルを返す時に、各環境で可能なら複数のレジスタを使って返し、レジスタ返しの数を超えていれば、例えば呼び出し元スタックフレームの指定領域に直接書き込んで返す。
したがってRustは多値返しをサポートする言語。
33:デフォルトの名無しさん
25/08/24 06:23:07.67 yIg8YRK3.net
分野によって用語の意味にブレがあるからそういうのを厳密に考えてもあんまり意味ない。
狭義の多値は継続 (continuation) に複数の値が渡ることをいうのでたぶん >>28 はその意味で言ってて、その意味ではタプルは多値ではない。
単なる言語ユーザの目線ではタプルにまとめて受け渡すことと複数の値を受け渡すことには何も違いはないから同一視しても何も困らないよ。
形式論理とかの世界の話。
34:デフォルトの名無しさん
25/08/24 06:51:31.37 Q1fxgDlW.net
重要なことはオーバーヘッドの有無
タプルをオブジェクトの一種として扱う言語はオブジェクトを用意してそのアドレス単値のみを渡すため間接アクセスのオーバーヘッドが生じる
タプルを多値として扱うRustは多値として渡せるためオーバーヘッドが生じない
もちろんRustではタプルをBoxに入れることでアドレス単値のみ返すことも可能でオブジェクト方式の言語は常にそれをしていることになる
35:デフォルトの名無しさん
25/08/24 07:38:29.67 yIg8YRK3.net
アーキテクチャによって ABI は違うかもしれないけど一般的な実装としては
関数の返却値が大きい時は呼出し側でメモリを確保してそれを隠れた引数として渡すようなメカニズムになってる。
返却値はスタックを介さない。
これは C++ でも同じ。
36:デフォルトの名無しさん
25/08/24 07:52:38.38 lHuVCVKu.net
>>35
ほぼ合っているが一部だけ違う
間違ってる部分は「スタックを介さない」
正解は「スタックを介す」ことで高速に引き渡す
サイズの大きな値を返す場合
具体的には呼び出し元でスタックポインタを増減することでスタックフレームを拡大してその確保領域のアドレスを隠れた引数としてレジスタ渡しする
呼び出された関数側ではその確保領域に直接書き込んで値を返す
ヒープ領域を確保して受け渡す方式と比べるとメモリ領域確保のコストがない点とスタック上でそのままメモリキャッシュに乗る点で有利
37:デフォルトの名無しさん
25/08/24 07:56:09.24 lHuVCVKu.net
ちなみにRustでx64アーキテクチャの時
16バイトまでならレジスタ渡しになり上記スタック領域は使われないため更に速い
38:デフォルトの名無しさん
25/08/24 08:16:24.05 lHuVCVKu.net
ごめん、肝心なところ書き間違えてる
✕ 16バイトまでならレジスタ渡し
○ 16バイトまでならレジスタ返し
39:デフォルトの名無しさん
25/08/24 10:58:20.04 lOj53x5G.net
言語が多値返却をサポートしてるかどうかというのは文法としてサポートしてるかどうかという意味
文法的にはサポートしてないけど「〇〇使えば多値返却できる」のは当たり前
一般的なプログラミング言語で「Functions can use 〇〇 to return multiple values」の〇〇に当てはまるものがない言語は無いので意味がない
文法的にサポートしているかどうかと内部実装がどの程度最適化されるのかはまた別の話
40:デフォルトの名無しさん
25/08/24 11:01:04.53 o5OQy7cK.net
多値が返せるか？の意味なんて、ユーザ的には戻り値の分割代入ができるか？ってだけだし
ダラダラ言わずに返せますで終わりでよくね
41:デフォルトの名無しさん
25/08/24 11:17:14.32 DLpoJrbF.net
Rustは多値を返す機能があるだけでなく
その実装も本当に多値を返すため効率よく実行も速いことが特徴
42:デフォルトの名無しさん
25/08/24 11:34:24.43 yIg8YRK3.net
>>40
仕様を読むときは言語の理屈や用語をわかってないとちゃんと読めない。
複数の要素をひとつにまとめたもの (タプルや構造体) をひとつ返すというのと複数の値を返せるというのは違うことなんだが、
Rust では同一視することにしたというならそれはそれで同一視しているという理屈をわかってないといけない。
43:デフォルトの名無しさん
25/08/24 11:46:57.61 s620v8qa.net
>>42
それは屁理屈
プログラマとしては多値を返せる機能があればよいわけで、
それがタプルという形で実現されていようが困ることは何一つない
逆に、タプルをサポートしていればそれだけで十分であり、
タプルでない多値をサポートするメリットが何もない
44:デフォルトの名無しさん
25/08/24 11:50:38.02 yIg8YRK3.net
>>43
実際に (複数の要素をタプルなどにまとめるのではなく) 多値をサポートしてる言語はあるわけだが、ディスってんの？
言語の理屈の構成の仕方の話であって言語としてのメリットの話なんかしてない。
45:デフォルトの名無しさん
25/08/24 11:58:39.52 sGVh/967.net
多値をサポートしてる言語の例としてGoが上で挙げられているけどさ
Goはタプルがなくてみんな困っている
タプルがある言語では多値がなくて困った話は聞かれない
機能として『タプル ⊃ 多値』 だからだよ
46:デフォルトの名無しさん
25/08/24 12:05:10.36 DXAve6fe.net
Goでタプルがなくて辛いという話は聞いたことがないな
最適化の観点抜きで機能的に他でカバーできるから不要と言ってしまうと、
例えばオブジェクトは全部ヒープに置いてスマポの所有権移動だけにしてしまえば複雑なムーブは不要となり遥かにシンプルになる
それはそれで一つの考え方だが、Rustはそういう言語ではないと思っているのだろう？
47:デフォルトの名無しさん
25/08/24 12:08:19.32 veJK4T2Q.net
返却された値がスタック上でどう扱われるかというのは言語仕様でなく最適化の問題だから、そこはRustではなくLLVMの話
言語仕様としては「Rustではタプルを簡単に作れる」「タプルの中身を別々の変数に束縛できる」というだけ
多値返却の目的からすればこれで十分だし、多くの言語はこれに相当する
Goは本当に多値返却という仕様で、これはタプルを返すのとは違う
そもそもタプルが言語仕様になくて、関数の返り値でだけ多値を返せるという変わった仕様
だから、2つの戻り値を返す関数を1変数で受け取ることができなかったりする
(Rustでいえば「戻り値を分解せず1つのタプル変数 t で受け取る -> t.0, t.1 のようにアクセスする」という書き方がGoではできない)
だから言語仕様としての話をしたいのか、「関数から複数の戻り値を返す」という目的の話をしたいのかで話は変わる
後者については、最近の多くの言語ではサポートしてるし、そんなに話がズレることもない
前者の意味でなら、Rustは多値返却の構文を持つ言語とは違う
48:デフォルトの名無しさん
25/08/24 12:16:23.06 aQdKZ7zp.net
Goの多値とRustのタプルは同じ
どちらも実装は多値として返すため多値レジスタ返しが可能ならばそうするため効率が最も優れている
関数定義もほぼ同じ
func foo() (type1, type2) {…
fn foo() -> (type1, type2) {…
49:デフォルトの名無しさん
25/08/24 12:16:31.50 tCu5AZNy.net
バカなやつほど抽象度の区別ができない
バカなやつほどオレオレ定義で用語を使う
バカなやつほど主語を書かない
本当に相手にする価値があるか考えよう
改善の見込みがないバカなら何を書いても時間の無駄でしかない
50:デフォルトの名無しさん
25/08/24 12:26:32.12 95hjiUrq.net
多値を抽象化して機能を強化したものがタプルだもんね
だから多値でできることは全てタプルでもできるんだよ
タプルを持つ言語は機能の低い多値を別途持つ必要がない
51:デフォルトの名無しさん
25/08/24 12:50:55.19 veJK4T2Q.net
「タプルがあれば十分」は殆どのケースでは同意するけど、Goに限ってはそうする理由があるんだよ
エラーを多値で返す仕様かつ、エラー処理を明示的に書かせる思想の言語だから
value, err := foo()
のように err がコード上に表れるようにする必要があって、これはタプルだとまずい
t := foo() と書けてしまうと「タプルの2要素目がエラー」というのが見えなくなる
これは割とGo特有の事情で、Result型や例外を使う言語だとタプルでも困らない
言語仕様というのは他の部分も含めた全体的なデザインとして考えるものだから、「Rustではタプルで困らない」が正しくても、他の言語含めて全てそうだとは言えない
52:デフォルトの名無しさん
25/08/24 12:56:30.01 9a3ehhoR.net
>>49
>バカなやつほど抽象度の区別ができない
>バカなやつほどオレオレ定義で用語を使う
>バカなやつほど主語を書かない
汚コーダーの特徴が濃縮されてるね
3番目は「書かない」というより「書けない」だと思う
53:デフォルトの名無しさん
25/08/24 13:02:12.19 LAWD3p/v.net
原始的な剥き出しの多値を扱う必要のない言語においては、タプル多値があれば多値をサポートしているという結論でいいんじゃないかな
54:デフォルトの名無しさん
25/08/24 13:07:02.23 vekMbO+E.net
Rustはnamed tupleもanonymous structもなくunnamed tupleで位置でアクセスするか事前に定義した型で名前でアクセスするかしかないから利便性ではモダンな他言語に一段劣る
55:デフォルトの名無しさん
25/08/24 13:18:17.18 kBf9AmUd.net
>>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
56:デフォルトの名無しさん
25/08/24 13:28:22.18 fUN48E4b.net
>>51
いや、エラーに限らずt.0とか普通に可読性最悪だからね
多値をタプルとして実装するなら、即時の分割代入を必須とするか、もしくはC#のようにpositionalなタプルと互換性のあるnamed tupleとするか、どちらかは必須
57:デフォルトの名無しさん
25/08/24 13:41:09.97 uDNIRrgr.net
必要となるまでは1つのまとまりとして一括して扱えたほうが有利
必要になったところでパターンマッチングさせて個別に用いる
58:デフォルトの名無しさん
25/08/24 13:49:22.14 +tDfyqBW.net
Rustは必要なところではパターンマッチングできるから不便なことはないよな
59:デフォルトの名無しさん
25/08/24 13:56:11.80 fUN48E4b.net
取得から消費までのコード上の距離が離れるほど人間の短期記憶の負担になり可読性が低下する
複おじは特に頭悪いから実感してるんじゃない？
60:デフォルトの名無しさん
25/08/24 14:11:41.28 0UxuBUhy.net
let (unko, chinko) = unkochinko
とか突然出てきてunkochinkoの宣言が離れてたら、合ってるのか不安を感じてつい宣言までスクロールしちゃうわ
離れた場所での位置依存は普通に可読性最悪
61:デフォルトの名無しさん
25/08/24 14:14:05.68 ieA/MpG4.net
>>56
ジェネリックに意味を持たない局面もあるからそこでt.0を使うのは適してる
意味がある局面なら例えばfor (index, name) in ...や|(index, name)| ...のように使われるから名前でアクセスできる
62:デフォルトの名無しさん
25/08/24 14:15:37.70 veJK4T2Q.net
>>56
C#も分割代入しない書き方はできるじゃん
その場合の可読性はPythonもC++もC#もそう変わらないかと (t[0], get<0>(t), t.Item1)
意味のある名前を付けたいなら、それはRustでもstructを定義すれば済む話だし
C#の匿名クラスの便利さもまあ分かるけど、あれば嬉しいくらいで、個人的には必須とまでは思わない
63:デフォルトの名無しさん
25/08/24 14:18:45.06 m/1beq6h.net
>>62
C#には匿名型とは別にnamed tupleがあって、positional tupleと互換性を持ったままフィールドに名前を付けられる
64:デフォルトの名無しさん
25/08/24 14:23:02.15 VS0PssfI.net
>>55
named tupleの定義が面倒＆カッコ悪いな
65:デフォルトの名無しさん
25/08/24 14:40:44.45 f2gy7gmS.net
Pythonの名前付きタプルは普通に使いにくいからな…
その用途なら dataclass にしとけ、というのが共通認識だと思う
66:デフォルトの名無しさん
25/08/24 17:03:59.99 apxru5vn.net
>>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)
67:デフォルトの名無しさん
25/08/24 17:15:02.39 7zDT8kXu.net
事実と意見を区別しろ
前提を明確に示せ
異なる前提に依存する結論を無理に適用するな
68:デフォルトの名無しさん
25/08/24 17:48:30.01 +zGYyK0c.net
>>66
これで済む話
let (x, y) = foo();
69:デフォルトの名無しさん
25/08/24 18:53:52.96 xPc+Pkry.net
>>66
筋がよくなく中途半端に感じる
その型を他でも用いるならば型に名前を付けて宣言したほうがよく
その場限りならば>>68
70:デフォルトの名無しさん
25/08/24 19:23:45.82 o5OQy7cK.net
let (manko, chinko) = foo(); // 本当のfoo()の返す中身は(chinko, manko)
が許されるから、それって嫌だよねって話じゃないの？
71:デフォルトの名無しさん
25/08/24 19:32:58.00 lcXQ4DrV.net
>>70
そうそう
AIに生成させるにしても、fooが別のパッケージだったりするとシグネチャだけで要素の意味を推測できないのは辛いわな
72:デフォルトの名無しさん
25/08/24 19:44:34.69 PRkNyipX.net
別なら構造体を定義しろ
73:デフォルトの名無しさん
25/08/24 22:32:48.16 O8wAGFa3.net
>>68
どっちかというと真逆でRustの場合は1mmでも名前でアクセスしたいと感じるものは構造体を定義しないといけない
>>69
中途半端に感じるのは当然
事前に構造体を定義しておくほどではないが要素には名前でアクセスしたいというものすごく中途半端な状況にこそ求められる機能だから
74:デフォルトの名無しさん
25/08/25 06:47:36.11 E2rxLwdP.net
>>59
>>60
それらは古典的プログラミングだから無関係な処理が間に挟まったり流れが乱されるため可読性が落ちる
Rustでは抽象化したプログラミングによりメソッドチェーンで繋ぐことが多い
チェーンの間はタプルのまま旅を続けたとしても一つの流れなので可読性は落ちない
チェーンの途中もしくは最後のforやfold系でパターンマッチングされてタプルが解消されればよい
75:デフォルトの名無しさん
25/08/25 08:15:32.90 foAG4KWU.net
多値戻しは_をサポートしてなければコーダーにとってはどうでもいい話じゃないんかね。
最適化機会を明示できるかどうかくらいじゃね？
76:デフォルトの名無しさん
25/08/25 10:18:01.04 hSk6qQ9G.net
ながめてるとたしかに_多いな
＞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()
＞}
77:デフォルトの名無しさん
25/08/25 12:25:47.76 lo8Kz+ZF.net
タプルの片方は途中不要で最後に必要だが、もう片方はその逆とかよくあるある。
後者のfind()はposition()に置き換えられるが、二つのfindが対称形の処理ぽいのでそのままでもいいか。
78:デフォルトの名無しさん
25/08/25 15:50:58.87 4Ejmg1ls.net
まだ多値の話してる・・・
79:デフォルトの名無しさん
25/08/25 16:13:59.05 M76UE5qm.net
このスレはあくまで複おじのファンスレッドだから
複おじの興味が続けばその話題が続くんだよ
80:デフォルトの名無しさん
25/08/25 21:09:46.97 KzDmCwhz.net
ファンじゃなくて自演スレだから
81:デフォルトの名無しさん
25/08/27 18:45:58.51 s/5KNF71.net
タプルといえば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<_>)>();
82:デフォルトの名無しさん
25/08/28 10:55:22.21 OS0cfYx9.net
抽象なんて「見たいものだけを見る」という程度の意味だからね
もしメモリ管理が最大の関心事なら
抽象度が最も高いIUnknownにリファレンスカウント機能をつけていい
83:デフォルトの名無しさん
25/08/28 11:58:26.45 1IatnfJ+.net
>>81
左辺に型を書けばいいんだよ
そのほうが読みやすいしタイプ数も少ない
あとunzip/multiunzipはcollectでも代用可
84:デフォルトの名無しさん
25/08/28 15:40:44.35 OS0cfYx9.net
なんで掛け算の引数には名前がないんだろう
順序を逆にできない理由が一目でわかるような名前があるなら名前をつけるべき
85:デフォルトの名無しさん
25/08/28 20:43:02.31 fdP0HyCm.net
>>81
unzipはトレイトを使っていないため余分なパラメタが露出してしまってる
multiunzipはトレイトMultiUnzipを
collectはトレイトFromIteratorを使っている
>>83
今年のRust 1.85からタプルもcollectできるようになったね
86:デフォルトの名無しさん
25/08/30 05:57:20.14 JBC8dN2M.net
a * b * c
は b や c のすぐ隣に目印があるからキーワード引数は不要だ
mul(a, b, c)
(* a b c)
このような記法だけが、b c 付近で文法的サポートが不足している問題を抱えている
87:デフォルトの名無しさん
25/08/30 23:22:46.71 6bFj+97W.net
>>55
namedtupleは廃れて今はdataclassを使う
Rustでの#[derive(Debug, Hash, Ord)]付き構造体相当
結局Pythonでもそのへんはちゃんとしてほしいことになった
88:デフォルトの名無しさん
25/08/31 09:51:10.58 cF2U6lLu.net
ハッシュ関数を使えば保守的GCが廃れる
確率を見たらカオスと思え
89:デフォルトの名無しさん
25/08/31 10:00:25.50 mJd+1ya1.net
>結局Pythonでもそのへんはちゃんとしてほしいことになった
誰か日本語に翻訳して
90:デフォルトの名無しさん
25/08/31 10:52:20.39 QUPYnWaR.net
足りない頭で必死に調べた複おじの努力を認めて差し上げろ
それはともかく、一般にスクリプト言語ではタプルはあまり好まれず、辞書が好まれる傾向がある
- ユーザーが辞書データ構造を使ってレコードを扱うことに慣れている
- 辞書を扱うための簡便な構文が存在する場合が多い
- 辞書と配列の速度やメモリ使用量の差が問題にならない
- 値が増えた場合にランタイムエラーを引き起こす
なお、dataclassは辞書に対する型付きのラッパーに過ぎない
あくまでこれはスクリプト言語の事情であり、Rustのような静的言語においてはレコードはタプル(構造体は名前付きのタプルの一種)として実装することが基本であることに注意しなければならない
91:デフォルトの名無しさん
25/08/31 17:32:35.66 qrCON/OK.net
辞書かどうかは本質ではない
辞書として用いないことが圧倒的に多いため例えばV8では静的解析で判明するプロパティを構造体フィールドのように扱い実行するため辞書実装とは異なり速い
92:デフォルトの名無しさん
25/08/31 18:15:49.65 IkR/a1qs.net
また的外れなレスだなぁ
結局複おじにもそのへんはちゃんとしてほしいことになった
93:デフォルトの名無しさん
25/08/31 18:20:32.10 yY4/9rZW.net
>>91
V8のプロパティアクセスの最適化は基本的には静的解析に依存しないよ
同じプロパティが同じ順序で追加されたオブジェクトは同じ型と見做してキャッシュされたプロパティの位置を利用する
あくまで辞書データ構造を前提としたままでキャッシュ戦略を工夫しているに過ぎない
94:デフォルトの名無しさん
25/08/31 23:19:02.35 cF2U6lLu.net
魔法の数字ではなく
ちゃんとenumを使うことになった
95:デフォルトの名無しさん
25/08/31 23:24:15.68 Dds/cnqW.net
Minimal Embedded FAT32 Driver - in Rust!
URLﾘﾝｸ(www.youtube.com)
96:デフォルトの名無しさん
25/09/02 22:34:52.76 sEJ6dDWm.net
「Rust」の平均単価が3カ月連続上昇 エン・ジャパンがフリーランス案件の分析レポートを発表
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
開発言語別では、比較的新しい言語「Rust」が3カ月連続で平均単価を伸ばし、87万4000円（2025年6月比で4.4％増）で1位となった。
97:デフォルトの名無しさん
25/09/03 01:10:14.83 rmZ6WmxL.net
もういいよ
98:デフォルトの名無しさん
25/09/03 06:18:41.58 Myuv+TwW.net
Rustがトップになる予想が当たったね
99:デフォルトの名無しさん
25/09/03 08:43:05.32 Ypa4ifGO.net
これからどんどん増えるで
100:デフォルトの名無しさん
25/09/03 10:27:14.93 pUgFa8ls.net
URLﾘﾝｸ(corp.en-japan.com)
Goもそうだけどレベル低い人(特定言語の習熟度ではなく基礎的な技術力の観点で)お断り案件がほとんどだから単価が高く出る
つまり裾野が狭いことを意味するわけで、決して手放しに歓迎すべきことではない
特にRustがこれから食っていかなければならないのは最下位付近にいるC++とCの領域だから、普及していけば単価は大幅に低下する
101:デフォルトの名無しさん
25/09/03 10:39:55.94 slTkF8Pj.net
> 全体として、比較的新しい言語である「Rust」や「Go言語」、「Kotlin」などが高い単価を維持しており、市場での需要の高さがうかがえます。
これかなり違和感あるなあ
このへんのメンツの単価が高いのはつまるところ案件の難易度が高いからで、
下の方のコモディティ言語と同じように需給バランスで単価が決まると考えてるのは実態を知らないんだろうなと思う
102:デフォルトの名無しさん
25/09/03 11:43:31.30 FcGJkFCi.net
>>100
C系はバカでも書けるから安いんだよ
レベルが低い人はRustが難しいと感じて挫折や一部アンチ化
一方で今後求められつつあるのが安全で速いRust
103:デフォルトの名無しさん
25/09/03 12:11:36.01 UDH6IOq3.net
もしかしてRustを誰も使ってないのはレベル低い人だらけだから？
104:デフォルトの名無しさん
25/09/03 12:41:52.63 JLXMHQtL.net
>>101
案件の難易度というよりも
開発者個人に期待されてる技術水準だったり
言語に付随して求められる知識やスキルの水準と希少性による
それらが低い水準の技術者でも構わないという求人の多寡が
言語別平均単価を最も大きく左右する要因
105:デフォルトの名無しさん
25/09/03 14:32:47.56 mk24rcqJ.net
低い水準の技術者ほど言語別の単価を気にするのは他に差別化できるものがないからなんだよな
転職エージェントについても同じ事が言える
106:デフォルトの名無しさん
25/09/03 14:55:10.39 wGzU1Ifu.net
納期を守るのと守らないのはどっちが供給不足か
デフレ脱却したいとして、供給を減らすのと増やすのはどっちが合理的か
ぜんぜんわからない
雰囲気
107:デフォルトの名無しさん
25/09/03 20:52:42.81 16NS2IAc.net
関係ないよ
Pythonの単価が一番高かったころもあった
その時はみな稼いでいたんだろな
需要と供給のバランスが崩れてるところと言う視点だけだと思うけど
108:デフォルトの名無しさん
25/09/03 23:36:04.43 0gdcYoMa.net
何が関係ないのか全然わからん
109:デフォルトの名無しさん
25/09/04 00:25:45.89 6pIdFnm5.net
プログラミングは一種のパズルのようなもの
各言語の機能制約＋バグなく目的の実現という全体のパズルを解いていく
Rustの場合はメモリ関係や諸々の安全性などのための制約で他より難しいパズルになるため誰でも参入できるわけではない
代わりに速さ省メモリ安全性の両立という唯一の果実を得ることができる
構造的に単価の崩壊は起きそうにない
110:デフォルトの名無しさん
25/09/04 00:35:53.93 LhBS9NeG.net
プログラミングをパズルだと思ってるやつw説得力が違うww
111:デフォルトの名無しさん
25/09/04 00:41:20.03 UUTUiuRY.net
データや手続きの構造化はパズルそのもの
112:デフォルトの名無しさん
25/09/04 02:30:07.00 LqWnaoik.net
それわかるわ
パズルを解く意識なく漫然と進めるとスパゲッティになりやすい
そうなるとバグや機能追加で辻褄合わせを重ねるダメなプログラミングになってしまう
113:デフォルトの名無しさん
25/09/04 08:52:39.19 ZfQJo1Tt.net
ルールが不安定なパズル
ストライクを三回見逃したらアウトか？
それは実際に起きてから検討する
114:デフォルトの名無しさん
25/09/04 08:58:39.79 1soimmg4.net
プログラミングの基本は段階的詳細化
設計のセンスない奴は逆にボトムアップで後から辻褄を合わせていくようなパズルになりがち
特にRustは細部に気を取られやすいから注意
115:デフォルトの名無しさん
25/09/04 09:22:33.64 vfX9hKSX.net
実現したい機能に対してトップダウン的に絵を描いていく過程も含めてパズルと言っているならいいが、
おそらく複おじが言っているのはそういうものではなくコードレベルの辻褄合わせのパズルだろう
いわば、自ら解く必要のないパズルをわざわざ作り出して必死にそれを解いている状況だ
116:デフォルトの名無しさん
25/09/04 10:16:31.84 eoDLYfq3.net
パズルではないわな
答えなんてないし
それぞれの事象に対してどう見るか 構造の把握
スケール感の問題
117:デフォルトの名無しさん
25/09/04 10:23:41.49 eoDLYfq3.net
ABCの処理があって普通に考えるとA、B、Cの順で処理するんだけど
よく考えるとC,A..BにしてCの段階で条件分岐や枝狩りしたほうがロジカルに効率が良いと気が付いて実装するけど
実務で使い始めて統計取ると特定のパターンばかり利用されててキャシュ効率上でBCAでやったほうが効率が良かったとか
パズルとは程遠い泥臭い世界
118:デフォルトの名無しさん
25/09/04 10:44:44.47 m/0dQr70.net
Rustは他の言語よりパズル要素強めじゃね？
119:デフォルトの名無しさん
25/09/04 10:56:34.58 3uttxPMH.net
明瞭な線があるわけではないグラデーションの中であえて「どちら寄り」かを言うならそうとも言えるかもしれない。
120:デフォルトの名無しさん
25/09/04 11:02:42.07 eoDLYfq3.net
外部の条件によって最適化のために条件分岐などが追加され複雑度が上昇する
そんなパズルなんてない
121:デフォルトの名無しさん
25/09/04 11:26:54.96 JGI2PCUV.net
プログラミングはぐちゃぐちゃの辻褄合わせになったら敗北
辻褄合わせにならないようにするという明確なゴールのパズルを解かなければならない
強引に辻褄合わせできてしまう言語ではその問題が潜在化して表面上はごまかす形になる
Rustでは辻褄合わせはコンパイルを通せないという形で顕在化してくれることが多くて好ましい
無理矢理にコンパイルを通すために無駄なコピーや不必要な内部可変性を用いるとコードレビューですぐに低質なプログラマであるとあぶり出せる
122:デフォルトの名無しさん
25/09/04 11:29:28.26 vfX9hKSX.net
そりゃ辻褄合わせと呼ぶラインをどこに引くかによって何とでも言える
優秀なエンジニアならコードレベルの試行錯誤は全て辻褄合わせだろう
123:デフォルトの名無しさん
25/09/04 11:40:43.96 IELJ+5qz.net
またそうやって擬似問題になりそうな話を
（wikipedia）パズルは、あらかじめ出された問題を、論理的な考察と試行錯誤によって解くことを目的とした、ゲームやクイズに似た娯楽の一種。
が世間一般の認識だから、解を用意していない問題はあんまりパズルとは言わん。
124:デフォルトの名無しさん
25/09/04 11:56:06.31 ZcFrEykS.net
プログラミングは制約条件を理解してないと解けないパズルかというとそうでも無い
テストさえ書けりゃ、どう解いてもいいパズルだから自由度は無限大
どこを妥協するか、どこを作り込むかだけの問題
もちろん、組み込みみたいに制約が厳しすぎて設計自由度のない世界もあるけれどそういう世界ではRustは使わない
125:デフォルトの名無しさん
25/09/04 11:57:48.23 ZcFrEykS.net
前スレから「辻褄合わせ」というプログラマーが大勢いるが、それは外部インターフェースとの整合とかの話だけでしょ
そんなの辻褄合わせして当たり前、仕様なんだから合格させようよ
126:デフォルトの名無しさん
25/09/04 12:02:06.25 cGup1Tfc.net
パズル的要素が皆無というわけではないんだが仕事としてのプログラミングの場合その割合はせいぜい全体の5％以下
プログラミングをパズルだと捉えている人は残りの95％が見えてないだけ
127:デフォルトの名無しさん
25/09/04 12:27:45.62 9OFIpubQ.net
競プロ上がりだと100%パズルぐらいの感覚で業務システム開発もやるのかな
128:デフォルトの名無しさん
25/09/04 12:43:52.93 sEvyWhfg.net
全員の意見が多かれ少なかれパズル的な部分が存在することを認めているな
さらにRustはそのパズル的な部分の難易度が上がるという見方が複数あってそれらに反論がない
元の話の結論が出たな
129:デフォルトの名無しさん
25/09/04 12:45:05.01 sEvyWhfg.net
元の話の結論が出たな
Rustに低質なプログラマは参入できない
よって>>96の単価表ボトム3『C/C++/C#』のように単価が下がることはない
130:デフォルトの名無しさん
25/09/04 12:50:01.72 sEvyWhfg.net
その記事の元の発表の単価表は>>100
131:デフォルトの名無しさん
25/09/04 13:08:42.88 7fb6B/JG.net
いやーC#はともかくC/C++はエッセンシャルワークとしての側面があるからねえ
C#みたいな業務システムの領域ならそんなものはSaaSに喰われて消えるみたいな強弁も一理あるけど、組み込みが消えたら社会回んなくなるよ
その領域がいつまでもC/C++のままで変わらないとしたら、複おじの願うRust理想郷は永遠に実現しないことになる
132:デフォルトの名無しさん
25/09/04 13:15:29.52 2hNgjipt.net
言語別単価で優劣を語りたがる層
≒ 言語以外に差別化要素を持ち合わせてない層
≒ プログラミングをパズルと捉えている層
≒ 生成AIで置き換えられる層
133:デフォルトの名無しさん
25/09/04 14:20:06.37 BCXVeHms.net
パズルの言語差が単価の言語差だと思ってる層 == 複おじ層
134:デフォルトの名無しさん
25/09/04 19:30:28.50 vcXGHXe6.net
脳内の「心の声」を読み取る新たな技術、最大74％の精度でリアルタイム解読に成功
公開： 2025-08-23 08:00
URLﾘﾝｸ(karapaia.com)
>> 彼らの脳の運動皮質（大脳皮質の一部で随意運動の指令を出す領域）にマイクロ電極を埋め込み、神経活動を記録した。
>> 実験では、参加者に以下の2通りの指示が与えられた。
>>1. 指定された単語を声に出そうと努力する（実際には発声しない）
>>2. 同じ単語を、声にも出さず、心の中だけで思う（内言）
>> 結果として、どちらの行動でも脳の同じ領域が活動し、似たパターンの神経信号が観測された。
>> ただし、内言の方が全体的に信号の強度は弱く、詳細な分析によって両者の違いも見分けられることが分かった。
>> さらに驚くべきことに、研究チームは、参加者が指示されていない言葉までもBCIが読み取っていたことを報告している。
>> たとえば、画面上に表示されたピンク色の円を数える課題では、参加者が心の中で数を数えていたことが検出されたという。
★直接接続しても読み取り精度１００％で無い！
★★★★★★★★★
思考盗聴不可能
★★★★★★★★★
135:デフォルトの名無しさん
25/09/04 20:49:36.52 3uhYTePD.net
Rustって思考盗聴の技術と何か関係あるんか
そもそもサブリミナルで他人の意思決定に干渉してるだけなのに「思考盗聴」とか言う意味が分からん
カードマジックで意図的に特定のカード選ばせた後に「透視」して言い当てるみたいなネタなら分かるけど
136:デフォルトの名無しさん
25/09/05 11:45:03.86 qGwJ0G0s.net
このスレ見てると統失多そう
137:デフォルトの名無しさん
25/09/05 21:32:26.30 y82F5TBG.net
プログラマーなんて、SEと違ってその気になればいつでも手帳もらえるようなのばっかりだろ
138:デフォルトの名無しさん
25/09/05 21:42:30.51 PE0qALNl.net
よくC/C++からの書き換えは話題になるけどJavaとかはどうなんだろ
139:デフォルトの名無しさん
25/09/05 22:16:43.53 SAtiqpOd.net
>>138
Meta社主導のオープンシステムBuckがJavaからRustに書き換えられ速くなった
140:デフォルトの名無しさん
25/09/05 23:14:16.74 PE0qALNl.net
やっぱそっちの方が効くよな…
C/C++は安全性は向上するかもだけど効率面はそれほど変わらないし
141:デフォルトの名無しさん
25/09/05 23:41:19.77 EdDK7HX5.net
C製のNginxにCloudflareが機能拡張の限界を感じてRust製のPingoraを作ってしまい速くなった話もある
142:デフォルトの名無しさん
25/09/06 00:25:08.85 PVmm5ZSZ.net
速くなるものが作れるともう戻れなくなるのよね
143:デフォルトの名無しさん
25/09/06 01:20:05.03 BBkKVX9d.net
JavaはなんとなくわかるけどCより速くなれたのは
どういう理由なんだろうな？
メモリ管理に厳しくなった分コードが整理されたとか
高速なライブラリが利用しやすかったりとか？
144:デフォルトの名無しさん
25/09/06 04:08:45.69 UZSX8lly.net
そういうのはたいてい並列化で読み込み時間短縮って例
145:デフォルトの名無しさん
25/09/06 08:16:45.68 RDwHnPgj.net
Nginxの件に関しては、マルチプロセスをマルチスレッドに変更してコネクションプールの効率を改善したのと、
LuaモジュールをRustに書き換えたことが速くなった理由
つまりCより速いかどうかは全く関係ない
146:デフォルトの名無しさん
25/09/06 10:23:19.24 gk21ZPjY.net
「xxx言語で書き直したらこんなに速くなりました」はだいたい言語とは関係無いよ
リライトに伴う構造やロジックの見直しがメイン
147:デフォルトの名無しさん
25/09/06 10:35:43.95 Eruvpq+4.net
頭がおかしい人にはそれが通じない↓
148:デフォルトの名無しさん
25/09/06 11:56:47.46 Ag/cJ4H+.net
JavaやC#やGoのような「決して遅くないけど最速でもない(最悪でもCより数倍遅い程度)」グループからのRust移行はあまり流行ってないよね
元々わざわざコアだけCで書いたりしてないし、Rustへの漸進的な書き換えもやりにくい
セキュリティ面でも得るものはほとんどなく、むしろ標準ライブラリが貧弱でコミュニティの馬の骨に頼る部分が増える点はリスク要因
あと、そういう言語の著名な成果物って現実の複雑性に真面目に向き合ってやるべきことを地道にやってきた結果として重厚になったのが多くて、
Rust信者が好みがちなサクッと書き換えて爆速最強！みたいな話にはなりにくい
Elasticsearchに対抗したMeilisearchみたいな例はあるけど、機能がしょぼすぎて性能以前の問題として全く戦いになってないのが現状
149:デフォルトの名無しさん
25/09/06 11:59:42.86 AI5/M/rL.net
>>143
まず前提として「事情は変わる」ってことだ。
ある時点の事情に合わせて最高にチューニングされたプログラムだとしても
変わっていく事情に合わせて変化できなければ相対的に遅くなる。
そして世の中のプログラムというのは世間で思われているほどには保守されていないし、ドキュメントもない。
根本から全てをやり直す機会というのはまず無いんだ。
しかしそれがあるのが「新しい言語の登場」という場面なだけ。
言語 (処理系) が充分以上の性能を持っていることは当然の前提としても
劇的な性能向上は書き直すという行為そのものにある。
Rust とは関係ないが、書き直して性能向上した顕著な例としてはリンカの mold なんかが有名だ。
GNU LD に比べたら百倍以上とかの速度差があるけど
飛びぬけた工夫があるわけではなく今風の設計でやり直したに過ぎない。
互換性を維持したままやりなおすってのがひたすらしんどいから誰もやりたがらないだけで
やれば効果があるってことはたぶんそこらへんにたくさんある。
150:デフォルトの名無しさん
25/09/06 13:01:26.27 6FQoWLuD.net
個人がバグったところで何の問題もないような自作のソフトを
AIでぱーっとRustに書き直して爆速！みたいなのなら、GC言語からの移行もあるかもしれないけど
金と人使ってビジネスでやるには、メリット説明できないわな
151:デフォルトの名無しさん
25/09/06 14:43:23.64 fE0qD0IQ.net
おまえら勘違いが激しいな
そのままで異なる言語に書き換えが割に合うのはスクリプト言語などクソ遅い言語から変更のとき
そのままではなく機能追加などで構成から見直して変更して書き直す時にRust一択
完全な新規開発でもRust一択
それだけのことだ
152:デフォルトの名無しさん
25/09/06 14:56:28.32 4LFoTDpR.net
ｗ
153:デフォルトの名無しさん
25/09/06 17:30:43.78 ljkmdzrF.net
デスクトップアプリをpythonからtauriに移植してる
やぱーHTML,CSSが最高だからね
154:デフォルトの名無しさん
25/09/06 18:05:28.67 nV8Wb4jy.net
クラウドもCDNもWebベースでWeb関係の知識は必須な時代
アプリAPIからGUIまで全てWebベースにするのが主流になりつつ
155:デフォルトの名無しさん
25/09/06 18:17:03.85 VNM5tarI.net
tauriってマルチプラットフォームのせいでWindows固有の設定が不足してるね
具体的には、新しいウィンドウを開くときに指定できるオプションが enum FormStartPosition より少ない
156:デフォルトの名無しさん
25/09/06 18:28:13.15 PRze6Nk7.net
Tauriって出てからもう5年経つのか
他の技術に比べればまだ未成熟だけど、それなりの時間は経っているような気もする
実際のTauri製のソフトって、世の中には増えてるの？
157:デフォルトの名無しさん
25/09/06 18:30:10.85 7D0PK96y.net
>>155
他の環境に存在しないなら必要のない機能なのかも
158:デフォルトの名無しさん
25/09/06 18:47:09.06 6FQoWLuD.net
そもそも、デスクトップクライアントアプリというものの新規需要が全然ないからな
PCに入れるのは、Tauriが出る前からあるような定番みたいなのと製品だけで
フリーソフトをいろいろ探して入れるような文化ももう死んだようなもんだし
159:デフォルトの名無しさん
25/09/06 19:02:18.72 aQ2hhWq1.net
今は環境依存せずにリモート表示をしたいことも多い
機能部分はローカルで動かしてGUI部分はローカルまたはリモートのWebブラウザに任せる
160:デフォルトの名無しさん
25/09/07 02:29:10.24 OLjKudo7.net
AIでいうと驚き屋はタダ働きじゃないだろう
お金もらってるのを公表したくないだけじゃないか？
161:デフォルトの名無しさん
25/09/07 07:09:53.38 zlUCw5iB.net
ここで自作自演してるのはRsut驚き屋？
162:デフォルトの名無しさん
25/09/07 07:12:25.76 tyTc6SH2.net
労働市場でもRustが1位になった
ソース>>96
163:デフォルトの名無しさん
25/09/07 09:53:55.20 OLjKudo7.net
驚き屋は統計学の大先生であってパソコンの大先生ではない
164:デフォルトの名無しさん
25/09/07 16:41:31.97 nTdhEyd9.net
tauriはjsも必要なのがめんどう
165:デフォルトの名無しさん
25/09/07 17:09:46.35 aS8wLvBq.net
webasmでそこもrustでやってしまう
166:デフォルトの名無しさん
25/09/07 18:00:55.17 OLjKudo7.net
誰が？
多数派がみんなでやってしまうのか
謎のヒーローが一人でやってしまうのか
167:デフォルトの名無しさん
25/09/07 22:39:15.60 B7DDbLUj.net
全部Rustで作ろうってことだよ
168:デフォルトの名無しさん
25/09/07 22:47:53.78 vrzW9IuU.net
だいたいWASMでGUIってIMEで詰むし、そこが気楽になんとかなればいいんだけどな
169:デフォルトの名無しさん
25/09/07 23:37:18.74 OLjKudo7.net
たかがIMEなら逃げていいんじゃね？
逃げていいという考え方のほうが要領よさそう
170:デフォルトの名無しさん
25/09/08 00:33:07.89 qpwOyyTY.net
妥協するんなら大概のものはTUIで十分
まさか仕事じゃないだろうし、今時わざわざGUIを選ぶ時点でオナニーなんだから要領とかナンセンス
171:デフォルトの名無しさん
25/09/08 01:35:14.64 XsspSmYE.net
そう
じゃあ詰みなさい
172:デフォルトの名無しさん
25/09/08 08:15:57.34 t7zevFyQ.net
何をやっているんだ！
お前らよくマジモノに手を出せるね
幻覚ではなく自分が考えた妄想で話していると思っているのでしょう
精神病院の薬を飲む猛者ですよ！
薬を投与しても収まらない！
家族薬飲んでいる姿見ているのですよね？
永遠に自分が考えた自作自演の妄想は終わらない！
★★★★
★有鬚★
★★★★
173:デフォルトの名無しさん
25/09/08 20:45:41.50 t7zevFyQ.net
教官はどのランク
◇審判のランクについての役割
A級審判はB級審判以下を教えれる立場
※指導する立場なのでパワハラや強制をするような指導をしないようにする品位も問われるのでテスト問題にないと駄目
B級審判はＡ級審判と同等の判定ができるがＢ級審判やＣ級審判に判定の仕方を教えることは駄目
※周囲から見てもわかりやすいようにジャッジの仕方の動作は綺麗な動作でないと駄目
Ｃ級審判はＡ級審判の判定の仕方を聞きながら判定を行う審判で他の人に判定の方法を教えては駄目
※駆け出しなのでジャッジの判定に対しての大幅な誤差がある
※上記でないと判定に誤差が出てくる
※判定に問題があるようならA級審判同士で話し合ってルールの変更をする必要がある
★A級審判のみがオリンピックやパラリンピックでの審判が可能な立場
174:デフォルトの名無しさん
25/09/10 14:42:07.11 ClB+7tQv.net
型はダックタイピングでもいい
それでも人間の頭の中でRustと同じことをやる
というのが基本的な戦略で
人間と機械を対立させるのは瑣末な戦術にすぎない
175:デフォルトの名無しさん
25/09/10 22:38:13.39 ClB+7tQv.net
OOPも関数型もAIも
古い知識とは全く互換性がない新技術、という前提が反知性的な噂話を助長したので
その前提を否定すればいい
176:デフォルトの名無しさん
25/09/18 13:51:11.68 1Ek4hiHD.net
WASM3きてた
URLﾘﾝｸ(webassembly.org)
177:デフォルトの名無しさん
25/09/18 17:00:45.40 9LufLH6a.net
OpenAIとGoogleのAIがプログラミング大会「ICPC 2025」に参加し金メダル相当の記録を達成、OpenAIは全問正解でGoogleは2問ミス
2025年09月18日 11時22分
URLﾘﾝｸ(gigazine.net)
☆遅くとも１年後には人間はAIには勝てなくなる！
宇宙太陽光発電に応用可能–NTTと三菱重工が最高効率を達成した「レーザー光無線給電」って何だ？
9/18(木) 16:30
URLﾘﾝｸ(news.yahoo.co.jp)
無機酸化物の結晶骨格を再構成、量子素子などへの応用に期待 京大など
9/18(木) 16:29
URLﾘﾝｸ(news.yahoo.co.jp)
端から端まで8光年 ウェッブ宇宙望遠鏡が観測した原始星「Sh2-284 p1」のジェット
9/18(木) 11:37
URLﾘﾝｸ(news.yahoo.co.jp)
原始ブラックホールの“最後の瞬間”が見られるかも
9/17(水) 19:00
URLﾘﾝｸ(news.yahoo.co.jp)
60年間気づかれなかった地球の「隠れた準衛星」、発見される
9/17(水) 19:00
URLﾘﾝｸ(news.yahoo.co.jp)
178:デフォルトの名無しさん
25/09/19 06:57:18.01 ub2LSIBW.net
◇マッチポンプ作業は全業界であるのか！
【話題】AIが生んだ新たな仕事「バイブコード修正屋」とは？ 熱狂の裏で急増する高額な“後始末” [すらいむ★]
2025/09/17(水) 21:53:35.20
ｽﾚﾘﾝｸ(scienceplus板)
>>「バイブコード修復専門家（vibe code cleanup specialist）」と呼ばれる、経験豊富なエンジニアたちによる高額な“後始末”稼業だ。
-
電波で初めてとらえられた「アインシュタインの十字架」
この画像はアルマ望遠鏡がとらえたもので、地球から約78億光年離れたところにある銀河群の重力により、約116億光年の距離にある「HerS-3」という銀河の像が5つに分かれて見えています。
アインシュタインの一般相対性理論によると、質量をもつ物体のまわりでは空間がゆがむために光が曲がります。
光学的なレンズのようなはたらきをすることから、そのような現象は「重力レンズ」と呼ばれます。
重力レンズによって、この画像のように奥にある天体の像が十字形に分かれて見えるものは「アインシュタインの十字架（アインシュタイン・クロス）」と呼ばれます。
（以下略、続きと画像はソースでご確認ください）
astropics 2025.09.18 17:30
URLﾘﾝｸ(astropics.bookbright.co.jp)
上記からしてダークマターは一直線に進むことが可能なのか？
179:デフォルトの名無しさん
25/09/19 13:46:44.80 ub2LSIBW.net
☆安全が証明された中国のAI健全に作成されている事が証明されました！
DeepSeekが推論モデル「R1」をわずか4400万円でトレーニングしたと発表、512基のNVIDIA H800チップを80時間使用
2025年09月19日 12時07分
URLﾘﾝｸ(gigazine.net)
>>この論文が公開されたことで、DeepSeek R1は査読プロセスを経た初の著名LLMとなりました。これについて、論文の査読を担当したHugging Faceの機械学習エンジニアであるルイス・タンスティル氏は、「これは非常に歓迎すべき前例です」「プロセスの大部分を公開して共有する慣習がなければ、こうしたシステムがどのようなリスクを持っているか評価することは非常に困難です」と語っています。
OpenAIがAIモデルの隠れたずるさを減らす実証、o3とo4-miniで実現
2025/09/19 10:25
URLﾘﾝｸ(news.mynavi.jp)
180:デフォルトの名無しさん
25/09/19 20:56:24.59 kwj0OC91.net
WASMは特殊なグラフィックに対して部分的に使うのが最適で、基本的にHTML+JS系がCtrl+F等のブラウザ機能やIMEをフルに使えるか
181:デフォルトの名無しさん
25/09/19 23:32:35.73 InldYzYM.net
WASMの話でブラウザ限定なのもアレだが
ブラウザでの話なら必ずJavaScriptによるグルーコードを伴う
WASMから全機能を呼び出せるためプログラミングはWASMのみで完結できる
182:デフォルトの名無しさん
25/09/20 13:53:37.80 v+zL1yTh.net
俺、スクリプト言語以外の言語で非同期処理を書くのはじめてなんだけど、
他の言語もちょっとした非同期処理を書くのにここまでスマートポインタをがちゃがちゃやらないといけないの？
慣れるまで大変だわ
183:デフォルトの名無しさん
25/09/20 14:22:51.12 DnfXGep7.net
非同期処理と並列処理は直交する別の概念
非同期処理でもシングルスレッド利用なら並列処理は行われないため排他制御は不要であり並行処理のみで実現できる
マルチスレッド利用ならば並列処理も行われるため排他制御のスマートポインタが必要
184:デフォルトの名無しさん
25/09/20 14:29:35.95 6MulabzN.net
他のコンパイル言語ではそこまで煩雑じゃないよ
Rustは根本的にスタックファーストな言語なのだけど、
非同期処理はヒープを多用せざるを得ないので、どうしても同期的なコードに比べて煩雑になりがち
185:デフォルトの名無しさん
25/09/20 15:08:37.34 vM0N4xNE.net
正しい処理をしているかを型で制約するのが Rust の流儀だからごちゃごちゃするけど、 C++ だとそこまで厳しくない替わりに間違えたら黙って暴走しがち。
制約が厳しくなくて実行時に暴走もしないやつは実行中に勝手に色々な制御が介入してるから速度的に不利になりがち。
トレードオフがあるので仕方ない。
186:デフォルトの名無しさん
25/09/20 15:08:41.63 3ZdmIyvv.net
Javaから各スクリプト言語に至るまでオブジェクトはヒープに格納される
187:デフォルトの名無しさん
25/09/20 15:11:29.13 oDVoBqGa.net
>>182
便利で善だからスマートポインタという名前が付いているよ
それなのにスマートポインタを悪のように捉えてるところに違和感
188:デフォルトの名無しさん
25/09/20 15:28:28.03 vM0N4xNE.net
いわゆる動的型のスクリプト言語における変数の実態としては全てスマートポインタのようなものとして実装されてるよ。
実際には不要かもしれない、必要以上のガードがあるスマートポインタだ。
だからプログラマは考えなくて良いようになってるだけ。
189:デフォルトの名無しさん
25/09/20 15:45:26.58 HFxf22eu.net
>>182
んなわけないじゃん
生成AIで他言語に書き直してもらえばすぐ分かるよ
190:デフォルトの名無しさん
25/09/20 15:56:22.22 UDg7vyx0.net
>>189
C++でもスマートポインタを使う
それ以前にRustのような非同期処理の手軽さはC++にないから止めとけ
191:デフォルトの名無しさん
25/09/20 16:20:32.56 J9I3m3UZ.net
複オジ仕草は相変わらずだな
見苦しいったらありゃしない
192:デフォルトの名無しさん
25/09/20 16:22:53.27 xgkvAj6i.net
>>182
どのスマートポインタ？
それを書けていないので区別がついていないことが敗因かもね
例えばヒープを管理するスマートポインタならばGCでない言語なら必要だよ
これは非同期でなくても必要だね
例えば排他制御をするスマートポインタならばマルチスレッドで排他制御を必要としてる状況だからどの言語でも必要だよ
もしくはスマートポインタより不便でミスしやすい形でのmutexなどが代わりに必要だね
193:デフォルトの名無しさん
25/09/20 17:59:15.89 gBMyGQKP.net
見苦しいというか本当に醜いね
194:デフォルトの名無しさん
25/09/20 19:07:52.69 yVoW5m+/.net
スマポがいらないのはスクリプト言語かどうかじゃなくてGCの有無の違い
パフォーマンスクリティカルな場面だと悪者にされがちだけど、GCは本来面倒なものをかなり楽に扱えるようにしてる
なので、Rustが大変に思うなら素直に他の言語にすれば良いじゃんと思う
そういう面倒さと付き合う覚悟があるならRustはとても良い言語 (C++などに比べれば)
195:デフォルトの名無しさん
25/09/20 19:19:36.48 6ax0UV6a.net
>>194
GCの有無とスマートポインタに関係はない
そもそもポインタを持つGC言語も多い
そこで目的毎の抽象化したポインタを持てばスマートポインタになる
例えばRustのMutex<T>のようなスマートポインタを持つ場合とバラバラにTとMutexを別個に持つ場合の利便性や安全性を比較するとわかりやすいだろう
これらはGC言語でも必要である
196:デフォルトの名無しさん
25/09/20 20:27:30.86 V+ThLNIP.net
Mutex<T>はスマートポインタじゃないんだが
スマポってリソースの寿命管理の仕組みだから、GCが面倒を見る言語では要らんでしょ
ポインタを持つGC言語はあるけど、スマポとGCの両方を使う言語は (少なくとも自分の知る限り) 無いと思う
ロックはまた別の話だ
197:デフォルトの名無しさん
25/09/20 20:45:04.95 4vgI+Jqh.net
スマートポインタは「高機能なポインタ」くらいの意味で、寿命管理以外の機能を含む場合はあるよ。
198:デフォルトの名無しさん
25/09/20 21:07:14.91 SpoPrW2p.net
正確にはMutexのlock()で得られるMutexGuardが条件をすべて満たしている正真正銘のスマートポインタ
GCのある言語でもこのようなスマートポインタは有意義
199:デフォルトの名無しさん
25/09/20 23:31:35.11 4/wGeSfa.net
いずれの機能もスマートポインターに慣れてしまえばスマートポインターなっていない従来の形は使いにくくミスも生じやすくわかりにくいことに気付けるよ
200:デフォルトの名無しさん
25/09/20 23:48:28.53 7sNK9LUJ.net
GC言語ではわざわざスマートポインタの形で実装する必要性が皆無
スコープと外部リソースの開放を結びつける仕組みは言語がそれぞれ用意してるからね
201:デフォルトの名無しさん
25/09/20 23:59:25.70 A0B8UFqR.net
GoはMutexと変数ばらばら
結びつける仕組みってなに
202:デフォルトの名無しさん
25/09/21 02:43:46.06 ETMxp5J0.net
Mutexなどロックしている間のみ変数にアクセスできるしくみを用意している言語はRustだけじゃね？
203:デフォルトの名無しさん
25/09/21 04:07:15.57 Obb0mglL.net
内部通報で無理なので犯罪者通報
暗黒状態の量子もつれを生成することに成功：世界初の快挙
公開日2025.09.10 18:30:27 WEDNESDAY
URLﾘﾝｸ(nazology.kusuguru.co.jp)
>>量子もつれが非常に壊れやすく、外界のノイズ（熱の揺らぎや周囲からの電磁波など）によって簡単に消えてしまうことです。
>>このノイズによる量子もつれの崩壊現象は「デコヒーレンス」と呼ばれ、量子技術が実験室の外で広く実用化されるのを妨げる最大の壁となってきました。
◇
・どうやって地上で行えるのですか？
・ 嵐の中や甘風が強い中での車での走行中などどうやって維持しているのかな
・UFOは重力県内でテレポートしている偽物だろう？
◇
・統合失調症から見て犯人不明で周囲の人は知っているかもしれませんが宇宙人だと名乗っているのとテレポート技術を所持している
・7人殺害した
・お前で埴鎮目だ
・殺害した人野事を晩酌で高笑いをしている
・お前「被害者＝統合失調症＝２４実感３６５日幻聴などの幻覚あり」を人質に立てこもる
・絶対に殺させる「自殺か殺人かは不明ですがさせる」
・コロな症状を引き起こせる
※など上記の事を話してきた
◇
ここにも愉快犯の犯人組織が居るだろう！
204:デフォルトの名無しさん
25/09/21 14:55:02.19 puxC1vt4.net
>>182
Rustだけ
205:デフォルトの名無しさん
25/09/21 16:00:08.03 qk42F/D+.net
>>204
嘘つくな
どの言語でも排他制御が必須
それがなくても動く言語は常に自動で排他制御されて重いかシングルスレッド
さらに非GC言語はshared_ptrやArcなどが必須
それがなくても動く言語はそれ相当を常に自動でされて重いかリスキーな自己管理になる
206:デフォルトの名無しさん
25/09/21 18:04:41.94 swJZ0gup.net
複おじの見識の狭さを露呈してるなあ
>>182はたぶんWebだろうから、排他制御なんかアプリケーションコードの範囲ではほとんど必要無い
207:デフォルトの名無しさん
25/09/21 18:58:11.62 85rn3aD/.net
>>182にウェブらしき話がないけど
ウェブでも共有データがあって排他制御されるよ
208:デフォルトの名無しさん
25/09/21 19:30:32.11 dKb8R8vZ.net
バックエンドにしろフロントエンドにしろ、Webは並列処理って意味合いでスレッド使うだろうか
1つの処理がバカスカスレッドたてて許される場面が思い浮かばないんだが
209:デフォルトの名無しさん
25/09/21 20:54:02.67 IgDJrn6I.net
>>208
Webなどは非同期タスクを使う
非同期タスクはマルチスレッド上でスケジューリングされる
スレッドは間接的に自動的に使われる
用いられるスレッド数は変更できるがCPUのマルチコアスレッド総数そのままがデフォルト値
210:デフォルトの名無しさん
25/09/22 05:34:04.05 eSSLiA97.net
goてポインタ使えるのにgcなのわけわからん
211:デフォルトの名無しさん
25/09/22 12:38:06.53 TdSBLD5R.net
ARM版のWindows上でRustを使ってる人に質問です
x64用のbinaryを吐かせたいのですが
1.x64用のRustを入れて(Prism上で動作させて)そのままx64だと思い込んでコンパイル
2.ARM用のRustを入れてx64用にクロスコンパイル
3.その他
どれがお薦めですか
皆さんはどうやってますか
212:デフォルトの名無しさん
25/09/22 12:40:23.44 pcxt24gw.net
GitHub Actions上でコンパイル
213:デフォルトの名無しさん
25/09/22 14:50:51.96 NxMlCQ3l.net
5年前ぐらいに試したときは、ARM版のWindows上で動作するリンカがなくて詰んだような覚えがあるな
（リンクとコンパイルは別だといえばそれまでになっちゃう話だけどさ）
今は変わったんだろうか？
214:デフォルトの名無しさん
25/09/22 16:07:58.75 ugFXIsjr.net
Rustで業務開発している人、日本にどれだけおるんだろ
そもそも求人しても集まらなくない？ tokioとかまともに扱える人、日本にどれだけおるんだろ
てか、そのレベルのコーダーならば、別の領域の技術まで収めてる可能性が高いから、
難易度の割に単価の安いRustに関わる現場に入ってくれる確率が低い気がする
215:デフォルトの名無しさん
25/09/22 16:40:27.78 amN/g6Kj.net
とりあえずtarget指定でクロスコンパイル
216:デフォルトの名無しさん
25/09/22 18:24:20.41 vLYT2rnq.net
業務で使うとしても、ニッチなところでワンポイントで使うだけなんじゃないかな
217:デフォルトの名無しさん
25/09/22 19:04:44.83 Vzryeu9P.net
「Rust」の平均単価が3カ月連続上昇 エン・ジャパンがフリーランス案件の分析レポートを発表
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
開発言語別では、比較的新しい言語「Rust」が3カ月連続で平均単価を伸ばし、87万4000円（2025年6月比で4.4％増）で1位となった。
言語別単価表
URLﾘﾝｸ(s3-ap-northeast-1.amazonaws.com)
218:デフォルトの名無しさん
25/09/22 22:16:09.39 vLYT2rnq.net
>>217
エージェントの公開データを真に受けるのはちょっと…
あと、RustがGoと0.2しか離れてないわけがない。適当すぎ
219:デフォルトの名無しさん
25/09/22 22:23:29.95 32nEMimf.net
Rustの驚き屋とか自作自演しながらここに書き込むお仕事があるよ
220:デフォルトの名無しさん
25/09/22 23:58:16.13 6AVVH58o.net
paypayがrust使ってjavaの10倍負荷下がったゆうてたしweb系なら求人ありそう
実際小さいベンチャーだと割とある
組込rustはさすがになさそう
221:デフォルトの名無しさん
25/09/23 00:20:48.81 fPMt7Vn0.net
組み込みは宇宙関係は（日本含めて）そこそこある
車はボルボあたりがやる気あるけど日系はどうだろうね
家電はまぁわざわざRustじゃなくてもって感じか
222:デフォルトの名無しさん
25/09/23 09:46:49.33 JEEzvMHJ.net
人命や数千億単位の金がかかってる機器の制御でヒープの動的アロケーションなんかやるもんなのか?
コネクティッドカー機能とか少々問題が出たところで死人が出ない上位レイヤなら、ある程度雑に作るだろうけど
223:デフォルトの名無しさん
25/09/23 11:07:26.61 fPMt7Vn0.net
OSないような低レイヤ組み込みならno_stdでヒープとか使わないでしょ
224:デフォルトの名無しさん
25/09/23 15:03:47.29 R9fXR9Ay.net
オナニーにも二種類あります
ムラムラしてやるのはいいオナニー、なんとなく暇だからやるのは悪いオナニーです
それでは、いいオナライフを
225:デフォルトの名無しさん
25/09/23 18:08:05.88 3GljEKUb.net
>>211
Win10かWin11かで違うね
Win11ならほぼ問題無いはず
226:デフォルトの名無しさん
25/09/24 10:08:26.98 sSJtDSWT.net
担当者の数が少ないレイヤは絶滅して数が多いレイヤだけが生きのこる・・・という科学の理論がある
計算機科学じゃないが
227:デフォルトの名無しさん
25/09/24 22:08:50.16 USnnfnCB.net
Rustコンパイラの悩みを一掃！開発者調査が示す、ビルド高速化への道
URLﾘﾝｸ(gamefi.co.jp)
2025年のRustコンパイラ性能調査の概要
この調査は、Rustの公式ブログで2025年6月にアンケートが開始され、9月9日に結果が公開されました。
調査の目的は、ユーザーがRustコンパイラの性能でどんな問題を感じているかを把握することです。
今後の改善策と関連ニュース
228:デフォルトの名無しさん
25/09/25 23:36:25.10 Inzkj0oI.net
コンパイルが遅いならjsを使えばいいというのがjsの存在理由なんだな
コンパイラもインタプリタもどっちも計算機科学の管轄内だし
外来種エセ科学に負けるな
229:デフォルトの名無しさん
25/10/04 21:39:35.87 MpcY569I.net
外来種エセ科学とかいう何の意味のない単語
230:デフォルトの名無しさん
25/10/05 23:48:14.10 J8doO7Is.net
Case Study: How Proton uses Rust to build secure cross-platform applications for millions of people
URLﾘﾝｸ(kerkour.com)
231:デフォルトの名無しさん
25/10/06 06:34:16.54 Lg9QofNc.net
unsafeという単語がもっと無意味な単語だったら発生しなかった疑問や議論があると思う
232:デフォルトの名無しさん
25/10/06 08:57:27.48 2MfGYhwC.net
unsafe って outerRust 程度の意味だよなー
せいぜい鼻から悪魔召喚されるぐらいだから ヘーキヘーキ
233:デフォルトの名無しさん
25/10/06 23:49:08.71 qYNp3V7N.net
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(m.media-amazon.com)
234:デフォルトの名無しさん
25/10/07 05:36:35.33 HynxI6Nw.net
安心安全の爆速言語ｗｗｗ
235:デフォルトの名無しさん
25/10/07 08:38:37.56 rIBjDf4i.net
トーンポリシングのようにトーンを変えるべきと言っているのではない
unsafeを使ったら大変なことになるぞというエセ帰結主義を変えるべき
236:デフォルトの名無しさん
25/10/07 23:34:16.46 XsK8AxHk.net
URLﾘﾝｸ(blog.0xshadow.dev)
237:デフォルトの名無しさん
25/10/08 06:12:45.82 BZ+5Tj3P.net
驚き屋なんだからリンクと一緒に驚いた事を書けよ
238:デフォルトの名無しさん
25/10/08 10:51:04.58 1WScrxrm.net
沈黙が生成されたのか
3回passしてもアウトにならないゲームに最適解はあるんだろうか
239:デフォルトの名無しさん
25/10/09 05:47:10.57 CxVpZ3lb.net
jiff と temporal_rs
ほぼ同時期にほぼ同じ設計・機能のcrateが2つ誕生してしまった
JavaScriptのTemporal仕様をRustで実装したもの
後者はChromeのV8エンジンで使用される
240:デフォルトの名無しさん
25/10/09 05:53:32.32 1tRwvakU.net
後者とは一体...
241:デフォルトの名無しさん
25/10/09 23:29:06.13 5jj473u7.net
Redis-rs 1.0.0 rc 来たね
242:デフォルトの名無しさん
25/10/15 02:42:51.67 HPDHDP+y.net
Rustの構文を学習するのにかかる期間は平均して100時間
この話を聞くと、大抵の奴は『俺、他の言語の構文を普通の人の○○倍の速さで取得できたから、Rustもせいぜい30時間で取得できるだろうな』と考えがち
そういうの含めて平均100時間なんだよ。罠すぎる
243:デフォルトの名無しさん
25/10/15 12:10:29.06 3+xAPSs8.net
さすがに他の言語の経験があってRustの構文だけで100時間は池沼
VBAとかですら実務は厳しいだろ
244:デフォルトの名無しさん
25/10/15 12:41:03.98 HPDHDP+y.net
The Bookをぜんぶ読んだらどう足掻いても100時間ぐらいはかかる
245:デフォルトの名無しさん
25/10/15 12:51:51.60 RLwHyQpR.net
毎日1時間だけでもたった3ヶ月で習得できる
Rustを理解できない人はよっぽどの境界
246:デフォルトの名無しさん
25/10/15 12:52:33.33 Wj1hklt3.net
「構文」の意味を理解していないレベルならそうかもな
247:デフォルトの名無しさん
25/10/15 13:35:07.70 R03CpXNj.net
100時間もかからないだろ
Rustは抽象化が進んでいて理解しやすくコードも書きやすく読みやすい
ところが抽象化は知能レベルがある程度ないとかえって難しく理解できないのだ
一部の人々にとってRustは難しい
248:デフォルトの名無しさん
25/10/15 14:50:44.09 Dy5l/sKj.net
などど知能レベルが低く抽象化を全く理解していなかったおじさんが言っており
249:デフォルトの名無しさん
25/10/15 17:01:58.19 r5azlaHS.net
他の言語やってたら結構わかりやすいと思うんじゃが難しいか？
ぶっちゃけ所有権ライフタイムジェネリックだけ読むだけでもええと思うけどあとはパクリみたいなもんだし
250:デフォルトの名無しさん
25/10/15 17:27:57.11 Wj1hklt3.net
C++
C#系言語を一つ(TypeScript, Kotlin等)
関数型言語を一つ
これくらい知ってたら楽勝だね
251:デフォルトの名無しさん
25/10/15 17:59:28.03 LJhrxkeQ.net
Rust の型システムはだいたい Haskell そのまんまな感じ。
衛生的マクロは Scheme 風だし、手続き的マクロは Common Lisp をはじめとする伝統的な Lisp のスタイルが踏襲されてる。
Rust だけの特徴と言えるのはライフタイム注釈くらいじゃない？
まあそれがそこそこ馴染みにくいものではあるんだけど。
252:デフォルトの名無しさん
25/10/15 18:23:05.35 V1g0382z.net
所有権の複製おじさんいたやん
ああいう人にとってはRust難しかったやろな
あのクソコード見てるとなんか苦心が透けて見えて苦笑いやわ
253:デフォルトの名無しさん
25/10/15 20:05:33.91 HPDHDP+y.net
>>249
学習コストが高いのは、所有権ライフタイムを除けば、マルチスレッド関連だと思う
シングルスレッドの同期処理しかやらないなら、10時間以下の学習で実践投入できる……かもしれないけど(やったことないから分からない)
254:デフォルトの名無しさん
25/10/15 20:24:15.79 EuiQLgBK.net
fortranよりも使われtないRustをこのAIの時代に学ぶって何の意味があるんだろ
255:デフォルトの名無しさん
25/10/15 20:45:37.79 uIA1Z+wo.net
>>253
マルチスレッド関連でRust特有はSendとSyncというマーカートレイトで区別するとは賢いなあくらいじゃないか
Mutexや条件変数など排他制御やchannelなどは他の言語で知ってれば困らない
いきなりatomicまで進む人ならメモリモデルはC++と同じ
ArcはRc理解した後なら悩むことなく
256:デフォルトの名無しさん
25/10/15 20:50:01.63 tYojUFcq.net
>>254
AI時代だからこそ、AIが扱う上で表現力が高くて高速堅牢な言語には価値がある
と言いたいところだが、Rustはライブラリを全面的にコミュニティに頼らなきゃいけないし、あまりデファクトスタンダードが揃ってなくて常に乱立してるからAIと相性良くないんだよなあ
乱立に関しては比較的新しい言語だからというよりは、文化的に割とそういう傾向がある気がするんだよね
257:デフォルトの名無しさん
25/10/15 21:03:09.05 HPDHDP+y.net
>>255
Rust以前に触れた言語や領域の経験値と、Rustでやりたいことがそこまで被ってれば学習は早いだろうな
俺は元データサイエンティストだからC/C++とか触ってもOpenCVだったんだよね…
pythonの経験値は十年あるんだけどさあ
258:デフォルトの名無しさん
25/10/15 21:04:31.59 HPDHDP+y.net
あと非同期処理周りでヒープにFutureをピンさしてメモリ管理するのいまだに慣れない
辛いわ
259:デフォルトの名無しさん
25/10/15 21:05:33.85 vyykZZUm.net
そういうコミュニティ依存って、今時の言語の、もっというとフロントエンドの文化なんだろうけど
それこそ10数年生きるのが普通なバックエンド向けのRustとは最高に合わないところではあるわな
260:デフォルトの名無しさん
25/10/15 21:13:31.82 wJCBzpoD.net
>>254
C/C++の置き換えを狙ってるならFortranとはあんまし被らないでそ。
本気で置き換えるなら512Bや256Bという、1kBも無いようなマイクロコントローラーにも書き込めるバイナリ吐くとか。
(Cとアセンブラしかない世界）
そうでなくてもAIの時代だからこそ自動運転な自動車組み込み向けはC++よりもRust。
Fortranとなら、それこそスパコンで並行並列処理は文法的にはRustの方が有利だけど、ライブラリやら最適化やらはFortranが長年資産やノウハウがあるから一朝一夕には行かんわな。
それこそ、これからの動き次第。
261:デフォルトの名無しさん
25/10/15 22:43:58.29 /hVmSz/X.net
>>258
何が辛い？
個別に目的と必要性と仕組みを理解しておけば組み合わさっても困らない
262:デフォルトの名無しさん
25/10/15 23:04:23.69 dwkfuJij.net
>>242
そもそも何を作るかによる
あんたのような素人は黙っていた方がいい
263:デフォルトの名無しさん
25/10/16 00:12:35.85 ljIqKmv0.net
非同期やマルチスレッドを使わない分野もいくらでもあるため
何を作るかによるのは正しい
しかし黙れはスレ妨害
264:デフォルトの名無しさん
25/10/16 01:46:09.80 0KrpoGON.net
Rustの構文って無駄の少ない洗練された感じがあるよな
関数型言語ぽい部分も多いから古めの手続き型言語ユーザーからしたら難しいのかもしれないが
265:デフォルトの名無しさん
25/10/16 02:22:05.21 trMgX6m0.net
日本はともかく世界的に見れば流行りの第一言語はpythonだから
そこからRustを覚えるのは割としんどいはず
266:デフォルトの名無しさん
25/10/16 02:22:08.52 trMgX6m0.net
日本はともかく世界的に見れば流行りの第一言語はpythonだから
そこからRustを覚えるのは割としんどいはず
267:デフォルトの名無しさん
25/10/16 03:06:05.37 XSc3rEJ2.net
Pythonしか使えないような似非プログラマーは
Rustじゃなくてもいいから他の言語も使えるようになりなさい
268:デフォルトの名無しさん
25/10/16 07:39:35.29 LogNv62J.net
>>264
そうか？
C#などのモダンC系に倣って関数型由来の機能を取り入れてはいるけど、根本的に関数型じゃないからこそ複雑になってる面が大きくて、
割り切ってもっと関数型に寄せれば色々切り捨てることは可能なはずだよ
所有権や可変参照の排他性みたいなRustのユニーク機能って結局は手続きプログラミングのために必要になので
269:デフォルトの名無しさん
25/10/16 07:49:42.75 dQTw8Gx2.net
>>264
逆ポーランドじゃない構文は、文を読む方向と制御の流れが異なるという根本的な問題があるから洗練されることは無い。UFCSぐらいはサポートしてほしいところ。
270:デフォルトの名無しさん
25/10/16 07:52:40.33 77JaeTBw.net
>>268
可変参照を許さない関数型は非効率で死んでいった
C++と同等の速度を出せないなら存在意義がない
C++と同等の速度を出せた上でRustは様々な抽象化に成功している
271:デフォルトの名無しさん
25/10/16 07:57:25.89 0MaBLq3K.net
>>269
UFCSは最悪の機能
可能な限りフリー関数をなくして最小限にすべきであり
UFCS適用可能なものはそもそもフリー関数ではなくメンバ関数とするのが正しい解決方法
Rustもおおむねその方向
272:デフォルトの名無しさん
25/10/16 08:15:27.91 IOBKmFcT.net
pythonて人気てゆうよりもはやbasicみたいな感じじゃないの
python使う仕事てpython自体の知識より数学とか統計の知識がいりそうだし
てかaiてpythonみたいな遅いやつ使ってて大丈夫なんかな
rustにも機械学習ライブラリあるしそれでよくね
組込 web ai全部rustでできるせつ１
273:デフォルトの名無しさん
25/10/16 08:18:48.99 dQTw8Gx2.net
>>271
それは洗練された構文の話じゃないね。自分でも「機能」て書いているのに気づいていないのかしらん？
274:デフォルトの名無しさん
25/10/16 08:20:17.29 LogNv62J.net
>>270
所有権や可変参照の排他性は場合によっては実行効率が犠牲になる
程度問題よ
275:デフォルトの名無しさん
25/10/16 08:32:20.65 CRgJz368.net
UFCSは有害な汚染
導入してはいけない
276:デフォルトの名無しさん
25/10/16 08:35:08.89 JsVTJVWO.net
>>274
所有権で実行効率が犠牲になる？？
そんな事例あるか？
277:デフォルトの名無しさん
25/10/16 08:44:13.38 5Jgs3V7t.net
>>274
実行時にペナルティが生じうるケースなんてあるの？
278:デフォルトの名無しさん
25/10/16 08:47:02.94 dQTw8Gx2.net
「正しい」とか「有害」とか断定してるのにその根拠は示せないのか。
科学から遠く離れた宗教の世界ですなぁ。しかも教祖ではなくタダの信者が権威を騙るのところとかは堕落した宗教みたいに見える。
279:デフォルトの名無しさん
25/10/16 09:01:39.29 UsUzzAEG.net
UFCSってフリー関数の第一引数が型Xならば勝手に型Xにimplしてメソッド増やしたことにみなしてしまおうという汚染のやつだろ
Rustではわざわざ混乱を避けるためや注意のため敢えてメソッドにせずにフリー関数のみを用意しているケースもあるくらい清潔さを気にしているのにそこへUFCS汚染を持ち込むのは正気の沙汰じゃない
280:デフォルトの名無しさん
25/10/16 09:28:00.47 CGNb/wdl.net
>>276
そりゃ現実に競合しないと分かっていてもMutexを使わざるを得ないケースとか普通にあるでしょ
281:デフォルトの名無しさん
25/10/16 09:48:06.42 0aSwdLuG.net
>>280
Mutexはマルチスレッドでメモリを共有する時にその排他制御のために使う
Cなど他の言語にもMutexは当然ある
「所有権で実行効率が落ちる」という聞いたこともない話の事例になっていない
282:デフォルトの名無しさん
25/10/16 09:56:20.09 CGNb/wdl.net
>>281
データストアを複数スレッド間で共有していても現実に絶対に競合しないと分かっている状況というのは普通にあるよ
283:デフォルトの名無しさん
25/10/16 10:07:41.24 LiHWqK2J.net
競合しないはず大丈夫だろうと思ってMutexを使わなかったために稀に競合する時のみバグる話はRustと関係なく大昔からあるよ
だからRustと関係なくどの言語でもMutexを使うのが正解
所有権と関係なし
284:デフォルトの名無しさん
25/10/16 10:45:16.18 dQTw8Gx2.net
>>279
メソッドを厳密に管理したいんだったら、メソッドを表すドット表記とは別の表記を使えばいいだけの話かと。例えばアロー表記とか。
（もともとは>>264の洗練された構文の話だし）
メソッドにフリー関数とは違う特別な意味を持たせて使い分けしなくてはならないRustでそうなるのはそうなのかもね。
メソッドのユーザー側に隠蔽できていないのは洗練されていないと思うけど。
285:デフォルトの名無しさん
25/10/16 11:10:36.20 trMgX6m0.net
Rustで非同期処理を実装してるけど、やっぱ魔境だと思うわ
俺はできるけど……って、謎の気持ちになる
286:デフォルトの名無しさん
25/10/16 11:16:10.30 trMgX6m0.net
技術的にニッチなところ触りすぎてる時の危機感がすごい
287:デフォルトの名無しさん
25/10/16 11:17:39.14 hFPLpyjg.net
>>283
データ競合の検証が不十分なだけだ。
検証をサボる代わりに不必要なところまでガードするのもひとつの選択ではあるがそれを唯一の正解とすべきではない。
288:デフォルトの名無しさん
25/10/16 11:37:34.04 trMgX6m0.net
排他制御はコードだけで競合しないことを保証できない時はとりあえず実装するものと思ってる
289:デフォルトの名無しさん
25/10/16 11:44:21.55 oH2hiodt.net
競合による不整合は殆どの場合複数のデータストアに跨って生じるもので、競合を想定していないロジックが万一競合したなら、Mutex使ってようがまともに動く可能性は低い
そもそもそういった予期せぬ事態が発生しにくくするという点においては、競合を防ぐ解としては関数型的なイミュータブルのほうがずっと有効だ
結局どこまで効率を犠牲にして安全側に倒すかという程度問題であり、決してRustのやり方が絶対的な解というわけではない
290:デフォルトの名無しさん
25/10/16 12:45:11.24 732JrVKw.net
理屈は通ってるけど現場では通らないだろうな
291:デフォルトの名無しさん
25/10/16 13:18:22.07 XPeMMJXV.net
>>289
デタラメだな
その関数型的なイミュータブルでは何の解決にもなっていない
例えば最も単純な1, 2, 3, 4, 5, ...と順に抜けがなく重複しないID発行機をマルチスレッドで共有する場合を考えてみろ
292:デフォルトの名無しさん
25/10/16 14:14:20.51 LogNv62J.net
>>291
言葉通りにやるならSTMとかあるし、そもそも関数型なら実際には連番の遅延シーケンスを作ってmapするか、
もしくはIDなしで結果のシーケンスを作った上で後からIDを振るのが一般的だろうな
293:デフォルトの名無しさん
25/10/16 14:46:26.27 r/geUxba.net
>>292
話の根幹であるマルチスレッドに対応できていない
「連番の遅延シーケンスを作ってmap」「IDなしで結果のシーケンスを作った上で後からIDを振る」
しかも現実のシステムが作れない
294:デフォルトの名無しさん
25/10/16 15:14:30.10 8nYGMC36.net
>>289
関数型イミュータブル手法ではマルチスレッドで競合する部分をどう解決するの？
>>292
それでは何も解決できていないですね
295:デフォルトの名無しさん
25/10/16 15:28:40.11 CGNb/wdl.net
>>293
mapを並列実行すりゃいいだけ
Rustでもそんなcrate山ほどあるしごく普通のテクニックよ
296:デフォルトの名無しさん
25/10/16 15:33:47.69 7eXHvQg1.net
>>295
色んなリクエストを処理してるマルチスレッドが動いていて各々がIDを欲しいのだからmapは無理だな
297:デフォルトの名無しさん
25/10/16 15:38:04.63 CGNb/wdl.net
>>296
知らんがな
WebアプリなんだったらDBかUUID使うんだからmutexがどうのという話じゃないぞ
298:デフォルトの名無しさん
25/10/16 15:44:47.08 /TAOeXj6.net
>>297
そんな特定の話はされてないよね
マルチスレッドで必ず起きる競合を
イミュータブルな関数型を使えば回避できて安全だ！とウソの主張をする人がいる話だよね
299:デフォルトの名無しさん
25/10/16 15:56:59.81 CGNb/wdl.net
>>298
だからSTMでできるでしょ
CAS命令使うからlockなんか要らん
300:デフォルトの名無しさん
25/10/16 16:35:23.71 w55hMUbI.net
普通はatomic fetch-addするからソフトウェアのレベルでは競合しないわな
301:デフォルトの名無しさん
25/10/16 16:38:08.70 IDpz7JRe.net
>>295
mapを並行実行できるのはリソースを重ならずに分割できる狭い範囲の話のみだよ
実際に使ってみればわかるよ
共有リソースがある場合は無理
302:デフォルトの名無しさん
25/10/16 16:50:42.80 ObLVPGO+.net
>>299
RustもCAS命令が使えますしlock freeにできます
Rustの方法より優れた方法があると言う話の流れでそれは本末転倒でしょ
Rustが最善だと認めたことになってしまいます
303:デフォルトの名無しさん
25/10/16 17:54:47.80 w55hMUbI.net
クソダサい
小学生かよｗ
304:デフォルトの名無しさん
25/10/16 18:16:41.15 yQ7FE2zJ.net
atomicモジュールはC++を模倣しただけだからRustの方法とかRustが最善とか言うのは恥ずかしいからやめて
305:デフォルトの名無しさん
25/10/16 20:04:40.86 3fXKt01N.net
それを言いだしたら
RustはC++0xから分岐した言語だし
306:デフォルトの名無しさん
25/10/16 21:06:43.72 JgNGnet3.net
結局Rustより秀でた方法は存在しないのかよ
307:デフォルトの名無しさん
25/10/16 22:27:36.69 Aijr1hHS.net
並行並列処理と言えばHaskellで初めて知ったけど、STM（ソフトウェア・トランザクショナル・メモリ）とかはRustに無いの？
OCamlでもやってたからHaskell固有のものじゃないっぽいし、イミュータブルなRustに向いてそうだからRustにもありそうなもんだけど。
308:デフォルトの名無しさん
25/10/16 22:50:37.13 z8fEfbMT.net
>>307
cratesで実装してるものはあるけどRustとは合わないから基本的に使われない
Rustは関数型じゃないからcomposabilityへのこだわりがなく
race conditionを静的に避ける仕組みはすでにあるわけで
実行時のオーバーヘッドが必要なSTMをわざわざ使うメリットがない
309:デフォルトの名無しさん
25/10/16 22:58:22.11 Aijr1hHS.net
>>308
そうなのか。
ありがとう。
310:デフォルトの名無しさん
25/10/16 23:57:58.80 S0/FXV9l.net
STMは基本的に競合の事後検証トランザクション方式なので様々な問題がある
1つは競合が見つかり検証失敗時にロールバックしてリトライするコスト
もう1つは競合が起きて事後に競合が見つかるまで競合した不正な状態のままプログラムが進むため
正常では起こらないループ停止条件の破綻による無限ループや
IOなど外部への副作用を伴うと不正な状態のまま正しくない書き込みが起きたりすることなど
311:デフォルトの名無しさん
25/10/17 02:21:36.13 tcxlU+Jp.net
>>310
事後検証方式だからダメみたいな考えは間違い
compare and swapだって事後検証方式だからリトライコストも発生するし
競合が起きて事後に競合が見つかるまで競合した不正な状態のままプログラムが進む
312:デフォルトの名無しさん
25/10/17 03:12:19.26 KXGM3Zvt.net
>>311
STMはCASよりコストがかかる
CASは不正な状態が生じない
まず競合時の復元コスト
STMはロールバックのためにトランザクション全ての記録が必要でその復元も必要
CASにはロールバックも値の復元もない
元々得た古い値がそのままあるかを確認するのみである
次に不正な状態のままプログラムが進むかどうか
STMはトランザクションの途中で競合が起きた場合にそれに気付かず進むため不正な状態になる
CASは競合が起きた場合にそれ以上進まないため不正な状態にならない
ちなみにCASで最初に得た古い値に基づき処理するのは不正ではなく正常な状態であり、競合が起きなければそれがそのまま採用される
313:デフォルトの名無しさん
25/10/17 07:05:35.11 r0gF6NYJ.net
単純に競合と1対1対応のCASを直接使う方が粒度も細かく自由度も効率も高いのは当たり前。
現実にはCASとは戦略の異なるLL/SC利用のCPUアーキテクチャもあってCASだけで抽象化するのは効率が悪く不利なので、C++とRustでは多数の不可分関数を用意していてそれらを使い分けることで対応できる。
アーキテクチャ毎のメモリバリアも様々なので、実装するアルゴリズムに対応して必要十分なメモリオーダーも指定する。
314:デフォルトの名無しさん
25/10/17 10:20:11.61 Anu0zAHn.net
さすがに単純なCASで代替するとかいう言説に関してはSTMというか基本的な競合と排他制御の概念を理解してきなさいと言うしかないが、
RustでSTMがあまり採用されないのは、>>308の言ってるようにそもそも静的に競合を回避できるケースを別にすれば、リトライ自体があまり好まれないというのが大きな一因だろう
所有権システムと相性最悪だし、レイテンシの予測可能性が損なわれる点はRustの得意分野を考えると受け入れ難い
Webなんかで雑にリトライしていいケースももちろん多いけど、そういうのはSTMなんか使わなくてもレコード単位の粗粒度な楽観ロックで十分だからな
315:デフォルトの名無しさん
25/10/17 13:56:47.42 8ZRl+8lG.net
>>312
STMのほうがCASよりコストがかかるのは当たり前
その分より高い抽象度で複数のオペレーションを1つのアトミックなオペレーションとして合成できる
CASならロールバックコストやリトライコストがかからないと思ってるのは間違い
CASの1つのメソッド呼び出しだけれ見ればそりゃロールバックもリトライもない
でも実際のアプリケーションではどちらも必要
STMの”不正な状態”というのは不正確な認識なんだけど
君の言うところの”不正な状態”というのはCASでももちろん発生する
>STMはトランザクションの途中で競合が起きた場合にそれに気付かず進むため不正な状態になる
CASだって競合が起きた場合にcompare and swap等を実行するまでは競合を検知できない
これは君が言うSTMの”不正な状態”と全く同じ
比較する粒度が根本的に間違ってるのかな
316:デフォルトの名無しさん
25/10/17 16:48:06.46 eIkdvZED.net
>>315
複おじの頭で捻り出せる限界が>>293程度の例なわけだから、複数のストアが絡むトランザクショナルな排他制御なんて想像できないんだろう
とはいえ単一のストアを想定するとしたらSTMは単なるCASと事実上等価になっちゃうから
CASと比較してSTMを下げるのはちゃんちゃらおかしいのだが、それも理解していないという
317:デフォルトの名無しさん
25/10/17 17:00:36.05 rge03BqN.net
ロックフリーはそれらの諸問題が必ず発生するから使い分けが重要
大きなトランザクションや副作用を伴うものや複数のリソースを扱うものは排他制御の方が有利なことが多いだろう
そして排他制御も使い分けが重要
リーダーが多いならMutexよりも同時利用が可能なRwLockが有利
非同期の場合は性質の異なるtokio::sync::Mutexとの使い分けも重要になってくる
ロックフリーも使い分けが重要
何でもCASを使って書くのは当然愚かで別アプローチのLL/SCアーキテクチャやアトミック演算命令の存在を考慮して各関数を使い分ける必要がある
CASも用途によってcompare_exchangeと偽陽性はあるがより軽くなり得るcompare_exchange_weakとの使い分けが重要
これらの各々の使い分けは用途に応じて少しでも速くなり得る可能性があるため行なわれる
初心者あるいはそこまで速さを追い求めない用途ならば常にMutexを選択するのもあり