C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

闘え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
C vs C++ vs Rust Part.2
https://mevius.5ch.net/test/read.cgi/tech/1639539350/

**デフォルトの名無しさん** · 2022/01/27(木) 22:28:23.63

前スレまでのあらすじ

---
987 デフォルトの名無しさん sage 2022/01/27(木) 17:14:15.89 ID:hWkHkx2k
>>986
> だから専有機なら上限で用いる
「現在の主流」というのは、「専有機」での話？
それとも一般的な話？

994 デフォルトの名無しさん sage 2022/01/27(木) 17:52:30.63 ID:LojT3k5n
自分が理解できないと相手が敵かつ全て同一人物に見える病気のパターンかねｗ
皆普通に同じことを指している
何が理解できないのか素直に言ってごらん

995 デフォルトの名無しさん sage 2022/01/27(木) 17:55:13.00 ID:hWkHkx2k
>>994
>>987の質問に答えてから続けてね

**デフォルトの名無しさん** · 2022/01/27(木) 22:58:22.92

あらすじが全くわからんw

**デフォルトの名無しさん** · 2022/01/27(木) 23:13:49.64

彼はこの部分がわからなくて連投していたみたいだから横から補足説明しましょう

> 大雑把にI/O観点で二つに分けると
> 昔は同期I/Oでブロックされるからマルチスレッド
> 今は非同期プログラミングでスレッド数はシングルからCPUコア数が上限
> RustのFutureタスク、GoのGoルーチン、JavaScriptの非同期Promiseやコールバック
> いずれもプロセス内スケジューラがI/O多重化(select/epoll)やタイマーなど管理して非同期プログラミングを支えている

昔は自分でOSスレッドを立ち上げて使っていたのに対して
今は自分で立ち上げるのがOSスレッドではなくそれよりも粒度が細かく軽い非同期なタスクで
OSスレッドを立ち上げる役割はそれらタスクの非同期なスケジューリングをするランタイムで
そのスレッド立ち上げ個数は効率最大のためCPUコアスレッド総数と一致するのが望ましいため
GoやRustなどではデフォルト値がそうなっていますよってことですよね
もちろん個数を1個つまりシングルスレッドに設定しても動くところが決定的な違いですね

OSがスケジューリングしてくれるけど重くて大きくリソースを喰うOSスレッドを今は直接使わずに
> RustのFutureタスク、GoのGoルーチン、JavaScriptの非同期Promiseやコールバック
これらのもっと軽くて小さなタスクを使うことで何万も同時に処理できるようになったという話ですね

ちなみにRustでは昔と同じ状況にスレッドとタスクを1:1(=n:n)でも使えますし
シングルスレッドにして1:nでも使えますし上述の状況は汎用的なm:nになりますね

**デフォルトの名無しさん** · 2022/01/27(木) 23:14:48.99

明らかに間違ってることを自信ありげに語るのはいつものこと
その人達用の隔離スレだから

>>1乙

**デフォルトの名無しさん** · 2022/01/27(木) 23:25:15.10

横から？w
本人だろ、お前w

**デフォルトの名無しさん** · 2022/01/27(木) 23:31:40.86

複製おじさんのいつもの自演です

**デフォルトの名無しさん** · 2022/01/27(木) 23:34:30.76

次はgoogleで2件しかヒットしない、「プロセス内スケジューラ」については説明してくれw

**デフォルトの名無しさん** · 2022/01/27(木) 23:49:40.45

非同期タスク群のスケジューリングをするランタイム部分のことではないでしょうか
一般的にプロセスの中に1つだと各スレッドへタスクを割り振るコストが高くて
各スレッドの中に独立して1つずつだと暇なスレッドと多忙なスレッドが偏るデメリットがあり
GoでもRustでもそれらのスケジューリング問題を改善するために
各スレッド内に独立キューを持って効率的に処理しつつもグローバルキューも備えることで解決しているようですね

**デフォルトの名無しさん** · 2022/01/28(金) 00:05:15.17

複製おじはGoでもRustでもまともに非同期プログラミングやったことないんだな

**デフォルトの名無しさん** · 2022/01/28(金) 00:14:38.44

>>8
OSスレッドがOSによりスケジューリングされることに対する対比じゃね？
タスクは各プロセスの中にスケジューラーがある
Goは言語ランタイムの中だがRustは各自が好きなのを選んだり自作も可能

**デフォルトの名無しさん** · 2022/01/28(金) 01:31:02.15

どうせRustは普及しないんじゃないかな、知らんけど。

**デフォルトの名無しさん** · 2022/01/28(金) 08:21:58.40

rustはc++を食うことがあってもピュアcを食うことはなさそう

**デフォルトの名無しさん** · 2022/01/28(金) 08:42:08.00

Cは誤解を恐れずに言えばアセンブリ言語みたいなもんだからな

**デフォルトの名無しさん** · 2022/01/28(金) 13:14:51.22

>>13
C++ 98以前は Cと似てるし、ライブラリも言語とは無関係に自由に作れたから大丈夫。C++11以後はダメ言語になった。

**デフォルトの名無しさん** · 2022/01/28(金) 13:17:06.82

そもそも、CやC++が普及したのはTurboCのおかげ。
TurboCはライブラリが分かり易かった。
C++11以後、言語もSTLも両方腐っていてTurboCとは全く違うようになり、
人気もがた落ちになった。

**デフォルトの名無しさん** · 2022/01/28(金) 15:22:28.01

何頓珍漢な事言ってんだこのバカ

**デフォルトの名無しさん** · 2022/01/28(金) 18:58:54.57

>>8
OSによるプロセスやOSスレッドのスケジューラではなく
プロセスの中で動くタスクのためのスケジューラ
各言語によって言語機能として備えている場合と外部ライブラリによる場合がある

Rustではその中間の形態で言語機能としてはasync/awaitの枠組みのみ提供
さらに標準ライブラリとしてFutureやWakerなどの必要とする定義のみ提供
実際に動作するスケジューラは外部ライブラリで様々な提供がなされ自作もできる
その他はこのスライドの前半の解説など参照

Rustのasync/awaitとスケジューラの話
https://speakerdeck.com/osuke/rust-async-await

**デフォルトの名無しさん** · 2022/01/28(金) 21:04:45.07

前スレ946の三つのサイトから数値を入手して和を求める例を練習のためにやってみたんだが
httpのheader取得までとbody取得の2回awaitが入るのがなるほどと思った
あと文字列を数値に変換parseも当然必要だったのでawait部分がちょっと長い
#[async_std::main]
async fn main() -> surf::Result<()> {
let n1 = surf::get("https://httpbin.org/base64/MTEx";); // 111
let n2 = surf::get("https://httpbin.org/base64/MjIy";); // 222
let n3 = surf::get("https://httpbin.org/base64/MzMz";); // 333
let sum = n1.await?.body_string().await?.parse::<i32>()?
+ n2.await?.body_string().await?.parse::<i32>()?
+ n3.await?.body_string().await?.parse::<i32>()?;
assert_eq!(666, sum);
Ok(())
}
利用させてもらったテストサイトはURLで返す値など指定できるhttpbin.org
これで動いて値取得もできて合計値assertも通ったのだが実は落とし穴があることに気付いた

**デフォルトの名無しさん** · 2022/01/28(金) 21:49:38.11

元のJSのコードもだけど
await連発すんなよw

**デフォルトの名無しさん** · 2022/01/28(金) 22:11:12.59

そのテストサイトにhttp返答を遅延させるdelay機能があるので試した時に露見した
同時に指定値を返せないようなので数値化と足し算の意味はないが遅延時間を知りたかった
let d1 = surf::get("https://httpbin.org/delay/4";); // 4秒
let d2 = surf::get("https://httpbin.org/delay/5";); // 5秒
let d3 = surf::get("https://httpbin.org/delay/3";); // 3秒
let sum = d1.await?.body_string().await?.parse::<i32>().unwrap_or(0)
+ d2.await?.body_string().await?.parse::<i32>().unwrap_or(0)
+ d3.await?.body_string().await?.parse::<i32>().unwrap_or(0);
結果は12秒かかってしまい期待と異なり直列に実行されていた
肝心なことを忘れていた

**デフォルトの名無しさん** · 2022/01/28(金) 23:09:26.07

JavaScriptではPromiseを返す関数を3つ呼べばそれで3つ並行に実行される
しかしRustでは並行に動くタスクを自分で明示的に起動しなければいけなかったのだ
よく考えればGoでも自分で明示的にgoと前置指定することで別goルーチンを起動している
Rustではそれがspawnでありgoと同じくそれによりスケジューラに登録されるようだ
use async_std::task::spawn;
let d1 = spawn(surf::get("https://httpbin.org/delay/4";)); // 4秒
let d2 = spawn(surf::get("https://httpbin.org/delay/5";)); // 5秒
let d3 = spawn(surf::get("https://httpbin.org/delay/3";)); // 3秒
このようにspawnを付けて以降は同じ実行をすると全体で結果5秒となり並行に実行された
言語自体に魔法の仕組みはなく自分で明示的にスケジューラに登録指定するのはわかりやすくて安心した
そのスケジューラも手作りできるらしく興味深い

**デフォルトの名無しさん** · 2022/01/28(金) 23:23:01.28

自分でblock_on書かないとRustのasyncは身に付かない

**デフォルトの名無しさん** · 2022/01/28(金) 23:49:49.26

>>23
use async_std::task::{block_on, spawn};の時
このblock_onを使った
fn main() -> surf::Result<()> {
block_on(async {
let d1 = spawn(surf::get("https://httpbin.org/delay/4";));
// 略
})
}
の簡略版が>>19で書いた
#[async_std::main]
async fn main() -> surf::Result<()> {
let d1 = spawn(surf::get("https://httpbin.org/delay/4";));
// 略
}
ってことか
つまりasync { ... } という非同期ブロックをblock_onによりスケジューラに実行させているわけだ
当たり前だがspawnする以前に最初からスケジューラの掌の上で踊っていたのであった
じゃないと全体を並行に実行できないもんな

**デフォルトの名無しさん** · 2022/01/29(土) 13:58:43.26

Rustのasync/awaitはコンパイルされると単純なステートマシンになる
例えばasyncブロック内にfuture1.awaitとfuture2.awaitが順に呼び出されるとする
最初はfuture1をpollする状態でpending中はpendingを返す
そこでreadyになればfuture2をpollする状態へ遷移
そこでもreadyになれば全体としてreadyを返す状態へ遷移
結局スタックレスなコルーチンを実現しているだけなので非常に軽い

**デフォルトの名無しさん** · 2022/01/29(土) 22:23:27.99

起動も切替もスレッドより軽くてリソースも喰わないなら
非同期タスクの欠点は何だ？

**デフォルトの名無しさん** · 2022/01/29(土) 23:26:45.54

Rustの場合軽量タスクはプリエンプティブじゃないので、変なコーディングすると特定のタスクが実行され続けて、他のタスクがいつまでも実行されないことがある
あとは、OSのスレッドじゃないからスレッドの属性や権限をタスク単位で異なる物にすることはできないとか

**デフォルトの名無しさん** · 2022/01/29(土) 23:44:38.93

>>27
前者は間違えて同期ブロッキングする関数を呼んでブロックしてしまった場合
および長時間ずっと全く非同期関数を呼ばずに計算し続けるか暴走する場合
これらはバグならfixで解決
バグでないなら非同期タスク実行スレッドとは別に専用スレッドを用意して実行できるスケジューラもあるのでそれを利用

**デフォルトの名無しさん** · 2022/01/30(日) 00:54:30.09

>>28
同じ処理でも入力内容次第で変わるからそんな簡単にいかないよ

**デフォルトの名無しさん** · 2022/01/30(日) 01:16:02.14

async-stdならgoみたいにタスクが一定時間経っても制御返してくれないときに勝手にスレッド起こしてくれるんじゃなかったっけ

**デフォルトの名無しさん** · 2022/01/30(日) 18:58:15.77

>>29
入出力が行なわれたらタスクのスイッチングが発生するので
意図的にブロッキングするものを呼んでブロックしているケースを除くと
いつまでもタスクが切り替わらないのは演算のみを延々と続けるケースのみになる
対応策としては自分で定期的に手放すか以下の方法で回避

>>30
それは様々な問題点で中止
結局tokioもasync_stdもそのような特殊ケースはspawn()の代わりにspawn_blocking()することで
タスクのスイッチングに影響が出ないように別スレッドで実行させる方針
その場合は結局スレッドを自分で起動して同期ブロッキングで使う昔からの方法と実質同じだが
そのような特殊なケースも含めて統一的にタスクを扱える

**デフォルトの名無しさん** · 2022/01/30(日) 20:50:10.05

>>31
延々と演算を続ける意図はなかったのに結果としてそうなる場合があるということ
それを最初から想定できてyieldを挟めるなら問題ないのだが現実はそうはなっていない
https://tokio.rs/blog/2020-04-preemption

**デフォルトの名無しさん** · 2022/01/30(日) 21:57:34.87

そのbudget方式は戻ってこないとペナルティ与えられないから本質的な解決になっていない
yield相当をコンパイラが上手く挟むのも無理だからプログラマーが自らすればいい

**デフォルトの名無しさん** · 2022/01/30(日) 22:13:02.89

歴史から学ばない人

**デフォルトの名無しさん** · 2022/01/31(月) 00:52:40.26

歴史ってのがマルチタスクOSにおける cooperative vs preemptive の話だとするなら前提が違いすぎない？
任意のアプリケーションが動く可能性のあるOSと自身のプログラムのルーチンが実行されるアプリとではスケジューラに求められる制約条件は違って然るべきかと

**デフォルトの名無しさん** · 2022/01/31(月) 07:30:22.38

シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて成功しているように問題なく動作する
同期ブロッキングを完全排除してしまえばタスク切り替えが起きない場合すなわちスケジューラに戻らない場合は
入出力もなくループでメモリ上演算を繰り返している場合となる
そのような場合でもループ内で自分で定期的にスケジューラへ制御を戻してやればよい
そのためにRustではtask::yield_now()がある

**デフォルトの名無しさん** · 2022/01/31(月) 10:15:42.24

イベントループがハングアップした時の対処とか考えたことないでしょ？
バグだからfixすればいいじゃ能がない
歴史に学ぶといいよ

**デフォルトの名無しさん** · 2022/01/31(月) 10:24:59.23

>>37
GoやJavaScriptなどは言語内蔵だが問題が起きたことはない
Rustは言語から切り離されているが同様
いずれもそれらのランタイムの製作者以外がその部分のコードを触ることはなくバグが発生しようがない

**デフォルトの名無しさん** · 2022/01/31(月) 10:27:00.53

>>37
> イベントループがハングアップした時の対処とか考えたことないでしょ？
そういうのは上位で対処（タイムアウトでプロセス再起動とか）することもあるからケースバイケースでしかない

**デフォルトの名無しさん** · 2022/01/31(月) 10:46:15.49

イベントループがハングアップするってなに？
epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？

**デフォルトの名無しさん** · 2022/01/31(月) 11:35:28.84

タイムアウト設定忘れみたいなバグの話でしょ
そんなに引っ張る話でもないと思う

**デフォルトの名無しさん** · 2022/01/31(月) 12:52:34.54

>>41
それは万が一あるとしても非同期スケジューラランタイム実装者の管轄
その利用者である一般プログラマーが引き起こすバグではないため関係ない

**デフォルトの名無しさん** · 2022/01/31(月) 13:02:21.71

> epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？
の話だぞ？

**デフォルトの名無しさん** · 2022/01/31(月) 13:17:00.70

歴史って言葉持ち出してるんだしそんなしょうもない話じゃなくてもっと有名なエピソードなんじゃないの

**デフォルトの名無しさん** · 2022/01/31(月) 13:24:49.76

「Rustのタスクの欠点は？」

「プリエンプティブじゃないところ」

「プログラマーが注意すればいいだけだから問題ない」

**デフォルトの名無しさん** · 2022/01/31(月) 13:35:30.64

そりゃepollやselect相当を自分で使っていてミスをすればイベントループがハングアップするのは当たり前
しかし非同期タスクのイベントループは非同期スケジューラの中にあって自分でepollやselectを扱わなくてよくなった
だから自分のミスでイベントループがハングアップすることはなくなった
それ以前の歴史では色々あったが状況が変わった

**デフォルトの名無しさん** · 2022/01/31(月) 13:51:12.77

はいはい、理想的な環境で羨ましいですね

これでいいかな？w

**デフォルトの名無しさん** · 2022/01/31(月) 14:52:14.32

メモリ開放忘れみたいなバグの話でしょ
そんなに引っ張る話でもないと思う

**デフォルトの名無しさん** · 2022/01/31(月) 14:57:56.44

バグ耐性高めるためにタスクをプリエンプティブにしたいならすれば良いのでは
プログラマーのスタンスに合わせて適切な物を選べるよう選択肢は用意されてると思うが
何について言い争ってるのかよくわからない

**デフォルトの名無しさん** · 2022/01/31(月) 15:37:58.82

GoやNode.jsが上手くいってる主因は非同期並行プログラミングのしやすさ
両者は方向性が真逆だけどそこが共通点で時代の要請
逆にC++が振るわないのは非同期並行プログラミングのしにくさ
その状況でRustが登場して非同期並行プログラミングのしやすい環境も装備されたという流れ

**デフォルトの名無しさん** · 2022/01/31(月) 18:03:53.30

>>49
タスクはプリエンプティブにはできないよ
スレッド使えって言ってるの？

**デフォルトの名無しさん** · 2022/01/31(月) 18:33:21.76

>>51
そうじゃね？

**デフォルトの名無しさん** · 2022/01/31(月) 18:56:25.41

Node.jsもプリエンプティブではないけど困っていない
タスクがプリエンプティブではないことを欠点だと主張する人は
欠点だという具体的な例を挙げてから主張すべき

**デフォルトの名無しさん** · 2022/01/31(月) 19:02:29.41

>>51
そうだよ
ここで言うタスクはtokioやasync-stdの用語のタスクのことね
spawn_blockingでタスク生成すれば専用スレッドが割り当てられるので特定のタスク選んでプリエンプティブにできる (OSにタスクスイッチの制御を委譲できる)

**デフォルトの名無しさん** · 2022/01/31(月) 19:03:44.27

>>53
spawn_blockingみたいなAPIが用意されてるのはプリエンプティブなタスクの需要はあるんじゃないの
そこを否定する意味が分からない

**デフォルトの名無しさん** · 2022/01/31(月) 19:28:57.02

>>54
それはレイヤーが違う
まずOSスレッドは何をしようが常にプリエンプティブ
だからOSスレッド上で動いているタスクも途中で一時中断されたり再開されたりしうる
だからといってタスクをプリエンプティブだと言わないのはタスクの階層で話をしているため
タスクスケジューラに制御を戻さない限り他のタスクに切り替わらないため「プリエンプティブではない」と言われる

次にspawn_blockingで起動されるのもタスクの一つ
だからタスクスケジューラが管理するスレッドの中で動く
それがspawnだと一つのスレッドに対するキューに複数のタスクが割り当てられる
一方でspawn_blockingは一つのスレッドに対するキューにそのタスクのみが割り当てられる
それだけの違いであり両者ともにタスクスケジューラの管理下にあるタスクである
もちろん動作中も終了後もタスクとして同じ扱い

つまりspawn_blockingはプリエンプティブにするものではない
同じタスクでありスタックレスなコルーチンであることも同じ

>>55
その意見は成立していない

**デフォルトの名無しさん** · 2022/01/31(月) 19:56:01.95

>>56
確かにプリエンプティブという用語を使ったのは適切ではなかったかもね
タスクがスレッドを占有するか他タスクと共有するか選択できると言い換えればよいかな

**デフォルトの名無しさん** · 2022/01/31(月) 21:28:17.75

>>54
最初からspawn_blockingで呼ぶべきだと誰もがわかるような処理だけじゃないよ

Goと同じでRustもそのうちプリエンプティブなスケジューラが作れるような機構を用意すると思うけどね

**デフォルトの名無しさん** · 2022/01/31(月) 22:11:33.46

>>58
preemptiveは必要ない
シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて問題なく動作し成功している

**デフォルトの名無しさん** · 2022/01/31(月) 22:59:08.63

Rustってデータ競合を許さない、ってあたりが並列処理とめちゃくちゃ相性良いように見えるけど、
まだそういうスケジューラとか非同期ランタイムらへんの仕組みがちっとも枯れてないんだね
将来のデファクトがどうなりそうか、ってのはある程度見えてきてるのかな？

**デフォルトの名無しさん** · 2022/01/31(月) 23:10:00.73

>>59
tokioの開発者もasync-stdの開発者もそうは考えてない

a major source of bugs and performance issues in concurrent programs: accidental blocking.
https://async.rs/blog/stop-worrying-about-blocking-the-new-async-std-runtime/

**デフォルトの名無しさん** · 2022/01/31(月) 23:16:15.33

>>61
それはすぐに廃止された
そして現在tokioもasync-stdもプリエンプティブを許すコードは存在しない

**デフォルトの名無しさん** · 2022/01/31(月) 23:18:46.34

>>62
知ってるよ
問題認識の話をしてるんじゃん

**デフォルトの名無しさん** · 2022/01/31(月) 23:21:44.46

Node.jsはタスク単位で高い信頼性が求められるシステムでは使われない
イベントループがブロックしたら他のタスクを道連れにしてプロセス丸ごと再起動する以外に対処法がないから
それもexecution managerできちんとモニタリングしてればの話

JSやNodeとRustとはポジショニングが違う

**デフォルトの名無しさん** · 2022/01/31(月) 23:28:55.88

>>64
イベントループがブロックすることはない
何を言いたいのか意味不明

**デフォルトの名無しさん** · 2022/01/31(月) 23:47:16.39

>>64
Node.jsまで否定し始めるとは発狂もほどほどに

**デフォルトの名無しさん** · 2022/02/01(火) 01:18:54.05

>>58
rustでプリエンプティブなタスクって実装できるのかね
goみたいなシグナルでスイッチする仕組みは使えない気がするが

**デフォルトの名無しさん** · 2022/02/01(火) 09:02:19.73

昔は標準で出来たのに「そういうのはライブラリでやればいい」って嘯きながら削除して、そのあと一生それが出来る標準ライブラリが登場しないいつものRust

**デフォルトの名無しさん** · 2022/02/01(火) 14:23:13.43

>>67
Cで実装できることはRustでも実装できる
もちろんRustにもプリエンプティブなスケジューラは存在する
Rustで書かれたプリエンプティブなリアルタイムOSもある

>>68
Rust標準にプリエンプティブなタスクであるグリーンスレッドがあったのは
Rust 1.0が正式リリース(2015年)となる以前Rust ～0.9 の試行している時代
しかし重厚となりベアメタルもターゲットとするRustでは不適なため放棄
例えばGoの方法だと巨大なランタイムや個別スタックが必要など

そのためRust標準ではスタックレスで軽いタスクを提供
さらに加えてasync/awaitもサポートし現在の軽く便利な環境となった

**デフォルトの名無しさん** · 2022/02/01(火) 15:14:51.45

あと5年寝かせれば使えるようになるかな

**デフォルトの名無しさん** · 2022/02/01(火) 15:26:14.30

別に今でもasync-stdを使えばええんちゃうか？

**デフォルトの名無しさん** · 2022/02/01(火) 15:54:32.70

>>69
ユーザーランドでプリエンプティブなタスク実現するという話なんだけど
具体的にどのライブラリがサポートしてるの？

**デフォルトの名無しさん** · 2022/02/01(火) 16:14:56.52

>>71
async_stdでのプリエンプティブな試みは軽さの方針等に合わず、組み込まれないままで終わった

>>72
上記の後継がasync_stdから独立していてsmolscaleとなっている

**デフォルトの名無しさん** · 2022/02/01(火) 17:44:48.05

>>72
lunaticってのがWASM限定だけどプリエンプティブ実現してるらしいよ
WASM以外はコンパイラのサポートがないと無理

>>73
async-stdがやろうとしてたのはプリエンプティブではないよ

**デフォルトの名無しさん** · 2022/02/01(火) 23:44:18.44

話題になってる分野だとC++が惨敗すぎて
Rustの話題一色になってしまってる感じ

**デフォルトの名無しさん** · 2022/02/02(水) 00:32:45.41

C++が落ち目なのはまっとうなエンジニアの間では共通認識だろ

**デフォルトの名無しさん** · 2022/02/02(水) 02:30:31.45

変な拡張し杉てワケワカになってきてるよな

**デフォルトの名無しさん** · 2022/02/02(水) 11:27:34.63

変な拡張を使わなければ良いだけでは？　使いこなせないのを使えなとは言わない。

**デフォルトの名無しさん** · 2022/02/02(水) 14:23:10.98

RustがGo位の位置にたどり着くのは、あと何年かかるかね

**デフォルトの名無しさん** · 2022/02/02(水) 15:00:57.22

GoはWebとかのアプリケーションでカジュアルに使われるようになってきたから、使う人数もかなり多くなってきたけど、
Rustはそういうポジションにつくことないだろうから、現在のGoほどの人気になることはないんじゃない？
RustはC/C++のシェアを塗り替えていく程度だろうけど、そういう低レイヤーでは最強言語になりそう

**デフォルトの名無しさん** · 2022/02/02(水) 15:03:25.91

RustがTIOBE Indexに出てくるのはいつなんだろう？w
https://i.imgur.com/DNijd0h.jpg

**デフォルトの名無しさん** · 2022/02/02(水) 22:30:37.00

言語機能としてはC++が完敗だから
過去遺産しか誇るものがない

**デフォルトの名無しさん** · 2022/02/02(水) 22:35:52.80

何言ってんだこのバカ

**デフォルトの名無しさん** · 2022/02/02(水) 22:46:31.08

シェアもユーザー数も過去遺産と言われてしまえばそうだが
そんなことは興味がないのでC++での非同期並行プログラミングについても語って欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 16:11:01.01

C++の非同期っていうとstd::asyncとか？

**デフォルトの名無しさん** · 2022/02/03(木) 17:48:17.26

>>81
今26位で、Kotlin, Lua, Scalaとかより上なんだが

**デフォルトの名無しさん** · 2022/02/03(木) 17:52:10.90

>>86
COBOLより下なんかwwwww

**デフォルトの名無しさん** · 2022/02/03(木) 18:30:47.00

KotlinやScalaは結局流行らずJavaで十分だし
Luaも一時期熱狂したけど記法や環境が多くの人の好みに合わずPerlのように嫌われてる
RustもC/C++で十分という認識が強くて普及せずに一部の通好みに終わる可能性がある
Rustは有力企業もプッシュしてるけど三つの言語の流行らない特徴を全て備えてる
そうこうしてるうちにRustより優れた言語がぽっとでて席巻する未来だってある

**デフォルトの名無しさん** · 2022/02/03(木) 18:38:00.04

流行るの閾値高くない？
何位以上になったら満足なんだ

**デフォルトの名無しさん** · 2022/02/03(木) 18:48:22.27

普通にTop10じゃね？

**デフォルトの名無しさん** · 2022/02/03(木) 18:51:38.73

しかしTop10のVisualBasicやアセンブリが流行ってるとか言われてもあまり納得感はないな…

**デフォルトの名無しさん** · 2022/02/03(木) 19:08:22.03

TIOBEってトレンドを計測してるわけじゃなくて、あくまで検索エンジンで検索結果のヒット数が多かったランキングだからな
CとかVBみたいに昔から一定の人気を保ち続けてるような言語がランキング高くなりやすいんじゃないかな

**デフォルトの名無しさん** · 2022/02/03(木) 19:24:04.62

GitHub上の活動に基づいたランキングの方がプログラマ間の流行を知るには良いのかな
https://madnight.github.io/githut/#/pull_requests/2021/4

**デフォルトの名無しさん** · 2022/02/03(木) 19:40:42.80

せやな
TIOBEはJavaScriptとアセンブラが隣の順位に並んでるとかおかしすぎるやろ

**デフォルトの名無しさん** · 2022/02/03(木) 21:31:55.43

>>88
Scalaも当時は熱狂的なファンがいたよなｗ

**デフォルトの名無しさん** · 2022/02/03(木) 21:44:00.20

ScalaはJVMベースだという点以外は特に悪いところは無いと思うんだが

**デフォルトの名無しさん** · 2022/02/03(木) 23:27:45.66

コラッツ関数を上手く実装できないかな

**デフォルトの名無しさん** · 2022/02/04(金) 00:31:37.55

>>93
githubはアマチュアプログラマも沢山混じってる。
日経の調査ではプロのプログラマで最も使われている言語はC/C++だとされている。
なお、githubでも、CとC++を合算すると、9.82%、Rustは 0.694%で、
14.1倍の差がある。

**デフォルトの名無しさん** · 2022/02/04(金) 00:34:29.27

>>98
C vs C++でもあるんだから足したらだめでしょ

**デフォルトの名無しさん** · 2022/02/04(金) 00:35:47.48

>>91
VisualBasicは結構使われているのではなかろうか。Excelなどで。
アセンブリは、基礎的なライブラリを作る人や組み込み、OS、BIOS
を作ったり、グラフィックや数値計算の高速化を行う場合に必要な場合がある。

**デフォルトの名無しさん** · 2022/02/04(金) 00:36:35.60

>>99
Cにクラスを入れたものとしてC++を使っている人は多いはず。
MFCなどもそう。

**デフォルトの名無しさん** · 2022/02/04(金) 00:44:19.25

>>101
いやいや、スレタイ通りこのスレではCとC++は対立する物として区別すべき

**デフォルトの名無しさん** · 2022/02/04(金) 00:45:03.38

今どき言語マウントするやつは
メンタルも技術力もアマチュア

**デフォルトの名無しさん** · 2022/02/04(金) 00:47:42.81

C++はCを基礎にしてるくせに、Cに歯向かって宿主を殺してしまう寄生虫みたいな
ことになってるからな。

**デフォルトの名無しさん** · 2022/02/04(金) 05:41:15.73

いまのc++の拡張がな
autoとラムダとdecltypeくらいでやめときゃいいのにあとでボツになりそうな仕様までモリモリに盛りやがって下手したらobjective-cみたいになりそう
なのにいまだにpropertyも実装されてないとか

**デフォルトの名無しさん** · 2022/02/04(金) 06:48:54.05

conceptsは許せる

**デフォルトの名無しさん** · 2022/02/04(金) 08:29:55.22

>>105
それほどへんなもの追加されてるか？
右辺値参照、constexpr、可変引数テンプレートは必要だしな

**デフォルトの名無しさん** · 2022/02/04(金) 08:53:37.86

色々理解できない機能が増えて辛いんだろw

**デフォルトの名無しさん** · 2022/02/04(金) 09:58:17.78

conceptはむしろ必須だろうよ

**デフォルトの名無しさん** · 2022/02/04(金) 10:06:51.33

C++11移行では、変数定義で、
TYPE a = b;
の形式が非推奨で、
TYPE a{b};
が推奨になった。
これは、C/C++の今までの伝統を全否定している。
C++11以後は、宿主を殺すウイルス的な存在に成り下がった一例。

**デフォルトの名無しさん** · 2022/02/04(金) 11:28:12.62

http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
すこ

**デフォルトの名無しさん** · 2022/02/04(金) 11:33:17.83

>>110 みたいな爺さんは書き方変わるだけでアタフタw

**デフォルトの名無しさん** · 2022/02/04(金) 12:53:41.07

>>110
TYPE a{b};
↑これって何がうれしいの？
c++よく知らんので教えてほしい

**デフォルトの名無しさん** · 2022/02/04(金) 12:55:43.71

コンパイラ都合じゃね？知らんけど

**デフォルトの名無しさん** · 2022/02/04(金) 14:18:18.78

>>113
オブジェクトの定義に対して初期化子を与えると、オブジェクトの初期値を
決定することになるが、初期化子には次の4種類ある :
T a{b};
T a={b};
T a = v;
T a(v);
・このうち、あらゆる局面で利用できるのは、最初の T a{b}の形式のみ
　(なおこの形式はC++11で新しく導入された。)。
・一番大きな理由はこの形式は「縮小変換を許さないから」とされる。

ただし、ややこしいのが、Tの部分を autoにした場合は、T a{b}の形式は
落とし穴がされるので使うべきではないとされている。
なぜなら:
auto z1{99]; // z1は initializer_list<int>型になってしまう。
auto z2 = 99; // z2は、int型。

ところが、Tが具体的な型の場合には、T a{b} が推奨される:
int x1{99};　// 推奨される書き方。
int x1 = 99;　// 縮小変換があるので推奨されない書き方。

全く一貫性が無く、C++11が駄目な部分の一つ。

**デフォルトの名無しさん** · 2022/02/04(金) 14:21:57.65

>>115
[誤字訂正版]

オブジェクトの定義に対して初期化子を与えると、オブジェクトの初期値を
決定することになるが、初期化子には次の4種類ある :
T a{b};
T a={b};
T a = b;
T a(b);
・このうち、あらゆる局面で利用できるのは、最初の T a{b}の形式のみ
　(なおこの形式はC++11で新しく導入された。)。
・一番大きな理由はこの形式は「縮小変換を許さないから」とされる。

ただし、ややこしいのが、Tの部分を autoにした場合は、T a{b}の形式は
落とし穴が有るので使うべきではないとされている。
なぜなら:
auto z1{99]; // z1は initializer_list<int>型になってしまう。
auto z2 = 99; // z2は、int型。

ところが、Tが具体的な型の場合には、T a{b} が推奨される:
int x1{99};　// 推奨される書き方。
int x1 = 99;　// 縮小変換があるので推奨されない書き方。

全く一貫性が無く、C++11が駄目な部分の一つ。

**デフォルトの名無しさん** · 2022/02/04(金) 14:40:30.04

ふーん、レガシー言語は大変だね

**デフォルトの名無しさん** · 2022/02/04(金) 14:44:09.08

Rustはもっと最悪に汚い。
C++の最大の欠点は、仕様が難しいことに有るが、
Rustはさらに仕様が難しい。
よって、RustはC++をさらに悪くしたと言えて、改良には全くなってない。

**デフォルトの名無しさん** · 2022/02/04(金) 14:54:48.13

ふーん、レガシー脳は大変だね

**デフォルトの名無しさん** · 2022/02/04(金) 14:59:52.64

>>119
馬鹿は黙ってろ。

**デフォルトの名無しさん** · 2022/02/04(金) 15:11:33.72

つまり仕様が簡単な方が良いということ？

**デフォルトの名無しさん** · 2022/02/04(金) 15:17:49.19

>>119
ばーかｗ

**デフォルトの名無しさん** · 2022/02/04(金) 16:13:01.17

効きすぎだろwww

**デフォルトの名無しさん** · 2022/02/04(金) 16:23:37.19

c++は（ランタイム速度落とさなくても）できらぁ！ってなったらとりあえず入れるからな。
ある意味とてもガキくさいがそれはそれでありなポジションに到達してる気はする。

**デフォルトの名無しさん** · 2022/02/04(金) 20:04:05.51

そんな凄いんだったらもっと普及してるよねRust
でも現実はブビにもコボルにも負けてる泡沫言語

**デフォルトの名無しさん** · 2022/02/04(金) 20:40:31.16

単純に新しい言語だから累積となるユーザ数でまだ不利なだけ
2019年11月のasync導入で非同期プログラミングがまともに使えるようになってまだ2年余り
Linux OSのようにC++を頑なに拒否していたプロジェクトでもRustは受け入れられたように
C++に未来はないがRustには未来がある

**デフォルトの名無しさん** · 2022/02/04(金) 20:44:24.76

最後間違い
C++に未来はないがRustも未来はない

**デフォルトの名無しさん** · 2022/02/04(金) 20:49:40.24

日本は先進国の技術トレンドから5年以上遅れてるからね

**デフォルトの名無しさん** · 2022/02/04(金) 20:53:24.16

C++erはレガシー脳が多いから

いい意味でのレガシーね
オリンピックレガシーみたいなw

**デフォルトの名無しさん** · 2022/02/04(金) 20:54:41.42

C++はあんなみすぼらしいラムダ式用意して哀れやわ
貧乏の家の子が自家製ボタモチもって突っ立ってるようやわ

**デフォルトの名無しさん** · 2022/02/04(金) 21:01:52.67

Rustやってる奴は現状アーリーアダプターで普及するにしてもまだ年月掛かると思う
んでその間にまた新しい言語が開発されみんなそっちに移って行くと

**デフォルトの名無しさん** · 2022/02/04(金) 21:06:34.54

新しい言語はどんな問題解決してくれるんだろうな
動的型付けが復権するんだろうか

**デフォルトの名無しさん** · 2022/02/04(金) 21:15:25.28

>>131
アーリーアダプターは数年前の時期
今は大手IT各社GAFAMがRustに本腰

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/
Facebook(現Meta)が「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/

**デフォルトの名無しさん** · 2022/02/04(金) 22:59:18.87

>>131
それならそれで無駄にはならない気がするが
考え方は継承されるだろうし

**デフォルトの名無しさん** · 2022/02/05(土) 01:30:11.76

SNS見てる限り、若い人でも人気は Rust より C/C++ の圧勝。

**デフォルトの名無しさん** · 2022/02/05(土) 02:39:36.18

大学の課題とかはまあC/C++よね

**デフォルトの名無しさん** · 2022/02/05(土) 06:15:36.04

>>133
RustはVisual studioでデフォルトで選択できるようになったら普及するだろうな

**デフォルトの名無しさん** · 2022/02/05(土) 09:06:42.96

北京五輪と東京五輪の開会式をプログラミングで例えるとどうなるやろ？

**デフォルトの名無しさん** · 2022/02/05(土) 16:44:42.87

そのまま普通に
東京五輪 Rust
北京五輪　C++

**デフォルトの名無しさん** · 2022/02/05(土) 17:35:54.33

東京五輪 FAMILY-BASIC

**138** · 2022/02/06(日) 17:01:26.43

ちょっとセンシティブな話だったか
与太話と思ってスルーしてくれ
すまんかった

**デフォルトの名無しさん** · 2022/02/10(木) 11:18:14.49

>>139
Rustってそんな酷い言語だったんだ
手出さなくて良かったわ～

**デフォルトの名無しさん** · 2022/02/10(木) 11:25:47.65

Rust 拝金主義
C++ ハイキング

**デフォルトの名無しさん** · 2022/02/10(木) 20:10:06.55

RustはC,C++を駆逐すると思う。アレに拘泥する理由はない。

**デフォルトの名無しさん** · 2022/02/10(木) 21:00:13.02

HighKingの至高の頂に座居するC++に勝てると本気で思っているのかね

**デフォルトの名無しさん** · 2022/02/10(木) 21:47:05.33

>>144
過去資産があるから駆逐まではいかないかな。
でももっと利用されるだろう。
けど非同期のやつとかの分断をどうにかして欲しい。

**デフォルトの名無しさん** · 2022/02/10(木) 21:50:08.15

ジワジワと侵食して気が付いたらいつの間にか利用していたって広がり方するんだろうな

**デフォルトの名無しさん** · 2022/02/10(木) 21:51:34.38

>>116
これ見てクソ言語だなって思わないヤツいるのかね。

**デフォルトの名無しさん** · 2022/02/10(木) 21:53:35.73

>>116
なんでこんな言語が使われるようになったんや？

**デフォルトの名無しさん** · 2022/02/10(木) 23:38:10.62

>>149
使われるようになったんじゃなく、既に使われてた言語を過去との互換性を崩さずに変更しようとして/変更してそうなったんだよ。
その変化は今なお止まってないんよ。

**デフォルトの名無しさん** · 2022/02/10(木) 23:40:02.53

>>149
はい
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

**デフォルトの名無しさん** · 2022/02/11(金) 01:30:20.07

>>149
C++が最初に使われ始めたころは、T a{b}のような記法はなく、
C++11で登場した。
使われ始めたころのC++はCの後継として丁度良いと思われるようなもので
あって、>>116のような変な仕様は入ってなかった。
最初は良かったが、後を突いていくと時々「え？」と思うような仕様が入り込み、
C++11で如実になった。
・templateの仕様も「え？」と思うことが多いものだった。
　Stroustrap氏によれば、高速化に重点を置いて導入されたものらしいから、
　分かり易さは犠牲になっているようだが、それにしても分かりにくいことが多い。
・C++にはライブラリが無かったので、C++11で導入されたが、それが
　賛否の分かれるもので、恐らく6割くらいの人には質が悪く感じるものであった。

**デフォルトの名無しさん** · 2022/02/11(金) 07:42:26.56

www.mercari.com/jp/search/?keyword=hr400p
こういう安い中古チューナ買って、Coinyをスカパープレミアム放送のICカード化して、
スカパープレミアムのチャンネル全部見れるし、USB HDDに録画フリー。
【avoCADO】 Coiny card Part4【仮想通貨】
https://mevius.5ch.net/test/read.cgi/avi/1640762750/

**デフォルトの名無しさん** · 2022/02/11(金) 11:09:11.39

C++は必要な機能だけ使ってれば問題ないことが多いが、
コンパイルエラーメッセージがやばすぎる
まともな言語とは言えない

**デフォルトの名無しさん** · 2022/02/11(金) 11:36:27.12

アレは読むんじゃない
詠むんだ

**デフォルトの名無しさん** · 2022/02/11(金) 11:39:59.37

>>154
逆にRustのコンパイラのエラーメッセージは手厚く至れり尽くせりで感度もの

**デフォルトの名無しさん** · 2022/02/12(土) 01:52:06.05

>>154
C++は、学者がtemplateメタプログラミング関連などの理論的な正しさを
見せびらかしているだけの様な気がするよ。
「ほら、これでメタプログラミングができるだろ、俺の理論の正しさがわかったか」
みたいに。

**デフォルトの名無しさん** · 2022/02/12(土) 01:53:21.86

ただ、だからといってRustがその代わりになるということではない。
RustはRustでC++以上に問題を入れ込んでしまった。
これもまた机上の空論の様な言語。

**デフォルトの名無しさん** · 2022/02/12(土) 09:46:16.21

>>158
机上の空論でない言語は何よ？

**デフォルトの名無しさん** · 2022/02/12(土) 10:21:13.78

アセンブラとC言語
使わないけどFORTRANとCOBOLもそうかな

**デフォルトの名無しさん** · 2022/02/12(土) 10:44:19.07

>>160
ADAは？

**デフォルトの名無しさん** · 2022/02/12(土) 11:06:25.45

>>159
横やけど
俺もC言語だと思ってる。

**デフォルトの名無しさん** · 2022/02/12(土) 11:24:57.04

>>161
Ada は（少なくとも出た当時は）けっこう机上の空論ぽい機能てんこ盛りだった

**デフォルトの名無しさん** · 2022/02/12(土) 11:27:00.51

Cは貧弱すぎだろう。いまさらmallocとか書く気もおきん。

**デフォルトの名無しさん** · 2022/02/12(土) 12:03:28.21

>>158
C++の問題よりはマシだろ

**デフォルトの名無しさん** · 2022/02/12(土) 12:07:09.85

前にこれをC++スレかどっかで発言したら結構叩かれたけど
C++って結局はテンプレートが言語の真ん中にあるよな
他の言語色々やった上であらためてC++見ると俺にはそう見える
一応マルチパラダイム言語だからC++しかやったことない人は
テンプレートだけをフォーカスされるのは不服っぽいけど

**デフォルトの名無しさん** · 2022/02/12(土) 12:08:32.56

テンプレートは強力だよな

**デフォルトの名無しさん** · 2022/02/12(土) 12:12:41.52

Cではちょっとしんどいです
いろんなコンテナ使いたいです
そんとき型をパラメータ化したいです
ハゲ「テンプレートでみんな幸せ」
C++er「やったぜ」

C++規格の関係者「いろいろ仕様につっこんだぜ！」
C++er「あっはい」

**デフォルトの名無しさん** · 2022/02/12(土) 12:42:37.24

>>166
概ね同意
テンプレートは便利だけど使いすぎてワケワカメってなりがち

**デフォルトの名無しさん** · 2022/02/12(土) 13:44:38.22

Rustでバブルソート書いてみたがすげー書きやすいな
食わず嫌いだったかもしれん
コンパイルエラーがめっちゃわかりやすい

**デフォルトの名無しさん** · 2022/02/12(土) 13:57:38.37

ほんとかよｗ

**デフォルトの名無しさん** · 2022/02/12(土) 14:50:46.51

バブルソートw

**デフォルトの名無しさん** · 2022/02/12(土) 15:04:29.49

バブルソートw
笑うとこかよ

**デフォルトの名無しさん** · 2022/02/12(土) 15:45:26.65

確かにエラーは笑っちゃうくらい親切だわな

**デフォルトの名無しさん** · 2022/02/12(土) 16:16:36.29

rustのエラー報告は全てのプログラミング言語で最高の親切さだと思う
他の言語がサボりすぎなんだよな
rust書くと他の言語かけなくなる

**デフォルトの名無しさん** · 2022/02/12(土) 16:54:42.98

そんなバブルソートバカにせんでもよかろうに
大学一年で最初の方に習うし、初めての言語触るにはまあまあ良い題材では

**デフォルトの名無しさん** · 2022/02/12(土) 17:44:36.13

少しいじってcombソートにしたらクイックソートにもひけをとらないしな。

**デフォルトの名無しさん** · 2022/02/12(土) 17:55:38.68

Rustで双方向リストをマージソートでソートするとかだとめんどくさいことになる気がする

**デフォルトの名無しさん** · 2022/02/12(土) 18:09:42.02

バブルソートがすげー書きやすいってどのへんが？
逆にそんなもん書きにくい言語なんてあるの？
fn main() {
let mut v = vec![8, 4, 3, 7, 6, 5, 2, 1];
let bsort = |v: &mut Vec<i32>| for i in 0..v.len() {
for j in 1..v.len() - i {
if v[j] < v[j - 1] {
v.swap(j, j - 1)
}
}
};
bsort(&mut v);
println!("{:?}", &v);
}
↑書いてみた
細かいところは日本語版wikipediaに準拠

**デフォルトの名無しさん** · 2022/02/12(土) 18:12:12.77

ソートの話はどうでもよくて要点はRustに対してのこの部分だと受け取ったが

>>170
> 食わず嫌いだったかもしれん
> コンパイルエラーがめっちゃわかりやすい

**デフォルトの名無しさん** · 2022/02/12(土) 18:34:19.97

>>180
同意

**デフォルトの名無しさん** · 2022/02/12(土) 19:15:40.31

バブルソートは理解が難しいわりに現実に使われんのがな。
それだったらクイックソートをだな。

**デフォルトの名無しさん** · 2022/02/12(土) 19:50:02.51

>>182
> バブルソートは理解が難しい
えっ？

**デフォルトの名無しさん** · 2022/02/12(土) 19:53:57.23

>>183
頭の良さは人それぞれなんだから馬鹿にしない

**デフォルトの名無しさん** · 2022/02/12(土) 21:02:43.90

ダブルアレイは原理が簡単にもかかわらず、十分バグが取れるまでずいぶん時間がかかった。

**デフォルトの名無しさん** · 2022/02/12(土) 23:07:39.79

CPU時間をたらふく使うバブリーなソートだよな

**デフォルトの名無しさん** · 2022/02/12(土) 23:55:25.98

>>180
Rustはコンパイラが出すエラーメッセージが詳しすぎて解決案まで示唆してくれたり親切すぎる
他のコンパイラ言語だけでなくインタプリタ言語まで広げても一番親切なプログラミング言語システムだと断言できる

**デフォルトの名無しさん** · 2022/02/12(土) 23:56:38.45

まあC++にテンプレートないならそこまで使わんわな

**デフォルトの名無しさん** · 2022/02/13(日) 01:14:02.16

Stroustrup氏の脳内では、テンプレートの目標が高速化であるということなのが
問題の始まりの気がする。

**デフォルトの名無しさん** · 2022/02/13(日) 01:20:30.65

マクロ=高速化用途で使われているもの
という見方が如何にも実用プログラムを書いたことの少ない学者だと思う。

**デフォルトの名無しさん** · 2022/02/13(日) 09:42:52.30

C++からテンプレート取ったらなにも残らない

**デフォルトの名無しさん** · 2022/02/13(日) 09:51:25.60

いや残るだろ

**デフォルトの名無しさん** · 2022/02/13(日) 10:12:41.48

STLなくなっちゃう

**デフォルトの名無しさん** · 2022/02/13(日) 10:25:11.79

>>186
その代わりメモリーは使わないから貧乏な俺でも使える

**デフォルトの名無しさん** · 2022/02/14(月) 23:17:34.32

>>179
そういうことではなく
おそらく>>170が言いたいのはコンパイラが出すエラーがめっちゃ親切なことだろう
こっちで書き換わってるからここにmutを付けなさいとか
ここで所有権が移動したのに後で使用してるからここに&を付けなさいとか
これをuse宣言するのを忘れてますよとか
この変数は宣言されず使われていますがこの変数名のスペルミスではありませんかとか
といった簡単なものから
複雑な借用関係をちゃんと登場人物たちをはっきりさせてあっちとそっちがこれこれでマズいのでこうしてみたらどうかなど
こんなにきめ細かく親切なエラーを出すコンパイラ＆インタプリタは他の言語と比べてもトップではないか

**デフォルトの名無しさん** · 2022/02/15(火) 00:19:44.75

>>151
デマは辞めようね

**デフォルトの名無しさん** · 2022/02/15(火) 00:24:28.01

>>195
同意

**デフォルトの名無しさん** · 2022/02/15(火) 07:23:31.22

>>195
そこは目から鱗だよな
ここまでできるなら、他の言語も頑張れよと言いたくなる

**デフォルトの名無しさん** · 2022/02/15(火) 07:51:21.06

言語として所有権の概念がないからその辺りの指摘はしないけどVS2022のC#も結構色々提案してくれるぞ

**デフォルトの名無しさん** · 2022/02/15(火) 09:28:59.50

このながれでこれを言う意味なんてないけど
わかるやつだけわかってくれたらいいんだけど
Rustのコンパイラ昔は酷かったよな
無慈悲なボローチェッカと戦ってたよな(´；ω；｀)