Some noteworthy lines from the README.md[0]:
> - The compiler (not kernel) is 99% AI-written and has not been fully audited yet.
> - Strings are linked lists of characters, so text processing is slow.
> - The compiler (not kernel) is 99% AI-written and has not been fully audited yet.
> - Strings are linked lists of characters, so text processing is slow.
We will introducing binary buffers eventually. The project is new...
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.
That said, yes, we definitely should have a compact Text type. I'll add it over the weekend.
https://www.usenix.org/system/files/conference/hotos15/hotos...
We survey measurements of data-parallel systems recently reported in SOSP and OSDI, and find that many systems have either a surprisingly large COST, often hundreds of cores, or simply underperform one thread for all of their reported configurations.Anecdotally I have a bit of a track record of 10xing slow systems’ throughout by converting them from distributed to single-node or from multithreaded to single threaded.
Heck I once even sped up a number crunching operation by getting it off of the GPU and onto the vector coprocessor. Because GPUs also have a bunch of extra overhead to have to amortize away.
You can slice up arrays in O(1).
The default type is incredibly clear to me.
so vibecoded