次世代言語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(日) 07:13:10.20

>>298
RustにはWebプログラミングには不要な要素が多いって言ってんだろ
文盲乙

OS開発しないのに細かいメモリ管理をプログラマにまかすのは完全に不要な負担である
これはまつもとひろゆきもいってる

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

とにかくWebやバックエンドといった高レイヤー層でRustが流行ることはないのは事実である
論破してみろよ自称玄人は
具体的に移行している企業もDiscordしか知らないみたいだし、Discordでも一部の部分しか採用してない

〇〇の機能があるから優れてる自慢はHaskellやScalaでも起こってた、でも流行らなかった

流行るのはGoやPythonのように機能を削った言語

RustにはOS開発など低レイヤーには必要な要素が詰まっているが高レイヤーでは不要なものだらけである、だから普及しないんだよ自称玄人さん

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

確かにWebでどうなるかはよくわからないな
ひょっとしたらJavaみたいにエンタープライズが使い出すのかもしれん
Webとの関連でいうと個人的にTauriには大いに期待している

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

自称玄人はOS開発やドライバ開発など低レイヤーの経験など一度もないのに、畑違いであるRustを使ってるだけにアイデンティティを感じている孤独なおっさん
だから高レイヤー層では流行らない言われても論理的に反論できず、他言語を貶めて他人にマウントを取ることしかが脳がない
Rustを使っていることが唯一のアイデンティティの哀れなおっさん

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

俺もWeb周りで使われるのはかなり限定的になるんじゃないかと思うな。良い言語だけど採用しただけの価値が出る領域はかなり狭いよ。

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

Web と一括りにしてる時点で議論の対象にならんクズレスでしかない

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

valeのGenerational Referencesって面白くない？
https://verdagon.dev/blog/generational-references
所有者は一つだけだけど非所有者の参照はいくつも持てる。
各ヒープメモリに世代カウントを付けて、参照はポインタ+世代カウント+オフセット値のようなデータになる。
参照先にアクセスするときはヒープの世代カウントと参照の世代カウントを比較して不一致だったら解放されたメモリにアクセスしたと見なせる。
参照をコピーするときは参照カウンタのようなカウントを増減する必要は無い。参照をそのままコピーするだけ。

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

ときどき現れる、自分んとこにRustがやってくるのが怖くて吠えまくるおじさん
Rustが使えるだけでマウントなんてとるわけないのに、劣等感で震えすぎ

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

>>317
これほんとか？
This is cheaper because programs dereference less than they alias and dealias

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

>>318
やってこないから（笑）

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

>>319
それは確かに怪しいっぽい

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

前はRustなんてどの領域でも採用されないと主張していた
その後は大手は採用しないとか、言語オタクしか使わないとか言い出して、今はwebに来ませんようにとお祈りしてる

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

いや、使われていないだろう。

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

黒魔術を禁止したいRust。
それはものすごく正しい。
Javaと同じ理念なので、Javaと同じように成功するだろう。
しかし、黒魔術使いがRustを使いたいと思うこともないだろう。

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

魔導士がRustを作ったが、魔導士はRustを使わない。

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

>>322
WebAssemblyが普通になってきたらRustが来るかもね

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

>>324
黒魔術が具体的に何を指してるか分からんがunsafeではだめか？

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

webassemblyは
高レイヤーのC++を変えなくても低レイヤーの機械語を変えれば安全になるという
C++を高レイヤーと見抜けない人には難しい技術

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

>>310
swiftは個別スレあるだろう

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

>>317
こういうレスを待ってた

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

>>311
Matzなのか
ひろゆきなのかw

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

ここは次世代か現世代に限らず言語マウンティングしたいやつらの巣窟

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

メモリ管理アルゴリズムを変えるたんびに言語を変えるのをやめよう
ライブラリを変えればいいだけ

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

>>267
難しいのですかね？
下みたいなアプリがあったのでできるのかと思ったのですが、、
なにか特殊な方法が必要なんでしょうか
https://play.google.com/store/apps/details?id=forinnovation.phoneaddiction&hl=ja

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

不正確：ここは次世代か現世代に限らず言語マウンティングしたいやつらの巣窟
ここはRust言語マウンティングしたいやつら（ただしコーディング能力はゼロに近い低め）の巣窟、まともに話し合うことすら不可能

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

>>307
Kotlinは次世代から卒業したと思ったらオワコン化しちゃったか。
Javaは緩やかに衰退しているし、頼みのAndroidもFlutterに持っていかれそう。

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

RustはOSの開発でもあんま使われてないよね
でも将来JavaみたいなIT土方専用言語になりそうな気がする

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

>>333
メモリ管理周りは標準ライブラリのインターフェースにも影響するけど
標準ライブラリすげ替えたらそれはもう別言語では

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

土方うんぬんはマウンティングではなく職業差別だよな
差別された業種はプロよりアマの方が強くなる
これ資本主義への挑戦だろ

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

>>317
> valeのGenerational References
> 参照先にアクセスするときはヒープの世代カウントと参照の世代カウントを比較して不一致だったら解放されたメモリにアクセスしたと見なせる。

それは重すぎる設計で実用的ではないですね
C++のshared_ptrもRustのRc/Arcも
参照先にアクセスするときは参照カウントへのアクセスがなくコストゼロです
RAIIによる自動解放時にようやく参照カウントを見てヒープも解放するか判断します
やはりC++のshared_ptrとRustのRc/Arcの方式が最も優れた方式と言えるでしょう

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

>>268
理解目来てないのはお前
「1000個ヒープにある」んだよ
まず文章を読め

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

>>300のスレにコピペしといたで続きはそっちでお願いな

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

>>341
まじでプログラマに向いてないんだなw
ヒープアロケーションが1,000回かどうかなんて書いてないだろ
配列で一気にアロケーションしてるかも知れんしな

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

そもそもRustというかスタックベースのRAIIって結構ヒープアロケーションしてるからな
生存スコープの管理にスタックを使ってるだけ

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

>>336
google的にもflutterをメインにしたいんじゃないかと邪推してる。

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

>>337
今それを言ったらOSのカーネル開発で使われてる言語なんてC以外あるんかね？

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

研究でだったらhaskellでだってカーネル開発あるけどな

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

> スタックベースのRAII

ほかに何ベースのRAIIがあるの？

> 生存スコープの管理にスタックを使ってるだけ

変数のスコープを静的に解釈してデストラクタ呼び出しを追加してるだけでは？
スタックをいつどうやって使うの？

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

メジャーどころのOSのカーネルだとCかC++かアセンブリだよね
かろうじてLinuxにRustが取り込まれそうだけど当面はドライバのみで使途は限定的

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

>>349
LinuxだけでなくAndroidもRust導入した

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

>>343
見苦しい言い訳をするな
1000個アロケーションされてると書いてるんだから1000個アロケーションされてるんだよ
配列がどうとかの話は言ってない
お前が読み飛ばした部分だよ
適当にしか読んでないから飛んだんだろ
人の文章を読みない上に話を変えようとしてる
お前こそがプラグラマに向いてないぞ
残念ながらお前の負け

**デフォルトの名無しさん** · 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は次世代じゃないんですよ。