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

**デフォルトの名無しさん** · 2023/07/29(土) 15:05:46.55

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

っていう雑談スレ。

前スレ　
https://itest.5ch.net/mevius/test/read.cgi/tech/1688129795

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

**デフォルトの名無しさん** · 2023/08/16(水) 23:46:16.73

>>557
その点がC++が敗れてRustの台頭を招いた技術的な最大の原因っぽいな
C10K対策とasync/await対応を兼ねたモダンな需要にC++が実用的な解を示せなかった

**デフォルトの名無しさん** · 2023/08/16(水) 23:53:08.75

>>598
マジレス頼むけど
上のレスに科学的に根拠が必要な個所はどこなんだ

か・が・く・て・き・に　だ！

**デフォルトの名無しさん** · 2023/08/17(木) 00:10:55.41

>>600
しょうもない話は誰も興味無い。
それは科学の話じゃないよw

**デフォルトの名無しさん** · 2023/08/17(木) 01:03:05.11

こいつ前もやってたなコレw
「数学的に」の次は「科学的に」かww

**デフォルトの名無しさん** · 2023/08/17(木) 01:08:52.68

先生、management scienceは科学に入りますか？

**デフォルトの名無しさん** · 2023/08/17(木) 01:27:54.71

>>596
YouTuberと「ChatGPTで一儲けしたい投資家」の
骨肉の戦いが始まりました。
Fight!!

**デフォルトの名無しさん** · 2023/08/17(木) 01:56:59.01

争え……もっと争え……

**デフォルトの名無しさん** · 2023/08/17(木) 01:59:28.59

「OpenAIが破産」でググってみろ。

**デフォルトの名無しさん** · 2023/08/17(木) 02:35:59.33

OpenAIが存続するかに関わらず
LLMが社会に取り込まれるのは確定だよ
君らの周りも今年は対応に追われてないか？

**デフォルトの名無しさん** · 2023/08/17(木) 09:57:29.35

言語の質をデータの量で凌駕する作戦がなぜ失敗するのか？

量で凌駕するって言ったのにお金を節約しようとしてるからでしょ

**デフォルトの名無しさん** · 2023/08/17(木) 13:28:13.01

アスペの共通点
御世辞を真に受ける

**デフォルトの名無しさん** · 2023/08/17(木) 13:45:23.19

逆にマウンティングを真に受けて、上下関係は社会に必要だと思い込むのも困る

**デフォルトの名無しさん** · 2023/08/17(木) 22:13:42.98

>>557
そのあたりはC++23でも標準化をあきらめた
低レベルな部品のみ標準化して提供という方針のままのようだ
C++20コルーチン向けライブラリcppcoroは実用的に十分埋めきれていない
C++20コルーチンにも対応したboost.asioもスケジューリング問題にぶち当たる
いずれにしても記述性と簡素さがよろしくない
IT大手各社がC++をあきらめてRustへ走ったのも仕方ないかと

**デフォルトの名無しさん** · 2023/08/17(木) 23:32:30.60

マルチスプロセスやマルチスレッドじゃだめなん?

**デフォルトの名無しさん** · 2023/08/18(金) 00:14:51.05

>>612
CPUの性能を活かせない
CPUと比べてネット通信はとても遅く待ち時間となるため空き時間をいかに活用できるかが勝負
つまり次々と切り替えて処理していくことになるが
スレッドは各リソースコストも切り替えコストもかかりプロセスはさらにそれらのコストが非常に大きい
そのためCPUの性能を活かすどころか切り替えコストで無駄にしてリソースコストで限界に達していた

そのため例えばJavaScriptはWebブラウザ内でもNode.jsなどでも同様にシングルスレッドの中で多数の通信やGUIなどを並行して非同期に捌けるようにした
Goでも多数の軽量のGoルーチンがシングルスレッドまたはマルチスレッド上で並行して動いて非同期に多数処理できるようにした
Rustの非同期タスク及びC++20のコルーチンも同じ位置付けで両者はほぼ同じ仕組みのライバル同士

**デフォルトの名無しさん** · 2023/08/18(金) 00:24:29.53

>>613
>スレッドは各リソースコストも切り替えコストもかかりプロセスはさらにそれらのコストが非常に大きい
何のコスト?
「切り替えコスト」って書いてるのはユーザーモードから
カーネルモードへの切り替えコスト?

**デフォルトの名無しさん** · 2023/08/18(金) 00:41:08.12

プロセス全体をexitしたら各スレッドのデストラクタはどうなるんだろう
Cの標準ライブラリを捨てる
C++のデストラクタを排除する
ネイティブスレッド禁止
の三択かな

**デフォルトの名無しさん** · 2023/08/18(金) 06:19:11.79

>>614
スレッドは文脈からネイティブスレッド(OSスレッド)のことだとすると、
スレッド切り替えは少なくとも全レジスタの退避と復帰が必要となり、
プロセス切り替えはさらにメモリ空間の切り替えが加わる。
そして各スレッドは個別のスタック領域を持つためリソース的に大量のスレッド作成は限界個数が早い。
一方でC++20コルーチンやRustのタスクはスタックレスコルーチンなので、
個別スタック領域を必要とせず全レジスタの退避復帰切り替えも必要としないため、
大量に生成することができて極めて軽量に動作することになる。

**デフォルトの名無しさん** · 2023/08/18(金) 09:26:08.12

並行並列処理に関してはGoにRustは何一つ勝ててないでしょ

Goは標準で並行並列処理をサポート
selectとチャネルとコンテキストがあり、従来のasync/awaitと比べると凝ったことをするのが非常に簡単
キャンセル処理やrate limitingや並列数制御が標準機構で自由自在
標準でサポートしているからどのサードパーティライブラリでも共通の仕組みが利用できる

こういったものが何のライブラリも必要とせず手軽にできるのが最大の強み

Goはコンパイル速度とマルチコアでスケールする並行並列処理のために作られたから
これらの観点でメモリ安全が目的で作られたRustが勝てないのは当然

**デフォルトの名無しさん** · 2023/08/18(金) 09:40:42.56

並列並行と非同期を対比する阿呆

**デフォルトの名無しさん** · 2023/08/18(金) 09:47:52.53

干支一周前でこれだからな
http://ponner.blog104.fc2.com/blog-entry-211.html

**デフォルトの名無しさん** · 2023/08/18(金) 09:53:40.51

>>618
goroutineやnode.jsのpromiseといったもので並行と非同期の違いって何？
別に変わらんし、区別する意味はないぞ

非同期ってのは汎用性が高い言葉で完了を待たないって意味なら何にでも使えるわけで
例えばLinuxでファイルを書き込むときはページキャッシュだけに書き込みディスクIOは非同期に行われる
これを並行処理とは言わないはず

**デフォルトの名無しさん** · 2023/08/18(金) 09:54:03.98

>>571
中身が replace all する関数で名前が delete all とか違う意味だったらどう解釈するのか教えて

**デフォルトの名無しさん** · 2023/08/18(金) 09:59:00.46

ChatGPTって観るだけで詐欺を連想するが
>>580
は説得力あるなω

**デフォルトの名無しさん** · 2023/08/18(金) 10:15:07.27

>>617
Goでアドバンテージ持ってる会社が他社を陥れる為にRustいいぞって噂を流したのかもな

**デフォルトの名無しさん** · 2023/08/18(金) 11:27:41.44

お客様を陥れるのが本質
本質を隠す為に同業者を陥れるという噂を流している

**デフォルトの名無しさん** · 2023/08/18(金) 12:31:50.68

https://play.rust-lang.org/ とかでも
https://paiza.io/ とかでも
使える crates が少な過ぎるんじゃね
これで普及とか無理やろ

**デフォルトの名無しさん** · 2023/08/18(金) 13:05:03.86

>>617
GoでできるそれらのことはRustでもできるよ
むしろチャネルの種類などRustの方が機能も豊富だよ

Goはモダンな言語の中で唯一null安全でないしデータ競合も起きまくるし安全性を無視しすぎかな
それはともかくGoは言語機能が貧弱すぎて辛すぎる
ジェネリクスがようやく入ったけどまともに使えないなど不満が多いよね

結局Goはガベージコレクション言語にすぎないから様々な限界があるよ
C/C++/Rustのように他の言語たちのライブラリ作成もできないしね

**デフォルトの名無しさん** · 2023/08/18(金) 13:14:44.19

＞C++20コルーチンやRustのタスクはスタックレスコルーチンなので、
＞個別スタック領域を必要とせず

Goルーチンは個別のスタック領域を必要としてしまうね

**デフォルトの名無しさん** · 2023/08/18(金) 13:25:35.72

chatGPTは何で作ってるんだろ？

**デフォルトの名無しさん** · 2023/08/18(金) 13:58:06.66

>>626
“気軽”にできるといってるわけだが本当に気軽にできるの？
標準ライブラリでサポートしているの？

データ競合に関してはチャネルを使えばある程度は回避できるしrace detectorもあるのでさほど問題にはならない
race conditionに関してはRustでもGoでも検出はできないから結局プログラマの技量になるわけだけど
Rustにしたからといってあらゆる並行並列処理のバグが回避できるものじゃないぞ
そもそも難しいものなんだから

**デフォルトの名無しさん** · 2023/08/18(金) 14:08:17.74

Goはこんな基本操作でも恐ろしい挙動で驚いた

14 デフォルトの名無しさん 2023/07/28(金) 03:06
その話ならばGoという最悪の言語があって直感と常識を裏切る挙動をしてくる
しかも理解できたと思ったら二転三転と次々と裏切りの挙動をしてくる

// まず [1 2 3] をaに作ってbに代入するところからスタート
a := []int{1, 2, 3}
b := a
// 実験1: 途中要素の書き換え
a[1] = 222
fmt.Println("a =", a) // → [1 222 3]
fmt.Println("b =", b) // → [1 222 3]
// aもbも書き換わってしまった！同じものを指しているのだろうか？

// 実験2: 末尾要素の削除
a = a[:len(a)-1]
fmt.Println("a =", a) // → [1 222]
fmt.Println("b =", b) // → [1 222 3]
// aだけ削除された！aとbは別なのだろうか？

// 実験3: 要素の追加 (その1)
a = append(a, 777)
fmt.Println("a =", a) // → [1 222 777]
fmt.Println("b =", b) // → [1 222 777]
// aとbは再び同じになってしまった！なぜだ？？

// 実験4: 要素の追加 (その2)
a = append(a, 999)
fmt.Println("a =", a) // → [1 222 777 999]
fmt.Println("b =", b) // → [1 222 777]
// aだけ追加された！また裏切られた！！

**デフォルトの名無しさん** · 2023/08/18(金) 14:24:07.82

>>629
>race conditionに関してはRustでもGoでも検出はできないから結局プログラマの技量になるわけだけど
そこでChatGPTですよ!

**デフォルトの名無しさん** · 2023/08/18(金) 14:31:02.70

>>629
Rustで発生するrace conditionてどういう前提？
普通は発生しないと思うけど

**デフォルトの名無しさん** · 2023/08/18(金) 15:25:39.40

>>626
5chなら知ったかできて気持ちいいよねw
良かったね

**デフォルトの名無しさん** · 2023/08/18(金) 16:16:34.73

常識的に考えれば気持ちいい方が合理的だよ
常識を疑えば、自分が損をしてでも何かを成し遂げるみたいな
合理性のない人間が増えてくる

**デフォルトの名無しさん** · 2023/08/18(金) 16:27:02.47

>>630
この話広げるのもなんなんだけどこの挙動はどう説明されるの？

**デフォルトの名無しさん** · 2023/08/18(金) 16:30:59.19

>>632
race conditionの意味でググってこいよ
機械で検出できない高レベルの競合のことで、並行並列処理するときは常にこれと向き合う必要がある

Rustで検出できるのはdata raceでこれはGoでもランタイムだが検出できるわ

**デフォルトの名無しさん** · 2023/08/18(金) 16:37:05.86

そこでChatGPTですよ!

**デフォルトの名無しさん** · 2023/08/18(金) 16:55:50.42

ChatGPTは、捨て垢で使えるようになってから来いよ。。

こう煩いとRust布教されるほうがマシｗ

**デフォルトの名無しさん** · 2023/08/18(金) 17:08:33.27

デッドロック検出できるのって画期的なことだと思うよ

**デフォルトの名無しさん** · 2023/08/18(金) 17:38:45.64

>>636
data race関係ないrace conditionを言語で検知してほしいケースなんてあるの？

**デフォルトの名無しさん** · 2023/08/18(金) 17:39:23.48

過ぎたるはなんとかってやつか
しつこ過ぎるとダメって事やな

**デフォルトの名無しさん** · 2023/08/18(金) 17:47:16.72

>>640
Rust信者が何でもコンパイル時に検出できるとか絶対安全！だとか吹聴しているから訂正しているだけだよ

データ競合ならGoでもランタイム時に検出できるわ

**デフォルトの名無しさん** · 2023/08/18(金) 17:47:46.99

>>640
むしろロックフリーデータ構造は
data raceあり
race conditionなし
の良く出来た高速アルゴリズム

**デフォルトの名無しさん** · 2023/08/18(金) 18:03:31.02

実際にGoで作ってるところは有名どころでも並行処理関連のバグ量産してるからRustとはリスクレベルが全く違うわな

**デフォルトの名無しさん** · 2023/08/18(金) 18:43:48.21

>>636
>>642
データ競合が運用時に検出できても手遅れ
しかもデータ競合を検出するために実行オーバーヘッドを伴うため悪い選択肢となる
この件でも静的にコンパイル時点でデータ競合を検出できるRustが大きく有利だろう

**デフォルトの名無しさん** · 2023/08/18(金) 18:47:47.02

ハイリスクハイリターンのように、リスクとリターンの差に意味がある
リスクとリスクの比較や、リターンとリターンの比較は合理的ではないと思う

**デフォルトの名無しさん** · 2023/08/18(金) 19:17:38.70

>>645
だけど気軽にできないよね
標準の機構で並行並列処理できないよね
async await使うだけでアホみたいに大量の依存をダウンロードしてきてコンパイル爆遅だよね

GoはCとかの手続き型言語を知っていたら、すぐマスターできるけど
Rustで並行並列処理までマスターするのに一体どれだけ時間がかかるんだろうねw

**デフォルトの名無しさん** · 2023/08/18(金) 19:22:26.53

>>635
C++のvectorに相当するのがその>>630のGoのスライス
その挙動は明らかに常識外れで理不尽だがGoの仕様通りの挙動
Goはあちこち設計がおかしい

>>644
このためGoで本格的なプログラミングをすべきではない風潮になってきた
もともと貧相な仕様をシンプル簡素と積極的に評価してきたが無理があった

**デフォルトの名無しさん** · 2023/08/18(金) 19:40:10.54

>>630
これ挙動わかってるのにわからんないみたいに書いてあるでしょ
配列とスライスのデータ構造はシンプルだからそれを調べれば自明にわかるだろ
他の言語でも

実験2でそんなこと考える奴はいないよね

**デフォルトの名無しさん** · 2023/08/18(金) 19:44:32.36

>>630,648
GoのスライスをC++のvector相当、ってのが早とちり過ぎる
Goのslice header, backing memoryの理解をすっ飛ばしただけじゃんw

**デフォルトの名無しさん** · 2023/08/18(金) 19:50:41.88

>>630
そんな妙な動きをするプログラミング言語はGoだけだな

**デフォルトの名無しさん** · 2023/08/18(金) 20:23:05.08

C++erに無視されてきてつまらなくなってきたので今度はGoをタゲるおじさん

**デフォルトの名無しさん** · 2023/08/18(金) 20:29:00.75

>>630
使いやすいかどうかは謎だけどスライスだから当然の挙動かなと

実験1 スライスは配列そのものじゃなく参照と長さなのでそういうもの
実験2　aは新しく作った別のスライスを代入してるので当然
実験3 スライスaの末尾に対してappendしてるので当然
実験4 3と同じ　スライスaとbの長さが違っているので当然

結論
スライスすら使えない奴は馬鹿

**デフォルトの名無しさん** · 2023/08/18(金) 20:36:58.94

てかこれを理解できないのであればRustは習得できないんじゃないかね
Rustできるならわかるだろ

**デフォルトの名無しさん** · 2023/08/18(金) 20:38:53.30

>>653
嫌なら配列使え、ということかね。

配列とスライスの表記に問題があるとは思うけど。[]と[1]で別物というのはやりすぎだわな。

**デフォルトの名無しさん** · 2023/08/18(金) 20:40:40.07

余談
初期の開発中のC言語にはポインタは　int* じゃなくてint[]だった

**デフォルトの名無しさん** · 2023/08/18(金) 20:51:02.38

>>630
Goの何がおかしいのかわかった
C++やRustや他の普通の言語ならば
bがaのコピーならばその実験1～4すべてでaとbは異なる
bがaを参照しているならばその実験1～4すべてでaとbは同じになる
その二つのケースどちらかになる
Goは実験を進めるごとにaとbが異なったり再び同じになったり再び異なったりおかしい

**デフォルトの名無しさん** · 2023/08/18(金) 20:54:15.45

わざと言ってるよねｗそれｗ

**デフォルトの名無しさん** · 2023/08/18(金) 21:01:52.15

なぜGoだけがそんな変な仕様にしちゃったの？
新旧の言語を見回してもそんな変な仕様の言語は存在しないよ

**デフォルトの名無しさん** · 2023/08/18(金) 21:20:15.18

スライス自体は他も似たり寄ったりだよ
pythonは3で多分新しい配列を作る
多分appendの時に新しい配列をコピーしてそっちに代入するはず

元の実態を明確にコピーすると言わずにコピーするかどうかと言う設計理念の違いだろう
pythonは初心者向けだからそうしたgoはしなかった

**デフォルトの名無しさん** · 2023/08/18(金) 21:24:30.15

配列の箱が並んだ絵でも書いてスライスは別のところに書いてポインタの矢印と長さでも書いてみれば理解しやすい

**デフォルトの名無しさん** · 2023/08/18(金) 21:36:19.25

>>659
GoはC言語に近い言語だから
Cでmallocとかreallocとかを使って配列を扱ってたらよく理解できるはず

無駄なコピーを避けつつ、細かいメモリ操作も行えるようにして最適化の余地を残しているのがGoの特徴なので

**デフォルトの名無しさん** · 2023/08/18(金) 21:36:31.10

>>659
スライスはrangeみたいなもので、スライスそのものはそんなに変なものではない。

問題はそこではなくて、
・スライスに「可変長なだけの配列」に見えるような表記を割り当てた
・真に「可変長なだけの配列」(vectorみたいなの)が存在しない
なので、スライスと配列を混同して使わざるを得ない言語設計が問題。

素直にCOWスライスを用意すればまだ良かったんだけどね。

**デフォルトの名無しさん** · 2023/08/18(金) 21:41:06.14

Goのスライスは現実社会の物を表しているとも言える

1,2,3と書かれた箱が並べてあって、あるスライス（窓）が1,2を指しているとする
そのスライスに4の箱を追加されたとしたらどのようになるのが望ましいか

Goは現実世界のように1,2,4,3と箱が並ぶ
Pyothonはどこかから急に箱が表れて
1,2,4と言う並びの箱の列と1,2,3と言う並びの箱の列ができる

**デフォルトの名無しさん** · 2023/08/18(金) 21:42:56.92

なるほど、スライスと言われてなんとなくわからんでもない挙動には見えてきた
でもやっぱりバグを呼び込むためだけの仕様にも思える
こんな仕様にして誰か幸せになるんかな

**デフォルトの名無しさん** · 2023/08/18(金) 21:45:59.61

>>665
スピードマニア、つまりgo ユーザー。

**デフォルトの名無しさん** · 2023/08/18(金) 22:01:59.17

C++もRustもわかりやすい仕様だけどGoよりスピード出る

**デフォルトの名無しさん** · 2023/08/18(金) 22:23:22.38

Goは言語設計をミスってるな

>>630
// 実験3: 要素の追加 (その1)
a = append(a, 777)

この部分は他の言語だとメソッド名こそ異なれど
a.add(777)
a.append(777)
a.push(777)
a.push_back(777)
となる
メソッド名は自由だがこの形式が正しい
Goの失敗の原点はここだ
a = append(a, 777)

**デフォルトの名無しさん** · 2023/08/18(金) 22:31:11.69

言語とライブラリを分離できないと潰しがきかない
C++の場合mallocやsjljを単なるライブラリではなく言語の一部にしたのが悪手

**デフォルトの名無しさん** · 2023/08/18(金) 22:42:32.22

>>668
go はオブジェクト指向じゃないからなぁ。

純関数にしやすいように、仮引数自体は変更しない設計にしたんじゃない？Rustも似たような思想だろ。

**デフォルトの名無しさん** · 2023/08/18(金) 23:16:43.53

手軽というのは実際はただの手抜きなんだよ
その尻拭いをさせられてきた良識ある若者が次の世代のためにRustのようなものを産み出す
それを無自覚な老害が腐す

**デフォルトの名無しさん** · 2023/08/18(金) 23:38:51.82

>>629
標準ライブラリの範囲は言語ごとに異なる
Rustの方針は言語サポートが必要な機能を標準ライブラリとする傾向が強いため他より範囲が狭い
例えばRustの標準ライブラリに正規表現や乱数などは含まれていない
だからといってRustはそれらが扱えない、というのは正しくないように
標準ライブラリに入っているか否かはさほど重要なことではない

今回の例で言えばC++20のコルーチンもRustのasyncコルーチン(タスク)も意図的にそれ自体の機能のみを言語機能および標準ライブラリに入れている
コルーチンのスケジューリング機能など含めてほとんどの機能は標準ライブラリにない
それらは言語自体が直後サポートしなくても実装可能だからであろう
Rustの場合はデファクトスタンダードの地位を確立したtokioがあるため困ることはない

**デフォルトの名無しさん** · 2023/08/18(金) 23:44:30.71

>>647
気軽にの意味が多様だがRustでもGoルーチンのように気軽にタスクをspawnできる
もちろんチャネルも使えてGoスタイルのプログラミングをしたければそれも簡単にできる

**デフォルトの名無しさん** · 2023/08/18(金) 23:52:18.58

>>654
RustでVecだと最初のb = aの時点でムーブとなるためその問題は起きない
ムーブではなくb = &aとして参照にしても競合防止のため書き換えできず問題は起きない
Goでaとbが異なったり同じになったりを二転三転してるのはaとbが競合してると考えてもいいのかもしれない

**デフォルトの名無しさん** · 2023/08/18(金) 23:57:19.87

>>670
Rustはオブジェクト指向であってクラス継承の概念のみを排除している
だからそこではRustでもa.push(a)の形となりVec型の値(オブジェクト)が書き換わる
他の例でもイテレータはnext()する毎に値(オブジェクト)が書き換わる

**デフォルトの名無しさん** · 2023/08/19(土) 00:22:06.39

getterだけを公開すればオブジェクト指向だが
いつどこからsetされるか分からないコードはstatic変数に近い性質
それはオブジェクト指向ではない

**デフォルトの名無しさん** · 2023/08/19(土) 00:59:21.18

>>676
「いつどこからsetされるか分からないコード」について
Rustは所有権もしくは可変参照を持たないと値を書き換えられないからコード上で明確にわかるよ
static変数については「いつどこからsetされるか分からないコード」によってデータ競合が起きうるのはその通り
しかしRustのstatic変数は(unsafeを除いて)可変(mutable)ではないため「いつどこからsetされるか分からないコード」によってデータ競合を起こすこともないよ
例えばRustのstatic変数をマルチスレッドで共有しつつ値を書き換えたいならばMutexなどによる内部可変性を与える必要がありデータ競合が必ず避けられる

**デフォルトの名無しさん** · 2023/08/19(土) 01:55:38.87

こういう意味のない比較を少なくとも2年はずっと書き散らし続けて
何も生み出していないっていうね

**デフォルトの名無しさん** · 2023/08/19(土) 06:12:11.05

技術板のスレなのに無能が適当なこと書き散らすだけで他人が参考にならないスレ
板違いの雑談スレなんだからせめてageるな

**デフォルトの名無しさん** · 2023/08/19(土) 08:18:21.33

Rust は安全(キリっ
ですね
わかります

**デフォルトの名無しさん** · 2023/08/19(土) 08:30:53.11

>>672
標準ライブラリのサポートは重要だろ
ちょっとしたことをやるだけでいちいちライブラリを選定する必要があり、コンパイルが遅くなる
CICDも遅くなるし、ライセンスもいちいちクリアしなくては行けない

同じく標準ライブラリが薄いNode.js使っててnode_modules肥大化問題に悩んでいる奴は多いだろう

例えばhttpリクエストするだけでもプロジェクトによってライブラリが異なる
ライブラリが異なるのでそれぞれの使い方をいちいち覚えないといけない
こういったことは企業で開発する上で不毛なんだよ

**デフォルトの名無しさん** · 2023/08/19(土) 08:44:42.58

企業については、企業がライブラリを指定するんだし…感はある(非プロの感想です

**デフォルトの名無しさん** · 2023/08/19(土) 10:43:11.58

>>681
わかります

**デフォルトの名無しさん** · 2023/08/19(土) 10:53:02.71

選定ばかりで何も生み出さない消費者を許せないってそこに書いてある
だから選択肢を増やせば増やすほど評価が高い

**デフォルトの名無しさん** · 2023/08/19(土) 14:23:54.36

オープンソース環境は、OSや環境に変化があるたびに、
別人が別の修正版を出してきて、少しずつ使い勝手が違う
ので、めんどくさい。
Rustもそうなる予感がするので使わない。

**デフォルトの名無しさん** · 2023/08/19(土) 14:30:43.48

>>685
今、OSSのある開発環境を使い始めたとしよう。
・ドキュメントも不十分なので、上手く行く方法を
　試行錯誤して探すのが必須。
・やっと探し出した方法でmakefileやbatファイルなどを
　整備して開発できるようになる。
・数年後、試して見ると動作しなくなっている。
・それでまた、ググり調査 + 自分でテストを繰り返し、
　数種類の配布物を試してやっとの思いで昔と似た
　ことが出来る方法にたどり着く。その間、大部分の
　環境は、来たいはずれの「試し損」となる。
・そして、makefileやbatファイルが作り直しとなる。
・ライブラリパス、インクルードパス、#includeなどの
　修正も必要となる。xxx.h だったものが、sys/xxx に移って
　いたり、昔 typedef されていたものが、なぜか無くなったり
　別ファイルで定義し奈緒知れていたりする。
・ここまで、数日間かかり、プログラミングは全く出来ない。

経験法則から導かれたOSSの開発環境の日常の風景。

**デフォルトの名無しさん** · 2023/08/19(土) 14:31:48.17

>>685
C++の新しい規格を使わないのかな？

**デフォルトの名無しさん** · 2023/08/19(土) 14:35:14.63

>>686
>・数年後、試して見ると動作しなくなっている。
あなたのOSSとの付き合い方の問題点は上記に集約される
常に追っていかなくてはおいてきぼりにされる
あなたには向いていないので使わないこと

**デフォルトの名無しさん** · 2023/08/19(土) 14:44:59.29

2022年版年次Rust調査結果、1万超の回答　職場でRustを使う理由
https://atmarkit.itmedia.co.jp/ait/articles/2308/19/news032.html

プロフェッショナルな環境でRustを使用する主な理由としては、「バグのないソフトウェアを作成できる」という認識(86％)、Rustのパフォーマンス特性(84％)、Rustのセキュリティと安全性の保証(69％)が挙げられる。また、回答者の76％が、「Rustが楽しいと感じたから」という理由だけでRustを使い続けている(ここでは回答者が複数の選択肢を選択できるので、数値の合計が100％になるわけではない)。

仕事でRustを使用した回答者のうち、72％が「チームの目標達成に役立った」と報告し(前年比4ポイント増加)、75％は今後もチームでRustを使用し続ける計画を持っている。

一方で、職場で適用されている他の言語と同様、Rustの学習曲線は重要な考慮事項だ。専門的な立場でRustを使用している回答者の39％は、そのプロセスが「挑戦的だ」と報告している。
回答者の9％は、職場でRustを採用することで「チームの速度が低下した」と回答した。

**デフォルトの名無しさん** · 2023/08/19(土) 14:45:09.39

>>681
Rustはデファクトスタンダードがあるからそのように困ったことないな
httpならhttpという名のクレートに基本事項が定められていて全てのhttp実装やその上の各フレームワーク等がこれを使う
httpクレート自体はhttp実装を持たずにhttpのリクエスト型やレスポンス型にURI型やヘッダ型やステータス型などだけを持つところが重要なポイント
もし新たな速いhttp実装が現れたとしてもインターフェイスはこのhttpクレートに(少なくとも今までは全て)従うため利用者が困ることはない

**デフォルトの名無しさん** · 2023/08/19(土) 16:02:34.86

>>688
うん。だから、OSSは大嫌いだし、出来る限り使わない。
Linuxを含めて色々試したが、ごく一部のものを除いては
結局駄目だった。

**デフォルトの名無しさん** · 2023/08/19(土) 16:07:41.17

>>691
ちなみに、俺は、自分で何から何まで作るのが好きなので、
人が作った環境に追いまくられるのが大嫌い。

**デフォルトの名無しさん** · 2023/08/19(土) 16:16:02.61

>>691
適応能力に長けてないと扱うのは難しい
変化の速さがOSSの競争力の源泉の一つと感じられなければ
苦痛だろうね

オープンソースでもboostとかはほとんど変わらんやろ? 使わないの?
規格にすらあなたは新しいものにクレームつけそうだがw

**デフォルトの名無しさん** · 2023/08/19(土) 16:17:31.20

>>692
仕事が遅いと言われるだろ?

**デフォルトの名無しさん** · 2023/08/19(土) 16:19:22.12

debとかrpmとかバイナリパッケージを否定したら挫折するね
Windowsに依存しないだけならそこまで無理ゲーではないけど
WindowsもLinuxもどっちも認めないいわゆる「中立」が過激化するとうまくいかない

**デフォルトの名無しさん** · 2023/08/19(土) 16:36:31.92

>>692
むしろ逆で、今までみたことがないくらい仕事が
物凄く速いと言われていたぞ。
研修時の記録も塗り替えた伝説も持っている。

**デフォルトの名無しさん** · 2023/08/19(土) 16:37:25.19

>>696
アンカーミスした。
正しいアンカーは >>694。

**デフォルトの名無しさん** · 2023/08/19(土) 17:00:00.61

OSSかどうかとは関係なく現状のRustはライブラリ探しと精査に超時間がかかるのは確か
アプリケーションプログラマーから見るとこれがRustの最大の欠点