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/

**デフォルトの名無しさん** · 2025/05/20(火) 11:16:09.13

遅いGoやC#などで作っても勝てないし
C/C++で非同期プログラミングは未だに様々な問題を抱えていて不利なので
速さも環境も整っているRust一択になっている状況

**デフォルトの名無しさん** · 2025/05/20(火) 17:31:30.72

クラウドフレアはFPGAを使うべきでは？
LuaスクリプトよりRustのほうが速いという主張も良くわかりませんでした
それは当たり前では？

**デフォルトの名無しさん** · 2025/05/20(火) 22:34:48.64

>>967
単純に、「重い」と認識できてない馬鹿と、分かってても変更しない意識高い系馬鹿の合わせ技でしょ

1995時点で「お前らのマルチスレッドはスイッチングが重すぎてまるで機能していない」と看破できたのはJSだけ
大半の言語はこれを認め、JSと同様に「手動」で軽量化も可能なよう、async文法を導入した
ただし実際、手間が増えてるのと、将来的にOSレベルでのスイッチングが軽くなった場合に、asyncで書かれたコードはゴミになる
だから「抽象度が高い状態で書きたいのだ！！！」「OSで『自動』的にやらせたほうがコード資産の価値は高いのだ！！！」という言い訳はできる
(問題は軽くなる予定が全く無いことだが)

この意味では、「asyncが必要なのではなく、OSがポンコツすぎるのだ！！！」と責任転嫁することも出来るはずだが、
誰もやらないところを見ると、OSは限界までは軽いんだろうな

そして逆に、アプリ側でasync必須でスケジューラも持ってれば、OS側で持ってるのは無駄なので削除して軽量化することは出来る
chromiumOSが奇妙に軽いのはこの辺かもな(＝JS専用OS)

**デフォルトの名無しさん** · 2025/05/20(火) 22:35:11.14

> プリエンプティブ
> 協調スケジューリング
改めて考えてみたが、「同期APIを使える」くらいしか利点を思いつかない
協調スケジューリングの場合は「非同期API強制」となるからね
JSは2013年頃でも「SLEEPは？」とか言われてたし、889のような馬鹿げたブログ(2015)を書くやつも居るしで、
非同期アレルギーはそうならなかったやつの想定以上に激しいのかもしれん
(俺に言わせれば、SLEEPは別の書き方があるからそれでいい、Promiseはゴミ、コールバック地獄になるのは腕前の問題、
この辺JSは全関数がクロージャなのだから適当に関数ぶった切って書き、コールグラフを整理すれば回避出来る、となるが)
そして出自がJSというのも当たりは悪い
フニャフニャ文法、階層が関数、専用構文とprivateのないオブジェクト指向、
ダックタイピング、動的に変化するthis、他型のメソッドも使える、で、
正統派オブジェクト指向のC++/Java/C#勢からすれば十分異端すぎるのに、更に、非同期、イベントドリブン、だからね
JSモデルが想定以上に速かったから、他言語開発者はJSを研究せざるを得ず、
何じゃあこれはーーー！！！となるのは分かる(＝JSアレルギーの発症
俺の場合は、え？こんなので大丈夫なのか？→あれ？意外と問題ねえな→実は他言語が無駄に冗長過ぎただけでは…、となったが)
まあブレンダン・アイクは本当に上手く攻略したな、とは思うよ

とはいえ、『同速なら』同期APIのコードの方がマシなのは事実だから、
同期API派はさっさと同速になる方向の努力をすべきだと思うがな

**デフォルトの名無しさん** · 2025/05/20(火) 22:36:05.33

>>976
> skipping TCP and TLS handshakes required on a new connection.
いやこれってありなんか？とは思ったが、GETならどうせ同じ(はず)だからいいのか？
となると、リバースプロキシって、誰かの操作を横から盗み見してる感じになるのか？

> 原文はRust最強みたいな変な誤解をされないように注意深く書かれている
信者が発狂するからといってオブラートに包みすぎ。原文は以下
> This is not because we run code faster.
まあCと比べればRustも遅いから、これはどうにもならんが

**デフォルトの名無しさん** · 2025/05/20(火) 22:43:28.20

Rustスレでやろうぜ

**デフォルトの名無しさん** · 2025/05/20(火) 22:44:31.07

GoクンのHPはもうカツカツよ🥺

**デフォルトの名無しさん** · 2025/05/20(火) 23:12:32.78

次スレ
Go language part 6
https://mevius.5ch.net/test/read.cgi/tech/1747750228/

**デフォルトの名無しさん** · 2025/05/20(火) 23:47:56.43

>>981
一般的なリバースプロキシじゃなくて、あくまでCDNだからね
基本的に全部パブリックリソースのGETだし、どのみちオリジンサーバーから見ればCDNからのリクエストだから一緒

**デフォルトの名無しさん** · 2025/05/21(水) 10:46:48.11

MITM

**デフォルトの名無しさん** · 2025/05/28(水) 04:53:46.40

つるつるわれめ

**デフォルトの名無しさん** · 2025/05/30(金) 13:31:36.30

梅八日

**デフォルトの名無しさん** · 2025/06/02(月) 21:47:55.19

適当なんだけどこれであってる？
肯定/訂正してくれたら嬉しい

1. ローカル変数(sliceはそのヘッド)はescape analysisでスタックやレジスタ割り当て
2. ヒープの頻繁確保解放は総量上限が分かるならプール
3. ロジック的に寿命が長いやつはそもそもGC影響は軽微

**デフォルトの名無しさん** · 2025/06/02(月) 21:51:04.00

配列/スライスの添え字アクセスは境界チェックされる

**デフォルトの名無しさん** · 2025/06/02(月) 21:52:50.52

dangling pointerは発生しない

**デフォルトの名無しさん** · 2025/06/05(木) 21:11:14.75

Go言語がエラー処理構文の導入を「一旦諦める」と宣言 — 7年にわたる検討の末コンセンサス得られず
https://techfeed.io/entries/6840c4096749026b87829bb9

**デフォルトの名無しさん** · 2025/06/05(木) 21:36:51.37

今のままでいいぞ。例外処理はワイには100年早い

**デフォルトの名無しさん** · 2025/06/05(木) 23:37:51.96

>>992
(他言語含めて)前から思ってるんだけど、コードは縦に書くもの(＝改行するもの)だと洗脳されてるよな
読みたくないコードはアナログに右に書けばだいたい解決する
今更「一行は80文字まで」等の化石コーディングルールを脳死で守ってるなら尚更

func printSum(a, b string) error {
x, err := strconv.Atoi(a); if err != nil {return err}
y, err := strconv.Atoi(b); if err != nil {return err}
fmt.Println("result:", x+y)
return nil
}

これでスッキリだろ
生理的に許せんならフォーマッタ使えで終わるし(逆も然りだが)

**デフォルトの名無しさん** · 2025/06/06(金) 00:36:59.99

printしてpanicしてエラースッキリ

**デフォルトの名無しさん** · 2025/06/06(金) 00:55:09.52

>>994
フォーマット以前にサンプルとはいえそんなクソコードを書くやつのほうが生理的に許せんわ

**デフォルトの名無しさん** · 2025/06/06(金) 00:56:27.07

go lint

**デフォルトの名無しさん** · 2025/06/06(金) 01:10:46.44

>>996
それは俺も思ったが、ここで言う意味もあるまい
(もし俺がサンプルを作ったと勘違いしてるのなら、リンク先確認しろ)

**デフォルトの名無しさん** · 2025/06/06(金) 10:14:03.88

IDEに見た目の折りたたみさせればよくね

**デフォルトの名無しさん** · 2025/06/08(日) 09:10:52.84

質問いいですか？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1197日 1時間 27分 33秒