C рулит и педалит.

Но есть Rust. Гн удовлетворяет всему сказанному.

Ну тот же Rust. Работает везде где есть таргет в llvm.

https://forge.rust-lang.org/release/platform-support.html

ну и насчет «вменяемых строк»… скажем так, могут быть разные мнения. чтобы никого не обидеть.

Что это? Это нормальные срезы и индексы?

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

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

Ну, за пределами kernel space каких-то особых требований к языкам программирования прямо скажем и нет.

Да спору нет, например, даже на Haskell-e операционную систему написали.

Интересно, где нибудь остались поезда в которых говно на пути выбрасывают?

Весь СНГ.

А си это язык для тех, кому нужна производительность

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

Так то защиты уже есть все, и проверки тоже, в С, для этого не нужен Rust.

Покажите аналог Send/Sync для Си. Напоминаю, что это проверка на многопоточный доступ времени компиляции.

Да, вот так проедет такой говновоз и распространит коронавирус или еще какую заказу.

если переписать код на Си

пишущие на Си переписываниями поголовно не занимаются.

авто-магически станет быстрее?

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

Но тут совершенно внезапно выясняется, что большинство пишущих на любом языке не умеют нормально на нём писать.

Какие из двух?

Строки одни - контейнеры разные. Внезапно, как и в C++.

Как насчёт получение символа по номеру позиции или среза?

Байт != символ. Или вас Эдик покусал? Ну и символов вообще нет. Есть графемы и кластеры. И они могут иметь произвольную длину.

Вы вообще знакомы с Unicode и обработкой текста? Ибо в Rust всё реализовано именно так как нужно. Это один из плюсов современного языка - нет смысла тащить ASCII совместимость.

Я знаю, что в utf8 символы имеют разную длину в байтах, это не повод трясти (а rust во всём руководстве по строкам только это и делает) поддержкой utf8 строк в то время как на деле не уметь с ними работать за пределами ascii таблицы. Ну и сидели бы в её приделах, раз реализация работы с ними для них так сложно.

Почему, например, в том же python для utf8 строк никаких проблем с получением срезов и индексов нет?

Да даже в Фортране нет проблем с индексацией и срезами utf8 строк.

Наверное везде неправильные строки, а в rust честные и правильные - остальные жульничают.

Rust всё реализовано именно так как нужно.

Ага, конечно: «только у нас самые правильные строки, но мы не знаем что с ними делать». Самому не смешно?

нет смысла тащить ASCII совместимость.

Они за её пределы нормально и не вышли до си пор. Иначе бы вышеприведённые пример работал бы одинаково для символов из ascii и символов за её прелелами, и не нужно было бы обвешиваться костылями с проверками вручную.

Почему, например, в том же python для utf8 строк никаких проблем с получением срезов и индексов нет?

#!/usr/bin/env python3
for text in ['й', '🏳️‍🌈', 'ю́']:
    print(len(text), text[0])

2 и
4 🏳
2 ю

Что же это творится, братцы… Я же «просто индексирую символы». Что тут сложного? (с)

Самому не смешно?

Вы можете привести более правильную реализацию?

Они за её пределы нормально и не вышли до си пор.

std реализует контейнер для UTF-8 строк. Больше от неё ничего не требуется. В C++ даже это не осилили.

Тащить весь ICU в std никто не будет. Для манипуляции строками (строками, а не наборами байт) есть доп. либы, который подключаются одной строчкой. Этого в C/C++ тоже не осилили. Да и вообще мало где смогли.

Они точно вменяемее C/C++.

C позволяет их писать. Сможешь ли ты этим воспользоваться - зависит от тебя. Многие языки этого не позволяют вообще.

dog = u"忠犬ハチ公"
print(dog[2:4])
ハチ

print(dog[3])
チ

Вы можете привести более правильную реализацию?

Фанатизм просто зашкаливает. Реализация всё равно самая правильная в rust.

Задачи, для которых необходим Си - стремятся к нулю. Если нужно быстро-быстро - пишут асм под конкретную архитектуру. Если нет, можно хоть на Java/C# наваять. Особых проблем с производительность не будет.

На данный момент, единственная ниша Си - это 8bit микроконтролеры.

Задачи, для которых необходим Си - стремятся к нулю.

микроконтроллеры, вычислительные плохопараллелящиеся задачи, системы реального времени (мы ведь не хотим чтобы сборщик мусора появился когда не надо? или еще какой тормоз в более «продвинутом» языке вылез)

асм под конкретную архитектуру

Зачастую нет смысла и gcc -Os выдает код не хуже, чем ты сам напишешь на асме, но будет гораздо проще сопровождать

Потрудитесь объяснить, что вы хотели показать своим примером. То, что питон умеет слайсить код-поинты? И какое это имеет отношение к работе с текстом?

Фанатизм просто зашкаливает.

Агрессивный фанатизм тут только у вас. Я лишь сравниваю реализации строковых контейнеров в системных языках.

Разговоров про GC так много, что я начинаю забывать, что в rust его нет.

микроконтроллеры

SoC может хоть на питоне работать. Не аргумент.

вычислительные плохопараллелящиеся задачи

Тогда уж фортран. Ну или ждать пока в сишке исправят restict.

системы реального времени

сборщик мусора

Не вижу связи. RTOS - про детерминированность. Никто не мешает вызывать sweep когда есть возможность.

или еще какой тормоз в более «продвинутом» языке вылез

Опять городские легенды про страшных-страшных монстров? Расскажите, кто же там такой может вылезти?

Зачастую нет смысла

Если достаточно того, что наворотит компилятор - то проще взять Java/C#. Но на деле, все пишут asm (криптография, работа с изображениями, аудио-видео кодеки, etc.).

Ну тока в python эксцепшоны, ты забыл про этот тонкий момент.

SoC может хоть на питоне работать

ты не путай SoC и микроконтроллеры. stm32 например, avr, а также всякие DSP

то проще взять Java/C#

между C кодом и Java/C# разница в производительности колоссальна

колоссальна

Зависит от задача. C#/Java могут быть и быстрее на конкретных задачах. Но даже на базовых задачах мы говорим про 2-3х кратное замедление. На «колоссальное» не тянет.

То, что питон умеет слайсить код-поинты? И какое это имеет отношение к работе с текстом?

Хотя бы это умеет. Прямое.

Это не делает строки rust нормальными по сравнению с другими.

Хотя бы это умеет.

Вам подсказать, почему в Rust этого нет, или сами догадаетесь?

#include <stdio.h>
#include <time.h>
#include <math.h>

int main(void)
{
    long i;
    double sum = 0;
    clock_t start = clock();
    for (i = 0 ; i <= 1e9; i++){
        sum += sqrt(i);
    }
    printf("Time elapsed: %f\n", ((double)clock() - start) / CLOCKS_PER_SEC);
    printf("Sum = %lf\n", sum);
    return 0;
}

Time elapsed: 1.997675

using System;
using System.Diagnostics;

namespace root_test
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            long i;
            double sum = 0;

            Stopwatch sw = new Stopwatch();
            sw.Start();
            for (i = 0; i <= 1e9; i++)
            {
                sum +=  Math.Sqrt(i);
            }
            sw.Stop();
            Console.WriteLine("Time elapsed: {0}\n", sw.Elapsed);
            Console.WriteLine("Sum = {0}\n", sum);
        }
    }
}

Time elapsed: 00:00:05.8484139

И там и там собирал с макисмальной оптимизацией по скорости.

Разница в 3 раза. 3 раза это порой разница между ждать результатов расчета 20 минут или час. Или ставить 2 разных микроконтроллера, причем второй может оказаться гораздо более прожорливым

Что мешает в С подключить самую последнюю версию самой правильной библиотеки для обработки текста? libicu или как её там

Подскажи

Вы это сейчас серьезно? Ну с такими «бенчмарками» Си точно вперде.

Подсказываю: слайсинг кодпоинтов имеет смысл чуть более чем никогда. А запихивать полноценную нормализацию и сегментацию в std системного язык никто не будет.

Зачем мне ICU на 8bit микроконтроллере?

шоб правильно показывать все буквы мира на присоединённом к этом у 8битному микроконтроллеру дисплее, как вариант

Кстати не всё так однозначно в этом примере.

И 1e9 лучше не писать, так как это double

https://gcc.godbolt.org/z/PaGXF8

хотя бы кастить…

https://gcc.godbolt.org/z/CA_dg_

каст

Time elapsed: 2.108000
Sum = 21081851083601.464844

без каста

Time elapsed: 4.218000
Sum = 21081851083600.558594

В C# тоже каст решает, правда меньше:

без каста:

Time elapsed: 00:00:05.5009283
Sum = 21081851083600,56

с кастом

Time elapsed: 00:00:04.7882181
Sum = 21081851083600,56

Вот что в расте действительно хорошо, то что implicit кастов нет.

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

В твоих фантазиях.

Что ещё редко встречается?

Как насчёт получение символа по номеру позиции

Для начала было бы неплохо понять, что в Rust строки UTF-8, тогда станет понятно почему нельзя взять символ по смещению также как в случае однобайтных кодировок и Си (только не надо «не всем нужен UTF-8»). Можно получить символ проитерировав по строке или если действительно (за каким-то хреном) понадобилось постоянно дёргать по символу из строки, можно её преобразовать в какой-нить Vec и брать по индексу.

Что ещё редко встречается?

Всё, чего нет в расте. Очевидно же!

Кстати, ещё про символы. Проитерировать по диапазону целых чисел в расте можно, а по диапазону символов - нет. Хотя сам по себе Range этих символов создать почему-то можно.

for x in 1..=10 {
    println!("{}", x); // работает
}

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

Но, разумеется, так и задумано. Прекрасный язык, да.

Почему бы не спрятать реализацию?

Где тут реализация? То что вы называете «реализацией» на самом деле является сложностью(сложностью проблем, с которой мы столкнулись в данном случае) и в Rust очень много мест, где сложность не маскируется и это мне очень нравится. Языков, где сложность максимально маскируется ценой производительности уже достаточно. И вам бы определиться, а то сначала «дайте нам скорость!», а потом «дайте нам простоту!».

Вам же уже показали как получать срез корректно, думаю, как при итерировании получить n-й символ вам не надо объяснять. Зачем вы упорствуете?

>>> s = u"नमस्ते"
>>> print(s[3])

>>>

??? WTF ???

Всё же «просто работает».

в Rust строки UTF-8

Это я уже слышал/видел. Но мне тут выше подсказали, что это и не с руки, а всё тот же массив байтов.

В остальных языках i utf8 строки не utf8 строки что ли?

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

Си позволяет писать быстрые программы,
но большая часть его пользователей не умеет их писать.

Слава б-гу, что вы писать умеете - как на C, так и на C++.

В остальных языках i utf8 строки не utf8 строки что ли?

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

но это костыль специально для символов размером больше 1 байта

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

Или получить символ через nth(). Там все это есть, ты чего.

Что ещё редко встречается?

Ваша адекватность.

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

• для программиста это всё те же массивы байт;
• разгребать эти массивы нужно опять вручную.

Какова область применения таких «строк»?

Клей между либами. Ваш КО. С этой единственной целью и существует std. Всё остальное в cargo.

Ого, переход на личности! Какая неожиданность!