結局C++とRustってどっちが良いの？ 4traits

**デフォルトの名無しさん** · 2023/06/06(火) 19:13:06.15

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 3traits
https://mevius.5ch.net/test/read.cgi/tech/1683154196/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/06/25(日) 23:07:06.21

>>727
>デザイン
coarray fortranってのがあるけど手書きMPIの方が性能は上らしい

**デフォルトの名無しさん** · 2023/06/25(日) 23:11:24.96

>>730
通信の方式とかかなりチューニングされてるからね
伊達に何十年も存在してない

**デフォルトの名無しさん** · 2023/06/25(日) 23:12:11.63

>>726
まあ、単純に自分が主体のクレートを開発したいというのと、ndarrayだと、型指定が多くてpythonライクな感じにならないから。ということで設計思想がndarrayの中の人たちとは少し違う。

**デフォルトの名無しさん** · 2023/06/25(日) 23:23:38.08

>>731
だね

>>732
なるほどね
>単純に自分が主体のクレートを開発したい
ver0.2.0で止まったりするとけっこう黄色信号で、せっかく技術力を誇示してもコミュ力評価が落ちるから
逆にコントリビューターが来るくらい頑張ってね

**デフォルトの名無しさん** · 2023/06/25(日) 23:34:38.25

>>683
ただ、ndarrayベースだとnumpyの様にas_typeとかreshapeを実装しにくい。self.reshape(shape)って感じにしにくい。APIは出来るだけnumpyに寄せたいのでそこら辺は少し困ってる。後、pythonでnumpyのfor文を回したときとの時間はまだ倍程度にしかなってない。自分で一から実装するべきかもしれない。

**デフォルトの名無しさん** · 2023/06/25(日) 23:36:37.70

>>734
倍速いってことねrustで開発中のクレートの方が。

**デフォルトの名無しさん** · 2023/06/25(日) 23:50:29.91

>>734
numbaでnjitした時との比較かどうかを明記した方が良い

**デフォルトの名無しさん** · 2023/06/25(日) 23:59:18.24

>>734,735
あとnumbaはparallel=Trueで簡単に並列処理が出来るから、速度優位を主張する時は
numba @njitは大前提で、parallel有り無し、自分のクレート(parallel有り無し)のデータを出さないと
見向きもされない

**Ndarray** · 2023/06/26(月) 00:46:15.23

タスクによるけどrayon使うと爆速になるものもあるな。1000倍以上早くなったタスクがあったのは驚いた。

**Ndarray** · 2023/06/26(月) 00:58:10.58

>>738
これ、勘違いだった。

**デフォルトの名無しさん** · 2023/06/26(月) 02:54:14.98

AVX512(zmm レジスタやEVEX)を使った高速化は、時代錯誤と言われる様になるぞ。
最新のCPUでは事実上使えなくなるらしいから。
命令表の表だけの行数(rowの個数)だけでも3500にも及ぶ複雑な体系を
沢山勉強しても、結局無駄になった。

**デフォルトの名無しさん** · 2023/06/26(月) 03:04:47.51

2020/04 にAMDがAVX512対応を表明して、実際に対応したと
思ったら、2022/03くらいで、IntelがAVX512を廃止する以降を
発表したとか。
そうやって競合企業を混乱させて弱体化させようとしている。
経営学における「陽動作戦」に近い。

**デフォルトの名無しさん** · 2023/06/26(月) 03:10:21.41

要素数を即値などで指定できずに、命令自体を買えてしまうので、
Intel準正のC/C++コンパイラ以外では、CPUが出てから対応に
時間が掛かる。ベクトル型スパコンでは、要素数を即値などで
指定できていたらしいのと対照的。
つまり、Intelが自分だけが優位に立てる作戦になっている。
命令のニモニックを分かりにくくすると同時に命令の個数や
オペランドの組み合わせをやたらと増やし、アセンブラ表記も
アセンブラの修正を必要とするようなものにしてしまうことで、
Intel純正開発環境以外では、対応に時間が掛かるようにしてある。
複雑すぎて人間の頭にはInputすることすら大変になり、全貌を把握する
のに膨大な時間が掛かる。複雑すぎて、サードパーティーのアセンブラや
コンパイラがバグ無く動作するのは難しい。コンパイラ作者の勘違い
があれば、バグになるから。

**デフォルトの名無しさん** · 2023/06/26(月) 03:13:27.69

Intel CPUの特徴は、アセンブラのニモニックが異常に分かりにくく、
Intel C/C++ コンパイラの intrinsic(組み込み関数)の表記は
少し分かり易い。
それで、純正コンパイラに誘導する作戦なんだろう。
アセンブラのニモニックも分かり易くしようと思えば出来たはず
なのに、高価なC/C++コンパイラを買わせるために、わざと
アセンブラを難しくした。
経営的には、参入障壁を上げ、模倣をしにくくし、自社だけに
有利なようにする戦略と考えられる。

**デフォルトの名無しさん** · 2023/06/26(月) 03:59:18.29

iclっていつのまにか無料だぞ(サポートが有償)

まあIntelほどの巨人でも、生き残りは大事だからな
我田引水は程度問題

**デフォルトの名無しさん** · 2023/06/26(月) 07:18:24.97

Linux のプロセス管理メモリ管理はピンピンコロリ作戦

**デフォルトの名無しさん** · 2023/06/26(月) 08:03:04.93

>要素数を即値などで指定できずに、命令自体を買えてしまうので、

>命令のニモニックを分かりにくくすると同時に命令の個数や
>オペランドの組み合わせをやたらと増やし

インテルはいってるは命令の一部に即値が入ってるアーキテクチャーが好きなだけ
つまりオペコード＝「オペコード＋オペランド」であって
「オペコード＋オペランド」であることには変わりない

**デフォルトの名無しさん** · 2023/06/26(月) 08:32:14.95

インテルどこ言ったんだよと思ったのはここだけの秘密です

**デフォルトの名無しさん** · 2023/06/26(月) 12:47:27.83

tokioとrayonの機能の違いを教えて！

**デフォルトの名無しさん** · 2023/06/26(月) 13:50:58.77

ここでは教えたがりの無能からしか回答が来ないので自分で調べることをおすすめします

**デフォルトの名無しさん** · 2023/06/26(月) 14:06:01.49

rayonは並列スケジューラ
tokioは並行並列スケジューラ
どちらもワークスティーリング方式でジョブ/タスクを効率よくスレッドに割り当てて並列処理してくれる点では同じ
しかしファイルやネットの読み書きなどで待ち時間が発生する場合に
スレッドからそのタスクを一旦外して他のタスクを割り当てる並行処理も行なうほうが効率がよい

**デフォルトの名無しさん** · 2023/06/26(月) 14:44:21.67

>>720
Rustのndarrayにはrayonベースで非同期ライブラリが組み込まれてるっぽいけど。

**デフォルトの名無しさん** · 2023/06/26(月) 15:40:30.64

常に同期して進めるわけでなければ非同期なので、非同期の並列は普通に起こり得て、非同期はそれ単体ではその観点で大した意味はないね
意味を持つのは非同期での並行、例えば一番わかりやすいのはシングルスレッドで非同期で並行して動作するJavaScriptかな
内部実装的には効率のためI/Oでマルチスレッドを使う実装もあるけど、シングルスレッドでも非同期に並行処理の実装が可能
各プログラミング言語のうちシングルスレッドでも並行に動作するpromiss/futureを持つ場合がこれに該当し、シングルスレッドでもasync/awaitで動作できるなら非同期な並行で動作してる
一方でJavaScriptはシングルスレッド内でしかasync/awaitの並行処理ができないけど、tokioなどはマルチスレッドで並行並列処理ができる
rayonはこの非同期な並行はできない

**デフォルトの名無しさん** · 2023/06/26(月) 16:07:13.82

>>751
マジ？
俺のアイデアパクられたかと思ったがあくまでプラグイン的な感じみたいね
俺のアイデアは非同期パイプラインベースの上で数値計算を行うこと
これができるのはtokioのみ

**デフォルトの名無しさん** · 2023/06/26(月) 16:18:30.02

何度も言うがなぜ非同期パイプラインを使うのかというと複数ノードで計算できることを想定に入れているから
その時点で俺のアイデアがずば抜けてることがわかると思う

**デフォルトの名無しさん** · 2023/06/26(月) 16:38:46.43

rayonっての知らなかったから調べてみたけど
やはり複数ノードは絶望的だな
しかしメソッドチェーンで数値計算を行うという俺のアイデアとかなり似たことはできるっぽくセンスの良さは感じる

**デフォルトの名無しさん** · 2023/06/26(月) 16:53:45.74

Vector SIB(VSIB)が良く分からない。
* vm32{x,y,z}
index レジスタが、xmm, ymm, zmm の中に 32BIT の個々の要素として入る。
* vm64{x,y,z}
index レジスタが、xmm, ymm, zmm の中に 64BIT の個々の要素として入る。
というところまでは分かったと思う。

[base + index * scale + disp]
で base は、GPR(RAX,RBXなど)、index が、xmm/ymm/zmm になっている。
float32 に対する vm32x の場合は、EA(Effective Address)が、
EA = base + xmm[i*4] * scale + disp
(i = 0,1,2,...,3/7)
の様になる感じ。
但し、xmm[i] で xmm の iバイト目から始まる DWORD みたいな意味になる。
でも、

Table 2-13. 32-Bit VSIB Addressing Forms of the SIB Byte
の
Note
1. If ModR/M.mod = 00b, the base address is zero, then effective address is computed as [scaled vector index] + disp32. Otherwise the
base address is computed as [EBP/R13]+ disp, the displacement is either 8 bit or 32 bit depending on the value of ModR/M.mod:
MOD Effective Address
00b [Scaled Vector Register] + Disp32
01b [Scaled Vector Register] + Disp8 + [EBP/R13]
10b [Scaled Vector Register] + Disp32 + [EBP/R13]

の部分の意味が分からない。

**デフォルトの名無しさん** · 2023/06/26(月) 17:06:57.57

>>756
分かって来た。
これは、base が 2進数で 101 の場合の話で、注意が
必要な場合に言及していたんだ。
特に難しいことは無いようだ。
もともと 32BIT の x86 で、SIB が無い ModRB で [d32]
だった箇所が、AMD64で、[RIP+d32]に変更になったので、
混乱を招き易いので注意書きを書いているだけらしい。
但し、SIB が有る場合の、mod=00、base=101 の場合の該当箇所は、
x86でもx64でも、[d32 + sclae * index] の意味になっていて、
特に混乱が無い。
SIBが有る場合は、mod != 00 の場合でも、x86、x64 で特に違いが
見られない。
だから、この注意書きは、もともとそんなに注意を必要とする部分
ではないと思う。逆に注意書きを書くことで混乱を招きそうな
気もする。

**デフォルトの名無しさん** · 2023/06/26(月) 18:11:27.20

いったい何のスレで何を見せられているのだろうか？

**デフォルトの名無しさん** · 2023/06/26(月) 19:15:53.61

いったい隔離スレに何を求めているのだろうか？

**デフォルトの名無しさん** · 2023/06/26(月) 21:51:11.03

スレに合った話をするか。
CやC++よりもRustの方が優れてる。
1)RustはCやC++と比べてセキュリティ的に圧倒的に勝ってる。
2)rust anslyzerはかなり優秀。
3)非同期処理や並列処理周りのライブラリが優れている。
4)CやC++みたいにコンパイラが乱立してない。

**デフォルトの名無しさん** · 2023/06/26(月) 22:02:08.35

4は「乱立」って言葉使って誤魔化してるが欠点だろーが?w

**デフォルトの名無しさん** · 2023/06/26(月) 22:14:55.18

予めネガティブな言葉を使うことによりさもそれが悪いことかのように見せかける詭弁のテクニックだな
「C/C++はコンパイラが複数ある。Rustは一つしかない」だとネガキャンには弱い
だからここぞとばかりに貶めるネガティブな言葉を使ったワケだ。
これが宗教戦争の端緒だよ
これに「○○言語を使ってる人間は劣っている」とかの人格批判まで加われば立派な宗教だ

**デフォルトの名無しさん** · 2023/06/26(月) 22:15:59.04

ところでC++にはtokioやrayonにそれぞれ相当するものがないのですか？

**デフォルトの名無しさん** · 2023/06/26(月) 22:20:21.85

あるのかないのかは知らない
ないのかもしれないけど大規模なプロジェクトでC++は使われているだろう

**デフォルトの名無しさん** · 2023/06/26(月) 22:37:03.61

>>763
C++ならtbbかな
あと非同期イベントループ使いたいならlibuv
しかしそれらを組み合わせることは不可能
tokioの素晴らしさは自分たちで非同期の仕組み自体を作れるところ

**デフォルトの名無しさん** · 2023/06/26(月) 23:19:03.58

>>765
それらはレベルが低すぎて対応するものではない
libuvはLinuxでいうところのepollシステムコールのイベントループにタイマとウォッチャの毛が生えた程度のライブラリ
使い勝手はコールバックを駆使する昔の不便な時代なもの
そしてスレッドセーフでないためシングルスレッド用
Rust tokioやGoのような高機能で使い勝手の良いものはC++に存在しない

**デフォルトの名無しさん** · 2023/06/27(火) 01:24:43.67

Rustって型を抽象的にしてもあまり実行時間に変化がない？ゼロコスト抽象化と言ってるけど。

**デフォルトの名無しさん** · 2023/06/27(火) 01:51:51.98

なにいってんだおめ

**デフォルトの名無しさん** · 2023/06/27(火) 03:21:29.26

>>762
こういうものには、カルト構造が有り、
本当に「信者」という言葉がふさわしいと言われている。

**デフォルトの名無しさん** · 2023/06/27(火) 03:37:30.86

AVX512 は、非推奨(deprecated)で、第12世代 Core i
シリーズの Alder Lake からは、デフォルトで disableになる
とのこと。重い処理用に用意されている P コアではまだ使えるが、
低消費電力の E コアでは、AVX512 が使えない。
どちらが使われるかは OS が切り替えて、どちらになるかは
アプリが決められない(?)ので、AVX512 が使えない、みたいな
話らしい。知らんけど。
こうなった根本原因は、AVX512にはそもそも熱狂的人気が無かったから
なんだそうだ。SIMD命令だけが速くなるだけで、数値計算プログラム
においてすら、全体的には数%しか速くならないのに、電力消費は
25%位も多くなる、という困った事になっていたそうだ。
SIMD命令はプログラムの自由度が低過ぎるし、お膳だてのための
オーバーヘッドがかなり掛かってしまう。
そもそも、今や、乗算、除算ですらかなり速く計算で来てしまうので
SIMDにするメリットより、デメリットの方が多くなってきつつある。
なでなら、SIMDにするためには、離れた要素をmergeしたり、
maskパターンを用意したりする必要があるが、それに時間が
掛かってしまう。いまや乗算なんて、10クロックくらいしか掛からない
のに、maskパターンを用意するのにそれよりも多く掛かってしまう可能性
があるので、SIMD命令を使ってもトータルではほとんど速くならない
ことが多くなってきている。
さらに、加算(add)や減算(sub)なんて、もともと1クロックで
実行できてしまうし、本質的に並列化できる場合には、
1クロックで4命令程度は同時実行されることがある。
だから、SIMD命令を使わなくてもループ命令を
展開するだけで、勝手に同時実行される場合がある。
だから、SIMD命令の高価がほとんど無い事が多くなってきている。

それに対して、マルチコアによる同時並列実行は、とても上手くいく。

**デフォルトの名無しさん** · 2023/06/27(火) 03:45:53.40

わかったから
使うほうが早いのだから使うんだよ
わからんやつだな

**デフォルトの名無しさん** · 2023/06/27(火) 03:58:12.99

>>771
特殊ケース以外は、微妙に速いだけだろう。

**デフォルトの名無しさん** · 2023/06/27(火) 03:59:31.74

どうせ、研究目的とかで、非常に非現実的な
例で実験して速くなった、とか言っているに一票。

**デフォルトの名無しさん** · 2023/06/27(火) 04:00:43.55

そんなに速くなるんなら、廃止する理由が無い。
便利でも無いし、単純なマルチコア実行に比べれば、
遅いし。

**デフォルトの名無しさん** · 2023/06/27(火) 04:04:45.59

マルチコア実装が理想的な動作をしないから仕方がない
手元のコードを通してしか動作を見れないのだから仕方がない

**デフォルトの名無しさん** · 2023/06/27(火) 04:05:34.80

もちろんマルチコア「も」使うんだよ
さらにプラスアルファで搾り取る
そのためのSIMD

**デフォルトの名無しさん** · 2023/06/27(火) 04:09:08.60

そもそもデータって、色んな場所に散らばっている。
しかし、SIMD命令で演算するためには、それらを
1つの場所に集めてくるか、VSIBを使わなければならない。
しかし、それが効率よく出来ない。
マルチコアでやれば、そのような手間が無いため、単純に
速度がコア数分だけ倍増するが、SIMDだとそうはいかない。
SIMDで高速化できるのは、数値計算に限定しても、
気象シミュレータの様に場合分けが少なめで単純な
メッシュで計算自体は場合分けが無くて同じ事の単純な
繰り返しになっている場合に限られる。
レイトレーシング、剛体力学計算、パーティクル計算、
量子シミュレータなどは、同じ事の繰り返しにはしにくい
ので SIMD で高速化するのは難しい。
一方、マルチコアで高速化するのはSIMDに比べれば
簡単である場合が多い。

**デフォルトの名無しさん** · 2023/06/27(火) 04:10:31.41

あとAVXは廃止されてないぞ
Xeonでは普通に使えるし
コンシューマー用の製品でもAVXを復活させるらしい
なぜならAMDが対応したから
AVX大戦国時代に突入が確定
普通のコア側の性能が完全に頭打ちなのだから
これまであまり活用されてなかったAVXなどのSIMDが今まで以上に大事だ

**デフォルトの名無しさん** · 2023/06/27(火) 04:10:37.14

>>776
SIMDでは微妙に高速化されるだけだろう。
マルチコアするための「スペース」が減ってしまう。

**デフォルトの名無しさん** · 2023/06/27(火) 04:15:00.63

やはりこれから数値計算にはAVXは当たり前のようになりそうだな
mojoというプログラミング言語もSIMD構造体を使えるし
juliaでもSIMDモジュールがある
ライブラリ作者が勝手に最適化するのはもはや義務となりそう

**デフォルトの名無しさん** · 2023/06/27(火) 04:16:41.02

そういう意味ではrustのstd::simdなどが標準モジュールに入ってきたのもこの流れを受けてのことだろう
rustのコア開発者は流行りに敏感だ

**デフォルトの名無しさん** · 2023/06/27(火) 04:24:09.85

これを読め

Intelが将来登場するCPUで再びAVX-512に対応する模様。AMDに対抗するため。
https://gazlog.com/entry/intel-avx512-rebirth/

**デフォルトの名無しさん** · 2023/06/27(火) 04:26:37.65

とはいえ並列数が少なすぎるというのは同意
GPUの数万スレッドと比べるとあまりにも差がある

**デフォルトの名無しさん** · 2023/06/27(火) 05:30:53.79

なんかの避難スレみたいになってるようだけど、自由にしゃべっててくれ
C++派だが、Rustの奴がガチな話してるの見るのは刺激になっていい
適当に流し読みしとくから

**デフォルトの名無しさん** · 2023/06/27(火) 10:58:25.30

IntelとAMDで使えるAVX命令がオワコンと思ってた人がいるみたいですね
さらにサーバー用CPUの存在も知らなかったのか？
無知って怖い

**デフォルトの名無しさん** · 2023/06/27(火) 11:51:09.37

多分win12か13でAVXの対応有り無しで足切りがあると思うわ
AVX使わない理由がない

**デフォルトの名無しさん** · 2023/06/27(火) 11:57:06.05

今までセレロンでAVXは無効化されてた
急にセレロンが無くなってそれ相当の後継CPUでAVX有効になってる

MSから通達があったんじゃないかな
次のOSでAVX必須にしますって

MSだってコードはAVXありで統一したほうがテストが楽になる

**デフォルトの名無しさん** · 2023/06/27(火) 12:01:56.73

中途半端に新しいCPUも名前はセレロンのままにして
AVXで足切りすると一般ユーザーは自分のPCが足切り対象かどうかわかりづらい

それで名前を変えた
セレロンではwin12は使えませんと言えれば楽だから

**デフォルトの名無しさん** · 2023/06/27(火) 12:06:05.20

tokioとasync-stdはどちらが使いやすいの？

**デフォルトの名無しさん** · 2023/06/27(火) 12:29:11.86

>>789
個人的にはasync-stdが好きだったが
tokioの充実度とtokio前提クレートの増大によりasync-stdを捨てた

**デフォルトの名無しさん** · 2023/06/27(火) 14:29:16.42

インテルの新しい仕様でAMXというのが搭載される模様

これはまさにディープラーニング用の命令セットで見る限りGPUの設計思想を持ってきた感じ

https://www.intel.com/content/dam/www/central-libraries/us/en/documents/2022-12/accelerate-ai-with-amx-sb.pdf

浮動小数点数の演算でAVX-512より16倍高速らしい

わかりやすいAVX/AMXの解説
https://zenn.dev/herumi/articles/granite-rapids-sierra-forest

今、CPUが熱い

**デフォルトの名無しさん** · 2023/06/27(火) 14:47:05.10

やめろPen4のおもいでが (その熱いじゃない

**デフォルトの名無しさん** · 2023/06/27(火) 19:28:14.66

ただ、12世代 Core i では、一時的であるにせよ、
AVX512が使えないような状態になるって事
だよね。

**デフォルトの名無しさん** · 2023/06/27(火) 19:39:04.70

どうやらCPUが復権するみたいだな
AMXのレジスタ数を見るとまたまだGPUには及ばないが
GPUメモリへの転送がクソ遅いことを考えるとワンチャンあるのか？
https://fuse.wikichip.org/news/3600/the-x86-advanced-matrix-extension-amx-brings-matrix-operations-to-debut-with-sapphire-rapids/
とりあえず早く使ってみたい

**デフォルトの名無しさん** · 2023/06/27(火) 20:47:43.85

GPUはCPUでは速度低下するような大量の計算に向いてる
少ないとCPUに完全に負けるパターンが多い

**デフォルトの名無しさん** · 2023/06/27(火) 21:22:42.14

Rustで数値型みたいのってないの？一々132,i64, f32, f64とか宣言しないとダメなの？

**デフォルトの名無しさん** · 2023/06/27(火) 21:55:33.15

>>767
ラッピングして新たな型を作ってももちろん実行速度は同じにできる

>>796
むしろ型を宣言することが珍しい
普通は型推論に任せる
型推論できない整数はi32になるのでそれか無指定時の整数型

**デフォルトの名無しさん** · 2023/06/27(火) 22:39:39.33

i32,i64, f32, f64, ...等を一纏めにした型が欲しいんですよ。

**デフォルトの名無しさん** · 2023/06/27(火) 22:44:54.00

その型のメリットがさっぱりわからん

**デフォルトの名無しさん** · 2023/06/27(火) 22:54:21.96

数字に型があるなんてのはプログラマの発想だわな
麻痺してるけども

**デフォルトの名無しさん** · 2023/06/27(火) 23:03:12.78

haskell の (Num a) => a みたいなやつ？
どっかのblogでRustにはないって言ってたのみた記憶が

**デフォルトの名無しさん** · 2023/06/27(火) 23:21:38.75

Rustではtraitを用いたgenericで解決させることが多いが
具体的に何をしたいのかによっては別の方法になるかもしれない
何をしたいのか具体的な話を書くべき

**デフォルトの名無しさん** · 2023/06/27(火) 23:25:41.57

JSみたいになんでもnumberで扱いたいとかそんな程度の思いつきでしょ

**デフォルトの名無しさん** · 2023/06/27(火) 23:44:18.70

Rustでrayonクレートを使ってみた。自分のやったコード大体素のRustのfor文の5倍くらいだった。

**デフォルトの名無しさん** · 2023/06/28(水) 00:03:59.57

一挙に漂う小物臭

**デフォルトの名無しさん** · 2023/06/28(水) 00:32:12.67

話の流れと全然関係無いけど、オープンソースは
成功して無いと思っても、成功しているんだ、
と言い返される。rustも今後、成功して無いような
状態になっても、いんや、これは大成功なんだ、
と言い返される気がする。

**デフォルトの名無しさん** · 2023/06/28(水) 00:34:14.32

どうでもいい

**デフォルトの名無しさん** · 2023/06/28(水) 00:54:31.85

数値型実装の件は何か解決できたわ。
何か微妙な質問をしてしまった気がするわ。すまんな。

**デフォルトの名無しさん** · 2023/06/28(水) 00:56:34.57

Rust作者にとってRust使用者は顧客ですらない。

**デフォルトの名無しさん** · 2023/06/28(水) 01:05:39.08

顧客ベネフィットは関係なく、全て自分の名誉のため、
あるいは、歴史に名を残すことが目的になっている。
「ほら便利でしょ」「ほら画期的でしょ」
「ほら安全で楽でしょ」と。

**デフォルトの名無しさん** · 2023/06/28(水) 01:15:30.75

まわりまわって、自分の為になるんだぜ
あくまで私利私欲情けは人の為ならず

**デフォルトの名無しさん** · 2023/06/28(水) 01:28:34.60

ユーザーに合わせてソフトをカスタマイズするか
既製品にユーザーが適応するか
の対立がオープンソースにはほとんどない

どっちか一方だけが勝利とか成功するみたいな分断をなくすには良い方法だと思うよ

**デフォルトの名無しさん** · 2023/06/28(水) 01:32:19.53

オープン・ソース・ソフトを作れば作るほど
「水源枯渇問題」が生じる。
水源とは、顧客の財布を山の上流の水源に見立てたものである。
顧客は、コンパイラを使ってソフトを作って生計を立てた
がっている。なのに生計を立てるための水源を枯らしてしまうから、
オープンソースコンパイラの顧客ベネフィットは低い。

**デフォルトの名無しさん** · 2023/06/28(水) 01:35:45.59

Rustを流行らせれば流行らせるほど、水源が枯渇
するから、顧客は積極的に使うわけには行かなくなる。
出来る限り(無料だが)「不買運動」を行なおうとする。
いくら安くても、rustcは、顧客にとってマイナスの価値を持っている。
なぜなら流行れば流行るほど、水源が枯れ、顧客の夢や
目的から遠ざかるためである。

**デフォルトの名無しさん** · 2023/06/28(水) 01:41:28.43

マーケティングにおいて、「顧客ベネフィット」とは
「顧客が商品から得られる良い効果」を指す。有名な例では、
ドリルとドリルによって空けられる穴の関係が上げられる。
顧客が欲しいのはドリルと言う製品ではなく、穴である。
同様に、顧客が欲しいのはRustコンパイラでも、それで自分が
作るプログラムそのものでもない。水源から流れてくるお金と
プログラムを使ってくれるユーザーの存在である。しかし、
オープンソースが流行るとその目的からは益々遠ざかる。
だから、オープンソースは顧客ベネフィットが低いどころか
マイナスである。

**デフォルトの名無しさん** · 2023/06/28(水) 02:42:58.42

コピーが違法か合法かでいえば合法だが
合法な状態になっても、いんや、これは悪いことなんだ、と言い返される
どうやら合法と善を区別する傾向があるのは慈善事業だけではないらしい

**デフォルトの名無しさん** · 2023/06/28(水) 05:29:10.50

Ruby で、Vagrant を作った大学生のMitchell Hashimoto の会社・
HashiCorp の時価総額は、7千億円！

Rubyの神と言われて、今では、Terraform などGo の神！

OSS じゃないと、学生プログラマーが時価総額1兆円とか行かない

ハーバードでもそう。
年収3千万のサラリーマンになるな。
時価総額1千億円を狙うなら、Ruby on Rails をやれ

**デフォルトの名無しさん** · 2023/06/28(水) 07:35:44.93

RustとC, C++のスレでRubyを推す奴マジで謎だな。せめてRustやC, C++との比較の文脈で話せ。

**デフォルトの名無しさん** · 2023/06/28(水) 08:36:26.09

Rustを使うとWeb開発もできちゃうんだぜ

**デフォルトの名無しさん** · 2023/06/28(水) 08:50:23.70

できちゃうんだぜどころか、相性いいらしいってのは上のほうでみたよ

**デフォルトの名無しさん** · 2023/06/28(水) 09:48:22.46

C/C++の標準ライブラリって
ファイルを読み書きできるけどディレクトリやソケットはできない感じ？

**デフォルトの名無しさん** · 2023/06/28(水) 10:29:51.21

ないけどある boostには来てる
API直叩きが好きな俺はそっちエアプだけど

**デフォルトの名無しさん** · 2023/06/28(水) 10:37:37.24

理想と現実の合間を取った実用が実装で来ていれば標準に取り込まれるのだろうけど
標準ライブラリが出来てからどれだけ時間が経っているんだろ

亀の歩み寄り遅い
C++の呪い

**デフォルトの名無しさん** · 2023/06/28(水) 10:52:46.01

>>798
trait Number

**デフォルトの名無しさん** · 2023/06/28(水) 10:55:37.71

>>815
いや穴で例えるなら
安価な靴下と穴と寿命で語れ
もちろん安価が顧客ベネフィットだったら穴開き易くても売れる

**デフォルトの名無しさん** · 2023/06/28(水) 11:57:18.27

>>817
VagrantもTerraformも意味不明だな。
オープンソースはカルト宗教になっていて、信者が
寄付してるのではないか。

**デフォルトの名無しさん** · 2023/06/28(水) 11:58:31.05

それに MIT ライセンスなのに、どうやって金儲けしてる
のかも不明だ。

**デフォルトの名無しさん** · 2023/06/28(水) 12:01:33.51

仮想マシンの設定ツールななかしらんが、
そんなもん、1つあれば十分だし、そもそも仮想マシンなんて
普通の一使わない。
そんなもんの時価総額が7000億円にもなるなんておかしい。
トヨタ自動車は、一台200万円くらいの車を大衆に大量に
売っていても、ある程度の時価総額だ。
MITなソフトなんて無料にダウンロードできるんだから、
儲かること自体ありえない。
何らかのカルト集団と断定する。

**デフォルトの名無しさん** · 2023/06/28(水) 12:03:05.62

そもそも需要が無いはず。
需要が無いはずのもので金儲けできるわけない。
やはりカルト集団によるなんらかの仕掛けがあると
疑われる。