红宝石3号聚会/黑客挑战摘要

尼耳多
91 阅读6分钟

你们中的许多人可能没有意识到，但Ruby 3不仅是一个遥远的、抽象的概念。Ruby 3是一个已经相当先进的过程的最终目标。

本周我有机会参加了由Miles Woodroffe和Cookpad在布里斯托尔组织的一个非公开的Ruby 3聚会/黑客挑战。

像这样的活动的目的是将Ruby核心团队成员以及许多著名的Ruby社区开发者和演讲者聚集在一起，介绍Ruby 3的工作进展，其他Ruby的改进，收集反馈，交流想法和学习。

人们认为Ruby是一种与日本以外的社区分离开发的语言。我很难对此发表意见，因为即使是现在的情况，要跟踪所有的变化也不是那么困难。然而，我确实相信，像在布里斯托尔举行的聚会将社区联系在一起，特别是因为他们确实将核心的Ruby开发者与正在构建Ruby生态系统的人联系在一起。

在这篇文章中，我将尝试为你介绍一些发生的事情，以及我对Ruby 2.7和Ruby 3状态的一些看法。

组织机构

本次活动分为三个主要部分。

  • 工作坊--用当前所有的开发改进来破解Ruby 2.7，并修复或详细回顾其中的一些内容
  • 演讲 - 来自Ruby核心团队成员的演讲，介绍他们最近与Ruby未来相关的工作。
  • 讨论 - 所有来宾之间的公开讨论

研讨会

你有没有和Matz玩过 "抛接球"？）

我不知道#rubyhackchallenge是一项运动✨ ⚾🧢 #ruby3 pic.twitter.com/hwMCR5qu9O

- Benoit Benoit (@Benoit_Tgt)2 lipca 2019

工作室的形式是相当开放的。你可以选择你是否愿意玩新功能，或者宁愿花时间与核心成员讨论选定的改进。

我决定花时间研究方法#method Method 对象的优化问题。我以这样的方式做了很多#method 相关的流水线操作。

class TrBase
  def self.call(input)
    data = input.dup
    data[data.keys[0] + to_s] = data.delete(data.keys[0])
    data
  end
end

A = Class.new(TrBase)
B = Class.new(TrBase)
C = Class.new(TrBase)
D = Class.new(TrBase)

stream.each do |data|
  data
    .freeze
    .then(&A.:call)
    .then(&B.:call)
    .then(&C.:call)
    .then(&D.:call)
end

然而，没有多少人知道，在引擎盖下，当数据集足够大时，上述代码可能每秒创建数十万个对象。我担心，有了新的语法糖，人们会更经常地使用这种方法，因此有时会因为不了解引擎盖下发生的事情而使他们的代码变得很慢。

我一直在与Koichi-san合作，为 "点冒号 "方法引用引入内部方法缓存。我很快就会写一篇关于这个问题的单独博文，并解释为什么最后它没有被合并到Ruby中，以及我们可以做什么来解决这个问题。

除此之外，我一直在和Anton Davydov一起研究干式监视器，因为能在同一时间、同一地点见到他和Solnic真的很难得。我们做了很多概念性的工作，这些工作将使我们在未来能够运送一些令人兴奋的功能。

演讲

有四个演讲。

  1. Matz的主题演讲
  2. 远藤祐介（Mame）的Ruby中的类型
  3. 笹田浩一的《Ruby的并发性改进和未来的并发性模型
  4. Ruby 2.7中的压缩GCby Aaron Patterson

人们可能会说 "没有什么新东西"。许多展示的东西在之前的各种会议上已经宣布或介绍过了。不同的是，核心成员有更多的时间来回答问题和参与讨论。

由于我在Castle所做的工作类型，以及我的OSS，我对Ruby的新并发模型特别感兴趣。

Koichi先生介绍了一些概念，如自动纤维、小线程、公会/隔离，以及关于在何处和何时使用它们的想法。如果至少有一部分的解决方案能在Ruby 3.0中实现，我们可能会看到许多东西的性能得到显著提升。

讨论

以下是我认为重要的讨论内容。

  • Matz意识到了 "流水线操作符问题"。
  • Matz称其为链式运算符，他正在考虑要么改变语法，要么完全推迟这一变化。
  • Matz不认为语言中表达相同概念的更多方式会增加其熵。
  • Matz反对通过 "gemifying "非语法的潜在不相容性来弃用（参见ERB新旧API）。
  • Guilds API并不稳定；因此，目前还没有办法用线程来模仿这一特性。
  • Ko1的Guilds API Ruby分支不可行，而且Guilds的进展也不是太快。
  • 在内存分配方面，全局对象空间是Guilds的一个问题。
  • 如果不进行转储，就没有办法评估内存碎片。Noah Gibbs提出了一个解决方案，可以在运行时对该值进行廉价估计。然而，我还没有验证他的想法。
  • 渐进式写入障碍的插入应该可以进一步优化内存，同时保持与C API的兼容性。

总结

值得注意的是，使Ruby成为一个高效工具的原因之一是库和预制的解决方案的可用性。

像这样的聚会使库的创建者和维护者能够对当前和未来的功能开发和改进有更多的了解，这些功能和改进可以用来建立更多令人惊叹的库。

目前，我只对公会的API还没有准备好的事实感到失望，甚至作为一个概念。我理解其中的原因，但是拥有 "或多或少 "冻结的API将允许我用本地线程来模仿它，并使像Karafka这样的东西 "准备好 "™。如果没有这样的信息，没有一个lib构建者知道该期待什么。我确实担心，如果不提前介绍公会，我们最终可能会在Ruby 3中加入一个功能，而这个功能在很长一段时间内不会被大多数主要的lib支持。

在这次聚会之后，我也不再像Paweł Świątkowski那样担心了。

例如，他所说的NIH综合症在我看来更像是一种对构建必须长期维护的东西的谨慎态度（了解Matz的方法--可能是永远）。

语言中不应该有任何一个组件不能被至少一个核心成员所调试或修复。这适用于像GC、内存分配器这样的东西，也适用于任何像模式匹配这样的新东西。最后，谁会想要那些可能破坏Ruby但又无法快速修复的东西呢？这同样适用于链运算符（在我看来，它是无用的）。

Ruby正走在一条好的道路上，成为比它现在更多的东西吗？肯定是的，然而，这是一条崎岖不平的道路，在地平线上有许多挑战。

The postRuby 3 gathering/hack challenge summaryappeared first onCloser to Code.

avatar
文章
阅读
粉丝