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

**デフォルトの名無しさん** · 2023/06/30(金) 21:56:35.52

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

っていう雑談スレ。

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

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

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

>>306
俺の話は置いとけ。
Rustを作り始めた筆頭プログラマは、大学の専攻はバイオで
真菌を研究しており、真菌の生命力に見せられてRustの名は
真菌の一種から採ったんだそうだぞ。
そしてそのような工学とは縁もゆかりもない人が作った
言語を有りがたそうに崇拝しているのがRust信者なんだぞ。

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

Rustの速度の見積もりが間違っているのが前から謎だったが、
数学とは縁が無い人が作ったからだったんだな。

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

>>306
俺はそんなpopularな学科には行って無い。

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

>>307
まだ、スレッド間は試してない。
とりあえずArcとMutexが単スレの時にオーバーヘッドが出ないかが個人的に懸念だった。

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

>>304
しかし、OSSには「水源枯渇問題」が有る。
消費者の財布を水源に見立て、山の上流に置いて有る様に見立てる。
OSSが蔓延すれば、その水源が枯渇するのだ。

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

水源とは何か良く分からんが、OSSでアメリカの大手ITをぶっ潰せるような仕組みを作れば日本には大きな得がある。出遅れた日本にとれる選択肢は少ない。
ビットコインのような非中央集権型のシステムを日本はITの全分野で押し進めていくべき。

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

優秀でないから様々なオープンソースソフトウェアを使いこなせないのだろう
Rustのアンチ活動をしている人のレベルの低さを知った

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

>>310
大学では何やってたん？

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

情報系産業は資本代替性が高いとは言うが殆どそれは資本力勝負となりアメリカには勝てない
なので別の方法で勝負しないといけない
流石にここまでのビッグテック支配は居心地が悪い

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

>>316
技術と言うより金の問題になっている気がするな。
金で優秀な人や企業を吸収したり、あるいは、検索エンジン用や
AI用のスパコンみたいなものを持っていたり。
いまのITは大量のプログラマやデータセンターが無いと成り立たない様になってきている。

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

>>317
パブリッククラウドを国家が無償で日本国民に開放するべきだと思う。日本はアメリカの様に大規模な資本家がいないので政府主導で計算資源を国民に開放してくべきだと思う。

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

AIなんかも結局はぶん回し勝負ってことで電気エネルギーを如何に大量に安価に調達出来るかが勝負となってきている
なのでマイクロソフトやGoogleは核融合発電の研究開発に躍起になっている
資本さえあればなんとでもなる世界になってしまった

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

左翼がオープンソース化を進めた結果、ソフトウェアを個人で作って
売れる時代が終わってしをいました。

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

>>318
沢山の人が使うと一人当りの計算リソースが減ってしまって、
使い物にならなくなる。

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

ID:auRxfwEHは自分で優秀と言うくらいだから
少なくともドクター取ってるんやろね
あれだけ自分で言っててまさか学部生ってことはあるまい

でも
発言からはアカデミックな香りを感じさせないのよね
数学や工学のバックグラウンドが見えないと言うか
文系かまったく畑違いなとこから来てるのかな？

**デフォルトの名無しさん** · 2023/07/08(土) 17:10:00.07

NECや銀行とかでメインフレームを触ってた70代のおじいちゃんでしょ

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

なんか山に籠もって一人でPC触ってるアマチュアって感じなんだよ正直

仕事からも学問からも遠いっていうか
自分たった一人でおうちで夢見ながら喋ってるような
批判や競争や責任からすごく遠いところに引きこもってるような

**デフォルトの名無しさん** · 2023/07/08(土) 17:58:46.48

>>320
そもそもゼロコストで無限に複製できるものを
製造個数に比例してコストが掛かる有体物であるかのように
扱っているマネタイズ方法に無理がある
俺は価格が適正値に近づいただけだと思うね

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

急にどうした？
発狂してからに
支離滅裂で会話が成立してないぞ
まずは強いお薬を飲め

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

>>311
スレッド間じゃないなら最適化されちゃうよ

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

Rustのライフタイムの型注釈についてちょっと真面目に資料読んでみたいんだけど「こういう時困る、だからこうしよう」的な文章しか転がってない
ちゃんと論文レベルで解説してる文章とかないですかね？

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

ありませんね
次の患者さんどうぞー

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

>>328
現状の公式ドキュメントとしてはたぶんNLLのRFCが一番詳しいと思う

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

>>327
確認したことないからわからないけどSendしていないからといってそんな最適化するかな？

まずまったく異なる型のArcをRcへ変えてしまう無茶はしないはず
ではArcの中身のAtomicUsizeをusizeにしてしまう最適化をするだろうか
その両者の速度差はndarrayの計算覧ﾊと比べて微々ｂｽる誤差にすぎｂﾈい話だと思う
Mutexについても同様で最適化するとしたら丸ごと無くすことになるがそれは考えにくい

一方でスレッド間テストをすれば競合時のlockのwaitが起きるなどで少し遅くなる可能性はあるが
それはどのようにコードを書いても必須で避けられない正しい行為

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

>>330
そうなんですか？
探してみます
ともかく“ライフタイム注釈”って“コンパイラが決定(推論)できないライフタイムを注釈する必要がある”というものらしいけど、どんな時は推論できてどんな時は推論できないのかさっぱり分からない
普通のHindley–Milner (HM) type systemとかだと論文レベルで解説文書がネットに転がっててわかるんですけど、ライフタイム注釈についてはどんな範囲では推論が可能なのかとか資料がひとつも見つからない

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

日本の工学系は教授ですらIT技術の良し悪しを語る資格は無いのに。

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

このスレは各言語の特徴的なキーワードだけを参考にしている。
どっちが優れているとかどっちがゴミだとかという話は全く参考にならない。

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

>>332
論文レベルじゃないと理解できないのは困りものですね

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

>>332
lifetime elisionは別に推論じゃないぞ
borrowckとしてはライフタイムは必ず事前に注釈されなくてはならない
一部のよくあるパターンで省略を許可する、人間のためのルールがelision rules

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

Rustについて安全であるということだけを切り取って議論しているのは、現場も現実も知らない阿呆

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

>>332
考え方が逆
ライフタイム注釈はコンパイラにとって常に必要
だからライフタイム注釈するのが基本しかしそれを省略することができる状況が多々あって
その省略された時にコンパイラが省略を補う規則が定められている
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#lifetime-elision
lifetime elision rules
The first rule is that
The second rule is that
The third rule is that

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

>>337
それ。

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

>>332
推論せんよ
だから自分で書く必要がある

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

ここで説明しても無駄だよ
彼は論文レベルじゃないと理解できないんだから

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

みなさまありがとうございます
ちょっと私まだ疑問が解決してないです
私の認識書いてみます
私の認識だとrustの“ライフタイム”はコンパイラが確保したメモリを解放するタイミングを決定するために必須のものだと考えています
何故なら効率のためにrustは複数の参照が同じオブジェクトを参照する事を許す“参照の貸与”のシステムを導入してるからです
なので所有権を持ちその参照が切れる前に全ての“貸与”していた全ての参照の“ライフタイム”が切れていなければなりません
コンパイラは貸し出された参照のライフタイムが所有権を持つ参照のライフタイムより長いものが有ればそれを検出し、貸借規定違反としてコンパイル時にそれを検出する事でダングリング参照の発生を防ぐシステムだと認識してます
その“参照のライフタイム”はユーザーが宣言するものではなくて本来ならコンパイラが自動的に拾うべきものだと思ってます
何故ならばrustの参照のライフタイムが「プログラマが好き勝手に自由に設定していい」ものなら結局それは“コンパイラがダングリング参照の発生を未然に検出する”システムになど到底ならないからです
少なくともユーザーが“この関数の返り値のライフタイムは引数のこのライフタイム以前に切れる”と宣言してもその宣言の妥当性をコンパイラが検証しないなら意味がありません、もちろん検証すると思います、具体的には返り値として用意された値のライフタイムがその値を作成した右辺値に現れる参照のライフタイムより長ければその時点で不当なライフタイムの宣言を検出できてそれでコンパイラは不適切なライフタイム注釈を検出できると思います
分からないのはそれなら結局コンパイラはライフタイムをやろうと思えば自分で推論できるのではないかという事です、実際rustの初期のコンパイラでは必須だったライフタイム注釈はいくつかの推論可能なケースでは省略可能になっているようです
じゃあいつダメなのか？いつどんな時なら推論がうまくいかないのかの基本的な理論がよく分からないんです

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

>>342
>私の認識だとrustの“ライフタイム”はコンパイラが確保したメモリを解放するタイミングを決定するために必須のものだと考えています

ちゃうよ

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

長文しか掛けんのかこいつは

全部関数など使わないで書けばライフタイム自体は一目瞭然
だが不注意な人はブロックから抜けて死んでる物を参照して使おうとする

それをコンパイラが阻止する
ライフタイムは基本的はこれだけ

これが前段階

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

多分GC言語しか使ったことがないのだろう
参照がある限り値が生き続けるというぬるま湯に浸かってるから理解できない

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

すいません、私が知りたい事説明するのにこれ以上短くできませんでした

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

それが途中で関数が使われてると戻り値のライフタイムがわからなくなる
入力した引数と戻り値のライフタイムが関連付けられるならその様にしなければならない

仮に　a とｂが与えられて戻り値がどちらかになるのであれば

「寿命が短い方を共通の寿命」と考えることが必要になる
そうしないと死んでる奴を参照しちゃうから

それを元にライフタイムの範囲を判定してはみ出てたらコンパイルエラーにする

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

発想を逆転させな？
「変数が生きている間しか参照は存在できない」

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

>>342
コンパイラはライフタイム注釈の推論をしていない
>>338に公式ソースを示したから読もう！
ライフタイム注釈は原則としてプログラマーが与えるべきもの
ただし例えば1対1に対応しているような、与えなくても自明な場合に省略できる
そして省略されている時にコンパイラが機械的に補うルールが定められている
結果的にプログラムは全てライフタイム注釈されていることになる

つまりコンパイラが推論することはなく
コンパイラがすることは省略を機械的に補うことと
ライフタイム注釈がすべて揃ったプログラムに対してのジャッジ

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

参照というのは実体がないと生きられないの
関数の引数や戻り値が参照だけだと実体がどれだけ生きてるかわからんでしょ？

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

ライフタイム自体はコードが書かれた時点で決まってる
それがおかしくないか判定するときのヒントがライフタイム注釈

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

>>349
はい、rustは型推論をしないのは知ってます
しかしそれが何故なのか分からないんです
例えばHaskellなら一才の型注釈は省略が可能です
全ての型は全てコンパイラによって推論され、型注釈を入れてコンパイルできるプログラムは型注釈を全消ししても(ただし効率のためにmtoplevel monomorphism restrictionというシステムが邪魔してくれますけどそれ外せば)必ずコンパイラが正しく推論してコンパイルしてくれます、その推論メカニズムの理論的根拠は論文として寄稿されネットにいくらでも転がってます
知りたいのはRustのライフタイム注釈は推論して省略可能だけどいつもいつも省略可能なわけではないのは、
・そもそもいつでも推論可能なわけではないので基本宣言させる、コンパイラが推論可能な限られたケースでは可能としている
・いつでも推論可能(私にはそう思える)のだけど効率を考えてそうしない(Haskell の toplevel monomorphic restrictionと同じように)
のどっちなんだろうと
そしてその話をtegulationに求めないのは必ずしもregulationは最新の研究を反映しているわけではないからです
つまり“現在のregulatinでは推論しない”という現状が必ずしも“そもそも推論などできない”を必ずしも意味しないからです
私ちょっとプログラミング言語論齧ってた事がありましてその辺の理論的背景どうなってるのかちょっと知りたいもので

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

お前のお気持ち表明はいらん

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

>>352
Rustは型推論します
非常に便利です

ただし間違った型推論の連鎖を起こす混乱やニワタマ問題などを避けるために
関数の引数値と返値については(ジェネリックを除き)
敢えてプログラマーに明確に型宣言させています
つまり型推論が可能な領域はもっと広いけど
意図的にRustは一定の範囲内に抑えていることになります

ライフタイム注釈についても同様で
推論可能な領域は確かに存在するけれど
意図的にRustは推論をせずに機械的な省略補完ルールの適用のみに抑えていることになります

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

そして明確に型宣言することが基本である関数の引数値と返値についても
ジェネリックな型とそのトレイト境界による制限を用いることで個別の型宣言をさけることができるし
さらに型宣言の位置に「impl トレイト名」という形で静的なopaqueな型指定をしたり
「dyn トレイト名」という形で動的な型指定をすることで
幅広い型を受け付ける関数を書くこともできたり
複雑な型を返す時にそれを明示せずに済むなど
Rustでは型推論とは別のアプローチで利便性と可読性の向上に役立っています

**デフォルトの名無しさん** · 2023/07/08(土) 21:00:55.19

ChatGPTみたいなレスだな…

**デフォルトの名無しさん** · 2023/07/08(土) 21:01:52.49

>>354
そうですね
一般的には“コンパイラにできないわけではない”場合でもユーザーにあえて“注釈をつけさせる”事が非常に便利な場合があります
多分Rustのライフタイム注釈もそれだと思ってはいるんですけど、ほんとにそれで間違い無いのか文書でまとめられたものがないか確認したいんです
HaskellやRustの型推論システムはもう論文でいくつか読んだ事があるのでそのメカニズムもまぁわかります
Rustのライフタイム注釈の場合も多分同じ事ができそうだとは思ってるんですけど敢えてか何故かやってない、それが“できそう”と思ってる自分の勘違いなのか、やはり“できるけど敢えてやってない”のか、あるいは現時点の最新研究でどこまではできることが確認されているのかとかその辺の情報持ってる人いないかなと

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

いやいや
関数を使う人間側が推論不可だろ

**デフォルトの名無しさん** · 2023/07/08(土) 22:06:00.43

NGでスッキリ

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

ググったら理由が出てきた

基本的に関数シグネチャが変わるような事態を避けたいようだ
関数内部を変更したら推論されるライフタイムを含んだシグネチャも変わってしまう事態が起こりうる

変更で呼び出した側であちこちにボコボココンパイルエラーが出るのはプログラマ的にうれしくないので避けてる
呼び出し規約は人間が決めてそれをコードを書く側が守ると言うこと

**デフォルトの名無しさん** · 2023/07/08(土) 22:12:52.52

Rustは関数単位で色んなチェックしてるけど
その関数が「どこでどう使われているか」を材料にして検証とか推論はしないし
最初からそんなつもりはないと思う

関数を全部インライン展開して１つのmain関数にできれば理論的には全部推論できそうだけど
関数ポインタとかdyn traitを使った動的な呼び出しが絡むと多分無理
Haskellレベルの推論は動的な呼び出しが存在しない参照透過性？が前提にあるはず

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

推論されたライフタイムを含むシグネチャと人間側が思ってる必要なシグネチャ（ライフタイム）と違うことが起こりうる

例えば他人が作ったライブラリのコードが変わって自分のところに波及してきたら嫌だろ？
従来のはそのままで別のシグネチャの関数を作れと思うだろ？

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

イヤ、ライふタイム注釈の推論に“使われる場所”まで検証する必要はないですよ
関数の返り値を作成してる右辺値を調べればそれで十分だと思います
その単位で返り値のライフタイム注釈が決定されれは、返り値が解放後に参照されるエラーが発生するか否かはその返り値を利用する呼び出し側関数のコンパイル時点で検出できると思います

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

>>332
論文を探す前にチュートリアルを読みましょう

**デフォルトの名無しさん** · 2023/07/08(土) 22:24:17.70

せっかくググって答えを見つけてきたのにガン無視されてる…

**デフォルトの名無しさん** · 2023/07/08(土) 22:24:38.70

いい感じにゴミ集積所になりつつあるな

**デフォルトの名無しさん** · 2023/07/08(土) 22:27:06.38

ゴミクズ荒らすなよ

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

最初は実質ライフタイムの使い方がわからないと言うのが徐々に軌道修正されて変なところまでたどり着いた

**デフォルトの名無しさん** · 2023/07/08(土) 22:33:04.65

>>382
コンパイラが推論する型と人間が想定する型が違うなんてもちろん日常茶飯事ですね
Haskell使ってて:tで推論した型表示させたら「うおーなんじゃこりゃ」と思うことなんてしょっちゅうです
コンパイラは右辺値(haskellでは表現)が提供可能な“最大に一般的な型”を与えようとします、そしてその「提供可能な最大の多層型」の中に関数の利用者が要求する利用可能ないずれかの型が含まれるかどうかを確認して可能ならその単相型を導出し、無理ならコンパイルエラーを吐きます
そして同じメカニズムは多分Rustのライフタイム注釈でも可能なはずです
しかしいくつか当たったRustのライフタイム注釈の解説文書のなかにはあたかも「それは不可能なのでプログラマに注釈をつけさせる」という類の説明がついてることが多いんです
それ見てホントかと、しかもその手の文書についてる例では明らかに推論可能でそれくらいコンパイラが自分でできるやろというくだらない作業をプログラマに強いてるだけの例がついてる事が多いんですよ
それがRustの“仕様”であるならそれはそれでいいんですけど、それを強いる理由が「推論することが不可能だから」と説明してるのがおかしいなと、何か自分の気付いてない勘違いしてるのかなと

**デフォルトの名無しさん** · 2023/07/08(土) 22:34:33.60

>>369
コンパイラから外されて実装してないから不可能だろ
それも事実を表してる

**デフォルトの名無しさん** · 2023/07/08(土) 22:34:40.18

わかったから消えろ

**デフォルトの名無しさん** · 2023/07/08(土) 22:38:51.77

完全に推論可能かは知らないが実害があるのでそもそも実装されていない

ただあからさまな場合は省略可能

コンパイラも楽だろ
戻り値のライフタイム覚えておいて型を返す場所でチェックするだけだし

**デフォルトの名無しさん** · 2023/07/08(土) 22:51:32.65

>>372
そうですね、多分コンパイラが楽だからがホントの理由な気がします
推論するには最低限その関数の関数定義が終了する時点まで読まなければならないですからね
しかし実際には関数の終わりの時点まで読んだ段階で完全に決定してその1回目の読み、ワンバス目で終わる気はします、少なくともコンパイラの世界の暗黙の了解「線形オーダーで解決しなくてはいけない」はクリアするとは思います、(勘ですけど)
まぁそれでも「必ず宣言するように、異論は認めない」が仕様ならそれはそれで結構なんですけどそれを「できないから宣言するしかないんです」という説明はある程度以上を勉強するつもりの人が読むと多分混乱招くと思うんですよ
初学者が余計な気を回さないように「できない、信じろ、なので宣言しろ」は初学者向けの説明でありかなとは思わないではないんですけどね
そこでちゃんとした論文ないもんかと

**デフォルトの名無しさん** · 2023/07/08(土) 22:58:05.15

もしかして、クロージャなら式から推論してるのかな
関数のシグネチャはフルで書かなきゃいけないってだけで

**デフォルトの名無しさん** · 2023/07/08(土) 23:59:50.01

クロージャは型推論してくれるからそういう用途に使える
集合としてみてもfnよりFnを満たす集合の方が大きい
逆にクロージャでも型指定を要求されることもある

**デフォルトの名無しさん** · 2023/07/09(日) 02:18:11.28

いずれにせよ、Rustは、自由と民主主義をベースとする西側諸国
の価値観には合わず、中国と同じ社会主義的な東側諸国の価値観
に合っている。この言語が成功することはIT産業が壊滅状態になる
ことを意味する。

**デフォルトの名無しさん** · 2023/07/09(日) 02:21:16.31

自分達の作った言語を普及させるためには、無料にして、他の業者
がどれだけ迷惑を被っても構わないというスタンスをとる。
このことは、世界の中心でありもっとも進んだ国であるところの
中国の価値観を広めるためには、人民の犠牲もいとわない、
他国がどれだけ苦しんでも構わない、むしろ歓迎する、などという
中国のスタンスと共通する。

**デフォルトの名無しさん** · 2023/07/09(日) 02:24:03.48

もっとも優れた政治経済思想であると事の中国流社会主義を
世界に広めるためには、どんな犠牲もいとわず、どんな
人権侵害も環境破壊もいとわず、経済ルールを無視して独自
ルールを徹底し、言論統制し本当の情報を流さない、
という中国のスタンスと、Rust信者達が行っているスタンスは
そっくりである。

**デフォルトの名無しさん** · 2023/07/09(日) 02:26:49.94

中国人は洗脳の結果、自分達が世界最高の政治体制を持つ偉大な
国家であり、その思想と政治体制を世界中に教えてあげなければ
ならないと思っている。
そしてアジアの最高の先進国は中国であり、日本より上回っている
と勝手に思い込んでいる。
この状況とRust信者の脳内心理はそっくりである。

**デフォルトの名無しさん** · 2023/07/09(日) 04:44:46.78

>>376
IT産業の壊滅とか最高じゃん。一番損をするのは覇権国のアメリカ、一番得するのは出遅れた日本だからねぇ。
ちなみにOSSとITの民主化は中国などのレッドチームを追い詰めることに繋がると思うぞ。お得意の世論統制が難しくなるからね。

**デフォルトの名無しさん** · 2023/07/09(日) 07:41:46.99

>>376
お前誰からも必要とされてないから消えて

**デフォルトの名無しさん** · 2023/07/09(日) 07:46:09.21

>>381
可哀想だからそんなこと言ってあげるな
病気なんだから
居場所はどこにもないんだよ

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

マシな流れからまたクソな流れになってきそうだな

**デフォルトの名無しさん** · 2023/07/09(日) 09:19:07.63

RustはDynamicRustみたいな感じのRustコンパイラ上で動くスクリプト言語が有っても面白いかもな。

**デフォルトの名無しさん** · 2023/07/09(日) 11:03:32.10

頭のおかしいネトウヨがアンチrust側で良かった

**デフォルトの名無しさん** · 2023/07/09(日) 11:23:19.56

>>385
ネトウヨって何？
ここはRustとC,C++の比較及びその他プログラミング系の話をする板であり君の様な差別主義者は別の板に行きなよ。

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

>>379
>この状況とRust信者の脳内心理はそっくりである。
お前さんの言動は統合失調症の患者さんとそっくりだよ

**デフォルトの名無しさん** · 2023/07/09(日) 13:41:10.77

効きすぎだろw

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

Rustなら失敗しなかったと思う割とマジで
https://www.youtube.com/watch?v=XDy0dqZrbN4

**デフォルトの名無しさん** · 2023/07/09(日) 14:21:39.84

だれもRustの使用を強制してないのに強制されてると思い込んでるあたりが危険だな…

どこかの大臣が「Rustの利便性向上のためにC++コンパイラを廃止します」とか言い出したら騒いでもいいけど

**デフォルトの名無しさん** · 2023/07/09(日) 14:30:11.62

>>337
Rustが安全であるという考え方が最も危険である

**デフォルトの名無しさん** · 2023/07/09(日) 15:40:54.31

>>308
それが本当なら水虫言語じゃん

**デフォルトの名無しさん** · 2023/07/09(日) 15:57:49.89

糖質だから仕方ない
誰からも必要とされてないことすら気がつかないのだから

**デフォルトの名無しさん** · 2023/07/09(日) 16:23:35.82

RustがC/C++に似ているとか、構文が便利だとか本気で思っている
方が統合失調症だ。病院で見てもらえ。

**デフォルトの名無しさん** · 2023/07/09(日) 18:47:10.60

Rustが爆発的に飛躍するには何が足りないの？

**デフォルトの名無しさん** · 2023/07/09(日) 19:01:36.68

学習コスト低減、ライブラリ作成支援
何よりもRustの案件・求人の増加

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

誰からも必要とされてない人
今日もよく喋るな

**デフォルトの名無しさん** · 2023/07/09(日) 19:43:24.19

せいぜい、人から必要とされまくって楽しい人生を謳歌しろよ。
ww

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

行列積ってマルチスレッドで実装すべき？それとも、キャッシュやコピーを減らすためにシングルスレッドの方が良いのかな？

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

GPUに投げるべき

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

真面目な話するとプロファイル取ってサイズで分岐すればいいんじゃないすかね

**デフォルトの名無しさん** · 2023/07/09(日) 21:34:02.14

>>399
parallel=trueみたいなオプションをどこかに書けばスレッド使うようにする

**デフォルトの名無しさん** · 2023/07/09(日) 21:55:27.03

>>400
GPUを使った並列演算処理を提供するRustのクレートで良いのは何？できれば、GPUのデバイスによらずに操作が抽象化されてるものが良いな。

**デフォルトの名無しさん** · 2023/07/09(日) 23:36:02.19

四次元ポケットがあるかのような話だな…

**デフォルトの名無しさん** · 2023/07/09(日) 23:43:54.14

C++にはあるんじゃね？

**デフォルトの名無しさん** · 2023/07/09(日) 23:57:17.50

rust-gpuとかいうクレートはどうなの？これはcudaがないと動作しない感じ？

**デフォルトの名無しさん** · 2023/07/10(月) 00:29:46.98

CUDAとかOpenCLとか書かれているから、CUDAでなくても動くんじゃね？