“No options” simply isn’t true. Here’s a guide to many of the options: https://hasufell.github.io/posts/2024-05-07-ultimate-string-...

Now if you’re asking why the basic prelude String type remains as it is, that’s because changing it would break more code than it’s worth, at least as far as prelude’s maintainers are concerned. This is no different from how standard C strings remain a null-terminated sequence of bytes even though that’s been awful for everyday use for at least 30 years.

▲

LightMachine 3 hours ago | parent [-]

Note that using linked lists for strings is actually more "parallel friendly" because you can take the head/tail and spread it around 16k GPU cores in O(1), unlike in Haskell, unlike arrays, which require a linear copy, becoming quadratic. So, the right "default type" isn't that clear on Bend, because GPUs behave very differently from CPUs.

That said, yes, we definitely should have a compact Text type. I'll add it over the weekend.

	▲	bunderbunder an hour ago \| parent [-]
		Though also, parallel processing strings and other non-numeric data on that level of granularity is, IME, typically less performant. The parallelism rarely manages to offset the performance penalties incurred by decomposing the problem in a parallel-friendly way. Even on a single machine you’ve got to think about whether organizing the data in a parallel-friendly way also makes it less cache-friendly. For example, a linked list of Unicode code points is 12 bytes per character, and each character might be on a completely different cache line. Depending on language a UTF8 buffer might be 1/10 the size and have a much more compact layout in memory.