私はむしろ言語仕様以外の理由だと思います。新規案件でRuby on RailsかGoかと聞かれたら絶対にGoを選びます。
- GoのほうがRubyよりも新しい言語な上に使用者も多い
- Goは開発環境の構築やデプロイが非常に簡単
- Rubyで作ったものをGoで作り直すという案件は多々ありますが、その逆は聞きません
- 言語以前のRailsのようなフルスタックフレームワークは黒魔術が多くて触りたくない
注 私自身はRust推しで別にGoが好きなわけではありません。
[香車]東上☆あらし☆海美「
そりゃあ、仕事なら、『Go言語のエンジニア』には『Go言語の仕事』を与えるべきであって、『Ruby (Rails)の仕事 』は、『Ruby (Rails) のエンジニア』にあたえるべきみみ。
『もう、Go の仕事はありません。かわりに、Ruby(Rails)の仕事があります』という話なんですか ? それなら、『Go言語のエンジニア』に勧めるのは『転社』であって『Ruby (Rails) の習得』ではない、のでは ?
」
動的型付け言語と静的型付け言語の違いはありますね。Goは静的型付け言語ですが、Rubyは動的型付け言語です。
例えばライブラリの一部において非互換の変更が行われた場合などにおいて、コンパイラがチェックできるかどうかという違いがあります。コンパイラでのチェックができないと、ユニットテストなどにおいてそれらをカバーする必要があります。
ただ、Goもinterface型を使えば Runtimeエラーが出ますしｗ ただそこに、Railsを書きたくないほどの優位性があるかというと そんなことはないと思いますね。 Railsの active recordが便利すぎてｗ 多少の問題には目をつぶってしまいたくなるので（ひとによりますｗ）
# ちなみに私は GoとRuby だったら迷わずRubyですｗ（独り言…）RustとRuby / ScalaとRubyで比べられると開発内容によって少し迷うなぁ……
いや、その前に本人にヒアリングするのが先じゃないかなあ。意外と些細なことかもしれませんよ？
たとえば end 書くのが面倒だとか、慣れてないので消極的だとか、Rubyというよりそれで作ったプロダクトがあれだとか、スクリプト言語は遅いと偏見もってるとか、別れた彼女がRuby推しだったとか、まあいろいろです。
てか、言語仕様とか設計思想とか簡単に比較できるようなもんじゃないし、シロートが上辺だけさらってもかん違いするのがオチじゃないかなあ。
ベテランさんでしたら申し訳ないですが。
どちらも書いたことがありますが、言語としての方向性がだいぶ異なると感じました。
Rubyはひとつのことをするのに色々な書き方ができますが、Goはひとつのことにはひとつの書き方を指向しているように感じます。
この特徴はとくにRubyコミュニティにおいて「書いていて楽しい」と表現されることが多いですね。ただ、コミュニティの雰囲気が内向きであるようにも感じるので、その辺りが他言語からの流入を拒んでいるようにも見えてしまいます。
件のエンジニアさんが書きたくないと仰るのも、あるいはそういう所に要因があるのかもしれません。
コンパイルが必要な静的型付け言語と動的型付け言語では、開発体験が違いますね。
開発体験は、私の造語ならすみませんが、実際開発している時のスピード感だったり、実際の開発フローだったり、それに対するエンジニアの所感を指します。
静的型付け言語と動的型付け言語では、大きく２つ違いがあります。
静的型付け言語は型を設定する必要があることと、コンパイルが必要になることです。
型を厳密に設定する必要がありコンパイルが必要な場合、コードはコーディング時に注意深くコードを書く必要があります。なぜならコンパイルに時間がかかり実行するまでに時間がかかるので、ささっと修正して試すようなスピード感ある開発体験は難しいです。
逆に動的型付け言語は、型付けが厳密でないので、実行時まで挙動がわからないんですよね。よってエンジニアはささっと修正して試せるというメリットの代わりに、プログラムでその挙動を担保する必要があります。
つまり心配事が変わります。
静的型付け言語を使用する開発者は、コードの書いている内容についてコンパイルする前にちゃんと検証する印象です。スピード感より地に足がついている感じ。
動的型付け言語を使用する開発者は、余計なエラーがでないことを心配する印象です。スピード感重視だが不安が多い。
実際私はDjangoを使用して開発しております。dockerとvscodeで開発しており、docker内でDjangoはrun
… (もっと読む)
Ruby on Railsはドメインを記述する上では便利ですが、パフォーマンスと可読性の両立を突き詰めようとすると難しい問題にぶち当たります
動作に無駄があるとか、サーバが遅いとか、ロジックを記述する上でどこまで精細にかけて、かけないかとか開発ツールがGoほど洗練されていないとかそういうことが大半な理由なんじゃないかなと思います。
一番大きいと思うのは例外の扱いじゃないでしょうか。信頼性の高いコードを書くという文脈においては例外はないほうが基本的に望ましいというのが、現代的言語が示している結論ではないかと思います。
要するにどこまで真面目にプログラムコードを書くべきかの期待値が揃えることが重要なのかもしれません。スクリプトでプロダクションレベルの精度の高いプログラムを書くのは結構技量が必要なことで、そうした職人芸に価値を見出さないというのも一定理解できます。
両者の違いはこんなところ。
Ruby(Ruby on Rails)
- 重厚長大
- 何でもできる
- 情報量多
- オブジェクト指向
Go
- 軽薄短小
- API特化
- 情報量少
- 関数
一番大きな違いは、オブジェクト指向かそうでないかでしょう。GoでできることはRailsでもできますが、オブジェクト指向を理解していないと十二分に扱えません。これはRailsだけでなく、LaravelやDjangoにも言えます。
技術者を名乗っていてもオブジェクト指向のコードを書けない・読めない人がけっこういます。自分が理解できないから「Rubyは嫌だ」と駄々こねてる場合もあるんじゃないでしょうか。褒められたもんじゃありませんが。
実務で使うなら、今のところRailsでしょうか。Goだとメンテできる人がいなくなってしまう可能性があります。自分が一生面倒を見るのならいいんですが、それはあり得ないので、少なくとも2,3年後まで手を加えられる人材がいるか否かを考える必要があります。そういう意味ではLaravelがベストです。
Goを書けるそのものよりもAWS・GCPなどのインフラ系の知識と合わせて売り込んだ方が良いです。できればKubernetesの知識があるとなお良いです。
Goを単体で書けるようになっても単価で言えば10万ぐらい上がる程度でしょう。勉強時間や未経験言語による足元を見られる可能性を含めたら労力にさほど見合わないと個人的には感じてます。
また、Go自体はイージーな言語のためGoが出来たから新しい概念を覚えることは少なく、勉強と割り切るならHaskellなどの関数型言語を学ぶ方が得るものは大きいです。さらにRuby on Rails自体が初学者の参入が多くレッドオーシャン化してきてますが、今後はGoがそのようになると個人的に予想しています。
質問の内容にあえて答えるならばScalaでしょうか。あまり書ける人も少ないので単価は高めです。ただ、JVM言語が初めてで関数型が全くわからないのであれば習得するのは結構大変です。
私自身フリーランスをやってきて感じたのがどの言語を書けるかというのはさほど売上には直結しないです。どちらかと言えば相手が大手であったりすることによる支払い能力が高いことの方が売上には貢献します。まあ。大手は大手で働き方が柔軟ではないといったデメリットも存在しますのでトレードオフにはなります。
私の収入に興味を持つ人は多かろうと思いますが、残念ながら現在の日本で収入を公開することにはデメリットしかないので、具体的な数値は述べません。
ただ、私は２つの会社(セールスフォース・ドットコムとネットワーク応用通信研究所)から正社員として雇用されており(しかも、両社からフルタイムでRubyのために時間を使うことが許されており)、さらに複数社から技術顧問として仕事を受けており、加えて講演料・原稿料などを頂いているので、サラリーマンプログラマーとしては充分な収入を得ています。
しかし、一方で給与と副業の収入でいわゆる「莫大なお金」でイメージされる「儲け」を得ることは現実的ではなく、ストックオプションとかの別の手段が必要だと思います。
社会は色んな人や組織が関わっているので予想するのは難しいですよね。
なので、もし言語の需要を気にするのであれば、定期的に監視しそれに合わせていくのが正しいスタイルだと思います。
元々は「言語が作りたかった」というのがRubyを作った動機なので、別にスクリプト言語である必要はなかったのですが、結局以下のような理由でスクリプト言語になりました。
- せっかく作った言語は自分で使いたかったので、プログラマとして普段使いしていた言語であるC、またはシェル(あとたまにPerl)を置き換えるような言語が欲しかった
- Cのようなコンパイル型言語は複数CPU/OS対応などバックエンドの移植性が大変なのでインタプリタ型言語が良さそうだった。
- もちろん、Cに変換してからCコンパイラを使うというアプローチもありえたが、それは大学の卒論でやったので違うアプローチを取りたかった
というわけで、Rubyがスクリプト言語だったのは意外と消去法で決まっています。今思えば正解だったわけですが、未来を予測してそうしたわけではないということは面白いですね。
なぜ人は恋に落ちるのでしょう？まるでパズルのピースのように、頬骨が高い、趣味が同じ、刺激的なデートをした、と理由をひとつひとつ見ていくことは出来ます。ですが、恋に落ちた理由の大部分はわからないままでしょう。パズルのひとつひとつのピースがどのように組み合わさって、恋に落ちるのかはわからないのです。
私の場合は、恋に落ちたのがRubyなのです。私はRubyに恋をしていますし、もう14年間もそうなのです。手続き型プログラミングや関数型プログラミングの素晴らしい部分を取り入れながら、オブジェクト指向プログラミングのブロックやオープンコアクラスを使うことは出来るでしょう。ですが、これらの全てはあくまでもパズルのピースです。他の多くの言語にも同じようなピースがあります。それでも、私が好きなのはRubyなのです。
多くのプログラマにとって、この曖昧で感情的な表現は、うっとしいとは言わないまでも、馬鹿げていると思えることでしょう。プログラミングは、言語科学との関連性も有るのだから、「仕事に最適なツール」を合理的な機械のように選ぶべきであると考えるプログラマも多くいることでしょう。
それでは満足できないと私は思うのです。「最適なツール」などというものは存在しないのです。あなたの脳をちょうどいい具合に刺激するパズルがあるだけなのです。今日では、ほぼなんでも作ることができます。そして、それを使って、さらに何でも作れてしまうのです。これは素晴らしいことです。表現や言語、そして思考の多様性に乾杯しましょう！
By David Heinemeier Hansson（デイヴィッド・ハイネマイヤー・ハンソン)、Ruby on Railsのクリエイター、Basecampの創設者 & CTO
0 件のコメント:
コメントを投稿