次世代言語26 TypeScript Swift Go Kotlin Nim

**デフォルトの名無しさん** · 2022/06/21(火) 09:27:46.30

スレタイ（順番はRedMonk準拠）以外の言語もok

※　Rustは現世代最強言語なので除外します

前スレ

次世代言語25 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/07/24(日) 21:27:37.48

>>371
おまえはGoとNode以外に何が使えるの？
比較対象をきちんと列挙せずに自分だけで完結してベストとか言われても困る

**デフォルトの名無しさん** · 2022/07/24(日) 21:34:55.30

RustはJavaの遺伝子を受け継ぐから組み込みやウェブでも流行するだろ。
Androidアプリの開発言語に採用されるかもしれん。
Javaではありませんよ言語とか苦しい言い訳しないで済むし。

**デフォルトの名無しさん** · 2022/07/24(日) 21:37:15.31

picojavaのようにpicorustプロセッサが出来るかもしれませんよ。
と思ったらすでに在った。

**デフォルトの名無しさん** · 2022/07/24(日) 21:40:01.27

5chで次世代言語と言えば、織田信長しかないんだけど。
忘れてやしませんか？
それとも意図的に無視してんの？

**デフォルトの名無しさん** · 2022/07/24(日) 21:43:31.89

>>371
その用途ならばRustがオススメです
Goとの比較で言えばRustの方が高速かつ省メモリにすることができるだけでなく
Goの貧弱な言語仕様とは異なりRustは開発効率も高いです

NodeとDinoはJavaScriptなのでそれらよりも遅くメモリも多く必要とするだけでなく
Worker以外はシングルスレッドの中でしか展開できない限界もあります

**デフォルトの名無しさん** · 2022/07/24(日) 21:45:28.55

Denoは言語じゃないだろ
なんでRustと比較できるの？

**デフォルトの名無しさん** · 2022/07/24(日) 21:46:24.07

マジでヤベェやつしかいないww
次世代老人スレ

**デフォルトの名無しさん** · 2022/07/24(日) 21:46:25.88

パラダイムシフトです。

**デフォルトの名無しさん** · 2022/07/24(日) 21:47:28.08

次世代老人とは、今は老人ではない、つまり若者のことである。

**デフォルトの名無しさん** · 2022/07/24(日) 21:49:59.66

>>377
それはRust批判をしている>>371さんがRustを叩くための棍棒として持ってきているだけだからでしょう

**デフォルトの名無しさん** · 2022/07/24(日) 22:03:49.93

>>381
アンカーつければ良かったな
>>377はもちろん>>371に言ってるよ

**デフォルトの名無しさん** · 2022/07/24(日) 22:25:39.05

>>375
おれも大学でGHC/KL1やったことあって、5ch関係なくその辺なんとなく好きだからせめてリンクを貼ってやろう
https://www.fun.ac.jp/~hirata/Papers/spa99-on-slides.pdf

**デフォルトの名無しさん** · 2022/07/24(日) 23:05:50.30

>>340
shared_ptrとarc/rcが参照カウンタを増減するのは参照をコピーするときとそれがスコープ抜けるときだけどその前後に参照先にアクセスするとは限らないので参照カウンタにアクセスするときにキャッシュミスが発生するかもしれない。
generational referencesではdereferenceするときだけ参照先の世代カウンタを読むので、世代カウンタにアクセスしたときは必ず参照先にアクセスする。キャッシュミスが起きても世代カウンタと参照先が同じキャッシュラインに存在する可能性が高いのであまり問題にならない。
generational referencesは参照カウンタと違ってヒープを確保するとき以外はメモリに書き込みを行わない。
なので単純に遅いとは言い切れないと思う。

**デフォルトの名無しさん** · 2022/07/24(日) 23:34:47.76

>>384
実際のプログラミングを考えれば分かるように、その利用のほとんどが参照先にアクセスすること。
つまり解放の頻度が非相対的に常に低いのが特徴。
なぜなら、解放の頻度が高くてすぐに解放されるような用途ならばヒープは使われないか、ヒープわ使ってもunique_ptrやBox等で多くは済む。
つまりshared_ptrやRc/Arcが使われるのは比較的に長期に保持されて解放の頻度は相対的にも低い。
いずにしても、「解放の頻度」よりも「参照先へのアクセス」がプログラムで起きる頻度の多い主流な出来事。

「参照先へのアクセス」のコスト
【shared_ptrとRc/Arc】コストゼロ (参照カウントは全く使用されない)
【valeのGenerational References】コストが高い (ヒープの世代カウントと参照の世代カウントを比較が必要)
したがってC++/Rustの方法が有利。

**デフォルトの名無しさん** · 2022/07/24(日) 23:36:40.59

いえいえ、C++はそんな魔法のようなことはできませんよ。
物理法則を超越するのはRustだけです。

**デフォルトの名無しさん** · 2022/07/24(日) 23:59:50.37

>>386
Rustでは出来ている

**デフォルトの名無しさん** · 2022/07/25(月) 00:06:36.72

RustのRc<T>のソースコードを見てみた
参照先へのアクセス時つまりTへのアクセス時には参照カウントは全くノータッチ
つまり>>385で正しいようだ
参照カウントは解放のためだけに使うものだから普段は使わないのは当たり前か

**デフォルトの名無しさん** · 2022/07/25(月) 00:40:50.97

したがってこのRust叩きしてる人がウソをついていた

>>264
> Rc<T>で無駄なメモリアクセスが起きてることを分かってない。
> 参照カウントで、かなり無駄なカウントアップ・ダウンが現実に起きてるし非効率。

正解は解放時にようやく初めてカウントダウンつまり1を引いて0と比較するだけの小さなコスト

**デフォルトの名無しさん** · 2022/07/25(月) 01:06:45.81

んなわけないでしょ。

**デフォルトの名無しさん** · 2022/07/25(月) 01:17:32.30

誰も問題にしてない問題の解決をありがとう
それで参照の複製と破棄のコストは？

**デフォルトの名無しさん** · 2022/07/25(月) 01:24:22.28

>>385
shared_ptrとかRCのような参照カウンタ方式は参照がスコープ抜けるときだけじゃなく参照を増やすときに参照カウンタを+1してるでしょ。

**デフォルトの名無しさん** · 2022/07/25(月) 01:26:08.06

ええええ！
そこ？？

**デフォルトの名無しさん** · 2022/07/25(月) 01:38:55.49

>>391
それは完全にコストゼロ
Rustでは(Rc/Arcの参照を含めて)参照を使ってもその参照を破棄(自動的)しても付加コストはかからない
対象がRc/ArcであろうがそのRc/Arc内の参照カウントを見ることは当然ない

例
let x = Rc::new(123);
let xx = &x;　// xの参照
foo(xx);
ここでxの参照が複製されて関数fooに渡される
当然Rcの内部の参照カウントの読み書きは発生しない
コストはゼロ

**デフォルトの名無しさん** · 2022/07/25(月) 01:40:09.84

>>392
いいえ
参照するだけならカウントを増やしません

**デフォルトの名無しさん** · 2022/07/25(月) 02:08:28.73

Rustユーザーはこのレベルか。
エアユーザーと認定する。

**デフォルトの名無しさん** · 2022/07/25(月) 02:13:24.40

おまえは何もわかってない。セマンティックムーブを備える言語の複数の所有権では意味が違う...
392が言ってるのは文脈で言ってる参照は、明らかに複数の所有権のことであり、コピーされた値とは違う。
参照カウントである以上、アルゴリズム的にどんな言い訳をしてもカウンタの上げ下げでボトルネックは生じるものであり
それを認めずにこういう馬鹿がゼロコストだとか現代のコンパイラー型言語で多くがやってることを、意味不明に連呼して
言語の普及に不利益を与える。
いい加減こんなバカなことは考え直せ

**デフォルトの名無しさん** · 2022/07/25(月) 02:20:06.89

>>396
君たちRustアンチが壮大な勘違いをしていることが今回わかった
参照で参照カウンタが増えていくと思い込んでいたのか

Rustでは参照をいくつ増やしてもコストが全くかからない
Rustには所有権とライフタイムがあるため参照カウントを増加させるなどは全く不要で参照についてはコストが全くかからない
もちろん参照先へのアクセスについてもそのような付加コストはかからない
これがRustの強み
コストをかけずに安全＆高速なのがRust

**デフォルトの名無しさん** · 2022/07/25(月) 02:30:53.81

ここの狂信者は389のようなことを言う。
例えば「正解は解放時にようやく初めてカウントダウンつまり1を引いて0と比較するだけの小さなコスト」のようなことを言うが
264の言うことと全く矛盾しない。たとえ参照カウントが1だとしても明らかにstrong countの上げ下げは発生しており
これが参照カウントのアルゴリズムでは常に問題になる。多くの場合大きな問題は表面化しないが良くある通例として
プログラム終了時に参照カウントの０が連鎖するため非常に時間を要するなどの場合がある

日本に良くいるタイプで1つでも否定句を入れると、発狂したように「嘘だッ！」と食って掛かる。
例えば「Cargoが不味いのでRustはコンパイルが、同様の10年以内に現れたGoやVと比べ遅いね」というと
「Rustは速い！ふざけんな！」と発狂し、最後にはCargoバンザイと礼賛まで始める...
これがgithubや海外フォーラムだと
これ遅くね？→確かに遅い→どこが遅いのか→なら遅いからどうするか
という改善すべき提案までされるのに、ここにいる気持ち悪いこのような輩はそんな事をしない。
壊れたレコードよりも高性能なＣＤのように永遠と同じことを繰り返す、ゼロコスト！強み！安全！
ゼロコストは多くのコンパイル型言語でほぼ同様であり、Rustの公式自体も認めているがRustはメモリーリークを認めているし
メモリリークそのものを安全として処理する。これを強弁して「メモリーリークが起こらない！」と言い張るのは明らかにおかしい

**デフォルトの名無しさん** · 2022/07/25(月) 02:41:14.40

>>394
その例と説明はRcとは何も関係ないよね
例えばfooが&RcではなくRcを取り、fooを呼んだ後もxを使うとしたら？

実際にはこうしたプログラムフローじゃなくて、データ構造的要請から参照カウンタを使う選択をとるのが多いとは思うけど

**デフォルトの名無しさん** · 2022/07/25(月) 02:47:14.81

魔導士はstd::shared_ptr<>を使うことになったら設計を疑えと心得ている。

**デフォルトの名無しさん** · 2022/07/25(月) 02:48:21.55

Rustに対して無知な人が、何を勘違いしてRustを叩いているのか、ようやく理解できた。
稀にしか登場することのないRcをなぜか連呼して叩く理由もわかった。
複数の参照がある場合に、Rcを使う必要があると勘違いしてるわけだ。
そして参照の数だけカウンターが増える、と勘違いしてるわけだ。
参照カウンタ方式のGC言語とは異なり、Rustではそんな無駄なことはしていないです。

**デフォルトの名無しさん** · 2022/07/25(月) 02:50:11.86

> Rustでは参照をいくつ増やしてもコストが全くかからない

こういうのが反論されてるだけでは？

**デフォルトの名無しさん** · 2022/07/25(月) 02:56:01.87

>>403
それで合ってる。
Rustで参照は数値型と同様にコピー可能で、数値型のコピーと同じコストしかかからない。
いくつ参照を増やしても同じ。
参照カウンタは出てきません。

**デフォルトの名無しさん** · 2022/07/25(月) 03:02:58.57

C++にもstd::unique_ptr<>とstd::shared_ptr<>があるけど、C++のスマートポインタはゼロコストでいくらでも参照を増やせると言えば反論されるでしょう。
Arcの欠点を指摘されるとまるでそれがArcの特徴であるかのようにRcの解説をし、Rcの欠点を指摘されるとまるでそれがRcの特徴であるかのようにArcの解説をする。
それがまずいのでは？

**デフォルトの名無しさん** · 2022/07/25(月) 03:07:04.80

基本的にRustは余計なことが出来ないように設計されているので、PythonやJavaのように使われるようになると思います。
初心者向きに良く練られていると思います。

**デフォルトの名無しさん** · 2022/07/25(月) 03:07:39.44

>>401
それも正しい。
多くのプログラムではshared_ptrやRcを必要としないことが多い。
その『設計を疑え』に従って、本当に必要なのかを一度見直すことは必要。

**デフォルトの名無しさん** · 2022/07/25(月) 03:08:57.43

↑
しかし、知ったかぶりの初心者を量産してしまったのは、Rustの罪の部分ですね。

**デフォルトの名無しさん** · 2022/07/25(月) 03:14:13.96

>>405
Rustの参照、つまりC++で言うところのunique_ptrは、Rustではコストゼロです
コンパイラによりライフタイムと借用ルールに反していないと保証されて、参照は単なるポインタ(アドレス)になります
アドレス以外の付加情報を持つファットなスマートポインタではありません

**デフォルトの名無しさん** · 2022/07/25(月) 03:16:23.43

しかしそれではGC付き言語のマナーでプログラムする人には使いにくいでしょう。
Rustは次世代じゃないんですよ。

**デフォルトの名無しさん** · 2022/07/25(月) 03:19:01.13

コンセプトが入った以上、C++は次世代です。
progress_displayが入れば世界最新だったのですが。
なかなか採択されませんね。

**デフォルトの名無しさん** · 2022/07/25(月) 03:23:21.39

>>409
ほとんど合ってるけど
C++に関するところだけちょっと違う
unique_ptrに相当するのはRustでは自動的に無条件でその機能を持つことになる
もちろん付加的な情報を必要としない
いずれにせよBoxでもVecでもStringでもRustで参照は複数いくつでもコスト無しで持てる
もちろん参照カウンタは必要としない

**デフォルトの名無しさん** · 2022/07/25(月) 03:36:04.97

Rustではライフタイムの概念の導入によって参照が複数いくつもあろうがコスト無く扱える
ライフタイムを超えた参照が存在しないことをコンパイルが通れば保証されるため
参照が複数あっても参照カウンタなどの付加的なコストをRustは必要としない

**デフォルトの名無しさん** · 2022/07/25(月) 03:50:26.54

>>413
Rcの参照て、実装的にポインタのポインタにならんの？
まぁ、大したコストじゃないけど。

**デフォルトの名無しさん** · 2022/07/25(月) 03:54:57.80

顔真っ赤になってほとんど人がいない深夜に、これをやる。マトモだと思いますか？
こんな事書いてる暇があるなら、ましなコード書けよ。おまえの汚いコードで大勢が苦労してんだよ

**デフォルトの名無しさん** · 2022/07/25(月) 04:30:16.31

>>414
何の参照を欲しいかに依る
中身の参照を欲しいならば
let x: Rc<i32> = Rc::new(123);
let p: &i32 = x.as_ref();
これで直接ポインタ
もちろん参照カウンタが増えることもなくコストはかからない

**デフォルトの名無しさん** · 2022/07/25(月) 04:35:50.04

Rust叩きしてる人の頭の中はこんな感じの妄想か

複数の参照を利用　→　参照カウンタが必要となるはずだ！　→　Rcを使う必要があるはずだ！

もちろんこれは間違いで
Rustでは複数の参照を利用しても
参照カウンタもRcも不要

**デフォルトの名無しさん** · 2022/07/25(月) 05:58:18.25

それじゃそもそもRCって何で存在しているの？
何の為に参照カウンタがあるの？

**デフォルトの名無しさん** · 2022/07/25(月) 06:15:33.82

Rustの話題はRustスレでやった方がいいんじゃね？
なんかもうRustって見るだけで吐き気がしてきた

**デフォルトの名無しさん** · 2022/07/25(月) 06:18:34.46

>>419
嫌なら無視するしかない
反応する人がいるということは需要があるということ

**デフォルトの名無しさん** · 2022/07/25(月) 06:25:52.20

>>418
Rcは滅多に使われない
もし使っていたら多くのケースで効率の悪い下手な設計の場合が多い
Arcはスレッド間の共有メモリなどで使う

**デフォルトの名無しさん** · 2022/07/25(月) 06:37:19.48

ただし>>352の来月のRustリリース情報から
スレッド間の共有メモリをArcを使わずとも通常の借用参照で済むようになるケースが出てくると思われる
つまりArcの利用も減少する

**デフォルトの名無しさん** · 2022/07/25(月) 06:39:01.08

>>418
俺に反論できなくなったので、要らないことになったのでは？

**デフォルトの名無しさん** · 2022/07/25(月) 07:13:41.21

>>376
言語仕様が豊富なら開発効率がいい（笑）なら
なんでScalaやHaskellは流行らないの？

**デフォルトの名無しさん** · 2022/07/25(月) 07:39:05.16

>>424
速いとか省メモリとか何か動機がないと

**デフォルトの名無しさん** · 2022/07/25(月) 07:55:15.70

>>425
なんでC++はNodeやGoに変わって使われないの？

**デフォルトの名無しさん** · 2022/07/25(月) 08:06:04.72

>>426
安全じゃないと

**デフォルトの名無しさん** · 2022/07/25(月) 08:21:13.01

>>427
それだけが理由か？
学習コストは？IOバウンドだからメモリ効率云々にかけるコストに意味がないからなのでは？

つまりRustはNodeやGoを置き換えないね

はい論破

**デフォルトの名無しさん** · 2022/07/25(月) 08:52:04.73

>>428
君は自分で言ってることがデタラメめちゃくちゃだと気付いていないのかね
論破とだけ強調する人物はキチガイが多いと聞くがそうなのかね

**デフォルトの名無しさん** · 2022/07/25(月) 08:59:06.96

>>429
キチガイではなく一般論を話しているのみ。Nodeが流行った理由知らないのか

単語をカウントするプログラムのベンチマークをした記事

Goがシンプル版、最適化版両方Rustより速いようだけどRust玄人さんはこれどう解釈するの？
メモリ効率がいいから速いんじゃねーの？
https://benhoyt.com/writings/count-words/

Goがライターが書いていて、Rustはripgrepの作者が作ってるみたいだけどｗ

**デフォルトの名無しさん** · 2022/07/25(月) 09:31:41.84

>>408
量産て全部同じやつだぞ
Rustスレでは誰も相手にしなくなった自演魔

**デフォルトの名無しさん** · 2022/07/25(月) 09:33:37.20

>>421
グラフとかどうやって実装すんの？
配列とインデックス？

**デフォルトの名無しさん** · 2022/07/25(月) 09:39:39.23

>>430
非最適化版はC++も遅いことを考えるとRAIIの性質として遅いんじゃないか？
細切れにメモリの解放が入るからな

**デフォルトの名無しさん** · 2022/07/25(月) 09:40:42.26

>>418
普通にデータなどを格納するコレクションを作るときに直接使用する、例えばVecとか
上のほうで書いてある「Rcが滅多に使われない」は大変な間違い。
多くのプログラムは間接的にほぼ間違いなく多く使用している、もちろん全く使用しないプログラムもあるがそちらのほうが例外。
当然、参照カウントはセマンティックムーブのある言語で所有権の複製時にはカウントアップされる
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=39acf5e2c625c2e5ccd8f9cca466f64c
スキル学習で分かりにくいのは、この種の言語の一般的な用語である「（ただ単に）参照」とは所有権の複製ではないという事
対して「可変参照」をとる場合、mutableな借用とされ参照カウントが0/1以外にもカウントアップされる。よって参照カウントが
実行時にボトルネックになる可能性があるという話は正しく、無意味に「コストゼロ、コストを必要としない」などを連呼する事は
とても近寄りがたい雰囲気を醸し出す

普通は中身を見るだけではなく格納している値を処理するので、可変参照を使うので、参照カウントがコストが無いなんていう
ふざけた説明は論外。この種の宗教的な勧誘は「コストゼロ、コストを必要としない」などを連呼する狂信性を発病する

**デフォルトの名無しさん** · 2022/07/25(月) 09:47:57.99

>>434
「所有権の複製」とか言っちゃうと
君もその狂信者こと複製おじさんと同じになっちゃうよw

**デフォルトの名無しさん** · 2022/07/25(月) 10:02:55.50

>>428-429
基本的なことを全くわかってないでなんでも独自解釈で間違った判断してると思うわ

なんでも狂っていたりそう簡単にぶっ壊れたりするもんじゃないから、
自分の予測と違った結果になったら基本的な用語とか使いかたを勉強し直さないと先に進めないと思う

**デフォルトの名無しさん** · 2022/07/25(月) 10:10:53.79

>>435
Rustはプログラマーへ負担を大変に強制する言語でありながら、問題解決している分野はとても狭い....
メモリーを限界まで使用してアクセスが高負荷な環境では確かに良いかもしれないが
Pythonなどの自動学習ライブラリ(多くはC/C++で書かれる)やNodeやTypescript/JSなどが主流であるフロントエンドには非常に使いづらい。
またスマートフォンのアプリ開発も出来なくは無いが両陣営からあまり重視されていない、最近では大企業も使用をしているが
Googleなどは多くはまだメニーコアを素直に活用できるGoを使用する（社内の標準言語）
ここまで否定的なことを、ハッキリ言える狂信者は居ないとおもう

**デフォルトの名無しさん** · 2022/07/25(月) 10:31:51.75

C/C++は危険だよ問題という
狭い問題のために過大なコストを消費するのは
Rust以前の時代からあった非合理的行動なんだよな

**デフォルトの名無しさん** · 2022/07/25(月) 11:25:18.08

新興勢力の宣伝の常套手段の一つ
既存の勢力を貶めること
個人的には好きではないしむしろ忌み嫌うやり方

**デフォルトの名無しさん** · 2022/07/25(月) 12:45:23.61

>>430
Nimが良いな。

**デフォルトの名無しさん** · 2022/07/25(月) 12:55:06.04

Nim++
Nim#

**デフォルトの名無しさん** · 2022/07/25(月) 14:26:21.66

>>437
Rustはれっきとした機械学習のライブラリや言語処理系を*作るため*の言語だよ
Rustは機械語を吐くコンパイラやトランスパイラのようなものに向いてるし
それってフロントエンドが今必死になって取り組んでる分野ではないの？
簡単に書けて省メモリかつ速い言語なんてないよ
夢見すぎ

**デフォルトの名無しさん** · 2022/07/25(月) 14:42:37.10

>>441
Nimが十分抽象表現できてるからNim++は意味ねーだろ

**デフォルトの名無しさん** · 2022/07/25(月) 14:47:29.52

>>437
Pythonの自動学習ライブラリはフロントエンドではない
さらに多くがC++で書かれている自動学習ライブラリに対してRustが非常に使いづらいと主張するなら根拠を書くべき
C++が多いのは長年の時間の差だけであり現在はPythonからRustを呼び出すこともできるようになったので今後は色々と出て来るだろう

**デフォルトの名無しさん** · 2022/07/25(月) 15:03:49.84

自動学習？

**デフォルトの名無しさん** · 2022/07/25(月) 15:20:21.13

>>434
デタラメな説明はよろしくないな
君はRustを叩きたい側だからだろうが根本的な理解ができていない
特に酷いのは「所有権の複製」
Rustにそんな概念も用法も無い

Rcが滅多に使われないというのは事実
様々なRustのライブラリ(クレート)を見てもRcの出現は非常に少なくArcよりも圧倒的に少ない
Arcが多い理由はマルチスレッドでデータを共有するためで別々の所有者だから
Rcはシングルスレッド用だから別々の所有者を必要とすることが非常に少ない
まれにRcを必要とすることもあるが本当に必要なのかをまずは疑うべき

さらにRc/Arcでカウントアップ／ダウンは滅多に起きない事象であるため負荷を批判するのもおかしい
例えばマルチスレッド間のデータ共有でArcを使うとしてもスレッド生成で＋１されスレッド終了で－１されるのみだからスレッド生成に対して誤差である
このように新たな所有主体が現れること自体の負荷と比べて数値を＋１することは誤差

**デフォルトの名無しさん** · 2022/07/25(月) 16:01:59.92

>>414
これはいい質問

>>416
これはダメな回答

詳しく知りたい人はRustスレでどうぞ

**デフォルトの名無しさん** · 2022/07/25(月) 16:04:20.43

>>446
>特に酷いのは「所有権の複製」
>Rustにそんな概念も用法も無い
複製おじさんのオマエが言うなよwww

**デフォルトの名無しさん** · 2022/07/25(月) 16:06:38.58

>>432
例えばC言語でグラフを実装する時も生のポインタのみで実装されることはありません
なぜなら各ノードのメモリを解放するタイミングがわからなくなるためです
そこで主に三つの方法が取られます

一つは各ノード一覧を配列などで持っておくとともに定期的にルートから到達可能か到達フラグを用意します
そしてノード一覧の中で到達フラグが立っていないものをメモリ解放します
この方法の欠点は4つあり
(1) ノード一覧を管理する配列が別途必要となる
(2) 到達フラグが必要となる
(3) 定期的に到達可能かを調べる必要がある
(4) 使われなくなったノードがすぐには解放されない

もう一つの方法は定期的コピー方式です
ルートから到達可能な部分を定期的に別の場所にコピーします
コピーされなかった部分が到達できない使われていない部分なのでまとめて解放となります
この方法の欠点は
(1) この方法も定期的な実行が必要となる
(2) メモリ空間が2倍必要となる
(3) 使われてる全体が定期的にメモリコピーされる負荷
(4) 使われなくなったノードがすぐには解放されない

残りの方法は参照カウンタ方式です
おなじみなので略します

いずれの方法も様々な欠点があります
このグラフのノード解放問題は
ガベージコレクションを必要とするプログラミング言語にそのまま当てはまります
GCの負荷コストを理解していただけましたでしょうか？

**デフォルトの名無しさん** · 2022/07/25(月) 16:46:22.65

>>446
このように顔真っ赤になって、怒り心頭で攻撃してきます、激おこぷんぷん...マジでRustコミュニティはこういう輩の扱い考えたほうが良い....

>特に酷いのは「所有権の複製」
頭から「君はRustを叩きたい側だからだろう」という下種な勘ぐりを持って色眼鏡で相手と話し合う事はできませんし、これ以上
狂者を相手をするつもりもありませんが、デタラメ/間違いなら、より正しい言葉で説明したら良いじゃない？
なぜ1番先に書いたことを無説明で流し、Rc/Arcなんかの長文説明でグチグチ言ってるんです？
下のコメで「メモリーを限界まで使用してアクセスが高負荷な環境では確かに良い」と認めているのがあなたの目には見えませんか？

>Rcが滅多に使われないというのは事実
RcはStringにさえ使われています。あなたから薄ら頭に付いてる目から見える「事実」は隠されたライブラリの中に存在しているようですが
そこでもArcの話なんてしていません。Rcのスレッドセーフ版がArcなだけで、グダクダと口臭いArcの説明なんて誰も求めていません。

さらに参照カウントの一般的な欠点を説明しているのに、「批判するのがおかしい」と「誤差」なんてそれだから一般的なプログラマーから
ドン引きされるんですよ。

**デフォルトの名無しさん** · 2022/07/25(月) 16:51:48.53

>>450
> RcはStringにさえ使われています。

これマジ！？

**デフォルトの名無しさん** · 2022/07/25(月) 17:01:49.95

>>451
https://doc.rust-lang.org/src/alloc/string.rs.html
pub struct String {
　vec: Vec<u8>,
}
これだと言葉足らずですが、リテラルから生成するString::fromなどはこのようになります

**デフォルトの名無しさん** · 2022/07/25(月) 17:05:57.06

>>450
> RcはStringにさえ使われています。

嘘つき！
RcはStringで当然使われていないだけだなく
Rust標準ライブラリの中でも(Rc自体の
部分を除き)Rcは全く使われていない

一般的にもRcは使われることが少ない
もちろんRcを使うべき例外も一部あるがRcを使う前に構造の見直しを勧める

**デフォルトの名無しさん** · 2022/07/25(月) 17:28:44.47

標準ライブラリでRcが使われてないのは
オーバーヘッドを嫌ってunsafeを使った代替実装が使われてるからだぞ

**デフォルトの名無しさん** · 2022/07/25(月) 17:32:52.00

>>430
RustよりGoのほうが速いやんけｗｗｗｗ
Goしゅごいｗｗｗ

**デフォルトの名無しさん** · 2022/07/25(月) 17:35:20.01

人を嘘つき呼ばわりするキチガイを使う前に見直しを勧める
Rustは一人でやる分には良いけど、こういう奴とは絶対組みたくない、stdしか見えないアホ、ドアホォ
std::collectionsにないコレクションを使いたければ自分で実装するかgithubなどで拾ってくる必要があるのに、お前の顔見直せよ

**デフォルトの名無しさん** · 2022/07/25(月) 17:57:22.48

>>452
そのStringにもVecにもRcは使われていないね

>>454
Rust標準ライブラリでRcが使われていないのは所有者が複数存在するという特殊な状況が発生しないため

>>456
外部ライブラリにはRcを使っているものも存在するけどその少なさに驚くと思うよ
これはシングルスレッドで所有者が複数存在するという特殊な状況が滅多に発生しないため

**デフォルトの名無しさん** · 2022/07/25(月) 18:18:18.06

>>454
ライブラリ内部の実装に依存するなよ
抽象に依存しよう

**デフォルトの名無しさん** · 2022/07/25(月) 18:57:52.01

Python代替を狙いたいなら、脳死スニペットコピペで、
Excelファイルが編集できて便利ね。くらいを目指さないと無理じね？

**デフォルトの名無しさん** · 2022/07/25(月) 19:33:13.71

自分で使わないならダメじゃん？
Rc。

**デフォルトの名無しさん** · 2022/07/25(月) 19:37:10.91

だいたい、Haskell全然流行っていないじゃんか。
世界のすべてがHaskellに代わるんじゃなかったのかよ？
Rustが流行るとか言われてももう信じられんわ。
D言語だって全然流行らなかったし。

**デフォルトの名無しさん** · 2022/07/25(月) 19:48:55.75

結局一番使える凄いやつはExcel VBAだと思うね。
一番役に立つじゃん。

**デフォルトの名無しさん** · 2022/07/25(月) 19:54:28.52

>>460
RcをRust標準ライブラリや多くの外部ライブラリが使っていない理由は、Rcがダメだからではなく、
Rcが対象とするシングルスレッド環境においては、所有者が複数となることがない、もしくは、避けられることが多いため。
使わなくてよい時は使わず、どうしてもRcを使う必要がある時のみ使う、という当たり前の行動の結果。

**デフォルトの名無しさん** · 2022/07/25(月) 19:55:45.54

言い訳は要らないんだよ。

**デフォルトの名無しさん** · 2022/07/25(月) 19:56:57.83

RustよりGoのほうが速いじゃん。

**デフォルトの名無しさん** · 2022/07/25(月) 20:00:32.25

こんな遅いんだったらRustなんか使うんじゃなかったってみんな言ってるわ。

**デフォルトの名無しさん** · 2022/07/25(月) 20:06:54.34

>>466
RustはC++よりも速い結果が出ることも多い中で何を言ってるんだ？？

**デフォルトの名無しさん** · 2022/07/25(月) 20:08:53.16

>>449
延々と変なことを書いてるなとしか

**デフォルトの名無しさん** · 2022/07/25(月) 20:16:00.56

RustはHaskellの後継言語では？
口だけ番長みたいな。

**デフォルトの名無しさん** · 2022/07/25(月) 20:18:22.01

速い遅いは1bit的な100パーセントの保証ができないからね
逆に、変数の型を全く書かない、ゼロを保証するPythonのようなものは誠実な印象になる

**デフォルトの名無しさん** · 2022/07/25(月) 20:29:29.58

>>455
それ測定方法がおかしい
解いていないとはいえ、grepが一番速くて、次にwcが速くて、それらはC言語で書いたものより速くなっている
解いているシェルスクリプトですら1.83秒しかかかっておらず、Rubyの最適化版に至ってはシェルスクリプトより遅い結果となっている
最適化版のコードも一人が提供しただけであり、これでは意味がなかろう
その程度の課題でプログラミング言語間の時間比較に意味あるのか？