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

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/02/28(月) 23:29:23.70

>>392
それはRustが最高速を出すために
ジェネリクスを具体的な型に対してコンパイル時に静的にモノモーフィングするからであって利点の一つ
もちろん稀なケースでは動的にディスパッチしたほうが有利なこともあるのでRustは静的と動的のどちらも選べる

**デフォルトの名無しさん** · 2022/02/28(月) 23:58:18.16

>>396
うちではRoRは使っていません
その階層での汎用的なフレームワーク全体を作るのは大変でしょうが
必要な機能のみを必要な用途に特化して用いていますのでそのようなものを必要としていません

**デフォルトの名無しさん** · 2022/03/01(火) 00:00:29.40

>>399
はい、嘘乙ｗ

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

>>397
エコシステム完成を宣言！？なんでもござれ？？？？
なわけないだろｗ嘘乙ｗ

**デフォルトの名無しさん** · 2022/03/01(火) 00:35:18.37

>>398
その利点は理解してるよ
ポインタをつなぎかえるようなプログラム以外ではそこまで面倒だとは思わないし
ほとんどのプログラムは静的に決まるように書けるしね

**デフォルトの名無しさん** · 2022/03/01(火) 06:36:40.86

ポインタ繋ぎ変えるのはRustでは面倒です←まあわかる

ポインタ繋ぎ変えるのはバッドプラクティスなのでアリーナ使って富豪みたいなメモリの使い方しましょう← ？？？？？w？？！？？？？？？？？？？？？？？？？？？？w

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

>>403
いや何でもかんでもArena使えってことではないよ
Arenaは処理の間、メモリの解放が起こらずに解放する時はまとめて解放するようなデータ構造で使うものだよ
rustのソース読んでたらAST作る部分で使ってた
ASTはまさにそのような部品
rustのソースは学びが多すぎる

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

arenaって富豪的なの？
最近のmalloc実装はarena使ってるからそれも富豪的ってこと？

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

>>405
arenaは解放処理が行われるときは必ず全てのオブジェクトが解放される
mallocはslab allocatorが上手いことやらないと解放されない

**デフォルトの名無しさん** · 2022/03/01(火) 19:11:45.23

>>406
なんでslab allocatorが関係してるの？

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

>>404
ASTみたいな構造+途中で解放する必要があるって時の解がRustにないので、オレオレ実装をプロジェクトごとに入れるか、アリーナを何度も作っては捨ててを繰り返しながら世代型GCもどきを作るかするしかなくない？
これは事実上なんでもアリーナでやるってことになると思うけど

**デフォルトの名無しさん** · 2022/03/01(火) 20:13:49.20

強力な静的型付けと言うのは普通のプログラム言語は当たり前でスクリプト崩れがそうでないだけだと思うけどなあ…

**デフォルトの名無しさん** · 2022/03/01(火) 20:26:25.79

>>408
そういうのはまさにRefCellを使うしかない
arenaはあくまで処理の間は絶対に解放されないデータ構造をまとめて確保するために使う
例えばASTだったりネットワークグラフだったりね
こういうメモリの使い方のセンスってGC言語が当たり前になったせいで完全に失われた技術って感じがする

**デフォルトの名無しさん** · 2022/03/01(火) 20:34:17.98

>>409
静的型付き言語の中でも代数的データ型や型制約のような型の表現力の違いというのはあると思うよ

**デフォルトの名無しさん** · 2022/03/01(火) 20:36:04.73

>>408
ちなみにarenaみたいな仕組みを実はV8は実装している
HandleScopeという仕組み
これはHandleScopeが生きている間はメモリが解放されないが
HandleScopeが死ぬタイミングで全てのローカル変数のメモリが解放される

**デフォルトの名無しさん** · 2022/03/01(火) 20:42:46.97

>>409
CやGoはどこに分類されるの？
スクリプト崩れ？

**デフォルトの名無しさん** · 2022/03/01(火) 20:53:08.57

ObjCのautoreleaseみたいなのが最初からあると楽でたすかる

**デフォルトの名無しさん** · 2022/03/01(火) 22:06:55.93

>>410
なるほど……

**デフォルトの名無しさん** · 2022/03/01(火) 22:31:05.05

いやRefCellはしんどいって
やっぱgcpointer復活して欲しい

**デフォルトの名無しさん** · 2022/03/01(火) 23:43:07.40

RefCellなんてたまにしか使わないものだし使うときも困るようなものじゃないぜ
おそらくRustのアンチが不利っぽく見えるところを取り上げようとしてるんだろうけとさ

**デフォルトの名無しさん** · 2022/03/01(火) 23:52:21.58

そりゃテキトーなスクリプトで済むようなコードばっかなら使わんだろうね

**デフォルトの名無しさん** · 2022/03/01(火) 23:55:04.65

分野にも依るんだろうけどWeb関係やってるとRefCellの出現は超レア
ライブラリの方のソースも全て見たけど
RustのHTTPデファクトスタンダードのhyperで1ヶ所だけ出現
その上のレイヤーのライブラリ群ではゼロ、HTTPS扱うhyper-tlsでもゼロ

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

Webだとメモリ上に状態を永続的に保つ必要はないからrust向きだよね
所有権を渡していくことで自然と安全なプログラムが書ける
永続情報はデータベースかmemcacheみたいなkvstoreに入れるし

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

>>416
gcpointerって@のこと？
あれはgcと言いつつただのRcだしinternal mutabilityとは関係ないよ

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

>>420
ほとんどの動的アロケーションはリクエストスコープだからという理屈？
だったら所有権というより自動変数で十分でしょ

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

循環参照が必要な時にやれることが「プログラマが注意して管理しましょう」しかないのキツくない？

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

>>423
現実に色んな分野でプログラミングするとわかるが循環参照なんてほとんどの分野で出てこないか回避できる
なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである
だから非現実的な机上の空論で悩む必要はない

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

グラフとか木構造になるの？

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

世界が狭い人に非現実って言われちゃった

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

> なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである

これが真ならベルマンフォードとか使うケースはどうなるんだ
まあ無理筋に頑張って木と同一視するのかもしらんが

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

>>425 >>426
抽象的な話しか出来ないなら相手にしないが
具体的に木構造の視点を持たないグラフを扱うシステムやアプリがあるなら挙げてごらん
そしてそのデータをどのように永続化しているのかも語って欲しい
あったとしても非常に特殊なレアケースだろう

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

>>427
ベルマンフォード法で扱うデータをポインタ(参照)で指し合うなんて非効率なことはしないので不成立
普通に配列に格納する

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

よくわかっていないけど
鉄道の路線図とか簡単にループするけど
どうするの?

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

>>428
質問してるのはこっちなんだがｗｗｗｗ

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

>>430
プログラミングでそういうのを扱うときに
駅の個数だけ駅ノードオブジェクトをメモリ確保して路線毎に隣接駅をポインタ(参照)で指し合う、なんてことはしない
それだと何かするたびにポインタを何度も辿りまくって遅いし
そのポインタで指し合う構造をデータベースに格納するのも大変

現実にはどう扱われているかというと
データの配列として持ってそのインデックス等で他を指す
つまりポインタ(参照)は出てこない
配列とインデックスの方が扱いやすいし、メモリアクセスも速いし、ファイルやデータベースに格納するのも容易

>>431
現実に必要となることが無いか、代替手段があるか、となり、
残る超レアケースがあるなら出してごらん

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

>>432
お前が>>424で
> なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっている
と宣うから、俺が
> グラフとか木構造になるの？
って聞いてるんだがｗｗｗｗ

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

>>433
現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造ならば
何らかの視点で見ると木構造になっている
もちろんその一番簡素なパターンである配列構造を含めてね
今のところ誰も反例を出せていない
もしあるとしても超レアケースなのだろう

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

>>434
グラフとか木構造になるの？

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

>>435
現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造の何のグラフですか？
ベルマンフォード法ならば>>429に書いたように配列で扱われます
鉄道の路線図についても>>432に書いたように配列で扱われます

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

>>436
> グラフとか木構造になるの？
こう聞かれて特定のグラフだと思う方がおかしくね？
答えられないなら何レスも使わずに分からないと言って欲しい

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

>>437
そこまでキチガイならば相手をしない
こちらは最初から一貫してこの話しかしていない

>>424　引用
|　現実に色んな分野でプログラミングするとわかるが循環参照なんてほとんどの分野で出てこないか回避できる
|　なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである
|　だから非現実的な机上の空論で悩む必要はない

そしてそちらが挙げた具体例に対して
それらは現実に配列として扱われていることも述べた

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

>>438
>>437

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

言ってることは分かるよ
俺はrust書き始めてポインタを使わないプログラミングをするようになった
C/C++に毒れてたことに気がついた
例えば木構造も配列とインデックスで同じことをやるように書き直した
昔のAhoやUllmanのアルゴリズムの本はポインタを前提にしてないから
配列とインデックスを使ってアルゴリズムを書いてる
その本を引っ張り出してきて読み直したりした
まさか現代において70年代に書かれた本を参考にするとは思わなかった

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

>>438は「分からない」ようだから話を進めると、グラフ構造は木構造にはならない
なぜなら、木構造はグラフ構造の一種だからｗ

グラフ構造を単純に実装すると、親ノードが子ノードを参照する形になり、簡単に循環参照を発生する
そういうこともあり、古来通常の実装はノードから直接参照するのではなく、エッジというものを用意し
各コンテナに保存した上で参照先をコンテナのキーにすることで表現する

つまり循環参照は簡単に発生し、それを回避する努力を惜しまない必要がある
>>423の言う通り、まさに
> 循環参照が必要な時にやれることが「プログラマが注意して管理しましょう」
であることが明確に分かる

これをろくに議論もできない頭で否定するものではないｗ

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

配列とインデックスを使うとして、ある要素のインデックスを取った後にその要素が削除されるとそのインデックスが想定していない要素を指すことになるじゃん。そういうのはみんなどうやって防いでいるの?

あと、双方向リンクドリストって普通に実装すると循環参照になるけどこれも配列とインデックスでやるの?

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

原理的には整合が取れない状態にならないように操作がatomicになるように実装する
もちろん実装方法なので、構造を変えたり、方法は具体的にはいろいろあるよ

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

>>441
そこまでアホとは思わなかったw
一般的なグラフが木構造にならないのは当たり前だろ
まさかそんなことを言いたいがためにこちらの質問に回答できなかったのかw
呆れた

現実に色んな分野でプログラミングするとわかるが循環参照なんてほとんどの分野で出てこないか回避できて残りはレアケース
なぜなら現実の様々なシステムからアプリまで全てにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているからである
さらに既に例で示したようにベルマンフォード法などのグラフにおけるアルゴリズムを扱う場合も現実のプログラミングでは配列として扱われている
だからそんな非現実的な机上の空論で悩む必要はない

>>442
そういうレアケースのために
Rustでは双方向リンクドリストも含めて標準ライブラリに用意されている
その上で注意書きとしてほとんどのケースではリンクドリストを使うよりも配列やリングバッファ(RustではVecDeque)を使った方が有利と明記している
これは言語に関係なく成り立つ話

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

>>444
そんな単純なことが返事できなかったのはお前だろｗｗｗｗ
そんな頭で「非現実的な机上の空論」とか言ってる場合じゃない
循環参照問題はレアケースではなく明確で常に回避を必要とし、各分野で日々回避方法が研鑽されている
Rustも例外ではない

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

>>445
そんな当たり前のことをわざわざ尋ねてくるほど君が低レベルとはその時は想定していなかった
結局のところ君は具体的な反例を出せずに非現実的な机上の空論を続けるだけなのかね

現実の様々なシステムからアプリまで様々なものにおいて出てくるデータ構造は何らかの視点で見ると木構造になっているものがほとんどであり循環参照で悩む必要はない
一般的なグラフ上の各種アルゴリズムについても配列上のデータとして扱われるのが通常
ポインタで指し合うデータ構造をとってもポインタを何度もたどるのはメモリアクセスで不利でキャッシュ的にも不利であり、もちろん永続化として格納する時も同じく

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

俺が言ってるのは循環参照問題は重大な問題であるということｗ
反論出来てないのはお前ｗ
Rustの標準ライブラリはunsafeのオンパレードだなｗ

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

>>447
その最後の行「Rustの標準ライブラリはunsafeのオンパレードだなｗ」によって
あなたがプログラミングについて無知だと判明しました

言語関係なく一般的にその「unsafeな操作」無しではプログラミングは成立しません
そのため各プログラミング言語はその「unsafeな操作」を様々な方法で閉じ込めようとしたり
あるいはC/C++のように全開放して全てをプログラマーの自己責任としたりしています
いずれにしても各言語の内部では「unsafeな操作」が当然ながら頻出となります

一方でRustでは従来にない以下の方針を取ることにしました
・GCを言語としては採用しない
・それにも関わらずプログラム全体のメモリ安全性をコンパイラが保証できるようにする
・必ず残る必須な「unsafeな操作」は型やモジュールの外に影響が出ないよう内部に閉じ込める
・その型やモジュールが外に提供するインタフェースは(unsafe宣言されているものを除いて)安全に提供する
つまりプログラミングをする上で避けることができない「unsafeな操作」を
C/C++のように(結果的に)プログラム全体に散りばめてしまうのではなく
ライブラリなどの内部に完全に閉じ込めて外に影響が出ない安全なインタフェースのみ提供することにしたのです

Rustはこの方針によってプログラミングに不可欠な必須の「unsafeな操作」なだけでなく
実行効率の良さのための「unsafeな操作」も型やモジュールの内部に閉じこめることが可能となりました
そして安全なだけでなく速さも両立することに成功しました

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

いやいや、普通unsafeなコードというのは外部とのやり取りの薄皮一枚だけで収まるはずなんだがｗ
Rustだと都合により内側でも使います！
みたいな使い方で、標準ライブラリの中ではやりたい放題されてるように見えるってことｗ
ベアメタルとかになると標準ライブラリも使えないわけで、薄皮一枚だけunsafeにしても足りず泣く泣くunsafeを使う羽目になり、、、
安全とは一体・・・になりそうってことなんだわｗ

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

>>449
そんなに無知を曝け出さないほうがいいと思いますよ
「unsafeな操作」とは何か、そしてその避けられない操作に対してRustがどのように
並行並列環境に至るまでメモリ安全性の保証を実現させたのか勉強するのをお勧めします

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

所有権と速度の問題を回避するためにunsafeに走ってませんか？？？？ｗ

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

>>449
ベアメタルでliballocは使えるからデータ構造を再実装しないといけないケースはあまりないのでは？

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

>>440
温故知新ですな

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

>>449
unsafeは無くすことできないから閉じ込めるってことなんだが。
unsafeあったらダメ原理主義者ですか？

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

>>432
結局データの配列として持つことになるのはわかるけど、それって指す先が存在するか分からないから実質ポインタとやってること同じだし、途中で要素削除があるとインデックスの整合性保つのに一苦労するじゃん

まあ君にとっては「レアケース」であり「現実に必要となることが存在しない」のかもしれんが、実際に存在するとだけは言っておくわ

あと、配列とインデックスの方がメモリアクセスも速いってのはわからんかった。配列とインデックスの方がポインタより速いってなんでだろ

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

まあベルマンフォードする前に配列とインデックスの形式に変換するくらいのことは出来るけど、結局その前段階のミュータブルなグラフを配列とインデックスで管理するのはキツい
アリーナでオレオレ世代型GCモドキを作った方がまだマシ

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

あとは配列とインデックスの代わりにHashMapとkeyにするとかかな？

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

配列とインデックスってすげーunsafeなコードだよな
unsafeブロックの外側でunsafeな処理をしている分余計性質が悪い

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

>>455
配列indexでグラフ構造表現する場合、インデックスが変わるような方法で要素を削除することはしないのでは
要素ごとに削除フラグを立てるとか、free listで未使用要素のインデックスを管理するとかが普通だと思う

>>458
ここで言うunsafeってどういう意味のunsafeなの？
rustの定義のunsafeとは違うことを言っているようにみえる

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

>>456
＞その前段階のミュータブルなグラフを配列とインデックスで管理するのはキツい
＞アリーナでオレオレ世代型GCモドキを作った方がまだマシ

同意

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

グラフなどのノード構成において
他のノードを指す方法として「idを用いる」のと「ポインタを用いる」のは完全に同型
というのがプログラミングでの常識です
同型というのは通常の管理からダングリングの発生やその防止も含めて同型です

配列に格納してそのインデックス方式も「idを用いる」方式の一種ですから
これも当然「ポインタを用いる」のと完全に同型です
どちらか片方の管理方法がキツイと言ってる人は完全に間違っています

これはGCを考慮した場合についても完全に同型です
誰もそのポインタを指さなくなったことと誰もそのidを指さなくなったことが対応します
したがって配列とインデックスで管理することで管理がキツくなることはありません
そしてGCをする場合も全く同型なので同じ方式同じアルゴリズムで互いに行うことができます

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

常識かあ

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

>>452
標準のをそのまま使えと？
想定ケース次第だと思うけど、どういうのが多いんだろうね

>>454
主旨が伝わってない...
まあ標準ライブラリ以外でunsafeを使ったら、それをcrateごとに分かるように名前にunsafeを付けるなりはしてほしいね

>>461
循環参照の回避はできてんだろ何言ってんだ…

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

あと主旨は>>451だぞ

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

>>461
それは全て正しいが
現実にはそこに付け加えるべき重要な事項がある
GCのコードを書くとわかるが使われたidの一覧が必ず必要となる
ポインタ方式ならば使われたポインタの一覧が必ず必要となる
インデックス方式ならば使われたインデックスの一覧が必要となる

すると『使われたポインタの一覧を管理するコスト』よりも
『使われたインデックスの一覧を管理するコスト(＝最大インデックスまで)』がはるかにコストが低い
つまりGCをする場合でもインデックス方式が有利となる
もちろんそれ以外のアルゴリズムなどは同型なので同じという点には同意

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

循環参照がレアケースとかいう人はもう発言しないでいいと思う
数年間は黙ってみんなの意見を読んで勉強しましょうね

>>423
> 循環参照が必要な時にやれることが「プログラマが注意して管理しましょう」しかない

それがGCなし言語
それがRustの選んだ道
メモリ管理はプログラマが手動でなんとかするしかない

>>445
> 各分野で日々回避方法が研鑽されている

心静かに同意だわ

>>458
> unsafeブロックの外側でunsafeな処理をしている分余計性質が悪い

キミは賢いね

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

>>465
その点についてはおっしゃる通りです
ポインタ一覧を管理するコストとインデックス一覧を管理するコストは同型か否かの枠外です
ダングリング防止やGCアルゴリズムなどは同型となるでしょう

>>466
あなたはRustにおけるunsafeとは異なる意味でunsafeという単語を用いているようです
もちろんRustと無関係な場においてunsafeの意味を独自に用いるのはあなたの自由です
しかしあなたはRustという単語を出していますからRustにおけるunsafeの意味に従う必要があります
勉強して出直してくることをお勧めします

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

だんだん話がオレオレGCになってきたな
結局GCは必要なんだよ
必ずしも標準に入ってる必要はないが、優秀はGCライブラリが存在しないのはかなり痛い

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

>>468
いいえ、GCは必ずしも必要あるわけではありません
GCが必要になるのは少なくとも以下の2点を満たす必要があります
・継続して動作させる必要がある
・使われていないメモリが有意に存在している
例えばGC言語であっても前者の継続動作が必要なければGCさせないモードで動かすケースもあります
一方で後者はGC言語であれば常に使われていないメモリが溜まっていきます
しかし非GC言語ではたいていの場合はメモリ開放をすることができるためGCは不要です
どうしても循環強参照を起こしたいというかなり特殊な状況でなければGCが必要になることはないでしょう

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

あ、循環参照はかなり特殊な条件派のひとだったか
じゃあ話すことはないや

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

>>468
C++に謝れ

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

C++用のGCライブラリは実在してるだろ

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

>>470
循環強参照を起こしたいかなり特殊な状況であっても
プログラムを継続して動作させる必要がなければGCは不要です
これは広義にはプログラム自体は継続してもその構造が長期継続しなければ成り立ちます
例えばRustならばtyped_arenaなどを用いればその構造の利用を終える際に一気に全体を消去可能です
また別の視点からはデータが単調増加ならば不要部分が発生しないのでこれもGCは不要です
これら全ての条件を相反するような条件が全て揃った時のみGCが必要となるでしょう
もしそのような具体的なケースが頻繁に多数有るならば教えていただけると勉強になりますのでよろしくお願いします

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

なんで特殊な条件派を説得しにかからず初手会話放棄するかというと、仕事で使っていておいそれとネットに晒せないからですね
なので秘密を打ち明けなくても前提に同意してくれている人とのみ話す訳ですよ

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

>>474
一般的な用途ならば仕事に関係なくその一般的な用途だけ話せばよい
そうでないのならば
君も一般的な用途でGCが必要となる具体例は無い派ということになる

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

>>475
一般的な話をすると増えたり減ったりする双方向グラフを更新し続けて持ち続けるという要件になるな
それ以上の説明を求められると何に使うのかという話をすることになり、俺の仕事の説明をすることになる

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

「一般的な用途」というのがどういう定義なのかしらんが、「Rustで簡単に出来る範囲を一般的と呼ぶ」と恣意的に定義するのであれば俺もその派に入れてくれて良いよ

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

>>476
それならばその双方向グラフの安全な型を作るのがベストソリューションです
ちなみになぜそのような一般的なライブラリがないかというと各々で求められる条件が異なるからです
あなたの場合は求められる条件が確定しているのですからそれを満たす双方向グラフの安全な型を実装できます
例えばノードが削除される場合もその際の条件やその後の処理が独自に確定しているはずです
したがってそれを元に双方向グラフの安全な型を実装して安全なインタフェースのみ提供すればいいのです
そうすればRustのコンパイラに対してもプログラム全体が安全に通るでしょう
そして循環参照についてもその双方向グラフの安全な型が責任を持って取り扱えばよいのです
汎用的なGCは不要でその状況に特化したものを用意すればいいだけなので容易に実現できると思います

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

>>478
まあできるかどうかで言えば出来ますけどね。容易とは思わないけど。
結局>>423なんだよな。そもそも頑張って安全なインターフェースを提供するだけならCでもできるし（>>478には容易かも）

まあ汎用GCついてる言語ならこんな面倒なことしないでいいのでGC言語使おうってことだろうな

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

$ cat hoge.sh
cat >hoge.rs <<EOF
// unsafeって宣言に出てこないし安全に決まってるよ！
fn read_address_4byte(address: usize) -> i32 {
unsafe {
*(address as *const i32)
}
}
// 流石Rust安全だな！
fn main() {
read_address_4byte(0);
}
EOF
rustc hoge.rs && ./hoge
$ bash hoge.sh
hoge.sh: 13 行: 124161 Segmentation fault (コアダンプ) ./hoge
$

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

>>479
いいえ、C言語にはここでいう「安全な」の定義がないので無意味です
一方でRustでは「安全な」インターフェースを提供する型を作れば
それを用いてコンパイラによりプログラムの安全性を保証することが可能です

>>480
「unsafe」の勉強をして出直して来ることを勧めます
そのread_address_4byte関数は条件を満たせていないので
unsafe fn read_address_4byte(address: usize)と宣言しなければいけません

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

>>481
あー。まあそれはそうね外側でもunsafeなのは頂けないたしかに

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

あれぇ・・・コンパイル通ってないと実行できないんだけどなぁｗｗｗｗ
エラーも何も出てこないんだけどなぁｗｗｗｗ
安全とは？？？
Rustが安全！？
何をご冗談をｗ

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

教官「GC無しで手動メモリ管理してきた言語だ、面構えが違う」

C/C++/Rust「（ﾟωﾟ）」

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

おじさん来た？
スレの質が一気に下がるな

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

>>482
そう
外側ではunsafeを使わない
その上で今回のケースはその独自仕様の双方向グラフの「安全な」型を作れば、Rustではプログラム全体の安全性が保証されます
そして「安全な」型を作るには
・型が外へ提供する「安全な」インターフェイス群を用いる限り、それらをどのように用いても、型の内部に矛盾や危険な状態を生じさせないこと
・たとえ型の内部でunsafeな操作が存在していても、型の外へは影響せずに内部に封じ込められていること
このような形で新たな型を実装することで全体を安全に解決できるところが他の言語にはないRustの特徴でしょう

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

まあGCライブラリさえあれば双方向グラフも簡単に作れるんですけどね
Javaくらいの出来のGCライブラリがついたら最強

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

Rustには静的型付けがあるすげー　←　スクリプトから来た人
Rustは強力な型推論がある　←　スクリプトかC++から来た人

こういう主張をする人は世間知らず
つまり雑魚

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

関数型言語以外の型推論は大体が変数の型や戻り値型の推論で、HM型推論採用してる言語ってあまりない気がする
もしそうならば非関数型言語にしてはRustは型推論が強力と言っても良いのでは

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

お猿さんは『「安全な」型を作れば、Rustではプログラム全体の安全性が保証されます』などと宣っているが、それは言語で保証しているのではなく、プログラマが手で保証しているに過ぎないｗ
つまりunsafeなブロックを少しでも含むものはC/C++と変わらないわけで、それを使っている部分も、どこでどう使うものなのか分からない限りC/C++と変わらないということｗ
さらに悪質なのは、Rustの外のライブラリなどunsafeな何かを呼び出しているわけでもないのに、自前で破壊的なコードを内包できる仕組みｗ
こうなると、もう外面だけでは分からないわけで、Rustの安全神話は完全に崩壊するｗ

またこのような状況に拍車をかけているのが自前で破壊的なコードを内包する動機になりやすい所有権の概念ｗ
安全性の根幹をなす部分であるにも関わらず、双方向参照への例外なく簡単に適用可能な安全かつ高速な対応方法が存在していないｗ
これはプログラマに対してunsafeへの誘惑を助長する形で、逆に安全神話の崩壊を招いているｗ

まあRustは数ある実装言語の1つとして今後も使っていくとは思うけど、何でもRustに肩入れするお猿さんとはちゃんと線を引いていきたいｗ

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

https://www.thecodedmessage.com/posts/unsafe/
> “If you have to use unsafe to write good Rust, then Rust isn’t a safe language after all! It’s a cute effort, but it’s failing at its purpose! Might as well use C++ like a Real Programmer!”
このブログでstrawmanとして挙げられてる主張そのまんまじゃん
まずは議論のベースラインとしてこの記事読もうぜ

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

>>490
全然違いますよ
CやC++ではunsafeなコードがプログラム全体に散らばってしまうため複雑になればなるほど人間にはどうしようもなくなります
一方でRustではunsafeなコードを各ライブラリや各型の中に封じ込めて外へはその影響を及ぼさないことを保証するだけでいいのです
あとはプログラム全体がどんなに大きく複雑になろうともコンパイラが安全性を保証してくれます

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

Rustの推論はプログラム追記で破綻する
後方で馬鹿が型を間違えて追記した場合予想した結果と異なる結果になる
しかもエラーが出ない

仕様が悪い

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

>>493
Rustは孤児ルールがあるからそんなことは無理だぜ

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

>>492
それが実際に違ってなくて同じという主張だろｗ日本語読めないのかよｗ

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

会社でいたら距離置きたいな…

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

>>491
クソ長い英文読まされた上に被ってる部分が全くなかった悲しみ

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

>>487
javaの出来は良くないぞ
ヒープのサイズかなり引き上げないとすぐメモリ不足になります