---
title: "再一次熱血 - RubyKaigi 2023"
date: 2023-05-17T00:00:00+08:00
publishDate: 2023-05-17T00:00:00Z
lastmod: 2023-05-17T15:13:46+08:00
tags: ["Ruby","RubyKaigi","心得","經驗","日本"]
toc: true
permalink: "https://blog.aotoki.me/posts/2023/05/17/enthusiasm-again-after-rubykaigi-2023/"
language: "zh-tw"
---


這幾年因為疫情的關係，大家都有不少生活上的改變，也因此我有四年沒有辦法親自到日本參加 RubyKaigi 這個對 Ruby 工程師來說最盛大的研討會。

終於在今年，我到日本重新感受了一次 Ruby 社群的活力。

<!--more-->

## 疲勞{#tired}

四年的時間，已經足夠讓我從工程師成為主管、體驗了一次失敗的創業、到外商工作甚至轉換工作主要使用的程式語言，加上疫情的影響，可以說是「心很累」

另一方面，從大學畢業、退伍到參加幾次 RubyKaigi 的時間，也開始從體力最好的 20 幾歲，開始要進入 30 歲出頭，加上確診後總覺得比以往更容易疲勞，身心上都處於一種疲勞的狀態。

然而，即使是日本也期待了 RubyKaigi 許久，因此這一次大家也是用盡全力地讓這場活動盡可能的盛大，將近 1200 人的參與者與 30 個贊助商攤位，即使平常不愛社交能量不足的自己，也會想看看有什麼不同。

## 新方向{#new-direction}

回到 RubyKaigi 的活動本身，這次的議程也和過去幾年不太一樣。從 Ruby 3 的推出開始，原本的「三倍速」目標已經達成，因此整個社群開始朝向一個新的方向努力。

相較其他語言，Ruby 一直以來都是以穩定的腳步在前進，也因此缺少了不少其他語言應有的功能。在過去幾年，開始有 WebAssembly 和 JIT（Just in Time）等等其他語言應有的功能被補上，到了今年，社群開始回顧 Ruby 本身能怎麼改進。

其中 Parser 也被提出來重新審視，現在的 Ruby Syntax（語法）需要使用相當複雜的方式來解析，因此是 Ruby 原始碼中數一數二繁重的檔案，也因為這樣複雜的語法特性才讓我們能用許多彈性的方式來撰寫程式。

正因如此，今年有許多議程將目光放在 Parser 上，開始思考能用怎樣的方式進行改進。

## 開發體驗{#develoepr-experience}

近年在 Ruby 的開發體驗也是一個相當被關注的議題，像是 [debug](https://github.com/ruby/debug) 的推出，讓一直以來缺少 debugger 的 Ruby 語言能更容易找出錯誤，或者型別的取捨也達成了以「補充文件」的方式的共識。

今年的 debug gem 議程是由現在任職於 Shopify 的台灣人 [Stan Lo](https://twitter.com/_st0012) 分享，在年初跟他聊天的時候也感受到他對開發者體驗的熱情，自己也在去年利用 debug gem 找到一個 [ViewComponent](https://viewcomponent.org/) 的問題，雖然還不習慣使用仍然能感受到巨大的幫助。

在型別的議題上，最早是由 Stripe 提出的 [sorbet](https://github.com/sorbet/sorbet) 作為前導，這幾年我一直都覺得 Ruby 官方所推廣的 [rbs](https://github.com/ruby/rbs) 沒有 sorbet 那麼好用，然而今年的議程也讓我注意到經過這幾年的努力 rbs 跟 [steep](https://github.com/soutaro/steep) 的搭配（型別檢查工具）已經達到可以使用的程度。

Ruby 社群一直以來有有趣的地方就是心態非常開放，許多社群努力的工具最終都會被 Ruby 整合進去讓整個語言更容易使用，像是 Shopify 的 YJIT 給出了很棒的 JIT 機制後，也啟發 RJIT 的實現，在不依賴 Rust 的狀況下獲得比原本 MJIT 更好的成果。

## 投入熱情{#enthusiasm}

能在 RubyKaigi 發表成果是一件非常榮耀的事情，這幾年我除了休息的原因外，似乎也沒有非常投入在什麼對 Ruby 社群有貢獻的地方，然而再次踏上日本的旅程中，似乎找到了方向。

如同我在 RubyKaigi 第一天在社群網站上所說，這些能夠站在台上的講者，並不單純只是「能力很好」更多的是他們投入了數年的時間在同一個主題，也很清楚自己該努力的方向。

前面提到我跟 Stan 聊天時，我們都對開發者體驗（DX，Develoepr Experience）有著不同的想法，他體現出來的就是對 debug、irb、sentry-ruby 這類幫助開發更順利的工具所做出貢獻，而我似乎沒有太過明確的定位。

然而，回顧我所投入的主題，會發現往往跟「讓 Ruby 可以運行」有關。不論是近期的 [boxing](https://github.com/elct9620/boxing) 讓製作 Ruby 的容器更容易之外，也可以看到我不斷的實驗讓遊戲、WebAssembly、ESP8622（微控制器）、Raspberry Pi 等等不同的環境可以運行 Ruby，雖然這些題目最後都在日本的大神努力下更完整的實現。

那麼，在我工作中主要的語言轉換為 Golang 後，我該做的事情是什麼呢？似乎沒有變化，就是讓 Golang 可以更加簡單的能夠運行 Ruby，僅此而已。

> Golang 目前可以利用 CGO 讓 mruby 被引用進去，目前相關的專案已經停止維護，我的新計畫是以純 Golang 實作 mruby 虛擬機器，讓使用更加容易。