次世代言語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/04(木) 18:01:05.24

>>427
ブロックも式になって最後の値を返すとか
ブロックで変数スコープがあらたにつくられるとか
Rustなどと一緒だね

あとはRustみたいに変数スコープブロックを抜けると(または変数のライフタイムが尽きると)
ファイルオープン変数だった場合に自動クローズとかもあるのかな？
具体的には、Pythonだとwith、C#だとusing、Goだとdefer、などそれそれ必要なところ
Rustはそういう特殊構文なくて
変数が解放されると自動closeされる

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

>>431
defer文でcloseできます。
nim-lang.org/docs/manual.html#exception-handling-defer-statement

コードを書けばデストラクタからcloseできるようになるけどNimにデストラクタができたのが最近なんで
標準ライブラリのFileはdefer文使うか自分でcloseを呼ぶ必要があります。

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

Rustはファイルディスクリプタ類を関数を超えて持ち回ったり複雑化しても使い終わると即座に確実にクローズが自動的にされるのが凄いよね

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

それは標準ライブラリがDropトレイとで成り立ってるだけの話で、openとcloseが完全対になるような
リソースならそれで良いがBufWriterの場合とかflushしなければならないし、何回もopen呼んでも良い
ようなリソース管理は、結局は自分で実装しないとならない

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

>>433
即座に着実安全にメモリ解放が自動でなされるRustにとって
その程度はオマケのついでの楽勝なだけにすぎない

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

その分とっつきにくいけどな

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

>>436
え？他の言語よりはわかりやすくてとっつきやすい

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

「rust 難しい」とかで検索すれば出てくるけど、残念ながら世の人々はそうは思わんのだよ
比較的進歩的な人でもそういう意見をよく聞くし、所有権は理解しないわけにいかない基礎だから端折れない

逆にgoではほとんどそういうことがない

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

Goはガベージコレクション言語だから比較の土俵が違うような
さらにGoはプログラミング言語として様々な機能を失いすぎてプログラミングしにくいのが辛いですね

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

比較的守備範囲の近い、とっつきやすい言語の例ｗ

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

失い過ぎたｗ
意図して実装してないだけだがｗ

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

>>440
Goは守備範囲が狭すぎて違う
Rustの元々の守備範囲はC/C++が使われている領域
その領域に加えてGC無くメモリ安全性の保証によりJavaなどの置き換えにも使われつつある
さらに加えてイテレータ等の現代的なプログラミングスタイルがメインとなってコーディングしやすいためスクリプト言語を含めた幅広い方面からの移行/兼用が起きている
いずれもGoは満たせない要件

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

だからこれからのコーディングの奴隷はRustで決まりってことなんだろ

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

goとrustならrustの方が守備範囲狭いよｗ
ひとえに難しいからｗ

OS周りならC/C++でいいし
現状ではweb周りのごくごく一部の超高速領域を除きrustには置き換わっていない
javaからの置き換えならgoでいい

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

>>442
その3種類ともGoは対象外なことに驚きました
実はGoとRustは領域あまり被っていなくて競合していないのかもしれませんね

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

他rust向きの領域だとdatabaseかなぁ・・・
ただ既存のDBを置き換えるのはなかなか厳しそうｗ
何かに特化したやつならいいかもねｗ

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

RustがJavaの代わりってマジか
Scalaみたいな負債の再来か

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

>>447
Meta (旧Facebook)が基幹システムをJavaからRustへ移行した
IT業界ではそういう流れ

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

ビルドシステムなｗ
https://www.itmedia.co.jp/news/articles/2107/28/news152.html

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

ビルドシステムでGCの動きを気にすることってほぼないけどな。
なんかやばい方向いってるね。

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

rustのスポンサー企業一覧
https://foundation.rust-lang.org/members/
プラチナメンバが錚々たる顔ぶれｗリンゴおらんｗ

nimのスポンサー企業一覧
https://nim-lang.org/sponsors.html

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

まあrustは天才向け言語と思うので、コアなところがrust縛りになってくれると安心なところはあるね。goとかnimとかはちょろい分野で頑張れば良い

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

て、天才ww

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

nimも良い言語だと思うけど、GAFAMみたいなとこがバックアップしてるわけじゃないし、仕事では使う気せえへんなあ。もったいない。
趣味ユーザが使いまくってエコシステムが充実するまで待つしかないな。

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

>>451
リンゴにはswiftがあるからなあ

**デフォルトの名無しさん** · 2021/11/05(金) 02:15:48.45

python嫌いだからnimも嫌いなんだわ

**デフォルトの名無しさん** · 2021/11/05(金) 05:25:56.07

嫌いっていうより、ウチの爺らはPythonすら出来なそうだけどね

**デフォルトの名無しさん** · 2021/11/05(金) 06:52:06.45

>>451
Rustのスポンサー企業一覧にTOYOTAがあるね
さすが日本のトップ企業

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

しょーもない見栄張ってるだけだな

**デフォルトの名無しさん** · 2021/11/05(金) 09:40:04.97

サーバーサイドに企業のバックアップなどいらぬ
趣味で弄れない仕様になってる車の内部やスマホのアプリを企業がしっかり作れよ

**デフォルトの名無しさん** · 2021/11/05(金) 10:28:44.23

Node.jsの話？

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

>>458
自動車ってガソリン車の時点でもう低レベルファームウェアの塊だもんな
これからEVとなるとなおさら…

**デフォルトの名無しさん** · 2021/11/05(金) 12:57:06.14

死ぬほど恥ずかしい知ったかだなこれ

**デフォルトの名無しさん** · 2021/11/05(金) 12:58:33.47

新手の自己紹介か？

**デフォルトの名無しさん** · 2021/11/05(金) 20:37:57.51

>>458
国外も国内も大手有名どころはRust採用で大勢が決した感じね

**デフォルトの名無しさん** · 2021/11/05(金) 21:28:24.58

国外も国内も全然違うｗ

**デフォルトの名無しさん** · 2021/11/06(土) 00:50:02.35

rustもアピールすごいな、内容の無いrust押しもどんどんrustから離れて行きたくなるけど

**デフォルトの名無しさん** · 2021/11/06(土) 01:56:27.18

YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
キャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir などは、普及のキャズムを越えなかったので、やる必要なし。
なのに、Rustが再評価され始めたのか

**デフォルトの名無しさん** · 2021/11/06(土) 02:00:59.99

C++でいろんな新規開発する組織ではRustが好評価されてるでしょ
それ以外の現場ではめったに見向きされない

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

転職サイトとかフリーランスのサイトでRustで検索したら1桁か2桁ぐらいしか求人が出てこないけど国外国内で覇権を握る言語らしい

**デフォルトの名無しさん** · 2021/11/06(土) 07:32:09.49

Rustでもユーチューバーでも国会議員でもそうなるわな

**デフォルトの名無しさん** · 2021/11/06(土) 12:03:26.15

rustが評価されてるのは高速・安全の2点
これらが難しさを無視できるほど重要になる領域では唯一の選択肢になる
世界規模のサービスでは特にクリティカルな問題になるのでこの分野の発展を望む巨人共が投資してる

**デフォルトの名無しさん** · 2021/11/06(土) 12:24:00.21

>>469
転職サイトw

**デフォルトの名無しさん** · 2021/11/06(土) 20:58:43.30

>>468
Goは言語仕様の欠陥により全くオススメ出来ない
Goでは例えばうっかりローカル変数の参照(ポインタ)をそのスコープ外へ持ち出しても
言語仕様としてコンパイラにもチェックされずそして禁止もされず
そのまま通ってしまうため実運用で致命的なバグを引き起こしてしまい
実際に以下のような大事件まで引き起こしている

Go言語で書かれたLet's encryptが300万以上の証明書の失効を迫られた致命的バグはRustで実装していたら防げたの？→Yes
https://qiita.com/komasayuki/items/02785730d486ec4b397f

**デフォルトの名無しさん** · 2021/11/06(土) 21:25:57.27

そういう問題じゃねーわ。
そこでポインタを外に出すようなバカはどんな言語使っても同じようにカスなことやってるよ。。

**デフォルトの名無しさん** · 2021/11/06(土) 21:32:11.29

>>475
人間必ずミスをする
そしてこれは言語の仕様としてそのようなことが起きないように禁止すれば済む話
Rustならコンパイラがその禁止事項でエラーとなるから人間が万が一のミスをしても大丈夫

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

じゃあunsafeも禁止にしないと

**デフォルトの名無しさん** · 2021/11/06(土) 21:45:46.17

>>475
だから、よりチェックが厳密な(100%とは言わない)rustが良いのでは。

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

rustにしたら防げたのかもしれないが、だからってrustにした方が良いとは思わんｗ

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

少なくともその分野のプログラミングならばRustを用いるのがベスト
他に解がない

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

静的解析さん……

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

Last

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

Rustは天才向け言語だからそんな凡ミスするやつが使うべきじゃない
はい終わり

**デフォルトの名無しさん** · 2021/11/06(土) 23:12:13.85

rustにしたらメンテナンスできる人や便利にしてくれる人が減ってしまう
明確に別の問題があるんだよ
本当にそれしか解がないのなら問題が起きる前に誰かがすでに書き換えている

**デフォルトの名無しさん** · 2021/11/06(土) 23:18:58.54

全人類Rustを極めてたらいいのに

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

それな

**デフォルトの名無しさん** · 2021/11/06(土) 23:32:27.72

>>484
Rustにしたらメンテナンスもしやすくなったよ
例えば機能追加で今回の件のようなバグが紛れ込むことも無くなった
もしその種のミスをしているとコンパイルが通らないから安心してメンテナンスできる

**デフォルトの名無しさん** · 2021/11/06(土) 23:35:57.66

天才が使う言語なんだからならそもそもメンテナンスなんてしなくていいだろ
はい終わり

**デフォルトの名無しさん** · 2021/11/06(土) 23:36:45.09

メンテナンスできる人の数の話をしてるのに、そもそもメンテナンスできる人がメンテナンスしやすくなったからって関係ないよね

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

アスペ＝天才

**デフォルトの名無しさん** · 2021/11/07(日) 13:38:59.39

たまに紙一重のやつがいるのは認めるが
イコールではないな
アスペ⊆天才でもないし
アスペ⊇天才でもない

**デフォルトの名無しさん** · 2021/11/07(日) 13:50:16.34

サヴァンみたいな一点豪華な才能は気苦労も伴うからな

**デフォルトの名無しさん** · 2021/11/07(日) 14:10:35.95

他のスレで暴れてるMbってやつは天才？

**デフォルトの名無しさん** · 2021/11/07(日) 14:21:05.01

召喚すんな

**デフォルトの名無しさん** · 2021/11/07(日) 15:13:11.87

天才でも凡人でも地方でも
最低限のマナーすら守れない香具師は何やっても成功しない

**デフォルトの名無しさん** · 2021/11/07(日) 15:30:00.12

マナーなんて無くても天才と馬鹿は行動力があれば成功するだろ
マナーが一番必要なのは凡人だけ

**デフォルトの名無しさん** · 2021/11/07(日) 16:47:03.65

488の煽りごときから天才の話を続けようとすんな

**デフォルトの名無しさん** · 2021/11/07(日) 22:52:33.86

>>489
PHPでも使ったら？一番人集まりやすいんでないか？

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

メンテナンスなんて少しも考えてないバカがrustすげーって騒いでるだけだろ。
どうせGAFAも認める言語使ってる俺すげーしてクソコード残して立ち去るような仕事のやり方ばっかしてんだろうね。

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

メンテナンスならばRustがもっともしやすいだろう
コンパイルが通ればメモリ安全性が保証される点で他の言語より抜きん出る
これは大きな利点である

**デフォルトの名無しさん** · 2021/11/08(月) 00:38:47.53

それでメモリ安全性の定義ってなんだっけ
意味論を定義したうえで形式的に証明されてるんだっけ

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

GoとRustってCのアドレス演算的なことはできるのですか？

int arr[] = {1, 2, 3};
int *p = arr;
p += 1; // ←これです
printf("%d\n", *p); // 2

**デフォルトの名無しさん** · 2021/11/08(月) 02:24:21.55

>>502
C/C++のようなポインタ演算は安全性のためにできないようにしてるが
Goならunsafe.Add、Rustならpointer::offsetやpointer::wrapping_offsetで同じようなことはできる

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

マンドクセ

**デフォルトの名無しさん** · 2021/11/08(月) 02:59:59.38

>>501
Rustは多くの論文が出ている
https://rustc-dev-guide.rust-lang.org/appendix/bibliography.html#papers-about-rust

>>502
生ポインタと呼ばれていて通常のプログラミングでは使わないが実行可能
Rustコンパイラによるメモリ安全性の保証外などとなることを宣言するunsafe{ ... }の中で使える

以下はRustのコードでコメント部分(＝各行の//以降)に対応するCコード
let a = &[1, 10, 100]; // int a[] = {1, 10, 100};
let mut ptr = &a[0] as *const i32; // int *ptr = a;
println!("{:p}: {}", ptr, unsafe{*ptr}); // printf("%lx: %d\n", ptr, *ptr);
　→ 0x5645a1293000: 1
ptr = unsafe{ptr.offset(1)}; // ptr += 1;
println!("{:p}: {}", ptr, unsafe{*ptr}); // printf("%lx: %d\n", ptr, *ptr);
　→ 0x5645a1293004: 10

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

>>501
絶対的メモリ安全性の定義が難しいなら
javascriptとtypescriptのような相対的な優位性を証明すればいい

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

>>503
なるほど
ありがとう

**デフォルトの名無しさん** · 2021/11/08(月) 14:46:35.97

>>420
(if true:
　echo "You can do this if you want"
　(block:
　echo "but everyone will hate you" # None indentation is OK
　)
　(for n in 0..5:
　echo n # None indentation is OK
　)
)
#for n in 6..10:
#echo n　# <-- Error: invalid indentation
https://play.nim-lang.org/#ix=3EmH

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

nimでスレが止まってるとイラっとするまでになってしまったｗ
前まで比較的好きだったのに・・・

**デフォルトの名無しさん** · 2021/11/08(月) 16:03:45.86

全員目をつむりなさい、この中に前から嫌いなのにA子さんの縦笛を盗んだ人がいます！
正直に手を挙げなさい！先生は怒りませんよ！

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

先生（クソッ、なんでバレたんだ…なんとか誤魔化さないと…）

**デフォルトの名無しさん** · 2021/11/08(月) 17:47:01.28

>>500
いまどきメモリー安全じゃない言語なんてC/C++/Delphiぐらいなもんだろw、Java/KotlinもC#もNimも、D言語も
Swiftもunsafe的なコードじゃなきゃメモリー安全。Microsoftも採用基準はメモリー安全以外だと言っているよ

**デフォルトの名無しさん** · 2021/11/08(月) 18:45:37.45

>>512
GC言語でもメモリ安全じゃないケースはある
例えばGo言語は>>474の実例のようにメモリ安全ではないことが示された
そしてGCなしネイティブコンパイル言語となるとメモリ安全な言語はレア

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

言葉の定義でしかないなｗメモリ安全なんて言葉は使わない方がいいｗ

**デフォルトの名無しさん** · 2021/11/08(月) 19:47:27.37

>>514
例えば>>474の現実例のようにメモリに関するバグをコンパイラが見逃して通してしまうプログラミング言語はメモリ安全性が保証されていない

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

ほんとアホは相手しちゃだめだな。長さ不定のリスト構造に要素の追加を値渡しではなく参照にしてしまうのは
メモリー安全性なんて一切関係ないｗ、型チェックの厳密性（緩さ）の違いだけGoは確かに緩いけど、Rustが
強い型付けをしているから。更に極端な例を言うなら秘密情報を一文字違う宛先に送った明らかなプログラミング
ミスと何ら変わりない。代わりにRustはキャストが大変になってる

GCなしなんてSwiftでもNimでも実質Rustと同じ参照カウントだし、S.T.Wで停止をしなければ高負荷な環境の
分野以外で問題になることはない。CrystalなんかでもARCの（まだ無いが）実装が検討されている。
この強烈な匂い立つような他の言語を貶める人たちへ、距離を置きたくなる。
言語のせいじゃないから困るわ・・・もっとアピールすべき点は他にあるでしょ

**デフォルトの名無しさん** · 2021/11/08(月) 19:58:54.68

>>516
そこは型チェックの厳密さは関係ない
ライフタイムの問題である
利用先よりも寿命が早くやってくる物の参照を渡したから問題なだけである
つまり型チェックの厳密さは関係ない

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

>>517
違います。利用先へ渡された参照渡しされたデータは寿命はやってきません。値渡しもしくは値コピーであれば
コピー元のデータは普通に寿命を迎えます。そんな事も分かってないのに強烈な初心者のような言い訳は意味が
ありません。他にも参照渡しされたデータたちの構造がリング状になることを循環参照と言いますが、（この
ような欠陥を作るのは大変ですが）Rustはこれを参照カウントで回収しません、これはARCだけを採用している
他の言語でも同じです。

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

>>518
基本的なことを理解していないようなので補足説明しますよ

まず関数内のローカル変数をスタック上に置く言語と全てヒープ上に置く言語の2種類に分かれます
このうち必ずヒープ上に置く言語でガベージコレクションを行なう言語は今回の問題が起きないので
ここでの説明では関数内のローカル変数をスタック上に置く言語を対象とします

スタック上に置かれたローカル変数の参照(ポインタ)を用いて関数内で様々な処理をしてももちろん大丈夫です
さらに別の関数を呼び出して先ほどのローカル変数の参照(ポインタ)を渡して別の関数で処理するのも問題ありませんし孫関数でも曾孫でも大丈夫です
そしてそれらの関数引き渡しの時に他の構造体変数に格納されて引き渡されることもあるでしようがそれでも大丈夫です
つまり他の複合的なデータ(配列や構造体など)に参照(ポインタ)が組み込まれて受け渡されることもありますが子孫の呼び出し関数にいるときは大丈夫です

問題が発生するのはその関数内ローカル変数を含む関数を終えたときです
ローカル変数の参照(ポインタ)が単体もしくは他の複合的なデータに格納されたまま呼び出し上位の関数に戻ってしまった時に問題が発生します
もちろん御存知のようにスタック上にローカル変数を確保した言語の話ですから関数を終えたときにスタックは開放されて参照(ポインタ)は無効となっています

この問題はCGの有無とは関係なくスタック上にも変数を確保する言語の場合は生じ得ます
さらにヒープ上に確保した場合でも非CG言語では生じ得ます
そして強力な型チェックを行なっていてもそれだけでは回避できない点にこの問題の難しさがあります
唯一の解決方法は言語が各変数(領域)のライフタイムを管理して更にその参照が渡って行く先々のライフタイムがそれより短いことを言語が保証することによります

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

RAIIですべて解決。
そもそも循環参照とか考えなければならなくなったら、自分の頭が狂っていないか病院で検査したほうが良い。
必要になってる時点で何かがおかしい。

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

クソみたいな長文書く前に
https://github.com/golang/go/wiki/CommonMistakes#using-reference-to-loop-iterator-variable
をちゃんと読んでこいよ
これをメモリ安全の問題だと思うのはアホだけだろ

**デフォルトの名無しさん** · 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を指していますよね？