Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

ゆくKotlin くるRust

ゆくKotlin くるRust

Avatar for TATSUNO Yasuhiro

TATSUNO Yasuhiro

December 17, 2025
Tweet

More Decks by TATSUNO Yasuhiro

Other Decks in Programming

Transcript

  1. 弊 “常駐プロセス ” のこれまで - 2021年、電子カルテサーバーと共通言語 Kotlin で開発 - 2024年、GraalVM

    Native Image でネイティブ化 - アップデートに課題があった通常の JRE (Java 実行環境) を不要に
  2. 技術刷新のモチベーション - GraalVM Native Image を使った継続開発に課題 - ネイティブ版で「Java リフレクションを使った機能が動かない」という不具合がたまに 起きた。テストを書いて

    Java リフレクション設定を自動収集する仕組み を活かす習 慣が担当部署に根付かなかった - Native Image そのものは悪くない(重要)。Java/Kotlin/Scala コードのネイティ ブ化を活用できる場面はいっぱいある - かといって JRE 配布にも戻りたくない - 今後多数の機能追加を計画してるので、たくさんの病院に何度も手作業 でデプロイしていくのはしんどい。安全な自動更新 が欲しい - サーバーサイドは引き続き Kotlin。リライトは常駐プロセスだけ
  3. Rust と Web 技術でアプリ開発できる Tauri を選定 - 2020 年 v1、2024年

    v2 - 一言で言うと小さくて軽い Electron - デスクトップやスマホアプリを TypeScript/HTML/CSS で書ける - 自社 Web アプリのデザインシステム利用で 統一感ある UI - 社内に Tauri 開発経験者がいて、Electron より知見がある - TypeScript に加えて Rust が使える - 高速:CPU アーキや OS ごとに合わせたネイティブコードにコンパイルするので - 堅牢:解放済みメモリへのアクセスやデータ競合を防げるボローチェッカーなど - 元の Kotlin がテスト含め4000行なので「いけるのでは!?」 Slack, Figma, 1password など大手は Electron 採用が多い。Tauri 大手事例は不明
  4. 1100 既存ライブラリで移植できたコード 200 既存ライブラリではできなかったので 自前実装したコード 2600 Tauri でできた新機能。自動更新など 3.2x 1.7x

    テスト大幅増は、Kotlin版で見逃され たケースを網羅したため&Rust ライブ ラリの挙動確認が大きい やってみたら 1人フルタイム 1.5ヶ月で なんとかなった
  5. ❶ファイル監視が環境依存のところがある - 検査装置やオンプレシステムとファイルでやりとりするため、昔なが らのファイル監視が必要 - Kotlinでは Java NIO WatchService で

    Win/Mac 問題なし - Rust で定番の notify とラッパー notify_debouncer を使用。正常系 動作はいいが、異常系(監視対象フォルダの削除)を Windows で 検知できない https://github.com/notify-rs/notify/issues/261 Tauri にパッチする時間が取れてないので、Windows だけフォルダを別途 監視し、削除イベントを擬似発行することで回避
  6. ❷ロガーがグローバルすぎて、出力先カスタマイズが困難 - Kotlin/JVM で広く使われる logback は、ファイルやコードでグローバルのロ ガーも、グローバルじゃないロガーも柔軟に設定できた - 一方、Tauri のログは

    fern という Rust で広く使われるロガーを使用 - fern はグローバルシングルトンで一度設定したら変更不能 。Tauri 内部で fern が設定されるので、Tauri ログ標準(ファイル、標準入出力、web console)以外 の外部サービスなどを設定するすべがなかった 任意のログ出力先(今回は Google Cloud Logging)を追加できる ようにするパッチを送って解決した https://github.com/tauri-apps/plugins-workspace/pull/2600
  7. ❸ .proto から生成されるデータ構造が微妙に違う - サーバとのデータ授受に言語非依存と称する gRPC を使用。共通の .proto か ら

    Kotlin class / Rust struct を生成 - 特に問題になったのが enum のデータ構造で、ざっくりいうと - grpc-kotlin data class MyEnum(val number: Int) みたいなフィールドあり - tonic (Rust) struct MyEnum(u32) のような newtype タプルでフィールドなし - この違いはメモリ上では気にならないが、テンプレートエンジンでテキストファイ ル出力する時に問題。Kotlinで {{ foo.bar.number }} としていたところを {{ foo.bar }} に書き換えるのは、製品導入チームに負担が…… 実際のテンプレートで問題が起きる enum が数個とわかったので、そい つらだけ Kotlin 互換シリアライザを実装
  8. まだ動いてない - Rust というよりデスクトップアプリ開発が難しかった…… - お客さまの Windows PC でなぜかシステム環境変数を読み込めない -

    「30億のデバイスで走る Java」は偉大だった - OS の違いをしっかり吸収してくれる標準ライブラリ - 堅牢で出力先も柔軟なロガー - それでも Rust は……いいぞ - 来週もう1回リリースして真の年忘れをするぞ