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/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

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

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

別に行かない

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

別にRustを使ってもデータ競合は防げるけど競合状態は防げないし、データ競合を防ぐ目的のために面倒なメモリ管理をやる気にはならないな

**デフォルトの名無しさん** · 2022/03/10(木) 14:34:23.63

JAVAから来ました

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

>>151
Goのスライスは言語設計ミスだけど
言語仕様を複雑にしたくないために起きている不幸の一つ
データ競合についてはGoは言語としてサポートせずプログラマーの腕に任せる方針

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

>>162
中途半端な仕様だな
それって意味ないだろ

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

今からGoですを勉強するのって意味ない？
rustとかいうやつのほうがいいの？

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

Goの採用はスタートアップなんかでも結構多いので意味無くはない
Rustは実際にはまだほとんど無い
とはいえGoをあえて勉強する必要があるかは微妙だな
こんなの経験なくてもチームに入ってからなんとなく空気読んで十分使えるし、
それができる程度に他言語の経験がないのであればGoはあまり意味のない言語だ

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

>>164
「勉強」の意味による。

仕事につながる技術を身に着けたいなら、普及率が高くて求人も多いJavaやcのほうがいい。
学問としてプログラム言語を勉強したいなら、より原理的なlisp(scheme),haskell,cのほうがいい。
趣味でプログラムするのに勉強したいなら、手軽で教本も多いpythonあたりかね。

goやRustは中途半端なので、最初の選択肢にはならない。

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

Goの戦場はニッチだからねぇ

汎用を求めるならJavaやC#
ハイエンドならC++
いっちょ大穴狙うならRust (次の次くらいに来るかも)

**デフォルトの名無しさん** · 2022/03/11(金) 12:02:29.15

Java, C# は使えて当然、C++が分かるなら誉めてもらえる

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

>>164
勉強はいつだって意味があるよ
2〜3日入門書を読めば大体分かるだろ
入門書の値段分ぐらいは価値があるよ

**デフォルトの名無しさん** · 2022/03/11(金) 12:19:29.55

goは言語自体はあまり面白くないからね
仕事で使う予定がないならもっと尖った言語の方が面白いだろう

**デフォルトの名無しさん** · 2022/03/11(金) 12:42:59.72

みなさんありがとうございます。
Javaとphpを仕事で使っていますが、Goの何でも自力で書く的なものに惹かれて将来的には仕事で使いたいと思いました。

**デフォルトの名無しさん** · 2022/03/11(金) 13:38:23.24

>>164
goかrustの2択だったらrustかな？
goは中途半端になってしまった。

**デフォルトの名無しさん** · 2022/03/11(金) 13:49:54.80

>>166の言う通りケースバイケースすぎてなんとも
もうちょっと素性や目的を明かしてくれないとね
あらゆるケースを想定して書くのはめんどう

**デフォルトの名無しさん** · 2022/03/11(金) 14:38:59.33

Goは文法だけなら超簡単だけど
channelを使った並行プログラミングのパターンをしっかり身につけてないと使い物にはならない

**デフォルトの名無しさん** · 2022/03/11(金) 14:45:54.90

Dust信者暴れないでください

**デフォルトの名無しさん** · 2022/03/11(金) 14:48:37.14

>>171
そういう志向ならgo もいいけどcのほうが勉強になると思う。
なんだかんだ言ってもサンプルとか解説はcのほうが多いし。

**デフォルトの名無しさん** · 2022/03/11(金) 19:15:19.80

>>171
> Javaとphpを仕事で使っています（中略）将来的には仕事で使いたい
どう考えてもJS一択。現在Javaメインで鯖周りだけPHPなら、明日から使える。

> 何でも自力で書く的なものに惹かれて
分野ごとに言語が違って一々勉強が必要なのはナンセンスじゃね？とは思うだろうが、
実際はJavaでも何でも出来るが、
例えばJavaでGUIやるよりは勉強の手間含んでも他言語の方がマシなのでみんなそうしてる。

Javaを既に普通に使いこなしているのなら、Goを『学ぶ』意味はない。方言程度で使えるはず。
引っかかるとしたらポインタだが、ポインタを学ぶならCの方がいい。
俺はパラダイム違いという意味でもJSだと思うけどね。関数ポインタ/クロージャを常用する言語をやった方がいい。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AF%E8%A4%87%E6%95%B0%E7%BF%92%E5%BE%97%E3%81%99%E3%81%B9%E3%81%8D/

**デフォルトの名無しさん** · 2022/03/11(金) 20:08:22.23

>>176も>>177も勧めてるけどC言語は基礎教養として必須
C言語のあとRustへ進めば進みやすい上に今どきの各種プログラミングパラダイムを押さえられていいかな

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

Cへの理解があればまあ何とかなるっしょ

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

>>178
JavaやっているやつにRust勧めるなよ。c++でRAIIとunique ptr勉強してからじゃないと無理。

GC前提のgo のほうが近道だわ。

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

>>180
C++は以前の「筋が悪いが代替がないから使う」から今は「避けることができる」言語
今となっては学ぶべきでない言語として大方のコンセンサスがあります
C→Rustと進むのが非常にわかりやすくてベスト

**デフォルトの名無しさん** · 2022/03/11(金) 21:27:24.13

ウェブ業界にいるんなら、Rustの案件は将来も少ないだろうし、
>>171が仕事で使う目的で学ぶっていう意味でいうならGoのほうがええやろ
教養としてならRustのほうが学ぶこと多くて面白いけど

**デフォルトの名無しさん** · 2022/03/11(金) 21:36:55.19

>>182
それならばウェブ業界で今急速に進んでいるのがWebAssembly
そしてWebAssemblyの記述言語は圧倒的1位がRust

**デフォルトの名無しさん** · 2022/03/11(金) 21:58:49.55

>>180
ただGoだと何も「新しくは」できなくね？

ガチ鯖はJavaで、ライト鯖はPHPで既に書けるなら、Goが他に活躍してる分野って何？
今時のデスクトップアプリはGUI無しとかあり得ないから、CLIアプリとか？ならJavaで全く問題ない。
Javaが動かせない貧弱環境(=非x86、非linux、つまり大体組み込み)ならC一択だし。

>>181
> C++は（中略) 今となっては学ぶべきでない言語として大方のコンセンサスがあります
これはない。お前の周りがトチ狂ってるだけ。Rust界隈はそうなのかもしれんが。

俺はRustは最終的に死ぬと思ってる。
C++とはコミュニティの規模が多分4桁違うし、FireFoxを殺したのはRustだし。
(まあ俺はGoも最終的に死ぬと思ってるんだが）

初心者は「全機能を使いこなす事が必要」だと思ってるみたいだが、これは明確な間違いで、
C++なんて全部入りなんだから全機能なんて使ってる奴は居ない。
(例えばインラインアセンブラも普通に出来るが、常用されても困るわけだし）
C++は元々「必要な機能を選んで使う」思想で、
初心者は「何が必要で何が不要か」判断出来ないから適切に使うのはかなり無理。
で、そういう奴は大体C++の悪口を言う事になるわけだが、ほぼ「肥大化してる」だけだろ。
それはお前が適切に取捨選択出来ないだけだ馬鹿タレ、でしかない。

**デフォルトの名無しさん** · 2022/03/11(金) 22:23:28.57

>C++は元々「必要な機能を選んで使う」思想で、
>初心者は「何が必要で何が不要か」判断出来ないから適切に使うのはかなり無理。

一人で使う分には自分が理解したところから使えばいいんだがチーム開発だと悩ましいよな。
書いた本人以外理解が難しいコードなんてのも簡単に量産されるし。

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

>>184
そこは冷静になって純粋に言語機能をC++とRustで比べてみればいいんじゃないか
言語としてはC++が勝っている点がほぼなくC++の様々な欠点をRustが改善解消
だからこそ大手IT各社が揃って共同でRust foundationを起ち上げるなど垣根を超えて惚れ込んでいる

**デフォルトの名無しさん** · 2022/03/11(金) 22:57:33.99

>>185
だから「コーディングルール」で切るんだよ。

つか、多分、C++とそれ例外では「コーディングルール」自体の意味が違う。
C++のは機能も使い方も制限する。Goとかだと見た目だけだろ。
(Goの場合は見た目もディレクトリ構成も画一だからもしかして何もない？
googleもC++/JS/PythonはあるがGoのはなさそう)

C++に問題があるとすれば、「難しいコードを書くことに何らブレーキがない」事で、
これをコーディングルールで補ってる。
C++以外の言語は「使うべきでない機能はそもそも入れない」で、これは正しいが、
後出しじゃんけんじゃないと無理。

>>186
言うてRustってC++で廃止されたauto_ptrを焼き直しただけだろ。
ヒープの生存期間をスタックと連動させるのはいいが、それはCでも書けるしCだと基本だった手法。（ただし手動）
だからRustで生成されるコードはC++でも書けてしまう。
そしてRustは境界チェックがある分だけ遅い。よって最終的に勝てる理由がない。
この点FireFoxの連中は大馬鹿もいいところで、スピード競争してるのに速度優位性がない言語を選んだ時点で自殺だった。

RustはCの代替になろうとしていて、勿論ネイティブバイナリを吐くわけだが、
これを潔く諦め、Cのコードを吐く（TS/JSの関係と同じ）だったら、覇権とれたかもとは思うけど。
この方法だと組み込み全分野に無理なく浸透していけるし。
(ただしこれだとC++の代替にしかならないから気に入らないのだろうけど)

RustでOS書こうとしてる馬鹿もいるだろ。誰も使わないよ。
Linuxより速くて小さい物を提供出来る技術的理由がないし、
仮にそれが出来てもCでも書けてしまうからLinuxももっと小さくなり、永久に追いつけない。
Rustには生き残る理由がない。

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

このおっさん勢いあるスレならどこでも湧くな。そして偏った知識で見境なく喧嘩ふっかける。かまってちゃんが過ぎる。

**デフォルトの名無しさん** · 2022/03/11(金) 23:13:16.62

>>187
そこまで無知だとは思わなかった
叩きたいならばまずは知識を身に着けないと恥ずかしいよ

**デフォルトの名無しさん** · 2022/03/11(金) 23:43:25.63

>>189
エコーチェンバーが欲しいのなら他言語スレに出てくるべきではないよ。

Rustが提供してる機能は結局のところ、プログラマの補助でしかない。
Rustで書かないと実現出来ないコードなんて存在しない。

元祖馬鹿向けCはJavaで、大ヒットして覇権を取った。
ただし関数ポインタが無かったのでGUIには全くフィットせず、そこは全滅してる。
とはいえ覇権言語であり、現在でも1/3はJavaだろ。

2代目馬鹿向けCがGoで、これもそこそこヒットしてる。(とはいえC/C++の規模からするとゴミだが）
RustなんてGo以下のゴミだし、そもそも人数は馬鹿>>>選ばれし勇者なんだから、
ずっとGoよりもゴミのままだと思うけど。
んで、元祖選ばれし勇者にはC/C++で十分だし。

俺はRustはC++のコーディングルールの一部になると見てるし、そうなる事を望んでる。

**デフォルトの名無しさん** · 2022/03/11(金) 23:50:45.41

>>190
C/C++の欠点はメモリ安全性等の欠如により発生する欠陥の多さであるとグーグルとマイクロソフトが意見を同調している
そこへ現れたRustはコンパイルが通ればメモリ安全性やデータ競合ゼロを保証するため彼らにも歓迎され用いられている

**デフォルトの名無しさん** · 2022/03/12(土) 00:13:31.67

>>191
C/C++の欠点は「馬鹿が『ひとりでも』混ざるとどうにもならない」事だよ。

ただ、静的解析で何とかなるものなら、「全部入り」のC++にもいずれは導入される。
現在C++は3周遅れ(9年遅れ）程度だから、
9年のうちに優勢になれば勝ちだが、これは多分無いでしょ。

**デフォルトの名無しさん** · 2022/03/12(土) 00:39:34.87

>>192
ところがC++には不可能
Rustには簡潔な借用ルールとライフタイムがあるために成立している
さらにRustにはunsafe操作の分離という導入もありこれが安全性の保証に大きく寄与している

**デフォルトの名無しさん** · 2022/03/12(土) 01:12:13.25

Go の G の字もないなｗ

**デフォルトの名無しさん** · 2022/03/12(土) 01:23:48.74

次スレまで待とうかと思ってたけど流石にワッチョイスレ作った方がいいか？
完全にスレが崩壊してる

**デフォルトの名無しさん** · 2022/03/12(土) 01:28:54.16

>>193
> ところがC++には不可能
『今の』C++にはね。
ただ、C++の場合は少しでもその方がコード効率がよくなる、とされると採用される。（ので良い物はいつか採用される）
それが「全部入り」

> 安全性の保証
要するに補助輪でしかない。Rustのは全部これ。

> 簡潔な借用ルールとライフタイム
これは俺は筋が悪いと思ってるけど。
プログラマに生存期間をマニュアルで管理させてるだけ。（これはCと同じ）
そしてRustの場合はこれの整合性を静的に解析出来る。（これはC++にはない。が、コンパイラ側で対処出来る話。そのうち導入される）
だいたいそもそも「貸し借り」なんてやってる事自体、
一般的プログラミングにおいての生存期間と合致してないからであって、根本的に筋が悪い。

そもそもプログラマは管理したいとは思ってないから、GCの方が筋がいい。
GCだと駄目な件については、例えば以下なら、（このブログは有名なので色々言われてるようだが）
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=bd6f6b9c5be3
そもそも大量の生存オブジェクトが存在する場合はGCには不向きなので、
Goについてなら例えば「GC非対象の変数宣言」構文が用意出来れば済んだ話。
(この思想がGCとフィットしないから一般的に導入される事はないが、
VC++ならnew/gcnewでGCなし/ありを切り替えられるし、俺はこれで十分だと思うよ）

まあ心配しなくても、所有権の貸し借りが素晴らしいってことになれば、C++にも確実に導入される。
そのときRustは死ぬよ。その猶予が9年間。

**デフォルトの名無しさん** · 2022/03/12(土) 03:16:10.27

>>196
合成の誤謬ってやつだね
C++は全てを含むから最強
あとはC++から必要な機能のみを抜き出せないユーザーの責任

完全チューリングマシンでもやっとけ

**デフォルトの名無しさん** · 2022/03/12(土) 04:40:23.33

VScodeで自前のパッケージを使おうとしたら、importの追加のクイックフィックスが出ないんだけど
これって昔からだっけ？

**デフォルトの名無しさん** · 2022/03/12(土) 04:49:23.73

あ、違うわ
プロジェクトのルートに置いてると /cmd/internal 以下のパッケージは参照できないみたい
なんだこれ？こんなルールあったっけ？1.17.7

**デフォルトの名無しさん** · 2022/03/12(土) 04:52:53.03

外部パッケージの参照の仕様はまあ仕方ないんだけど
なんで内部パッケージで相対参照できなくなったんだろう
どっかにブログとか理由の解説ない？

**デフォルトの名無しさん** · 2022/03/12(土) 05:00:12.51

ディレクトリ名とpackageでの宣言、二重に記述しないとまともに動かないパッケージ名ルール
物凄く不満

それでいてcmdとかのディレクトリだろうがmainはmainパッケージだし
一貫性よりも何か重要な理由があるのか？

**デフォルトの名無しさん** · 2022/03/12(土) 06:14:51.35

ITの9年は長いでよ、ロートルには短いかもしれんが。
そして30年という長い年月を持ってしてもC++はLinuxカーネルに入れなかったのにRustは入った。この違いよ

**デフォルトの名無しさん** · 2022/03/12(土) 08:30:46.88

>>202
> ITの9年は長いでよ、ロートルには短いかもしれんが。
長いという程長くもない。お前もオッサンになれば分かる。まあこれはさておき、
実際、現在のプログラミング言語のアイデアは既に80年代に出尽くしており、
今はそれを実装していってるだけ、とは言われてるだろ。言う程進化はしてない。
Rustだって何一つ「新しいアイデア」はないだろ。

> Rustは入った
ググってみたが、まだforkして勝手に起こしただけじゃね？
> https://japan.zdnet.com/article/35174333/
> https://thenewstack.io/rust-in-the-linux-kernel-good-enough/#:~:text=When%20we%20first%20looked%20at%20the%20idea%20of,the%20standard%20C%20normally%20used%20in%20Linux%20development.
多分知らないのだろうけど、オブジェクト指向最盛期(2005頃)には、
・Linuxのコードを『安全な』オブジェクト指向で書き直そう！
というプロジェクトはあった。今はググッても出てこない程跡形もないが。
これと同じだよ。
安全に書き直したコードは、書き直してないコード(既に世界中で使われてる)よりバグが多いから意味がない。
この反省を踏まえてRustは「書き直すわけではない」というスタンスのようだが。

LinusはC++の依存性を持ち込む文化を毛嫌いしている。だからC++は入らなかったが、Rustも同じ。
Rustのコードを入れれば、Rustが読み書き出来ないと参加出来なくなり、つまり開発人数がコミュニティ規模に比例して小さくなってしまう。
今現在のRustのコミュニティ規模なんて、C/C++からすると多分4桁くらい小さいだろ。それは開発人数を1/10000に削るのと同じ。
(C++ではコードそのものの依存性が問題だが、Rustの場合は他言語への依存が問題）
馬鹿じゃなければやらないし、Linusは馬鹿ではないと思うけど。

まあRustの連中はすさまじいエコーチェンバーの中で生活してる事は分かった。

**デフォルトの名無しさん** · 2022/03/12(土) 08:34:30.70

Rustスレで相手してもらえないからってこっち来るの止めてもらっていいですか

**デフォルトの名無しさん** · 2022/03/12(土) 09:40:04.46

何を勘違いしているのか知らんが、俺のこのスレの直前の書き込みは>>104

**デフォルトの名無しさん** · 2022/03/12(土) 12:00:36.41

cppの話はcppスレでやれよ。
しかしgcnewってC++/CLIの話じゃないの？

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

gcnewってなんだこれ、.Net専用とはいえなかなか邪悪な代物だな……

**デフォルトの名無しさん** · 2022/03/12(土) 12:34:33.53

>>196
それは知識が足りていない
借用ルールの借用とは当然ポインタを含む概念でありC++でも借用は普通に行われている
そして借用をよく見ると読み取りのみの借用と書き換えもありの借用の2種類がある点はどの言語でも同じ
読み取りの借用がある状況で書き換えの借用を許せばデータ競合が起きることはわかるだろ？
もちろん書き換え借用がある状況で読み取り借用を許してもデータ競合が起きうる
一方で読み取り借用だけならば複数の読み取り借用を許してもデータ競合は起きない
つまり『multiple reader XOR single writer』となりこれが借用ルールだ
もちろん全てのプログラミング言語においてこの借用ルールに違反するとデータ競合が起きうる
Rustはこの借用ルールに違反がないかどうかをコンパイル時に判定できる言語仕様となっている
だからRustはメモリ安全性だけでなくデータ競合安全性も保証することができるわけだ

**デフォルトの名無しさん** · 2022/03/12(土) 12:59:10.90

荒らしまくるRusterと不愉快仲間たち

**デフォルトの名無しさん** · 2022/03/12(土) 13:13:55.79

最近他のどのプログラミング言語スレいってもRustの書き込みあるな
飛ぶ鳥を落とす勢いとはこのことか
そういえばJavaが出現した頃、C++erがよくJava厨に噛み付いてたっけ

**デフォルトの名無しさん** · 2022/03/12(土) 13:17:12.31

>181 >186 >187 >190 >191 >193 >196 >197 >202 >203 >208 >210
>>96
荒らしに反応するやつも荒らしだからな。誘導だけしろよ。

>195
早いところワッチョイ立てようぜ。
NGが捗る。

**デフォルトの名無しさん** · 2022/03/12(土) 13:29:40.57

>>96 読んでみたが、なるほどここと同じような話が展開されてる。
ただ、C11に移行しようとしてるじゃないか。 >>202
> https://mevius.5ch.net/test/read.cgi/tech/1638086359/542
> トーバルズ氏、Linuxカーネルを「C89」から「C11」コードに移行する準備
> https://japan.zdnet.com/article/35184296/
このペースならあと10年はRustなんて入らないね。

>>208
> それは知識が足りていない
これはその通り。俺はRustやる気はないし、借用だ何だかんだの顛末を見て、様子見する事にした。

C++で既に慣らした奴ですら戸惑うのは、
自然な（直感的な）ライフタイムと言語の管理機能がマッチしてないからだよ。

そもそも俺はCでもメモリリークに困った事はない。
ただこれは「困らない範囲でやってる」(＝ごくごく安全運転に徹してる)からであり、俺が賢いわけではないが。
この辺の「安全運転を強いられる」のが嫌でC++的にやりたいのも分かるし、Rustも良い実験だとは思うが、
余計な事を考えて、しかもそれでコンパイルが通らない事に悩まされるのは、そもそも設計が悪いからだよ。
つか、そんな事で悩むくらいならGCの方がいいから、実際ほぼ全部の言語はGC持ってるわけだし。

GCの問題点は色々あるけど、discordについては、Goに「GC非対象」を明示する構文があればGoのままで行けてたはず。
何も考えたくないんだよ、っていうGCの思想に反するけど。
Goはポインタのキャストって出来たっけ？出来るのなら、自前で大きめに確保して(数百MB)、
そこから小分けするmalloc/freeを用意してやれば済む。(現行の機能だけで出来る）
システムプログラミング言語だ！OSだって書けるんだ！って言ってるんだから、まあ何とかなるんだろうけどさ。

>>207
魔合体されてるVC++が見た目異様なだけで、
gcnewは単にgc対象ヒープから取るだけ。使い方はGC言語のnewと同じ。
(&*が既に使われてるから%^になってて初見で拒絶されるのは仕様）

**デフォルトの名無しさん** · 2022/03/12(土) 13:30:00.30

>>211
96読んだ。俺は移動に同意でいいが、移動する権利は相手に与える。
つまり、レスが投下されたスレに俺もレスを投下するから、
俺にレス付けるなら、やりたい方のスレでレスしてくれ。

**デフォルトの名無しさん** · 2022/03/12(土) 13:48:18.60

>>212
全てのプログラミング言語の中で
コンパイラメッセージが最も親切でわかりやすく修整点も具体的に指摘してくれるのがRustコンパイラ
この状況でどうしてもコンパイルが通らないのだとしたら知能がよっぽど低いのではないだろうか？
標準的な知能があれば問題とならないような点でつまずいたのかね

**デフォルトの名無しさん** · 2022/03/12(土) 18:45:21.44

>212 >213 >214
>>96
とっとと行け。スレ違い続けんな。

**デフォルトの名無しさん** · 2022/03/13(日) 17:26:43.65

ワッチョイ無いとほんと不便ね

**デフォルトの名無しさん** · 2022/03/15(火) 11:20:02.60

Goってどうやって勉強すればいいの？

**デフォルトの名無しさん** · 2022/03/15(火) 11:47:39.11

>>217
Goに限らんけど俺の場合は実際に動くコードの載ってる本で写経しつつ読み進めるのが一番短時間で覚えるみたい。
俺って頭じゃなく体で覚えるタイプなのかも。
結局、文法的なものは他の言語触った経験あれば新しい言語も難しくないんだけど、キーワードの要不用やライブラリやそれの使い方とか、その辺記憶するのが一番面倒。

**デフォルトの名無しさん** · 2022/03/15(火) 11:58:47.19

>>218
やっぱ自分の能力次第だよな。
俺はなんかサイト一個作ったほうが覚えられそうだから作ってみるわ。
何作ろう

**デフォルトの名無しさん** · 2022/03/15(火) 12:36:58.99

標準的なソースコードを集めたコードサンプル集とかあればいいんだけどな。

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

ハイエンドというほどじゃないが、みんなのGo第二版はよく参考にしてる
flag使ったときとか

でも言いたいのは多分、ファイル読み込みとかごく基本のコード断片だろなー

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

https://qiita.com/takehanKosuke/items/9034e3d993df337eb669
こういうのの巨大なバージョン、誰かgitに公開してたりしないかね

**デフォルトの名無しさん** · 2022/03/15(火) 15:44:18.88

テーブルドリブンテストはなんか標準かでGenerateされるようになったね

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

テスト対象の呼び出しまで完璧にサポートされてて便利すぎる

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

Go 1.18 is released!
https://go.dev/blog/go1.18

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

ジェネリクス使ったmapやsliceのユーティリティが乱立するのかな

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

やっっっとジェネリクス医薬品きたのかよ
どれどれどんな塩梅よ

**デフォルトの名無しさん** · 2022/03/17(木) 01:41:25.22

>>225
よっしゃ！
そしたら1.17入れる準備するか。

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

やっとこういうのできるようになったか
https://github.com/samber/lo

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

>>229
使いにくいインタフェースで筋が悪いな
あと多段適用するにしても途中で毎回配列生成は無駄すぎる

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

GoCVのWindows版一生動作しなくて泣いてる
動作してる人がいたらmingwとgocvのバージョンの組み合わせとか教えてほしい

**デフォルトの名無しさん** · 2022/03/19(土) 14:59:48.35

>>231
解決した
gocv 0.28.0
mingwgcc 8.1.0
go 1.8
で動いた

**デフォルトの名無しさん** · 2022/03/27(日) 19:47:35.42

今更案件に採用したいとの連絡が来やがった。
もう他に決まっちゃったよ…

**デフォルトの名無しさん** · 2022/03/27(日) 20:03:34.05

go案件一回だけ行けたことあるけど
バージョンが古くてきつかった記憶あるなぁ
下手にでかいシステムだとそういうのあるんだよな

**デフォルトの名無しさん** · 2022/03/28(月) 00:04:31.98

もう go modules 無しで開発できる自信がない…

**デフォルトの名無しさん** · 2022/04/01(金) 09:14:02.94

構造体のブランクフィールド
struct {
_ int
}
って、どこかのソースで使ってるのって見たことある？

**デフォルトの名無しさん** · 2022/04/01(金) 10:24:23.29

1.18 で ~T って、T を実装している型という認識で正しいのかな？

**デフォルトの名無しさん** · 2022/04/01(金) 15:58:41.67

1.18 の言語仕様読んでるけど
ジェネリックスいらんわホントに
HTMLコメントでは書き足りてないとか、ホントにホントに…

**デフォルトの名無しさん** · 2022/04/01(金) 16:36:14.26

>>238
どう言う意味でいらない？

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

>>239
ジェネリックス入れる上では仕方のない事なんだけど、
型関係の言語仕様が山になって追加されてた

spec の単純行数にして
1.17 - 2823 行
1.18 - 3265 行 (+442行)

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

これからガンガンでかくなるはずなので、これに耐えられないなら早く逃げてくださいね
お疲れさまでした

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

>>239
ライブラリ開発者くらいじゃないのか？
欲しがってるのは正直、一部の開発者だよな
そのために仕様を10%単位でブクブク肥らすのは許容できるトレードなのか？