勉強会 on blog.kyu08.com

Go Conference mini in Sendai 2026に参加した

Sun, 01 Mar 2026 09:00:32 +0900

2026/02/21(土)に仙台で行われたGo Conference mini in Sendai 2026に参加したのでその内容をまとめる。

Go Conference mini in Sendai 2026

2026年2月21日（土）開催 - Go Forward Together - 東北から広がるGoコミュニティ

https://sendaigo.jp/

【KeyNote】静的解析からみるGoの過去と未来

tenntennさんによるキーノート。

最後に紹介されていたGo1.27のアノテーションで静的解析をできるようにする機能は今まさに自分が欲している機能¹なので調べてみようと思った。

以下メモ。

//line a.go:1のような記法は知らなかった。
- 調べてみたところline directiveという名前がついているようだった。²
- こんな感じでコンパイラが出力するエラーメッセージなどが上書きされる。
  - https://go.dev/play/p/Thvs9U8Twvj
- 自動生成されたコードのエラーを元のコードの行番号で表示したいときなどに使われるらしい。(例えば自動生成されたGoファイルでのエラーに対してprotoファイルの行番号をエラーに表示したいケースなど)
go test -coverを実行すると裏側ではgo tool coverが実行され、計測用のコードが挿入される
Goがセルフホスティングされるようになったのは2015年（Go1.5）（それまではC）
- (まだ10年しかたってないんだなー)
- ここからコンパイラのコードが既存標準パッケージと共通化されたりするようになった
2019
- goplsが登場
- 最初はgolspだったがしれっと名前が変わったらしいw
Go 1.27
- アノテーションによる静的解析
  - 一点もののlinterを作らなくてよくなる。
  - //go:fix inline
    - https://go.dev/doc/go1.26#go-command
  - xxしたあとにyyする、みたいな制約をアノテーションで表現できるようになる（らしい。が一次情報は見つけられていない）

AI時代のGo開発2026 爆速開発のためのガードレール

UPSIDERのRyo MimuraさんによるAI時代の開発生産性を保つにあたっての課題と対策についてのセッション。

最近PRレビューをする機会が増えてレビュワーとPR作成者双方の負担を減らす方法を考えていたのでとても参考になった。

以下メモ。

AIの予期せぬ変更はRules / Skillsでもある程度は防げるがあくまで挙動は非決定的なためすり抜けてしまう可能性がある。そのためハード制約（決定的な処理による制約）を設けることが重要。
ハード制約の例
- internal packageで予期せぬ外部参照から保護する
- depguardによる依存性ルールの強制
- Package by Featureで凝集性を向上させることでコンテキストをうまく制御する
Fuzzing Test, Mutation Testingなどのテスト手法を活用してコード品質を保つ
開発者体験 = エージェント体験
- 両者は同じもの。
- 環境構築、テストとフィードバック、可観測性等開発者体験が悪ければAI Agentもうまく開発を進めることはできなくなる。

Go での並列処理「最初の一歩」から「次の一歩」へ

TakasagoさんによるGoでの並行処理についてのセッション。

並行処理の原理だけでなく、パターンを身につけておくといざ実装するとなったときに役に立ちそうだと思った。（なかなか毎月書くような機会がないのであまり定着してない…）

以下メモ。

Goは同期で書いておいて高速化したい箇所だけ並列化する、という書き方がやりやすいのが特徴。

Go.1.26のruntime/metricsが便利そうな件（？）

o_ga09さんによる発表。

goroutineリークをリアルタイムに検出できるの便利そう。

モジュラモノリスにおける境界をGoのinternalパッケージで守る

SODA inc.のmagavelさんによる発表。

メモ:

「結合はむしろ、忘れてはならない設計ツールだ。」
bounded_contextディレクトリを切っているのが印象的だった

お話したこと:

ディレクトリ構成について
- bounded_contextディレクトリの同階層にはmonolishディレクトリがある
  - これらは現状ワンバイナリになっている
- bounded_contextディレクトリの中には購入、xxx、yyyなどの境界づけられたコンテキストが並ぶ。
- たとえば購入コンテキストの中には購入モジュール、決済モジュールなどがある。
- 購入モジュールからは決済モジュールの公開されたIFを呼び出すようになっている。
- 公開したくないパッケージはすべてinternal配下に置くことで予期しない依存を防いでいる。
- 他にもdepguardを使って依存関係を制御している。

Go設計思想の深掘り

k_program510さんによる発表。

メモ:

発表者の方がオブジェクト指向言語に慣れていてGoにクラスがないことに驚いてGo誕生の背景を深ぼろうと思った、という自分の疑問に向き合う姿勢がとても素敵だと思った。
設計思想は「どこで使うべきか」を教えてくれるいい言葉だ。

database/sql/driverを理解してカスタムデータベースドライバーを作る

replu5さんによる発表。

メモ:

カスタムデータベースドライバーを作る理由
- ログをだしたい
- リクエストをDBのwriteインスタンスとreadインスタンスに振り分けたい
- sqlcを使っているが、sqlcが生成したコードに手を加えていくのは避けたい
- 本体をforkしてしまうと本体に追従するのが大変なので既存のドライバーをラップしたドライバーを作成することにした

お話したこと

sqlcだと引数に応じてwhere句を一部変更することができないと思うがどうやっているのか。
- そういうケースでは複数パターンのクエリを（愚直に）repository層に書いている。
- そもそも巨大で複雑なクエリにはsqlcは適していないので使うべきではないかもしれない。
  - （技術の思想や特徴を理解し適切な場所で使うべき、という姿勢は↑のk_program510さんの『Go設計思想の深掘り』とも通じることがあると感じた。）

nilとは何か〜言語仕様と設計者の葛藤から理解する〜

株式会社サイバーエージェント kurodaさんによる発表。

以下メモ。

Goで定義されているキーワード数を即答している人が数人いてすごかったw（25個らしい）
nilはキーワードではない。true, false, iotaと同じpredeclared identifier(事前宣言された識別子)である。
predeclared identifierのなかでデフォルト型を持たないのはnilだけ。
（ちょいちょいクイズが挟まっていて参加者を飽きさせない工夫があって発表の仕方が参考になった）
interfaceが==nilになるのは型情報もデータも両方ゼロのときのみ。
- なのでtyped nilは==nilにならない。
  - -> var err *MyError = nilのように初期化した値は==nilにならないのでnilをreturnしたい場合は明示的にnilを返す必要がある。（全然知らなかった）
nilに関する問題をどう解決するかの議論がなかなか前に進んでいないことを説明してからのerrors.AsTypeをセマンティクスを変えずにうまく問題を解決した例として説明する流れがめっちゃ綺麗だった。

Who tests the `Tests` ?

sivchariさんの発表。

メモ:

AI時代になってCIの重要性が増している。
カバレッジだけを追っていくと本質的でないテストコードが増えてしまう。
テストコードのテストとしてMutation Testingという手法を紹介する。
Mutation Testing
- プログラムの一部を意図的に書き換え、生成したミュータントに対してテストを実行し、失敗するかどうかを検証する手法。
  - 演算子の変更、elseブロックの削除など
- 失敗することを期待するテスト(KILLED: テスト失敗 == 期待した挙動、SURVIVED: テスト成功 == 期待した挙動ではない)
- どれくらい失敗したかを指標にする。
- ただこれは銀の弾丸ではない。実行時間とのトレードオフになる。
  - 100% KILLEDを目指すべきではない。
Mutation Testingをどう実装するか
- sivchari/gomuというMutation Testingライブラリを作成した。
- overlayを使うと実際のファイルを仮想的に変更して実行できる
  - ソースコードを汚さずに好きなように変更できる

感想:

overlayすごそう
気になったこと
- mutation testingの使い所について
  - 実際のプロダクションに導入するならある程度テストが整備されたあとにやるのが優先順位としてよい？（Mutation Testingがちゃんと動作することの前提としてある程度のカバレッジが必要そう）
  - あとは不慣れな巨大コードと向き合うときにmutation testを実行してみてテスト品質を把握する、というのもいいかもしれない。
- mutation testing以外のテスト品質保証手法について
  - あまりテストの品質を定量的、機械的に保証する方法をカバレッジ以外に考えたことがなかった。
  - mutation testing以外ではどのようにテストコードの品質や正当性を保証するのがよさそう？
  - たとえばk8sの内部実装などではどのように品質担保しているのか気になった（気になっただけで調べられてはいない）

Goから学ぶGCの仕組みとGreen Tea GCによる次世代最適化

go_poron10さんによる発表。

とても内容が高度で途中でついていけなくなってしまったのでいつかリベンジしたい。

【実装公開】Goで実現する堅牢なアーキテクチャ：DDD、gRPC-connect、そしてAI協調開発の実践

株式会社テレシーのDaisuke Sasakiさんによる発表。

お話したこと:

application層のQuery Serviceからdomain packageへの依存はOKにしている？それとも独自のreturn typeをQuery serviceで定義している？
- 依存OKにしている。
- domain層に以下の2種類があり、それぞれ別パッケージに定義している。
  - commandとqueryの両方から参照される型(tier1)
  - queryからのみ参照される型(tier2)

スポンサーブースで話したこと（一部抜粋）

ANDPAD
- 意外にもGo関連の勉強会でスポンサーブースを出すのは初とのこと。
  - スポンサーブースが抽選なので出展の機会を得るのは簡単ではないらしい。
  - 個人的にはGoに力を入れている会社のイメージを2年くらい前から持っていたので意外だった。
SODA
- CodeRabbitでレビュー負荷を下げている
- PRレビューはチーム全員で分担して特定の誰かに負担が偏らないようにしている

感想

ソロ参加だったがセッションの合間や懇親会でたくさんの人と交流できてとても楽しかった。
- 社外のエンジニアと話せるとかなり刺激&学びになるので今後も機会を見つけていろんな勉強会に参加してみようと思った。
- 勉強会に参加している人は自分の時間を使って勉強会に参加するくらいなのでモチベが高い（あるいは技術が好きな）人が多いというのはあるかもしれない。（考えてみれば当たり前だが実際に行ってみてそのことを実感できた）
今年はCSの勉強³と並行してGoのインプット & アウトプットを頑張っていこうと思っているのでモチベがいい感じに上がった。
- たくさんの強者を見たことで自分が目指す技術力の基準を上げられた感覚がある。
運営、登壇者、スポンサー、参加者の皆様ありがとうございました！

振り返り

セッションの合間は発表者の方に質問するためにウロウロしている時間が長かったのもあり、全スポンサーブースを回れなかった。もうちょっといい感じに時間を使えるとよさそう。（スポンサーブースで各社の方とお話するのは楽しいので全部回りたい気持ち）
懇親会の途中から他の人に自分から話しかけたりできたけど次回は最初からできるともっとよさそう。⁴

おまけ

土日に仙台でKing Gnuのライブがあった影響か、土曜は仙台駅付近のホテルがめっちゃ高かったので福島まで移動して宿泊してgot aことなきした。（ありがとうアパホテル）
福島で食べたお寿司が美味しかった。観光までする（体力的）余裕がなかったのが残念。
なんか新幹線が長かった。

大AI時代になりPRレビュー負担が肥大化しているのでCIで機械的にコード品質を担保するためにLinterを増やそうと思っているため。 ↩︎
https://pkg.go.dev/cmd/compile#hdr-Line_Directives ↩︎
今は（今更ながら）『ネットワークはなぜつながるのか』を読んでいる。 ↩︎
話しかけるときは普通に「お疲れ様です〜」とかでいいんだなという学びを得た。 ↩︎

VimConf 2025 Smallに参加した

Sun, 02 Nov 2025 01:07:08 +0000

2025年11月2日（日）にアキバプラザ・アキバホールで開催されたVimConf 2025 Smallに参加した。

こちらはノベルティ。食器とかお箸はたくさんあっても困らないのでありがたい。

お茶碗
お箸
コースター
巾着
お茶

nvim-cmp retrospective: Exploring Completion and Facing FOSS Challenges

hrsh7thさんによる発表。

Explore Completion

nvim-cmpのcmpって「シーエムピー」って読むんだ（「コンプ」って読んでた）
補完プラグインってめちゃめちゃいろんなケースを考慮して作られているんだな…（全然詳しくないので薄い感想しか出てこない）

FOSS Challenges

大きなOSSプロジェクトをメンテすることになったことでの学びの共有。

もともとはユーザーが求めるものと自分のやりたいことが合致していた。自分がやりたいことをやることで感謝してもらえていた。
- あるときから自分のやりたいこととユーザーの要望が乖離してきた
  - やりたいこと
    - コード品質を上げたい
    - 実験的な新機能を追加したい
  - ユーザーが求めること
    - 安定した動作
- 結果モチベが下がった
- 予期せずプロジェクトが大きくなって責任が芽生えた
- モチベが低いならコミュニティ主導にすればいいのでは？という意見も見るが…
  - 直接話したこともない人をrepositoryに招待するのは危険だと感じた（ユーザー数も多いのでサプライチェーンアタックが怖い）
    - 実際にhrsh7thさんが作ったプラグインのコピープラグインがリリース1週間後にできて、そこにマルウェアが含まれていたことがあるらしい（怖すぎる）
  - 新メンテナのオンボーディングをサポートするのも大変
とはいえOSS開発は楽しい
- nvim-cmpを公開して「これめっちゃ便利だね！」といってもらえたのはとても印象に残っている
- 意図せず人気になってしまうと責任も生じる

感想

たくさんのユーザーを抱えるOSSのメンテ目線のリアルな心境を聞けてよかった。

大規模OSSのメンテナに憧れる気持ちもあるが、楽しいこともあればその分大変なこともあるんだろうな〜などと思った。（それはそう）

とはいえたくさんの開発者、プロジェクトに寄与するような大規模OSSメンテナへの憧れはあるのでコミットしたいOSSが見つかったら挑戦してみようと思う。

And Yet, Vim Survived: Thinking and Seeing in the Age of Code You Don’t Write

Λlisueさんによるコードリーディングに関する発表。

以下の3stepに分けてコードを読む。

Where - Seeing the flow
What - Seeing the structure
Why - Seeing the Reasoning

Where - Seeing the Flow

File Jumps
- gf / gF - open file under cursor
- これ知らなかった。go testの結果を見て失敗しているファイルに飛ぶときとかに便利そう。
Search Jumps
- /や?で検索しnでジャンプ
fall.nvim(fuzzy finder)
- 検索してnで飛ぶのに比べて<c-o>で直前の位置に戻れるので便利
Quickfix
- ]q / [qでジャンプできる

What - Seeing the structure

Window management
- <c-w> + s/v/h/j/k/l
- <c-w> + o: （複数ウィンドウを開いているときに実行すると）現在のウィンドウのみを表示する
  - nativeだと元の状態に戻れない
- goyo.vim¹を使うと<c-w> + oをもう一度実行するともとのウィンドウの状態に戻れる。
file treeは知らないファイルを探すために使う
fuzzy finderは知っているファイルを開くために使う

Why - Seeing the Reasoning

git blameを活用してコードの背景を理解しながらコードを読む

感想

ありすえさんが発表がうますぎてその点でも勉強になった。特にこのあたりのポイントが勉強になった。

論理構造が自然で理解しやすかった
話す速度、スライドの情報量が多すぎなかったのでついていきやすかった
ユーモアを交えていて楽しく聞けた
シンプルに滑舌が良かった（わかんないけどマイクの使い方とかも違うんだろうか。なんかとにかく声が明瞭で聞き取りやすかった）

Beyond Syntax Highlighting: Unlocking the Power of Tree-sitter in Neovim

atusyさんによるtree-sitterに関する発表。

GitHub - atusy/treemonkey.nvim

Contribute to atusy/treemonkey.nvim development by creating an account on GitHub.

https://github.com/atusy/treemonkey.nvim

便利そう

tree-sitterをもっと深く理解したくなった（趣味のプロジェクトでIndianBoy42/tree-sitter-justに依存しているので自分もメンテに参加できるようになりたい）

Designing Repeatable Edits: The Architecture of . in Vim

Satoru Kitaguchiさんによるドットリピートの解説。

.でリピートできる操作
- ノーマルモードから始まってバッファを編集し、ノーマルモードに戻ってくる
- undoツリー上のlast-change nodeを再実行している = 直前の編集チャンクを再適用する
daw, ci"などはリピートできる
Visual modeを含んだ操作などはリピートできない
- Visual modeでは内部的には選択された文字数や行数しか保持されないため

さらっとVimの内部動作を解説していてかっこよすぎた。Vimのコードを読んだのか、Vimの内部構造を解説しているsomethingがどこかに存在するのかちょっと気になった。かなり周到に調査されてスライドを作られてそうな印象を受けた。

便利なプラグインの情報を集めるのも楽しいが、たまにはちゃんとVim自体の機能を学んだ方がかえって効率よく日々の操作を効率化できそうだな〜と思った。

実践Vimを読みたい気持ちが芽生えた。（n回目）

LT

ryoppippiさんの https://github.com/ryoppippi/nvim-in-the-loop がかなり便利そう。

自分のVimの操作履歴を記録し、AIにどのようなキーマップを登録すると無駄な操作を減らせるかを分析させるというものらしい。すごい。

まとめ

学びや刺激を得られたので行って良かった。

発表内容もさることながらプレゼンが上手な方がいたり、（おそらく日本の方だけど）英語が超上手な方がいたりして、その意味でも刺激を得られた。

今回初参加なので他の回との比較はできないが全然Smallな感じがせず、満足感が高かった。（もしやSmallじゃない回は2トラックとかあったりする…?）

運営の皆さん、登壇者の皆さんありがとうございました！

おそらくこれ https://github.com/junegunn/goyo.vim ↩︎

関数型まつり2025に参加した

Sun, 15 Jun 2025 05:00:00 +0000

2025/06/14(土)、2025/06/15(日)に中野セントラルパークで行われた関数型まつり2025に参加した。

筆者はElmやRustの開発体験を気に入っており、Webアプリケーションのサーバーサイドを関数型言語で書くことに興味があったので参加してみた。

関数型言語テイスティング: Haskell, Scala, Clojure, Elixirを比べて味わう関数型プログラミングの旨さ - lagénorhynque/カマイルカさん

lagénorhynque/カマイルカさんによるHaskell, Scala, Clojure, Elixirの紹介と比較を行う発表。

部分適用や関数合成やパイプ演算子などElmで便利だった言語機能を思い出しながら聞いていた。

文法を見ていると、Elmの文法はかなりHaskellに近いようだった。(ML系と呼ばれるらしい)

あとは関数型かつ動的型付け言語の実際のアプリケーション開発での書き味が全然想像がつかないのでちょっとElixirやClojureを書いてみたくなった。質疑応答でも触れられていたが、実際にML系の言語とlispなどの動的型付け言語の関数型言語ではメンタルモデルが違うらしい。

発表の最後に関数型プログラマのメンタルモデルとして以下のようなことを紹介されていて、自分が関数型言語から得た学びと重なる部分が多かった。

適切な制約が解放をもたらす
- 純粋関数を基本にしてコードを組み立てていく
- いつでもどこでも破壊的に更新できるデータ構造は怖いため不変/永続データを基本に
- 適切な型を定義することで不正値を表現不能にしてより型安全に
単純で安定したブロックを基礎に全体を構成したい
- 式思考、宣言的、合成可能

関数型言語を採用し、維持し、継続する - 松澤有さん

Siiibo証券株式会社のCTOである松澤さんによる自社プロダクトのフロントエンド、バックエンドの開発言語として関数型言語(Elm, Elixir)をなぜ採用したのか、そしていかにして維持し、継続しているかについての発表。実は主にこの発表を聞くために関数型まつりに参加したので良い発表を聞けてよかった。

関数型言語を採用し、維持し、継続する

https://zenn.dev/siiibo_tech/articles/adopting-fp-languages

結局はラストマンシップを持って自分がなんとかするという気概が重要だという話が一番印象的だった。これは関数型言語を業務で書いているわけではない自分にも大いに参考になる話だと思っていて、結局どんな技術を採用したかやCTOかメンバーかなどにかかわらず、このラストマンシップを持っているエンジニアが多ければ多いほど開発組織は強固になるんだろうなと思った。

また「アウトリーチを怠らなければ意外と世の中にちゃんと仲間はいる」ということをおっしゃっていて、使用言語がメインストリームであろうとなかろうと外部発信を通してコミュニティに貢献したり認知を獲得することの重要性を改めて感じた。やっていき。

総じて松澤さんのエンジニアとしてのマインドセット的な部分がとても参考になった。

技術的な内容に関しては、コードレビューの話とUpkeepの話が参考になった。

コードレビューに関しては以下のようなことをおっしゃっていて、とても参考になった。特に2番目に関しては、前提としてコード品質を重要視するマインドがチームに装備されている必要があると思っていて、それをどう実現しているのか気になった。

自分がいいと思う技術であっても、それを伝道できなければあとが続かない
チームにとって良いコードとはどのようなものか、ということを感覚、信念として共有できる状態に持っていくことを目指している
人は忘れるし、一度言っただけで身につくことは誰であれないので繰り返し伝えていくことが重要

Upkeepとは維持費の意味で、ここでは依存ライブラリや言語自体のバージョンアップなどのことを指す。こまめにバージョンアップ作業をやっておくことでいざというときに言語やライブラリの新機能をすぐ取り込めたり、巨大なバージョンアップのせいでデグレするリスクを低減できたりと良いこと尽くめだと改めて感じた。（もちろん簡単ではないが）

あとはバージョンを最新に保つという行為に名前をつけたことがなかったのでUpkeepという語で表現するのはいいなーと思った。

以下発表を聞きながら取ったメモ。(発表を聞きつつスライドを見ながら書いたメモなので誤りが含まれる場合があります🙇)

技術選定の方針

CTO, Founding Engineerが技術構成を選ぶにあたっての観点
- まともなモノを継続的に提供するに足る機能があるか
- それを実際につくるヒトを継続的に集められるか
（スタートアップなら）
- （上記2点を説得材料として）カネを集められるか

非メインストリーム言語でどうやっていくか

ElixirやElmはメインストリームと目されているとは言えず、モノ・ヒト・カネの要素を自信を持って揃えるには弱い
とはいえ、良いと感じた技術があって、良いものを作れると検証できたのであればあとは自分がやるかどうかでしかない
- 勝手に機会は降ってこない
勇気と周りを巻き込んで走り続ける力が重要

コードレビューの技術

自分がいいと思う技術であっても、それを伝道できなければあとが続かない
健全で有意義なコードレビューのやり取りがどのようなものか？という経験とその内面化が重要
どういうコードがチームにとって良いコードかを伝道する
- 感覚、信念として共有できる状態に持っていきたい
以下の理由でコードレビューで繰り返し伝えていくことが重要
- 人は忘れる
- 新しい人は入る
- 一度言っただけで身につくことは誰であれ、ない

Upkeep

Upkeepとは維持費の意味で、ここでは依存ライブラリや言語自体のバージョンアップなどのことを指す。
Upkeep恐怖症にならずにこまめにやれる環境をつくる。
(バージョンアップ作業がやりやすいのは言語の大きな加点項目)
Elixirで静的型検査の導入が2022年に発表された
- Upkeepしておくと、こういった新機能もすぐに取り込める

情報収集

言語公式フォーラム, ML, Slack, Discordのウォッチ
- そもそもコミュニティがデカすぎないので最新動向をすべて追うのがそこまで大変ではない
コンパイラ、主要ライブラリのissue trackerも購読する
- チーム内で抱えてる課題と似たような話題も出たりする
Twitter

コミュニティ還元

フォーラムでの質問を見るだけでなく回答もする
- 小さいコミュニティなので自分が第一人者、Front Runnerである可能性もある
国内外の勉強会参加、主催協力も積極的に行う

採用

やれることをやり、アウトリーチもすることが採用に直結する
非メインストリーム言語だとその言語を業務で書くにはそもそも会社の選択肢が少なかったりするので、意外とマッチングしやすかったりもする

続けていく気概

結局大事なのは言いだしっぺがケツを持つ気概があるかどうか
アウトリーチを怠らなければ意外と世の中にちゃんと仲間はいる

産業機械をElixirで制御する - 菊池豊さん

菊池豊さんによる複数の水力発電の制御ソフトウェアをElixirで書いた経験を紹介する発表。

Elixirは書きやすく、コミュニティも盛り上がっているという話を聞いてちょっと書いてみたくなった。

以下メモ。

課題

Python
- 並行プログラミングができなかった
- コンパイラでの支援が期待できなかった
リプレイス先の候補はGo, Rust, Haskell, Erlang, Elm
- Elixir を使うようになった経緯〜電力システム制御の現場から〜

Why Elixir

世俗型関数型言語
- 関数型であることにこだわりすぎず使いやすさがある
- コミュニティも楽しかった
並行性
- アクターモデル
パイプ演算子
パターンマッチ

Elixirにないもの

型
- 静的型解析がほしい

Lean言語は新世代の純粋関数型言語になれるか？ - 井上亜星さん

井上亜星さんによるLean言語の紹介の発表。

この発表でLean言語という言語の存在を知った。純粋関数型言語でありながらforループやwhileループを書けるのはユニークだなーと思った。

What I have learned from 15 years of functional programming - Scott Wlaschinさん

Scott Wlaschinさんによる関数型プログラミングでの学びを共有する発表。

「直和型とレコード型を駆使しドメインモデリングを正確に表現することで保守性が向上するだけでなく動作可能なドキュメントとしても機能する」という話が印象に残った。

前者のメリットは以前から感じていたが、後者の観点はなかったので面白かった。（言われてみればそれはそうという感じだが）

以下メモ。

パイプライン指向で書くことで保守性の高いコードを書くことができる
- 以前はSOLID原則を満たすことを意識しすぎてしまいうまくいかなかったが、パイプライン的な志向でコードを書くことで自然と綺麗なコードを書くことができ、SOLID原則も自然と満たすことができるようになったとのこと
ドメインモデリング
- 直和型をうまく使ってドメインモデルを正確に表現する
  - 保守性が高くなり、バグが減る
  - 実行可能なドキュメントとしても機能する
Railway Oriented Programmingを使うことでエラー処理を伴う処理を保守性高く書くことができる¹

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股健太郎さん

猪股健太郎さんによるF#の言語設計の特徴、設計意図を紹介する発表。

純粋関数型言語なのかと思っていたが、命令形っぽい書き方もできることは知らなかった。他の.NET言語との相互運用性があるのも便利そう。

以下メモ。

概要

OCamlに大きな影響を受けている
金融工学、データサイエンス、科学計算、Webアプリなどで活用されている
F#をJavaScriptにトランスパイルするコンパイラもあり、フロントエンドも書ける

F#の特徴

静的型付けの非純粋関数型言語である。
- デフォルトはイミュータブルだがmutableにもできる
- .NETランタイムは仮想マシン型
  - C#, F#など複数言語を.NETランタイム上で動かす前提で設計されており共通中間言語、共通型システム、共通言語仕様を備える
ホスト環境との相互運用性
- F#で書かれたコードは他の.NET言語から自然かつ安全に利用可能
マルチパラダイム言語
- 関数型プログラミングのパラダイムを核に、オブジェクト指向プログラミングの要素も備える
- クラスや構造体も書ける

言語設計の意図

プログラマーが命令的なコーディングから関数型のコーディングへ移行する際のハードルを下げることを意識した設計になっているらしい。

マイクロサービス内で動くAPIをF#で書いている - ayato-pさん

ayato-pさんによるマイクロサービスの1サービスをF#で書く際の設計や悩みどころを紹介する発表。

ドメイン設計の際に容易にOptionを使わずにenumの別のvariantとして表現する、という考え方はRustなどでも活かせそうだと思った。別の概念であれば別の型として表現するのが大事そう。

以下メモ。

どんなチームで採用したのか
- ペアプログラミングを中心に100人超の組織で開発している
- モノリス -> マイクロサービスの移行をやっている
- マイクロサービスの各APIは多種多様な言語で書かれている
F#導入以前のプロダクトチーム
- JVM系、Elixir, Go, Rust, OCaml, Haskellなども採用
- .NET系の言語は採用されていなかった
どう導入したのか
- システムのコアにいきなり採用するのはリスキーだったのでなにかあってもまずは影響が少ないサブシステムで採用
なぜF#か
- 静的型付け
- シンタックスが簡素
- .NETの資産を活用できる

F#らしさを活かした設計

Optionなどを入れずに判別共用体を使って設計する

e.g. 上場企業と非上場企業を表現するときにisListed: bool, listedAt: Option<DateTime>のように表現するのではなく…

type Company = 
  { id: CompanyId
    name: string
    isListed: bool
    listedAt: Option<DateTime> }

そもそも別のvariantとして表現する

type Listed = Listed of listedAt: DateTime

type CompanyProfile = 
  { id: CompanyId
    name: string }

[<RequireQualifiedAccess>]
type Company = 
  | Listed of CompanyProfile * Listed
  | UnListed of CompanyProfile

スポンサーブース

Jane Streetのエンジニアの方にお聞きしたがJane StreetではフロントエンドとサーバーサイドをOCamlで書いているらしい（！）ブースでお話した方も関数型言語が書きたくて入社したそうで、関数型言語への愛を感じた。

ブースでいただいたノベルティのTシャツもめっちゃOCamlだった。

ノベルティ

入場時にロゴ入りのトートバッグがもらえた。

Nulabさんのノベルティのマイクロファイバークロス。実用的でありがたい。

まとめ

今は業務で関数型言語を使うことはないが、関数型言語の考え方を取り入れることで非関数型言語でもより良いコードを書けるようになると改めて感じた。

個人で初めてオフラインの勉強会/カンファレンスに参加したが普通に楽しかったのでまた行ってみようと思う。

つけ麺情報

二代目えん寺がとても美味しかった。

Elm Patternsでも紹介されていたのを思い出した。改めて読み直してみよう。 ↩︎

勉強会 on blog.kyu08.com

Go Conference mini in Sendai 2026に参加した

【KeyNote】静的解析からみるGoの過去と未来

AI時代のGo開発2026 爆速開発のためのガードレール

Go での並列処理 「最初の一歩」から「次の一歩」へ

Go.1.26のruntime/metricsが便利そうな件（？）

モジュラモノリスにおける境界をGoのinternalパッケージで守る

Go設計思想の深掘り

database/sql/driverを理解してカスタムデータベースドライバーを作る

nilとは何か 〜言語仕様と設計者の葛藤から理解する〜

Who tests the Tests ?

Goから学ぶGCの仕組みとGreen Tea GCによる次世代最適化

【実装公開】Goで実現する堅牢なアーキテクチャ：DDD、gRPC-connect、そしてAI協調開発の実践

スポンサーブースで話したこと（一部抜粋）

感想

振り返り

おまけ

VimConf 2025 Smallに参加した

nvim-cmp retrospective: Exploring Completion and Facing FOSS Challenges

Explore Completion

FOSS Challenges

感想

And Yet, Vim Survived: Thinking and Seeing in the Age of Code You Don’t Write

Where - Seeing the Flow

What - Seeing the structure

Why - Seeing the Reasoning

感想

Beyond Syntax Highlighting: Unlocking the Power of Tree-sitter in Neovim

Designing Repeatable Edits: The Architecture of . in Vim

LT

まとめ

関数型まつり2025に参加した

関数型言語テイスティング: Haskell, Scala, Clojure, Elixirを比べて味わう関数型プログラミングの旨さ - lagénorhynque/カマイルカさん

関数型言語を採用し、維持し、継続する - 松澤 有さん

技術選定の方針

非メインストリーム言語でどうやっていくか

コードレビューの技術

Upkeep

情報収集

コミュニティ還元

採用

続けていく気概

産業機械をElixirで制御する - 菊池 豊さん

課題

Why Elixir

Elixirにないもの

Lean言語は新世代の純粋関数型言語になれるか？ - 井上亜星さん

What I have learned from 15 years of functional programming - Scott Wlaschinさん

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股 健太郎さん

概要

F#の特徴

言語設計の意図

マイクロサービス内で動くAPIをF#で書いている - ayato-pさん

スポンサーブース

ノベルティ

まとめ

つけ麺情報

Go での並列処理「最初の一歩」から「次の一歩」へ

nilとは何か〜言語仕様と設計者の葛藤から理解する〜

Who tests the `Tests` ?

関数型言語を採用し、維持し、継続する - 松澤有さん

産業機械をElixirで制御する - 菊池豊さん

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股健太郎さん