次世代言語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/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を指していますよね？

**デフォルトの名無しさん** · 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が最強ってことだろ？