Go language part 3

レス数が950を超えています。1000を超えると書き込みができなくなります。
2019/10/17(木) 21:38:04.78ID:wMsZ+t6y
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

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

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/
872デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:28:43.57ID:XctsM+Su
>>870
たくさん書き込んでるけどもう良いだろ、Rubyスレに帰ろうな
2020/11/03(火) 22:33:32.93ID:OQJ1TfTq
>>856
Nodeがシングルスレッドなのは基本中の基本で、そんなのでこんな記事書いてること自体がびっくりだよ。
お前はそれすら知らずにNode使ってたのかよ！(Go界は人材不足だからこんなもんかもしれんが）
そこら辺がWeb系が馬鹿ばかり、と言われる点だと思うよ。これで仕事してることになっちゃってるし。
ただこいつのイベントループの部分の理解も間違ってると思うけど。
イベントループを抜ければスタックは空になる。スタックフレームガーなんて事にはならない。
そして「燃え上がるグラフ」になってるのはお前がそう組んだからで、完全に組み方が悪い。
(燃え上がってるのは「負荷」ではなくて自分が呼んだ「関数ネスト」だから）

ただまあ、組み方が悪かろうが何しようが、動くってのは重要なんだが。
だからこのケース（＝同じ奴＝同じ技術レベルの奴）が組んで動くようになったんだから、Goの方が向いているのは事実だ。
状況からすると、timeoutした場合はおそらく優先処理しないといけなくて、
それを放置して次のリクエストを積んだら余計な手間が発生するのだろう。
そうじゃないと「燃え上がるグラフ」にはならないから。

この点、NodeというかJSのイベントループには優先順位がないから、筆者の言うように「最後まで待たされる」事になる。
だから優先順位を付ける必要がある場合は自前でsetTimeoutをラップしてやる必要があるけど、逆に言えばそれだけだね。
それすら思いつかない人でもGoなら上手く行く、というのもまた重要な点ではあるけど、
781のブログと同様に噛みつかれ、「お前のコードが糞なだけ」と言われた場合、それは事実だと思うよ。
(なおこのケースはI/Oのようなので優先順位付加ではなく自前キューの方がいいが)
2020/11/03(火) 22:33:55.31ID:OQJ1TfTq
ただこれは「後付」であって、ここまで解明していればNodeでも対策は簡単に出来るわけだが、
実際はここまで解明するまでに時間がかかる。
AmazonS3がそういった類の、
つまり「timeoutのエラー処理を優先的に処理しないとその後の処理も遅れます？」みたいな特性を持っているとすると、
スペック上からは見えない落とし穴であり、Nodeなら嵌るがGoなら(知らなくても)嵌らない、というのはあり得る。
それはやっぱりNodeのシングルスレッドアーキテクチャの方が世間（他言語）からは特殊で、
Nodeだけ嵌り得る落とし穴も世の中には存在するということ。
こういうのに遭遇したくない場合、Goの方が安牌、というのはその通り。この点はNodeだけが特殊だから。
勿論この人が最初からGo使ってたら一番幸せだったろう、というのもその通り。
2020/11/03(火) 22:34:19.61ID:OQJ1TfTq
ただgoroutineって優先順位付けられたっけ？
何かこの人たまたま直ってるだけで、さらに負荷かけたらやっぱだめでした、になるだけの気がするが。
「燃え上がるグラフ」になってるのは「処理が遅い」のではなく「処理時のネストが深い」だからね。
AmazonS3のせいでもなくて、
いわゆる「コールバック地獄」的な組み方＝コールバックを深くネストして『最初の段階』で全部積み上げてしまうから、
後で止まれなくて実はtimeoutしてた時に余計な処理が多々発生してネストが深くなっているだけの気はする。
ただこの手の「不味い組み方」な奴はJSには多いのも事実。もっとフラットに組めよ、と言っても通じないし。
多分彼等にとってはJSの非同期ってのが至極相性が悪くて、
彼等的に非同期を解消する方法がコールバックネストしかないのだと思う。
その点、Goだと最初から同期で書けるので、そういった「糞コード」には(初心者でも)ならない。
この辺はC/C++/Rustだと「お前が糞なだけ」で片づけられるだろうけど、
俺自身は「初心者でも糞コードになりにくい」のは大変良い特性だとは思う。(というよりこの点はJSが糞なだけだが)

というわけで俺のその記事に対する感想は、
goroutineが優先順位付けられた場合：Nodeだけ嵌る落とし穴に命中してご愁傷様でした
goroutineが優先順位付けられなかった場合：初心者JS使いだけが何故か嵌る糞コードになっててご愁傷様でした
だな。多分後者で、初心者でも糞コードになりにくいGoだから救われた、だけの気がする。
(Goが良いというよりはJSの非同期ってのが糞コードの産地になってて、筆者もそうだっただけだが)
2020/11/03(火) 22:46:43.82ID:OQJ1TfTq
>>866
ついでだから本家の方読んできた。
まずそもそもReadStatesをそんなにバカスカ更新するようなアーキが必要なのか？という疑問はあるが、
それはさておき。

これは、多数のオブジェクトを「生存したまま」でメモリを埋める、
つまりオンメモリDBのような使い方をするアプリとGCが絶望的に相性が悪くて、それに該当した、ということなのだろう。
これはGoがショボイというよりはGCの限界で、C++/Rustしかねえわな、ということだと思うよ。
JavaでもC#でも同じ結果になる気はする。
だからそういうアプリでGC言語使っちゃ駄目、というのが教訓だと思うよ。
2020/11/03(火) 23:20:17.15ID:UEeX42rQ
マジで怖いんだけどこの人
何かやらかさないか心配
2020/11/03(火) 23:44:46.53ID:cdE7yZQv
お前ほんとに学習しないのな。
2020/11/03(火) 23:52:01.26ID:pWieQE6j
Ruby のコンパイルに、1CPU なら、20分掛かるけど、
4CPUなら、5分で済む

CPUセントリックな処理では、CPU並列処理は意味がある
880デフォルトの名無しさん
垢版 |
2020/11/04(水) 00:08:44.43ID:BNFfXKWA
>>862
cspは概念・モデリングっつう理解でだいたいいいと思うよ。
昔から並行処理システム関わった奴ならたいていは似たようなモデルは考えてる。
cspはそれを厳密に数学的に記述するって感じ。
極端なこと言えばメッセージでやり取りしましょう、だ。

っで、goはプログラミング言語としてgoroutineとchannelがあるから他の言語より並行処理向き。
go以外なら古くはadaやなんかもそう。タスクにランデブポートっつうのがある。
erlangも似たようなメッセージ機構はあるんじゃなかろうか。

本質的に並行処理ってのは非同期的な処理システムなわけだけど、
非同期ioとコールバック(やシンタックスシュガー)でやるより、独自に動く実行体が複数あってそれらがメッセージ通して協調動作するってシステムの方が好きだ。
881デフォルトの名無しさん
垢版 |
2020/11/04(水) 00:15:06.09ID:BNFfXKWA
>>876
まぁーやっぱ、gcってよくねーわ。
捨てる前提のプロトタイプにはgcあり言語もよいと思う、ほんで大部分の案件はそれで十分ってのもあっる。
げももっと性能を、、、てやると今なら c/c++/rust の3つしかナイショ。
2020/11/04(水) 00:48:58.46ID:thexrnOY
>>880
それアクターモデルだろよ、と思ってwiki確認したら、CSPがモロに書いてあったわ。
ただ、アクターは浮かんでは消え、という印象があるが。
smalltalk信者等、通信したい奴は確かにいるようだが、それがイマイチ何になるのか明確でない。

あと、コード上で通信したいのならGoだが、アクターモデル自体は普通にオブジェクト指向で組めるし、
C++なら（あまりよろしくはないが） >> と << をオーバーロードしてそれっぽく見せることは可能だ。
実際その方がgoroutineより何倍も速く動く。

Erlangは俺も以下を半分くらい読んだ程度しか知らないが、
https://www.ymotongpoo.com/works/lyse-ja/index.html
あれは実用本位で、理論側から出てきたものでは全然無い。
電話交換機筐体を複数並べてスケールアウトした時にも性能が低下しないように作られてる。
だから最初から共有RAMなんて禁止されてる。そして当然メッセージ交換だが、
最初から上記のような疎結合でのメッセージ交換を想定されてるから、
Goみたいな密結合を想定されているものとはちょっと違うが。
2020/11/04(水) 00:55:48.53ID:thexrnOY
>>881
ちなみに本家の方はコメントも付いてて、GoUserが吠えてる（事になってる。
ただあの程度で噛みつきと捕らえられるのも厳しい気はするが)

Rust試す前にGoのバージョン上げろよ、というのもそうだが、
キャッシュサーバー使えよ、というのは確かにな、とは思った。
2020/11/04(水) 04:35:34.49ID:o5YVwgYf
言葉の端々に今どきの若者は〜みたいなのを感じる
周りから相当クソ扱いされて5chで鬱憤晴らしてるんだろうな
2020/11/04(水) 06:03:20.20ID:bB+A/rRK
それか単なるヒキニート
2020/11/04(水) 07:42:42.00ID:a9nrTc1S
>>881
実際問題、ここ数年のGC言語で足を引っ張られた事はあんまりないけど。
そういう意味では参照カウンタ方式のPythonなんかは割と効率良いんじゃない？それこそスクリプト言語だけど。
言語としてのスループットを上げたければ、allocはまとめて、freeはもっともっとまとめてやって、必要そうだったらメモリのcompactionかけるほうがスループット上がると思うが。

>>882
Goのどこが密結合？
チャンネルは？
2020/11/04(水) 08:59:07.22ID:thexrnOY
>>886
参照カウンタのGCとマーク&スイープのGCは意味合いが全然違う。
それを一緒くたにしてるようでは駄目だよ。

そこら辺がGoスゲーって言ってる奴のレベルが低いところだよ。
それ以外も君は間違いすぎていちいち指摘するのは諦めたけど、
多分もうちょっと勉強した方がいい。

Goは酷い言語でもないけど、凄い言語でもない。
860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。
888デフォルトの名無しさん
垢版 |
2020/11/04(水) 10:32:02.91ID:BNFfXKWA
>>882
c++はc++11以降ほんとよくなった。
でももう新規案件ならrustに譲ってもいいかなと思う。
889デフォルトの名無しさん
垢版 |
2020/11/04(水) 10:57:28.03ID:BNFfXKWA
>>887
広義では参照カウンタもgcじゃん。
gcも色々改良されてるし未だに古典的なマークスイープgcのみってのはあまり無いんじゃろか。
だから案件の多いweb系とかアプリとかの上のレイヤーでgcが問題になるケースはあまり無い。

gcはそれより下のエンジンとかのシステムレイヤーで問題視されることが多い。
で、一応goはc/c++/rust同様のシステム言語のくくりで語られることもあるからその辺から叩かれたりするけど、そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
2020/11/04(水) 11:27:49.81ID:8aX5ek4k
哀しき中間管理職みたいな言語なんだね
2020/11/04(水) 11:50:37.38ID:8aX5ek4k
>>887
> 860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。

>>860 の本家ってこれかな？
Why Discord is switching from Go to Rust（Discord Blog）
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
コメント58件あるけどGo信者の圧が凄い…
2020/11/04(水) 11:56:43.57ID:q9h9Yk1J
>>887
参照カウントに対して、俺がどういう意図で話してるかわかってる？
一緒くたにしてるわけではなくて、参照カウントのメリットってのもきちんとあるんだよ。

勘違いが多すぎるのはお前の方だと思うよ。
グリーンスレッド知らなかったんだっけ？
グリーンスレッドの切り替えにはコストがかかるんだっけ？
全部スレッドの話だよな。

いちいち都合の悪いところをネグってレスつけるのやめろよ。
2020/11/04(水) 11:58:46.84ID:5Emk5REP
Go vs Rust、じゃなくてむしろこの2つ以外が要らんのだけど
取り敢えずGoが分からないグリーンスレッド君がRustを理解出来るとは思えない（笑）
2020/11/04(水) 12:03:20.78ID:q9h9Yk1J
参照カウント方式には結構なメリットがある。
別スレッドも必要ないし、速度も出る。ストップザ・ワールドも必要ない。
オブジェクトの開放が「かならず」「一定の場所」で行われてデストラクタの動作タイミングを保証できる。
弱参照がきっちりしてればそれこそ循環参照もそれほど恐れることはない。

組み合わせて使うのが良いと思うよ。俺的には。
だからこそ引き合いに出したんだが。
C++好きならshared_ptrあたりから理解が及びそうなもんなんだが。
2020/11/04(水) 12:04:06.32ID:q9h9Yk1J
>>887
で、指摘してみろよ。
お前が間違ってることは懇切丁寧に指摘してるんだから。
2020/11/04(水) 12:22:41.50ID:Q20JRtoy
循環参照検出付きの参照カウント方式は、GC?
2020/11/04(水) 15:06:50.39ID:q9h9Yk1J
>>896
自動的にメモリを開放してくれて、フラグメントを解消してくれる仕組みは、大雑把に言ってガベージコレクションの仲間に入れるもんじゃない？
2020/11/04(水) 16:33:07.68ID:bB+A/rRK
誰かこの人形劇を止めてくれよ
2020/11/04(水) 18:33:48.20ID:q9h9Yk1J
とりあえずGoのリリースノートを全部読んでから話してほしいな。彼には。
1.14あたりでgoroutineのスケジューラちょっと変わってるし。
2020/11/04(水) 22:39:50.46ID:thexrnOY
>>889
> 広義では参照カウンタもgcじゃん。
そう。俺も「参照カウンタのGC」とも言っている。
馬鹿は放置として、君も疑問のようだから回答しておくと、
参照カウンタ方式は「ユーザーが間違ってない」前提が必要で、「ユーザー補助」でしかない。
対してマーク＆スイープは「ユーザーが間違ってても」GCが為されるから、「システム保護」なんだよ。
だから役割が全然違う。少なくとも真面目に24時間365日動作させるつもりなら、単純に交換は出来ない。

これが結局何だかんだでマーク＆スイープから離れられない理由で、
JavaもC#もJSも、勿論Goもマーク＆スイープしてる。
勿論それが重いのはみんな分かってるから、色々工夫してるけど、最終的にはやるしかないから。

だから参照カウンタ方式のGCでマーク＆スイープと同様に「システム保護」を得る為には、
「ユーザーがどんな書き方をしても」解放されることが必要で、
例えば>>896のようなのが有ればいいけど、これで実装してる例ってあったっけ？
（なお循環参照の検出自体は簡単だが、適切に起動する為のイベントがないから、実装時に困るのはそこだと思うが）


> そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
そこは今どっかりとC#が根を下ろそうとしている。
C#は俺は良い言語だと思うけど、Javaに食われて死にそうなのがなあ、という見方だったが、
少なくとも俺の予想以上には大健闘していて、生き残るかもしれないなあ、とは思いつつある。
これまではC#もC++もWeb系が手薄だったけど、どっちもガチで整備し始めてるから、それが完了した時にどうなるかだね。
そしたら本当にGoを使う意味が全くなくなる。

逆にRustはCPU負荷無しで「システム保護」出来るわけだから、GC言語を皆殺しにかかってる。
そしてC並に速いのだから、確かに最終兵器ではあるんだよ。盛り上がる理由はそれ。
2020/11/04(水) 23:37:57.93ID:7oWZmWjZ
>>900
長文連投しても知識が薄っぺらい
https://github.com/JetBrains/kotlin-native/blob/master/FAQ.md#q-what-is-kotlinnative-memory-management-model
2020/11/05(木) 00:53:39.27ID:iOSFoZGZ
>>900
ユーザーが参照カウントを上げ下げすることなんてほぼないぞ
言語内の仕組みなんだから
C拡張とか書く場合もたいていスコープ抜けたら
それまでの一時変数は全解放するって書き方があるし
他のGCでもそれは同じ
だからほとんど中身の仕組みを意識しなくても良い
むしろそれができないなら実装がしょぼい
2020/11/05(木) 01:09:47.48ID:dYXzTkiF
Goが人気出た大きな理由の一つは、過不足がなく比較的高品質な標準ライブラリ
その点でいえばNodeも同じだが、Nodeと違って変なのを噛まさず標準ライブラリを素のまま普通に使うことを美徳とする文化があるのも効いてる
くだらない流行り廃りに惑わされずに決まったものをただ普通に使えばよいというのが近年の複雑化しすぎたWeb界には受けた
Rustはそのへんは全然ダメだね
2020/11/05(木) 01:17:10.50ID:x7P4NeVz
またそんな煽りを…
まったくオマイラときたら変な輩を呼び寄せる呪文を唱える
才能に関しては天才的だな
2020/11/05(木) 07:04:56.97ID:40Zkap5B
>>900
それで実装してる例がPython
2020/11/05(木) 07:24:03.07ID:td0oky8W
RustはRustでC++の標準ライブラリがゴテゴテと九龍城が如く聳え立ってきた反動でもあるので許してやれという気持ちがある
それにしたって初期の標準が貧弱で標準に取り込むまでの右往左往が長すぎるというのも分かるが
2020/11/05(木) 09:00:41.20ID:/CgVmiK8
>>906
Rustは去年ようやく並列処理APIが固まったレベルだから、将来性はともかく現時点ではまだヨチヨチ歩きな幼児と見てる
十年後に期待
2020/11/05(木) 09:25:14.26ID:gkJnxR7E
Rustは今でも面白いよ。標準ライブラリが貧弱でも大して困らんけ、並列ランタイムだけは標準に入れて欲しかった。
メジャーなtokioとasync-stdの両対応してる場合も有るけど、大抵枝分かれしてて共存も出来ないから無駄なんだよな。
2020/11/05(木) 10:34:46.60ID:/CgVmiK8
>>908
Javaで言えば1.0レベルだろ
当時から面白かったんで使ってたけど、実用性は微妙だった。特にファイルIOとコレクション
910デフォルトの名無しさん
垢版 |
2020/11/05(木) 10:59:39.83ID:OMGYJi8L
参照カウントって、本当に「言語の仕組み」なの？
2020/11/05(木) 11:05:21.21ID:x7P4NeVz
こっち↓で聞いてみたら

GCは失敗。メモリは自分で管理せよ！ その2
http://mevius.5ch.net/test/read.cgi/tech/1447856699/
2020/11/05(木) 11:08:21.64ID:+m168BhN
C#が充実したらGoが要らなくなる論は全然わからんな。
一体どういう理屈なんだろうか。
同じサーバサイドでもお互いに分担するエリア全然違うくないか？
というか、全然手薄でもなかったし。C#。
2020/11/05(木) 11:27:44.88ID:pymKzIg5
ファットなランタイムに依存しながらも比較的デプロイ時の取り回しが良い
わりと固定されたツールセットで無難に迷わずに使える
まあ近いと言えば近いんじゃないかな
C#をバリバリ使ってるとこだとGoの出番はないだろうし
2020/11/05(木) 11:59:24.87ID:/CgVmiK8
C#ならGUIもサービスも書けるし遅くもないから、Windowsアプリを書くなら鉄板の選択肢だよな
どうしても高速化したいとか解析されたくない時だけC++
ただ事前にランタイムのインストールが必要なんで、Linuxとかマルチプラットフォーム展開の敷居がちょっとあるんで、CLIツールとか書いてもGoに比べてデプロイが不便
充分に住み分けされてるからどっちを使う論争は不毛
2020/11/05(木) 12:39:02.69ID:+m168BhN
Windowsアプリを作るときの鉄板に関しては異論はないが、C#のデプロイはガッカリ仕様だぞ。
.Net 5でも。
2020/11/05(木) 13:08:26.70ID:LX/aXWmP
SCDも知らんのか
2020/11/05(木) 13:22:01.75ID:+m168BhN
>>916
SCDでデプロイしたことあるか？
むちゃくちゃファイル数多いぞ。
SingleBinaryが自己展開ではなく直接アセンブリをロードする形にやっと.Net5でなったけど、そのままだとSingleBinaryと言ってるくせに数ファイル漏れるので、
それも完全にSingleBinaryにするには結局自己展開ファイルにせざるを得ない。

ファイルサイズも結構でかくて、最近は使ってるメソッドのみと言う形でTrimできるようになったけど、誤爆もまだまだあって実用とは言えんし。

ホントにやってみ。期待してただけにすごくガッカリしたから。
918デフォルトの名無しさん
垢版 |
2020/11/05(木) 14:44:49.50ID:BWbga0la
>>908
Rustは非同期まわりが不安だよな。
919デフォルトの名無しさん
垢版 |
2020/11/05(木) 17:50:15.36ID:goPbZhqC
>>914
F#とかどうよ
https://qiita.com/cannorin/items/59d79cc9a3b64c761cd4#%E9%96%8B%E7%99%BA%E5%AE%9F%E8%A1%8C%E7%92%B0%E5%A2%83-net-core--vscode

高速な動作, 簡単な配布
・.NET Core は現状で最も高速な .NET 実装の1つで, ベンチマーク上では例えば Go とほぼ同等〜少し速い程度のパフォーマンスを発揮します.
・.NET Core は Go と似たようなスタンドアロンバイナリの生成をサポートしており23, .NET Core ランタイムがインストールされていない Windows / OS X / Linux 環境上で実行可能な状態で配布することができます.
2020/11/05(木) 17:54:16.33ID:/CgVmiK8
>>918
まあ、不安ったって迷走してる程度で、根本的にはCの代替として落ち着いていくでしょ
確かどっか大手がコンテナの記述用途でテコ入れするとか

対立煽りしたいらしい奴は、方向性がまるで違うんだからC++のスレにでも行けって感じ
2020/11/05(木) 20:03:23.12ID:LX/aXWmP
>>917
あるに決まってるだろ
2020/11/05(木) 20:13:34.79ID:40Zkap5B
>>921
ならわかるだろ。
あれがガッカリ仕様でなければ何なんだ。
2020/11/05(木) 20:34:00.27ID:LX/aXWmP
>>922
うん、めっちゃ楽
2020/11/05(木) 21:13:05.05ID:rDKR4t8H
>>901
>>905
俺が無知なのはさておき、GCを実装してる連中はそこら辺まで調査して選択してる。
Go含めて重鎮が地味にマーク＆スイープを選択するのは、それなりに理由がある。
ただし、マーク＆スイープは、「大量の生存オブジェクト」には不向きで、Discordの件はそれに該当する。
逆に言えばそれが不向きなだけで、「最小限の生存オブジェクトと大量のゴミ」という、
普通の使い方の場合には、マーク＆スイープの方がいいと判断したからそっちを選択してるわけだ。

kotolin-nativeは多分新しいことを試してみたかったんだろうと思うが、
Pythonはおそらく判断をミスっていて、通常向けに最適化するべきだと思う。
(これがPythonが無駄に遅い理由の一つになっているかも）
ただしGC機構についてだけ言えば、Python型なら今回のDiscordみたいなことにはならなかったはずだ。
だからあれはより正確に言えば「『マーク＆スイープ方式の』GCの限界」だな。
2020/11/05(木) 21:25:07.21ID:rDKR4t8H
>>903
最後の部分
> 近年の複雑化しすぎたWeb界には受けた
以外には同意だ。
俺は「Web系は複雑化しないところがいい」と見ている。
Web系は馬鹿ばかり、と揶揄されつつも、それでもWebが回ってるのは馬鹿でも回せる構造になってるからだ。
それは水平分業がしっかりしていて、しかもそれを普通に選択する文化だと思う。
例えばPHP、3層構造にするのについて誰も文句言わないだろ。
対して今回のDiscord、あれは指摘されてるとおり、キャッシュサーバーを使っていれば発生しなかった問題だと思う。
そこをなまじ実装力があって自前で実装してしまうからこそ命中する。
実際キャッシュなんて100行程度で書けるから、
不必要な機能も付いてて遅く、さらにブラックボックス的な他ライブラリ等に頼るよりは、
自前で実装する方が気分が楽なんだよ。
(ソースが読めるとしても100行程度で書けるのだから書いた方がまし、という選択になる）

その辺Web系は実装力もないからさっさと外部ライブラリ/フレームワークに頼るのだけど、
結果的にはそれの方が正しいように俺には見えてる。
この文化だと「○○が欲しい」というリクエストも感謝も明確に出てくるのでライブラリも揃う。
C++だと「そんなゴミ要らん自分で書いた方がましじゃボケ」になるからね。
だから遅々として整備は進まないが、それでも徐々には進むから、最終的にはどうなるかだけどね。

Web系が複雑化しているように見えるのは、やたらフレームワーク/ライブラリが乱立するからだと思うが、
それは外部的に見えるから複雑化しているように感じるだけ。
C++等だと内部的にみんなやってるのが出てきてないだけで、確実に重複しまくってて再開発しまくってる。
だから乱立に見えるけども一応外部に出てきて重複開発しないWeb系の方がエコシステムとしては効率がいいと思うよ。
2020/11/05(木) 21:34:05.29ID:rDKR4t8H
ちなみにデプロイって何の話してるんだ？
サーバーサイドなら最低限ビルド出来る奴がセットアップするんだから問題なし。
WindowsへのC#のデプロイは何ら問題ない。
Linuxなんてど素人は使ってない。
残るはMacだけど、お前らMac向けにGoでツールとか書いてるの？


ちなみに俺が言ったのは、「楽に書けて、サクッと動いて、そこそこの性能」という事だよ。
君らの分析の方が技術的に真面目で、さらに当たってるからそれで問題はないけど、要は、

PHPだと超超超楽勝だがポンコツ、
(Pythonだと超楽勝だがPHPと同程度の速度しか出ないポンコツ、ただしPHPからは逃れられる)、
Nodeだと楽勝でそこそこ速い、
Go/C#だと楽勝でもないがまあ普通に速い、
それより速いのはC++/Rustだけどこいつらは非現実的、

と今は並ぶでしょ。速度/容易さで並ぶのはC#。
C#の方が断然巨人だから、色々環境は整ってる。
ただしWebではなくWindowsアプリを主眼にしていたから、Web周りは若干周回遅れになってる。
勿論ASP.NETは昔からあったけどね。
サーバサイドでなくとも、要は「中庸」のプログラミング言語が欲しい場合に何が来るかということ。
一応C#は過度に難しくならないように努力してるから、巨大化している割には肥大化してない。
その辺C++とかかなり最悪だし。

ただしそれは「最速」言語の宿命で、
こちらの方が少しでも速いケースがある、という場合にユーザーが最速記述出来ないのは問題だから、
どうしても仕様が肥大化してしまう。速度面で仕様に妥協が出来ないんだ。
だからほぼ確実にRustもこれから肥大化する。

ただGoではC#を馬鹿にするなんて出来ないよ。
お前らの眼中にないASP.NETの方がGoサーバーよりも100倍シェアがある。
https://w3techs.com/technologies/overview/programming_language
2020/11/05(木) 21:45:04.52ID:rDKR4t8H
すまん100倍では済まずに 31,666倍(=9.5/0.0003)だった。
言語名を押せば各詳細が出る。

その他の面もC#は既に巨人だからC#からみればGoなんてゴミ同然で、相手されてないよ。
2020/11/05(木) 22:10:29.26ID:40Zkap5B
>>923
楽かぁ。
Goのシングルバイナリに慣れてると、結構なガッカリ感だったが、主観的な物言いしてはいかんのかもしれんな、すまん。
2020/11/05(木) 22:12:14.15ID:40Zkap5B
>>924
さておくなよ。
どう判断をミスってんの？言語設計の問題でしょ。
Swiftは？
2020/11/05(木) 22:16:08.14ID:40Zkap5B
>>926
「サーバサイドはできる奴がセットアップするから問題なし、PHPのデプロイが簡単」とか言ってる時点で話についてこれてないから、ちょっと調べてからしっかり喋ってくれ。
少なくともPHPファイルをポン置きするような事は「デプロイ」とすら呼ばん。
C#が眼中に無いのではなくて、ここはGoのスレ。
931デフォルトの名無しさん
垢版 |
2020/11/05(木) 22:41:27.37ID:BWbga0la
>>919
F#いいよな。
でも ocaml も流行ってないしなぁ。
ocaml は歴史もあるし金融系で使われてたり実績も十分そうなんだけど。
2020/11/05(木) 23:35:22.45ID:5bWXoO+B
COBOLは歴史もあるし金融系で使われてたり実績も十分。
2020/11/05(木) 23:47:46.08ID:/6Zmm2qe
C#はビルド速度とNuGetが地味につらい

Goのビルド速度、シンプルな純正テスト環境は大きな利点に思う。小規模開発時には特に。
2020/11/06(金) 00:13:18.80ID:5acjwhy7
YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる

この2つ以外は、出てこない

GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった
935デフォルトの名無しさん
垢版 |
2020/11/06(金) 11:27:45.34ID:kU46w3PV
そういや Go ってジェネリック入ったの？
2020/11/06(金) 13:43:45.59ID:4QwN1dUc
なんのために？
2020/11/06(金) 16:04:25.31ID:vuRZSDYg
だれのために？
2020/11/06(金) 16:41:08.49ID:VIMw9dW+
「俺の考えた最強の型システム」合戦になって収集つかなくなって導入しないことが決定した
2020/11/06(金) 17:16:52.08ID:t5Qz3yQt
医薬品
2020/11/06(金) 17:40:20.04ID:RRtA6cm3
これがキャンセルされたってこと？
https://blog.golang.org/generics-next-step
2020/11/06(金) 20:14:23.58ID:DtEkLbzN
sort書くときはジェネリクスと型推論効かせて簡潔に書きたくなる
2020/11/07(土) 11:07:18.19ID:fULQIOig
なにかというと interface{} が現れる今の状況をなんとかしてほしい。
943デフォルトの名無しさん
垢版 |
2020/11/07(土) 18:27:21.32ID:WaP+6xrD
どこかのブログで「Goはイテレータを書くのに4つの全く異なる方法がある」って書いてあったけど、これマジ？
2020/11/07(土) 19:50:01.55ID:alCltY04
変数宣言くらいひとつにして欲しかった
2020/11/07(土) 21:53:29.96ID:sL9l9w2Z
>>943
イテレータを書く
と言ってる意味がよく分からない
イテレーションはrange句を書くときだけを意味するが、配列もしくはスライス、文字列、マップ、チャネルでそれぞれ受けとるイテレーション変数に違いがあるんで、それで４種と言ってる？
2020/11/07(土) 22:24:39.29ID:alCltY04
どこかのブログってこれか？
https://qiita.com/yamasaki-masahide/items/c228fca4ab788b042777
ソースくらい貼れよな…
2020/11/07(土) 22:35:37.85ID:sL9l9w2Z
>>946
チャネルにキャパシティ設定してないとか
goの諸々が分かってる？という記事だと思う
948デフォルトの名無しさん
垢版 |
2020/11/07(土) 23:59:31.34ID:WaP+6xrD
ごめん　前に見たブログが全然見つからない……
けど同じように言及してるブログは見つけた。
3 ways to iterate in Go
https://blog.kowalczyk.info/article/1Bkr/3-ways-to-iterate-in-go.html
2020/11/08(日) 00:40:26.10ID:cr0qwrbo
>>948
1.無名関数をループする関数
2.Nextとかのインターフェースを持ったオブジェクト
3.並列処理でループさせて通信で受ける

これをイテレータねえ？
950デフォルトの名無しさん
垢版 |
2020/11/08(日) 22:36:26.97ID:aJEtBYMB
>>948
for文だけでカプセル化できてるように思うけど

for i := 0; i < 11; i += 2 {
println(i)
}
println(i) // undefined: i
2020/11/11(水) 16:24:39.37ID:2YRRcyS5
Typing [Generic] Go
https://www.dropbox.com/s/ch403rkrspomw0v/AG%20-%20R%20Griesemer%20-%20Typing%20%5BGeneric%5D%20Go.pdf
952デフォルトの名無しさん
垢版 |
2020/11/12(木) 15:55:37.84ID:x/dKav4D
>>948
こんなことやってる奴って他にいる？
2020/11/12(木) 16:06:34.24ID:ajQurm37
いや、Goに関わらずAPIの設計としては常識に近いよ
Iteratorデザインパターン
954デフォルトの名無しさん
垢版 |
2020/11/13(金) 09:51:20.25ID:PXZYfUWY
Goではfor文がイテレータ

自分でイテレータみたいなものを実装する必要はない
2020/11/13(金) 12:01:55.68ID:1iElEYNS
イテレータ知らんやつばっかりで草生える
956デフォルトの名無しさん
垢版 |
2020/11/13(金) 14:22:31.00ID:PXZYfUWY
>>955
じゃあイテレータの定義説明して、どうぞ
957デフォルトの名無しさん
垢版 |
2020/11/13(金) 14:38:40.75ID:/AMzz1sP
イテレータは、既定の順序に従って移動できることと、値を逆参照できることが要件になるだろうな。
2020/11/13(金) 15:13:39.60ID:9KKZC7Fr
意味不明。
はい次！
959デフォルトの名無しさん
垢版 |
2020/11/13(金) 15:22:45.15ID:RWm0omqa
覚えたての言葉使って見たかった説に+1
2020/11/13(金) 22:40:33.20ID:5mXtPG+h
連続した要素を一個ずつ舐めて処理することだよね？(´・ω・｀)
2020/11/13(金) 22:47:58.01ID:PGsPGVPV
それはただの繰り返し、
for文の説明にしかなってない。
もう一段の抽象思考が必要。
2020/11/13(金) 22:51:34.63ID:IGEbWGrX
>>960
キンタマかよ
2020/11/13(金) 22:59:31.91ID:YBOwt/E7
>>960
wikipediaの解説くらい読めよ……

イテレータ（英語: iterator）とは、プログラミング言語において配列やそれに類似する集合的データ構造（コレクションあるいはコンテナ）の各要素に対する繰り返し処理の抽象化である。

「連続した要素」である必要は無いし、「一個ずつ舐め」る必要も「処理する」必要も無いぞ。
2020/11/13(金) 23:02:04.54ID:5mXtPG+h
>>963
えっ、繰り返し処理って一個ずつ舐める以外の手法ある？
実際なにかするかは別として、絶対舐めるよね？
2020/11/13(金) 23:05:36.62ID:PGsPGVPV
>>964
しゃぶれよ
966デフォルトの名無しさん
垢版 |
2020/11/13(金) 23:05:54.91ID:PXZYfUWY
舐めるって何だよ（哲学）
2020/11/14(土) 02:20:57.24ID:J1qSeya3
やっとレベルの高いスレになってきたな!
2020/11/14(土) 02:41:25.39ID:OEj/Ps5D
>>964
何Pするつもりだ
2020/11/14(土) 04:48:04.59ID:hiKCjj1+
一人が同時に何本の竿を処理できるのか
その答えを俺は知ってる
2020/11/14(土) 09:58:05.81ID:lw/b63Rx
GoFのを定義とするならhasNextとnextでラップして要素持ってるだけなんだよな
流石に古いだけあって些か貧弱
2020/11/14(土) 10:52:40.49ID:AxEpuS5V
イテレータにそれ以上の機能は何も無いだろ。
それ以上を求めると、ジェネレータとの釣り合いが取れなくなるんじゃないか？
連続したもなにもなく「次」の値を取り出していくものでしかない気がするが。
レス数が950を超えています。1000を超えると書き込みができなくなります。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況