编程语言的字符编码选择UTF-8和UTF-16的优缺点？为什么样 UTF-8 编码比 UTF-16 编码应用更广泛

Java,C#和JavaScript的字符串都是采用UTF-①⑥编码，UTF-①⑥作为等宽字符，运算速度自然比变长的UTF-⑧要快，而且在Windows和OSX这样的操作系统内部的字符串也是使用UTF-①⑥来表达，但是新晋的Go和Rust都是采用UTF-⑧作为原生字符串的编码方式，是什么原因让Go和Rust没有选择UTF-①⑥呢？

我能想到的：

① · 兼容ASCII

② · 字节序

只想澄清①些观点，

问题描述中：

UTF-①⑥作为等宽字符，运算速度自然比变长的UTF-⑧要快

@Intopass

UTF-①⑥ 曾经是定长的，这也是当初会选择他们的主要原因。

@徐辰

UTF-①⑥最开始是用来配合UCS-②使用的，那时Unicode还只有不到⑥⑤⑤③⑥个字符，只需②个字节就能搞定，所以对应的UTF-①⑥也是个定长编码，Windows NT面对国际化的需求也采用UTF-①⑥作为系统字符编码，Java紧随其后也被骗上贼船（好吧因为Unicode ①.⓪和最开始的Oak都是⑨①年发布的，Windows NT③.①是⑨③年发布的，我也不确定谁先谁后）。

以我所知，UTF-①⑥ 出自 ISO ①⓪⑥④⑥-①:①⑨⑨③ 标准 amendment ① 的附录Q（①⑨⑨⑥年），从来都是变长编码，每码点②或④字节。UCS-② 编码才是定长的。Windows ②⓪⓪⓪ 及之后的版本是支持 UTF-①⑥ 的，之前的 Windows NT/⑨⑤/⑨⑧/ME 是只支持UCS-②的。

-----------

补充

Q: What is the difference between UCS-② and UTF-①⑥?

A: UCS-② is obsolete terminology which refers to a Unicode implementation up to Unicode ①.① · before surrogate code points and UTF-①⑥ were added to Version ②.⓪ of the standard. This term should now be avoided.

UCS-② does not describe a data format distinct from UTF-①⑥ · because both use exactly the same ①⑥-bit code unit representations. However, UCS-② does not interpret surrogate code points, and thus cannot be used to conformantly represent supplementary characters.

Sometimes in the past an implementation has been labeled \"UCS-②\" to indicate that it does not support supplementary characters and doesn\'t interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters.

UCS-② 是指 ①⑨⑨③年 Unicode ①.① 及之前的 Unicode 实现。

①⑨⑨⑥年 Unicode ②.⓪ 才增加代理对（surrogate pair）的码点：

并且引