That made me think about something else. How cool would it be to have a program visually show you how a string is stored in memory?
This way you would be able to interactively see how unicode and different runes are represented in bytes, how they are also abstractly represented in your programming language array data structure, and how finally they are stored on your little-endian system.
I'm sorry, what? Golang didn't appropriate the term Rune in reference to Unicode. The term comes from Plan 9's UTF-8 handling library (libutf) which was written by ken and pike, who invented UTF-8. Rob Pike went on to write Go, which was heavily influenced by Plan9 C.
rune.c:2: "The authors of this software are Rob Pike and Ken Thompson."
No, they just used rune because it sounds cool and someone felt two words was too much, also why follow the terminology of a well-established international standard if you can invent your own words and confuse everyone in the process?
As I mentioned elsewhere in the thread, Rune was the agreed-upon term by the inventors of UTF-8. They literally set the standard that was adopted as UTF-8.
UTF-8 is just an encoding of Unicode. The Unicode terminology is "code point". Terminology may have been more varied 30 years ago, but "code point" won long ago, and using other words to mean the same thing is just confusing.
That may be the case, but Rune as a term for implementation predates the accepting of UTF-8 as Unicode.
In addition, Rune refers to a specific implementation of the code point. As far as I am aware, UTF-8 doesn't define a code point as being uint32, rather it just defines it as a point within the code space (which is defined to be at least a certain size), a code point could be implemented in any number of ways internally. When talking about implementation details, a Rune is defined as a uint32, which is analogous (for implementation purposes) as a code point.
That is to say, a Rune is a manifestation of a code point, but a code point need not always map to that internally. This is like complaining over using "int" instead of "uint32_t" (I'm sure someone else can think of a better example, actually).
From the title I wondered if another person decided to implement their own variant of Christopher Domas' ..cantor.dust.., which has never been released to the public (despite initial promises). The only alternative I know if is Veles.
This way you would be able to interactively see how unicode and different runes are represented in bytes, how they are also abstractly represented in your programming language array data structure, and how finally they are stored on your little-endian system.