次世代言語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(日) 18:27:44.09

>>269
たしかにRustでRc/Arcが使われるのは限定されたケースのみではあるが、
例えばスレッド間での共有では使わざるを得なかった。
しかし来月リリースのRust 1.63では、スコープ付きスレッド生成(spawn)がstableとなるため更に使用頻度が減ることになる。
これにより参照カウントを使わずとも共有(借用)できるようになり、Rustの高速化と利便性が更に進む。

**デフォルトの名無しさん** · 2022/07/24(日) 18:30:59.25

>>351
1000個アロケーションされることと1000回アロケーションされることの区別もつかない馬鹿は黙ってろw

**デフォルトの名無しさん** · 2022/07/24(日) 18:33:44.43

論点がズレたからもう一度まとめておく
Goでは無意識的にヒープにアロケーションされてしまう可能性がある
それはエスケープ解析をしないとわからない
つまりメモリ使用量も実行効率も落ちる
これは一般論
恣意的な特定のベンチの数字を言ってるわけではない
rustは明示的にヒープに置くように書くのでそのようなことは起きない
つまり理論的にはrustが1番速いし最高の言語
もう一度言うが特定のベンチの話をしているのではない

**デフォルトの名無しさん** · 2022/07/24(日) 18:35:55.52

>>353
だからお前はメモリ使用量の話をしてたからだろ
それに配列の話はしてない
何度も言わせるな
どこに配列と書いた？

**デフォルトの名無しさん** · 2022/07/24(日) 18:41:01.38

もう一度まとめておく
おれに喧嘩を売ってきたやつはメモリ使用量と実行効率をわかってないと言ったが以下のように考えている
メモリ使用量については1000個ヒープにアロケーションされる可能性があるGoが不利
そして実行効率もヒープアロケーションによってGCが動くため悪い
シンプルすぎる当たり前のことを言ってるだけなのだから単に喧嘩を売りたいだけか？
まあ論破ごっこも自爆で負けとるが

**デフォルトの名無しさん** · 2022/07/24(日) 18:44:26.04

しつこいと言われるかもしれんが特定のベンチマークの話をしているのではない
もっと普遍的で一般論の話をしている
なのでこのベンチの結果は～というのは受け付けない
同じように普遍的な理論で話してくれ
rustの普遍性は理想的な言語モデルなんだよ

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

メモリの安全性
メモリの自動解放
スタックヒープを意識したコードを書ける
実行効率
モダンな構文
これら全てを満たした奇跡のような言語
今のところ勝てる言語は存在しない

**デフォルトの名無しさん** · 2022/07/24(日) 18:50:46.35

結局アンセーフを使ってしまうから無駄

**デフォルトの名無しさん** · 2022/07/24(日) 18:51:09.20

唯一の欠点はC++とのInteropぐらいだ
なのでCarbonの存在意義は理解できるが
その代償としてメモリ安全性を失ってしまった
これでは元の木阿弥
まあInterop特化言語だろうからそれで良いのかもしれん
普通の人はrustで良いです

**デフォルトの名無しさん** · 2022/07/24(日) 18:55:55.77

しつこく言ってるが特定のベンチマークの結果だけで鵜呑みにするのは間違っている
ソフトウェアに必要なのは普遍性なんだよ
そう言う観点で語ると一つ上の議論ができる

**デフォルトの名無しさん** · 2022/07/24(日) 18:58:18.60

rustはゼロコスト抽象化とメモリ安全性という「普遍性」から生まれた
優れた開発者は必ずこの普遍性を設計に取り入れてる

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

言語と言語が対戦する異世界があればどちらか一方は必ずハッピーエンドだが
現実は違うんだよな
C++でできなかったことをRustにやらせても、できない理由の方が多い

**デフォルトの名無しさん** · 2022/07/24(日) 19:02:10.29

>>352
Rustコンパイラの進化が素晴らしいね
それら安全であるとコンパイル時に静的に確定できることの範囲をどんどん広げていってる
これは他のプログラミング言語には無い思想でまさに次世代言語
そしてそれら安全となった操作がコスト最小で実行できるようになるのだからRustが安全最速を独走

**デフォルトの名無しさん** · 2022/07/24(日) 19:28:58.17

>>355
メモリー使用量？
細かい実装上の差異を除けばヒープに取ろうがスタックに取ろうが同じだぞ
必死に連投する前にちょっとは勉強してこい

**デフォルトの名無しさん** · 2022/07/24(日) 19:30:50.45

>>350
AndroidのカーネルってLinuxの取り組みとは別にRust導入してるの？
それともカーネル以外の低レイヤー領域の話？

>>359
まだunsafeを一カ所でも使ってしまうと台無しになる論唱えてるの？

**デフォルトの名無しさん** · 2022/07/24(日) 19:39:14.02

プログラムが使用するメモリの総量の話をするなら
そもそもスタックにはたかだかプロセスのスタックサイズ分のデータしか載らないので
メモリ使用量の観点でスタックとヒープの差違を議論しても有用な比較にはならないのでは
メモリ使用量に占めるデータと管理領域の比率という意味ならスタックの方が良いだろうけど

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

IO待ちが主体のプログラムでそのメモリ効率とやらがボトルネックになることはないといってるのでは？

>>255
でメモリ効率がいいからパフォーマンスがいいとか言ってわけだけど、そんなことよりIOがボトルネックになるからいかにブロックしないように書く方が大事ってのはまさにそうだね

そのメモリ効率云々ってのが重視されるのって組み込みとかでWebサーバーなどでそんなのどうでもいいに決まって

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

>>366
Androidは新しいBluetoothスタックとかDNSリゾルバなんかがRustになってるよ

**デフォルトの名無しさん** · 2022/07/24(日) 20:39:49.97

まるでRustのネガティブキャンペーンやってるようだな

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

IOバウンドなプログラムでRustを積極的に採用するメリットなんかほとんどない
Goが現在ではベストな選択、次点でNodeなわけだけどなんでかっていうと
GoはC言語+GC+並行処理ってなぐらいでものすごいシンプルだから。
普通の手続き言語触ったことがあるなら、並行処理以外は全く覚えることはないから1週間あればすぐにチーム開発に参加できるぐらいの容易さがあるわけ。
エンタープライズではまずこの容易さがないと流行らない。

それに比べRustはまず並行処理がランタイムに組み込まれておらず、tokioとかいうライブラリを使うわけだけど
そもそも並行処理以外の言語部分での学習コストが高すぎるから、C++での豊富な経験でもない限りチーム開発の戦力になることは難しい。
tokioもGoみたいに抽象化されていて簡単に扱えるわけじゃないからこれも非常に学習コストが高い。

そもそもそんなパフォーマンスが重要ならC++で非同期プログラミングでもやればいいわけだけど、こんなのやってソフトウェア作ってる企業なんてほとんど存在しない。
つまりバカでも扱えるような言語ではないと企業で流行ることはない。(OS開発などは別)
DenoはRustで作られてるけどバカではRustは使いこなせないからわざわざ労力をかけてDenoを作ってるんだよ
Rustが優れてるからDenoがいらないとはならない。

Rustはあくまでも選ばれし人間にのみ使われる言語。自称玄人が背伸びして使う言語ではない。

**デフォルトの名無しさん** · 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にさえ使われています。

これマジ！？