Google's Go has made finding info on the ancient Chinese board game generally referred to in English by its Japanese name Go difficult. This has has interestingly lead to increased use of its original name Weiqi or its Korean name Baduk.
The Japanese name is actually 囲碁 (igo). 碁 (go) is just an abbreviation; I don't see it often in Japanese text, but for some reason the Anglosphere decided to adopt it.
囲 is a simplification of 圍, and 碁 is a Japanese-specific letter that roughly maps to 棋. If you read 圍棋 in Chinese, you get weiqi.
Devs will never learn this because naming languages after common words is exactly the PL dev culture. It's not important to pldevs because they know the median number of users for a pl is 0, large companies know they can buy the search results, so names are chosen for reasons other than SEO.
People get around it by appending "-lang" or "-script" to the name and that solves the SEO.
In the 90s/2000s people also used to shorten cybersex to cyber. I guess if they wanted to have fun with it they could add a "Wanna Cyber?" in place of the usual "Try <x>".
My gripe with new languages like this is that strings are always UTF-8 and that makes it needlessly difficult to parse HTTP headers correctly. This has led to vulnerabilities in the past.
I disagree. UTF-8 is the right default. Pure ASCII strings are rarely needed in modern software. Unless you know that you need ASCII, your strings should support unicode.
I agree. At this point scripting languages should have native support for string subtypes with custom charsets (ascii/utf16) or just regexp-defined or even ENUM()'erated values.
IIRC historically on Windows, a string was UTF16, on unix it was ASCII; nowadays everywhere it's UTF8 without a way to specifically limit what goes into a string.
For example UTF8 opens the door to homoglyph attacks and various other things (RTL, spaces), and a program should be able to force a string to be ASCII-only so that these classes of problems are ruled out.
Homoglyph attacks and RTL work just as well in UTF-16. UTF-8 and UTF-16 are different character encodings for the same character set (Unicode).
That being said, Windows permits unpaired surrogates in its "UTF-16" strings, even though that is not actually valid UTF-16. Similarly, many Linux APIs accept arbitrary bytes, not just valid UTF-8.
Of course. I was trying to say that it would be nice to limit certain variables to an ASCII charset, or ASCII+umlaut+accents without any of the 10k other UTF8 shenanigans.
It links to the bench.cy, but nothing explains how the others were measured. It seems that they're including some start-up time in some that dominates, but not explaining whether it's realistic to be needing to spend that.
When will devs learn that being able to search for a term on the open internet without having it polluted by normal language is kind of important
囲 is a simplification of 圍, and 碁 is a Japanese-specific letter that roughly maps to 棋. If you read 圍棋 in Chinese, you get weiqi.
People get around it by appending "-lang" or "-script" to the name and that solves the SEO.
Cryptography is much older than bitcoin.
IIRC historically on Windows, a string was UTF16, on unix it was ASCII; nowadays everywhere it's UTF8 without a way to specifically limit what goes into a string.
For example UTF8 opens the door to homoglyph attacks and various other things (RTL, spaces), and a program should be able to force a string to be ASCII-only so that these classes of problems are ruled out.
That being said, Windows permits unpaired surrogates in its "UTF-16" strings, even though that is not actually valid UTF-16. Similarly, many Linux APIs accept arbitrary bytes, not just valid UTF-8.
It links to the bench.cy, but nothing explains how the others were measured. It seems that they're including some start-up time in some that dominates, but not explaining whether it's realistic to be needing to spend that.