業務アプリケーション開発にGoを採用する理由

この記事は MICIN Advent Calendar 2022 の24日目の記事です。 前回は熊沢さんの２つの新規事業立ち上げで経験したタイプ別MVP検証の進め方でした。 はじめに 本記事では、業務アプリケーションのバックエンドとしてGoを採用することによるメリットを、実際の業務経験を振り返りつつ考察してみます。 近年では多くの企業でGoが採用されています。その採用理由は、「並行処理をたくさん行いたいから」「学習コストが低いから」「フットプリントが小さくコンテナベースのプラットフォームに向いてるから」「Googleが使ってるから」「高速だから」といったところが挙げられるんじゃないでしょうか。 一方で、単なるモノリスなAPIとしてGoを選ぶ必要はないんじゃないのか、といった声もよく聞きます。「初期フェーズはスピード重視でRuby on Railsが最強だ」「枯れた技術であるJava + S

[abekoh]

書きました

[onefootinthegrave]

書いててつまんないのが最大の難点

[strawberryhunter]

複数の戻り値を返せるのは地味に便利だけど、戻り値のerrをチェックするのがだるい。Javaから見てGoにはRubyとは逆方向の文化的ウザさが気にはなるが、なんだかんだ言いつつも使い勝手がいい言語だと思う。

[trace22]

問題の分析に対して解決がGoで適切なのか分からなかった。RubyとかJavaの方が採用楽そうだし、デファクトのフレームワークがダメとかじゃあなんならいいと思ってるのだろ。あと今どきGoFとか言わなくていい

[jun6428]

その理屈だとDjango/pythonが正解でも良い気がする

[queeuq]

人海戦術のときに一番採用しちゃだめなのはspringやらrorだなぁとは痛感してる

[baronhorse]

一見学習コスト低そうだけど特有のイディオムがあって逸れると思わぬ落とし穴にハマるのでそうでもない印象

[sora_h]

ポインタがあるせいで何が起きてるのかわからんってところは結局発生するんだよな…書き手のスキルに依存してる

[wwolf]

好きな言語のマイクロFW使えばよくね？感はあるんだよな。PHPやRubyは脳死でフルスタックFWを選定しちゃってるだけで、本来は言語選定に影響する問題じゃないと思う。

[haton14]

やばいところだと関数の戻り値に4〜5つくらい値入れがち

[devrabi]

保守的にSpring Bootを選択するのでは無くGoやNext.jsを使う話も聞くようになってきたので、こういう話はもっと聞きたい

[arx0balest]

個人的には静的型付けなら割と何でもいい。Ruby・PHPあたりはガチでゴミ。言語もエンジニアもな。本当に質が低い。

[syu-m-5151]

一理ある。そして、どこかの現場の一つのリアルだと思う。

[fjwr38]

まぁこの辺も過渡期だよなぁ

[m50747]

エンジニアの調達しやすさも言語選定には影響すると思う。そりゃ勉強すれば使えると思うけど、やったことない言語の仕事はあんまり選ばないしね。

[diveintounlimit]

“言語としてまだ歴史が浅いからとも捉えられます”つまり言語が熟れてくれば同じことになるのでは。“入れ替わりがちな組織にとってよい効果をもたらしている”入れ替わりが多い状況を改善すべきでは。

[yarumato]

“Goの特徴：表現の選択肢が少ない文法。例えばSlice(他の言語でいうList,Arrayなど)の操作について、filter/mapといった関数型的な処理は標準提供なし。for文で愚直に取り出すか、自前で定義するかになる。”

[yosio_ism]

その理由には個人的に同意するけど、結局なんだかんだspringboot選択しちゃうのよ。無念

[cpw]

帯域脱出だけ用意してくれれば自分の理想の言語になるのに、errをちまちま返さないといけないんだよなぁ

[ryuichi1208]

人海戦術案件でもGoが流行ってるらしいのはこの辺の理由なのかな。

[mizdra]

なるほど