>>zero cost abstractions
> А ниче что уже изобрели такое понятие как DLL? Правильный ответ почему
> они не сделали - они не осилили. Они ждут русских, китайцев,
> японцев, может таджиков, которые смогут в unicode. Это типичное мышление америкосов:
> мол ASCII нам хватает, а остальные пусть е***ся как хотят.

Я бы рекомендовал, прежде чем критиковать, всё же ознакомиться с документацией:
https://doc.rust-lang.org/std/str/

В модуле str есть все инструменты необходимые для разбора байтов на символы unicode и на кластеры графем. То есть, в стандартной библиотеке всё это есть, что на самом деле причиняет анальных болей, потому что подключая стандартную библиотеку ты подключаешь заодно и кучу табличек необходимых на разбор этого самого unicode'а, и dll здесь не очень помогают, потому что dll или не-dll, но таблички эти надо хранить на диске и держать в памяти, что не проблема в случае десктопа, но может оказаться недопустимым оверхедом, если ты пытаешься запилить что-нибудь типа 16-битного досовского com файла.

> Я вот про отсутствие юникода только сейчас узнал и это просто феерично.

Ты ничего не узнал. Ты прочитал и не понял, что именно прочитал. Аноним выше, как я понимаю, сокрушался по поводу того, что str/String заточены на работу с байтами, а не с символами. Скажем, метод str.get, позволяет получить слайс из str задав диапазон индексов _байтов_, а не символов. Если же тебе нужен слайс простирающийся от пятого символа, до десятого, то тебе придётся переводить индексы символов в индексы байтов, прежде чем получить нужный слайс. std::str предоставляет тебе всю необходимую для этого функциональность, чтобы тебе не пришлось бы консультироваться со спецификацией unicode'а и декодировать символы самостоятельно. Но там нет готового метода, который бы позволил тебе сделать это одним вызовом метода. Отчасти потому, что стандартная библиотека не знает, что именно тебе надо -- символы или кластеры графем? Отчасти потому, что трансляция индекса байтов в индекс символов -- это O(n) операция, но если это оставить программисту, то он может выбрать вместо этого O(N) операцию, сложность которой зависит не от размера индекса, а от размера строки: например, декодирование строки хорошо сочетается с парсингом этой строки, и можно декодировать каждый символ строки ровно один раз, а не на каждый индекс.

И именно это аноним выше назвал "всю работу переложить на плечи программиста". И именно на это я сослался баззвордом "zero-cost abstractions". Формально говоря, конечно же не вся работа перекладывается на плечи программиста, основную всё же делает std::str, но кого интересуют эти формальности?