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/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のシンパらしいからそのうちクラウドサービスでマネタイズを試みるんじゃないかな
ビッグテックが欲しがるのは基本的にプラットフォームであり、コードそのものにはあまり価値を認めないから、まずはクラウドを成功されられるか次第だろうな

**デフォルトの名無しさん** · 2025/04/25(金) 23:36:31.47

なるほど、合法な6億も違法な6億も、返せ返せと言われる点ではどっちもどっちだ

**デフォルトの名無しさん** · 2025/04/25(金) 23:39:57.43

Python方面でも最近の良いものは全てRust製なんだね

**デフォルトの名無しさん** · 2025/04/26(土) 00:28:58.67

uv以外ある?

**デフォルトの名無しさん** · 2025/04/26(土) 00:29:47.79

polarsだっけpandas的なやつ

**デフォルトの名無しさん** · 2025/04/26(土) 00:38:28.74

qiskitのrustが進んでる

**デフォルトの名無しさん** · 2025/04/26(土) 00:38:45.64

qiskitのrust化が進んでる

**デフォルトの名無しさん** · 2025/04/26(土) 00:48:53.01

量子コンピュティングか。何も分からん

**デフォルトの名無しさん** · 2025/04/26(土) 08:40:09.93

Python以外、例えばRubyのライブラリをRustで書くといった動きってあるの？

**デフォルトの名無しさん** · 2025/04/26(土) 08:49:32.69

RubyだとJITコンパイラ（YJIT）がRustで書かれてるね

**デフォルトの名無しさん** · 2025/04/26(土) 09:38:41.16

完全にグルー言語と割り切って使われているPythonと違って、Rubyって未だに絶頂期の変なプライドを引きずってる人が多いからRustの採用は広まらなそう
yjitみたいに元々Cで書かれている部分を置き換える分には抵抗がないだろうけども

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

rubyってmatzがcかc++で書いてたんでしょ？今のところ書き換える意味はないよ
仮に替えるとしてコンパイラを書き換える理由はなんだ？
rustで書いてみたかったとか

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

yjitはMRIと比較して普通に速い
もちろんRustだから速いのではなく、元々の実装がヘボいだけ

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

ゆるゆるRubyをRustで描き治すなんて発狂しそう

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

Pythonにしても元々Cで書かれていたライブラリのコア実装をRustに切り替えてるだけで、PythonからRustになったりはあまりしてないと思うが…
Rubyの場合pure Rubyなライブラリが多くてRustにできる余地が少ないイメージだけど実際どうなんだろうね

**デフォルトの名無しさん** · 2025/04/26(土) 11:35:09.77

理念をどうこう言っても理念通りにいかないのも普通のこと。
現実はトレードオフの連続で、微妙な判断の連続を繰り返したら汚くもなってくる。
「綺麗なのは使われてないものだけ」という格言もある。
不恰好なのは現実の道具として使われてきた証とも言える。

ただ、現実の事情は変わっていくからね。
昔の現実に合わせたものが今の事情にマッチしなくなっていく。
プログラミング言語だってたまには新しいものが現れて過去をリセットしつつまた汚く (しかし現実に都合よく) なっていくんだろう。

**デフォルトの名無しさん** · 2025/04/26(土) 11:35:21.29

改善点無しで書き換えるのはやらん方が良い

**デフォルトの名無しさん** · 2025/04/26(土) 11:37:10.07

多神教、二元論はピュアじゃないとか、データさえあればプログラミングは不要とかいう一元論は今でも絶頂期

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

実際、業務システムならDBが全て
ドメイン駆動とかほざくアホは無視し、Postgres上で徹底的に業務ルールを定義するのが最善

**デフォルトの名無しさん** · 2025/04/26(土) 13:13:44.82

結局Rustはなにならできるの？

**デフォルトの名無しさん** · 2025/04/26(土) 13:33:53.91

全部出来るでしょ。ただC並みに細かくなるので、業務アプリレベルのものは、GC付き業務フレームワークのPythonやrubyでいいよ

**デフォルトの名無しさん** · 2025/04/26(土) 13:34:17.50

アプリ用DSLか

**デフォルトの名無しさん** · 2025/04/26(土) 13:44:16.81

>>667
Rubyを高速に動かすために不可欠なYJITがRust製

**デフォルトの名無しさん** · 2025/04/26(土) 14:26:52.65

>>667
主に、有効であることが既に確認されている既存のソリューションの高速化に用いられる。
新規性の高い未確立なソリューションの開発に用いられることは少ない。
Rustは信頼性とパフォーマスに優れている一方で、柔軟性が乏しいため試行錯誤の必要な開発には向かないと思われているのだろう。
もちろん異論はあるだろうが、実態としてな。

**デフォルトの名無しさん** · 2025/04/26(土) 14:42:28.20

>>671
それは真逆だ
Rustでの開発は柔軟性が高いため
新たな設計による機能強化や高速化などにRustが用いられている
一方で単なる既存の書き換えだけではどの言語間でも効果は限られる
スクリプト言語からRustへ移植する場合でも少なくとも中核部分はそのままよりも設計し直した方がより高速化と省メモリに繋がる

**デフォルトの名無しさん** · 2025/04/26(土) 14:59:40.76

CとGC言語両方経験者ならすぐ分かるような質問多いね
精進頑張って

**デフォルトの名無しさん** · 2025/04/26(土) 15:12:31.71

全レスにそれってあなたの感想ですよねって返されても何も言えない

図書館言ったらプログラム書籍のコーナーが1つ棚が減っていてその分AI等の書籍の棚が出来ていた
どこにこんなに本があったのかと
ゴミみたいなRust入門書とPython入門書などが書庫行きになってた

**デフォルトの名無しさん** · 2025/04/26(土) 15:37:01.99

個人の感想とか個人の試行錯誤は良いぞ
全体主義的な試行錯誤はダメだ

**デフォルトの名無しさん** · 2025/04/26(土) 15:58:41.44

>>674
>プログラム書籍のコーナーが1つ棚が減っていて

PearlとかRubyとかPHPとかJavaとか減っていけ

**デフォルトの名無しさん** · 2025/04/26(土) 16:18:14.26

>>671
新規性が高いというのはユーザを抱えていないということでしょ。
結果的に観測されにくいってだけじゃね？

**デフォルトの名無しさん** · 2025/04/26(土) 16:27:16.63

ソースが短い内容なのに実行時ランタイムが必要な奴を置き換えてる

**デフォルトの名無しさん** · 2025/04/26(土) 17:16:17.24

観測が任務だったのにろくに観測しない
1話でやったやつを見てない
0話切り

**デフォルトの名無しさん** · 2025/04/26(土) 17:41:13.28

>>675
塞翁が馬でどうなるかわからないな
俺が抑圧されたら反抗するが

**デフォルトの名無しさん** · 2025/04/26(土) 17:51:31.23

コード書きなよ。そして考える。読んで考える

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

>>678
これは割と効いてくるので良い方針だと思う。
いまどきは Ruby でも JavaScript でも JIT でかなり高速化してるんだけど、 JIT だと何度も通過する内にだんだんネイティブコードに置き換わっていく仕組みだからガッと動いてすぐ終わるようなコードだとぜんぜん JIT の恩恵がない。
それでいてそこそこ大きいランタイムのロードには時間がかかるからあまり向いてないんだよね。

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

>>672
そんなもん完成形は目の前にあるんだから、頻繁に大規模な手戻りが発生するようなら設計した奴が無能なだけ
スタートアップなんかでのガチで新規性の高い開発ってのは、そもそも作っているものに価値が無い可能性が高い
そのような性質の開発にRustは適していると思う？
俺自身の意見はともかく、現状その問いにYesと言えるだけの実績がRustに無いのは事実だ

**デフォルトの名無しさん** · 2025/04/26(土) 18:06:58.12

WebブラウザWasm、CDN Edge、クラウドなどもRustが言語筆頭候補の領域

**デフォルトの名無しさん** · 2025/04/26(土) 18:21:45.82

rustから他の言語に書き直すのは大変そう

**デフォルトの名無しさん** · 2025/04/26(土) 18:50:24.41

>>658
RubyのYJITはC言語で書かれていたMJITを単にRustへ移植したのではなくて全く別のアプローチ
YJITを作ったShopifyの研究開発チームがYJITの論文も発表しているよ

>>683
スタートアップが新規に開発でRustなら既に話題になってるPythonのruffやuvも該当するね

**デフォルトの名無しさん** · 2025/04/26(土) 19:24:47.94

YJITやuvやruffが新規なのか
別に煽るつもりも否定するつもりもないのだけど、平均的なRust開発者の認識がそうなんだとしたら、Rustは実際にそういう言語なんだろうね

**デフォルトの名無しさん** · 2025/04/26(土) 19:37:07.61

276,406行のC++コードを捨ててRustへ移行したスタートアップの技術的決断
https://zenn.dev/rwcolinpeng/articles/14760991836800

**デフォルトの名無しさん** · 2025/04/26(土) 19:40:30.88

Cからrustへの書き換えはわりとうまく行きそうだけどC++からだとしんどそう

**デフォルトの名無しさん** · 2025/04/26(土) 19:49:20.55

スタートアップでも開発効率の高いRustを採用する方が当然有利ってことだな

**デフォルトの名無しさん** · 2025/04/26(土) 21:18:45.78

試行錯誤ってカーゴカルトを正当化するんだな
滑走路作ってみな
飛ぶぞ

**デフォルトの名無しさん** · 2025/04/26(土) 21:47:38.26

別の視点でスタートアップであろうとなかろうと
競合相手がいて他の条件がほぼ同等ならRustを採用した方がおそらく有利っぽい
速度の面でも使用リソースの面でも

**デフォルトの名無しさん** · 2025/04/26(土) 22:16:38.86

開発者が優秀だからじゃないか
同じ人が開発する時の速度に影響するかなあ

**デフォルトの名無しさん** · 2025/04/26(土) 22:43:45.38

kindle 日替わり500円

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

Cのままだとライセンス違反になりそうなグレーゾーンをRustで書き換えて解決ってか

**デフォルトの名無しさん** · 2025/04/26(土) 23:13:16.03

言語を書き換えてもライセンス抵触なら無意味
それ以前にいまどき落とし穴の未定義動作だらけにC言語なんて使うのはコンパイラ指定な特殊な組み込み環境くらいだろ

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

>>689
その通りなんだがC++の機能にどの程度依存してたかだな

**デフォルトの名無しさん** · 2025/04/26(土) 23:40:40.79

>>695
freebsdカーネルは完全にgcc捨ててllvm化が終わってる

**デフォルトの名無しさん** · 2025/04/27(日) 05:42:31.77

>>688
C++エキスパートなら、必要なスキルが揃っているから移行コストが少ない、というのがデカイね。

逆にC++で大規模開発するのにコーティング規約を決めてなかったみたいだから、コーダーが好きにやって破綻している感じもある。
C++標準化委員会は標準的なコーティング規約を決めた方がいいんだろうけど、宗教戦争になりかねないから難しいか。

**デフォルトの名無しさん** · 2025/04/27(日) 06:03:34.96

C++を完全に捨てるしかなかったな

>>688
>>C++ はプログラマーに多くの柔軟性を与えますが、それには代償が伴います。バグを埋め込むのが非常に簡単であり、その多くは非常に厄介です。しかし、それ以上に C++ プログラムのデバッグは非常に困難です。特に並行プログラミングにおいてはなおさらです。

>>依存関係の管理が面倒です。たとえば CMake のように、C++ プロジェクトのコンパイルを自動構成するツールはありますが、開発者は依存ライブラリの構成やインストールを手動で行う必要があります。

>>標準テンプレートライブラリ（STL）は、たとえばネイティブなコルーチンのサポートなど、モダンプログラミングの一部ツールに対応していません。その結果、開発者は多くのコミュニティプロジェクトに依存せざるを得ず、これらの多くは長期的なサポートがありません。

>>品質保証が難しいです。C++ は非常に多機能な言語であるがゆえに、開発者ごとにまったく異なるコーディングスタイルで C++ を書いてしまう傾向があります。異なるバックグラウンドを持つ開発者がチームに増えると、コードの可読性を維持できなくなりました。さらに、C++ コードのバグは簡単には特定できず、コードレビューが非常に困難になる原因でもありました。

**デフォルトの名無しさん** · 2025/04/27(日) 06:08:20.98

>>688
C++エキスパートかどうかは何も痕跡がないな
むしろJava屋さんじゃね(Initial commit)
https://github.com/risingwavelabs/risingwave/tree/cb527ae81e9d9f51010da4b16ad9101447b7670b

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

>>688
こういう極端な例しか出て来ないよね

**デフォルトの名無しさん** · 2025/04/27(日) 06:23:06.49

>>688
今となっては何もかも劣るC++を使うメリット無いからな
ましてやそのような最近のシステムなら非同期並列が必須なのでC++だと茨の道

**デフォルトの名無しさん** · 2025/04/27(日) 07:51:33.32

libuvを使うのじゃ
全くおすすめできない

**デフォルトの名無しさん** · 2025/04/27(日) 07:52:41.59

非同期並列並行が標準装備なんて恵まれた言語ばかりになってグスン

**デフォルトの名無しさん** · 2025/04/27(日) 08:04:58.94

設計の見直しがあるとRustは辛いよなぁ
Goのほうが柔軟な気がする

**デフォルトの名無しさん** · 2025/04/27(日) 09:24:24.45

Kotlin もよろしく

**デフォルトの名無しさん** · 2025/04/27(日) 09:26:48.67

Oracle怖いので

**デフォルトの名無しさん** · 2025/04/27(日) 10:46:11.91

> 開発者は多くのコミュニティプロジェクトに依存せざるを得ず、これらの多くは長期的なサポートがありません。

これを理由にしてRustへ行くのはちょっと本末転倒感あるけどなあ
数年後には、古くなったcrateに縛られてモダンでクールな〇〇をイントロデュースするのベリーハードだぜフ〇ックとかブツブツ言ってるだろうな

**デフォルトの名無しさん** · 2025/04/27(日) 10:48:58.05

処理系のサポートは重要だよね
IntelのCコンパイラ使ってるプロジェクトあったな
最適化の都合かもしれんけど

**デフォルトの名無しさん** · 2025/04/27(日) 11:29:27.41

新しいものの方が魅力的に映るのは当然のことだが、当面の最大のリスクはRustより魅力的な言語が出現したときにどうなるか、だな
>>688の例でも必死に言い繕っているように、新しいものを使いたかっただけではなく真の合理的判断の結果であれば問題にならないはずだが、果たして本当にそうだったのかはそのときに明らかになる
Rustがいかに優れていようと、その時はいずれ必ず来るわけだが、Rustエコシステムは未だそれを経験していない

**デフォルトの名無しさん** · 2025/04/27(日) 11:31:45.33

それを言ったら、CもJavaも出だしの頃は散々使えないって言われてたので。自己責任で腹を据えるしか無い

**デフォルトの名無しさん** · 2025/04/27(日) 11:33:37.49

zigは難しいし、まあRustの20年が始まるよ。

**デフォルトの名無しさん** · 2025/04/27(日) 12:18:30.81

RustのようにCと同等の速さを出すことが可能で
Rustよりも安全な言語は当面出現しそうにない
C言語からRust出現まで43年間かかった
そしてC出現から53年たった現在もCも使われているように
50年後もRustは使われているだろう

**デフォルトの名無しさん** · 2025/04/27(日) 12:39:43.81

実現したとしてもRustと同程度の2番煎じじゃ意味ないのよね
Rustでは出来ない問題を解決しなきゃ

**デフォルトの名無しさん** · 2025/04/27(日) 13:04:11.13

＞　Rustでは出来ない問題

未知の新言語に誰にでも使える容易さがあればRustは消えることになる

**デフォルトの名無しさん** · 2025/04/27(日) 13:16:54.38

50年後かな