与许多其他人一样，我总是坚持认为“对于Ruby来说，纯粹的编译器永远不会存在，因为这种语言对于静态编译器来说太过动态了。”
但我最近偶然发现了这些：
The Crystal programming language at GitHub
这两个项目似乎都非常有趣。它们可以为我们提供本机编译语言的速度（以及编译语言的商业需求，混淆代码），同时保留Ruby的所有（或大部分）优雅和灵活性。添加一个好的支持库（或者更有可能是访问现有C ++库的可能性），你可以很容易地理解为什么这些东西会很有趣。
有人试过Crystal语言吗？ （我还没有，因为ruby-llvm的编译问题）
他/她对此感觉如何？
您是否认为，鉴于这些设计选择，实际上是否可以为Ruby开发本机代码（机器代码）编译器（在合理的时间内合理努力）？它会有意义吗？
答案 0 :(得分：42)
我是水晶的开发者。目前并非所有内容都是通过项目符号点列表实现的。事实上，课程刚刚开始实施。
我真的很喜欢它的想法。但我需要更多地思考如何实现它。而且我还需要更多时间，呵呵。
第二篇文章有一个完全不同的方法，因为它不会引入一种新语言：它只是尝试编译Ruby的一个子集，或者可能会被编译为本机代码但仍然允许一些动态的性能成本（几个月前我和那篇文章的作者谈过。）
我对这两种方法的感觉：我真的可能会发生这种情况。我们需要一种快速的语言，优雅，可读，使用语法和库（就像Ruby提供的那样）。
答案 1 :(得分：12)
我是Foundry的开发者;第二篇文章是我的。
关于同一主题的最新文章将是"A language for embedded developers";或者您也可以通过订阅foundry-lang.org来跟踪开发进度。
但请注意，我的项目是商业的，（至少在最初阶段）不是开源的，主要侧重于嵌入式开发。当然，你仍然可以在台式机或服务器上使用它。
我也是ruby-llvm维护者之一;请在project page上报告您遇到的问题。