AndroidのためのJava/Kotlinはスコープ外とします
まず断っておくと、俺はScalaが好きだ。
自分が作ったScalaプロダクトは二個現存している。うち一つはまだまだ自分が開発している。というか今は会社を作って1人でプロダクトを作っている身なのだが、それもScala3+ZIO2でゴリゴリ書いている。
でも残念、もうScalaというかJVM言語がオススメできません。TypeScriptかGoかRustをオススメします。
どういうこと？
まずこの記事を見ていただくのが一番分かりやすい。
https://aws.amazon.com/jp/builders-flash/202310/java-serverless-saas-backend/?awsf.filter-name=*all
素晴らしいエントリーだ。読みに行かないせっかちな方のために概要を紹介する
JavaプロダクトをAWS Lambdaで動かす時のCold Startの短縮に奮迅した
暖機運転をさせておくProvisioned Concurrencyは効果的だったが費用がかかった
GraalVMでNative Imageを作ったら実に速くなったが、安定して動かすまでが辛かった
起動が終わった地点を保存しておくCRaCは注意点はややあるがお手軽で良かった。
素晴らしい。とても素晴らしい。努力の結晶だ。
素晴らしいがJVMの起動が遅いのが悪いのであってTypeScriptかGoかRustとかで作っておけば良いじゃん？ということになる。
ここからした2セクションほどは上記の記事とほぼ同じ事を言うのだが、自分の視点から思っていることを述べたいので述べさせてくれ。
GraalVMで動かすためにやらねばならないこと
繰り返すが、いまはScalaでプロダクトを作っている。
もちろんそれが適切だからそうしているのだが、素早く起動できることも重要になる予定なのでGraalVM Native Imageを動かせるように注意深く実装している。
紹介したエントリーとほぼ同一の内容になるが、Native ImageとJVMのリフレクション機能は相性が悪く、安心して動かす為には
ほぼ全ての機能を通るようにユニットテストを整備する
リフレクションの利用のされ方を記録するエージェントプログラムを挟んでテストを実行し設定ファイルを作らせる
設定ファイルを作ってNative Imageを生成する
という手順を踏まないとちゃんと動いてくれない。
ぶっちゃけテストを書くのは当然だし、テストを動かして設定ファイルを練ってからビルドする機構を整えたので自分だけなら問題ない。
無いのだが、そんなことするぐらいならTypeScriptかGoかRustとかで作っておけば良いじゃん？ということになる。
CRaC(起動した後あたりの状態復元すりゃいいじゃん作戦）
CRaCはこのエントリーを書こうとおもっていろいろ調べたら知った。
…あれ？これでよくね？（やったね！）
次の素晴らしいエントリでも実に詳しく説明してくださっている
https://developer.mamezou-tech.com/blogs/2022/12/02/jdk-crac/
え、別にこれならいいじゃん（やったね？）
…まぁでも？例えばCloud Runとかで動かすなら？自分でCRaC対応させたプログラムとコンテナ作るの大変そうじゃん？そんなことするぐらいならTypeScriptかGoかRustとかで作っておけば良いじゃん？ということになる。
（今作ってるやつはGraalVM対応やめてこっちにしとこう）
ともあれ、JVMはServerlessと相性が悪いのは間違い無いし、TypeScriptかGoかRustとかで作ってよいならそっちのほうが良いじゃんとはおもう。
Serverlessに向いてないだけでそこまで言う？
様々なシステムを作ってきて、恥ずかしながらも沢山障害を起こしてきたが、Serverless… というか勝手に増減してくれる機構は偉大だ
もしこれから新規でシステムを作るなら以下の方針をオススメする
バックエンドはとにかく勝手に増減するやつで作れ。Cloud FunctionsでもCloud RunでもLambdaでもなんでもいい。たかだかメモリやCPUが足りないくらいで障害にならないというのは素晴らしいことだ
データベースはとにかく勝手に増減するか無限に強化できるやつで、かつ機能が十分あるやつで作れ。PlanetScale(ｺﾚｲｲﾖ-)とかCloud Spannerとか Aurora ServerlessとかMongoDB AtlasとかFirestoreとかだ。たかだかメモリやCPUが足りないくらいで障害にならないというのは素晴らしいことだ。（※でもさすがにスロークエリたっぷりとかホットスポット発生しまくりとかは無理ですから気をつけてください）
お金もったいないからRedisとか噛ましてCacheしたい？やめとけ？そこが負荷で燃えて溶けるよ？最近でたAmazon ElastiCache Serverlessならいいとおもうよ。
とにかく勝手に増減するやつで固めろ。
クラウド破産しちゃうよだって？しちゃうよね。しちゃう人はしょうがないのでがんばろう。でもちゃんとした企業なら即死はしないはずだ、安定とスケールが大事なはずだ。まず安定とスケールを手に入れてから節約を考えた方がいい。Serverlessは時間をかけずにお金を自動スケールに変換してくれる素晴らしい発明だ。
だからServerlessと相性の悪いJVM言語はもうオススメできない。
Scalaはとても良い言語だ。JVM利用でよいのなら今でも一番オススメする。昔からいろんなところで説明しているが言語の習得コストはそれほど重くない。
またScalaか？Kotlinか？Javaか？で議論するのは意味が分からない。好きなの使えば良い。全部等しくオススメできない。
じゃあなんでScalaでつくってるのさ
俺は全部をリアルタイムにしたSNS（みたいなもの）を作りたいのだ。そして作っているのだ。
しかしリアルタイムとなるとどうしてもWebSocketやServer Sent Eventがでてくるのだ。そしてそれはServerlessと最悪レベルに相性が悪い。
そしてガワは会社ではあるが個人資金でやっているだけだ、クラウド破産はできない。許せる範囲で確保した機材で狂ったパフォーマンスをひねり出す必要がある。だからServerlessは使えない。Kubernetesに全部突っ込むつもりだ（いまやってるSUGARも全部k8sでうごいてます）
習熟度が高ければRustのほうがよい可能性が高いのだが、経験があり渡りきれる材料がそろっていることが確信できてパフォーマンスもめちゃくちゃひねり出せるのはScalaなのだ。
俺はScalaが好きだ。JavaもKotlinも好きだ。というかAndroidの為にKotlinももりもり書いている。
でもきっともっと下火になっていくだろう。
そこで、そこで、いま作っているやつを人をお招きできるレベルの事業にして、Scalaかこうぜーーーーーもりあげようぜーーーーっって、いいたい。
そんなことを考えている。
かとじゅんのこちらもどうぞ → https://sizu.me/j5ik2o/posts/eumksus0o0di
数日前にかいたこちらも面白いのでどうぞ → https://sizu.me/sugitani/posts/5cvbsa5hk9wn
アンサーソング！ Scala.jsは視界に入ってなかったけどかなり良いのでは？ → https://blog.3qe.us/entry/2023/12/09/223552
【おまけ】TypeScriptが一番好きかもしれない
TypeScriptはいいぞー
元ある型を元に、プロパティのあれを足したり消したりOptionalにしたり名前を変えたりとかいう面白い真似をできるのはTypeScript独特で、ものすごい快感がある。