結局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/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の最大の欠点

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

>>696
仕事が速い人がOSSに適応できないわけないじゃんw
>>686に「・ここまで、数日間かかり、プログラミングは全く出来ない。」
と自分でも書いてるし

boostは使わないのかい?

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

>>698
そもそもRustは低レイヤ向けでライブラリを特に必要としない用途に向いてるってことだよ
Webやクラウドなどの通常のバックエンドアプリはライブラリを多用することになるがそれは向いていないってことの証

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

ほんとに(webの上位層で)人気が出てくれば、ライブラリは勝手に揃ってくるだろうけどね

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

webやるには十分よ

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

>>700
ところが低レイヤもたくさんライブラリ使うんだよ

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

だんだんOSSがおかしいと思い始めてきた

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

RHELやHashiCorpの動きはAmazonがターゲット？

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

actix-webとaxumどちらがいいのだろう

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

>>704-705
Mojo🔥がAmazonかGoogleに買収されてクラウドオンリーになる可能性

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

Firefoxはバクサイ開いたままにしてるとメモリー20GB、CPU100%になったりする
Chromeはそんなことにならない
そういう違いがある

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

>>706
axum

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

>>707
妨害してるってこと？

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

インターネットはおかしいと最初から思ってた
でもソースコードを保存する場所はネットでもディスクでも紙でもなんでもいい

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

>>690
Python3の場合(正常に動作しかも高速)
https://paiza.io/projects/ciU5iRNbruZiSz4IAy9M4w
Rustの場合(timeoutする)
https://paiza.io/projects/xeAwQZ8M_BHwu0fvFsPLtw

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

write_allの後はflushした方いいんじゃね？
しらんけど

まあPythonの方がアマチュア向けというか面倒見がいいのは分かる

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

>>697
自演がバレたなω

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

>>698
crates.io 破綻してるよな

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

crates.ioに限った話ではないけど
ライブラリ名と実装品質のミスマッチはいつも気になってる
HTTP/2用のライブラリでもhttp2よりh2の方が利用者数多いとか
オープンなレジストリの宿命として諦めるしかないのかな

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

>>644
5chでデマ垂れ流して気持ち良くなるだけのゴミ人生でしたw

**デフォルトの名無しさん** · 2023/08/20(日) 00:49:54.32

損得の勝負をしてると、デマで得をする奴がいないか常に不安だよな
それなら単純に本当か嘘かで勝負すればデマと勝利は両立しないから安心安全なのでは

**デフォルトの名無しさん** · 2023/08/20(日) 01:54:31.51

>>712
HTTPを知らないなら素直にライブラリを使えよ
そのRustコード汚すぎるがそこに正しくHTTPヘッダを一行加えたら動いたぞ
サイン曲線GIFが表示されている

**デフォルトの名無しさん** · 2023/08/20(日) 02:56:13.90

>>719
修正版ウブおながいします

**デフォルトの名無しさん** · 2023/08/20(日) 06:38:03.53

練習に書いてみた

fn base64_encode(input: impl AsRef<[u8]>) -> String {
　const TABLE: [u8; 64] = *b"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
　const MASK: usize = 64 - 1;
　let mut input = input.as_ref();
　let mut output = Vec::new();
　while let [i0, i1, i2, rest @ ..] = input {
　　let x = u32::from_be_bytes([0, *i0, *i1, *i2]) as usize;
　　(0..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
　　input = rest;
　}
　match input {
　　[i0, i1] => {
　　　let x = u32::from_be_bytes([0, *i0, *i1, 0]) as usize;
　　　(1..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
　　　output.push(b'=');
　　}
　　[i0] => {
　　　let x = u32::from_be_bytes([0, *i0, 0, 0]) as usize;
　　　(2..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
　　　output.push(b'=');
　　　output.push(b'=');
　　}
　　_ => {}
　}
　String::from_utf8(output).unwrap()
}

**デフォルトの名無しさん** · 2023/08/20(日) 07:18:09.55

>>663
同意

**デフォルトの名無しさん** · 2023/08/20(日) 08:16:48.41

>>699
俺はOSSを使わない仕事をしているから。

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

>>698
>OSSかどうかとは関係なく現状のRustはライブラリ探しと精査に超時間がかかるのは確か
いや、それはOSSだとほぼ必ず起きる現象。
OSS自体が持つ欠点の一つだから。

**デフォルトの名無しさん** · 2023/08/20(日) 08:24:41.49

クローズドなソフトだと、古いものも維持されるかどうかは、
それぞれの企業次第で各企業の特徴が出る。
ところがOSSの場合、人類全体の傾向となるから、
どのOSSなソフトでも似たような保守の傾向となり、
制御できない。なぜなら、人類全体の傾向はいつも
ほぼ同じだから。
電力送電における「無限大母線」という言葉を思い出した。

**デフォルトの名無しさん** · 2023/08/20(日) 09:39:15.51

>>720
>>712 もう治ってる
>>719 thx

**デフォルトの名無しさん** · 2023/08/20(日) 09:56:36.27

>724
なんか全体集合と部分集合を理解出来ていない様な日本語ですね

**デフォルトの名無しさん** · 2023/08/20(日) 10:26:38.95

人類の傾向はいつも、n=1を笑い、前例が1つもない事件事故に泣く

**デフォルトの名無しさん** · 2023/08/20(日) 10:50:22.50

>>723
boostは使わないのかな?

**デフォルトの名無しさん** · 2023/08/20(日) 11:46:34.65

>>727
実際rustに限らずOSSなら必ず当てはまることなので部分と言っても意味はない。

**デフォルトの名無しさん** · 2023/08/20(日) 11:52:30.19

>>730
「ライブラリ探し」は検索すれば良いだけ
「精査」はOSSはソース手に入るが
プロプラなソフトでは諦めるしかない

**デフォルトの名無しさん** · 2023/08/20(日) 12:53:04.65

時間はお金で買える
ただ具体的にいくらで買えるのか誰も知らないだけ

**デフォルトの名無しさん** · 2023/08/20(日) 13:19:08.66

>>731
ライブラリの選定ってソースコードの精査はそれほど比重高くないよ。
それよりもライセンス、開発体制やアクティブさ、直近のリリース状況、人気とかが重視されがち。

**デフォルトの名無しさん** · 2023/08/20(日) 13:30:35.17

>>733
アンカー間違っとった

>>724
「ライブラリ探し」は検索すれば良いだけ
「精査」はOSSはソース手に入るが
プロプラなソフトでは諦めるしかない

**デフォルトの名無しさん** · 2023/08/20(日) 15:55:58.84

>>712を見て思ったが
RustにもPythonのrequests/base64のようなライブラリあるんだろ

**デフォルトの名無しさん** · 2023/08/20(日) 15:58:19.75

標準ライブラリには入ってない

**デフォルトの名無しさん** · 2023/08/20(日) 16:12:04.89

>>736
Pythonのrequestsも標準じゃないだろ
Rustは標準のみを使い,Pythonでは外部ライブラリも使ってだからな

**デフォルトの名無しさん** · 2023/08/20(日) 16:22:18.11

RustってSimd命令は非安定だよね？実際にSimd命令使うとどれくらい高速化できんの？
Simd命令ってCPUに応じて場合分けしてコードを書かないとならんの？

**デフォルトの名無しさん** · 2023/08/20(日) 16:51:39.65

>>738
CPU以外にボトルネックがないならおおよそ並列度の分だけ性能上がる
32bit + 32bitのような計算を1命令で処理してたところを256bit幅がサポートされてるハードウエア&命令を使えば約8倍

**デフォルトの名無しさん** · 2023/08/20(日) 16:54:56.78

>>739
実際には、「お膳立て」のためのオーバーヘッドが有ることと、
SIMD命令が使える部分が少ないことで、8倍のSIMD命令を
使っても、20%位の向上にしかならないと言われている。
数値は大体。
だから、IntelはAVX512をメインストリームからは捨て
ようとした。

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

スパコンが、ベクトル型が廃れてスカラー型の並列型が
流行していることからしても、SIMDは将来性の無い
ものだと個人的には思ってる。
むしろ、SIMDを捨て、コア数を増やす方が圧倒的に
高速化できる。

**デフォルトの名無しさん** · 2023/08/20(日) 17:20:33.01

スパコンのコーディングは知らんけど
雑にスレッドプールにぶん投げるだけで速くなる並列処理の方が
SIMDより使いやすいなって思う

**デフォルトの名無しさん** · 2023/08/20(日) 18:05:27.72

>>720
整理するとこれでいいみたい

use std::error::Error;
use std::net::TcpStream;
use std::io::{BufReader, BufRead, Read, Write};
use std::fmt::Write as _;

fn http_get(host_port: &str, path: &str) -> Result<Vec<u8>, Box<dyn Error>> {
　let mut server = TcpStream::connect(host_port)?;
　let mut http = String::new();
　write!(http, "GET {path} HTTP/1.1\r\n")?;
　write!(http, "Host: {host_port}\r\n")?;
　write!(http, "Connection: close\r\n")?;
　write!(http, "\r\n")?;
　server.write_all(http.as_bytes())?;

　let mut server = BufReader::new(server);
　let mut line = String::new();
　server.read_line(&mut line)?;
　if line != "HTTP/1.1 200 OK\r\n" {
　　return Err("HTTP: not 200 OK".into());
　}
　while server.read_line(&mut line)? > 2 {}

　let mut data = Vec::<u8>::new();
　server.read_to_end(&mut data)?;
　Ok(data)
}

**デフォルトの名無しさん** · 2023/08/20(日) 18:11:30.48

よかったね

**デフォルトの名無しさん** · 2023/08/20(日) 18:25:00.43

>>743
え？Rustって標準ライブラリでhttpリクエストすらできないの？

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

Rsutはwebやるための言語とか言ってたような

**デフォルトの名無しさん** · 2023/08/20(日) 19:01:10.42

とりあえず1000×1000の行列の行列積dotが0.015秒弱でできるようなところまで行列ライブラリーが実装できたので、何とか0.00秒台で計算が終わる様にしたい。
今の所手を出してない最適化
1) Simd命令
2) インラインアセンブリ
3)ループアンローリング(これはRustだと自動的にやってくれてる様で自分の実験した範囲ではあまり効果がなかった。)

この中で一番効果的な最適化は何？
ちなみに今の所は以下の最適下は既に実装済み
1) ループ交換
2) キャッシュブロッキング
3) rayonによる並列処理

**デフォルトの名無しさん** · 2023/08/20(日) 19:10:25.82

>>745
Rustの標準ライブラリは言語サポートを必要とするものを中心に極めて絞っている
既出のhttpやbase64だけでなく正規表現や乱数など多くの機能がデファクトスタンダードライブラリ

>>746
標準ライブラリにないだけで各種ライブラリは下位から上位フレームワークまで揃っている
CPUとメモリのリソースコスパ重視でWebやるならRust一択でまちがいない
Webインフラ各トップ企業たちも>>496のようにRustを採用している

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

デファクトスタンダードという選りすぐりに聞こえるが
単にそれしかないだけのような...
ユーザ数少ないので

**デフォルトの名無しさん** · 2023/08/20(日) 19:20:14.76

>>747
simdに手を出すとarmのsimdまでやる羽目になる
インラインアセンブリも同じ

つまり今のところおすすめはない
外部のライブラリなどに依存するなら別だけど

**デフォルトの名無しさん** · 2023/08/20(日) 19:25:32.14

>>750
じゃあ基本的にはdot演算に関してはこれ以上の最適化の余地はないって感じ？

**デフォルトの名無しさん** · 2023/08/20(日) 19:26:47.41

グーグルとアップルが流行らせようとしてるらしいが

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

paiza.io の Rust は crates 使えないから
ホント使いもんにならんわ

**デフォルトの名無しさん** · 2023/08/20(日) 19:47:42.13

じゃあGitHubのCodespacesでも使ってれば

**デフォルトの名無しさん** · 2023/08/20(日) 19:54:55.65

>>751
おすすめはしないけどやればやったになるはず
デバッグ環境があるかは知らないが

**デフォルトの名無しさん** · 2023/08/20(日) 19:58:02.59

>>753
それはpaizaが悪い
例えば>>712で意味のない比較をしているが
Python版はimport requestsと標準ライブラリではないものを使っている
つまりpaizaはPythonだと標準ライブラリ以外のライブラリも使える
同じようにRustでも標準ライブラリ以外を使えるようにpaizaが対応すれば解決

**デフォルトの名無しさん** · 2023/08/20(日) 20:00:15.86

>>747
これに即して測ってみては(1500x1500(f64)の生成、行列積、破棄の計測)
https://github.com/kostya/benchmarks#matmul

とりあえずnumpyとの比較とか
https://github.com/kostya/benchmarks/blob/master/matmul/matmul-numpy.py

**デフォルトの名無しさん** · 2023/08/20(日) 20:00:40.96

シミュレータなどは行列演算だけ高速化しても、全体の
高速化にはなら無い事が多い。

**デフォルトの名無しさん** · 2023/08/20(日) 20:04:56.81

>>757
手元のnumpyよりは少なくとも1000×1000の行列積は2倍から3倍速、10000×10000の行列積だと約5倍から10倍速い。手元よnumpyのバックエンドはIntelMKL。

**デフォルトの名無しさん** · 2023/08/20(日) 20:07:47.30

まだ、行列の対角化とか逆行列の計算は実装できてない。

**デフォルトの名無しさん** · 2023/08/20(日) 20:20:10.35

なんかnumpyが遅くない？

1000x1000でnumpy.dot(a, b)部分だけ測ったらこんな感じだったけど

0.006215572357177734
0.005822658538818359
0.005129098892211914
0.007399797439575195
0.011432886123657227
0.008414506912231445
0.009572029113769531
0.009091615676879883
0.008922100067138672
0.007265329360961914

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

def calc(n):
n = n // 2 * 2
a = build_matrix_np(n, 1.0)
b = build_matrix_np(n, 2.0)

start = time.time()
d = matmul(a, b)
end = time.time()
time_diff = end - start
print(time_diff)

return d[n // 2][n // 2]

**デフォルトの名無しさん** · 2023/08/20(日) 20:37:44.31

pipで入れたのでopenblasだと思うけど、こんな感じ

OMP_NUM_THREADS=1 python mutmul-numpy.py 1000
0.030291080474853516
0.029540538787841797
0.029771089553833008
0.02943873405456543
0.02980208396911621
0.03012990951538086
0.0300595760345459
0.030525922775268555
0.03243899345397949
0.02984023094177246

OMP_NUM_THREADS=8 python mutmul-numpy.py 1000
0.0073316097259521484
0.007174968719482422
0.007193326950073242
0.006682157516479492
0.006906747817993164
0.006983757019042969
0.007711172103881836
0.008562803268432617
0.007740497589111328
0.00671076774597168

>>759のnumpy計測がsingle threadになってたりしてる？

**デフォルトの名無しさん** · 2023/08/20(日) 22:44:27.85

>>763
シングルスレッドでの計測になってたぽい。この計測って最初のメモリ確保は含めてる？

**デフォルトの名無しさん** · 2023/08/21(月) 11:52:24.10

SIMDでの行列演算の最適化方法そのものとかさすがに関係なさ過ぎ。
RustとC++の違いに着目するならまだしも。

**デフォルトの名無しさん** · 2023/08/21(月) 14:56:42.48

>>764
>>762の通り行列積部分

JuliaをREPLで試した

function matgen(n, seed)
tmp = seed / n / n
[tmp * (i - j) * (i + j - 2) for i = 1:n, j = 1:n]
end
n = 1000
n = round(Int, n / 2) * 2
a = matgen(n, 1.0)
b = matgen(n, 2.0)
using BenchmarkTools
c=@btime(a*b)

OPENBLAS_NUM_THREADS=1 julia --optimize=3 --check-bounds=no
29.581 ms (2 allocations: 7.63 MiB)
OPENBLAS_NUM_THREADS=8 julia --optimize=3 --check-bounds=no
6.875 ms (2 allocations: 7.63 MiB)

juliaが行列積でnumpyの10倍遅いのが意外

**デフォルトの名無しさん** · 2023/08/21(月) 16:08:29.46

>>765
まあ、この板は実質雑談板なんで。アンチOSS君も大暴れしてますし大目にみてください。

**デフォルトの名無しさん** · 2023/08/21(月) 16:21:29.46

OSS関係無いわな。スレチ。別のところで好きなだけやればいい。

**デフォルトの名無しさん** · 2023/08/21(月) 16:41:35.26

OSSは関係大有りだと思う。

**デフォルトの名無しさん** · 2023/08/21(月) 16:46:18.02

Juliaとかは関係あるの？

**デフォルトの名無しさん** · 2023/08/21(月) 16:48:11.28

議論に関係あるかどうかの議論が必要ですね

**デフォルトの名無しさん** · 2023/08/21(月) 16:55:39.81

>>769
rustのエコシステムの話とかなら関係あるけど、OSS自体のメリデメ、とかそういう論点はスレチ。

**デフォルトの名無しさん** · 2023/08/21(月) 17:31:43.44

>>772
そんなことなくて、OSSであるということは、
非常に大きな影響を及ぼすので無視できない。

**デフォルトの名無しさん** · 2023/08/21(月) 17:54:01.38

>>773
それが通るなら少しでも擦れば何でもありになる。
影響の大小なんて本人が大きいと言い張れば大きいことになる。
スレタイ読んで関係あるかどうか常識で考えれば自明。もちろんあなたに言っても意味無いわけですけども。

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

>>774
そういうことじゃなくて、OSSは本質的に非常に大問題を
抱えてしまっているから、どうしようもない。

**デフォルトの名無しさん** · 2023/08/21(月) 18:33:57.42

>>775
そういうことじゃなくて、

じゃなくて、このスレそういうスレなんだよ。
マジで頭おかしいw

**デフォルトの名無しさん** · 2023/08/21(月) 18:35:45.82

Rustが失敗した原因の根底にOSSの問題があるって言いたいんじゃね

**デフォルトの名無しさん** · 2023/08/21(月) 19:07:31.63

「（すべての）OSSは本質的に非常に大問題を抱えている」→「Rustは本質的に非常に大問題を抱えている」
ってことだな
一応前提が正しければ結論も正しいけど前提の論証が大変そうだ

「一部のOSSは本質的に非常に大問題を抱えている」→「すべてのOSSは本質的に非常に大問題を抱えている」
みたいな論証魔法を決めれば何とかなるけどプログラマはこの類には耐性あるからな

「一部の」と「すべての」を削って後ろの修飾語を盛る程度だとまだ術式が足りなくて通らない

**デフォルトの名無しさん** · 2023/08/21(月) 19:20:23.58

どっちでもいいから、面白いことを書いてくれ

**デフォルトの名無しさん** · 2023/08/21(月) 19:32:31.36

>>775
boostは使わないの?

**デフォルトの名無しさん** · 2023/08/21(月) 19:53:38.34

矛盾を抱えているんだから論証とか無駄。
どんな結論でも導出できる。

**デフォルトの名無しさん** · 2023/08/21(月) 20:44:27.67

背理法の仮定を利用しなくても矛盾するなら、任意の結論を背理法で証明できる

だから「矛盾しているのはお前だけ」みたいな結論はむしろ出てこないんだよ
属人的な仮定を必要としないのだから全人類が矛盾する

**デフォルトの名無しさん** · 2023/08/21(月) 21:19:54.31

>>782
論理を語るのなら、まず共通の前提条件を全部出して合意取れよ。

前提条件より先に結論が出るとかありえないし、前提条件の合意が取れていないなら矛盾するから議論する意味がない。

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

>>778
おもしろい

**デフォルトの名無しさん** · 2023/08/21(月) 21:58:53.90

>>782
合意がなければ義務はないというのは正しい
議論には義務が必要不可欠というのは間違っている
強制力があるべきという合意がもしあれば論理ではなく物理的な戦争が始まる