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/

**デフォルトの名無しさん** · 2023/07/31(月) 00:39:34.75

agoutiのかわりのライブラリでないかなー

**デフォルトの名無しさん** · 2023/08/18(金) 16:42:15.53

かなり早い段階で翻訳が出たな
原著公式レポがあるから動かす手間を惜しまなければ何がダメなのか分かるけどね
https://github.com/teivah/100-go-mistakes/blob/master/09-concurrency-practice/68-string-formatting/main.go

“開発の失敗学”から生産性とコード品質を高める。『Go言語 100Tips ありがちなミスを把握し、実装を最適化する』
Goプログラミングの間違いを網羅的に解説した一冊
https://forest.watch.impress.co.jp/docs/bookwatch/news/1524131.html

https://www.アmazon.com/100-Mistakes-How-Avoid-Them/dp/1617299596
翻訳者ご本人柴田芳樹 5.0 out of 5 stars The equivalent of "Effective Java"
>However, please note that there are many minor errors in the book, so if you can read Japanese, I recommend the Japanese version that I have translated.

なおreadme翻訳募集中
README: Japanese translation 🇯🇵
https://github.com/teivah/100-go-mistakes/issues/30

**デフォルトの名無しさん** · 2023/09/03(日) 01:50:02.49

最近goはじめたけど、例外処理になれないわ

今まで安易にスローしてきたつけが出てる感じ

**デフォルトの名無しさん** · 2023/09/17(日) 01:24:19.14

身内に不幸があったので

**デフォルトの名無しさん** · 2023/09/28(木) 18:02:19.03

みんなgoに帰ってくる

**デフォルトの名無しさん** · 2023/09/28(木) 18:30:24.70

女性がイクときは3パターンある
1.come(欧米)
2.go(日本)
3.end(日本ではあまり知られていない)

**デフォルトの名無しさん** · 2023/11/27(月) 22:53:28.32

mattnさんのGo本半額だったのに買い忘れた…
昨日でセール終わってた

**デフォルトの名無しさん** · 2023/12/31(日) 23:28:43.30

もっと盛り上げてもらっていっすか？

**デフォルトの名無しさん** · 2024/01/10(水) 20:53:52.31

goいいよな
わかりやすい

でもpythonのあほみたいな量のライブラリ使った後は自分で作んなきゃいけないんかとなる

**デフォルトの名無しさん** · 2024/01/10(水) 21:15:00.66

マイクロサービス向けの言語だから
APIサーバーとか小さな特化したものを
サクッと作るのに適してる

それ以上のことやると死ぬだけ
まさしく適材適所

**デフォルトの名無しさん** · 2024/01/11(木) 20:28:02.09

コピペ地獄

**デフォルトの名無しさん** · 2024/01/15(月) 10:36:24.87

勉強がてらGoでwebサービスやってるけどLaravelで良いじゃんって気がしてしょうがないw
PHP Laravel再評価の時代来そう

**デフォルトの名無しさん** · 2024/01/15(月) 11:07:21.77

> PHP Laravel再評価の時代来そう

こない。

**デフォルトの名無しさん** · 2024/01/16(火) 00:18:43.14

プロの労働市場は、Ruby, AWS Solution Architect だけ。
Java は多重請負構造のIT 土方

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7

多くの言語 : 6.5～7

PHP : 5
Dart : 4.4

PHP, Dart は、コンピューターサイエンスを勉強していない高卒用言語

フレームワークは、
Ruby on Rails : 9 万ドル
Django : 6
Laravel : 3.8

YouTube で有名な雑食系エンジニア・KENTA が言ってる。
初心者のキャリアパスは、Rails → Go のみ

Ruby/Goの神・HashiCorp のMitchell Hashimoto がそう。
Ruby製のVagrant → Go製のTerraform。
今は、Goプログラマーしか求めていない

PHP, Scala はKENTAがオワコン認定したので、絶対にやってはいけない言語です！

**デフォルトの名無しさん** · 2024/01/17(水) 20:06:14.83

なるほど尊師様がおっしゃるのなら間違いないw

**デフォルトの名無しさん** · 2024/01/19(金) 05:11:59.56

地雷原を歩かせるスパルタ…！

**デフォルトの名無しさん** · 2024/01/28(日) 11:18:59.19

Goしか勝たん

**デフォルトの名無しさん** · 2024/02/07(水) 17:22:45.49

Googleがプログラミング言語「Rust」に100万米ドルを助成
「C++」との併存・置き換えを図る
https://forest.watch.impress.co.jp/docs/news/1566662.html

**デフォルトの名無しさん** · 2024/02/07(水) 17:32:10.04

スレ違い

**デフォルトの名無しさん** · 2024/02/13(火) 21:58:15.14

.22 のmuxのパラメタさぁ

**デフォルトの名無しさん** · 2024/02/14(水) 13:09:52.21

mux使ってないけど、なんかあったん？

**749** · 2024/02/14(水) 20:05:40.85

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5～7 -> 7.3～7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6

**デフォルトの名無しさん** · 2024/04/03(水) 16:01:02.02

>>753
GoogleはGoにしたいのか、Rustにしたいのか

**デフォルトの名無しさん** · 2024/04/03(水) 16:23:26.97

したいって現状用途が全然違うのに

**デフォルトの名無しさん** · 2024/04/03(水) 16:40:24.82

>>759
確かに現状用途が異なる。GoがWeb、Rustがシステム記述
しかし、本来はGoもRustと同じところを狙っていたのではないかと

**デフォルトの名無しさん** · 2024/04/03(水) 16:51:21.63

goとrustじゃあ全然言語機能違いすぎるよ
goは言語自体くそシンプルでだからバックエンドのマイクロサービスみたいな
小さなサービス自体を実装するのに使われてる(用途)
goでそれ以上のことをやると死にかけると思う

GoとRustはC#とJavaみたいなにたもんじゃないと思う

**デフォルトの名無しさん** · 2024/04/03(水) 17:00:55.33

逆にRustでバックエンドのWebサービス実装する
フレームワークあるけどコンパイル時間長すぎて
Webとか時間の流れ速い分野ではこれはこれで地獄だし

GoとRustは色々比較して別物だからな
用途も現状すみわけられてると思う

**デフォルトの名無しさん** · 2024/04/03(水) 17:16:01.43

本来についてはどうなんだろうね
Goはシステム記述を最初から狙ってたの?
システム記述がどこを指すのかにもよるけど

**デフォルトの名無しさん** · 2024/04/03(水) 17:37:49.09

でも実際GoogleはGoで書かれたものもRustに移行してる
生産性は同程度だけど不具合の数が圧倒的に少なくなったらしくかなり前向きっぽい

**デフォルトの名無しさん** · 2024/04/03(水) 19:14:38.98

RustはC/C++の代替言語なわけで結局メモリ管理のための記述が必要な低級言語なんだよ～
ガベージコレクションの無い低級言語なんか触りたくないぽよぉ～、Goしか勝たん！

**デフォルトの名無しさん** · 2024/04/03(水) 19:19:11.96

シンプルな言語機能でコードの保守性を高めることがGo言語の目的で、それはRustと真逆のような

**デフォルトの名無しさん** · 2024/04/03(水) 19:21:07.80

Rustが人気な理由は
完全にメモリ自動解放しかも必ず安全
を実現しつつC言語と同等の速さで動く点

**デフォルトの名無しさん** · 2024/04/04(木) 22:12:02.80

つかメモリ管理が～とか中級者まででしょ
普通の頭があれば25歳までに卒業してるわ

**デフォルトの名無しさん** · 2024/04/04(木) 23:05:06.38

javaがウケたのもcがウケたのも
シンプルだったからなんやろねえ
実際のプログラミングってのはどうしたってクソみたいな
状態の山、依存の山みたいなもんに取り組んでいくわけで
余計な複雑さを持ち込まないでほしいってのは現場のリアルな声だと思う

もちろんgoも、それをわかってて、それを押さえてる

**デフォルトの名無しさん** · 2024/04/04(木) 23:26:31.09

>>769
Cが受けたのは他が糞だったから。勿論Cの完成度は超高いにしても。
あとその当時はCPUが非力すぎて軽くないと話にならなかった。
Javaが受けたのはCで鬼門だったポインタを廃止してGCも導入し、馬鹿でもバグが出にくくなったから。
その後スクリプト言語が受けてるのは富豪プログラミングの方が断然楽だから。
ただ効率を考えたらポインタを直接扱える方が断然有利なので、Goは簡単な範囲でポインタを使える言語の位置づけだと思う。

**デフォルトの名無しさん** · 2024/04/04(木) 23:40:17.98

ただしJavaは敷居を下げすぎて業界にバカが多数流入した
ポインタを取り扱える/扱えないがハードルとして機能していた
Go関係ない話ですまん

**デフォルトの名無しさん** · 2024/04/05(金) 00:59:31.65

>>762
初老のおっさんのyoutubeで見たけど
actix-web使ったプロジェクトのビルドに10分位掛かってた。
もうちょっと頭使って環境作ればいいのに

ちなワシの環境なら10秒程度

**デフォルトの名無しさん** · 2024/04/27(土) 20:42:50.26

こんばんは

Goってネームバリューあるけどそんなに盛り上がってる感じじゃないよね
javaの後継になるかと思ってたけどそうでもないし

**デフォルトの名無しさん** · 2024/04/27(土) 21:13:07.86

言語仕様が簡素な点が特徴だけど
Javaのような大規模開発には向いてないかな
ガベージコレクションがあるからC/C++の分野も不向き
守備範囲が意外に狭い

**デフォルトの名無しさん** · 2024/04/27(土) 23:58:02.43

Goはもう衰退傾向に入った

**デフォルトの名無しさん** · 2024/04/28(日) 10:43:50.01

>>774
Javaが大規模開発に向いてるのは「文化」であって、「言語機能」ではないだろ
Goで技術的に出来ない事はない。ただしやる意味もないが
Goが糞なのは「全部書け」という言語ポリシーだが、これはJavaも同じだし

>>773
Javaの代わりにGo使うメリットってポインタが使える事くらいか？
ならJavaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、
> javaの後継になるか
これ自体が間違いだな

ただまあ、GC付きCの需要は以前からあったし、この分野ではそこそこ生き残り続けるのでは？

**デフォルトの名無しさん** · 2024/04/28(日) 10:57:35.16

javaの代わりにGo使うメリットってネイティブコード吐き出すことだと思うけど
処理速度が早くなればそれだけマシンのリソースが少なくて済む

**デフォルトの名無しさん** · 2024/04/28(日) 11:46:19.27

>>777
ああその点は完全に失念してた。
ただなんつーか、今時鯖代より人件費の方が高いので、Web鯖なんて物理で殴る方が安いというソリューションになってしまってる。
Javaも同様の状況だと思う。
Webに比べて製品寿命は長いので、状況異なるかもしれんが。

処理速度が絶対的に必要なのは物理で殴って逃げられないケースで、
これは例えばディスコードやFPS等のゲーム、つまりユーザー間でのデータのやりとりが大量にある状況で収容数を増やしたい場合で、
現在はRust/C++ということになっている。この分野でJavaを選択する奴は居ない。

Javaが使われてるのは大概インフラ、つまり銀行の送金システムや自治体の戸籍管理等だが、
負荷がかかって物理で殴って逃げられないのはDBであってJava記述部分ではないので、
最大でも精々2倍程度にしか速くならない現状で、Goに書き直す事はない。
それよりも書き直す際のバグを嫌うはず。

つまり、Rustが存在せず、鯖代が今の10倍くらい高ければ、JavaをGoに書き直す需要は発生してたはずだが、そうではなかった、ということ。

**デフォルトの名無しさん** · 2024/04/28(日) 13:33:28.92

3行で

**デフォルトの名無しさん** · 2024/04/28(日) 13:57:24.88

> Javaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、

アマチュアさんからはそう見えるんだね
職業マにとって言語なんて案件次第なんよ

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

>>779
速度面も機能面も、GoはJavaの後継ではない

>>780
ゆとり乙

顧客次第というのなら、現時点でのJava案件は今後ともJava案件だろうよ
顧客は公務員かお堅いところで、「もし何かあったら誰が責任を取る？」しか考えない連中だから
C++しかなかった時代ならともなく、現時点でJavaを「安全」とする技術的意味はないが、
顧客はそれを理解出来ず、また、責任逃れの為に誰も先陣を切らない
ただオラクルが妙な動きを見せ始めてるから、その辺どうなるかだが、それでも公務員連中は金払って終わりだろうよ
所詮は税金であって、自分の金ではないから
そういえば三菱銀行は10-15年前にC++で書きました、Haskell使いました、とかやってたが、続報は聞かないね

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

素人ならではの発想ほほえましい

**デフォルトの名無しさん** · 2024/04/28(日) 15:24:23.74

しょうもないマウント合戦

**デフォルトの名無しさん** · 2024/04/28(日) 15:26:16.67

>>782
ゆとり引きニート乙

>>773
一応捕捉しておくと、773がGoを「速いJava」と『個人的に』考えたのは間違いではない。
ただし『言語として』なら完全に間違いだ。

Javaはビルジョイが「Cでのバグの大半はポインタがらみで、ポインタ使用ケースの9割がStringだった。
だからStringを言語がサポートすればポインタをなくせると考えたんだ」とリーナスに語ったとおり、
ポインタを無くしてバグを減らす為の言語として作られてる。
そして実際、大受けして天下を取った。(なお「大半」と「9割」は逆だったかも)

ただ、速度チューンにはポインタでの効率化が必須で、この意味でGoは「速いJava」として『個人レベルでは』使える。
ただしJavaにはそもそもポインタがないのだから、
この発想、つまり「ポインタを使えば速くなる」とはJava使いは考えないし、実際、出来ない。
(個人レベルなら出来るのは混ざってるだろうが、Java流の開発方針だとチーム全員が出来ないと意味がなく、機能しない。
そしてポインタにまつわる問題をデタラメに吹聴してる震源はJava使いであって、具体的に言えば「メモリリークガー」だが、
C使いがメモリリークに悩まされる事はない。それはCの使い方を知らない馬鹿がデタラメやってて勝手にバグってるだけ。
この意味で ID:vlvoJs2w は正しい事を言ってる。なお俺は ID:Chhm4gg1)

**デフォルトの名無しさん** · 2024/04/28(日) 15:55:49.27

そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによってセキュリティホールが生み出し続けられている
結局C/C++を使用禁止にするしか解決策はない
アメリカでは政府レベルで決断して声明を出したので日本も後を追うだろう

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2024/04/28(日) 18:01:20.89

AIによるコンパイラによってC/C++は復活する、コンパイル時にメモリ安全がAIによって保障されるのだ
さらにAIコンパイラがはくエラー＆提案によって誰もがC/C++マスターとなる
つまりRustの人間にメモリ安全を強制する構文ルールは瞬く間に錆ついてしまうのさｗ

もちろんAIの恩恵はガベージコレクションにも及びGo、Pythonなどの実行速度も劇的に上がる
つまりRustはすぐに錆びついてしまうのさｗ　AIという母なる海によってね

**デフォルトの名無しさん** · 2024/04/28(日) 18:22:25.79

めちゃくちゃ頭の悪い妄想だな

**デフォルトの名無しさん** · 2024/04/28(日) 18:41:43.21

>>785
そう思う人がC/C++を使わなければ済むだけ。

> そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによって
なお、これはただのコンプレックスで、
ポインタの概念を理解すら出来ない馬鹿はお引き取り下さいではあるが、
ポインタを理解できたがリークするのは、やり方を知らないだけ。
(そしてここはGoスレであり原則後者だから、前者は死ねでいい)

ただ問題は、Javaの連中が「メモリリークガー」とデタラメに吹聴してるのに騙され、
文法にて縛ってしまうRustに逃げてしまってる事。まあ初心者は文法しか見えないから致し方ないが、
実は定番の手法があり、踏襲すれば絶対にリークしないだけ。
賢いからリークしないわけではなく、知ってるか知らないか、守るか守らないか、でしかない。
そしてRustは実際はC->C++->Rustと来ないと意味もメリットも理解出来ず、
「RustのおかげでCを入門する奴が増え、現在RustよりCの入門者の方が多いじゃねえか！」とか2019頃に言われてた気が。
RustはCを駆逐したいようだが、間抜けな話だ。

そして、Javaが「安全」とされていたのは、
・ポインタにまつわる問題が無い
・配列の境界チェックあり　(←これGoはどうだったっけ？忘れた)
・GCありなのでリークしない
・サンドボックス
だと思ったから、技術的に見れば確かにGoはJava＋ポインタ＝高速版Javaとしての側面はあるのだろうよ。
ただ、マーケティング的に(781)、また技術者リソース的に(784)、当面は無いが。

この意味では俺はRustの方が詰んでると思うよ。AIで出来るとは思って無いが、(>>786)
・動的な境界チェックをやってる限り、Cの速度に勝てない
・静的な境界チェックが出来るようになれば、C++にも導入されるだけ
で、出口が無い。
そして意味もなくマウントを取って来た780が言う様に、現在のJavaプログラマはポインタを扱えるのなら、
Java->Goへの大移動は起きるのかもしれんよ。この意味ではRustよりGoの方がワンチャンある。
(けどまあ、普段やってないことがいきなり出来るわけも無く、ゆとり引きニートの言い分なんてお察し、だが)

**デフォルトの名無しさん** · 2024/04/28(日) 20:18:11.49

童貞が女の口説き方教えてくれてるような長文

**デフォルトの名無しさん** · 2024/04/28(日) 21:47:54.49

例え方がキモすぎる

**デフォルトの名無しさん** · 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++使い