DBFluteでGo言語どうしよう?

さて、DBFluteユーザの集いMLにて、
すでに話題になっていますが...

Go言語にどういうしたらいいのかスレッド
(DBFluteユーザの集い)

即席でGo版はできない

まず大前提...

直近でDBFluteのGo版が出ることはない。
なぜなら、そのリソースがまったくないから。

もし、Go言語がJVM言語だったらなんとか...
だけどそうではないので、
DBFluteランタイムを移植する必要がある。

Javaととっても似ているC#DBFlute.NETの方の移行でさえも道半ばなので、
DBFluteランタイムの移植はかなり大変だろうと。

あと、jfluteがほとんどGo言語をさわったことがない。
なのでフットワーク軽いアプローチができない。

Go+DBFluteの声

そんな中、Go言語の熱はちょっとずつ伝わってきています。

Go言語でDBFluteを使いたい

そういった声が...
うーんまあ、一年に数回くらいですが(^^、
聞こえてくるのです。

これはとってもうれしいことですよね。
この期待に答えられないのが悔しいくらい。

新しい言語のジレンマ!?

一方で、新しい言語の大変なところはここですよね。
創世記はライブラリというかフレームワークがほとんどない。
だから、実践でなかなか利用しづらい。

他の言語であれば、ああいうライブラリ、
こういうフレームワークがあってすぐに問題解決できるけど、
まだできたばかりの言語では当然のごとくない。

いまや、ビジネスが期待する機能は多様化し、
求められるスピードはどんどん速くなっています。
どんなに素敵な言語だったとしても、
ライブラリやフレームワークがなければ、
その素敵さをなかなか享受できなくて費用対効果が薄くなる。

新しい言語で素敵な言語であれば、
「そもそもライブラリやフレームワーク自体も進化する」
という考えもあるでしょうが、
現時点で存在していないのであれば、それはないのと同じ。

例えば、ScalaJVM言語なので、
いざとなればJavaのライブラリをそのまま利用できます。
これ自体が良いことなのかどうかは賛否両論かもしれませんが、
普及という意味合いではやはり現場からすると安心感あります。

Go言語は素敵な言語だと聞いていますが、
その辺の不安がやはりまだまだあるようです。

ビジネスの現場でそのコストを丸ごと払うというのは、
なかなか難しいことでしょう。
ビジネスサイドから見れば、それは本末転倒だし。
なので、誰かが、みんなちょっとずつリソースを分け合って、
積み上げていかないといけないのかなと。

それでもできることあるかな?

でも、何もしなければ何もおきない。
jfluteも第一歩くらいは踏めればなぁってところ。

例えば、
Go言語で既存のORM用のEntityを自動生成するとか、
区分値のCDefのようなものを自動生成するとか、
そういった些細なところからアプローチできないかなぁと。

ただ、現時点で、

o どういうEntityを作ったらいいのか?
o どういう区分値のCDefを作ったらいいのか?

それすらもわからないので、まだ調査段階。
単純なgetter/setterのクラスでいいのか!?とか、
もうそういうレベルで。
Go言語の実装習慣とか思想もあるんじゃないかなって。
(Scalaだとimmutableじゃないとってあったし)

まあ、Scalaのときもそうですが、
「その言語のDBFlute版を作る」
というのがjfluteの新しい言語の覚え方...
というか厳密にはきっかけですね。

ということで、Go言語にDB周りに困っている方々、
先ほどご紹介した「DBFluteユーザの集い」のMLにて、
ちょっとあれこれブレストしてみませんか?(^^

【追記: 2015/07/29】
なんか、Go言語版のDBFluteがあるっぽいです!
MikeshimuraのDBFlute Web Framework
ほぼ自動生成する業務用Framework

…
…

ふー、今日もブログ書いたー。四日間継続中。
今日、四地点に出向く分刻みのスケジュールで、
乗り換えとか駅降りてからとか移動が全部ダッシュ、
ということで全然寒くなかった。。。