upinetree's memo

Web系技術の話題とか。Qiitaも合わせてどうぞ (http://qiita.com/upinetree)

Ruby25の聴講メモ

昨日(2/24)、Ruby25に参加してきました。 最初は小さくお祝いするのかなと思ってたら、予想以上に大きなカンファレンスでびっくりしました。参加できてよかった。 いろいろあって最近仕事でRubyをあまりキメられていないのですが、やっぱ良い言語で良いコミュニティだなと再確認しました。 また、久々に会えた方々とお話できて良かったです。

以下、聞いた講演のメモです(まとめられてないです)。 聞き間違えや解釈の違い等あるかもしれません。

高橋さん「Rubyの1/4世紀」

  • Ruby」の頭文字が大文字なのは、連載「ちょーわかりやすい Perl & Ruby 入門」で「ruby」のように小文字だと「Perl」との並びが悪いので大文字になったらしい
  • かつて主要なパッケージ管理にはRPA, RubyGemsがあり互換性なかった。RailsがRubyGmesを採用したことで普及
  • rubygems.org は Gemcutter が前身
  • パッケージ管理やbundlerなど、Rubyのエコシステムの構築をRailsがリード

Matz「Ruby after 25 years」

  • ソフトウェアの誕生には物理的実体がない。概念的
    • Rubyという概念とは、名前?
    • Rubyという名前が生まれたときが、Rubyという概念の誕生
  • 未来の話してと言われたけどむずかしい。当たるも八卦当たらぬも八卦

この25年をふりかえる

  • プラットフォームとしてのOSはほぼOS。WindowsすらWSL
  • CPUもあんまりアーキテクチャが変わらない
  • プラットフォームは多様性が減少する一方
  • コンピュータの普及、性能の向上、モバイルの台頭
  • サーバサイドでなんでもやる時代ではなくなった。モバイルアプリ、SPA
  • トレンドの変化がある
  • 変化の傾向として、ものすごくスケーラブルに、分散処理

これを踏まえて未来のRubyは?

  • Rubyのコアは変わらないのでは
    • チューリング完全性という最低限は備えているので劇的な変化は必要ない
    • 文法が大きく変わったらRubyとはいえない
  • プログラミング言語のテーマは生産性の向上
    • より早くより簡潔に書ける、頭の中を直接コンピュータに伝えられる
    • 優れた抽象モデルが提供できる
    • 保守性がある
  • 現在のRubyは小さなチームではじめられる

近未来のRuby(Ruby3)

  • 高速、分散、解析
  • Ruby 3x3
  • やればできるゴールではなく、できるかもしれないゴール、わくわくさせるようなことを提示するのが私の役割
  • 言ってみるもんで、案外できそうなところまできた
  • 2020年目標(約束はしない)
  • 過去に学んで、断続的な変化はしない。Ruby3は単なるラベルにする

その先のRuby

  • インタラクティブプログラミング
    • 入力したら警告がポップアップで出てくるみたいな感じ
    • 静的解析技術、実行時プロファイリングなどの発展系
    • 賢いテディベア(テディベアプログラミング)がコンパイラについてくるなど
  • 分散技術の発展とともに、分散処理の抽象化、スケーラブルなアーキテクチャが必要になってきている
    • Webもいい線行っているが万能ではない
    • FaaSが現在では近いと予想
    • Rubyでは、Guildのその先ができるといい
  • 非均質的計算環境対応
    • BigLITTLE、GPGPU
    • FPGAもある種の非均質的環境
    • どう抽象化し、同じシステムとして扱えるようにする?

むすび

  • 人類は25年ではあまり変わらないが、文化は変化する
    • 「コンピュータは楽しい」があたりまえになってほしい
    • 思考ツールとしてのRuby、人間のためのRubyにしていきたい
  • 最大の目標は「プログラミング言語サバイバル」
    • 生き残るために価値、楽しいプログラミングを提供し続ける

松田さん「Ruby on Ruby on Rails

  • RailsRubyの良さを伝えるためのインフラ
  • 先週くらいから6.0を開発中
  • 5.2はコミッタの中では終わったRails
  • これからもRailsは変わり続け世の中を変え続けるので必死こいてバージョンアップして下さい

近藤さん「 RubyとInfrastructure as Code、そして大規模インフラ」

  • Rubyはどう Infrastructure as Code と関わっていくか
  • RubyDSLを作るのに向いている
    • なのでDSLを採用したプロダクトが多い(Cheff, Itamae, Serverspec...)
    • 特にConfigurationのツールが多い
  • 直近のインフラコードの潮流
    • マイクロサービス、コンテナ化、サーバレス
    • ウェブインフラの大規模化、アプリの複雑さが背景
  • 支援団体 Cloud Native Computing Foundation(代表プロジェクト: Kubernetes)
    • この団体の支援プロジェクトの中で、Ruby製は1つだけ(最多はGo)
    • まだクラウドインフラ分野に進出の余地がある
    • mrubyで実現する未来を作っていきたい

石井さん「 mruby、今IoT、組込界隈でこう使われています、最新事例紹介!」

  • 組み込み技術者不足
  • webの人にも組込してもらえたら良いよね、ということでmruby
    • ruby, mruby, mruby/c で世の中のなんでも作れる
    • 試作しやすさ、文字列処理のしやすさ
    • ただし弱点として何msec以内に〜をしなければ、というのを保証できない
    • それ以外のエンタメとかいろいろな面で利用価値がある
  • しかし、なかなか使ってもらえなかった
    • 組み込みは一回製品を出荷したら変更できないのですごく慎重
  • 軽量Ruby 普及・実用化促進ネットワークで技術情報を提供中
  • これからのmruby
    • Ruby2.0をキャッチアップ(現在1.9ベース)
    • グローバル会議やりたい(来年)

田籠さん「Data Processing and Ruby in the World」

データ処理のステップは collect => summarize => analyze => visualize

この世界でのRuby

  • collect
    • fluentd
    • logstash (JRuby)
    • embulk
  • summarize, analyze
  • Rubyを使ったサービス
    • TD
    • Repro
    • FlyData

という感じになっている

これからの機械学習系プロジェクト

他の言語ではすでに実装されているものもあるが、全体のエコシステムで不自由なく使えることがとても大事。

Matz & Miyagawa 未来を語る特別対談

  • MJITは最初はオプトインで提供
    • 今後の性能特性を見てデフォルトにするか判断する
    • (2.6-preview1 がさっきでた)
  • steepによる型推論、別ファイルとしての型情報
    • TypeScriptの型定義ファイルみたいな感じ
    • 型を指定したときの安全感は別の気持ちよさがあるのでは
  • 言語のシンタックスは互換性を保つことを考えると厳しい。もう限界が来ている
  • Ruby3には間に合わないが、パッケージ、ネームスペースの再考したい
    • JSみたいにrequireの返り値がモジュールとか(現在Rubyはtrue)
    • ちなみにrequireは複数の引数を受け取れるが、全部のrqeuireをトランザクションで保証するわけではない