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

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

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

っていう雑談スレ。

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

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

**デフォルトの名無しさん** · 2023/06/01(木) 09:22:18.21

どうせまたdangling pointerが作れちゃうって話を長文で書くんだろ
もういいよ

**デフォルトの名無しさん** · 2023/06/01(木) 09:37:25.18

ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない

**デフォルトの名無しさん** · 2023/06/01(木) 10:16:34.79

>>677
草
入門書の最初のほうに書いてるような内容を
ひたすら繰り返し演説するのが好きなんよ彼はｗ

**デフォルトの名無しさん** · 2023/06/01(木) 12:18:27.95

入門書の最初のほうに書いてるような内容を
入門書も読まずに聞いちゃう676みたいな初心者がいるからしゃーないやん

**デフォルトの名無しさん** · 2023/06/01(木) 14:35:57.29

RefCellからget_mut()したらどこかでget()したRefが生きてたせいでpanicしたということがあって
そのときはデバッガのお世話になって問題のget()してる場所を探すことができたんだが
実行デバッグから解放されたらしい>>672はもっといい方法を知っているんだろうか

**デフォルトの名無しさん** · 2023/06/01(木) 14:43:24.51

他スレッドに持ち出さない保証ができればどうだ

**デフォルトの名無しさん** · 2023/06/01(木) 14:43:52.25

あら、IDかわってる >>682は>>676

**681** · 2023/06/01(木) 14:52:20.51

×get()/get_mut()
○borrow()/borrow_mut()
でした

**デフォルトの名無しさん** · 2023/06/01(木) 15:32:59.04

clippyとかで多少拾えるだろうけど実行時チェックがpanicにならないようにするのはプログラマの責任

デバッグから解放されるなんて話は夢物語だが
デバッグしないとborrowとborrow_mutのlifetimeが分からない状態は見直した方が良い

**デフォルトの名無しさん** · 2023/06/01(木) 15:54:48.22

English translation:

No.

**デフォルトの名無しさん** · 2023/06/01(木) 16:50:46.87

>>678
本当にそんな不自然な状況に頻繁に出くわして困ってるの?
設計おかしいんじゃないの?

**デフォルトの名無しさん** · 2023/06/01(木) 21:02:26.16

常に問題なく設計できる人はRustでライフタイムを満たすことも容易
複雑になると混乱しうる場合はC++で穴の可能性が残るがRustならライフタイムのコンパイルエラーが検出され助かる
実際にMicrosoftやGoogleがその穴の頻出でセキュリティ脆弱性も招いていたと判断してライフタイムを用いるRustへ移行中

**デフォルトの名無しさん** · 2023/06/01(木) 21:07:45.31

>>688
>>678
>ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない
スマポ返せばええだけちゃうの?

**デフォルトの名無しさん** · 2023/06/01(木) 21:10:07.38

>>688
>実際にMicrosoftやGoogleがその穴の頻出でセキュリティ脆弱性も招いていたと判断してライフタイムを用いるRustへ移行中
社内の好き者が試してるだけじゃないのん?
全ソースの何%くらいなんかな?
移行って書くと新規は全て感じがするがそれ誇大広告じゃ?

**デフォルトの名無しさん** · 2023/06/01(木) 21:23:32.48

>>689
スマポunique_ptrはカバーできる範囲が狭い
スタック上のインスタンスに対しては使えないためヒープ上のインスタンスと共通に扱えなくなる
部分領域に対しての扱いも同様

**デフォルトの名無しさん** · 2023/06/01(木) 21:33:58.30

5/30の一連の流れは何事も無かったかのように平常運行に戻ってるの、ふてえ野郎だぜ

**デフォルトの名無しさん** · 2023/06/01(木) 21:39:32.47

Rust公式と自分の意見が違っているのが分かった瞬間急にｽﾝ……ってフェードアウトするの最高にダサかったよ

**デフォルトの名無しさん** · 2023/06/01(木) 21:53:38.87

>>691
C++でスタックのポインタ返しちゃいかんだろw
論外

**デフォルトの名無しさん** · 2023/06/01(木) 21:54:37.80

FirefoxがプチフリするのはRustのせいじゃないのか？

**デフォルトの名無しさん** · 2023/06/01(木) 22:03:56.60

>>694
スタック領域を指すポインタを返せないと不便で効率が悪くなるぞ

**デフォルトの名無しさん** · 2023/06/01(木) 22:14:49.71

>>696
は? C++で?

**デフォルトの名無しさん** · 2023/06/01(木) 22:21:04.58

未だに未定義動作という不発弾を検出できない欠陥言語

**デフォルトの名無しさん** · 2023/06/01(木) 22:29:25.95

スタック上を指すポインタを常に安全に返せるようになると
ヒープを使わずにスタック上だけで済ませられるケースが生じる
それは高速化に寄与する

**デフォルトの名無しさん** · 2023/06/01(木) 22:41:03.06

そもそもC++は関数でスタックのポインタを返してはいけない
それを
>>678
>ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない
ってのは支離滅裂な議論

**デフォルトの名無しさん** · 2023/06/01(木) 22:43:29.65

C/C++では確かに以下の関数をエラーなく書けるが（警告は出るけどね）
これにエラーを出すことにどれだけの意味があるかな?

int *fun ()
{
int a;
return &a;
}

**デフォルトの名無しさん** · 2023/06/01(木) 22:50:50.58

Rustはライフタイムがあるからそういう返してはいけないポインタ(参照)はコンパイルエラーとなるし
たとえスタック領域を指すポインタであっても安全に返せる時はコンパイルが通って使えるね

**デフォルトの名無しさん** · 2023/06/01(木) 23:02:08.29

>>702
>Rustはライフタイムがあるからそういう返してはいけないポインタ(参照)はコンパイルエラーとなるし
C/C++で>>678のような間違いする人はいないから全く意味がないんだよ
頓珍漢なことを書かぬように
批判の前にはそれなりに批判対象も勉強し給え
（念の為に書いておくがライフタイムを否定するものではない）

**デフォルトの名無しさん** · 2023/06/01(木) 23:11:12.73

>>694
> C++でスタックのポインタ返しちゃいかんだろw
> 論外

普通に返すぞ

**デフォルトの名無しさん** · 2023/06/01(木) 23:30:58.01

>>704
は? どんなコード?

**デフォルトの名無しさん** · 2023/06/01(木) 23:34:30.43

>>703
その単純な例で間違える人はいないけど、
複雑に込み入った例で返してもよいポインタと返してはいけないポインタの判断を間違えることは起き得る
その発生がレアで運用時に発覚となると悲惨だ

**デフォルトの名無しさん** · 2023/06/01(木) 23:43:15.74

>>706
>複雑に込み入った例で返してもよいポインタと返してはいけないポインタの判断を間違えることは起き得る
絶対に間違えないと断じれる
ライフポイントが役立つのはそんなところじゃない

**デフォルトの名無しさん** · 2023/06/01(木) 23:43:54.39

-ライフポイント
+ライフタイム

**デフォルトの名無しさん** · 2023/06/01(木) 23:51:59.43

見事に単発ばっかりだけど
複おじはこの構図を「顔を真っ赤にしたC++信者に群がる勇敢なRust戦士たち」と見てもらえると本気で思っているのかな？

**デフォルトの名無しさん** · 2023/06/01(木) 23:53:45.26

>>707
ライフタイムを指定する関数や構造体を書いたことないのか

**デフォルトの名無しさん** · 2023/06/01(木) 23:54:57.04

自演じゃないならこっちでやってみてよ
ちょうどいい題材

C/C++のソースをRustへ全力で置き換えるスレ
https://mevius.5ch.net/test/read.cgi/tech/1681777958/

**デフォルトの名無しさん** · 2023/06/01(木) 23:58:48.29

>>700
そんな制限はない
C++でもスタックのポインタを返してもよい

**デフォルトの名無しさん** · 2023/06/02(金) 00:08:14.98

>>712
どんなコードを言ってるのか分からんので書いてみて
もちろん>>701のようにコンパイルは通るけど
関数脱したら消滅するスタックのポインタ返して
どう実用するのかスゲー興味ある

**デフォルトの名無しさん** · 2023/06/02(金) 00:09:53.77

>>710
俺はRustは書かないよ
それともその「ライフタイムを指定する関数や構造体」ってのは
C++の話しかい?
よく分からんので簡単なコードで示してみて

**デフォルトの名無しさん** · 2023/06/02(金) 00:11:47.32

アドレス値を返すだけで読み書きしないんじゃね

**デフォルトの名無しさん** · 2023/06/02(金) 00:12:42.40

Rustを書かないやつが連投して暴れてるのかｗ
通りで無知なわけだ

**デフォルトの名無しさん** · 2023/06/02(金) 00:48:31.36

>>713
複おじはバカだがお前もお前で「スタック」が「現在の関数のスタックフレーム」以外も指すことにいい加減気付け

**デフォルトの名無しさん** · 2023/06/02(金) 00:54:45.14

スタック領域のポインタ返すってstatic変数のこと言ってんの？

**デフォルトの名無しさん** · 2023/06/02(金) 01:14:58.53

>>716
C++に関して頓珍漢なことを書いていたら否定している
知らんことに関してはコメントしていない

**デフォルトの名無しさん** · 2023/06/02(金) 01:16:10.14

>>717
「現在の関数のスタックフレーム」以外のスタックって何なん?
知らんので教えて

**デフォルトの名無しさん** · 2023/06/02(金) 01:17:36.57

>>718
さすがに違うと思う

**デフォルトの名無しさん** · 2023/06/02(金) 01:58:01.64

スタックからアドレスを取得して、それをスマポにしないのは、その段階でunsafeだろ

**デフォルトの名無しさん** · 2023/06/02(金) 02:03:25.21

>>722
スタックのインスタンスのアドレスはスマポには入らん
C++では参照型を使う
Rust的にはたぶんunsafeかな?

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

>>720
典型的には呼び出し元のスタックフレーム、呼び出し元の呼び出し元のスタックフレーム、呼び出し元の……以下略

具体例で言うなら、strchr()にスタック上の文字列を渡したら帰ってくるのはスタックを指すポインタでしょうが
strchrのスタックフレームとして積まれた領域じゃなきゃ別にスタックを指すポインタを返すこと自体に問題はないのよ
分かったらもう黙っててくれ、例の自演君がつけあがるだけだから

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

>>723
Rustの参照はsafe
常に有効な領域を指す

**デフォルトの名無しさん** · 2023/06/02(金) 02:31:49.11

>>724
なるほど関数呼び出し元のスタックね
しかし話の起点>>678に書かれているのは呼び出し先関数が返そうとしている
参照（ポインタ）の有効性をどう保証するかという話
一方で呼び出し元のスタックの有効性を保証すべきは呼び出し元で
呼び出し先が感知すべき内容ではないと思うが?

**デフォルトの名無しさん** · 2023/06/02(金) 02:34:40.83

>>725
参照のダングリングなんて起こらないけどね
ただしマルチスレッドだと起こり得るのでshared_ptrで指す
このくらいのことを出来ない輩がいるので
Rustの存在意義がある

**デフォルトの名無しさん** · 2023/06/02(金) 02:38:30.45

>>722
C++はそれをすることができない
スマポに格納できるのはヒープ領域を指すポインタのみ
Rustはスタック領域でもヒープ領域でも所有権を持つがC++はスタック領域で持てない

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

>>728
参照型で受ければ良いのでは？

**デフォルトの名無しさん** · 2023/06/02(金) 02:44:59.65

>>727
C++の参照は気をつけないとダングリングになる
この記事の二つの例は興味深い
https://qiita.com/sumomoneko/items/58358eb8bcc8b70a481b

**デフォルトの名無しさん** · 2023/06/02(金) 07:24:04.28

rvalueとlvalueを理解しないものにC++は無理
Javaを使いなさい

**デフォルトの名無しさん** · 2023/06/02(金) 07:42:10.08

やだことわる、Oracle怖い

**デフォルトの名無しさん** · 2023/06/02(金) 12:13:39.36

>690
unsafe {} だらけだよ！

**デフォルトの名無しさん** · 2023/06/02(金) 13:57:04.29

>>730
面白いけどtrivialだと思うね
しかしtrivialなので嵌るのかもしれない

**デフォルトの名無しさん** · 2023/06/02(金) 19:56:41.94

Win32APIはコールバックが多用されてて定型的な処理の1つなのにRustでは普通に書く方法がいまだにないように見えるのだが
こんなんでC++と張り合おうとするなよー

**デフォルトの名無しさん** · 2023/06/02(金) 20:35:22.54

安全をうたうならJavaと張り合いなさい
最高速チャレンジに危険は付き物です

**デフォルトの名無しさん** · 2023/06/02(金) 20:36:54.02

素人でもC++に匹敵する速度が出せます
もう熟練は必要ありません
↑
こんなこと言うやつは詐欺師
財布なくなってないか？
気をつけろ

**デフォルトの名無しさん** · 2023/06/02(金) 20:41:55.28

>>735
https://github.com/microsoft/windows-rs/tree/master/crates/samples/

**デフォルトの名無しさん** · 2023/06/02(金) 20:47:11.96

結局常に迫りくるソフトウェア危機に常に対応していかないと
言語の発展は青天井になる

**デフォルトの名無しさん** · 2023/06/02(金) 21:16:22.90

>>738
そんなリンク貼って恥ずかしくならないの？ってことなんだけど…

**デフォルトの名無しさん** · 2023/06/02(金) 22:03:25.91

Microsoft公式を恥ずかしいって？

**デフォルトの名無しさん** · 2023/06/02(金) 22:28:15.18

自分が作ったわけでもないものを貼ってドヤってるのは恥ずかしいかもしれない

**デフォルトの名無しさん** · 2023/06/02(金) 22:41:24.04

公式サンプルすら見ずに文句を言ってた>>735が恥ずかしい

**デフォルトの名無しさん** · 2023/06/02(金) 22:59:27.31

調べもせず無知を晒す奴が一番恥ずかしい

**デフォルトの名無しさん** · 2023/06/02(金) 23:09:18.71

自演バレてないと思って懲りずに単発続けてるのはだいぶ恥ずかしいよ

**デフォルトの名無しさん** · 2023/06/02(金) 23:21:33.50

俺が気に入らないから自演ですね、わかります

**デフォルトの名無しさん** · 2023/06/02(金) 23:31:47.49

どっちかっていうと>>743が「ぽい」なと思っててお前はどうでもいいと思ってたんだけどな

調べもせず無知を晒す奴と言えば
GIGAZINEがねつ造したリンクに騙されて原文を調べずもせずに
Rustの将来の可能性を示してくれるかもしれなかった人を叩いてたのは恥ずかしかったねw

**デフォルトの名無しさん** · 2023/06/03(土) 01:39:42.55

cargoとかも嫌いなシステム。
パッケージシステムが嫌い。
メンドクサイ。

**デフォルトの名無しさん** · 2023/06/03(土) 01:50:29.03

今や手動でやる言語はないだろ

**デフォルトの名無しさん** · 2023/06/03(土) 01:53:30.53

毎回変化するのが嫌なんですよ。
ダウンロードするバイト数も予め分かりませんし、インストールされるバージョンも
分かりませんし。
単に何かが使いたいだけなのに、使う段階になって勝手にネットからダウンロード
が始まり、コマンドが使える様になるまでに何十分も一時間も掛かることがあります。

**デフォルトの名無しさん** · 2023/06/03(土) 01:57:22.81

勝手にダウンロードされることで、PC内に存在する色々なもののバージョンが
めちゃくちゃになります。
複雑すぎてメモすることも出来ません。
以前動いていたのに、今度やってみたら動かなくなってる。
Windowsだけだとそういうことはなかった。Linux文化(?)やオープンソース
文化なのか、よく分かりませんけど、もう、ストレージがいくら有っても
足りませんし、毎回毎回、動作不良を起こし、インストールし直す必要が
有ります。それでオープンソースは、サーバー以外では普及しないのかも。
PC内に同じファイル名のものが無数に存在してます。
クローズド文化ではそういうことは有りませんでした。

**デフォルトの名無しさん** · 2023/06/03(土) 02:16:53.48

>>750
インストールされるバージョンは自分で指定するから全くわからないってことはない
(孫のバージョンは子が指定しているから気にする必要はない)
ちゃんと直接使うクレートのバージョン指定をしているか？

>>751
以前動いていたのに今度やってみたら動かなくなってる、は通常ありえない
もちろん後方互換性のないバージョンを使えば動かなくなるのは当たり前だ
ちゃんと直接使うクレートのバージョン指定をしているか？

**デフォルトの名無しさん** · 2023/06/03(土) 02:17:53.45

>>751
ワロタ
好き嫌い言う前に基礎を学ぼう

**デフォルトの名無しさん** · 2023/06/03(土) 02:22:55.48

意見の古臭さと文章の幼さのギャップが凄い
タイムリーパーかな

**デフォルトの名無しさん** · 2023/06/03(土) 02:27:40.16

それにRustはオープンソースを前提にした開発環境なので、広告を収入源と
してない限り、ソフト企業では扱いにくい。
何もかもがソース公開する人や企業に有利で、ソース公開しない人や企業に
不利になるような構造になっている。

**デフォルトの名無しさん** · 2023/06/03(土) 02:31:40.44

全部自分で作ればいいじゃない

**デフォルトの名無しさん** · 2023/06/03(土) 02:32:28.44

cargoの仕組みも、オンライン前提で、ソフトウェアを「みんなと共有」する
ことを前提にしているように思える。apt-get や pacman なんかも、みんな
同じ。それに対して Windows は、各社が各様に独立したバイナリで完結
するようにした文化なので、責任の所在がはっきりし、実力主義になっている。
Rustは、Linuxやgccなどと同じで、世界中で全体的に技術を向上させようと
するような思想を前提にしているように思える。
それは物理学や天文学、宇宙科学などの分野では良いことだと思うが、
ITや半導体の分野では問題ある。

**デフォルトの名無しさん** · 2023/06/03(土) 02:33:57.53

>>756
何年もかけてそれやったら、ソース共有しまくっている人が数週間で同じものを
作って、馬鹿にする。
それがオープンソース文化。だから閉塞感が漂っている。

**デフォルトの名無しさん** · 2023/06/03(土) 02:38:59.08

・オープンソースを「人類の最良の最終目標」にする人達が大勢いる。
・それとは関係なく、トヨタなどのハードウェア産業の人やドコモなどの
　通信基盤産業の人は、オープンソースが喜ばしい存在となる。
　但し、自分のハード技術は企業秘密であり、そちらは守秘するのは当然の
　権利だと彼らは思っている。
・よって、Rustは、トヨタやドコモなどが採用するが、ソフト自体を売りたい
　企業は採用しにくい。

**デフォルトの名無しさん** · 2023/06/03(土) 02:41:13.31

ただ、トヨタなどは、ハードウェア産業であり、時間の問題で衰退する。
オープンソースを礼賛していたのは、そういうった古い企業であり、
それらが衰退すると共に、クローズドソース文化が見直されていく
のではないか。
要は日本は古い形態の企業が多かったので、オープンソース信者が多かった。
それでITが遅れた。

**デフォルトの名無しさん** · 2023/06/03(土) 02:48:10.40

Rustは、GPL感染しても、とにかく結果が出ればそれでよい、という文化である。
Rust自体が研究所か、公務員か、Googleから流れてきた資金でMoziillaがやって
いるのか、わけの分からん金の流れがあり、結局、他人の成功の足を引っ張る文化
がある。

**デフォルトの名無しさん** · 2023/06/03(土) 02:51:06.93

たとえば、clangやLLVMでも、C/C++で書かれたものは、クローズド文化
なものに比べれば劣るが、インストールは有る程度簡単に行なえる
(但し、やはりオープンソースゆえの非常に沢山の困った混乱があるが。)。
ところが、Rust製のコマンド類はインストールするのも一苦労する。
とにかく、インストールできず、現実的に使い物にならない。

**デフォルトの名無しさん** · 2023/06/03(土) 02:54:38.93

Rust製のアプリ作者は、ネットから連鎖的に依存関係がダウンロードされるのを
「かっこいい」と思っているらしい。
使う側にとってはただただメンドクサくて不便なだけなのに、それに気付かない。
「ネットから児童ダウンロードされる仕組みを使っている俺ってカッコいい」
的な価値観らしい。
ようは実用的なツールやアプリを作ることには全く興味が無く、なんとなく、
最先端な(??)仕組みを使っている俺ってカッコいい、的なよく分からない価値観
を持つ人がRustでプログラミングしたがっている。

**デフォルトの名無しさん** · 2023/06/03(土) 03:02:13.37

>>755
Rustでコードを書いてもソースコードを公開するかどうかは自由

>>760
貴殿の話はプログラミング言語とは無関係な話ばかりだ
そして要点がわからない長文をダラダラ書くダメな典型例になっている

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

>>764
「成果をみんなで共有しない」という思想は、プログラミング以上に大事。
目標とする思想が逆さまになっている集団が作った開発環境は、結局は
足を引っ張る存在となるので使い物にならない。

**デフォルトの名無しさん** · 2023/06/03(土) 03:09:04.27

cargoも、「オンラインの悪いところ」を凝集したようなツールだ。
逆に、オンラインゲームは「オンラインの良いところ」を凝集している。
前者はただただ面倒なのに対し、後者は気軽。
同じネットを使っているのに、逆の結果となっている。
パッケージ管理ソフトは、その意味で経営戦略的な誤りである。

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

そもそも、開発環境とは作るための道具である。しかし、作ったものが売れないような
思想に基いているなら、道具が使い物になるはず無い。
そもそもそこでRustは間違ってる。
嬉しさだけを売っているなら、ソフト企業が使えるわけ無い。
だから、トヨタみたいなハードウェア企業やGoogleみたいな広告を収入源と
する企業にしか使われない。

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

作ったものを売りたかったら売ればよい
プログラミング言語とは無関係な話だ

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

要は相手の事を考えず、自分だけよければいい、というのがオープンソース思想
である。なぜなら、Rustを開発している人達がどこかから開発費が入ってくる
立場にある。しかし、Rustを道具として使う企業にすれば、作ったソフトから
何らかの方法で「マネタイズ」して開発費を回収しなければならない。
その意味で、オープンソースで作っているRust開発者には営利企業の気持ちが
分からないから、ニーズを理解できないから、「斜め横の」機能を付けてしまう
ことにも繋がっていく。
まず、自分がクローズドでそれ自体を売って手本を見せて、それに他の
営利企業も続くような状態にしなければ、Rustが反映する道は無かろう。

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

>>768
オープンソース思想で作られた道具で、売れるものを作ることは非常に難しい。
なぜなら、道具の作者が営利企業の気持ちが分かってないから。
オープンソース作者、つまり、普通の営利企業とは異なる収益構造、
または、単なる研究機関の人員の価値観で作っているから、営利企業の気持ちや
需要が全く分かって無い。その結果、需要と供給のミスマッチが起きる。

**デフォルトの名無しさん** · 2023/06/03(土) 03:35:45.96

cargoの役割 = 「ネットを使っている俺ってカッコいい」&「時間が掛かり面倒」
ネットゲーム = 「気軽」&「複数人プレイ」
全然異なる。

**デフォルトの名無しさん** · 2023/06/03(土) 03:38:47.29

何を主張したいのかさっぱりわからん
gccもclangもllvmもオープンソースだぞ

**デフォルトの名無しさん** · 2023/06/03(土) 03:43:10.50

>>772
そして実際ほとんど使われて無い。

**デフォルトの名無しさん** · 2023/06/03(土) 04:01:20.75

別の惑星に住んでいるのか

**デフォルトの名無しさん** · 2023/06/03(土) 04:14:45.86

オープンソース系ソフトは、サーバーサイド以外ではほとんど使われて無いと
言われている。

**デフォルトの名無しさん** · 2023/06/03(土) 04:21:06.33

clangもgccよりはましかも知れないが、結局、無料で配って、販売することも
なく、研究費は Apple がハード(iPhoneなど)を売った金でまかなっている。
そのため、営利企業の気持ち側からず、「気が気かない代物」となり、
実際にはほとんど道具としては使われて無い。

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

>>762
Rustは他の言語と比べてインストールも最も簡単だろ
Rustの言語システム自体のインストールや更新などはrustupだけで済む
個々のアプリのインストールや開発などはcargoだけで済む
どちらも色んな入門ドキュメントの最初に書かれているから読め

>>766
cargoはオンラインでなくても使える
必要なものをcargo fetchで取得しておけば例えばcargo build --offlineとオフライン環境で使える