結局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/05/12(金) 14:19:03.50

解散

**デフォルトの名無しさん** · 2023/05/12(金) 14:25:26.74

カーネルのどのへんで使われてるんだろう
Linuxみたいに周辺部分からかな

**デフォルトの名無しさん** · 2023/05/12(金) 14:32:56.45

>>341
Rustの成果をC/C++に還流させるフェーズどんどんやってくれ

**デフォルトの名無しさん** · 2023/05/12(金) 14:44:13.86

Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
https://azure.microsoft.com/en-us/blog/microsoft-azure-security-evolution-embrace-secure-multitenancy-confidential-compute-and-rust/

Rust as the path forward over C/C++

Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we’re betting on Rust as the alternative to C/C++. Rust is a modern language designed to compete with the performance C/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure. We expect our adoption of Rust to expand substantially over time.

**デフォルトの名無しさん** · 2023/05/12(金) 14:45:57.07

マイクロソフト、Rust言語による開発を含む初めてのWindowsカーネルをInsiderプログラム参加者向けに提供開始
https://www.publickey1.jp/blog/23/_rustwindowsinsider.html

デバドラからか

**デフォルトの名無しさん** · 2023/05/12(金) 15:41:33.52

これを見ると、言語の移り変わり時期が来ると
一気に使われなくなって廃れていくんやな、、
https://m.youtube.com/watch?v=qQXXI5QFUfw

**デフォルトの名無しさん** · 2023/05/12(金) 16:02:52.10

むかしもこんな感じでJ++に騙されたんだよ

**デフォルトの名無しさん** · 2023/05/12(金) 16:05:02.84

コンパイラは何使っているんだろうね?
MSがllvmなんかつかうのかな?

**デフォルトの名無しさん** · 2023/05/12(金) 16:11:29.41

Visual Rust++登場も近いな

**デフォルトの名無しさん** · 2023/05/12(金) 16:19:18.80

新しいGC言語がどれだけ出て来ても
C++の天下は揺らがない
もしC++が転落するときが来るとすれば
C++の欠点を解決しつつ同等の性能を出せる新たな非GC言語が登場した時だけだ

**デフォルトの名無しさん** · 2023/05/12(金) 17:14:53.42

trait 内の fn は pub 付けていなくても
trait 自体が pub で定義されていたら
他の trait (というか上の trait を引き継いでいる) からでも参照出来るんだね

**デフォルトの名無しさん** · 2023/05/12(金) 17:16:09.03

Visual R++
Visual R#
しっくりこない

**デフォルトの名無しさん** · 2023/05/12(金) 17:47:30.22

R言語はもう別であるからRustがR++になる心配はない

**デフォルトの名無しさん** · 2023/05/12(金) 17:50:51.87

Visual &mut Rust

**デフォルトの名無しさん** · 2023/05/12(金) 17:54:33.84

トリビア: トレイトメソッドに付くVisibilityは構文定義上だけは許されている

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

トレイト完全に理解した！
ヒャッハーっ！！！

**デフォルトの名無しさん** · 2023/05/12(金) 18:29:46.57

https://doc.rust-lang.org/reference/items/traits.html#item-visibility
Trait items syntactically allow a Visibility annotation,
but this is rejected when the trait is validated.

**デフォルトの名無しさん** · 2023/05/12(金) 20:36:17.87

またひどい知ったかぶりしてる……

https://medaka.5ch.net/test/read.cgi/prog/1619943288/575
575 仕様書無しさん 2023/05/12(金) 15:53:45.02
C++のスマートポインタはRustで吸収され

・RustのCopy実装型 (使われる時は自動コピー)
・RustのCopy非実装型 (使われる時はムーブ)　←　C++のunique_ptr
・RustのArc型 (atomic増減でスレッド間も利用可)　←　C++のshared_ptr
・RustのRc型 (高速にスレッド内で利用可)

つまりunique_ptrの機能がRustでは標準で備わっている
さらにshared_ptrはArcでその軽量版Rcが追加
C++と異なり使い間違えるとコンパイルエラーで知らせてくれる
さらにRustは参照と可変参照の規則によりデータ競合をコンパイル時に防ぐ

**デフォルトの名無しさん** · 2023/05/12(金) 22:56:44.22

問題なし

**デフォルトの名無しさん** · 2023/05/12(金) 23:46:30.09

unique_ptrに対応するのはBoxやろがい

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

>>361
C++のunique_ptrとRustのBoxは対応しない
Boxはヒープ確保であり例えば以下でのnew int(123)部分にあたる
std::unique_ptr<int> foo(new int(123));
そしてunique_ptr自体にヒープ確保の機能はない

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

>>351
それがrustだろ

**デフォルトの名無しさん** · 2023/05/13(土) 07:59:34.64

天下ねえ
天下って思われてると、むだに煽られるよねえ

C++サイコーｗｗｗ(大好き)とは思ってるけど

**デフォルトの名無しさん** · 2023/05/13(土) 10:20:28.21

何故プログラミング言語が変わるのか
まずハードが変わる、当然命令セットも変わる、さりとてハードが変わるたんびに新しい言語を覚える、既存のソフト移植する、など不可能なのでここで一個
ソフトサイドで新しい考え方が出てくる、既存の考え方ではバグ出やすい、効率悪い、こう考える方がいいという新しいプログラミングに関する知見が出れば言語そのものの刷新に向かう圧力が出る
ここで一個
大別すればこの2段やろな

①高級言語
━━━━━━
②繋ぎレイヤ
━━━━━━
③アセンブラ

①、③は必然的な刷新圧力に応じてどんどん変わっていく、③は必然的に新しいハードが出るたびに、①は絶対ではないけどBasic, Perl, Java, Ruby, Python などなど概ね5～10年周期で変わってきた
しかし②のレイヤはほぼ半世紀近くC,C++の独壇場, MachとかObjectice Cとかあったけど結局消えていった
さてさてどうなるのか？
Windows, Linuxでは一部Rubyに置き換える試みがなされてるけどコレは本流の大きなにがれになるのか、あるいはやはりごく一時的なものでやはりC,C++の牙城は崩れないのか

**デフォルトの名無しさん** · 2023/05/13(土) 10:27:54.96

>>365
Rustは③だよね？

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

たった今あるソリューションがRustだから、切迫した更新需要にはRustが入ると思う
もうちょっとゆとりのあるものは、improved C/C++ でいいかなって感じじゃないかな
自分もその位置

**デフォルトの名無しさん** · 2023/05/13(土) 12:46:24.99

C++は倒れたままなのか？

死亡フラグ

**デフォルトの名無しさん** · 2023/05/13(土) 12:48:52.48

倒れたと言いますと?

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

>>365
頭悪過ぎ

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

>>362
make_unique知らないの？知ってて黙ってる？
それとも知ってたけどunique_ptrに属さないから駄目だって言いたいの？

というかその差異を認めたとしても、スコープを抜けるとき/ムーブされるときに内容の後始末とヒープの解放を行うという重要な共通点が依然としてあるし、
その点を無視してunique_ptr<T>を任意の非Copy型と対応付けようとするほうがよっぽど無理があると思うけどね

**371** · 2023/05/13(土) 13:54:01.76

あ、ムーブされるときは違うなすまん

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

lifetime の &'static と
global の static で
同じ名前になってるのはセンス無いな
Rust 界にも static おじさんは息衝いている

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

なんかメチャクチャ書いたな
NeXT Stepとかはあくまで周辺プログラミング環境がobjective CだっただけでOS本体はMach kernelでそれはCとかでかかれてるから②のレイヤでC,C++に変わるものは四半世紀でてきていない
果たして本当にここにRustが食い込めるのかね、あるいは置き換わるなどということが本当に起こりうるものなのか

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

>>373
そこはむしろRustの美学というか方針
Rustは予約キーワード類を最小とするために巧妙な使い回しと組み合わせを意図的にしている

**デフォルトの名無しさん** · 2023/05/13(土) 21:15:21.97

>>371
make_uniqueは複合の合わせ技だから、
unique_ptrのコンストラクタを見た方がよいね
引き数はnewで確保したポインタなどだから、
unique_ptrの構築前に別途ヒープ領域を確保済
一方でBoxの構築時はまだヒープ領域を確保しておらず、Boxがヒープ領域を確保
だから両者は決定的に違うんじゃないかな

さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね

スコープを抜けたときの処理や内部で持っているヒープ領域の解放については、
unique_ptrやBox以外でも行われる話だから、両者の共通点というよりもっと大きな範囲の共通点だね

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

>>375
騙されないぞ

それじゃC++とおんなじじゃないかｗ

**デフォルトの名無しさん** · 2023/05/13(土) 21:55:24.10

>>373,375
staticはglobalスコープとは関係ない
lifetimeがstaticなだけなのでどっちも同じ意味

美学てｗ

**デフォルトの名無しさん** · 2023/05/13(土) 22:14:54.43

Copy非実装型とBoxとどちらがunique_ptrに近いかと言えば大多数の人はBoxだと言うだろうな

まあ言語が変われば1対1で対応しない機能があるのが普通なので
無理に対応づけようとするよりもそれぞれの違いを学んだほうがいいよ

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

>>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね

だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ

**デフォルトの名無しさん** · 2023/05/13(土) 22:50:11.88

Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew

**デフォルトの名無しさん** · 2023/05/13(土) 22:51:59.52

BoxもZero Sized Type(ZST)だとheapを伴わないよね

**デフォルトの名無しさん** · 2023/05/14(日) 02:32:01.76

>>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな

**デフォルトの名無しさん** · 2023/05/14(日) 09:24:48.35

Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される

PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される

何か出るたびそれを信仰し同じコトを繰り返すんだな

**デフォルトの名無しさん** · 2023/05/14(日) 09:25:10.34

>>383
使いどころがないからなｗ

**デフォルトの名無しさん** · 2023/05/14(日) 09:27:43.22

自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし

**デフォルトの名無しさん** · 2023/05/14(日) 09:34:52.10

>>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)

今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない

Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ

**デフォルトの名無しさん** · 2023/05/14(日) 10:27:30.61

javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript

地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから…

**デフォルトの名無しさん** · 2023/05/14(日) 14:29:21.51

WindowsのカーネルもRustに移行するのか

**デフォルトの名無しさん** · 2023/05/14(日) 15:10:39.12

これでWindows、Linux、AndroidがRust採用かー

**デフォルトの名無しさん** · 2023/05/14(日) 19:44:19.16

rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい

**デフォルトの名無しさん** · 2023/05/14(日) 19:45:39.76

>>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね

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

色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう

**デフォルトの名無しさん** · 2023/05/14(日) 20:36:25.87

🐟::🐟::🐟::

**デフォルトの名無しさん** · 2023/05/14(日) 20:47:29.76

::も<type>もC++と同じだから連続してもそれほど違和感ない

**デフォルトの名無しさん** · 2023/05/14(日) 20:57:09.57

goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった

**デフォルトの名無しさん** · 2023/05/14(日) 20:59:37.48

C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ

**デフォルトの名無しさん** · 2023/05/14(日) 21:00:38.00

>>392
関数型はマイナーだからな

**デフォルトの名無しさん** · 2023/05/14(日) 21:02:12.13

>>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな?

**デフォルトの名無しさん** · 2023/05/14(日) 21:06:28.92

< >は解釈の時若干邪魔なのかとは思うけど

ヒマだからANTLRで構文解析器でも作ってみようか

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

ｃはtypedefとかの仕組みがクソ

**デフォルトの名無しさん** · 2023/05/14(日) 21:30:13.88

>>401
typedefかっけーやん
#include <iostream>
using namespace std;
struct Hoge {
void hage () const {cout << "hage" << '\n';}
};
int main () {
typedef void (Hoge::*Mage) () const;
Hoge hoge;
Mage mage {&Hoge::hage};
(hoge.*mage) ();
return 0;
}

**デフォルトの名無しさん** · 2023/05/14(日) 22:05:58.43

何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ

**デフォルトの名無しさん** · 2023/05/14(日) 22:07:54.16

>>403
昔のC++はそうだったよ

**デフォルトの名無しさん** · 2023/05/14(日) 22:57:53.83

次スレのスレタイはC++ Considered Harmfulにしよう

**デフォルトの名無しさん** · 2023/05/14(日) 23:23:04.77

>>402
頭が痛くなるからやめて

**デフォルトの名無しさん** · 2023/05/14(日) 23:23:32.31

>>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ?

**デフォルトの名無しさん** · 2023/05/14(日) 23:26:10.97

作った人たちも失敗したと言ってるからな

**デフォルトの名無しさん** · 2023/05/14(日) 23:29:27.12

変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです

**デフォルトの名無しさん** · 2023/05/14(日) 23:34:59.36

俺は使える程には理解してるが人にはちょっと説明できん

**デフォルトの名無しさん** · 2023/05/14(日) 23:35:38.40

>>408
誰?

**デフォルトの名無しさん** · 2023/05/15(月) 00:00:45.30

>>411
しばらく検索してみたけどソースが見当たらないので取り消します

**デフォルトの名無しさん** · 2023/05/15(月) 00:06:48.33

>>412
お時間使わせてスミマセン

**デフォルトの名無しさん** · 2023/05/15(月) 09:27:18.72

C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに

**デフォルトの名無しさん** · 2023/05/15(月) 09:33:17.96

>>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った

**デフォルトの名無しさん** · 2023/05/15(月) 09:37:02.63

>>411
ハゲ麦紐じゃなかった？

**デフォルトの名無しさん** · 2023/05/15(月) 09:38:10.71

>>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな

**デフォルトの名無しさん** · 2023/05/15(月) 11:36:55.02

>>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
https://doc.rust-lang.org/book/ch15-02-deref.html

**デフォルトの名無しさん** · 2023/05/15(月) 12:27:59.24

>>415
いつの話だよ。
C++11以降を知らんのか。

**デフォルトの名無しさん** · 2023/05/15(月) 12:36:46.16

じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ

**デフォルトの名無しさん** · 2023/05/15(月) 12:58:13.92

Box[T]
Box t
't box
(box t)

**デフォルトの名無しさん** · 2023/05/15(月) 13:30:47.16

今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね

**デフォルトの名無しさん** · 2023/05/15(月) 13:45:50.28

Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ

**デフォルトの名無しさん** · 2023/05/15(月) 13:49:25.75

http://www.kmonos.net/alang/d/templates-revisited.html
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～

**デフォルトの名無しさん** · 2023/05/15(月) 14:23:03.39

> C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた

完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず

仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？

**デフォルトの名無しさん** · 2023/05/15(月) 14:37:29.92

C++11までそんなので頑張ってたんだねw

**デフォルトの名無しさん** · 2023/05/15(月) 14:44:13.08

「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？

Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ

**デフォルトの名無しさん** · 2023/05/15(月) 15:00:31.60

()が増えるのは良くない

**デフォルトの名無しさん** · 2023/05/15(月) 15:09:20.65

https://github.com/rust-lang/rfcs/pull/2544#issuecomment-422078938
https://github.com/rust-lang/rust/commit/014c6922e12d4faa6a2181674d12a7f487c06bb6

0.1すら出る前の超初期は角括弧だったんすねえ

**デフォルトの名無しさん** · 2023/05/15(月) 15:11:35.81

https://soc.me/languages/stop-using-angle-brackets-for-generics.html
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど

**デフォルトの名無しさん** · 2023/05/15(月) 15:21:53.58

>>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね

あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢

**デフォルトの名無しさん** · 2023/05/15(月) 15:44:34.72

言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ

**デフォルトの名無しさん** · 2023/05/15(月) 18:44:18.46

プログラミング言語をただの道具と言うやつは大抵無能

**デフォルトの名無しさん** · 2023/05/15(月) 18:58:00.82

>>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて

**デフォルトの名無しさん** · 2023/05/15(月) 19:22:58.71

何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ

**デフォルトの名無しさん** · 2023/05/15(月) 19:25:10.97

道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ

**デフォルトの名無しさん** · 2023/05/15(月) 19:32:41.90

ここからは理論無用でレスできるのでスレが進むのか？

**デフォルトの名無しさん** · 2023/05/15(月) 19:32:43.22

作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。

**デフォルトの名無しさん** · 2023/05/15(月) 19:34:27.68

問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。

**デフォルトの名無しさん** · 2023/05/15(月) 19:38:48.81

If all you have is a hammer, everything looks like a nail.

>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから

**デフォルトの名無しさん** · 2023/05/15(月) 19:42:25.96

ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。