> They did it again to LSP, and that was in 2016.

That one is explainable by the fact that it was developed for VS Code, a typescript/javascript project. Javascript uses UTF-16 for strings (for historical reasons unrelated to Microsoft, though they are the same reasons that made MS use UCS-2 during the same time period).

▲

genxy 2 days ago | parent | next [-]

https://en.wikipedia.org/wiki/UTF-16

> UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.

▲

tredre3 2 days ago | parent [-]

Absolutely, UTF-16 is bad and inexcusable in most contexts. Perhaps you misinterpreted my comment or I wasn't expressing myself properly.

I was trying to say: If all the components in your stack are javascript-based, it makes sense that your RPC-API would also use UTF-16. It wasn't Microsoft pushing it for historical Windows reasons as GP implied, it was dictated by a JS stack they chose but didn't create.

▲

genxy 2 days ago | parent [-]

I understood, I was just providing context. Windows, JavaScript, Java are all UTF-16. 65k characters is all you need.

	▲	noosphr 21 hours ago \| parent [-]
		I always thought the js libraries throwing emojies around was stupid. Then I finally sat down to understand enough JS for LLM slop and the having rockets all over the place wasn't just cringe but the quickest way to show you handled utf 16.

▲

Someone 21 hours ago | parent | prev [-]

> Javascript uses UTF-16 for strings

I don’t think the spec requires that. charAt indexes on UTF-16 code points, but I don’t remember ever seeing that it has to do that in O(1) time, so that doesn’t imply the implementation has to use UTF-16 internally.

Also, for modern JavaScript, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... says:

“Note: Avoid re-implementing the solutions above using charAt(). The detection of lone surrogates and their pairing is complex, and built-in APIs may be more performant as they directly use the internal representation of the string. Install a polyfill for the APIs mentioned above if necessary.”

Because of that, I would hope most modern implementations to at least have a variant internal representation that is similar to UTF-8.

	▲	kragen 13 hours ago \| parent [-]
		I wouldn't expect them to. Let us know if you find otherwise!