а то сначала «дайте нам скорость!», а потом «дайте нам простоту!».

Мне всё вместе и две.

для программиста это всё те же массивы байт

Для такого как вы - да. Для остальных - это контейнер, который можно итерировать как угодно.

разгребать эти массивы нужно опять вручную

Не нужно. Всё уже написано.

Так в чём тогда нормальность «юникодных» строк в rust

В том, что они гарантированно юникодные.

Только после вас.

Ты понял неправильно.

Подойдёт?

https://m.habr.com/ru/post/435872/

можно итерировать как угодно.

выше как угодно уже было

for c in 'a'..='e' {
    println!("{}", c); // не работает
}

Всё уже написано.

Всё что нужно лично тебе?

они гарантированно юникодные.

и?

идеально!

Для такого как вы - да.

Пфф, я вообще не программист.

На сколько я понимаю, взятие n-го символа ведёт к проходу по строке, а раз grem так сильно напирает на этот use-case, то, видимо, хочет делать это часто и тогда лучше всё же преобразовать данные. Но это всё предположения. Что за надобность такая постоянно брать n-й символ в юникодной строке, я не знаю.

выше как угодно уже было

Потому что ты итерируешься не по строке?

Так в чём тогда нормальность «юникодных» строк в rust по сравнению с другими

На сколько я понял, дискуссия началась со сравнения со строками в Си, а там поддержка юникода просто никакая. Да и строк-то нет. Только куски памяти с нулём в конце.

разгребать эти массивы

Да где ж «вручную»? Вам же показали уже, что можно вполне брать и n-й символ, и корректно делать слайс. Ничего не понимаю.

Что за надобность такая постоянно брать n-й символ в юникодной строке, я не знаю.

Это встроенная функция кучи языков и для кучи языков постоянно спрашивают как это сделать. Как тут любят говорить «деды делали…». При работе с текстом постоянно возникает задача куски из строк выдирать.

можно вполне брать и n-й символ, и корректно делать слайс.

Можно, но громоздко как-то.

дискуссия началась со сравнения со строками в Си, а там поддержка юникода просто никакая. Да и строк-то нет. Только куски памяти с нулём в конце.

В Си сравнивать не с чем, там нет строк. Разве что str в rust всё тот же массив байт (указатель на массив + длина)

У большей части распространенных языков несколько реализаций: C, C++, Fortran, C#, JavaScript, Java - языки у которых есть стандарт и по нему можно написать реализацию. Python - есть референсный cpython но при этом есть куча других реализаций (pypy, jython, ironpython) разной степени совместимости (обычно код без хаков и биндингов с C работает идентично)

C, плюсы и фортран имеют много реализаций в силу исторических причин. C# и Java по лицензионным, ибо шарп и жаба написаны корпорастами и изначально были несвободными. Короче, много реализаций обычно получаются не от хорошей жизни.

выше как угодно уже было

Это не итерирование строки.

Всё что нужно лично тебе?

И не только мне.

и?

В других, популярных системных языках такой роскоши нет.

Разве что str в rust всё тот же массив байт (указатель на массив + длина)

Вы не поверите, но даже в питоне и JS это тоже «указатель на массив + длина». Разница в том, что в расте вы не можете напортачить с &str, в отличии отю

Пажжи, через какое-то время он узнает, что питон, на самом деле, тоже не умеет индексировать по графемам (только по символам) , потому что в общем случае это слегка невозможно.

потому что в общем случае это слегка невозможно.

По значению первого октета (байта) можно определить сколько байт выделено под символ и организовать сдвиг дальней границы индексов.

То есть для пользователя индексы будут означать номер символа, а не номер байта по счёту.

Что за общий случай имеется ввиду?

По значению первого октета (байта) можно определить сколько байт выделено под символ и организовать сдвиг дальней границы индексов. То есть для пользователя индексы будут означать номер символа, а не номер байта по счёту.

Именно так. Символа, не графемы.

Что за общий случай имеется ввиду?

В общем случае графема (видимое пользователю представление юникодной подстроки) состоит из нескольких символов. То есть на экране у тебя один символ, а в коде – два. Два символа, не байта.

В общем случае графема (видимое пользователю представление юникодной подстроки) состоит из нескольких символов

чую, разговор сейчас зайдёт про смайлики, где графема строится из нескольких (4 и больше) кодепоинтов
ну надо же откуда-то высосать оправдание для неумелости раста )))

чую, разговор сейчас зайдёт про смайлики, где графема строится из нескольких (4 и больше) кодепоинтов ну надо же откуда-то высасать оправдание для неумелости раста )))

Осталось понять, причем тут раст, если сейчас разговор о питоне.

У питона в итоге всё равно удобнее сделано в более распространённых случаях (несоставных).

Как о питоне разговор? Тебе таки нравятся строки в питоне?

Что значит «более распространенных», лол? У тебя невалидная индексация, если ты ставишь целью индексировать видимые юзеру символы. Рано или поздно найдется текст, на котором ты попадешь в середину графемы и будет бобо.

да, я вставлю целью индексировать символы юникода, а не графемы. но когда они понадобятся - потребуется либо реализация нормализации либо ограничить область используемых символов: версий unicode уже много - вон год назад обновили опять.

Ну так это из разряда saahriktu, не всем нужны корректно работающие программы.

но нужны работающие хотя бы иногда

И в python, и в Rust есть модули, позволяющие сделать то, что ты хочешь, корректно.

«Нужны программы работающие хотя бы иногда».

Такое мог написать только человек, который в реальности не сталкивался с программами, которые работают «иногда». Потому что для реального пользователя нет хуже сценария когда программа без всяких оговорок в документации начинает на разных наборах данных работать или не работать. Потому что над пользователем стоит начальник и говорит «ты охренел что ли, чудила? результат нужен был вчера, тебе дали мегасовтину, а ты пару кнопок нажать не можешь» (начальнику глубоко фиолетово, что мегасофтина за сотни нефти работает «иногда»).

речь о том, что в расте заявлена поддержка юникода. а по факту это только на заборе, а в сарае дрова лежат. если так натягивать сову на глобус, то и в стареньком си есть полноценная поддержка юникода, ничем не хуже.

и оправдывать ситуацию тем, что «ах в юникоде графемы» - графемы тут ни при чем. байты - символы - графемы. переход к работе с графемами попросту невозможен без реализации нормальной работы с символами.

крч раст в своем репертуаре. «системный язык программирования». в каком месте, я стесняюсь спросить? стандарт на «системный язык программирования» где посмотреть? Rust does not have an exact specification, but an effort to describe as much of the language in as much detail as possible is in the reference.

вот https://www.ntecs.de/posts/rust-ported-to-dragonflybsd/ опус о портировании раста. нет, не на принципиально новую архитектуру, не на экзотическое железо, нет. читаю, как говорится, и плачу.

при том что компилятор сишечки под железо ваяется 2 месяца. прописью - два. при наличии компилятора С нам автоматически становится доступен весь набор портируемого софта. и какой-нибудь там nim, например. если уж прям такой дефицит сахара в организме.

и да, портирование nim на тот же dragonflybsd выполняется при помощи команды make. не о чем писать. желающие могут убедиться в этом самостоятельно.

крч ниша раст мне совершенно непонятна.

из любопытства можно так же глянуть на https://github.com/frol/completely-unscientific-benchmarks

доставляет отдельно и особо.

читаю, как говорится, и плачу.

И что там такого что заставило тебя плакать?
К расту там относится только проблема с jemalloc, всё остальное проблемы llvm.

без реализации нормальной работы с символами.

Где это реализовано?

над пользователем стоит начальник

Технологии тут ни при чем. Раб всегда будет ниже господина, с растом или без - без разницы. Это же вовсе не техническая проблема.

речь о том, что в расте заявлена поддержка юникода. а по факту это только на заборе, а в сарае дрова лежат. если так натягивать сову на глобус, то и в стареньком си есть полноценная поддержка юникода, ничем не хуже.

Мы только что выяснили, что поддержка такая же, как в Питоне. В Питоне тоже плохие строки?

и оправдывать ситуацию тем, что «ах в юникоде графемы» - графемы тут ни при чем. байты - символы - графемы. переход к работе с графемами попросту невозможен без реализации нормальной работы с символами.

Которая в Rust есть. Такая же, как в Питоне :D

крч раст в своем репертуаре. «системный язык программирования». в каком месте, я стесняюсь спросить?

Он быстрый, без GC и может работать без stdlib.

стандарт на «системный язык программирования» где посмотреть?

Его нет. Теперь твоя очередь рассказывать, почему системный язык программирования обязательно должен иметь стандарт.

при том что компилятор сишечки под железо ваяется 2 месяца. прописью - два. при наличии компилятора С нам автоматически становится доступен весь набор портируемого софта. и какой-нибудь там nim, например. если уж прям такой дефицит сахара в организме.

Учитывая, что поддержку новой платформы в Rust легко добавить в llvm, я не вижу особой проблемы.

Да раст тут уже почти что и не при чём уже. Речь же была про подход к созданию программ. Я не согласен с подходом «пусть программа работает корректно иногда». Вот и всё, что я имел в виду.

Такая же, как в Питоне

dog.char_indices().nth(2).unwrap().0

угу, угу. тогда в асме тоже есть полноценная поддержка юникода.

Он быстрый, без GC и может работать без stdlib.

nim быстрый, может без gc и его стандартная библиотека, насколько я понимаю, не имеет зависимостей https://nim-lang.org/docs/lib.html

все, он тоже системный? а пацаны и не знают.

почему системный язык программирования обязательно должен иметь стандарт

потому что при создании компайлера для целевой платформы нужно иметь спеки на абстрактную машину ЯП, внезапно. ну или получится то, что «иногда работает».

Учитывая, что поддержку новой платформы в Rust легко добавить в llvm, я не вижу особой проблемы.

сравни supported platforms для раст и llvm

Его нет. Теперь твоя очередь рассказывать, почему системный язык программирования обязательно должен иметь стандарт.

Он ничего не должен. Стандарт просто так на пустом месте не появляется. Стандарт полезен, чтобы привести к некоему общему знаменателю различные реализации и накопленный опыт. Эти различные реализации и опыт применения уже должны существовать до того, т.e. уже должен быть обширный интерес к языку со стороны индустрии. Стандарт может и не появиться, здесь стандарт лишь следствие, а причина - интерес к технологии множества конкурирующих друг с другом компаний. Точно так же, как стандарт на единицы измерения, сам по себе, - без априорного наличия различных систем - он не нужен.

угу, угу. тогда в асме тоже есть полноценная поддержка юникода.

АСМ умеет валидировать UTF-8?

nim быстрый, может без gc и его стандартная библиотека, насколько я понимаю, не имеет зависимостей https://nim-lang.org/docs/lib.html

все, он тоже системный? а пацаны и не знают.

Ничего не знаю про nim.

потому что при создании компайлера для целевой платформы нужно иметь спеки на абстрактную машину ЯП, внезапно. ну или получится то, что «иногда работает».

ПСС, парень, но ведь для поддержки новых платформ в rust просто используют llvm.

сравни supported platforms для раст и llvm

Потому что есть некоторая разница между «мы можем компиляться под X» и «наша stdlib умеет в X, документация для X готова и мы регулярно тестируем работу всего этого под X».

Он ничего не должен. Стандарт просто так на пустом месте не появляется. Стандарт полезен, чтобы привести к некоему общему знаменателю различные реализации и накопленный опыт.

У Rust одна реализация :)

Эти различные реализации и опыт применения уже должны существовать до того, т.e. уже должен быть обширный интерес к языку со стороны индустрии. Стандарт может и не появиться, здесь стандарт лишь следствие, а причина - интерес к технологии множества конкурирующих друг с другом компаний. Точно так же, как стандарт на единицы измерения, сам по себе, - без априорного наличия различных систем - он не нужен.

Опять же, у языка одна реализация. Если у тебя одна реализация, стандартизировать особо нечего.

при том что компилятор сишечки под железо ваяется 2 месяца. прописью

Компилятор уровня GCC, который умеет во всякие стекпротекторы, пишется за два месяца? Ох лол.

АСМ умеет валидировать UTF-8?

в конечном счете все, что умеет работать с юникодом, ложится на асм. значит умеет.

ничо что я позаимствовал подход и логику?

есть некоторая разница «мы можем можем компиляться под X» и «наша stdlib умеет в X, документация для X готова и мы регулярно тестируем работу всего этого под X».

ну то есть llvm все вопросы внезапно не закрывает

в конечном счете все, что умеет работать с юникодом, ложится на асм. значит умеет.

Ну то есть строковые литералы в ASM юникодные, да? То есть итерироваться по чарам можно? :)

ничо что я позаимствовал подход и логику?

Не знаю, у кого ты её позаимствовал.

ну то есть llvm все вопросы внезапно не закрывает

Наверное потому, что разработка компилятора и стандартной библиотеки – разные задачи? :D

Компилятор уровня GCC, который умеет во всякие стекпротекторы, пишется за два месяца? Ох лол.

а где там было про «уровня gcc»? и да, компайлер очень даже неплохого качества под конкретное железо могут запилить специально обученные люди за вменяемое время.

пруф https://www.astrosoft.ru/products/development/compiler/

В случае, когда у заказчика нет ограничений по использованию зарубежных разработок и отсутствуют опасения насчет возможных изменений в лицензионной политике таких решений, подходящим вариантом может оказаться компилятор на основе LLVM – набора компиляторных технологий, упакованных в удобную модульную форму.

Стартовав в 2000 году как исследовательский проект Университета Иллинойса, на сегодняшний день LLVM де-факто является стандартом в качестве платформы для создания новых компиляторов и продолжает активно развиваться.

В отличие от компилятора GCC, LLVM не требует раскрытия исходных кодов создаваемых на его основе продуктов, что стимулирует его использование в коммерческих проектах.

АстроСофт обладает соответствующими компетенциями, имея опыт разработки специфических LLVM оптимизаций, а в 2017 году ведет несколько проектов по разработке полных LLVM-компиляторов.

И ведь действительно пруф.

ну или получится то, что «иногда работает».

Кто сказал UB?

Опять же, у языка одна реализация. Если у тебя одна реализация, стандартизировать особо нечего.

Правильно! Если измерениями на планете занимается всего пара фриков, им не нужна никакая система измерений, у них есть всего одна берцовая кость (эталон), и они используют в качестве руководства один и тот же наскальный рисунок, друг с другом как-нибудь договорятся. Или вообще живут на разных континентах, друг о друге не знают, и международный стандарт им в их доисторической экономической системе - как собаке пятая нога.

Правильно! Если измерениями на планете занимается всего пара фриков, им не нужна никакая система измерений, у них есть всего одна берцовая кость (эталон), и они используют в качестве руководства один и тот же наскальный рисунок, друг с другом как-нибудь договорятся. Или вообще живут на разных континентах, друг о друге не знают, и международный стандарт им в их доисторической экономической системе - как собаке пятая нога.

У нас вот Интернет придумали, все обо всем знают. У тебя аргументация вида «Если у парня есть кость в носу – он шаман. А если нету – не шаман». Стандартизация – необходимый шаг, когда есть либо необходимость пилить разные реализации, либо уже так сложилось, что они есть, и нужно как-то с этим жить.

А если ты про UCC говорил, то ты там немножко выдрал из контекста:

Компания АстроСофт разрабатывает свой компилятор языков программирования C/C++ с 1999 года. К проекту привлекаются исключительно российские специалисты, на разработку потрачено в общей сложности более 170 человеколет. За это время созданы несколько пакетов средств разработки на базе компилятора UCC, которые используются в производственных процессах крупных промышленных компаний.

За счет архитектуры адаптация компилятора к новой платформе занимает около 2 месяцев в зависимости от сложности процессора и методов низкоуровневой оптимизации. Адаптация включает в себя настройку правил кодогенерации, в то время как основной исходный код компилятора остается неизменным.

То есть компилятору уже двадцать лет, но новую платформу к нему прикрутить можно довольно быстро.

Если у парня есть кость в носу – он шаман. А если нету – не шаман

Еще раз внимательно перечитай, что я написал. Сначала интерес к технологии и только потом стандартизация. Если стандарта нет, это не значит, что язык плохой. Но это может означать, что он мало кому интересен, и потому у него одна единственная реализация.

Еще раз внимательно перечитай, что я написал. Сначала интерес к технологии и только потом стандартизация. Если стандарта нет, это не значит, что язык плохой. Но это может означать, что он мало кому интересен, и потому у него одна единственная реализация.

По-моему, это ты не понял. Я хочу услушать аргумент почему вдруг множественные (актуальные) реализации каким-то образом должны о чем-то свидетельствовать. У Go вот одна реализация, и ему это почему-то никак не мешает. Есть, конечно gccgo, но я не представляю, кому он нужен.

То есть компилятору уже двадцать лет, но новую платформу к нему прикрутить можно довольно быстро.

за 40 дней в одно лицо https://habr.com/ru/post/274083/

удачи проделать с компилятором раста то же самое

за 40 дней в одно лицо https://habr.com/ru/post/274083/

Статья на хабре о том, как паренек сделал цомпилятор ради лулзов, должна каким именно образом нас убедить в возможности написания корректного компилятора за два месяца? %)

удачи проделать с компилятором раста то же самое

Я наверное в третий раз скажу: LLVM. Давай, следи за руками:

• Компилятор раста использует LLVM
• Добавить поддержку платформы – это добавить бекенд в LLVM
• Добавить поддержку стандартной либы это отдельная задача, поэтому платформы Rust и LLVM различаются