基于 Dwayne Reeves的博客文章介绍了HSL ，似乎主要的优点是数组是本机值，而不是对象.这有两个重要的后果:

Based on Dwayne Reeves' blog post introducing HSL, it seems that the main advantage is the fact that arrays are native values, not objects. This has two important consequences:

1. 对于用户而言，值通过参数交叉时的语义是不同的.对象作为引用传递，并且变异会影响原始对象.另一方面，值是在传递参数后在写入时复制的，因此没有引用(最终将完全在Hack中被禁止)，被调用者无法更改调用者的值，但更为严格的

1. For users, the semantics are different when the values cross through arguments. Objects are passed as references, and mutations affect the original object. On the other hand, values are copied on write after passing through arguments, so without references (which are finally to be completely banned in Hack) the callee can't mutate the value of the caller, with the exception of the much stricter inout parameters.

本文引用了可变容器(向量，集合等)的不变性，并且通常指出了共享的可变状态耦合如何将功能紧密地结合在一起.本文中讨论的健全性问题有些争议，因为还有 也是不可变的对象容器(ImmVector，ImmSet等)，尽管由于这些接口是在用户区中编写的，所以方差将函数类型签名放入了严格的约束.与此有明显的区别: ImmMap< Tk，+ Tv> 在 Tk 中是不变的，仅是因为(function(Tk):Tv)吸气剂.同时，由于固有的针对写时复制的突变保护， dict< + Tk，+ Tv> 在两个类型参数中都是协变的.

The article cites the invariance of the mutable containers (Vector, Set, etc.) and generally how shared mutable state couples functions closer together. The soundness issues as discussed in the article are somewhat moot because there were also immutable object containers (ImmVector, ImmSet, etc.), although since these interfaces were written in userland, variance boxed the function type signature into tight constraints. There are tangible differences from this: ImmMap<Tk, +Tv> is invariant in Tk solely because of the (function(Tk): Tv) getter. Meanwhile, dict<+Tk, +Tv> is covariant in both type parameters thanks to the inherent mutation protection from copy-on-write.

对于编译器，可以快速分配静态值，并且可以在服务器的整个生命周期内保持不变.另一方面，对象通常具有任意复杂的构造例程，并且看来收集对象不会是特殊情况.

For the compiler, static values can be allocated quickly and persist over the lifetime of the server. Objects on the other hand have arbitrarily complicated construction routines in general, and the collection objects weren't going to be special-cased it seems.

我还要提到的是，在大多数使用情况下，即使在代码样式方面，差异也很小:例如-> 参考链可以直接替换为 |> 管道运算符.在特权标准功能"之间不再存在边界.以及针对集合类型的自定义用户功能.最终，集合类型当然是 final ，因此它们的客观性质仍然不能为最终用户提供任何实际的分层或多态优势.

I will also mention that for most use cases, there is minimal difference even in code style: e.g. the -> reference chains can be directly replaced with the |> pipe operator. There is also no longer a boundary between the privileged "standard functions" and custom user functions on collection types. Finally, the collection types were final of course, so their objective nature didn't offer any actual hierarchical or polymorphic advantages to the end user anyways.