Rust part28

**デフォルトの名無しさん** · 2025/03/24(月) 17:37:00.15

公式
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 part27
https://mevius.5ch.net/test/read.cgi/tech/1733146370/

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

**デフォルトの名無しさん** · 2025/04/20(日) 20:56:57.67

>>547
見たけど言語の差ではない。モダンな言語であればほぼ同様の記述が可能。
この手の小さなアルゴリズム実装程度の課題ではRustの面倒臭い面が表に出ることはない

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

課題を変えたら課題の差が計測されてしまう
既に、良い課題と悪い課題があるみたいな空気になりかけている

**デフォルトの名無しさん** · 2025/04/20(日) 22:12:48.98

>>549
他の言語で速いプログラムが出てこないのはなぜなのかなと思って

**デフォルトの名無しさん** · 2025/04/20(日) 22:45:33.70

速度に固執してる奴がたまたまRust信者だっただけだな
まだアルゴリズムの改善でオーダーが変わっている段階であり、細かい最適化とかの次元ではない
遅くない言語であれば十分

**デフォルトの名無しさん** · 2025/04/20(日) 22:51:31.25

clangでも同じにできるよね
どちらもLLVM

**デフォルトの名無しさん** · 2025/04/20(日) 22:53:22.13

rustが本当に速かったらもっと普及したと思う

**デフォルトの名無しさん** · 2025/04/20(日) 22:57:10.24

CやFORTRANより速くはならんからな

**デフォルトの名無しさん** · 2025/04/20(日) 23:05:02.71

こういうミクロなベンチマークは速度を追求すると最終的には拡張命令等によるハードウェア依存の最適化に行き着くから、Rustに勝ち目はない
一応Rustコンパイラを使い続けながら最速に到達することは可能かもしれないが、もはやRustとは呼べない何かになる

**デフォルトの名無しさん** · 2025/04/20(日) 23:16:39.25

インラインでsseして頑張ろう

**デフォルトの名無しさん** · 2025/04/20(日) 23:24:22.62

>>555
Rustは同じ速さにできる

>>556
CPU依存でいいならRustはインラインアセンブラに対応していてRustの変数をそのまま渡すことができるためそのクリティカルな部分以外をそのままRustで記述できるRustは有利

**デフォルトの名無しさん** · 2025/04/20(日) 23:37:04.43

知ってる知ってる

**デフォルトの名無しさん** · 2025/04/20(日) 23:51:55.62

お題スレでノッてくれる人が少ないからってこっちに持ってくんなよって一瞬思いかけたけど
ある意味最初からこっちでやるべきだった話かもしれん

**デフォルトの名無しさん** · 2025/04/21(月) 00:30:33.79

Rustを叩きたいならばRustのコードより速く解を出す別言語のコードを実際に示さないとな

**デフォルトの名無しさん** · 2025/04/21(月) 00:34:48.87

ビット演算とか負けそう

**デフォルトの名無しさん** · 2025/04/21(月) 02:27:05.65

ローテートとか多倍長計算出来るのけ？

**デフォルトの名無しさん** · 2025/04/21(月) 12:26:55.06

調べたらRustはなんでもあるんだな
reverse_bits
count_ones
leading_ones
trailing_ones
rotate_left
rotate_elements_left
carrying_add
carrying_mul
carrying_mul_add
widening_mul

**デフォルトの名無しさん** · 2025/04/21(月) 14:43:44.89

直交性は無いよ

**デフォルトの名無しさん** · 2025/04/21(月) 18:14:51.15

どれについて何の直交性が必要とされてる話だろうか。
全てに該当するレジスタの直交性関連の話だと、制限のあるCISCでは必要があればmov命令の前置きコードが生成される場合もあるかもしれないが、Rustの変数や式で気にする必要はないか。唯一型について、ビットのカウント数/シフト数やilog/power指数はどの型に対してもu32型となるくらい。

**デフォルトの名無しさん** · 2025/04/21(月) 22:52:58.94

>>552
じゃあRust以外の言語でゼロから作ってみせてよ

**デフォルトの名無しさん** · 2025/04/21(月) 23:26:48.36

しかし、裁判所の言う事を聞かない人間が世界中に出没しているから
法廷では、物的証拠が、っていうの時代錯誤だよな

**デフォルトの名無しさん** · 2025/04/21(月) 23:35:15.33

ひろゆきの悪口か
いいぞもっとやれ

**デフォルトの名無しさん** · 2025/04/21(月) 23:36:25.44

>>567
アセンブリ吐かせれば、あら不思議
意味不明のニーモニックから同じ結果がでましたよ

**デフォルトの名無しさん** · 2025/04/21(月) 23:57:43.20

そのRustのコードはCで書けば速くなるような部分もなさそ

**デフォルトの名無しさん** · 2025/04/22(火) 00:16:50.91

>>571
興味があるならハイパフォーマンスコンピューティングという魔界を覗いてくるといい
実はあまり言語は関係なくてRustで同じことができないわけでもないが、Rustの抽象化云々とはかけ離れた異次元の世界だ

**デフォルトの名無しさん** · 2025/04/22(火) 00:26:30.67

HPCのライブラリなんかなんの言語で書かれていても良いけど、インストールだけはCargoで楽にやりたいものだ

**デフォルトの名無しさん** · 2025/04/22(火) 00:35:43.68

アーキテクチャの性能を引き出すためのチューニングというのは高速化できるパターンの蓄積だったりするんだよ。
いいかんじのアルゴリズムを使えば全部綺麗に高速になるなんていうシンプルな世界ではない。
コンパイラは単純に巨大な辞書を持ってる。

分量が強い。
投資が多いほうが強い。
同程度に活発なら歴史が長いほうが強い。

素人がちょっと画期的なことを思いついたくらいでは覆せない物量の世界。

**デフォルトの名無しさん** · 2025/04/22(火) 00:38:12.62

HPCのライブラリがなんで書かれていても良いと言うのはどういう意味なのか
利用する側として現状c,c++でしか使えない物が主流だと思うんだけど
CUDAカーネルもrustで書けるようだけど今のところ利点がない

**デフォルトの名無しさん** · 2025/04/22(火) 00:50:02.20

入出力用言語ということか

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

Rustは清書用

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

HPCは、行指向のデータ構造、動的アロケーションを避ける、データ並列、といった性質があるのでRustと対極なんだよね
Rustがそれらを苦手とするわけではないけど、特に強みがない

**578** · 2025/04/22(火) 09:02:46.96

失礼、列指向の間違い

**デフォルトの名無しさん** · 2025/04/22(火) 10:00:51.24

Rustで作られたOSとかwebブラウザとかないの？

**デフォルトの名無しさん** · 2025/04/22(火) 10:01:41.11

HPCとRustという別の階層のものを比較してるのは滑稽だ。
HPCは大昔からあるものであって、システム構成もGPU時代になってどんどん変わっていってるし、使用言語もFortranから最近はPythonまであり、そしてRustでの試みもある。

**デフォルトの名無しさん** · 2025/04/22(火) 10:38:41.79

クリエイターと消費者がよく比較されるのも滑稽すぎてウンザリする

**デフォルトの名無しさん** · 2025/04/22(火) 12:00:21.29

比較のレイヤーがごっちゃになってカブトムシとライオンを比較するような意味不明な記事が投稿されるのが問題
日本語特有の課題なんだけどね。外国語だったら比較対象が厳密だからこんな比較はされない
外人に生まれたかった

**デフォルトの名無しさん** · 2025/04/22(火) 12:04:09.96

>>580
OSはLinux
ブラウザはFirefoxが
Rustで作られています

**デフォルトの名無しさん** · 2025/04/22(火) 12:21:14.17

>>584
Chromeもこの前のバージョンからRust

**デフォルトの名無しさん** · 2025/04/22(火) 14:56:33.88

WindowsもRustです
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1536253.html

**デフォルトの名無しさん** · 2025/04/22(火) 15:01:02.62

>>584
USO-800

**デフォルトの名無しさん** · 2025/04/22(火) 23:38:16.08

ほとんどの分野でRust化が進んでいるといってもOSとブラウザは巨大すぎてRustへの部分置き換えの領域が広がっていく感じだろう

**デフォルトの名無しさん** · 2025/04/22(火) 23:40:56.68

LinuxはカーネルモジュールがRustでも作れるようになっただけね
ごく一部の置き換えが始められるかどうかってところだけ

**デフォルトの名無しさん** · 2025/04/23(水) 00:32:40.73

なんかい同じ話しとんねんきみら

**デフォルトの名無しさん** · 2025/04/23(水) 07:26:01.78

現状でLinuxやFirefoxのコードベース中のRustの割合ってどれくらいなん？

**デフォルトの名無しさん** · 2025/04/23(水) 07:40:34.19

そろそろChromeの方がFirefoxよりRustの割合高くなってるだろ

**デフォルトの名無しさん** · 2025/04/23(水) 07:45:28.98

PythonでもRust製のuvが今後天下を取りそうな流れになりつつある
爆速すぎる

**デフォルトの名無しさん** · 2025/04/23(水) 07:50:08.26

CPythonのRust版まだー？

**デフォルトの名無しさん** · 2025/04/23(水) 08:11:24.03

>>591
%1ぐらいじゃね

**デフォルトの名無しさん** · 2025/04/23(水) 08:34:59.19

uvは開発速度が異常に速いな
どうなってるんだ？

**デフォルトの名無しさん** · 2025/04/23(水) 08:51:58.21

uvが速いのはパッケージをインストールする際のダウンロードとコピーを避けてるからで、別にRustだから速いわけではないんだけど、
Rustの速そうなイメージを利用してPythonに群がる雰囲気コーダー達にうまく売り込んだよね
シングルバイナリだから細々とスクリプトを読むより起動時のロードが速いくらいの効果はあるかもしれんが

**デフォルトの名無しさん** · 2025/04/23(水) 09:25:47.00

Rustが速いはCが速いというのと同じぐらい実装依存でしょ
正しくはuvの実装が良くて実行速度が速いだけじゃん

**デフォルトの名無しさん** · 2025/04/23(水) 09:26:47.77

>>590
AIの出力のコピペ繰り返してると
Echo Chamber Effect で発散するお

**デフォルトの名無しさん** · 2025/04/23(水) 09:42:39.16

>>598
そう、だからRust最強したいだけの層はuvのようなアーキテクチャの根本的な見直しではなく単純な書き換えばかりに傾倒する
Rust界隈はトランスレートばかりやってて何も生み出してないと揶揄されることが多いが、その原因はまさにこれ
(念を押すが、uvはそれには該当しない)

**デフォルトの名無しさん** · 2025/04/23(水) 10:37:52.74

>>597
596は開発速度の話だろ

**デフォルトの名無しさん** · 2025/04/23(水) 11:18:25.26

Rustは開発効率が良いもんな

**デフォルトの名無しさん** · 2025/04/23(水) 11:41:00.34

uvの人がシゴデキで暇なだけじゃね

**デフォルトの名無しさん** · 2025/04/23(水) 11:43:34.82

あの人普段何して収入を得ているんだろうな

**デフォルトの名無しさん** · 2025/04/23(水) 11:47:44.34

アーキテクチャを変えればアーキテクチャの差が評価される
言語以外何も変えなければ言語の差が評価される

**デフォルトの名無しさん** · 2025/04/23(水) 11:50:43.26

uvの開発元はスタートアップ企業としてVCから多額の出資を受けてるから開発者の生活は安泰
いずれビッグテックへの買収でイグジットか、Anacondaみたいにエンタープライズ向けのサポートで金取るんだろう

**デフォルトの名無しさん** · 2025/04/23(水) 11:52:11.03

uvもそのうちAnacondaみたいになっちゃうってコト！？

**デフォルトの名無しさん** · 2025/04/23(水) 11:52:38.07

おお、会社なんだ
CLIツールで企業できるとか夢のようだな

**デフォルトの名無しさん** · 2025/04/23(水) 12:12:50.41

>>607
可能性はある
VCから出資を受けている以上、必ず資金回収のタイムリミットがあるため、
最終的にどのような形になるにせよ今の状況を続けられるのは数年だけ

**デフォルトの名無しさん** · 2025/04/23(水) 12:16:36.99

デファクトになったらボランティアベースでも回るかね

**デフォルトの名無しさん** · 2025/04/23(水) 20:50:51.07

ディールだけで回るかどうかの方が知りたい

**デフォルトの名無しさん** · 2025/04/23(水) 21:20:01.21

>>609
uvはRustで書かれたオープンソースでライセンスはApache2＆MIT
つまり自由にフォーク可能
したがってuvでサポート契約サービスはありえても
uvを使用料でお金を取る可能性は低く
もしそうなれば有志たちがuvをフォークして無料提供を続けるパターンとなる
したがってuvを気にせずに使っても問題ない

**デフォルトの名無しさん** · 2025/04/23(水) 21:38:33.95

>>612
元々書いた人なり団体が一つでそこが今後クローズドにしますと言えばそこからは普通にライセンス変更はできるよ
そういうのはたまにあるし

**デフォルトの名無しさん** · 2025/04/23(水) 21:40:20.32

GPTに聞いた答え
実際に「Apache 2.0で公開 → 後にクローズドライセンスで商用展開」する事例はかなり多い

**デフォルトの名無しさん** · 2025/04/23(水) 21:45:14.93

もちろんライセンス変更後はフォークできないけど
ライセンス変更前はフォークできるためそれは問題とならない

**デフォルトの名無しさん** · 2025/04/23(水) 21:46:24.20

>>606
uv怪しいよな
Pythonをバイナリで配布してるあたりが金取ってきそうな予感

**デフォルトの名無しさん** · 2025/04/23(水) 21:49:14.92

企業向けは有料でクローズドで個人向けはオープンのままに変わることもよくある話

**デフォルトの名無しさん** · 2025/04/23(水) 21:53:14.31

何言ってんだいニューメディア
紙の本はみんな有料さ

**デフォルトの名無しさん** · 2025/04/23(水) 21:54:56.18

>>617
それはフォーク側でなく元の側な
フォーク側は企業であろうと個人であろうと無料で利用できる

**デフォルトの名無しさん** · 2025/04/23(水) 21:58:30.25

実際開発してるのはその団体でソースがあってもそれからフォークして新たに開発しながら使うのは少ない
mariaDBとかみたいに開発者が分裂してるなら開発者がフォーク先にも残るけど

**デフォルトの名無しさん** · 2025/04/23(水) 22:20:06.96

これまでの有力筆頭だったRyeもuvに統合となったし
Pythonで最強静的解析ツールのRuffもuvと同じところで作られていてRust製だよ

**デフォルトの名無しさん** · 2025/04/23(水) 22:26:23.93

クラウドサービスは有償クローズドでCLIはOSSのままというのはよくあるパターン
自然に課金に誘導できOSS乞食も納得させやすい合理的な形なのだけど、
uvやruffって今のところ囲い込みというより既存のPythonツールセットを一部置き換える形で容易に導入できることを売りにしてるから、
クラウドサービスと統合されたPython開発スイートみたいな方向へ行くのはユーザー離れを招きそうだね

**デフォルトの名無しさん** · 2025/04/23(水) 22:45:26.71

そこに資金回収のフロンティアが残されている

**デフォルトの名無しさん** · 2025/04/23(水) 22:51:38.64

Ruffもuvもgithub上でコミュニティによってIssue/Pullベースで開発されているのを知らない無知なやつが有料化されるぞ！とか見当外れな批判していてワロタ

**デフォルトの名無しさん** · 2025/04/23(水) 22:52:58.24

複おじ頻出単語集
となる

**デフォルトの名無しさん** · 2025/04/23(水) 22:56:52.19

つまり、uvの作者は霞を食べて生きてるってことでいいの？

**デフォルトの名無しさん** · 2025/04/23(水) 23:08:49.69

開発チームにはripgrep, bat, hyperfine, maturinの開発者にCPythonのコア開発者たちがいると書かれてるな
つまりRust＆Pythonの開発者たちの本流だ

>>626
企業がサポートをお願いしたい時の筆頭候補になる

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

いつの価値観で断罪したいのか知らんけど、どうせ現在の価値観ではOKだろ

**デフォルトの名無しさん** · 2025/04/23(水) 23:23:47.07

>>624
GitHubでOSSとして公開されてたものが後に有償化するのは普通にあるぞ
C#のPrismとか、PythonのPySimpleGUIとかがその例

**デフォルトの名無しさん** · 2025/04/23(水) 23:33:07.28

PythonのRuffとuvのAstralはサイトのトップページにオープンを理念とすると掲げているとともに信頼があり多くの有能開発者たちが協力しているプロジェクト

**デフォルトの名無しさん** · 2025/04/24(木) 01:17:00.64

Don’t be evilとか言ってた企業が世界一evilな企業になるみたいな話だね

**デフォルトの名無しさん** · 2025/04/24(木) 01:49:00.09

anacondaがやばすぎて疑心暗鬼になってる人たち
俺も一員

**デフォルトの名無しさん** · 2025/04/24(木) 02:13:25.73

企業としてマネタイズする場合、ソフト自体を有償化する (無償版と並列に運用する体制) パターンと付随するサービスのほうで稼ぐパターンとその会わせ技のパターンがある。
uv はパッケージマネージャなわけだからエンタープライズ向けに精査されたパッケージリポジトリの提供とかで商売になるんじやないかなぁ。

**デフォルトの名無しさん** · 2025/04/24(木) 02:51:42.67

OS依存をおそれないC/C++はコンパイラもライブラリもOSで管理するから問題ない
自称OS非依存の方がかえって邪悪になるってことかな

**デフォルトの名無しさん** · 2025/04/24(木) 03:01:04.69

OS というかディストリビューションのパッケージマネージャに乗っかるのが C/C++ の伝統ではあるな。
ただ、本来は実行環境の管理に使うべきシステムだから開発環境の管理に使うのは微妙に行き届かない面もあり、事情がややこしくなる部分もある。

**デフォルトの名無しさん** · 2025/04/24(木) 08:59:09.87

>>630
Astralが信頼できるかどうかは関係ない
VCから貰った金が底を尽きたら会社は即潰れるし、貰った金はいずれ100倍にして返すよう常に期限付きでプレッシャーをかけられる
そして見通しが厳しくなれば最終的にVCは事業の持続的成長を放棄した強引な方法で回収にかかる
dockerやanacondaがいい例だ
これは善い悪いという話ではなくスタートアップ企業の構造上の宿命なの

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

この手のスタートアップは最終的に大手に買われるのがゴールとなるのが一般的だ。
企業の信頼性というのは理念ではなく企業体力 (資本力) で測られる。
個人ユーザ程度の些細なところでマネタイズしなくて良いくらいに資本がある会社が運用してくれるのがユーザとしては安心できるシナリオと言える。

オープンソースの一大拠点である Github だってマイクロソフト傘下なんだぞ。

**デフォルトの名無しさん** · 2025/04/24(木) 13:31:41.47

LibreOfficeのスレかと思った

**デフォルトの名無しさん** · 2025/04/24(木) 14:34:38.61

MSになってgithubから脱出したOSSもあるけどな

**デフォルトの名無しさん** · 2025/04/24(木) 17:58:43.83

>>632
その件があったからuvとRuffのAstralはオープンを方針として明記していて
https://astral.sh/about
オープンさを大切にしてオープンソースで寛容なライセンスを信念として掲げている
だから開発コミュニティに協力してくれる人たちが集まってる

**デフォルトの名無しさん** · 2025/04/24(木) 18:41:31.45

理念がどうあれ、事実としてVCから出資を受けてしまっている以上、必ずVCは利益を目的として意思決定に介入する
もし高尚な理念を本当にこの先守っていきたいなら、VCへの株式譲渡などせず財団方式で運営すべきだった
君の信心に対してとやかく言う筋合いはないが、君が信じているのは果たして誰なのか？は考えてみたほうがいいよ

**デフォルトの名無しさん** · 2025/04/24(木) 20:59:08.21

理念が期待通りに機能しないのは人間が悪いんだよ
理念が撃つのではない人が撃つのだ

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

人間を襲ったクマを駆除するのか生け捕りにして山に還すのかどっちが正しいんか

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

Astralって今はカネとってる商品一つもないの？

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

>>643
そういうのを最もくよくよと考えてるのが中立
中立ではない人はわりと判断が早いよね

**デフォルトの名無しさん** · 2025/04/25(金) 19:05:53.27

中立でなくて中庸では？

**デフォルトの名無しさん** · 2025/04/25(金) 20:10:42.17

>>643
検討の余地はない

**デフォルトの名無しさん** · 2025/04/25(金) 20:50:10.25

目の前に6億積まれてこの金で開発に集中していいよと言われたら断れないよね
創業者はSentryのシンパらしいからそのうちクラウドサービスでマネタイズを試みるんじゃないかな
ビッグテックが欲しがるのは基本的にプラットフォームであり、コードそのものにはあまり価値を認めないから、まずはクラウドを成功されられるか次第だろうな