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

**デフォルトの名無しさん** · 2023/10/28(土) 13:45:00.38

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

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

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

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/11/16(木) 12:42:36.36

>>397
nginxでは性能の限界があってRustで新規に
作ったと記事の読み飛ばしたところに
書きてなかった？

**デフォルトの名無しさん** · 2023/11/16(木) 12:47:30.32

APIがRustになってないとRust採用する意味が無い

**デフォルトの名無しさん** · 2023/11/16(木) 12:53:18.79

>>401
今回の話の場合APIに相当するものはHTTPだと思いますが
APIがRustになっていないと、とは何？

**デフォルトの名無しさん** · 2023/11/16(木) 12:53:44.43

nginxの代わりに使えるものを「新しく」作ったのだからPingoraはnginxの「置き換え」ではないと言いたいのか？？
じゃあ>>392の言う「移行」>>394の言う「置き換え」って厳密には何のことを指すんだ？？

**デフォルトの名無しさん** · 2023/11/16(木) 13:04:58.32

たとえ後発のより良い新言語(ex. Rust)であっても
システムそのままで新言語への置き換えはコスト的に意味がなく
新たなシステムへ置き換える時に新言語の採用は大いに意味があるという実例だろう

**デフォルトの名無しさん** · 2023/11/16(木) 13:27:53.62

403 は言葉使いからして感情でしか物事をみれない

**デフォルトの名無しさん** · 2023/11/16(木) 13:37:39.61

>>383
一応メールの中でコードを書いてるって言ってたけどね

**デフォルトの名無しさん** · 2023/11/16(木) 13:40:47.78

>>397
そりゃCloudflareレベルの規模ならメリットはあるだろう
メリットがあるなら書き直すし
メリットがないなら書き直さない
それだけ

**デフォルトの名無しさん** · 2023/11/16(木) 14:28:52.70

>>394
置き換えがしたいという意志があるとは誰も言ってない
そもそも修正と新規作成をどうしても区別したいという意志がない

ただ、ミクロな意志と無関係なマクロな現象として
置き換えが自然発生するかも知れないという謎の空気はある

**デフォルトの名無しさん** · 2023/11/16(木) 15:09:24.13

early adoptersやearly majorityになるのは
Linuxのperipheralとしてビジネスをしている企業ではなく
Linuxをperipheralとしたビジネスをしている企業

前者の大半はゲームのルールを他者に支配されている立場であり裁量の余地が小さいためマインドセットが保守的
純粋なコストベネフィット以外に低いリスク選好度からくる心理的抵抗が強いためearly adoptersやearly majorityにはなりにくい
複オジがいつも事例であげてるAndroid、Cloudflare、AWSなどが全て後者なのは偶然ではなく構造上の特性から生じる必然
新しい技術というのはゲームのルールを自らコントロールできるこちら側の企業によって牽引される

**デフォルトの名無しさん** · 2023/11/16(木) 15:14:00.47

つまり何が言いたかったかというと
Linux KernelにおけるRustの採用率というのは
技術採用ライフサイクルの観点で見た場合
late majorityやluggardsのRust採用率の目安だということ

**デフォルトの名無しさん** · 2023/11/16(木) 15:14:30.69

adaptor だと思ってたけど adopter なんか

**デフォルトの名無しさん** · 2023/11/16(木) 15:24:27.23

>>410
× luggards
○ laggards

**デフォルトの名無しさん** · 2023/11/16(木) 15:29:19.80

early adopter とは
https://dictionary.goo.ne.jp/word/en/early+adopter/
アーリーアダプター，(新製品の)初期受容者

adopter とは
https://dictionary.goo.ne.jp/word/en/adopter/
1 採用［採択］者
2 養い親，里親

**デフォルトの名無しさん** · 2023/11/16(木) 16:41:51.84

>>403
コードの移行、コードの置き換え。

>397は>370の例だろ。

**デフォルトの名無しさん** · 2023/11/16(木) 17:06:23.69

それぞれのケースで大きく異なるから区別が必要

(1) 新規に作るもの
CloudflareやAWSの例やゲームの新フレームワークやLinuxの新たなデバドラ等すべてこれ
これらは100% Rustが有利

(2) 既存のソフトの言語のみの置き換え
(2)-a. スクリプト言語などからの言語の置き換え
CPUやメモリの使用リソース削減が目的ならばRust化は有利

(2)-b. C/C++からの言語の置き換え
セキュリティやメモリ管理の不安定で困ってる時にRust化が有利

一般的に可能なら(2)の単なる言語間の移植よりも
設計を見直して(1)の新規作成とした方が好ましい

>>399でCloudflareがCPUメモリリソース消費1/3にできた例も
単なるC→Rustへの(2)移植ではなく
新たな設計での(1)新規作成だからであろう

**デフォルトの名無しさん** · 2023/11/16(木) 17:13:48.99

C/C++から書き直すにしても設計をそのまま使えないことが多いから
かなり大変なんだよな
とくに参照やポインタだらけで全部ヒープアロケーションしまくってる場合とか
C++でもその辺りポインタを多用せずスマポやスタック割り当てをうまく使って書いてあるソフトは移植しやすい

**デフォルトの名無しさん** · 2023/11/16(木) 17:41:46.11

どの言語からでもいいけどRustに移行するのにプログラム設計もそのまま引き継いだ自動コンバージョン的な移行を想定するほうがおかしいやろ
そんなんありえんよ

**デフォルトの名無しさん** · 2023/11/16(木) 17:41:52.36

C/C++にRust世代の知見が流入してくることに賭けて、待ってる勢はあるはず自分はそう
それもあるけど、いまあるRustから前線で知見を得ようという勢もあるはず

**デフォルトの名無しさん** · 2023/11/16(木) 17:47:05.98

>>417
C/C++もclangがいったん咀嚼してLLVMにしてる
Rustにトランスパイルするのは非現実的とまではいえないはず
うまくいけば、Linuxは一夜にしてpure Rustになる
Rust派の誰かがやるんじゃないかと思ってる

**デフォルトの名無しさん** · 2023/11/16(木) 17:51:33.13

>>417
な
いつもの藁人形論法

AWSが最初からRustで構築されたとでも思ってんのかね

**デフォルトの名無しさん** · 2023/11/16(木) 17:55:14.82

全てスタック変数で割り当てる
コピー時に適切なムーブをする
ヒープが必要なところはスマポを使う

これをちゃんとやればC++をrustに置き換えることは可能
しかしこれをやってるC++プロジェクトはない

**デフォルトの名無しさん** · 2023/11/16(木) 17:56:48.64

>>420
そいつの意見を真面目に考えてて草

**デフォルトの名無しさん** · 2023/11/16(木) 18:05:24.97

ま、雑談だから
ストローマンは愚痴

一頃のC++はなんでもかんでもヒープに置きすぎだったよね
まあ、お膝元のスタックがそんなでかくない石・スレッドも少なくないけど

**デフォルトの名無しさん** · 2023/11/16(木) 18:12:37.43

>>419
わざわざLLVM IRまで降りて戻ってこなくてもc2rustとか最低限のトランスパイラはいくつかあるぞ
出力結果は作業の開始地点として使うものでそのままプロダクションに使うものじゃない

**デフォルトの名無しさん** · 2023/11/16(木) 18:27:30.00

c2rustの出力をあんまり手直しばっかりしなくていいように、
入力のCにアノテーションを加えていこう、みたいな動きは必ず出ると思うんだよね
良くも悪くもCはマクロ世界だから、当面関わってない人には影響ゼロなようにも書けるはず

そのアノテーションが、そのまま、safe C の礎になればいいんだよ

**デフォルトの名無しさん** · 2023/11/16(木) 18:28:02.28

ああ、ストローマンは自動コンバージョンに反応したのか
“的な”の意味が通じなかったんだな

**デフォルトの名無しさん** · 2023/11/16(木) 18:39:53.99

>>397
記事を読めてないバカを晒すスレはここですか？

**デフォルトの名無しさん** · 2023/11/16(木) 18:40:10.28

LinuxはスクリプトとCの二刀流だ
PythonとCの関係はRustとCの関係にも使える

その知見が流入してこない原因はスクリプト不要論だろう

**デフォルトの名無しさん** · 2023/11/16(木) 20:51:00.53

>>423
だがスマートポインタはスタックに置いて参照渡ししたい。

**デフォルトの名無しさん** · 2023/11/16(木) 23:13:12.09

>>425
Cの安全性を高める目的ならトランスパイラではなく静的コード解析ツール用にアノテーションするほうが遥かに簡単
C++と同じようにCにもそういう動きが出てくる可能性はあると思う

ただ安全性を高めようとすればするほど既存のコードとはかけ離れていくからMISRAのように標準化され半強制的なものにならない限り広く受け入れられる気がしない

イメージ的には↓こういうやつ
浸透するとしても10年以上先だろうね
https://www.youtube.com/watch?v=Pk2RAl8kG1o

**デフォルトの名無しさん** · 2023/11/16(木) 23:35:15.35

そこで奥さんChat-GPTですよ!

**デフォルトの名無しさん** · 2023/11/16(木) 23:43:26.30

>>430
Cの標準では今後も無い。
委員会がやる気ない。

**デフォルトの名無しさん** · 2023/11/17(金) 00:28:52.66

Cは他のお笑い言語とは違って俺が最初に手に取ったK&R第二版から変える必要無かったからな

**デフォルトの名無しさん** · 2023/11/17(金) 00:34:46.03

>>433
さすがにK&Rからは変わってる
(ギャグだったならスマン)

**デフォルトの名無しさん** · 2023/11/17(金) 00:41:31.13

C++もlifetime annotationどうするか決まってないんだな
一番めんどくさくてコードも汚くなる部分だからannotation周りの評価はlifetime+borrow checkerの出来次第だと思ってる
https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377

**デフォルトの名無しさん** · 2023/11/17(金) 01:27:31.74

やる気が暴走したPerlとかC++とかを過大評価するのは暑苦しい
やる気以外のルールはないのか

**デフォルトの名無しさん** · 2023/11/17(金) 05:30:59.53

あー、Perlも好きだわーｗ
ドザなので、シェルスクリプト代わりに、中途半端な処理は全部お願いしてる

**デフォルトの名無しさん** · 2023/11/17(金) 10:14:27.25

>>436
無能な働き者がやる気を出すとね……

**デフォルトの名無しさん** · 2023/11/17(金) 21:12:15.87

NGINXモジュールがRustで書けるようになった
https://www.infoq.com/jp/news/2023/11/nginx-modules-rust/

**デフォルトの名無しさん** · 2023/11/17(金) 22:09:06.15

>>421
>コピー時に適切なムーブをする
これが恣意的すぎて自動的に対応できんわな。

**デフォルトの名無しさん** · 2023/11/17(金) 23:36:50.31

>>436
その2言語は増築工事でダメになった

**デフォルトの名無しさん** · 2023/11/17(金) 23:58:55.97

継承でダメになった、と言った？
ほぼそれに近い？

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

立場によってはそう
継承に親でも殺されたんかって人なら、そう言うだろう

でもそれ、自分の推しの言語に継承かなにかが後出し採用されたら、ブーメランだぞｗ

**デフォルトの名無しさん** · 2023/11/18(土) 11:36:22.09

クラス継承(実装継承)は悪でプログラミング言語界が一致してるから後から継承の採用はないだろうな
過去のしがらみで継承を採用したSwiftやKotlinですら継承を使わずに済む機構などを採り入れている

**デフォルトの名無しさん** · 2023/11/18(土) 11:44:56.68

その結果>>89が示す通りマイナー言語に留まっているじゃん?
ユーザ数を増やすことを優先しないと
数多あるマイナー言語の一つとして忘れ去られる

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

言語のユーザ数の増加要因として最大なのはユーザー数だよ

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

>>446
頭沸いてんのかおまえ、進次郎かよw

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

それがわからんようでは、いっしょに旨い酒は呑めんなあｗ

わかれよーわかりきってんだろ再帰だろ

**デフォルトの名無しさん** · 2023/11/18(土) 12:11:13.74

>>447
微分積分はまだなのかな?

**デフォルトの名無しさん** · 2023/11/18(土) 12:11:30.53

ユーザー数の多いアプリやOSの開発言語が言語利用者数に影響してるんだろうがいw

**デフォルトの名無しさん** · 2023/11/18(土) 12:22:30.52

方法が違うだけでRustやGoにも実装継承が採用されてる
SwiftやKotlinは過去のしがらみで実装継承を採用してるわけではない
目的に対して有益だから採用してるだけ

実装継承の乱用するやつも悪だと決めつけるやつも中身を理解してないという意味では同類だから
どの言語を使っていようがどちらも採用してはいけない

**デフォルトの名無しさん** · 2023/11/18(土) 12:22:47.39

>>450
dN/dt = cN
右辺は一次関数とは限らんだろうけども
新たに学ぶ言語を選択するときには
人は多くの人が使っている言語を選択する傾向にある

**デフォルトの名無しさん** · 2023/11/18(土) 12:27:30.14

>>452
そんなん仕事で開発する人には通用しないよw
開発対象がどのハードのどのOSで動かすかによって決まるからな

**デフォルトの名無しさん** · 2023/11/18(土) 12:29:23.25

しかし、パラメータの意味も説明も無くいきなり数式出す奴ってなんなの？

**デフォルトの名無しさん** · 2023/11/18(土) 12:31:03.67

>>451
それは理解していなさすぎる
実装継承とはある型(クラス)に対して定義したメソッドが別の型(クラス)に対して引き継がれることを指す
Rustに実装継承はない

**デフォルトの名無しさん** · 2023/11/18(土) 12:35:26.40

継承はダメおじさん「継承はダメ」
IUnk教徒俺「うんこ->Release();」

**デフォルトの名無しさん** · 2023/11/18(土) 12:38:02.55

>>453
「仕事で開発する人」ってのは仕事の多さに左右される
新規の言語はまずユーザー数を増やさないと
この先生きのこれない

**デフォルトの名無しさん** · 2023/11/18(土) 12:38:26.91

多段継承は何だかなぁだけど
単純な基礎クラスに応用クラス乗せるくらいは許して欲しいなぁ

**デフォルトの名無しさん** · 2023/11/18(土) 12:39:14.68

>>454
Nってのは数
tは時間
cは定数
どれもよく使うから端折ったけども?

**デフォルトの名無しさん** · 2023/11/18(土) 12:40:04.55

>>457
だからユーザー数なんて増えないんだよw
その言語でしか開発出来ないスマホとかでも作らないとなw

**デフォルトの名無しさん** · 2023/11/18(土) 12:41:04.57

>>459
dは何よ？

**デフォルトの名無しさん** · 2023/11/18(土) 12:42:08.12

ダァン! ってやつだ

俺が考えた

**デフォルトの名無しさん** · 2023/11/18(土) 12:45:04.02

>>461
>>449

**デフォルトの名無しさん** · 2023/11/18(土) 12:49:36.30

ネットワーク外部性 - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%A4%96%E9%83%A8%E6%80%A7

**デフォルトの名無しさん** · 2023/11/18(土) 12:49:49.32

>>463
ならば進次郎にも分かる説明でないとダメだろ

**デフォルトの名無しさん** · 2023/11/18(土) 12:54:44.31

>>465
>>446に分かりやすく書いておる

**デフォルトの名無しさん** · 2023/11/18(土) 12:55:17.22

>>466
だからそれは否定されたろ

**デフォルトの名無しさん** · 2023/11/18(土) 12:56:30.92

>>467
誰に?

**デフォルトの名無しさん** · 2023/11/18(土) 12:56:35.04

仕事で使う技術選定の最大要因ってなんだかんだで利用者数の多さ（≒資料の多さ）になりがち

**デフォルトの名無しさん** · 2023/11/18(土) 12:57:39.99

>>468
俺にw

**デフォルトの名無しさん** · 2023/11/18(土) 12:59:42.63

>>470
そりゃお前が読めてないだけだよ
>>452の最後の1行も平易に同じことを書いているので読んでね

**デフォルトの名無しさん** · 2023/11/18(土) 13:00:29.94

>>461
ワロタ

**デフォルトの名無しさん** · 2023/11/18(土) 13:03:35.26

C++の資料なんか腐るほどあるが
今やC#かCしか生き残って無いだろw

**デフォルトの名無しさん** · 2023/11/18(土) 13:05:11.55

Rustなんて使わなきや開発出来ないアプリなんか無いし
使う事は未来永劫無いだろうね

**デフォルトの名無しさん** · 2023/11/18(土) 13:06:24.64

書けない人がいくら叫んでも無駄

**デフォルトの名無しさん** · 2023/11/18(土) 13:09:08.70

Rust書けないからって嫉妬してるのはわかるけどそこまで逆恨みすることはないじゃん？

**デフォルトの名無しさん** · 2023/11/18(土) 13:09:45.32

それともここで煽られたから「Rustを書いてる人」が嫌いなのかな？

**デフォルトの名無しさん** · 2023/11/18(土) 13:42:18.00

>>473
Debian bookwormのfirefox-esrのソースのうちcとc++を比較すると
ヘッダは区別がつかないので除外して
$ apt source firefox-esr
$ find firefox-esr-115.4.0esr -name *.cpp -o -name *.cxx | xargs cat | wc -l
4766467
$ find firefox-esr-115.4.0esr -name *.c | xargs cat | wc -l
3598263
4766467 / 3598263 = 1.3... C++がCの1.3倍程度
C++はヘッダのみで実装してしまうことも多々あるから1.3倍では済まないだろう
C++の方が多いのだよ
Rustは>>366に書いた通り全体の15%程度（総本山なのに）

**デフォルトの名無しさん** · 2023/11/18(土) 14:46:30.05

それ過去に開発された言語が混ざってるよね？

**デフォルトの名無しさん** · 2023/11/18(土) 15:41:41.81

もうすでに15%もあるといった考え方は？現状の％を並べても5年どうなるかわからないんだし。
その調べかたからわかるのことは限定的だな。
その割合が年々減っていってるのならRustはだめだろうし。

**デフォルトの名無しさん** · 2023/11/18(土) 16:00:47.99

言語の変更は多くの場合システム改新などコードを書き換えるタイミングで行なわれる
また言語の変更をするか否かに関係なくモノリシックなシステムはシステム改新に不利でその点ではマイクロサービスなど多数で構成されるシステムが有利
OSカーネルやWebブラウザも同様でモノリシックに作られている場合は言語の変更に最も適していない
そのような最も適していない極端な特殊例を持ち出して数え上げることは無意味で無駄な行為

**デフォルトの名無しさん** · 2023/11/18(土) 17:15:55.14

一眼観て微分方程式だと判らないレベルの人は黙っていて欲しい

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

それはわかったけど、英語そんな読めない俺、なんも言えず

教えてもらったRustの再評価? 論文、積ん読になってるんだよねえ
面白そうだったから忘れたことはないけど

**デフォルトの名無しさん** · 2023/11/18(土) 21:45:39.76

>>444
一致してない
継承理解できずにアホな使い方する一部の人が勝手に騒いでるだけ
採り入れないとおまえみたいなのが無根拠に騒ぐからとりあえず採り入れてるだけ

**デフォルトの名無しさん** · 2023/11/18(土) 22:49:22.88

モダンなプログラミング言語のうち、
過去のしがらみのある2つの言語を除いて、
すべての言語が継承をクラスごと排除して採用していないもんな

**デフォルトの名無しさん** · 2023/11/18(土) 22:53:24.96

>>485
おかげで全てマイナー言語のままじゃん?

**デフォルトの名無しさん** · 2023/11/18(土) 23:39:14.05

切捨ては極端すぎる。まるで都合の悪いことは無かったことにする左翼の思想
継承はあった方が便利なんだよ
元々オブシコは継承機能が売りだったのに手のひら返してやっぱ合成でいいって、それC言語でもできることだし…
先祖返り…デグレード…設計ミスってことぉ？

**デフォルトの名無しさん** · 2023/11/18(土) 23:51:56.62

2010年以降にできた言語で広く使われてるのは
Kotlin, Swift, Dart, TypeScriptらのクラス継承のある言語

**デフォルトの名無しさん** · 2023/11/19(日) 00:04:07.84

型のgeneralization/specializationはどの言語でも必須と言っていい機能でspecializeされた型でgeneralな型の実装を再利用できるというのは物凄く直感的でわかりやすく便利な機能だから完全に無くせば利便性を損なうだけ

Rustでも形を変えて実装継承が存在するのはそのため

**デフォルトの名無しさん** · 2023/11/19(日) 04:16:47.88

>>489
実装継承は問題点が多すぎるからRustでは採用されていない
実装継承とはある型で定義されたメソッド実装がその型を継承する別の型にそのまま継承されること
Rustは実装継承をちゃんと排除している

**デフォルトの名無しさん** · 2023/11/19(日) 10:00:16.37

>>490
>実装継承とはある型で定義されたメソッド実装がその型を継承する別の型にそのまま継承されること
さすが進次郎
トートロジーが得意だな

**デフォルトの名無しさん** · 2023/11/19(日) 10:14:54.62

継承が必須という人は>191 >195 >204に反論してくれんかね？

shared_ptr<function<T>>で、Tをコンセプトに拡張したものがイメージかね。コンセプトに合致する「インスタンス」なら何でも変数に代入できるようにできれば、わざわざ継承で「インスタンス」の代入可能性を確保する必要は無い。

**デフォルトの名無しさん** · 2023/11/19(日) 10:29:52.82

>>492
継承で定義のコードを書く手間が減るだけでメリットになっている
デメリットうんぬんは使い方知らないだけ
使う場所間違えてる
以上
論破

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

>>493
ずいぶん貧弱な論破だなぁ。

>継承で定義のコードを書く手間が減る
そのために「事前にクラス継承関係をクラスに追加する」という余計な重たい依存関係を埋め込む必要があり、後々のインターフェイス設計に多大なコストが発生する。
依存関係低減のためにAdaptorを使うことになるなら、最初からインターフェイスにAdaptorみたいな機能があった方が良い。

>デメリットうんぬんは使い方知らないだけ使う場所間違えてる

あなたの感想ですか？

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

>>492
複オジはデメリットを真に理解してないから
どれレスでも的外れな内容になっている

>shared_ptr<function<T>>で、Tをコンセプトに拡張したものがイメージかね。コンセプトに合致する「インスタンス」なら何でも変数に代入できるようにできれば、わざわざ継承で「インスタンス」の代入可能性を確保する必要は無い。
継承の前にポリモーフィズムから勉強した方がよさそうだね
メリットとデメリットを理解してないというのは同じようだけど

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

>>495
おいおい、まともな反論できなくなったらレッテル張りかよ。

>ポリモーフィズム
だからポリモーフィズムにサブタイピングは依存関係重すぎると言っているんだよ。
std::funcionを理解できていますか？

**デフォルトの名無しさん** · 2023/11/19(日) 11:34:23.07

記述量が多くなる＝悪は誰にでも判るだろう
RADが流行ったのも理解できるだろう
プログラマはいつも何を重視しているのか、それは時間だ
Rustでコンパイル通す時間よりC++でやった方が早かろう
C++でGUIアプリ作るよりC#でやった方が早かろう
さてRustでGUIアプリ作るには、一体どれだけ時間が掛かるのか
話は終わりだ

**デフォルトの名無しさん** · 2023/11/19(日) 11:39:08.94

>>492
必須とは考えてないから反論はしない

ユーザが選択できれば良いんだよ
言語としては装備していて
害悪があると考えるならそう考えるユーザが使わなければ良い
他言語のライブラリを移植する際に
使った方が再設計の手間が掛からないというなら使えば良い
マイナー言語のまま終わるぞ

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

数年でRustみたいな思想はAIが肩代わりしてくれると思うよ
今からRustで数年苦労するよりは
他の事しつつ待ってた方がもしかして有意義なんじゃないかな笑