可是 Ruby 代码一般不是右边那么写的...

def sum x, y=nil
  x.to_i + y.to_i
end

要定义三个方法，也是醉了，要实现同样的功能可能要写很多重复代码。而且 Ruby 也不会写那么啰嗦的。

@chenge 估计 ruby 的改进会朝着这个方向走，但是用不用这种方式难说。ruby3.0 开始字符串默认都会成为 immutable，如果再加上可选的类型或者类型推断，不仅仅可以有效减少 bug，还能大幅度提高执行速度。Crystal 需要disallowing certain dynamic aspects of Ruby，所以即使 rails 能在上面运行，也需要大量修改，估计不太可行。

建议各位再去看看 rubykaigi 2014 中 matz 的 Keynote Coming soon

#2 楼 @rubyu2 个人持不同意见。我是支持左边的写法，论点如下：

1. 我觉得拆成三个函数这样语义更细化，也更清晰了。这样调试起来会更方便，假设 sum(x : Int32) 错了，我们只调试这个方法即可，不影响其它方法。

之前还在说 Ruby 怎么为 foo(*bar) 定类型呢（详见：https://ruby-china.org/topics/25428#reply4），结果 Crystal 说我们用多态吧，2333。（BTW，Crystal 能不能把模式匹配搞进去啊？）

1. 以前是要自己做参数匹配，现在把这个工作交给编译器/解释器了，很好。（想想，虽然自己做参数匹配固然更加灵活，但每个函数都做，岂不是又 Repeat Yourself 了么？）

其实我想听听 @luikore 的深入见解。

用 Crystal 写代码的话开发时间会增加三倍

原来还能重载。。。这比 Ruby 省事太多了。。。

Ruby 的优点就是把珍贵的人工时间移交给电脑。 能花 1000 美金解决的电脑配置问题，绝对不要用 70000 美金来解决人工不够的问题。

#5 楼 @deathking 是好是坏得看使用者... 如果重载的各个函数定义在了不同的地方会不会坑？

class A
  def foo x
    x
  end
end

module B
  def foo x, y=nil
    y
  end
end

class C < A
  include B
  def foo x
    x
  end
end

Crystal 应该是限制最宽松的静态语言了... 但要成功，得把 method name resolution 的规则做好，和加上 pattern match

用了这多语言，最爱 Ruby！希望 Ruby 底层做些优化，让我们的思维继续欢快地驰骋！

这个语言是编译型的