Go language part 5

**デフォルトの名無しさん** · 2022/02/27(日) 07:43:20.04

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

※前スレ
Go language part 4
https://mevius.5ch.net/test/read.cgi/tech/1605467680/

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

Rustの標準ライブラリはunsafeのオンパレードだなｗ

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

誤爆

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

ライブラリもOS機能を使うならunsafeも致し方ないのではないだろうか、と誤爆にレス

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

興味があるならどこの誤爆かだけ書いておく
https://mevius.5ch.net/test/read.cgi/tech/1638086359/447

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

>>58
わざわざGoスレでくだ巻いてる方がやれよ。
できなけりゃGoを使うよ。

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

>>63
俺はGoのパフォーマンス測定をGoスレで尋ねてその後も調査してるだけだけ(すでに終了は宣言した)
ただまだ妥当性がどうのと言ってる人がいるから、とりあえず恐らく同じくデフォルトが通常2KなOSスレッドスタックを使ったRustとC++の結果を貼っただけ
結果は1:1でthreadが動いてるRust/C++の完敗だが、ロジック同程度で標準機能だけという条件なら仕方ないねって話をしただけだぞ
まだ文句があるなら自分でやれと言って何が悪い
お前がGoを使おうと何を使おうと俺はどうでもいい

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

>>64
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することは無意味
比較したいならばC++&Rust側でもm:nでやりなさい

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

>>64
勝ち負けを認めさせたいから言ったのでは無く、それ以上はRustスレでやれと言ってる。

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

>>66
俺に言うなよ
>>65に言え

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

C++スレでもRustスレでもここでも同じで無意味
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することはナンセンス

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

thread単品で制御できないgoじゃこういう計測ができないのも理解できないとは・・・
何しにgoスレに来てるのやら

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

C++とRustでもOSスレッドではなくm:nグリーンスレッドを使えばよいだけだろ

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

>>64
妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
君のデータは妥当だし正確だと思うよ。

>>54
> OSがそれなりにさばかないよ。
GOMAXPROCSがCore数と同じ事に拘ってるからだよ。だから完全な（＝高価な）スケジューリングが必要になる。
Core数よりも多いMにして、優先順位を低く設定しておけば、CPUが空いてればそのMで実行される。（これはOSがやってくれる）
これなら今のランタイムがやってるようなスケジューリング管理なんて丸々必要なくなる。
C#がこれで、空きCPUがあれば新規スレッドをプールに追加して、実行させるだけでしょ。
(ただしGoの場合は同期チャネルなので一々止まりまくり、この場合は確かにそのままOSに任せても駄目で、
Rustみたいに同期受信待ちをコルーチン化して送信時に受信側goroutineのコードを直接実行する実装の方が向いてるが、
《だからthreadなのにコルーチンと名付けたのか？》
ここら辺はジョブの重さと同期チャネル量の兼ね合いで、第一選択肢として力業（スケジューラ）で解決、という判断は妥当ではあるが)

> グリーンスレッドの価値を全否定だな。
「コンテキストスイッチのオーバーヘッドを減らす」Goより、
「コンテキストスイッチ自体を無くす」非同期の方が原理的に速い。
ただし非同期はソースがうざかったが、async文法でまあ何とかなった。
よって肯定する部分がない。当然他言語も全く追従しない。（今後出てくるかもだが）
逆に非同期はJS/C#/Rustと来てるだろ。良いと見られている証拠。

> V8もTurbofan+Ignitionに変わってすぐはソース読んでたぞ。
それは君が興味があるからだろ。
大半のJSerはC++は読めないし、読む気もない。ブラウザが速ければそれで良しだよ。

わざわざ自前でスレッド管理するのなら、OSと被ってないところをやらないと。
スケジューリングはOSがやってくれるのだから任せておけばいいし、自前でやっても余計に遅くなるだけ。
残ってるとすればスレッド間通信で、これは確かにOSのは遅い、というより動くようにしか出来てない。（そして非同期）
だからそこそこ速い同期チャネルが絶対不可欠なアプリがあれば、と思って考えてみたが、やっぱり俺は思いつかないね。

**デフォルトの名無しさん** · 2022/03/03(木) 00:21:30.68

やり方がわからんのだろ。

**デフォルトの名無しさん** · 2022/03/03(木) 00:23:05.45

チャンネルが同期なのはバッファが無いとき
お前は本当に人な話を聞かないし何も読まないな。

**デフォルトの名無しさん** · 2022/03/03(木) 00:56:08.72

>>71
> 妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
うん、それは分かってたんだけど、定量的なデータがないとその妥当性分からんでしょ
M:Nのgoroutineだからと言って調子に乗って1:1の10倍積むと、俺の環境だとrssは超えてしまうってことがデータから分かる
データは簡単に取れる状況だったから、取っただけ

**デフォルトの名無しさん** · 2022/03/03(木) 11:28:44.36

Windowsでアップデート後にVScodeでテストを走らせると1.14.13でコンパイルされてるためツールバージョン1.17.7とマッチしませんと言われる
setting.jsonでgo.gopathを環境変数のGOPATHに合わせてビルドしてもダメ
かといってアップデートされたディレクトリを指定してもダメ

環境変数のGOPATHのgo.exeがアップデートでは更新されていないためなのか
でもツール類はアップデートされてたりしてもう訳がわからない
どう処置したらいいの？

ちなみに、システム環境変数のPathには$GOPATH\binのパスが入れてある

**デフォルトの名無しさん** · 2022/03/03(木) 11:44:33.79

いや…落ち着いてエラーログを見たら、例えばruntime/internal/sysが、とか言ってる
参照モジュール？

で、go.sum を消して再ビルドしたけど同じ結果

**デフォルトの名無しさん** · 2022/03/03(木) 13:27:09.03

とりあえず全部をアップデート先に統合する方向で納めた
バージョン混在状態だとどうしたらベストなのだろう？
環境的には最新に統合してgo.modでのバージョン記述に頼ればいい？

**デフォルトの名無しさん** · 2022/03/03(木) 18:20:17.50

>>74
つまりリソース的にGoroutineはOSのスレッドの数倍しか立ち上げられないということ？

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

https://zenn.dev/mattn/articles/c453f42393778a
numpy より速い？Go の行列演算ライブラリ nune

やっぱＧＯは速いね

**デフォルトの名無しさん** · 2022/03/03(木) 20:31:53.54

>>74
それはご丁寧にどうも。ついでなら、
> C++は20を使えば標準機能だけで実装できるはず (>>58)
これについてもキーワードかURLだけでも教えてくれれば助かる。見に行く。
greenthreadが採用されたって事か？
(C++の場合は『全部入り』を目指してるからいつかは入るとは思うが）

>>73
あの文法は同期が主目的で非同期も問題なく書けるだけ。

OSのスレッド間通信は非同期しかなく、
同期したければ自前でループかサスペンド/ウェイクアップするしかない。
だからそんなに同期を取る事はなく、仕方なくやる程度。
そしてそれで何とかなってる＝従来分野は非同期で問題なく書けてる。

同期の場合、シェークハンド等の単純な方法なら同期プリミティブ無しで書ける。
多分もっと複雑な事も出来るのだろう。だけど俺にはそれに適した分野が分からない。
(従来分野は問題ないので、従来既に困ってたか新分野かだが、思いつかない)

ランタイムの仕様が無駄に大きいと、実行速度がそのまま低下する。
JSが無駄に速いのは、仕様が小さい(最小限に絞ってる)のもある。
チャネルの実装は以下(前スレ805内リンク8章)にあるが、
https://zenn.dev/hsaki/books/golang-concurrency/viewer/chaninternal
こんなまどろっこしい実装になってる理由は、同期（も出来る構造）だからだ。
非同期専用ならもっと単純な実装で済むし、速い。

だから優位性を発揮するためには、「同期チャネル」がないと辛いアプリがあれば分かりやすいが、
俺には今のところ思いつかないって話。
（非同期チャネルだと「空になったら止まる」という間抜けな同期しか出来ないが、実際それで十分という話）

**デフォルトの名無しさん** · 2022/03/03(木) 20:56:08.85

>>80
coroutine

**デフォルトの名無しさん** · 2022/03/03(木) 21:23:47.28

>>81
あ、そういう事ですか、なるほど。

まあ見てみましたが、相変わらずというか、何というか。
https://cpprefjp.github.io/lang/cpp20/coroutines.html

**デフォルトの名無しさん** · 2022/03/03(木) 21:54:21.27

Docker CLIのダウンロードみたいな
複数のプログレスバーを出せるライブラリほしい
何がおすすめ？

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

GUIなぞ基本的には管轄外です
お引き取りを

**デフォルトの名無しさん** · 2022/03/03(木) 22:22:12.59

CLIでのプログレスバーの話だろ？

**デフォルトの名無しさん** · 2022/03/03(木) 22:27:14.50

あーすまん

**デフォルトの名無しさん** · 2022/03/03(木) 23:09:26.23

いいってことよ

**デフォルトの名無しさん** · 2022/03/03(木) 23:29:47.34

>>64
そこは標準機能だけ対象といってもその定義が難しい
そのRustは標準(std)ライブラリーは最小限のものしかなくて
例えば乱数も暗号関係(TLS含む)も正規表現もJSONもHTTPも非同期ランタイムも何もかもstdに含まれていない
全てデファクトスタンダードで賄う方針だからそれらを標準機能として採用して比較してよい？

**デフォルトの名無しさん** · 2022/03/03(木) 23:35:59.34

rustはもう少し標準ライブラリにも機能増やして欲しい。

**デフォルトの名無しさん** · 2022/03/04(金) 00:05:33.31

>>88
俺が依頼してる話でもないから俺に聞かれても・・・ではある。そもそもここgoスレだし何のためにそれをしたいのかすら分からない。

単純に話を聞く限り
・goは言語機能で賄っているのに標準ライブラリ以外を使うとか流石に比較にならないと思う
・C++の標準ライブラリにもjsonやhttpや暗号はない
・同じロジックにこだわらず、追加のロジックで不足機能を補うなら、可搬性(プラットフォームごとに実行コードが変わらない)が必要
のではないかと思う

**デフォルトの名無しさん** · 2022/03/04(金) 07:00:31.23

非同期処理ですら紛糾して仕上がったのが2019/11な赤ん坊に無茶言うなって
Rustのコンセプトは分かるけど、学習難易度とライブラリの貧困さを何とかしないと浮かばれずにいつの間にか沈むぞ

**デフォルトの名無しさん** · 2022/03/04(金) 11:17:26.10

そんなにライブラリ貧困なの？
おれもまだ勉強中なんだけど何のライブラリで困るのか具体的に教えてくれ
勉強がてら試しに作ってみるかも

**デフォルトの名無しさん** · 2022/03/04(金) 13:21:46.53

>>91
学習難易度はキノコードが動画作れば解決w

**デフォルトの名無しさん** · 2022/03/04(金) 15:27:21.82

>>91
Rustも難易度は高くなくて広く色んなプログラミング言語をやってきた者には容易
例えばC言語などのenumを関数型言語の代数的データ型で拡張したのがRustのenum
そういうのを理解しているとメソッドによる代数的演算やパターンマッチングなどRustの基本機能も習得がすぐ
あるいは例えばGoでも構造体ベースのイテレータパターンを書いたことあればRustのイテレータも楽勝といった具合
GoやCのfor ; ; 文はRustには存在せずイテレータに集約されており更にメソッド連鎖させて操作の分離と抽象化でわかりやすく書くことが多い

**デフォルトの名無しさん** · 2022/03/04(金) 15:37:03.27

>>92
むしろRustは民主主義方式なのでライブラリは多種多様に豊富
異なる考え方で作られたものが両立している分野もあるし後から優れたものが出てきてシェア拡大も起きたりしている
代わりに標準ライブラリ(std)は必要最小限のものしかなく
その一部であるコア標準ライブラリ(core)はヒープがなくても動作する更なる最小セットを提供

**デフォルトの名無しさん** · 2022/03/04(金) 15:39:19.04

間違ってる上にスレ違いすぎるな

言語比較がしたいなら↓へ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

**デフォルトの名無しさん** · 2022/03/04(金) 15:48:00.84

>>96
間違ったことは書いていない
質問や話題があったからそれに対して答えたまで

**デフォルトの名無しさん** · 2022/03/04(金) 15:52:46.98

>>97
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 16:07:29.53

>>95
民主主義方式はc++みたいに標準委員会方式の場合だろ。
実装複数でデファクトスタンダードを競わせるってのは戦国時代方式だよ。

**デフォルトの名無しさん** · 2022/03/04(金) 16:41:14.71

>>99
あの標準委員会方式は強いて言えば一党独裁制だが紛糾ちぐはぐに近い
そしてC++の標準拡張が失敗してきた歴史を見ても反面教師としたのは理解できる

**デフォルトの名無しさん** · 2022/03/04(金) 17:03:59.90

>>100
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 17:23:53.33

確かに、いい加減Goの話に戻そう。

**デフォルトの名無しさん** · 2022/03/04(金) 18:00:31.30

>>102
荒らしに荒さないでって言ってるようなもんだぞ
話が通じる相手ならとっくにやめてるだろ
相手にせずにNGなどで無視したほうがいい

**デフォルトの名無しさん** · 2022/03/04(金) 18:09:02.15

>>103
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 18:20:16.68

そうだね
じゃあ 1.18 の話でもしよう

せっかく Generics が入るみたいのに、slice での Map、Reduce、Filter みたいなユーティリティが提供されないっぽいよね？
今はとりあえず準標準といえるものがこれ https://pkg.go.dev/golang.org/x/exp/slices
だと思うんだけど、そのうち増えるのかな？

例えばこんな感じの実装↓でいいと思うんだけど、本家でなんか議論されてるん？ Go追いかけてるひとおせーて！
https://gotipplay.golang.org/p/Y2cpCCPjKqr

**デフォルトの名無しさん** · 2022/03/04(金) 18:21:39.81

他のインタフェースが検討されてるとしたら、メソッドチェーンできるようにしたい、とかかな？

**デフォルトの名無しさん** · 2022/03/04(金) 19:18:02.80

Rustに移行すべきでは？

**デフォルトの名無しさん** · 2022/03/04(金) 19:23:47.26

>>107
>>96

**デフォルトの名無しさん** · 2022/03/04(金) 19:26:20.71

GoスレでRustRust言う奴から得るもんは何もない
失せろ

**デフォルトの名無しさん** · 2022/03/04(金) 19:27:58.27

>>106
メソッドチェーンの途中で>>105の実装のように毎回スライスを生成するのは無駄で遅いから
各メソッドをイテレータとして実装して中間生成物を作らないようにすべきかな

**デフォルトの名無しさん** · 2022/03/04(金) 19:30:36.16

たしかに効率的にするならイテレータにしないとね
それで簡単に仕様が決まらんのかな

**デフォルトの名無しさん** · 2022/03/04(金) 19:41:10.06

今一番rustの話で盛り上がるのがこのスレだからな

**デフォルトの名無しさん** · 2022/03/04(金) 20:33:03.39

Rust スレはどうなっているんだｗ

**デフォルトの名無しさん** · 2022/03/04(金) 20:34:31.83

NGword: Rust
なんでこれしないのか？

**デフォルトの名無しさん** · 2022/03/04(金) 20:36:30.45

>>113
Tauriで盛り上がってる
electronをRustで実装しなおしたら性能上がりすぎRust覇権とかwww
馬鹿だね～

**デフォルトの名無しさん** · 2022/03/04(金) 20:41:31.76

>>110
それ7年前のRust 1.0公開時からサポートしてる機能だが
Rustはプル型にすることで無駄な動きをゼロにしつつメソッドチェーンの形になってもヒープを使わずスタック上のみで動く特徴がある
しかしGoでは受け入れられる方針なのだろうか？
一方でプッシュ型であるチャネルを使った実装だとプッシュ型にすることでのムダよりもgoroutineを使うオーバーヘッドが大きい

**デフォルトの名無しさん** · 2022/03/06(日) 19:22:52.31

>>40
そのとおり。
決定的なのは、goをRustで実装してしまえばいいw
それがすべてだろw逆にRustをgoで実装することは何万年立っても不可能なんだからw
なぜならgcのある言語でgcのない言語を実装できないから

**デフォルトの名無しさん** · 2022/03/06(日) 19:40:37.34

Istioがまさにそうだよ
> RustをGoで実装

**デフォルトの名無しさん** · 2022/03/06(日) 21:05:29.02

フリーランスだけど未経験OKのところに応募してみた。
採用されたらよろしくな。

**デフォルトの名無しさん** · 2022/03/06(日) 21:06:19.97

>>117
なんでだよw
言語処理系にGCがあるかないかと、それから作られるバイナリにGCがあるかないかなんか関係ないだろwwww
インタプリタじゃあるまいし。

**デフォルトの名無しさん** · 2022/03/06(日) 23:38:19.72

>>117
コンパイラの処理って何か知ってる？

**デフォルトの名無しさん** · 2022/03/07(月) 00:39:41.57

>>117
あのーGoもRustも最終的に吐き出すのは機械語のコードだよ？
その場合GCはランタイムに含まれるんですがそれは実装する言語関係ないですよ？

**デフォルトの名無しさん** · 2022/03/07(月) 00:44:33.34

>>122
goでメモリ管理まで書くの？そしたら所有権とかの概念があるRustに軍配があがるだろ

**デフォルトの名無しさん** · 2022/03/07(月) 08:43:53.50

>>123
Rustの所有権とかのメモリ管理はコンパイル時に行われる静的な処理が中心となるので
どんな言語でも書けると思う

**デフォルトの名無しさん** · 2022/03/07(月) 08:55:53.15

RustあげてるやつがRustの良さを何も理解できてないのがホント阿呆らしい

**デフォルトの名無しさん** · 2022/03/07(月) 09:07:37.44

>>123
既にGoでGoのGC書いてるじゃん。

**デフォルトの名無しさん** · 2022/03/07(月) 10:35:08.70

>>124
単に書けるのと言語でサポートされてるのとはちがうんだよなあ
特に多くのは人が関わるプロジェクトでは

**デフォルトの名無しさん** · 2022/03/07(月) 11:00:36.82

>>127
Rustのメモリ管理の実現方式を理解出来てないと思う
コンパイル時に行われることと、コンパイルされた機械語が行うことの区別は出来てる？
Rustの所有権の処理はコンパイル時に行われるので、そのコンパイラがRustで書かれていようとGoで書かれていようと関係無い

**デフォルトの名無しさん** · 2022/03/07(月) 12:03:12.32

>>127
「サポート」じゃなくて「強制」。

ほんと、Rust信者はRustのメリット・デメリットを知らんな。

**デフォルトの名無しさん** · 2022/03/07(月) 14:11:55.83

>>123
どの言語に対するコンパイラもインタプリタも別のほとんどの言語で書ける
例えばプリミティブ以外は全てオブジェクト型になってしまうJavaScriptでもGoやRustのコンパイラを記述可能
もちろん記述可能性とは別の話として言語機能の強力さや高速性と省メモリ等の点から現存言語ではRustが最も有利であるだけにすぎない

**デフォルトの名無しさん** · 2022/03/07(月) 15:56:13.82

>>123
いやだからコンパイル後に動くのはランタイムのコードなの
Goとか関係ないの
ランタイムって意味わかる？
機械語に含まれる標準ライブラリやメモリ管理のコードのことだよ

**デフォルトの名無しさん** · 2022/03/07(月) 16:06:10.52

>>117 >>123
フルボッコでワロたʬ

**デフォルトの名無しさん** · 2022/03/07(月) 17:12:28.11

>>132
痛いところをつかれた証拠だな
よほど都合が悪いらしいwwww

**デフォルトの名無しさん** · 2022/03/07(月) 17:14:22.08

>>129
そうそれ
だが強制するとしないでは天と地の差がある
つまりセキュアが保証されるかされないかということに影響する

**デフォルトの名無しさん** · 2022/03/07(月) 17:54:54.88

コンパイラの仕事が何なのか知らない人がRustを推すのは流石に恥ずかしいからやめてくれ
Rust使ってる身としてはすごく迷惑

**デフォルトの名無しさん** · 2022/03/07(月) 17:55:43.77

>>134
Rustの言語仕様の所有権による実行コードの安全性の保障は、コンパイラをRustで書いてもGoで書いても、同じように得られる
逆にRustでコンパイラ書いたとしても、それによってコンパイルされたコードがRustの所有権による安全性を得られるわけじゃない

**デフォルトの名無しさん** · 2022/03/07(月) 18:08:24.58

やはりおじさんはVM系言語しか使ったことがないようだな
会話が成立しない訳だ

**デフォルトの名無しさん** · 2022/03/07(月) 18:28:02.87

GoスレでマヌケなRust推しが暴れているという地獄

**デフォルトの名無しさん** · 2022/03/07(月) 19:04:12.73

Rustの方が言語機能の強力さや高速性と省メモリ等の点から最も有利なだけにすぎないからね
ほとんどの言語でGoのコンパイラもRustのコンパイラも作ることが可能
この両者の区別ができないとね

**デフォルトの名無しさん** · 2022/03/07(月) 21:22:24.00

いわゆるVM系の言語(Java、C#、JavaScript、Python、Rubyなど)はランタイム自体がインタプリタに含まれてるので意識しないんだろうな

なんか普通に恥ずかしいよね
コンパイルが何をしているのかも知らなかったなんて
最近のVM系言語でもJITしてるし理解してるものかと思ってた
JITはインタプリタのランタイムのスタックとマシンコードのスタックを引き継ぐ処理とか内部でやってる
そういうのもわからないんだ

rustだなんだという前に大学に編入してCSを勉強した方が良いのではないか

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

なんでここまでボロが出る前にスッとROMに徹せられないんだろうね？

**デフォルトの名無しさん** · 2022/03/08(火) 02:39:31.07

>>140
そんなの知らなくていいよ

**デフォルトの名無しさん** · 2022/03/08(火) 07:57:09.39

Rustのことは忘れて

スライスってよく考えたら中にサイズとキャパシティ持ってるだろうからlen(スライス)はそれを見てるだけなのか？

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

>>143
おそらくそうだったと思うよ。

**デフォルトの名無しさん** · 2022/03/08(火) 08:17:46.56

これが良いかな。
https://stackoverflow.com/questions/28204831/how-do-gos-len-and-make-functions-work

**デフォルトの名無しさん** · 2022/03/08(火) 11:48:16.95

struct の中にスライスと長さを持たせてたよ…orz

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

RustのVecだって同じじゃん...orz

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

RustのスライスとGoのスライスは概念が異なる
Rustのスライスはポインタと長さの2点のみを持ち常に「参照」である
つまり「参照」ということは「本体」がある
本体は配列(＝そのままだとスタック上で長さ固定)やVec(＝ヒープ上で長さ可変)など
Rustのスライスはそれら本体の一部(もしくは全体)を指す「参照」という従属物
このように概念を整理して分離したことがGCのないRustの効率の良さに繋がっている

**デフォルトの名無しさん** · 2022/03/09(水) 19:25:13.15

まーた(ry

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

>>148
Go のスライスの内部実装も知らない男の人って・・・

**デフォルトの名無しさん** · 2022/03/09(水) 19:37:39.05

Goのスライスはうっかりデータ競合を起こしても自己責任
別変数に代入して各々に対して値を書き換えたりappendしたり可能だがもちろん互いに競合する
そして苦肉の策の結果としてappendでキャパシティを超えた時に両者がそこから分岐
一方でRustは言語仕様でデータ競合を起さないことを保証している

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

>>151
>>96

**デフォルトの名無しさん** · 2022/03/09(水) 23:07:53.69

>>151
Goの欠点だな

**デフォルトの名無しさん** · 2022/03/09(水) 23:15:13.75

Goのスライスは実質的には可変長配列として使うからね

**デフォルトの名無しさん** · 2022/03/09(水) 23:56:47.85

嘘つきはRustの始まり。std::syncだって同期とが標準モジュールに入ってるし、atomic型だって同じ。並列操作ではgoは他の
言語に抜き出ている。goが競合を起こすのはgoroutine同士でデータを共有するような、”古い老人のような作り方”をしている
からでchannelを通さない、sync.Mutexを使ったこともないasync/awaitだけでRustライブラリの中がArc<Mutex<T>>に
なってる事も知らないド素人がイキがってるだけ。
スレ違いなので荒らすのは止めましょう

**デフォルトの名無しさん** · 2022/03/10(木) 00:16:27.61

refrect.DeepEqual() って便利
だけど、単体テストでNG出たんで今日は寝ますね
(…どこが食い違ってるのか教えてはくれない)

**デフォルトの名無しさん** · 2022/03/10(木) 08:01:20.84

Javaやpythonからgoに来た人って絶対Rustにも行くよね?w

**デフォルトの名無しさん** · 2022/03/10(木) 08:05:56.68

皆さんストリンガーって保険のためにとか実装してる？