次世代言語22 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2021/08/22(日) 08:59:03.31

スレタイ以外の言語もok

前スレ
次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/

**デフォルトの名無しさん** · 2021/11/08(月) 21:09:44.36

>>520
助言ありがとう。早速病院に行ってきた

医者「それで……本日はどのような件で？」

俺「循環参照を考えなければいけなくなったので、検査してもらってもいいですか？」

医者「？？？？？どういうことだね？」

俺「だから……！！！循環参照を考えないといけないんです！！！検査してください！！！」

医者「だめだこりゃw」

とりあえず精神薬は貰えるっぽい。ありがとうな

**デフォルトの名無しさん** · 2021/11/08(月) 21:15:19.22

>>519
基本的なことを理解していないのはあなたです、それはメモリー安全性ではありません。メモリー安全性は
バッファオーバーフローなど配列の添え字や境界を超えてアクセスを許してしまう事です。（または無効な
アドレスを許してしまう）簡潔に説明出来ないのはあなたが言い訳しているからです。

あなたが説明しているのはRustのRAIIを言っているに過ぎません。当然それはメモリー安全性ではありません
これはファイルのクローズ処理などでも限定された処理を自動化しますが、解放を強制しているだけです。
またこのRAIIの自動リソース資源の解放も万能でありません。ある意味では、メモリー（他の資源を含む）
リーク回避策の実装（解決策の１つであり唯一ではない）でしかありません

**デフォルトの名無しさん** · 2021/11/08(月) 21:20:36.74

>>521
それも全く同じです
ライフタイムが尽きたのにその参照を維持してままだから生じた問題です
ライフタイムを管理する言語ならばそのケースも同様にコンパイラがそのコードの問題を指摘します

**デフォルトの名無しさん** · 2021/11/08(月) 21:27:40.83

>>523
落ち着きましょう
様々な原因(スコープを外れたり再利用のために)自動開放されてしまったものへの参照を維持し続けてしまい発生するその問題は明らかにメモリ管理使用ミスの問題でありメモリ安全性の問題です
あなたが主張するバッファオーバーフローはメモリ安全性の問題の一つに過ぎません

**デフォルトの名無しさん** · 2021/11/08(月) 21:29:14.32

>>524-525
じゃあ世の中にメモリー安全性を謳う他の言語の本家に文句言って、この言語たちはメモリー安全ではないと
ホームページを書き換えろと文句言いなさいよ。どうせ相手にしてもらえませんがね
RAIIをアピールするならまだしも、それをメモリー安全性なんて言って勘違いし他を暗に危険だと貶める行為は
とても褒められませんし、なんの意味もなく必死なアピールが嫌悪を伴います。正当なアピールでさえ、最近は
ウザいと嫌がられますよ？

「ライフタイムが尽きたのにその参照を維持してままだから生じた問題です」
ライフタイムが尽きたと考えられるのはGo言語のソースでRust的なコードの見方をしているからです。何度も
言っているように参照で渡したデータの寿命は尽きていません。

**デフォルトの名無しさん** · 2021/11/08(月) 21:36:44.29

>>526
>> 何度も言っているように参照で渡したデータの寿命は尽きていません。

寿命が尽きて参照先が再利用されてしまい参照が無効状態になっていることをマジで理解できないのですか？

**デフォルトの名無しさん** · 2021/11/08(月) 21:43:30.84

>>527
あなた自分の上げた記事さえ読んでいませんね？「参照が無効状態になっている」無効にはなっていません
$ ./test_gomistake
Values: 3 3 3
ですから問題が起こったのです。もうメモリー安全性でも私の逃げでもイイから勝ち誇って嫌われなさい
Rustには偉い迷惑な存在なので、もう相手しませんよ

**デフォルトの名無しさん** · 2021/11/08(月) 21:43:51.47

Goの変数は参照がある限り存在するからお前が全て間違ってる
はっきりして良かったな

**デフォルトの名無しさん** · 2021/11/08(月) 21:56:52.12

>>528
わかりやすいように1回目のiをi1と表現すると
i1への参照を他が持ったままi1は寿命が尽きて解放されてますよね
そして2回目のi2が同じ領域を割り当てられて別の値2となりそれも尽きて
最後に3回目のi3が同じ領域を割り当てられて別の値3となりそれも尽きて解放
つまりPrintlnした時点で未割り当ての領域の値3を指していますよね？

**デフォルトの名無しさん** · 2021/11/08(月) 22:12:26.06

C言語でもメモリ的に危ないコードにはunsafeってコメント書いとけば
rustと同じで安心安全だよね

**デフォルトの名無しさん** · 2021/11/08(月) 22:49:01.85

上から下までunsafeまみれになるわ

**デフォルトの名無しさん** · 2021/11/08(月) 23:13:31.22

GCにも矛盾はあるんだよ
参照できなくなったポインタの集合を参照できないならばGCの実装は不可能

現実的にはunsafeでweakな参照を使って無理矢理GCを実装している

**デフォルトの名無しさん** · 2021/11/08(月) 23:48:37.92

だからメモリ安全って言葉使うなって言ったのにｗ

**デフォルトの名無しさん** · 2021/11/08(月) 23:49:59.34

分煙と言えば
ミドリ安全です

**デフォルトの名無しさん** · 2021/11/09(火) 00:03:37.26

プログラマーってメモリが安全かどうかでずーーーーっと同じような話しててキモいわ
安全日とか危険日とかどうでもいいだろ消えろ

**デフォルトの名無しさん** · 2021/11/09(火) 01:09:11.48

>>521
そのバグ問題やってみたが興味深い問題だな。
func main() {
　var out []*int
　for i := 0; i < 3; i++ {
　　out = append(out, &i)
　}
　fmt.Println("Values:", *out[0], *out[1], *out[2])
}
上記のバギーなGoコードをそのまま普通に以下のRustコードにすると、
fn main() {
　let mut out = vec![];
　for i in 0..3 {
　　out.push(&i);
　}
　println!("Values: {} {} {}", *out[0], *out[1], *out[2]);
}
コンパイルエラーとなり「変数iの借用(参照)がforループの外で使われてる!」とライフタイムの問題。
そこで変数iを強引にループの外へ追い出して、この問題が起きないように以下のコードにすると、
fn main() {
　let mut out = vec![];
　let mut i = 0;
　loop {
　　if i < 3 {
　　　out.push(&i);
　　　i += 1;
　　} else {
　　　break;
　　}
　}
コンパイルエラーとなり「変数iが借用(参照)されたままで変数iを書き換えてる!」と書き換え競合の問題。
つまりRustは少なくとも2種類の方法でこの種のバグが生じないように防いでいるということか。

**デフォルトの名無しさん** · 2021/11/09(火) 03:57:16.61

どこかで拾ったGoの変な挙動を示すコード

slice1 := make([]int, 0, 5)
slice2 := slice1
for i := 0; i < 10; i++ {
slice1 = append(slice1, i)
slice2 = append(slice2, i + 100)
}
fmt.Println("slice1 =", slice1) // => [100 101 102 103 104 5 6 7 8 9]
fmt.Println("slice2 =", slice2) // => [100 101 102 103 104 105 106 107 108 109]

これはなかなか常人には理解しがたい

**デフォルトの名無しさん** · 2021/11/09(火) 04:12:13.75

実行してみると確かにそうなるな。なんじゃこりゃ

**デフォルトの名無しさん** · 2021/11/09(火) 05:02:02.91

>>538
常人には、というかsliceの仕様を知らないと全くわからんよ。理解してみればシンプル。

sliceはコピーするとバッファも共有されてしまう。
バッファのキャパシティを超えるまでは、同じバッファに書き込まれることになる。
下のページの Slice internals らへんをちゃんと読めばよくわかるよ。
https://go.dev/blog/slices-intro

そのコードの場合は、slice1とslice2はバッファが共有されていて、そのキャパシティは5なので、5番目の要素までは同じバッファに書き込まれてしまう。

そのあとキャパシティを超えるので、slice1とslice2でそれぞれ別々の新しいバッファがallocateされて、元の共有バッファの要素がコピーされる。
なので、6番目からは別々に書き込まれる。

> slice2 := slice1
ここのコードは slice2 := append([]int{}, slice1...) とかに変更すればバッファが共有されないので、違和感のない動作になるぞ。
https://play.golang.org/p/3fCafqo9L5v

このへんか、deferが実行されるタイミングとか、 >>521 らへんは初心者がハマる罠だな。
次にハマるのは goroutine とか channel 使ったときの race condition らへんだな。

**デフォルトの名無しさん** · 2021/11/09(火) 08:45:42.78

>>536
変数の型も書かないPythonが人気ナンバー1だからキモいのは少数派

**デフォルトの名無しさん** · 2021/11/09(火) 09:26:15.28

>>540
Goのスライスの諸問題は親スライス(＝元)と子スライス(＝バッファ部分がキャパシティを超えるまでは共有される)が同じスライスとして扱われるところにあるよな

一方でRustはそれをVec(＝親＝実体)とスライス(＝子＝部分参照)の2種類へ明確に分離して諸問題を防いでいる
さらにRustのスライスは親がVec(＝伸長可)でも配列(＝固定長)でも区別なく統一して使える
そしてスライスも参照の一種であるため「読み取り専用共有スライス」と「書き換え可能専有スライス」に分けることで並行＆並列処理での競合問題にも対処して安全な効率化を実現している

**デフォルトの名無しさん** · 2021/11/09(火) 09:57:47.67

わざわざmakeでキャパ5作ってるのに、その後に10未満までappendするなんて
バカゴミクズしかこんな事しない。
ほんとRustのせいじゃないのに、このバカゴミクズは何もわかってないので
早く市んでほしい。イメージ最悪

構造をもったコレクション構造と連続領域確保のアロケーションを比べるなんて
頭がどこまでもおかしくなればこんないい加減なことを言えるのか

**デフォルトの名無しさん** · 2021/11/09(火) 10:05:19.89

めっちゃ分かりやすくありがたい挙動ｗ

**デフォルトの名無しさん** · 2021/11/09(火) 10:06:48.86

比べるなら、配列やVecじゃなく、heap::allocate(size, align);なのに
長々と無駄な事を書いて、Vec::with_capacity(len);と比べているという
スパナと釘を比べて、どっちが安全と説いているバカゴミクズ勘違い野郎

**デフォルトの名無しさん** · 2021/11/09(火) 10:16:31.45

>>545
俺もクソみたいなRust推しはどうかと思ってるが
今回の件は君よりもそのゴミクズ野郎のほうが問題の本質を理解してる

**デフォルトの名無しさん** · 2021/11/09(火) 10:21:06.21

また顔真っ赤の何も言わない援護射撃が現れる

**デフォルトの名無しさん** · 2021/11/09(火) 10:23:15.72

C++なんてこれ1だからなｗ
#include <iostream>
struct s{};
int main() {
std::cout<<sizeof(s)<<std::endl; // 1
return 0;
}
理由は同じポインタ値を同じオブジェクトにしたいからだとｗ
言語仕様なんて実用本位でそんなもんｗ
ちなみにCは0ｗ
#include <stdio.h>
struct s{};
int main() {
printf("%ld\n",sizeof(struct s)); // 0
return 0;
}

**デフォルトの名無しさん** · 2021/11/09(火) 10:33:38.60

>>545
GoのスライスはRustのVecで合っている
どちらも以下の点で同じ
・3つ組で構成される(領域へのポインタ、確保されている長さキャパシティ、そのうち使用中の長さ)
・append/pushなどで長さは伸長することが出来る
・長さが伸長してキャパシティを超えると自動的にヒープ領域の再割り当てを行ないデータは移動する
・その時に3つ組のポインタ部分は当然変化する

>>545
>> heap::allocate(size, align);なのに

そのようなヒープ領域割り当てはとは異なる
GoのスライスとRustのVecはどちらも伸長して足りなくなるたびにヒープ領域の再割り当てを何度でも自動的に行なう
もちろん再割り当てが頻繁に起きないように大きく確保してそれがキャパシティ

**デフォルトの名無しさん** · 2021/11/09(火) 10:37:04.74

調べてきた
Cでは、構造体が名前付きメンバーなしで定義されている場合、プログラムの動作は"未定義"です。
ですから、処理系によっては0ではない違う値ということもあり得ます、なので0だ、というのは
少々違います。C++の場合、標準ではサイズ0 のオブジェクトは許可されないため値1を返します。
clangに-std=c++17でCのソースをコンパイルすれば1になります。

未定義動作が多い言語は確かによろしくないですが、それだけ多くの処理系がある事の裏返しです

**デフォルトの名無しさん** · 2021/11/09(火) 10:39:15.18

必死に顔真っ赤になってレス付けてくるけど相手にしません、読むのも嫌

**デフォルトの名無しさん** · 2021/11/09(火) 11:07:58.08

CとC++は実際違う言語だから、CのソースをC++の処理系にかけてもC++として処理されるだけｗ
gccでもclangでも言語オプションは-xなので、-x cでC言語、-x c++でC++になるｗ
Cなら-std=c++17ではなく-std=c17かなｗ
Cの場合古い分事実上の標準に合わせて標準化されてる感じが強いから未定義という扱いになるのは仕方ないｗ
実際gccでも警告すら出ず--pedantic-errors付けてようやく怒られる程度の話ｗ

**デフォルトの名無しさん** · 2021/11/09(火) 11:20:15.97

>>549
単体で使う限りGoのスライスとRustのVecは同じ構造も持ち同じ挙動だが
共有されると両者の挙動が異なってくる

Goのスライスは>>538のようにバッファ部分が共有されていると
別スライスでもキャパシティ限度内ならば書き換えや伸長があっても変化が共有される
そしてキャパシティを超えてバッファ部分再割り当ての時に二つに分岐してそれぞれが最終的にGCで回収される

Rustは競合回避のためsingle writer xor multi readersの原則があるので
RustのVecに書き換えや伸長が起きるときは共有されていない
だからキャパシティを超えてバッファ部分再割り当ての時は移動のみで旧バッファ部分は即座に解放回収

**デフォルトの名無しさん** · 2021/11/09(火) 12:35:36.43

goは比較的新しい言語とは思えないほど危険がいっぱいなんだな。rustどころかnimや crystalにも大きく劣る言語仕様なのに、信者が無理矢理な理屈で自分を騙してる印象

**デフォルトの名無しさん** · 2021/11/09(火) 12:36:57.75

>>540
素直にcopyか参照にしとけば良かったのにね。
効率求めるならCOWにした方が良さそう。なんでCOWにしなかったのかな？COWは並列処理とあんまり相性良くないけど。

**デフォルトの名無しさん** · 2021/11/09(火) 12:47:14.84

スケープゴートを用意し比較的人口の多いGoを攻撃する、Rustは悪くないのに"危険がいっぱいなこいつ"の悪辣性

**デフォルトの名無しさん** · 2021/11/09(火) 12:56:13.87

go最強！！！！

**デフォルトの名無しさん** · 2021/11/09(火) 13:08:33.41

>>554
信者が無理矢理な理屈で暴れてるのはRust信者だろ
そんなことしてるからいつまで経っても普及しないオタク言語止まりなんだよ

**デフォルトの名無しさん** · 2021/11/09(火) 17:57:07.15

capacity は、単なるデフォルト値だろ

別に、それを超えても良いのだろ？

**デフォルトの名無しさん** · 2021/11/09(火) 18:50:44.35

RustはD言語の再来と言われるほど期待されてる。

**デフォルトの名無しさん** · 2021/11/09(火) 19:55:55.57

倒してしまっても構わんのだろ？

**デフォルトの名無しさん** · 2021/11/09(火) 20:01:35.84

うんこ野郎の独演会

**デフォルトの名無しさん** · 2021/11/09(火) 20:12:33.83

>>559
超えていいよ。超えたときには別のバッファが作成されて、元のバッファの要素がコピーされる、ってだけだから。

キャパシティを意識するとしたら、このようなバッファ作成回数を減らしたいっていうような、パフォーマンスを意識するときが多いんじゃないかな。
普通は明示的にキャパシティを設定せずとも、デフォルトの2のべき乗サイズのキャパシティがいい感じのパフォーマンスになるけどね。

**デフォルトの名無しさん** · 2021/11/09(火) 20:57:16.81

スライス<T>型がユーザー定義型だったら
それは言語の欠陥ではなくユーザーのミスでしかなかったのに

スライス<T>型をユーザーが再発明できない原因をよく考えるべき

**デフォルトの名無しさん** · 2021/11/09(火) 23:26:26.60

>RustはD言語の再来と言われるほど

言われたくないだろうな

**デフォルトの名無しさん** · 2021/11/09(火) 23:33:50.69

注目度がだいぶ劣るけど後継は多分nimだから・・・

**デフォルトの名無しさん** · 2021/11/10(水) 01:07:58.28

C++の再来はありますか？

**デフォルトの名無しさん** · 2021/11/11(木) 10:10:47.29

去ってないから

**デフォルトの名無しさん** · 2021/11/11(木) 14:23:06.64

C/C++は簡単にやばいコードを書けてそれを発見するコストが高いという問題がある
特にC++は使いこなすための練度のハードルが高いせいか凶悪と言ってもいいｗ

**デフォルトの名無しさん** · 2021/11/11(木) 14:56:27.50

C++がよくあそこまで流行ったもんだよね
こうなる前に他の言語を作る動きはなかったのかしら。まあそれが1995年のJavaだったのかなあ。昔すぎて自分にはよくわからんけど

**デフォルトの名無しさん** · 2021/11/11(木) 15:12:54.92

むしろそれまではCしかなかった
Windowsが出てきて、その開発の主要言語でVisual C++が出てきたのでC++が流行った
と思ってる
インターネットが急速に発展したのはWindows 95以降だったので、それまでの流行りは処理系の人気に依存してた
と思う
その頃のUnix系や汎用機の世界までは俺も知らんｗ
勝手にUnix系はCで汎用機はCOBOLだったんじゃないかと思ってるｗ

**デフォルトの名無しさん** · 2021/11/11(木) 15:29:17.41

要は、スマホのように説明書不要と称する物を特許とか著作権とかの規制で縛って課金する方法と
本体を無料であげる代わりに分厚い説明書を買わせる方法がある

**デフォルトの名無しさん** · 2021/11/11(木) 17:04:48.90

>>571
なるほど。たしかにWindowsとVisual Studioがキラーアプリケーションだったんだ
MicrosoftがObjective-Cを採用してたら、Objective-Cがめちゃ流行ったんだろうし、やはりプラットフォーマーは強いな
MicrosoftかAppleのいずれかがLispを採用してたら、Lispの存在感も桁違いだったんだろうなあ。そういう世界線を見てみたい

**デフォルトの名無しさん** · 2021/11/11(木) 17:23:23.65

ネットの怪文書を処理する難度がC++よりも凶悪なのでC++が良心的に思える

**デフォルトの名無しさん** · 2021/11/11(木) 18:27:16.30

C++は諦めが肝心の言語
機能を全部使うと死ぬ

**デフォルトの名無しさん** · 2021/11/11(木) 19:54:16.99

関数型の言語は当時Unix系の開発者(学術系多め)がemacs lispを中心に好んで使ってたよ(開発ツールとして)
ただWindowsとPCの普及にともなってunixやemacs自体が段々下火になっていった
処理系とはIDEのことなので、IDEの開発効率とその付属ライブラリが言語選択の決め手ということ
当時はC++以外だとpascal(delphiなど)を使う人やVBを使う人がいた
appleは丁度ジョブスいなかったので低迷中だったかな
当時強かったのはMS/IBM/Sunあたりかなぁ
※個人の感想/主観であることに注意

**デフォルトの名無しさん** · 2021/11/11(木) 23:33:58.00

どうしてprologのことを無視するかなあ
80年代後半から90年代初頭にかけては
unixではprologの天下
Cよりも早くコーディングできた

**デフォルトの名無しさん** · 2021/11/11(木) 23:45:48.82

それ天下とはいっても流行してた、って意味じゃないよね？
GNUのソフトウェアもほとんどC言語だろうし・・・。

**デフォルトの名無しさん** · 2021/11/11(木) 23:50:14.50

prologはいいんだけどrust製prologのscryerとか見てるとISO準拠にこだわるのやめてくれと思う
文法とか組み込みオペレータ、組み込みプレディケートとかライブラリも新時代に合わせて工夫してほしい
昔ながらのコードをそのまま動かせる…
それは昔ながらのPrologで動かしてもろて…
じゃあprologじゃなくていいじゃんって？
そうだよ！基礎コンセプトそのままでガワを新しく整えたのがほしいんだよ！

**デフォルトの名無しさん** · 2021/11/12(金) 00:06:01.94

Prologが分かる奴はErlangもRustも分かるから早急に次世代に行けた

**デフォルトの名無しさん** · 2021/11/12(金) 02:10:18.26

prologなんて誰も使ってなかったよｗ

**デフォルトの名無しさん** · 2021/11/12(金) 14:30:35.33

>>579
それ、何てOz？
Oz触ったこと無いけど。

**デフォルトの名無しさん** · 2021/11/12(金) 14:41:26.85

swi-prologなら若干拡張されてるけど、prolog自体が昔からほぼ使われておらず
存在自体あまり知られてないし、結局手続き的思考が必要だし、用途が限定される使いにくい言語だと俺は思ってるｗ

**デフォルトの名無しさん** · 2021/11/12(金) 14:59:17.99

調べてみるとICOTとかいう、Prologをメインに使って、500億円も予算をかけたプロジェクトがあったらしいけど、なんだったんだろうな

**デフォルトの名無しさん** · 2021/11/12(金) 21:33:34.72

第五世代コンピューターと論理プログラミングを基にした現代の深層学習とは違う人工知能・・・ウッ頭が
つまりはアランケイのSmalltalkが最強ってことだろ？

**デフォルトの名無しさん** · 2021/11/13(土) 11:37:24.38

コストが高いか安いかでくるくる掌返すのはポジショントークだよな
しかもサンクコスト

**デフォルトの名無しさん** · 2021/11/13(土) 12:37:16.91

Prologは夢を見すぎたな
結局バグは仕様そのものとかいろんな理由で起きるというのに

**デフォルトの名無しさん** · 2021/11/13(土) 13:27:58.51

メモリ安全みたいなテーマに限定すれば夢が無限に大きくはならんだろ
夢を見たことではなくテーマを表す言葉を使わなかったことを反省しよう

**デフォルトの名無しさん** · 2021/11/13(土) 13:40:18.34

ループをすべて再帰で書くというのがちょっと難しいが
デバグが楽だし、保守もしやすい
ライブラリをどさっと作れば流行ったかもしれないな
のちのperl,javaのように

**デフォルトの名無しさん** · 2021/11/13(土) 15:45:12.67

>>589
末尾再帰ループ化できない再帰はスタックが溢れる
最近はループを更にわかりやすくイテレータ連鎖で書くのが主流だね

>>588
Rustの発想は目からウロコだった
他の言語たちが最初からガベージコレクション前提にしてた状況でGCなし言語があそこまで出来るとは驚き

>>587
論理宣言型言語は結局は現実のCPU命令手続きとのギャップを処理系でカバーするも効率面も厳しく

**デフォルトの名無しさん** · 2021/11/13(土) 16:19:14.47

また過大評価してGC無しなんて言うけど理論上は参照カウントはGCアルゴリズムだし、そんなのは原始的で
最も基本のGCに分類される。仮にこれから今のRc系のGCに参照カウントGCの非同期が搭載されたりすれば
その動作はスイープマーク系や世代別GCに近くなる。（その可能性は少ないが）現在なぜ良い結果が出るかと
いえば構造上、連鎖的な多量GCが少なくなるために、スループットが高くなる事だけ。
レテンシーで見ればJavaやC#のGoなどの処理は毎回GCするとは限らないので、その分だけ処理が速い

**デフォルトの名無しさん** · 2021/11/13(土) 16:22:04.94

君、頭悪いでしょ

**デフォルトの名無しさん** · 2021/11/13(土) 17:00:56.00

末尾呼び出し最適化が保証されてる言語でのみ
枕を高くして再帰で書きまくれるというもの
ocamlはいいぞ

**デフォルトの名無しさん** · 2021/11/13(土) 17:01:06.08

>>591
まずほとんどのデータは参照カウントで管理しないから極一部のケース対象にしか論じていないね
次に参照カウントゼロ時に即座に解放する場合はガベージが一度も発生しないためガベージコレクションとは通常言わないです
最後に列挙しているGC言語はC/C++/Rustよりもベンチマークでも遅いですね

**デフォルトの名無しさん** · 2021/11/13(土) 17:14:56.21

末尾再帰はプログラミングテクニックではなく、コンパイラ等におけるコード最適化の技術です。
（多くは手続き言語における自己呼び出しをTailに変形してスタック消費をゼロにしたりする）

「ループを再帰で書く」まったく意味ないどころか、言語問わず末尾再帰最適化が未実装のコンパイラ等では
弊害しかありません。「イテレータ連鎖？で書く」は普通のループ大きく変わりませんが、言語によりけりで
手続き言語では非同期処理やサイドエフェクトのある処理では上手く書けません。

そもそもPrologの一階述語論理における再帰処理というのは再帰定義自体が、関数型プログラミングの元と
なる論理型プログラミングで、多くの普及している手続き言語のような弊害がないために成り立つだけです。

**デフォルトの名無しさん** · 2021/11/13(土) 17:29:13.45

>>594
(1)多くの言語のデータ管理はヒープとスタックです。スタックには（よほど特殊なOSでない限り）違いがありません。

(2)「参照カウントゼロ時に即座に解放する場合」意味のある日本語で書きましょう、開放すると言っておきながら
ガベージが無いといったり、RustであればRc<T>やArc<T>で参照カウントゼロ時は確保してないということです。

(3)「ベンチマークでも遅い」例えばCPUのベンチマークだって幾つも項目がありますが、その中のスループットは
高い（near =早い）と言っているのです。一方でレテンシーは遅いのです。

なぜそんなに強引に推し通したいのか、理解不能です。

**デフォルトの名無しさん** · 2021/11/13(土) 18:05:59.35

ベンチマークの数値ってもうRustのコンパイルエラーと同じぐらい意味不明と思われてるね
Prologさんを500億の言語にしても誰もほめてくれないし

**デフォルトの名無しさん** · 2021/11/13(土) 18:55:57.32

GCなければキャッシュの効果は高くなりそうだけどねｗ

**デフォルトの名無しさん** · 2021/11/13(土) 19:58:21.21

>>596
おそらくC++やRustを使ったことがないのだろうけどC++のshared_ptrやRustのRc Arcを使うのは所有者が複数になる特殊ケースのみ
それらのみが参照カウンタを用いるけど所有者がいなくなった時点で自動的にリソース解放される
これをGCと呼ぶ人はいない
もちろんそれ以外のケースは参照カウンタも使わずに解放される
そのためGC言語は原理的にどうやってもCやC++やRustに勝つことはできない

**デフォルトの名無しさん** · 2021/11/13(土) 20:16:30.44

特殊な界隈でそういう習慣があるのか知らんが
参照カウンタは普通にGCの実装方式の一つと
言われてるだろ

**デフォルトの名無しさん** · 2021/11/13(土) 20:50:12.12

末尾再帰ができないのをループで書いても
スタックがあふれるけど

**デフォルトの名無しさん** · 2021/11/13(土) 20:53:18.97

例えば、ベンチマーク時間が30秒だとして、どれだけ回数を多く実行できるかがスループットであり
gcのあると言われる言語の中でgcの時間/頻度を調整できるものは30秒gcをしなければ、余計な処理が
走らないために数値が当然高くなる。もちろん処理中に使用メモリが常に増大して終了時のみに解放を
するため整合性のある説得力のあるベンチマークとは言いませんが、特定の処理に限ってメモリーが
溢れないのであれば、十分に取りうる選択肢です。

そして1msが致命的となるような処理では重要ですが特定桁までPIを求めたりフィボナッチ数列の処理
時間を計測したり、あんまり意味がないですね
多くは最適化がどこまでなされているか、配列などの範囲チェックなどのランタイムチェックが足枷に
なっているか、などが違うだけで言語的な特性だとは言いません。

上のほうでshared_ptrなんて持ち出してバカ言ってる人がいるけど言語は適用範囲が違えば有利な分野が
違います。「勝つ」なんて、Cなんて基本は配列などの範囲チェックなんかはやってないわけで原理的な
説明に１つもなってません。CとRustを同列に並べることがどうかしてる、Rustは範囲チェックなどは
安全な言語として当然やってるわけでRustだってアロケーションは他のgcの言語と同じく従来はjemallocで
今は違いますが確保と解放がセットになっている事が、今は有利に働いているが、将来的にはそうだという
確信はありません。そうでなければgcの研究なんて見捨てられるでしょう

**デフォルトの名無しさん** · 2021/11/13(土) 21:00:37.35

またGCの定義をmalloc/freeとreference countとtracing GCの3つの間でお手玉して好き放題言う流れか

**デフォルトの名無しさん** · 2021/11/13(土) 21:05:09.14

更に言えば多くの独立したgcのある言語は、gcにおけるメモリー断片化を防ぐコンパクション処理を独自にやっている訳でOSに任せているRustが有利なのはその通りですが、だからと言ってその処理を行って無い事を不正という話には全くなりませんし、原理的にどうやっても等という結論出すことは全く意味がありませんね

**デフォルトの名無しさん** · 2021/11/13(土) 21:14:45.54

>>600
参照カウンタはオペレーティングシステム内でもファイルシステムでも用いられている普遍的なデータ管理方式
参照カウンタを用いていることをガベージコレクションだと主張する人はいない
C++もRustも所有者が複数とせざるを得ない特殊ケースにおいて最適最速な方式として参照カウンタを用いている

>>602
やはりCもC++使ってことがない初心者だったのか
shared_ptrはCではなくC++です
そしてC++のshared_ptrはRustのArcと同じもので参照カウンタを用いている
あなたの無茶苦茶な主張では「C++とRustはGC言語」となるが世間では当然そんな主張は存在しない
もう一つのあなたのデタラメな主張「GC言語は速い」というデータも世間には見当たらない

**デフォルトの名無しさん** · 2021/11/13(土) 21:24:08.80

ガベージコレクション
https://ja.wikipedia.org/wiki/ガベージコレクション
じゃあページの記述を削除して直して来いよ。顔真っ赤にしなくても良い話だぜ？書き間違いぐらい読もうよ？
「GC言語は速い」などという主張はしていないのも読めないから呆れるんだよ、妄信するあんたらを

**デフォルトの名無しさん** · 2021/11/13(土) 21:51:51.77

もっと詳しく書かれている英語版に明確に書かれていますね
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Many programming languages require garbage collection, ...
these are said to be garbage collected languages.
Other languages were designed for use with manual memory management,
but have garbage-collected implementations available (for example, C and C++).
「多くのプログラミング言語はGCを必要としていてそれらはGC言語と言われる」
「その他の言語は手動メモリ管理で設計されたがGC実装も利用可能(例としてCとC++)」
つまりCとC++および状況が全く同じRustはGC言語ではないです

**デフォルトの名無しさん** · 2021/11/13(土) 22:03:01.49

はあ。。馬鹿馬鹿しい

**デフォルトの名無しさん** · 2021/11/13(土) 22:10:48.49

お前らの判断が遅いのは「審判は第三者でなければならない」という習慣のせいかな
自分が審判になって自分で好き放題に判断すれば早いんだが

**デフォルトの名無しさん** · 2021/11/13(土) 22:13:59.53

tracing GC の方が有利なアプリケーションって具体的に何？

**デフォルトの名無しさん** · 2021/11/13(土) 22:29:17.51

いろいろなプロセスが動かないバッチ処理なんかは逐一確保と解放を繰り返さない分だけ、調整すれば早いでしょ

**デフォルトの名無しさん** · 2021/11/13(土) 23:05:29.89

>>611がここでプロセスとか言い出してるのを見てもわかるように
GC言語が有利というトンデモ主張している人は基本的な常識知識がないようだ

**デフォルトの名無しさん** · 2021/11/13(土) 23:09:26.37

自分の間違いを認める人が全くいなくてこのスレはわけわからん

**デフォルトの名無しさん** · 2021/11/13(土) 23:10:29.14

馬鹿はほっとけ

**デフォルトの名無しさん** · 2021/11/13(土) 23:31:48.59

前提の違う話が交錯してるだけｗ言いたいやつに言わせとけばいいｗ

**デフォルトの名無しさん** · 2021/11/13(土) 23:42:47.00

>>611さんの解読
(1)バッチ処理だといろいろなプロセスが動かなくて
(2)つまりバッチ処理でなければいろいろなプロセスが動いて
(3)そしてバッチ処理でいろんなプロセスが動かなければ逐一確保と解放を繰り返さなくて
(4)逐一確保と解放を繰り返さない分だけ調整すれば早い
とおっしゃってるようだけど

(1)バッチ処理でもよくあるパイプライン式ならいろんなプロセスは動くし
(2)バッチ処理でなくてリアルタイムにストリーム処理でもプロセス一つだけもあってそもそもバッチ処理とプロセス数は関係ないし
(3)プロセス数が増えてメモリを使うことで起きうる確保と解放ならばOSによるメモリ管理とスワップの話になるし
(4)OSによるスワッピングが起きなければ起きた時より確かに実行速いのはその通りだけど
プログラミング言語によるメモリ管理やGCの話とは関係ないですね

**デフォルトの名無しさん** · 2021/11/13(土) 23:55:33.15

言いたいことを自由に言うのは良いことだよ
ただ、言われたことを全部聞く義務があると思うのは悪い

**デフォルトの名無しさん** · 2021/11/14(日) 00:37:07.99

GCの方式の一つとして参照カウント方式があるが増減のオーバヘッドや不完全性からGCとしては少数派で主流はトレーシング方式
一方でC++/shared_ptrやRust/Rcは参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな
そのためC/C++/RustはGCのない言語と一般的に言われている
このあたりは共通認識でよいのではなかろうか

**デフォルトの名無しさん** · 2021/11/14(日) 00:48:00.30

書き込みが多すぎてなんの前提で話をしてるのかよくわからんが、通常のGCじゃないならなんなんだ。PerlはGCじゃないのか

**デフォルトの名無しさん** · 2021/11/14(日) 00:54:15.03

>>619
そこは日本語をちゃんと読んで欲しかった

＞参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな

**デフォルトの名無しさん** · 2021/11/14(日) 00:55:47.54

ごめん。それでもわからんけど、Perlは参照カウント方式を使ってるんだけど、通常のGC言語ではない、ってこと？