言語選定資料
目次
判断基準
-
BtoB等でのパッケージ提供時の考慮
- コンパイル言語
- マルチプラットフォーム
-
採用の為 (分母の多さ)
- ユーザー数
-
保守性
- コンパイル言語(コンパイルエラー判断)
- OS依存度(rubyならOSにmysql入れないとライブラリ入れても動かないとか)
- let などの再代入が不可能機能ありか
- 言語のformatの自由度 (Pythonがうるさいみたいな)
- テスト、コードフォーマットはどれも入れる前提だが言語固有があれば◯という感じ
-
求められるセキュリティ基準実装?
- 金融系とか 行政で採用されているか？
Java/Kotlin
- オブジェクト指向・構造化・手続き型
- 強い静的型付け
- コンパイラ言語、並列プログラミング
メリット
- 人が多い！
- ライブラリはダントツ。
- 日本語の資料も多い。（調査時間少なくすむ）
- Androidエンジニアのデフォ言語
- 銀行系のシステムやら業務系システムでの実績の多さからセキュリティ面での実装対応も調べやすい
- web, batch共に多くの実績あり。
- ライブラリなどもOS側に依存が少ない
- version更新時に下位versionの互換には優れてる。
- コードを渡さずある程度まとめたjarで提供できる。
デメリット
- 人が多いけど、スキルが低い人もめちゃ多い。
- 言語の仕様がかなりoldで縛られている。Kotlinで少し解消
- 古い印象はどうしようもない。
Ruby
- 構造化、命令型、オブジェクト指向
- 強い動的型付け
メリット
- 人が多い！
- 日本発祥言語
- 日本語の資料も多い。（調査時間少なくすむ）
- Webアプリでは定番のRailsあり。ただフルスタックフレームワークだけど。
- ベンチャー採用に多い
デメリット
- 人が多いけど、こちらも人が増えすぎて練度はバラバラ
- 言語の仕様の更新も激しいけどその分、versionアップがシビア。古いのは基本推奨されない
- OS依存が多いのでインフラも考慮。mysql等も基本osに入れないといけない。
- パッケージ提供時にはコードまるみえ。
- batch系の処理は少ないイメージ。主にweb系
Node.js
- イベント駆動型プログラミング環境
- altJSの選定を再度必要。
- TypeScript (静的型付けをしたいとき)
- CoffeeScript
- ES7なのかとか (まーデフォがこの基準でES5はなし)
※ 色々ライブラリを取り入れる事により書き方は異なる。
メリット
- ブロックチェーン業界だと関連ライブラリ多し。
- frontと同じJavascriptで書ける。
- front側エンジニアだとそもそも開発時のツールとして必須
- ベンチャー採用増えてきてる。
デメリット
- 現状人が集まらない。
- ES6から大きな変更がありversionの更新が激しい
- パッケージ提供時にはコードまるみえ
- altJS等を入れるとやはりコンパイルが発生して遅かった。(TypeScript初期で導入経験あり。)
Go
- 強い静的型付け
- コンパイラ言語、並列プログラミング
間違ってたらごめん。軽くは読んでる
メリット
- ブロックチェーン業界だと関連ライブラリ多し。(gethがGoでの実装)
- 個人的には新しい言語でありモダンな言語という印象
- testやfmtなど言語レベルで用意。（他言語にも同様にあるがfmtはたぶんこいつが初かと）
- Pythonとかの影響か書き方に統一性がある。言語の書き方に縛りあり。
- ベンチャー採用増えてきてる。
デメリット
- たぶん同様に人が少ない。
- コンパイルして納品可能なはず。
- 今までと違いクラスとかの概念がなく言語の設計思想がだいぶ異なる。
参考URL
まとめ
個人的には言語の批判はないです。あくまでお硬い物を作る前提なので。
NodeやRubyは手軽に作るプロトタイプやサービスの初期開発などには
手軽に使えていいと思っています。
下記は簡易ながら独断で表にしてます。
| 言語 | ユーザー数 | pkg販売 | メンテナンス度 | セキュリティ面 | ドキュメント量 |
|---|---|---|---|---|---|
| Java | ◎ | ◎ | ◯ | ◎ | ◎ |
| Ruby | ◯ | △ | △ | △ | ◎ |
| Node | △ | △ | △ | △ | ◯ |
| Go | △ | ◯ | ◯ | ◯ | △ |
2018/04/13 現在
そもそも今の時代にjarで固めてサービス提供ってのは古いと認識
SaaSという選択肢を入れてコンパイルする事はpkg販売っていう項目は不要にしました
Kotlinかなって思ったがGoの可能性とかGoのtest/fmtの用意は
言い換えればgithubの他者のコードの可読性も高いと判断してます。
java等でのレガシーコードの記事のフィルタ等も考えるとGoの将来性にかけるかと思います。