文章讨论了不同编程语言在处理包含表情符号的字符串长度时的差异，指出JavaScript中"🤦🏼‍♂️".length == 7是合理的，而Python 3的len("🤦🏼‍♂️") == 5则显得不够实用。作者认为Swift的方法并非最佳，而Python 3的处理方式则是最不理想的。文章旨在说明不同语言在处理Unicode字符串时的设计选择，不应简单嘲笑JavaScript的处理方式。

文章主要讨论了不同编程语言在处理字符串长度时的不同方式，特别是涉及Unicode字符和表情符号时的情况。作者通过比较JavaScript、Python、Rust和Swift等语言在处理字符串长度时的表现，揭示了不同语言在处理Unicode字符时的差异。

首先，文章指出JavaScript在处理包含表情符号的字符串时，.length属性返回的值通常大于1（通常是2），这导致一些人认为JavaScript在处理Unicode时存在问题。然而，作者认为这种批评并不完全合理，因为不同语言在处理字符串长度时有不同的设计选择。

接着，文章通过具体代码示例展示了不同语言在处理字符串长度时的表现。例如，在JavaScript中，"🤦🏼‍♂️".length返回7，而在Python 3中，len("🤦🏼‍♂️")返回5，Rust中则返回17。这些差异源于不同语言对Unicode字符的编码方式不同。JavaScript使用UTF-16编码，Python 3使用UTF-32编码，而Rust使用UTF-8编码。

文章还提到，Swift在处理字符串长度时采用了“扩展字形簇”（extended grapheme cluster）的概念，这使得"🤦🏼‍♂️".count返回1。扩展字形簇是Unicode标准中定义的一个概念，用于表示用户感知为一个字符的多个Unicode标量值的组合。

最后，文章讨论了不同语言在处理字符串长度时的设计选择，并指出没有一种“最佳”的方式来处理字符串长度。每种语言的设计都有其合理性和适用场景。例如，Rust选择在字符串创建时存储UTF-8编码的代码单元长度，而Swift则更倾向于使用扩展字形簇作为字符串长度的计算方式。

总的来说，文章通过比较不同编程语言在处理字符串长度时的表现，揭示了Unicode字符处理的复杂性，并指出不同语言的设计选择都有其合理性和适用场景。

评论主要围绕Unicode字符串长度的复杂性和不一致性展开，以下是主要观点总结：

1. Unicode字符串长度的复杂性：

   • 评论2指出，字符串长度在不同编码（UTF-8、UTF-16、UTF-32）和扩展字素簇（Extended Grapheme Clusters）中表现不同，导致不一致性。
     • "We’ve seen four different lengths so far..."
     • "We would not have this problem if we all agree to return number of bytes instead."
   • 评论12提到，扩展字素簇虽然从用户角度更合理，但需要存储整个字符数据库，且可能随Unicode版本变化，导致兼容性问题。
     • "Therefore, people should use codepoints for things like length limits or database indexes."
     • "If a newer Unicode version suddenly defines some sequences to be a single grapheme cluster... what would I do?"

2. 编程语言对Unicode的支持：

   • 评论16批评Python 3对Unicode的支持不佳，认为其处理方式甚至不如将字符串视为原始字节的语言。
     • "Python does an exceptionally bad job."
     • "After dragging the community through a 15-year transition to Python 3... we ended up with support that's worse than in languages that simply treat strings as raw bytes."
   • 评论14赞扬Raku语言在处理字符串长度时的清晰性，认为其他语言应借鉴其设计。
     • "Worth giving Raku a shout out here... methods do what they say and you write what you mean."

3. Unicode的解析与兼容性问题：

   • 评论18认为Unicode的演变使其无法向前兼容地解析为扩展字素簇，建议需要一种新的编码方式。
     • "It seems to me that the evolution of unicode has left it unparseable... in a forwards compatible way."
     • "Then the original sender determines what is a grapheme, and if they don’t know, who does?"
   • 评论9批评UTF-8解析的复杂性，甚至建议回归ASCII的简单性。
     • "But the gymnastics required to parse UTF-8 correctly are truly insane."
     • "Maybe we should just to go back to the simplicity of ASCII until we can come up with with something better?"

4. 实际应用中的问题：

   • 评论6提到，由于切割表情符号导致渲染失败的bug，反映了Unicode处理的实际问题。
     • "I learned this recently when I encountered a bug due to cutting an emoji character in two making it unable to render."
   • 评论17指出，即使是Google Docs也未使用扩展字素簇计数，导致字符计数不准确。
     • "I have noticed that even Google Docs doesn’t seem to use grapheme counts and will produce larger than expected counts for strings of emoji."

总结：评论普遍认为Unicode字符串长度的处理复杂且不一致，不同编程语言的支持也存在差异，Unicode的解析和兼容性问题给实际应用带来了挑战。