パーソナルトレーニングの話
なんか、パーソナルトレーニング続けてらっしゃるんですか?
パーソナルトレーニング、そうですね。つい最近、解約しちゃいまして。
ジムのトレーナーが急遽退職されるっていうことで、パーソナルトレーニングってそういう確かにリスクあるなって、最近気づいたんですけど。
で、その後の候補の後にやってくださる方も見つからなくて、結局辞めることになっちゃって、今、家で自主トレばっかりしてます。
そうなんだ、そうなんですね。トレーナーの方は別に、独立するみたいな感じとか、別のところに行くみたいな感じだったんですか?
あ、でもそんな感じです。大会に出るのに集中したいからっていうので、自分のトレーニングに集中したいっていう理由とか。
で、その後に実はもう一方、アサインしてもらったんですけど、その方もなんかちょっと自分の通ってるところまでの場所が遠くて、
もうちょっと近いところに通い直したいみたいな理由で退職されてって感じですね。
なるほど、そうなんですね。まあでも、結構なんかトレーニングされてから、こう、結構インプルーブしてますよね。こう、ゴッシーさん。
それはあのあれですか、体重的な意味とか、健康的な意味。
そうですね、顔の輪郭とか、シュッとされたなっていう感じかな。
そうですね、だいぶ10キロぐらい痩せたんじゃないかなって思うんですけど。
まあその筋トレ始めてから本当に、全然風邪ひかなくなって、健康にもめちゃくちゃいいじゃんって思ってたんですけど、
子供ができて、保育園に行き始めたんですけど、子供からこう風邪をもらうことが最近多くなって、もう全然ダメじゃんってなってます。
ゴシーの経歴
最近は本当に血膜炎、ウイルス性の血膜炎をもらっちゃって、1週間以上ダウンしてました。
いや、子供からもらうわね、もういたしかたないよな。まあそうだよな、胃腸炎とかなると最悪なんだよな。
いやー、つらいですね、それは。
冒頭はそんな感じで、ということでこの番組は趣味でOSSをやっているものだという番組で、OSS作家のソムがゲストを交えながら趣味や仕事について話をするポッドキャスト番組です。
ということで今日のゲストはゴシーさんです。よろしくお願いします。
よろしくお願いします。
じゃあゴシーさん、自己紹介お願いします。
はい、GOCCYという読みにくいスペルで活動しているゴシーというものなんですけど、
今は新卒で2012年にミキシーという会社に入って、そこで5年ぐらい勤めた後にゲーム系のスタートアップに3年ぐらいいて、
その後2020年ぐらいに今のメルペイという会社に来て、今もそこで働いています。
基本的には社内のエンジニア向けの生産性を向上させるツールを作ったりとか、
そのツールを使う人たちをアシストするようないろんな業務をしているというのがメインのお仕事の内容になっています。
はい、よろしくお願いします。
よろしくお願いします。
本名がね、ゴシマさんだからゴシーっていう。
そうなんですね。
ですよね。
昔からずっとそう呼ばれてきたんで、アカウントもこれにしたんですけど、
この名前にする理由が、実は誰にも言ってない理由があって、
これは高校生ぐらいの時に父のメールアドレスがこのスペルで書かれてて、
当時自分はそういうゴシーって呼ばれたかったらこういうスペルにすりゃいいのかなと思って、
なんとなくそんなに考えずに父の影響でつけたんですけど、
よく考えた目でSにしておけばよかったなとか、いろいろ思うことありますね。
確かに。僕もマツキ由来でソンムーにしてるから、ソンムーアットとかもあるし、
子供が真似する可能性確かにあるかもっていうのをちょっと思いました。
まあでもうちの子はそんなことしないかな、うちの子っていうか時代として。
そう、マツキはソンムーなんでね。
確かに。なるほど。
ゴシーさんとはそうですね、結構付き合い長くて、僕からもちょっとご紹介しますと、
やっぱりそうですよ、ミクシーに入られた時にのやっぱり衝撃の業界デビューみたいなのがあって、
で、もうこれ調べたらCAsia2012で発表してるから、もう大昔ですね、なんか。
なんか結構ゴシーさん、若者のイメージ強いけど、なんかもう同世代だなっていう感じですよね。
いやー本当ですよ、もう。40万人なんで。
パールと出会いパールを作るっていうトークをして、新卒でミクシーに入られて、
当時はミクシーかないパールを使ってる会社だったから、最速のパールを作ってやろうということでいきなり作り始めたっていう感じですよね。
この頃の頃って覚えてます?
覚えてます覚えてます。
当時その自分はミクシーに入る前に言語処理系を作る研究室に所属してて、
自分はそのコンピューターのコンピューターサイエンスとか勉強し始めたのは大学4年生からなのでかなり遅いんですけど、
その研究室に入ってからプログラミングも覚えるっていう感じで、C言語から頑張って覚えていったんですけど、
そんな自分には処理系を作るっていう研究室はかなりハードルが高くて、日々ついていくのに大変精一杯だったんですけど、
1年とか2年とかやっていくうちにだいぶCSの分野に興味が強くなっていって、
そのスキルも徐々にスパルタ環境で学ぶところがあったんで、処理系に対して結構知識がついてきて、
その研究室自体が実用的なスクリプト言語を超高速に作ると。
ジットコンパイラーとか最新の技術を使って、誰でも使いやすい言語を、
研究目的じゃない、ちゃんと実用的な言語を早くして届けるっていうのを結構ミッションにしてて、
そこでいろいろ学んだ技術があったので、その技術を、その知識を生かして、パールってものを自分なりに解釈して作り直したら、
早く作れるんじゃないかっていうのを思って。
で、当時フェイスブックとかがヒップホップVM、PHPを超早くするみたいなのをやってたりしたので、
その対抗馬じゃないですけど、パールを使っている会社だからパールを早くするのを作りたいって、
そういうのを届けられるのって技術的に面白いんじゃないの、みたいなのを新卒ながらに思ってやったっていう思い出があります。
すごかったですね、これは。で多分この翌年とか、それこそ海外の方からもちょっとゴッシーに会いたいっていうふうに、
YAMLライブラリの進展
ヤップシーに来る人とかも現れて、みたいなのもありましたよね。
その頃結構そのパールの将来みたいなのがやっぱりいろいろ話されてた頃だったから、
それこそパール6とかパール11とか、なんかそういう話がある中で、
そうですよね、かなりパール業界にとってすごい新生が現れたっていう感じでしたよね。
確かに。自分もそういうのを牽引していきたいみたいな、確かに思ってた思いがあります。
パールモーションみたいなものを作った時もそういうモチベーションで、
当時から言ってみれば、パールのコードをいろんなところで動かせるようにしたいから、
そのLLVMの中間表現にパールのコードをコンパイルして、それをLLVM IRをいろんな表現に変換する。
例えば今だったらWebアセンブリとかあると思うんですけど、当時で言うとASM.jsとかを使ったものにしてブラウザ上で動かすとか、
なんかそのパールモーションってやつはそのiOSの上で動かすしたいから、
そのLLVM IRからAppleのアーキテクチャにネイティブコードに変換、コンパイルして、
あとそのObjective-CのUIキットとバインドして、UIも操作できるようにするみたいな、そういうやつでやってましたね。
いやー、パールモーション、これ見てそんなのあったなっていう、それはすごい頑張って作ってたなっていうのを思い出しました。
そう。なので、そうですよね。
で、その後結構パールボンガーの人たちはGoを書くようになって、Goを書く人が多くなって、ゴシーさんもGoを書いて、
で、僕はそのGoYAMLってやつとGoJSONってやつをよく使わせてもらってるんですけど、
こういう超大事なシリアライゼーションフォーマットのライブラリを作ってるので、超お世話になってますって感じですね。
GoYAMLは僕がツール使ってYAMLサポートするときは絶対これしか使わないし、
てか他に選択肢も少ないと思ってるし、GoJSONはもうイスコンの初手で入れるみたいな、そういうライブラリになってますね。
イスコンで標準のJSONライブラリとコンパチで動くライブラリなので、
まずインポート文を書き換えるところから始まるみたいな、そうするとスコアが2割ぐらい速くなるみたいな、なんかおかしなことが起きるみたいなので抑えなっております。
ありがたいですね。ちなみにGoJSONはまさにイスコンのために作ったもの、実は。
自分がイスコンに出るときに同じように初手でインポート文を書き換えて速くするのをやりたいがために作ったみたいなところもあって、
自分はなかなかイスコンで上位にはいけないですけど、そうやって使ってくださる方がいっぱいいるのはありがたい話ですね、本当に。
そういうのちゃんと一般公開してくださっているのはすごいありがたいですしね。
あとそれこそ初期は結構イスコン用に入れるとちょっとエラーが出て落ちるみたいなのもありましたよね。
でも逆にそういうイスコンで鍛えられて結構さらにちゃんとした実装になっていったみたいなのが面白いなって思ってます。
それこそソンムさんにも一周あげていただいたりとかしたの覚えてます。
そうですね、一周あげましたね。
なんかそう直そうかと思ったけど多分別の人に直されてしまったみたいなのがあった気がする。
そうですね。
なのでとにかくゴッシーさんはそういう結構チームで本来作るレベルのソフトウェアを結構個人で凌駕してしまうっていうすごいウィザード級のソフトウェアエンジニアっていう、そういうふうに思っております。
恐縮です。
なのでそうですね、たぶん初めて会った時の話を書いてくださってますけど、
そうですね、たぶんそれこそゴッシーさんが新卒だった頃に、たぶんパフィックスさんとか交えて新宿かどっかの居酒屋で飲んだみたいなのがあった感じですよね。
あの時は全然、あるコミュニティの方とも話したことある人なんてほぼいないですし、
あの時もたぶんパフィックスさんに誘っていただいたのかなんだか。
で、たぶんその飲み会でソウムさんとお話し初めてさせていただいたみたいな流れだったと思うんですよね。
たしかに、そうですね。僕としてもすごい話したい人だったから、話せて嬉しかったっていう覚えがあります。
逆にすごいエンジニアの人と話すと、逆に緊張しちゃうみたいなのがあるんですけど、
まあまあその後も仲良くさせてもらえて嬉しいなって思ってます。
こちらこそありがとうございます。
まあそうですね。で、今回お呼びしたきっかけっていうか、たまに定期的に飲んだりしてるから、いつか来てもらえるといいかなって思ってたんですけど、
ちょうど今日出た記事の中で、僕がちょっと寄稿してる記事で、印象に残るプルリクエストは何ですかっていう、そういうファインディーさんから出てる記事があるんですけど、
これで、僕以前ゴーヤムルにコントリビュートしたことがあって、ゴーヤムルっていうか、これはすごい複雑なんで後で説明しますけど、
多分世界的には一番使われてるGoライブラリにコントリビュートしたことがあって、それのことを紹介してるんですけど、
で、これは、go.pkgin.yamlっていうライブラリ名になっていて、GitHub上はgo-yaml/.yamlっていうのでホストされているっていうライブラリなんですけど、
で、これが最近アーカイブされたと。これが結構大きな事件なんですよね。なぜかっていうと、これはもう世界的には一番使われてるyamlライブラリで、それこそKubernetesのyamlとかもこいつが使われてるっていうのがあるので、
じゃあどうすんだみたいな話になってて、じゃあやっぱり、ごっしーさんのgo.yamlも結構今後有力な選択肢になってくるっていうか、もうこれしかないんじゃないかなっていうふうに考えていたんですけど、
そしたら、yamlオーガニゼーションっていう、yaml全体の公式のオーガニゼーションがあるんですけど、それがこのgo.pkgのyamlをフォークして、yaml/.go.yamlっていうのをフォークして作ったっていう。
そういうのに、ことが多分先月ぐらいに起きていたっていうのがあって、これをオフィシャルなGoのライブラリとして後継としたいっていうことを書かれてるみたいな、そういう状況になっているので、
ちょっとこの辺の話をごっしーさんに伺えればなというふうに思って、来てもらったっていうのがあります。なので、すごいややこしいんですけど、go.pkg.in.yamlっていう、で、これはgo.yaml.yamlなんですけど、これがアーカイブされて、yaml.go.yamlっていうのにフォークされて、
で、それとは別に、ごっしーさんが作ってるgo.c.go.yamlっていうのがあるっていう、そういう3つのリポジトリがあるっていう、これ言葉ではすごい説明が難しい状況ですね。
YAMLライブラリの進化
おだしょー うん。まあでも、オフィシャルのyamlオーガニゼーションがアーカイブされたyamlを引き取ろうとしてるっていう、で、それとは別に、ごっしーさんが作ってるyamlのライブラリがあって、これもかなり有力なyamlの選択肢になってるっていうのがあるっていう状況ですよね。
おだしょー そうですね。まあこの辺に関して、じゃあちょっといろいろ話していきたいと思うんですけど、ちなみにソンムさんのこの記事、自分もさっき読みました。
ソンムさんがそのコントリビュートしたのも、以前に伺ってたので知ってて、なるほどこういうプールリークだったんだみたいなのがこの記事からわかって面白かったです。
で、その、普段のgo-yaml//yamlの話なんですけど、これはその、まあ話がその6年前ぐらいにいくんですけど、当時は、当時ももちろん世界で一番使われてるライブラリで、まあこれ以外の選択肢はそもそもなかったっていう状況でもあったと思います。
自分も当然、yamlを使うツール作る時はこれを使ってたんですけど、まあいろいろ使っていく上で、まあそのエンコーディングJSONの感覚で使っていくと、なんでこうなってんのみたいな、いろいろつまずくところが多くて、まあなんかこれバグじゃないかみたいな挙動とかも、まあいろいろ踏んだりした覚えがあって、
まあただでも、そのリポジトリのメンテナンス状況とかを見ると、まあ当時でもあんまりプルリクエストとかを取り込んでくれてるような印象がなくて、で、まあコードベースもそのlibyamlベースのポートになってるので、まあそのCからポートしたっていうところもあって、まあこれもこの話もちょっとまた後でしようと思うんですけど、
なのでまあちょっとコードベースの語を由来じゃなくて見にくくて、まあなんかこうコントリビュートしにくいなという印象を結構持ってしまったので、まあなんか自分その前にパールのパーサーとか作ってたっていうのもあって、
まあパールのパースよりは、まあyamlの方が楽だろうっていうような印象もあったんで、ちょっと作ってみようかなと思って作り始めたのがきっかけでした。
なので、go-yamlスラッシュyamlをリプレイスするための選択肢になりたいっていう、まあそういうライブラリとして作り始めたのが動機で、
そうですね、まあもう6年経ってだいぶそのコントリビュートしてくださる方も多くいらっしゃって、そのメジャーなバグどころが取れてきてて、実用上普通に使う分にはほぼほぼ問題ない状況にまでなりましたと。
で、結構有名なOSSにも採用していただいてて、多分業界的にはもうすでにあのナンバー2ぐらいのユーザーがいるとは思うんですけど、まあとはいえ自分の中では絶対自分のライブラリの方が使いやすいだろうとはずっと思ってはいるんですけど
自分のライブラリを知らない、知らなかったりとか、そのスタンスが一番多いっていう理由で採用する方は基本的にはこの一番メジャーどころのライブラリを使ってるんだろうなっていうような、そういう価値観でずっといたんですけど
今回のアーカイブを受けて、なんで自分的にはその数年前からもう一個もメンテナンスされてないし、実質アーカイブ状態ではあったと思うんで、そんなに驚くことでもなかったんですけど、業界的にやっぱり明治的にアーカイブされたっていうのはインパクトが大きいみたいで
それで初めて危機感を覚えるという方も結構いらっしゃったみたいで、いろんなプロジェクトが移行先みたいなものを検討してたと、中には自分と同じように数年前からそもそもメンテナンスされてないからすぐそこの移行先を探すっていうのもしなくていいんじゃないかって言ってる発言もいろいろあるんですけど
中にはやっぱりそもそもこの今のgo-yamlがサポートできてないいろんなイシューがあるので、そもそもそのイシューに問題感を感じてる人とかは移行したいよねって思ってましたと
で、自分のライブラリーにその移行先としてあげてくださいっていう方が結構多くて、おって思ってたんですよ 実質そのスター数も1月あたり200スターぐらいずつ増えてきてて
今年の4月ぐらいからですね、もう4、5ってきてますけど200ずつぐらい増えてて、結構順調なペースで増えてたんで嬉しかったんですけど、最近そのyaml本家で報告するって話は
ふとむさんに教えてもらって知ったっていうのがあって、まあ知って、で、まあ自分としてはなんでっていう気持ちもちょっとありましたね、そのなぜその今メンテされてなかったこのライブラリーを報告するのかと
で、その自分が今2番手の位置にいて、これからその1番手に行くいい機会だったのにみたいな、そういう気持ちもちょっとあったんで、あれって思って
まあなんかスラックでなんか、このyamlについてのいろんなそのコントリビューションとかを受け付けているよみたいな話をしましょうみたいなのがリードに書かれてたので、ちょっとスラックの方を見に行って
実際話をしてきましたというのがあって、で、そこでそのyamlスラッシュGoYamlの思想がちょっと知れたのが最近面白かったトピックです
これ面白いですね、このCNCFのスラックワークスペースでなんかゴッシーさんが発言してるの多分入れば誰でも見れると思うんですけど、これやりとりしてんのちょっと面白いですね
それこそなんかこうインギー.ネットさんが直々にこう結構何ていうか返事してくれてるのちょっと熱いなっていう感じになりました
まあそのカイツマンでその概要を言うと、結局そのyamlスラッシュGoYamlっていうのは一番使われてるからっていうのも理由なんですけど
なんでそのフォークしたか、このライブラリをフォークしたかって話なんですけど、一番使われているのっていう理由の他にそのLibYamlをポートしてたっていうのがでかいらしいですね
彼ら的にはLibYaml、LibYamlっていうのは元を正せばPyYamlからのその実装のフォークなのか、ちょっとこの辺は曖昧ですけど
コミュニティの反応
そのPyYaml、LibYamlっていう実装を基本的には彼らはそのYaml本体の実装の標準だと定義したくて
それを忠実にポートしているからこそその価値があるっていう見方をしてるみたいですね
なのでその、だから自分たちがGoの流儀に従ってないっていうふうに思ってしまったところは、逆に言うと彼ら的には良かった部分でもあって
その設計のその思想とかがここで大きく違うことがわかるのが面白いんですけど
で、また追加で思うのが、要はパーサーの標準的なものに乗っかってるかどうかっていうのが一番重要視しているところで
その上のAPIのデザインとか、どういうものをパブリックのAPIに切り出しているかとか
どういうユーザーに使わせたいかとか、逆に言うとそういうところはそんなに考慮してないのかなというのも逆に思えて
そういうのは、逆に言うと自分のライブラリはそういうとこかなり重要視しているので
ユーザーにしてみればそこがその選定理由に大きくなってくるところではあるんで
彼らも言ってたんですけど、自分のとYAMLスラッシュGo YAMLっていうのは共存可能な
敵対関係ではなくて、YAMLエコシステムの上で共存する有力な選択肢のそれぞれが選択肢になるっていう話をされてて
自分も実際それでそれが落とし所としては良さそうだなっていう気はしました
そうだよね、なんかこの辺はかなり難しい話だなと思っていて
やっぱりそれこそKubernetesの裏側でももともとの一番使われてるGo YAMLが使われてるので
ラッパーみたいなのはKubernetesは書いてるけど結局その裏側でこのYAMLライブラリが使われてるみたいなのがあって
それが全部5CYAMLに切り替わったら熱いなっていう感じもあったけど
なかなかそういうジャッジにもなりづらいのかなって
でもじゃあその上の代替みたいなものをどう示すのかみたいなところで
それこそ本体のYAML総本家が頑張ろうとしてるみたいなのがあるのかなっていうのはありますよね
でもこのGo YAMLはまだ27starsしかないっていう感じなんで
実装の違いと挑戦
これがどうなるかっていう
そうですね、気づいてない人がほとんどなんでしょうけど
競技中っていうことでね、だからその元のアーカイブされたやつが7000スターぐらいで
5Cさんのやつが1700スターぐらいっていう感じですね、今見たら
でもやっぱりそのYAMLオーバニゼーションっていうところで引き取るわけだから
結構そうだよね、彼らはそういうCで書かれたLibYAMLみたいなものとか
Pythonで書かれたPyYAMLみたいなものの
なんとなくその内部実装みたいなものが近いことを重要視してるっていう感じはありますよね
それは多分彼らとしてメンテナンスしやすいみたいなのもきっと背景にはあるんだろうなっていうのは思ったりはしました
やっぱりそのYAMLのスペック、そのスペックに対して忠実に実装するそのリファレンスっていうものをちゃんと守っていくっていうところに
やっぱりYAMLオーバニゼーションとしてプライド持ってやってるっていうのが結構でかいのかなという気はします
逆に言うとだから、GoとしてYAMLライブラリをどう使いやすくするかみたいなことに関して
どこまで関心があるのかとかは分からないんで、そこがその引き取った結果どうなっていくのかっていうのは今後の見どころかもしれないですね
見どころですね、やっぱりそう、どうしてもGoのスペシャリストがいるわけではないだろうから
逆にそういうむしろ元々のLibYAMLとかに実装が近い方が彼らとしてはメンテナンスしやすいみたいなのもちょっとあるのかもしれないなっていうのは
思いました。でももうその最初の話もそうだけど、やっぱりそういうLibYAMLから明らかに移植したでしょ、そのままCをそのままGoにポートしたでしょみたいなコードだから
なんかすごいやっぱ読みにくいとかなんか慣れないとか、あとやっぱ巨大なライブラリだから結構変数の命名規則とか結構全然
場所によって違うんだけど、それもそのGo版では結構習っちゃってるから、だから読みにくいみたいなのもあったりしますよね。
いやーわかります。実際ソームさんはプルリク出すところまで行ってるから、余計に読み込んでて大変だっていうのはわかってるでしょうけど。
そうなんですよ。これプルリク出したときすごい頑張って読んで、もうなんか結構すごいしょうもないバグだったんで、いやーこんなしょうもないバグがやっぱメジャーなライブラリに残ってるもんなんだなっていうのをね、やっぱりこう改めて感じたっていうのはね、ありましたね。
まあ、でも結構そういう意味で、このインギーさんとの話し合いも結構面白くて、だから結局そのリブヤムルだったりパイヤムルみたいなものの動作が事実上標準的になっているみたいなのがあるから、それに近い実装のほうが好ましいみたいな話もありましたよね。
というのも結局こういうのって、結局その実装か使用かみたいな話があるわけですよねっていう、そういう実装性とするか使用性とするかみたいなのが、よくプログラミング言語でも多分、処理系の実装性とするか、それともちゃんとスペックを作って複数の処理系を作れるようにするかみたいな話があると思うんですけど。
で、ヤムルは結構ちゃんとテストスイートが揃っていて、なのでそういう意味ではちゃんと複数実装を期待した作りにはなってはいるものの、現実的には結構実際使われているライブラリの挙動みたいなものが標準になってしまっているみたいな、そういう話がされてて、これはなかなかこう難しい話だなっていうのは思いましたね。
そうですね。ヤムルってそのスペック読んだことがある方はわかると思うんですけど、やっぱり網羅的ではなくて、このスペックからなぜこの挙動になるんだろうっていうその間にギャップがあることが多々あるわけなんですよね。
で、そのギャップっていうのを理解するために、これが仕様なのか、個別の処理系独自の実装なのかっていうのを把握する必要があって、自分もオンラインのヤムルパーサーとか、
Go-yamlスラッシュヤムルの実装とか、場合によってはLibyamlとかの実装を照らし合わせながら、このスペックを満たす実装が何が正解なのかっていうのを考えたりすることもあったんですけど、
かなり大変だし、あとその実装によって挙動が違うことが本当に多くて、どれが正しいのかっていうのはわからないことがあるんですよね。
で、そのソムさんにさっき言ったテストスイートっていうのも、そのYamlテストスイートっていうのが有名なやつがあって、複雑なテストケースとかも一応書いてはあるんですけど、
そのYamlテストスイートをパッスル実装を作ろうとした時に、スペックからだと読み取れない、なぜこのテストスイートの期待値が得られるのかっていうのがわからないことが結構あって、
スペック読んでもわからないみたいな。で、じゃあこの実装だとこれをどう処理してるんだろうって言ったら意外とケアしてなかったりするっていうのがかなり多くて、
そういった意味で、Yamlのそのテストスイートっていうのを100%満たすっていうこと自体が意味があるのか、大変なだけなんじゃないかっていうことを思ってたら、
Yamlの実装の課題
実際インギーさんとの話の中で、実際テストスイートを全部網羅した実装っていうのは実用的なものはなくて、
で、フェイルするものもあるけど、うちの実装のLibYamlとかPyYamlっていうのが実質フェイルするけどそれが標準になってるみたいな話を受けて、なかなか苦い顔をしました。
いやそう、テストスイートがね、そのテストスイートがそもそも合ってるかどうかっていうところもわからないし、世の中に100%のものが実質ないっていう。
で、2020年まではなくて、で、2020年ぐらいに多分このインギー.NETさんが多分すごい一応通る参照実装を作ったけど、実用的ではないみたいなことをこのスレッドの中でやり取りをされてますね。
だからそう、Yamlは世の中に完璧な実装がないっていうことで有名なんですけど、それが図らずもこのやり取りの中で露呈されたっていう感じはありますね。
あれですよね、多分元々のGoのYamlライブラリも、ゴシーさんのYamlライブラリも一応網羅率は測ってますよね、テストケースの。
そうですね。多分元々のメジャーのライブラリの方は、Yamlテストスイート側がメジャーっていうのもあって、勝手に測ってくれてて、
で、それのスコアとかも確かあるんですけど、それとは別に自分もそのYamlテストスイートを全部引っ張ってきて、自分のライブラリがそれどこまでパスするかっていうのを独自にやってるんですけど、
そのときに、この、配布Yaml、スラッシュYamlと比較して両方計測してみるというのは試してみてました。
で、一応なんだっけかな、そのメジャーのライブラリの方は7割ぐらいが通過率で、自分のはもう8割超えてるっていう感じですね。
そう、そんなもんなんすよね。言うてもそれでも。だからもういかにそのテストスイートを完璧に網羅することが難しいし、それに意味があるのかどうかよくわからんっていうのはありますよね。
あります。例えば、Yamlって本当に奥が深くて、普通の人が普通に使う分だったら、Yamlのオブジェクトのキーって文字列なんですけど、
だからそれをGoの型にマップするときって、ストラクトとかマップのストリングのキーがストリングになる型で表現できるはずなんですけど、
実際にはYamlってオブジェクトのキーにストラクチャーを取れるんですよね。だからマップのキーにストラクトとかスライスとかがきてもスペック的には問題なくて、
でも実用上そんなことをしたい人が、それをして何の価値があるのかみたいなところも含めて、したい人がいなくて。
それをサポートしたいってことは、マップのキーを必ずAにしないといけないけど、マップのキーがストリングの前提で作った方がデザインとして美しいとか、
実用上も考えてみたいなので、自分はキーをストリングに基本的にはしてるんですけど、
そういうGoとマップする上で、Yamlの仕様をどう落とすかみたいなところも考えないといけないポイントで、
この仕様を全部満たすっていうことが本当にユーザーにとって幸せになるのかどうかっていうのも含めて、
このYamlテストスイートを全部パスすることが正しいのかなと思って、あえてそこいうところで止めてるっていうのもありますね。
インギー.NET氏の貢献
そうだよね。それはあるよね。
キーにオブジェクト取れるっていうの結構すごい話で、でも確かにキーにスライスとか取れると、
何らかの集合キーとしたバリューみたいなのがあると便利かもしれないと思うけど、別にそこ頑張る必要ないよねっていう感じはするし、
それにキーをAnyにするとめちゃくちゃ、ライブラリー利用者側からするとめちゃくちゃめんどくさいよね。
そこは明示的にストリングであってほしいっていうのは、ユースケースのほとんどがそうだから、
むしろそういう節度を持って使えばいいじゃんっていうのがあるからね。
パールのハッシュもリファレンスをキーに取れたと思うんだよなっていうのがあって、
いや、パールをパースできたんだから、ヤムルもパースできるやろうみたいなことをおっしゃってましたけど、
なかなか趣深いなっていうのは思った。
さっきから何度か話してるインギー.ネットさんっていう人が、これがかなり面白い人で、
てかもともとめっちゃパールの人なんですよね、この人は。
しかもパールの中でも、この人がヤムルの仕様とかを考え始めてヤムルを提案した人で、
今でも結構精力的にヤムルの活動されてる人なんですけど、この人はやっぱパール界でも結構マジカル寄りの人で、
マジシャン寄りの人で、そういうマジカルの仕様が好きな人だから、
なんかその思想がかなりヤムルにも反映されてるっていう感じがありますよね。
ああ、なるほどなるほど。確かにそうかもしれない。
あと、そうなんですよね。
あと最近、結構ヤムルスクリプトってやつ取り組んでるんだみたいなことをこのスレッドでも言ってましたけど、
いやもうヤムルスクリプトとかもう嫌な匂いしかしない言葉ですね。
もうなんか、ヤムルを強調してスクリプティングできるようにしようとしてるみたいな、そんなことを本気で言っているのかみたいな。
いや、愛を感じますよね。
いや本当にね、もうこの人なりのやっぱり考えを持って取り組んでるんだなーっていうのがありますね。
本当、こんな、なんていうか、まあ多分だからすごいコンセプトメーカーっていうか、すごいやっぱりこう面白いものを思いついて、
しかも結構実装力もある人だから作っちゃう人なんだけど、そういう人の提案したヤムルがこんな世界的に受け入れられてるっていうこと自体が結構びっくりなことだなっていう感じがありますね。
うん、まさに。
はい、まあそうっすね。
まあ、でもゴッシーヤムルは今後もお世話になっていければなと思っております。
ありがとうございます。
まあ皆さんもぜひ。いや、多分なんか、そのもともと使われてたヤムルライブラリがどうなのかみたいなのはあんまり、
てかその後の進化追ってないんですけど、そのよく使われてるヤムルライブラリが。
でも多分そのゴッシーヤムルのいい点としては、まずその、JSONタグを総合利用可能にしてあるみたいなのがいい点ですね。
そうですね。
そう、ちゃんとそう。とか、あと多分ストラクト埋め込みみたいなのを適切に扱ってくれるとか。
あと多分、そうそう、マーシャルした時にこう、ストラクトの定義順に並んでくれるっていうのがあって、フィールド定義順に。
多分本家のゴーヤムルは、そのなんか、まあハッシュランダマイゼーション的に順番狂っちゃうことがあったと思うんですね。
最近直ってるのかもしれないけど、ちゃんとそのストラクトに定義された順にヤムルが出力されるっていうのがゴッシーヤムルはそうなってるけど、
多分オフィシャルの、オフィシャルのっていうか、ヤムルはなんかそうな、以前はそうなってなくて困るなーって思ってたみたいなのがあります。
そういうのもありましたっけ。基本的にはなんかヤムルのマップスライスみたいなのを使わないとやってくれないっていうのはありましたよね。
そう。ので、まあ引き続き使っていきたいし、皆さんも使えばいいかなと思います。
まあということで、とりあえず前半はこれぐらいにして一旦切ろうと思います。
