  |
はてなキーワード: golangとは
k8sのSlackみてるけど、mattnがリリースした1.10.0/1.10.1はk8sとして採用見送りになってるね。
（そもそもk8sの規模的にそんなに爆速で依存ライブラリバージョン上げるようなものではないと思うが）
さらにfsnotify issue #757を読み進めたところ（本当にかなり揉めていますが）、現時点では1.9.0を維持するのが安全な選択肢に見えます。
1.10.0および1.10.1は、どうやら「1年間リリースがなかった」という理由が主な背景だったようですが、個人的にはそれだけでリリースを正当化するには十分とは言い難いです。
スレッド全体を見ると、追加の背景や事情もいくつか見えてきて、状況としては“完全に危険”というより“やや不安定だが一応様子見可能”という印象です。
小規模〜中規模OSSであればスピード重視ということでやる気のある有志だけでちゃっちゃとマージ→リリース回してもいいのだろう。
多くのOSSはこれに類するしGolangに絞ると割とCLI Toolが最終目的のものも多い。
ただ今回はk8sという世界中の重要システムで使われてるインフラ周りのさらに下回りに位置するものだったから、スピードよりも安定性重視、ほぼ本業レベルの責務がかかる。
こなへんを軽んじてしまったのかなぁという印象がある。
先のSlackスレッドで言及があるが、Windows周りのメンテをしてくれるのはとても貴重なので、レポジトリ状況が良ければこんなことにはならんかったんだろうな。
そもそもそんな重要なライブラリを1人メンテにしないでーという気持ちが強い。
とかいうノリ、マジ勘弁してくれ……。
ふむふむ。
まぁ、今時のプロジェクトだね。
「現行のPHP版、むっちゃ古くてセキュリティ的に不安だから移行したいんだけど、開くのに1分とかかかる管理画面とか出るようになっちゃったから、むちゃくちゃ速いっていうgolangにしたら一瞬で開くようになるんでしょ？」
……は？
開くのに1分……？
どうなってんのよ、中身？
普通のインスタンス変数のノリで、お手軽にあちこちでDB呼び出しが発生する。
いや、キャッシュされないのか？
同じ物なのに、呼び出し経路で別インスタンスになって増殖増殖。
インフラ層にいるはずのORMのDataAccessObjectが、プレゼン層のHtmlTemplateで乱舞乱舞。
「いや〜、クリーンアーキテクチャとか、採用してなかったんで」
おけ。
3億歩譲ってそれを飲むとして、これ、そのままgolangに移行……、
できるわけねぇだろ！
しかもこのDAO、いろんなところから参照されてて、参照元によってif文で複雑に構成されてて、どこから呼び出されたどういう条件がどうなってるんだか、全部あげるの一筋縄じゃいかないし、なんかの不具合解消のためか、空配列が追加されてたり、カオスカオス。
できるわけねーでしょが！
PHPでフレームワークをモダナイズしつつ、DAOの突き抜けを解消したり、安易に使っちゃうからORMの廃止と……。
同一言語なら、DAOの突き抜け解消とORM廃止はパフォーマンス的に厳しくないところは一旦手を抜けるから……。
golang移行で想定される予算の4/1くらいにできそうかなぁ……？
と思ったら、その金額でも想定予算大幅オーバーって、どれくらいでいけると思ってたの？
何年もコツコツと積み上げてきたプロダクトでしょ？
段階的移行の手間考えたら、真っ当にやったらかけてきた人月金の3倍かかってもおかしくないんよ？
NHKの営業基幹システムとか、大変なことになってんの、聞いたことない？
ちゃんと動いていて、稼いでるプロダクトの移行は、規模等々、一筋縄じゃいかないんよ。
マンションと同じでさ、日々のメンテにも金出さないといけないし、大規模修繕も計画的定期的に行わないと、こういう時にやってなかった場合の数倍のお金と時間が必要になってしまう。
盆栽も同じやな。
SIer出身者には一度作ったプログラムは永遠に資産。作ったら終わり、って感覚かもしれないけど、日々機能追加だなんだ行うSaaSプロダクトとかは、常に形を整えてないと、すぐ腐っちゃうんだよ。
でさ、この辺りのメンテ、多分生成AIはうまく回し続けられないんじゃないかと思うんだよな。
大丈夫か？ w
ただ、エンジニアの足切りの要素が高い(対応できないエンジニアは排除される)ので、PHPに比べればカオス感は激減する。
golangは、PHPの次のお手軽な乗り換え先になっていて、ほぼPHPみたいな使われ方してて、（ー＿ー；）ってなることがしばしばある。
golangに乗り換えられないPHPer様の……、はあまり考えたくない。
障害が発生したり、要件が追加されるたびに、関係する処理だけを順方向に追っかけて、「ここに if 文追加するだけで対応できます」みたいなアドホックな修正が積み上がってる上に、自動テスト無し。
なんてことない、ポツンと一軒家的な、一見周囲から孤立しているようにしか見えない if 文の有無が、致命的な障害発生を抑制していたりして、マジ怖い。
赤のコードか、青のコードか、みたいに見せておいて、黒い隠しコードみたいなのが、ぽんぽん現れるんだよな。
君は生き延びることができるか?
「え〜？ 今動いてるのに、なんでそんなにお金かかるの？」
あのね、今動いてるから大変なんだよ。
返事次第では手を引いていいっすか？
最近だと、Scala/Java、Golang、Rust、C#、Swift、Kotlin、JavaScriptあたりを並行して使っている。
フロントは、できるとか言うと、仕事量がバカにならないので、できないことになってる。
そんなかで、と言うと、サーバサイドでは、ロジックが単純で、高速性が求められるならRust。ビジネスロジックが複雑だとか、スイート化(大規模化)する可能性があるのなら、Scala2(w/o cats/scalaz)/Java。
Golangはね、基本部分の隠蔽化がちょっと難しい感じがするので、5人を超えてくる規模だったら、お勧めしたくない。
Golangはたくさんいる。
って言われることがあるんだけど、質がね。
Rustなら大丈夫か？ って言われたら、最近の生成 AI ででっち上げてくる手合いが増えてきて、大丈夫とは言い切れないんだけど、言語仕様に難しい部分が含まれているので、足切り効果で最低限の質は担保されているので、結果、採用で当たり引く確率は高くなると思う。
そう言うできるエンジニアを惹きつけるだけの魅力を備えてくれ、と言いたい。
「わからなければ書けない」
「わかってないけどなんとなく書ける」とか「完全に勘違いしてるけど書ける、動く」ってのが、発見撤去困難な遅延信管地雷をプロダクトに埋めるのだよな。
なもんで、IT技術者不足！とか言われても、一定程度のハードルがある言語にしておいた方がいいと思う。
なんとなくエンジニアを3人雇うくらいなら、その金額にちょっと色つけて、できるエンジニアを2人とか、むちゃくちゃできるエンジニアを1人雇った方が、確実に元がとれるんだよな、この世界って。
他の職種と違ってエンジニアは、下手すりゃプロダクトの生涯通してみれば、100倍くらいパフォーマンスが違ってくることも、ザラではないからね。
いや、これ、原理的に当然なのに、なぜみんなびっくりしてんの？
んでもって、ベンチマークを用意したら、そのベンチマークに過剰適応する。
ってのは Kaggle 流行った時に十分周知されたと思ってたんだが。
おいらはシステムエンジニアなので、AI 使って何が起こりそうか、ざっくり検証済み。
確かに、ジュニア程度のプログラマよりは局所的なコーディングはましに「見える」。
調子が良ければ、当時で95％くらいは。
人間のジュニアプログラマなら、よほどのアタオカじゃなければ、指導すればちゃんと伸びるか、向いてないと諦めて転職していってくれる。
「いや、ここおかしいよね？」
って指摘しても、根本的なことを一切理解しないで、その場限りの対応するだけ。
毎度、必死にググってコピーしてきて、「俺、できるんで。こんなところでこんなプログラム組んでるような人間じゃないんで」みたいな。
人間のエンジニアなら、ミスが一貫してるんだが、このタイプのエンジニア、生成AIは一貫してない。
いや、それだったら自分で全部組むわ。
ってくらい油断できない。
何やら、人事規則とか色々、ややこしいことも、AIエージェント使えば全て解決！
いやいや、そもそもややこしいところを整理せぇや、と。
設計時の検討事項や会議録、設計書はまとめてAIに食わせれば、いい感じに疑問に答えてくれるようになる！
物事を整理して構造化する能力に著しく欠けている人間がお手軽にAI使うってことは、制御不能な怪物にせっせと栄養を与えて育ててることって、マジで理解したほうがいい。
超短期間、超少量であれば役に立つとしても、長期視点に立って、それが日々積み上がっていくことを考えると、これにベットするのは歴史に学ばんアホウとしか言いようがない。
企業の事業継続の重大な障害になる地雷を埋めまくってるって気づけ。
システムに関しては、生成AI使うまでもなく、整理構造化されないまま、局所的実装を続けた結果、三年五年経って、不具合の根本的解決も、新規機能追加も困難になってる例は、多分一般人、利用者が想像するより多い。
Scala → GoLang で作り直ししたいってプロダクトでは、曰く、「より生産性が高い言語を使いたい」。
いやいや。
言語の問題なんじゃなく、大元の設計の問題、「エンジニアのおつむ」の問題だよ。
言語変えても変わらん。
この傾向は生成AI使ったらより顕著になっていくだろう。
三年後、五年後、圧倒的コード量を前に、AIに頼り切る程度のエンジニアでは何もできなくなって、放棄されるサービスが大量発生するだろう。
この状態になったサービスは、流石においらでも正常化するのに年単位かかる。
悪いことは言わん。
生成AI使うぞー！
これ見たけど、そんなにローレベルやりたいならC++で良いじゃんって思った。俺のユースケースだとgolangか。次のガチプログラムgolangで書いてみるか
