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/

**デフォルトの名無しさん** · 2024/04/28(日) 23:14:08.57

そんな心配しなくてもAIが進化すればGOもC/C++もRustもなくなって別の高級言語が生まれるよ、もう会話してればプログラムができちゃうような感じになる

**デフォルトの名無しさん** · 2024/04/28(日) 23:51:58.46

>>788
配列の境界チェックは任意に与えられたインデックス値に対してはC言語であろうとなかろうと境界チェック必須
一方で配列の内部であると確認されているなら不要(にすることができる)

例えば配列の内部であると確認されているならその配列内部へのポインタとして持ってしまえば
読み書きアクセスのたびに境界チェックは不要となる

よく使われる配列の全体もしくは一部分の範囲を順にシーケンシャルアクセスする場合もポインタにすれば境界チェックを不要にできる
なぜならその範囲の終端条件に達するまでは内部であると確認されてるため個別の境界チェックは不要

RustがC/C++と同じ速さで動くのもこの原理のため

**デフォルトの名無しさん** · 2024/04/29(月) 00:43:52.99

>>792
言ってる事は知ってるが、そうではなく、

> 任意に与えられたインデックス値に対して
の時に実際どうしてるか聞いてる。

C言語の場合は、境界チェックして無い。
Rustの場合はするらしい。だからこの部分でどうしてもCより遅くなる。
Javaは勿論やってる。だから馬鹿が書いて添字範囲をオーバーしたら、例外が返されたはず。
Goはどうだったっけ？という事。

で、Javaが792の手法でゴリゴリに高速化し、C比3倍遅かったのが1.8倍程度まで盛り返したのも知ってる。
そしてC#の方はJavaが6,7で留まってた際にも言語自体が進化してたので、高速化がまだJava程には至ってない。

あと、ついでに言うと、（別人かもしれんが)
> セキュリティホールが生み出し続けられている
> 結局C/C++を使用禁止にするしか解決策はない
これも間違いで、C/C++の場合は788に書いたとおり、
・（プログラマの技量により)バグを生みやすい
・ベアメタルなので問題があった場合に直撃する
だが、アプリとしてはバグが無い（上記上側がクリアされてる)、という前提なら、RustはC/C++と比べて安全ではなく、同程度でしかない。
セキュリティホールは設計上のバグだから、言語関係なく発生する。
(だからLinuxをRustで書きなおそうという馬鹿は居ないし、居てもポシャる。
そういえば10-15年程前はLinuxをC++で書き直そう、という連中が居たはずだが、消息聞かないところを見ると、完全にポシャったようだし)
ただ、Javaの場合はセキュリティホールを突いてもVMだから、さらにVMのセキュリティホールを突く必要があり、この意味では安全。
Goの場合はランタイムだから、VM程ではないにしても、ベアメタルよりはまし。ランタイムの実装によっては、VMと同等の堅牢さも確保できる。

ただ、言っちゃ悪いが、Rustの連中がやたら布教に熱心なのは、所詮はその程度の言語なんだと思うよ。
JavaScriptなんて悪口しか聞かないが、蔓延る一方だろ。プログラマに支持されてる言語はこうなるという例だよ。
Rustは精々ポリコレがんばってください。俺はRustは死ぬと予想してるし、そう望んでます。

**デフォルトの名無しさん** · 2024/04/29(月) 01:08:13.38

>>793
配列の境界チェックをしなければどんな言語でも範囲外アクセスで続行となり致命的な穴となります
だからC/C++以外はどんな言語でも境界チェックが行われています
C/C++でも自分で境界チェックを行わなければ致命的な穴となります
したがってそこで速度差は生じません

**デフォルトの名無しさん** · 2024/04/29(月) 05:43:48.04

なんかスレが進んどる。半分は読んでない。
けど大規模開発になると些細なパフォーマンスは関係なくなることには同意した。
それを差し引いても自分はGoが好き。

**デフォルトの名無しさん** · 2024/04/29(月) 08:46:16.16

>>794
Cで境界チェックしてる奴なんて、世界中でも誰もいない。
境界オーバーは純粋にバグであり、プログラマの責任でデバッグしておけ、というのがCの文化。
そしてずっとそうやって来てる。

だから動的に境界チェックをしてる限り、RustはCよりも原理的に遅く、実際そう。
この意味ではRustは補助輪付きCであり、補助輪の分だけ遅い。
Rust＝馬鹿向けC、といえば分かりやすいか。
そして、C/C++でなんら問題なかった連中からすると、
Rust？記述がウザくなるがリークがなくなって境界チェックしてくれる？
いやリークなんて元々しないし、デバッグもちゃんとやってるから間に合ってるよ、であり、
何もメリットが無いからRustなんて使わない。

**デフォルトの名無しさん** · 2024/04/29(月) 08:47:08.70

とはいえ数は力である。
Cの場合は「リークや境界オーバーするような馬鹿がコード書くな」であり、
コードを募る場合は中～上級者だけに対象を絞る大前提だが、

**デフォルトの名無しさん** · 2024/04/29(月) 08:47:32.78

Rustの場合は「文法に従ってさえすればリークは防げます、境界オーバーは動的チェックしてます」らしいので、
大多数の馬鹿からもコードを募れる。これが今の時代には向いているのも確か。

ただ、馬鹿向けCなら、Goの方が上だと思うよ。境界チェックしてたかは忘れたけど。

**デフォルトの名無しさん** · 2024/04/29(月) 09:45:04.56

>>798
Goももちろん正しく配列境界チェックをしていてindex out of rangeのランタイムエラーが出るよ
Cだけが基本的なこともできない古い失格言語で範囲外をアクセスしてしまう

**デフォルトの名無しさん** · 2024/04/29(月) 11:03:19.56

>>799
なら馬鹿向けCはやはりGoで決まりだな。

そして、「僕は馬鹿だから補助輪ください」か、
「俺はちゃんとデバッグするから補助輪なんてイラネエ、100%の速さをくれ」か選べる。
それでいいのでは。
(というかこの辺グダってるのはRustだけで、Go使う連中は最初から100%の速度なんて求めてない。
Rustが原理的にCより遅いのは回避しようも無い事実なのに、嘘ぶいてるからおかしなことになる。
そしてこの手のことを「選択肢を絞り、政治的に解決する」のがパヨクの常套手段で、典型的には>>785
パヨってるRustは当然嫌われてるだけ)

ただまあ、もう一度整理すると、Goは
・ポインタにまつわる問題はそれなりに対策されてる
・配列の境界チェックあり
・GCあり
・ランタイム
だから、経緯とか界隈の文化とか技術者の状況を無視して、単に純粋に言語の技術的側面だけを見ると、Goは
> javaの後継 (>>773)
は言えてるのかもしれんね。
そういえばJavaは「元祖馬鹿向けC」、Goは「２代目馬鹿向けC」と言われてたし、自然な発想なのかも。
ただ「安全」に関しては、一度保険をかけたら二度と戻れないものだから、Javaの連中がGoを「安全」と見なす事はなかなか無いとも思うが。
(ランタイムエラーを吐いてくれる環境で動いているソフトは、
ランタイムエラーで誤魔化せてるから動いているのか、
そもそもバグが無いからランタイムエラーは絶対にないのか、区別付かない。
だから、ランタイムエラーがある環境でどれだけ動かした実績があっても、『保険』をはずしてベアメタルに持って行くことは出来ない)

**デフォルトの名無しさん** · 2024/04/29(月) 11:07:50.34

Cと違ってGoは賢い

str := "01234"
a := []byte(str)

fmt.Println(a[3]) // → 51 (3のascii code)
fmt.Println(a[3:5]) // → [51 52] (3と4のascii code)
fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
fmt.Println(a[3:9]) // → panic: runtime error: slice bounds out of range [:9] with capacity 8

**デフォルトの名無しさん** · 2024/04/29(月) 11:37:52.73

>>801
> fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
これはランタイムエラーのほうがいいのでは？

**デフォルトの名無しさん** · 2024/04/29(月) 12:54:08.59

キータにでも行ってくれ

**デフォルトの名無しさん** · 2024/04/30(火) 23:59:10.31

>>802
なぜ？

**デフォルトの名無しさん** · 2024/05/01(水) 08:22:11.43

>>804
動作の一貫性が無いから。
或いは

fmt.Println(a[3:9])　を [51 52 0 0 0 0 ] (範囲外の値は0になる)

でもいいが、べき論ならランタイムエラーに揃えるべき。
境界オーバーはプログラマ起因の単なるバグであり、修正することを期待されるので。

ランタイムエラーは本来
・メモリ不足
・DB開こうと思ったが応答が無い、或いは何らかの理由でDBに書き込みが出来ない
・ユーザー文字列をevalしようとしたが、エラーになる
等の、『プログラマのミスではない』問題に遭遇する可能性がある局面でtry-catchするものであって、
プログラマ起因のバグがあってもそれなりに動かす為の仕組みではない。

けどまあ、実際はお前のように後者だと勘違いしてる奴が多いのも事実。
だからJavaは基本的に低品質、というかCでは許されない品質のコードが大量に混入することになる。
これをもって「安全」とするのは本来は間違ってる。
(低品質のコードでもそれなりに動かせる環境自体は研究する価値があるのも事実だが、これは本来は明確に別件としてやるべき。
なおGoの場合はpanicから復旧する手段はなかったような気がするので、この点は多少ましかも)

**デフォルトの名無しさん** · 2024/05/07(火) 01:44:11.10

んで、けっきょく今時点だとGoとRustはどっちがええねん
どうせ「用途による」とか玉虫色の回答しか言えないやろ

**デフォルトの名無しさん** · 2024/05/07(火) 04:24:12.21

>>806
人による
君にはGoがお似合い

**デフォルトの名無しさん** · 2024/05/07(火) 06:37:23.80

長文を連投してる人、Goのことを知らなすぎて草

>>793
> Javaは例外が返されたはず。
> Goはどうだったっけ？という事。

>>805
> Goの場合はpanicから復旧する手段はなかったような気がする

**デフォルトの名無しさん** · 2024/06/18(火) 21:17:45.07

tinygo 0.32.0きたね

**デフォルトの名無しさん** · 2024/06/19(水) 23:06:48.88

TinyGo 知らなくて、流行の組み込み用サブセットみたいなヤツかと思ってググってみたらそのとおりなんだけど
WebAssembly でも出力できるんだな
意外と良いかもしれない

**デフォルトの名無しさん** · 2024/07/28(日) 18:50:53.82

UTF-8をShift-JISにエラー無く文字コード変換したいんだけどググって出るサンプルは変換できない。
実例ないですか？

**デフォルトの名無しさん** · 2024/08/07(水) 05:15:10.47

TinyGo よいよね

**デフォルトの名無しさん** · 2024/10/06(日) 12:22:59.83

WindowsでExec.Command()でPipe経由の
処理ってできるの？コマンド実行エラーになる

**デフォルトの名無しさん** · 2024/12/18(水) 11:16:14.03

最も使うプログラミング言語、Python連覇　COBOL上昇
https://www.nikkei.com/article/DGXZQOUC045XF0U4A201C2000000/

**デフォルトの名無しさん** · 2024/12/25(水) 08:07:30.27

日時のシリアル値から
実際の日時に変換するには
どうしたらよいですか？

**デフォルトの名無しさん** · 2024/12/25(水) 23:28:06.92

シリアル値って何？UNIX時刻？UNIX()あるよ

**デフォルトの名無しさん** · 2024/12/29(日) 14:52:44.20

シリコンバレーの1流のエンジニアがGoの入門書を書いた！みたいな本を見かけたから買ってみたわ。
買ったからには読むけど、20/100点ぐらいの本だろうな。

**デフォルトの名無しさん** · 2024/12/29(日) 18:55:25.73

発売前からアマゾン1位jのやつだろ？

**デフォルトの名無しさん** · 2024/12/30(月) 00:21:57.66

立ち読みしたけど至って普通だった
Goの本はレベル高いものが多いからそれに比べると普通に入門書レベル

**デフォルトの名無しさん** · 2025/01/04(土) 13:31:21.68

【IT】初心者が最初に学ぶプログラミング言語　3位「Python」、2位「C言語」、1位は？
https://egg.5ch.net/test/read.cgi/bizplus/1735924157/

**デフォルトの名無しさん** · 2025/01/04(土) 14:11:45.29

Rust

**!id:ignore** · 2025/01/18(土) 15:45:57.85

ジジイは死んだんか？w

**デフォルトの名無しさん** · 2025/01/18(土) 17:34:58.21

Javaはメソッド呼び出し時の引数が
プリミティブの場合、コピー渡し
オブジェクトの場合、参照渡し
合理的

**デフォルトの名無しさん** · 2025/01/18(土) 17:35:50.07

GoにはもしかしてちゃんとしたHTMLパーサーがあるのでは

**デフォルトの名無しさん** · 2025/01/18(土) 22:02:52.51

>>823
それは合理的ではないな
小さいオブジェクトでその値を書き換える目的でないならばコピー渡しが圧倒的に有利

**デフォルトの名無しさん** · 2025/01/18(土) 23:07:47.87

そもそも前提が間違ってる
Javaには値渡ししかない
これ何十年も前から何度も何度も初心者に言って聞かせるやつ
「プリミティブ型の値渡し」「参照型変数の値渡し」これしかない

void foo(std::string s) { // c++ 値渡し
s = "foo"; // 呼び出し元に影響なし
}
void bar(std::string &s) { // c++ 参照渡し
s = "bar"; // 呼び出し元に代入される
}
void foo(String s) { // Java 値渡し
s = "foo"; // 呼び出し元に影響なし
}

このことってそんなに難しい？
なんで初心者はいつもここ間違うの？

**デフォルトの名無しさん** · 2025/01/19(日) 07:54:07.72

Javaは参照型について
参照値自体の値渡ししか出来ないの？
参照値が指してる先の値の値渡しが出来ないってこと？
効率悪いね

**デフォルトの名無しさん** · 2025/01/19(日) 09:11:16.49

んなことはない
参照値自体の値渡し : 参照値をコピー→必要に応じて渡した先でデリファレンス
参照値が指してる先の実体の値渡し : デリファレンス→実体の値をコピー
ここで、一般に参照値のコピーは単なる64ビットの数値のコピーであるのに対して、実体の値は複合データであるため単なる参照値よりコピーのコストが大きい
従って、殆どのケースでは後者の方が非効率である

**デフォルトの名無しさん** · 2025/01/19(日) 09:57:03.41

>>828
間違っている
関数への参照(アドレス)渡しはその先で実際の値があるメモリを読み込んでようやく値を得るから遅くなる
呼び出し元関数でも実値を何らか処理していることが多いので既にレジスタ上にあることが多い
したがって参照アドレス渡しではなく値をレジスタ渡しで関数を呼び出すのが速い

**デフォルトの名無しさん** · 2025/01/19(日) 16:14:51.30

もし一般的にその説が成り立つなら大きな構造体のコピーを避けることを目的とした参照渡しをする必要はないことになるが、そう主張したいのか？

**デフォルトの名無しさん** · 2025/01/19(日) 16:41:50.96

>>830
常に参照を渡すばかりではなく適材適所で使い分けられることが重要という話だぞ
自分の関数でも処理をしているデータなら既にメモリから読み込んでレジスタ上にあるから遅くなるアドレス渡しの必要がないという話
もちろん関数にレジスタ渡しできるサイズは限りがありABIで定められている
例えば86系64bitでLinux等なら64bit✕6個まてはレジスタ渡しできる

**デフォルトの名無しさん** · 2025/01/19(日) 21:01:24.78

オブジェクトはコピーに時間と空間が必要なので参照渡し
合理的すぎる

**デフォルトの名無しさん** · 2025/01/19(日) 21:24:12.64

>>832
例えば小さいオブジェクトは参照アドレス渡しよりも値コピー渡しが速い
例えば一番小さく整数一つだけをオブジェクトに包んで専用メソッドを付けて単なる整数型とは別の型を作ることはよく行われる

**デフォルトの名無しさん** · 2025/01/19(日) 22:26:45.76

Goの場合は、
どうせコピーのコストが大きな問題になるようなオブジェクトはコレクションと文字列だけ
だからそいつらさえ常に参照(の値)渡しになるようにしときゃ構造体は基本的には値渡しで実用上問題ないだろう
という極めて雑というか実用主義的な判断のなされた仕様になっている
実際には参照渡しの方が効率的なケースも多いが、少々の効率を理由にポインタ渡しを選ぶことは好まれないのがGo流

**デフォルトの名無しさん** · 2025/01/21(火) 16:27:44.96

Javaは目からウロコが落ちる出来事だった

**デフォルトの名無しさん** · 2025/01/21(火) 16:29:19.66

ちょっと聞いてよ私はハゲ
20世紀からのC/C++使い

**デフォルトの名無しさん** · 2025/01/21(火) 20:51:56.00

お呼びじゃない
カエレ！

**デフォルトの名無しさん** · 2025/01/22(水) 16:05:32.40

だいたいGoって名前がダサすぎる
なんだよゴーってよ、ゴー!!ゴー!!ゴープログラミング!!ってかwwww昭和かよwwwwwwwwww

**デフォルトの名無しさん** · 2025/02/11(火) 23:43:29.84

アセンブラを知らないから
どういうコードに落ちるか
想像つかないんだろな

**デフォルトの名無しさん** · 2025/02/11(火) 23:45:13.36

昔はレジスタに値をセットして割り込みかけるのがシステム呼び出しだったから
どんな言語使ってようがアセンブラは必須だった

**デフォルトの名無しさん** · 2025/02/12(水) 10:56:43.50

ブブー
間違いです

**デフォルトの名無しさん** · 2025/03/02(日) 23:09:02.68

Javaで参照渡したいとき配列で渡してたわ

**デフォルトの名無しさん** · 2025/05/15(木) 21:27:28.17

【海外記事紹介】Go言語から離れる開発者が増えている？その理由とは
https://techfeed.io/entries/68250b69c4e1671f6888ca33

Go は 2007 年に Rob Pike、Ken Thompson、Robert Griesemer が開発し、クラウド・インフラ向け言語(“C of the Cloud”)として脚光を浴びた。しかし 2022 年頃から、早期採用者の間で「プロトタイピング専用言語」「入門用言語」として位置づけ直す声が増え始めた。背景にはエコシステムの限界や AI ワークフローとの相性の悪さがある。

Go から離脱する開発者が挙げる代表的な不満点は次のとおりだ。

エラー処理が冗長で、同じ if err != nil パターンが散在する。
goroutine は強力だが、競合状態や静かな失敗を招きやすく、テストが難しい。
“No frameworks” 文化により、共通機能を一から実装する負担が大きい。
Go エンジニアの母数が少なく、採用・オンボーディングコストが高い。
生成 AI が慣用的な Go コードを出力しづらく、Python などに比べ生産性が劣る。

一方で、パフォーマンスとシンプルさを兼ね備えた Zig、豊富なツールチェーンを持つ Kotlin、安全性と速度で評価される Rust などの新たな言語は、Go言語への不満を解消する選択肢として、開発者たちの関心を集めているという。

**デフォルトの名無しさん** · 2025/05/16(金) 10:08:38.99

pythonよりAIの相性が悪い？？動的言語なのにいいわけねーだろ笑

zigとRustとか流石にバカすぎるw 低レイヤ用の言語でIT土方は関わらない言語なのにw
そして書いてある欠点がないC#は無視されてて草

**デフォルトの名無しさん** · 2025/05/16(金) 12:17:23.65

C＃はLinuxと相性悪そうだからね。候補に挙げられない

**デフォルトの名無しさん** · 2025/05/16(金) 12:30:40.01

>>845
今はもう完全にクロスプラットフォームだけど？無知乙

IDEもRiderが使えるしVSCodeでもいい

**デフォルトの名無しさん** · 2025/05/16(金) 12:32:36.26

>>846
そんな事ある?
MS関係者はもっとLinux事例のアピールしなきゃ

**デフォルトの名無しさん** · 2025/05/16(金) 12:34:31.04

IDEはjetbrains製のか。VSがLinux来ないと

**デフォルトの名無しさん** · 2025/05/16(金) 12:55:52.74

無知乙
2014から.NET Coreが出て完全にクロスプラットフォームだわ

Github ActionsとかC#で描かれてるし、stackoverflowもそう

開発PCはWindowsでサーバはLinuxを使えばいいだけ
Linux環境欲しいならWSL2を使えばいい
Macみたいなバカみたいな高いPC買う必要ないし会社でもメリットが多い

>>848
Goも同じだけど何言ってんだ？IDEはGolandしかないよね、LSPでVSCodeやneovimが使えるのはC#もGoも共通なんだが？

**デフォルトの名無しさん** · 2025/05/16(金) 13:17:59.65

IDEがないとビルドできないマンが量産されてるのか
Javaの二の舞

**デフォルトの名無しさん** · 2025/05/16(金) 22:37:19.26

Goはルーン文字と同じ運命をたどりそうだな
紙が普及した時代に原始的な彫刻文字は流行らない
時代に合わせて形を変えないと

**デフォルトの名無しさん** · 2025/05/17(土) 11:22:02.13

GC付きCとしては残るんじゃね？
言語の衰退期に入ったのは事実だろうが、それならJavaやPHPも同じ
個人的には死んで欲しいのはRust、理由は信者がウザイから

○○付きC、が乱立気味なのは、Cがやる気無さすぎなのと、C++が暴走してるから
ゆうて今後コア数はてんこ盛りになるようだし、goroutineが速ければワンチャンあるが…
https://qiita.com/kawasin73/items/3d2aa21f0b4bf05de1c6

**デフォルトの名無しさん** · 2025/05/17(土) 12:23:41.13

>>844
Rustが低レイヤ用の言語ではなくて低レイヤもC同様扱える言語だね
Rustを使ってる人たちのアンケート調査で最大利用分野はWebだと判明しているよ

>>852
C/C++を置き換えられるのはRustだけで既に進んでいるからかなり長生きするだろうね

**デフォルトの名無しさん** · 2025/05/17(土) 12:39:18.59

>>853
> 既に進んでいる
と思ってるのは信者だけ。まだ実際は「入った」事がニュースになる程度
まあ昨日話題になってたがマスゴミ的に「モームリが大盛況！！！」と同レベル
そして必ず信者が沸くのが本当にウザイ

**デフォルトの名無しさん** · 2025/05/17(土) 12:49:46.67

>>854
その書き込みさえもRust製のPingoraを通過して5chに書き込まれているよ
世界のネットインフラのRust化の恩恵だね

**デフォルトの名無しさん** · 2025/05/17(土) 13:06:04.46

はいはいすごいね
だけどそんな事を言ったら、C無しで出来る事って何もないのでは？
JavaやC#も同レベルだし
マジでRust信者は死んで欲しいし、殺す為に新言語を開発したいと思うよ

**デフォルトの名無しさん** · 2025/05/17(土) 13:12:54.63

Rustスレでやってください…

**デフォルトの名無しさん** · 2025/05/17(土) 13:33:19.14

C言語の役目を完全に置き換えることができるRustの出現はデカいよな
Goはシンプルな芸術的な反面で色々と中途半端な機能と立ち位置になってしまった気がする

>>856
Rustを置き換えることができる新言語の開発すばらしい！
C→Rustで43年間かかったらしいけど
今はまだ芽も発見されてないから早くて20年後かなあ

**デフォルトの名無しさん** · 2025/05/17(土) 13:41:42.69

>>856
また信者が生まれるよ。君の信者だよかったね

**デフォルトの名無しさん** · 2025/05/17(土) 13:46:37.14

>>857
全くその通りだ
勝手にエコーチェンバーでホルホルしてればいいのに、出張ってくるからウザイ
まあ一応、俺の勝手な感想を>>843について述べておくと、

> エラー処理が冗長で、同じ if err != nil パターンが散在する。
Try-catchもろくでもない
現在のプログラミング言語はまだエラー処理に最適な記述方法を発見出来てないだけ

> goroutine は強力だが、競合状態や静かな失敗を招きやすく、テストが難しい。
静かな失敗がデッドロック等を意味するなら、そりゃそうだが、
ハードウェアの近未来(数年後)がEコアマシマシ方向なので、コンセプトとしては合ってた
ただ、そもそもメニーコアはおそらく現在のフルスペックなCPUの多数盛り(16-64コア)ではなく、
小型限定機能CPUの『超』多数盛り(1024+コア)が正解だと思うので、
ハードウェアもGo言語自体も中途半端な状況で、中期的(10年後)にも厳しい

> “No frameworks” 文化により、共通機能を一から実装する負担が大きい。
Framework on framework が乱立してる他言語に対してのアンチテーゼとしては意味があったし、
実際、dllはCで世界が構築されてるとき、つまりLinux等では有効だが、それ以外では依存性の問題が面倒なのは事実
しかし現実的には、frameworkをいくら嫌ったところで、同様のコードはどうせ記述する事になるのも事実
同じような事を何度もやる＝大企業内の職業プログラマにとってはframework学習の方がマシと見えるのもそうだろう
乱立してたframeworkも、各言語毎にほぼ統一気味だし

> Go エンジニアの母数が少なく、採用・オンボーディングコストが高い。
状況知らんのでなんとも

> 生成 AI が慣用的な Go コードを出力しづらく、Python などに比べ生産性が劣る。
Pythonは人数が多いだけ
そもそも自動生成コードで出力しづらいとかは言語に依らず、やってる人数だけの話

**デフォルトの名無しさん** · 2025/05/17(土) 14:11:35.74

>>859
実際、その方向で殺す事になると思うよ(俺の言語ではなくね)
今の『日本の』Rust信者って、Cを勉強しない言い訳としてRustをやってて、非Rust使いを排除して、俺ツエーホルホルしてるだけでしょ
『アメリカの』Rust使いは、「(Cを殺そうと思ってRustを出したのに)RustのおかげでCを勉強する奴が(以前よりも、またRustよりも)増えてしまったじゃねえかよ！！！」とか言ってて、
なるほど連中は正しく学習しているのだな、とは感じるが
なんつーかここら辺、アメリカがソフトウェアで圧倒的に強いのは、センスの違いを感じるよ
(まあアメリカのRust信者もウザイのは同じらしいが)

多分数年後、「Rustを超えた！！！」という言語が現れ、俺ツエーしたいだけの馬鹿Rust信者はそっちに移る
その辺でRust死んでくれねーかなと思ってる
(そしてこの意味では、俺ツエーしたいだけの馬鹿がたむろする言語は必ず存在してて、それがC++→Rustになってるのが今、というだけでもある)

>>858
> 今はまだ芽も発見されてないから早くて20年後かなあ
そう思ってるのはお前だけ
単純に、Cの駄目な点をチマチマ直せばいいだけの話

だから俺の場合は「新言語」ではなく「ハイパーCプリプロセッサ」になる
例えばif err != nil パターンが嫌で、try-catchで書きたければ、try-catchをif errパターンに変換する物があればいい、というだけ
Cがウザイのは記述レベルが低すぎるからであって、JSレベルでリテラル記述出来ればだいぶ変わる
というかCの問題は言語仕様ではなく、主に書きにくい点だけだから
(Rust信者はメモリ管理が出来ないのだろうが、Cを『正しく』使っててメモリリークする馬鹿は居ない)

**デフォルトの名無しさん** · 2025/05/17(土) 14:24:44.58

>>861
なぜCが捨てられRustへ置き換えられていってるか世界の流れの理由を把握した方がええよ
毎月どこかで言語の欠陥によるセキュリティホールが見つかる昨今
必ずミスを引き起こす人類に対して言語仕様で自動的に安全を保証する点が求められてる
その点Goは自己責任な面でちょっと向かい風なんだよね

**デフォルトの名無しさん** · 2025/05/17(土) 14:38:07.99

CとGoは同じ人が策定に関わってる時点で限界あるんだろうね。似てしまう

**デフォルトの名無しさん** · 2025/05/17(土) 14:40:21.44

>>862
> 言語仕様で自動的に安全を保証する点
俺はそれを言語仕様で「手動」ではなく、コンパイラやプリプロセッサで「自動」化する方向
まあ俺はC派なので馬鹿は死ねではあるが、Rustが馬鹿対策出来てる点は評価してるよ

というかね、お前のコードは「駄目」だからreject、となるとだいたい軋轢が発生するわけで、
その最低限のラインを「コンパイルが通る」として、プルリクされたコードは原則全てacceptならRustは昨今のGitHub的開発では強い
でもこんな運用出来てる奴居ないでしょ
結局人間が判断してるのならどの言語でも大して変わらん

> 言語の欠陥によるセキュリティホール
って何ぞ？
もしかして境界チェックの話？ならJavaだとセキュリティホールは存在しない事になるけど、そういうレベルの馬鹿か？

**デフォルトの名無しさん** · 2025/05/17(土) 14:44:35.88

コードが駄目って言語化が足りない。やり直し、レビュアーは60過ぎの頑固爺だな

**デフォルトの名無しさん** · 2025/05/17(土) 14:45:52.25

>>863
というか元からbetterCだろ
Cにそんなに不満がない人が作ったらそうなる
(というか多分、不満があったのはCではなくC++に対してなんだろ)

まあでも、C++ではないbetterCとしては、これもありかな、という仕様だとは思うよ

**デフォルトの名無しさん** · 2025/05/17(土) 14:47:41.15

境界チェックだけでなくnil (やnullやundefinedなど)チェックのミスなど色々あるね
ヌルポが起こるJavaなどは論外だね

**デフォルトの名無しさん** · 2025/05/17(土) 14:57:24.25

>>865
ゆとりか？
「駄目」ってのはこの文脈で一言で表現してるだけで、
実際の所は当事者間で何回も往復してて、もっともらしい理由は添えてると思うぞ

ただ、Cの場合に、駄目なコード(例：メモリリークを誘発するコード）を受け入れる事が出来ないのは事実なんだよ
そして、これを相手に説明しても、相手が理解する事はない
だってそもそも理解してないからそういうコードなんだし、逆に理解してたらそういう『駄目な』コードなんて書かないから
だからrejectはどうやってもけんか腰になるし、
この展開～結末を知ってたら最初からrejectとして何も言わない奴もでてきてもおかしくないし、実際に居るとも思うけど
(だからGitHub等では独裁/フォークであって、民主主義的多数決ではない)

こういうのを一々相手のせいにするのは、ゆとりやZの特徴ではあるが、
これも含めて昨今の情勢ではあるから、Rust的に文法にしてしまうのは一つの対策ではある
(ただしこれが機能するのは受け入れ基準＝文法とするときであって、実際にこういう運用をしてる奴は居ないと思うので意味無いが)

**デフォルトの名無しさん** · 2025/05/17(土) 15:00:26.74

>>867
俺はそういうのはリンターで対策出来ると思ってる
だからその場合はJava＋強力なリンターで落とせばいいだけの話

わざわざ新言語にして書き換え、他言語使用者を排除し、
結果的に少数精鋭！！！と勝手に妄想して俺ツエーやりたいだけの馬鹿は死ね、だね

**デフォルトの名無しさん** · 2025/05/17(土) 15:09:10.86

>>861
>> Cを『正しく』使っててメモリリークする馬鹿は居ない

メモリーリークによる穴の報告が常にあってなくならない理由をわかってないのか
複雑化するとどんなプログラマーもうっかりミスすることが判明している
静的分析でも一部しかミスを見つけられないことも判明している
そのため穴発生のレポートが絶えない

>>869
>> リンターで対策出来ると思ってる

静的分析では一部しかミスを見つけられないことが判明している

**デフォルトの名無しさん** · 2025/05/17(土) 15:17:32.48

>>868
説明しても揉めるようなメンバーしかいないのか。あんた可哀想だな

**デフォルトの名無しさん** · 2025/05/17(土) 17:43:17.73

>>870
> 静的分析でも一部しかミスを見つけられないことも判明している
> 静的分析では一部しかミスを見つけられないことが判明している
そういう問題じゃねえ

Rustは静的解析で完璧！！！なんだろ
なら、静的解析で出来るのは事実だろ
この矛盾にすら気づけないから馬鹿信者なんだよ

Javaで問題になるのはnullを代入してるからであって、
これはnull許容型と禁止型を明示的に分離してないからであって、やりゃいいだけの話だろ
要は、Rustと同じ手法で安全にする事は他言語でもやれば出来る
どこまで文法化し、どこからはプログラマに任せるかを各言語が決めてるだけ

Javaが中途半端だ！というのはごもっともだが、
それはセキュリティ要求とプログラマの想定知能レベルがJavaの頃と現在で変わったから
当然後発のRustの方が今に合ってるし、
Java7で10年弱全く変化しなかったから「死んだ」と開発元に言われてたし、実際そんな感じではある
とはいえ、RustよりJavaの方が殺しても死なないのも事実
Java8以降は半年毎に上げる事にしたようだし、既に後発言語になってるので、
必要なら上記の通り他言語を参考に新文法を導入していけばいいだけ
(この意味ではJavaもRustを殺せると思うけど)

信者は「Rustが！！！」と思ってるが、
正しくは「手法が」であって、当たり前だが他言語でも同じ手法で同じ事は出来る
だからRustは「現代的新文法詰め合わせ実験言語」であって、まあ頑張れといったところ
(ただ、言語としての筋が悪いので、どうせ駄目だと俺は見てるが)

**デフォルトの名無しさん** · 2025/05/17(土) 17:43:43.79

> 複雑化するとどんなプログラマーもうっかりミスすることが判明している
これが間違ってるというか、考え方が根本的に違うと最近は感じてる
「無重力でも書けるボールペン」指向のbetterCがC++で、
「一方ロシアは鉛筆を使った」指向のbetterCがGoなんだよ
そしてRustは前者、ところがCに似合うコードは多分後者なんだな

そしてうっかり、とかいう話でもない
つか、お前も「トイレで『うっかり』ケツを拭き忘れた」事なんて、何十年も無いだろ
習慣化＋目に入る位置に紙がある、の合わせ技だが、でも見た目紙が無くても探すだろ
メモリリークしないのは、こういうレベルの話なんだよ
(だからRustが必要な奴＝ケツを拭く習慣がない奴には全く通じないのも事実だし、
実際お前が理解出来るとも期待してないが)

**デフォルトの名無しさん** · 2025/05/17(土) 21:51:30.90

Goも別にC/C++ほどにはプログラマを信用してないと思うけどな
GCはあるし、変数は必ず初期化されるし、ポインタへの算術演算も禁止してるし
そもそもCの置き換えを目指すような低レイヤーを扱う言語じゃないので

**デフォルトの名無しさん** · 2025/05/17(土) 22:21:05.70

一応Java対抗よね。Oracleで混迷してるし、あってよかったと思うわ

**デフォルトの名無しさん** · 2025/05/17(土) 22:53:10.81

>>874
CはCPUが遅かった時代だから余分な事を一切しないだけで、信用と言うよりは放任
なのでプログラマ間で信用出来ないコードをrejectする事が必要になる

> そもそもCの置き換えを目指すような低レイヤーを扱う言語じゃないので (>>874)
> 一応Java対抗よね。Oracleで混迷してるし、あってよかったと思うわ (>>875)
いや当初はシステムレベルも記述可能と謳ってたはず
実際、出来るとは思うし
(とはいえCの方がいいのでほぼ誰もしてないが、Dockerはシステムレベルとも言える気が)

Java対抗なんて初耳だが、最近は看板掛け替えたのか？
Javaとダダ被りなのはC#のはずだが
Java＋ナマポ＝ Go になるのか？バイナリではあるが、最近なら問題にならないだろうし
ただJava案件をGoで書き換える、なんてのは聞いた事無いが

**デフォルトの名無しさん** · 2025/05/18(日) 00:19:36.18

GoogleがC++とJava使ってるっぽいからそれの代替用途でしょ
Cの代替ではない、あくまでも高級言語

**デフォルトの名無しさん** · 2025/05/18(日) 00:24:42.72

>>876
低レイヤーという意味でのBetter Cになるのは多分Zig (まだver.1未満だけど)
Goが使われるのはCLIやWebのバックエンドなので、CよりかはJavaやC#のレベルだと思う
GCがある以上、例えばLinuxカーネルのようなシステムプログラミングの領域を置き換えるのは正直無理

> Java＋ナマポ＝ Go になるのか？
Goらしさとして必要なのはポインタでなくGoroutineだと思う
並行処理を比較的簡単に書けるのがバックエンドの要件に合ってるから流行った感じなので

> ただJava案件をGoで書き換える、なんてのは聞いた事無いが
現在Javaでやってる案件はそのままJavaを使うんじゃない？
置き換えはそもそもリスクが大きいので (規模が大きいと特に)
仮に置き換えるとしても、同じJVMで動くKotlinという選択肢もあるし

**デフォルトの名無しさん** · 2025/05/18(日) 00:43:52.11

>>876
Goの開発当初Javaはなかったので、Google社内でもGC付きの言語を開発しはじめた。などという開発秘話を読んだことあるよ

**デフォルトの名無しさん** · 2025/05/18(日) 00:46:18.40

たまたまGC付きでCより高級で安全だからJavaと守備範囲が被るというだけで、置き換え用で開発していたわけじゃない。

**デフォルトの名無しさん** · 2025/05/18(日) 02:04:06.55

ネイティブスレッドを扱えずにグリーンスレッドモデルの時点でCの代替を想定してなさそうだけども

**デフォルトの名無しさん** · 2025/05/18(日) 11:14:11.80

>>877
GoでC++とJavaをリストラする、というのは技術的には面白いと思うが、
Android(Java)とchrome(C++)を抱えているgoogleには現実的に無理だな

>>879
それが本当なら、Java(1995)に対してGo(2009)は出てくるのが遅すぎる
> 後のインタビューで、3人の言語設計者すべてが、新しい言語を設計する主なモチベーションとしてC++が好きでないこと（英語版）を共有していたことを述べている (wiki)
なら、Javaと同時期に出せれば、C++嫌いな奴(＝その時期にJavaを選んだ連中の大半)には受けただろうに

**デフォルトの名無しさん** · 2025/05/18(日) 11:15:06.82

>>878
Zigは全く知らないのでチラ見してみたが、かなりC/C++を意識してるな
流行ってRustが滅んでくれれば俺は万々歳だが

> CよりかはJavaやC#のレベルだと思う
そりゃCよりはな
ただ、フレームワーク前提ではなかった『当初の』Javaは、確かにGoとレベルは被るのかもな
フレームワークが肥大していったJava、フレームワーク前提だったC#と並べれば C << Go <= Java <= C#

Goヨイショ気味の記事を見つけた
元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話
https://inside.dmm.com/articles/ex-java-engineer-thoughts-about-go/
> Optionalにはmapやfilter、orElseなどといった、Optionalのままで値を操作できるメソッド群が用意されており、これらを駆使することで、
> nullチェックをせずともnull-safeに処理を書くことができるようになっています。
出発点はおそらく「既存コードを変更無しでnull-safeにする」だったんだろうが、
多分このコンセプトが暴走気味で、余分な知識が必要で生産性を下げている、という例。これがC++/Java/Rustの方向
一方Cは、「null-safeが欲しいのなら毎回nullチェックしろ」であって、これはGoも同じ
言語としての基本的方向が違うから、RustはC++は殺せても、Cは殺せない
GoならCは殺せる可能性があるが、殺す気はないらしい
というより、多分Goは、そんなにCが嫌いではなく、C++が嫌いな人のための言語
(だからGo使いに対してはもっと低レイヤが欲しければC使えで平和に終わる
Rust使いにとってはCの思想は許容できないので喚き散らすことになる)

**デフォルトの名無しさん** · 2025/05/18(日) 11:15:45.42

Java案件は今後共Javaなのは俺も思う
C#のMSベンダロックを嫌ってるらしいが、Oracleロックはいいのか？とも思うが、
発注元が公務員、及び公務員じみた、「僕は悪くないもん！」が確保できればいい連中だけなので、今後共変わらない

だとすると、Goは基本的に置き換えなし、『新規』Web/バックエンド案件しかないが、これも一周気味だし、てなところか
と考えてたら、Rustがウザいのは『既存』案件の置き換えを迫ってくるから『押し売り/ゴリ押し感アリアリ』なところかとも
「間に合ってます」で終わるのに、
トイレでケツをしょっちゅう拭き忘れるガイジ/自分が何故数十年もケツを拭き忘れたことがないのかに思い至らないガイジ、しか居ないので話が通じない
この点、
> プロトタイピング専用言語 (843)
は悪く言われてる感があるが、良く言えば「プロトタイピング＝サラッと書いてサクッと動かすときに生産性が高い」のは利点でもある
(というよりRustはプロトタイピング時に生産性が皆無だから「新規」案件が出来ず、
結果的に「既存置き換え」の清書用言語としてガイジが勧めてくるが、「間に合ってる」連中にとっては糞ウザい)

**デフォルトの名無しさん** · 2025/05/18(日) 11:16:39.56

> 並行処理
wikiも見たがGo界隈では『平』行ではなく『並』行なのか？
まあ俺は一般の平行(coherency:違う処理を同時に行う)と並列(parallelism:同じ処理を同時に行う)を使うことにするが

> Goroutine
JSは、「同期/マルチスレッド」な他言語に対して、「非同期/シングルスレッド」という異端めいた選択が大当たりしたから蔓延ることになった
逆にGoがいまいち蔓延れないのは、Goの売りであるGoroutineがハズレたからだ

各プログラミング言語は、プログラマに何を「明示的に書くか」を要求する
JSは「I/Oを分離」することを要求し、報酬として「シングルスレッド化によりマルチスレッド時の諸問題が消滅する」ことを提示した
「お前のプログラムはすべてI/Oが律速しており、実はCPUなんて一つで足りる」とするJSに対して、
「そんなことはない！！！CPUが一つでは絶対に足りない！！！」と考えた他言語だが、結果はasyncの圧勝で終わった

Goroutineは、プログラマに「データフローの依存関係を明示的に書く」ことを要求する
つまり、平行/並列出来るものはすべてGoroutineとして分離し、大量のスレッドプールでこれを処理すれば、
処理性能は自動的に最大に貼り付き、スケールアウトも自在、というわけだ
このコンセプトはありだろう

**デフォルトの名無しさん** · 2025/05/18(日) 11:17:23.81

ただし現在は、これを処理するハードウェアがない。また、今後とも多分ない
超並列は現状CUDAの圧勝だし、こちらはそもそもハードウェアが起点なので、最初から専用ハードありきで言語も設計されてる
CUDAが出来ない超平行は、本来Goroutineが活躍する分野だが、
言語として本来要求すべきは「最小粒度でGoroutineに分離」で、
それを各処理系にマッチした粒度に『コンパイラが自動で』変更/割当すべきなのに、852内URL読む限りこれが出来てない
プログラマに粒度を調整させてるようでは、「資産」としてのソースコードは劣化する(全ハードウェアで同じソースコードを使えない)のだが、
GoはC側の「それが必要ならそう書け」であって、
C++/Java/Rust側の「コンパイラが自動的に行い、ソースコードからは隠蔽する」ではないのでこれが出来ない
(つまり、根本の思想として矛盾してる)

そして、仮に最小粒度でGoroutine書けたとしても、これを実行する最適なハードウェアは
「I/OはシンプルなFIFOとローカルキャッシュのみ(=グローバルメモリアクセスは出来ない、キャッシュのコヒーレンシは必要ない)、
最小命令セットのCPU」を「出来るだけ沢山」なのだが、
こんなハードウェアを作る予定があるところはない
(Intelはメニーコアをずっとやりたがってるが、フルスペックのx86なんてGoroutineでの超平行には必要ない)

冷静に考えれば、最小粒度の超平行＝ハードウェアであって、
Goroutineで攻め込むべきはVerilog/VHDLの分野なのだが、これをやろうともしてない
(というか、現状、ハードウェアエンジニアとソフトウェアエンジニアは明確に分離されており、やる必要自体がない
IntelがAlteraを買収し、今後はCPUにFPGAが載るのか？と思われたが、結局Xeonの一部に載っただけで頓挫した
まあその製品はネットワーク系ではすごく使えたらしいが)

だから、今後共Goroutineで頭抜けることはない、というより今の所「兆し」がどこにもない
結果、GoはGoroutineが本来提供すべきだった報酬、
「Goroutineに分離すれば自動的に性能は最大になり、スケールアウトも容易」が提示できてないから(圧倒的には)支持されない
一方、async(というコンセプト)でブチ抜いたJSは蔓延った、というだけ
(勿論GoroutineがGoの特徴ではあるが、他言語者がそれを使う理由がない)

**デフォルトの名無しさん** · 2025/05/18(日) 12:49:49.95

Javascriptでフロントエンドプログラム初心者が簡単に使えるから流行っただけ
async/awaitの発祥はC# (F#)だけどGoと同じくマルチスレッド非同期だわ、async awaitがシングルスレッドと勘違いしているようだが元々JSがその仕様だったのをそれにあわせて実装しただけ

JSはC#のasync/awaitをパクった劣化版に過ぎない、標準ライブラリはコールバックでawait使えなかったりキャンセル処理もサポートしてないゴミ

**デフォルトの名無しさん** · 2025/05/18(日) 13:06:33.55

シングルスレッドで十分w
じゃあなんでRedisに対してDragonflyやGarnetが出てきてるんだ？

**デフォルトの名無しさん** · 2025/05/18(日) 13:12:33.86

歴史的に見れば
・PythonやJavaScriptはもともと1スレッドで動く言語だった
・C#においてMスレッドN並列を扱いやすくする仕組みとして async/await ができた
・それが Python や JavaScript にも輸入された　

だからな
JSが勝ったのは、それがブラウザで動く事実上ただ一つの言語だからであって、別にシングルスレッドでの並行処理が良いなんてことはない

処理系がよしなにスレッドを切り替える (async/awaitのように切り替えポイントを明示しない) という点でGoに近いのは Erlang や Elixir あたりかな
理想的にはasyncの方が効率的になり得ると思うけど、これは呼び出し側も含めて async にする必要があるという感染的な性質を持つ
(https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ みたいに、これは「色付きの関数」みたいに言われる)

Goは「普通の関数をそのまま並行に動かせる」感じなので、その手軽さが好まれてると思う
CPUバウンドな計算には向かないけど、IO中心のタスクなら十分に良い性能にはなるので

**デフォルトの名無しさん** · 2025/05/18(日) 13:19:05.01

>>887
プログラミング初心者かよ
コールバックがあればPromise作って返せるからasync/awaitを使える
そういう基本的なことを知らずに批判しているのか？
仕組みを理解せずに表層的にasync/awaitを見てるからそうなる

**デフォルトの名無しさん** · 2025/05/18(日) 13:38:16.33

>>890
だからいちいちコールバック形式の関数をプロミス化するのが面倒だって言ってるんだろ
キャンセル処理すら最近になるまで対応してなかったゴミ、今もまともに扱えない
.NETだったら全部xxxAsyncとxxxの2つが用意されててAsyncには必ずキャンセル用のCancellationTokenを渡せる
Goはcontextを全て渡せる
JSはabortcontrollerはほぼ対応してない、あまりにも終わってるゴミクズ

Node.jsやらDenoとかいうのは最悪の発明だわ、JSをブラウザ以外の環境で流行らした愚行、そんなゴミ言語とか使いたくないんでね
なんでブラウザ以外でjsだのtsだのゴミ言語ランタイム使わないといけねーのw
作者は死んだ方がいいわ