With UTF-8 certain common operations take long. Individual character access is O(n); accessing all characters in a string is O(n log n). Even just cutting a str

With UTF-8 certain common operations take long. Individual character access is O(n); accessing all characters in a string is O(n log n). Even just cutting a string is O(n). For some applications that'd be too slow. Implementation of regex and other features is complex. Rune is not UTF-32, but a similar constant-width format. It is not multibyte, but rather single-int-per-character. Gotta stress this point: never interpreted as bytes. Resides only in process memory, not in files, nor for IPC. Held in arrays of of 32-bit ints, not bytes, thus no problem with nulls. There is a trailing zero int, quite like in good old strings. Individual Rune character access (again, an int, not byte) is O(1); various string processing functions are simple to implement for Runes; character ranges are easy to compare, etc., strings have `predictable' length, etc. etc. As an internal-only format, it may be improved at will. Indeed, once it was -- from 16 bit short to 32 bit int, to support newer Unicode character set ;-) The change was internal to library and header files; programs were just re-compiled.