GoからRailsへ転職して気づいた：「明示性」と「規約」の思想の違いから考える使い所

1. はじめに 転職に伴い、メインで扱う開発環境が Go から Ruby on Rails へと変わりました。 前職ではマイクロサービスでGoを使ったバックエンド開発をしていました。Goに慣れた状態でRailsを触り始めたとき、最初に感じたのは、うまく言葉にできない違和感でした。同じWebバックエンドなのに、何かが違う。でも、その「何か」がすぐには言語化できませんでした。 僕は、その違和感を言語化するために、「GoとRailsはそれぞれどんな思想で、何を解決しようとして作られたのか？」を調べてみました。すると、設計の出発点がまったく違うことがわかってきました（Goは言語、Railsはフレームワークなので厳密な比較ではないのですが、そこはご容赦ください。GoとRubyの言語仕様そのものの違いは、また別の記事で整理したいと思います）。 今回は、その調べた結果をもとに、GoとRails（ちょっと

[cinq_na]

似たような記事は色んな所で読んだ気が。迷うならGoのような明示的言語を、確固たる自信がある時だけRoRみたいなのを使えば良いと思う。

[u06nh]

両方やってたけど、認知負荷の上がり具合がrailsは大きい。複雑になればなるほどrails wayに従えなくなる。Shopifyは昔のCTOが「うちはrails g scaffoldした時のコード構成そのものもさ」と言っていて絶対リップサービスだと思っ

[takafumiat]

Railsは開発速度を速くできるけど、どう考えてもシステムパフォーマンス面ならgoのほうが圧倒的に省メモリで実行速度が速いだろ。

[rawwell]

“Goのように戻り値でエラーを明示するわけにもいかず、大きくrescueでまとめてしまうべきなのか、処理ごとに細かくrescueすべきなのか、チームに明確な指針がない中で判断するのは難しいと感じています。”

[hurafula]

go/typescript/kotlinに慣れた後rubyやると型推論とかのコード支援でムキーってなる（なってます） 小さなDSLでもこれなのでRailsともなるとめっちゃ大変そう

[dorokei]

人が書くからRailsは抽象化がなされていてよかったけど、AIが書くなら抽象度の高さよりも、型などでの厳密さのほうがメリット大きいかも

[aarx]

まだ型なしクソ言語で消耗してるの？

[yarumato]

“Goはコードの読みやすさや予測可能性を重視。本質的な処理が、多数のエラーチェックに埋もれがち。Railsは、コードを読むだけでは、この処理はそもそもエラーになるのか判断できず、影響範囲を把握に時間がかかる”

[YassLab]

"明示性には裏返しのコストもあります。if err != nil を呼び出しのたびに書くことになる / 3行のうち1行が if err != nil という関数は珍しくありませんでした。明示的であることと、読みやすいことは必ずしもイコールではない"