Comments 25
А где сравнение, название статьи не отражает содержимое
Ну хоть что-то делают. Создали бы уже один головной комитет для решения концептуальных проблем программирования, и решали бы вопросики с учетом интересов всех участников рынка…
Ой ладно…. потерплю весь этот «дерьмокод», видимо до конца своей жизни… буду ругаться на читеров, взломы банков и прочеее. Ничего, я потреплю…
Все ещё не очень понимаю кому может понадобиться Carbon. Выглядит не лучше условного D, работает даже хуже, кроссплатформы до сих пор нет. Из плюсовых проблем фактически решена только модульность и возможно часть проблем с работой с памятью, да и то под вопросом. Документации даже на стандартную либу отсутвует - непонятно что вообще в неё входит без копания в репозитории. Трейты/протоколы вижу вроде как есть, а что по тем же span/slice - совершенно непонятно. Интеграция с плюсами есть, но вопрос все тот же - а зачем, если профита от использования почти никакого.
В этом плане cppfront куда перспективнее. Улучшена модульность, улучшена борьба со странными взаимоедйствиями компонентнов - что частично покрывает проблемы с памятью, глубокая интеграция с плюсами (главным образом потому что оно в итоге в него превращается). Кроссплатформенность едва ли не с нулевого дня. Детские болячки синтаксиса тоже решены, хотя и несколько по своему, непривычно. Если кто-то использовал GSL (Core Guidelines Support Library), то считай что всё это уже интегрировано в язык.
На мой взгляд бич Rust это отсутствие стандартизации, хочешь просто получить псевдослучайное число, что в паскале 1983-го даже было из коробки Random - пиши генератор или сторонний крейт, и вот пишешь под wasm, там штук 15 таких крейтов надо знать на всякую мелочь хотя бы как называются, какие-то pool_promise, gloo_timers... И каждый автор по своему трактует интерфейс
Генерация случайных чисел - это платформозависимая история, std в rust должен гарантировать одинаковый результат выполнения операций на любой платформе. Плюс это будет проблемы с многопоточностью, у того же /dev/random случаются зависания при недостатке энтропии. Ну и последнее в 1987 году не так парились насчёт безопасности и криптостойкости, поэтому в тех же делфях был (вроде) рандом от времени, что потенциально несёт риски для всех криптографических алгоритмов.
Резюмируя, в std должно попадать все, что работает прогнозируемо на любой платформе, остальное - идите в библиотеки. Поэтому, в том числе, такой цирк творится в ассинхронщине
а что отвечать когда спрашивают далёкие от раста, а при чем тут везде std?
С++ как-то справился, или вы действительно думаете, что невозможно сделать одинаковую генерацию чисел на разных процессорах?
Давно у нас понятие платформа стало эквивалентно процессору?
В плюсах <random> использует такой же алгоритм, берется источник энтропии, который дёргает системный вызов ОС. Если в ос не удалось его найти, то вызов по сути фиктивный, что влечёт проблемы с безопасностью. Вроде еще там только поддерживается не особо криптостойкий алгоритм prng, но не берусь утверждать точно, может можно другие юзать. Ещё в плюсах ты сам решаешь как бороться с неопределнным поведение в мультипотоке, когда дергаешь эти вызовы. Rust такое на уровне концепта запрещает.
В расте не было проблем это реализовать в стандартной либе, просто идеология там другая по включению в нее, вот и все.
Какая разница как выбирается зерно для алгоритма? Сам рандом специфицирован и не зависит от платформы. А какое будет начальное зерно - либо вы возьмете его из времени, либо поставите фиксировано 42, либо получите из запроса в гугл-рандом - неважно
вроде еще там только поддерживается не особо криптостойкий алгоритм prng
не надо тащить раст мышление в плюсы. Не все алгоритмы должны быть какими-то там "криптостойкими" и мифически "безопасными". Это рандом, он считает псевдослучайные числа и распределение математически правильное. Как он может быть "некриптостойким" - понятия не имею
Буквально, мой тезис написанный ДВА раза: в rust другая идеология попадания в функций в стандартную библиотеку. Перед этим, объясняю почему rand не попал в стандартную либу. В первом комментарии еще подчёркиваю проблему этого подхода на примере ассинхронщины.
Вы:
не надо тащить раст мышление в плюсы.
Какой-то Милонов-style получается.
Не все алгоритмы должны быть какими-то там "криптостойкими" и мифически "безопасными".
Я сказал где-то, что так делать обязательно? Без проблем, считайте как хотите, rust - на уровне концепта, не даёт это сделать "из коробки", чтобы какой-нибудь программист не взял эту функцию из коробки в основу своего криптоалгоритма. Если он может так сделать, то rust потеряет свою главную фичу- безопасность. Когда программист использует сторонние либы для таких целей, то ответственность с языка снимается.
Какая разница как выбирается зерно для алгоритма?
Вы как представляете это: есть список алгоритмов, а ты дальше к ним пишешь свой источник энтропии? На хера эти функции тогда тащить в std, если можно вынести в отдельную либу? где ты все это получаешь СРАЗУ?
Как он может быть "некриптостойким" - понятия не имею
Если вы понятия не имеете, то может просто загуглите исследования по этому поводу, притом исходное название алгоритма у вас есть. Я лично не хочу заниматься просвящением и копированием ссылок на статьи по этой теме, потому что ощущение, что я "играю с голубем в шахматы"
Вы говорите про сишный rand, предлагаю вам зайти и убедиться уже, что речь не про него
https://en.cppreference.com/w/cpp/header/random.html
К чему вопрос? К криптостойкости?
Я конкретно говорю про mt19937, там еще дисклеймер в оригинале добавил.
Вроде еще там только поддерживается не особо криптостойкий алгоритм prng, но не берусь утверждать точно, может можно другие юзать
Если про источник энтропии, то описал в ветке ниже, как это происходит.
P.s. мне уже лень цитировать самого себя.
Ещё в плюсах ты сам решаешь как бороться с неопределнным поведение в мультипотоке, когда дергаешь эти вызовы. Rust такое на уровне концепта запрещает.
вы вообще про сишный rand(), то есть совсем не понимаете о чём речь.
Что мешало расту на уровне его типов запретить использовать многопоточно тип?
Плюс это будет проблемы с многопоточностью, у того же /dev/random случаются зависания при недостатке энтропии
В плюсах <random> использует такой же алгоритм, берется источник энтропии, который дёргает системный вызов ОС.
Вы контекст не храните, когда ведёте дискуссию, я буквально описал проблему.
того же /dev/random случаются зависания
а как так вышло что мы обсуждали алгоритмы и стандартную библиотеку языка, а внезапно появился какой-то dev random? Детали реализации тут ни при чём
внезапно появился какой-то dev random
если он у вас внезапно появился, то у вас проблема явно есть проблемы с хранение контекста. Ну да ладно, сделаем скидку и попробую еще раз объяснить в одном сообщении:
Алгоритм в c++/random и в rust/rand (не std)
1) в качестве источника энтропии платформозависимый источник (процессор - это не платформа, на будущее). В linux это /dev/random или getrandom(), windows - CryptGenRandom, wasm window.crypto.getRandomValues()
2) создаётся chacha12, в плюсах std::mt19937. Дальше генерация чисел.
Rust из коробки не готов брать на себя ответственность за поведение этих типов в мультипотоке. В плюсах это ответственность на программисте.
mt19937 никак не зависит от платформы, его поведение специфицировано
утверждение про то что раст "не готов брать на себя ответственность за поведение этих типов в мультипотоке" это бред, потому что в расте существуют Vector строки и так далее, которые обладают такими же гарантиями в многопотоке как и генератор mt19937. И в расте есть способ выразить это в типах через трейты синк и проч
Я думал у меня получится в одном сообщении, активировать ваш механизм внимания и вы сможете хоть чуть чуть сохранить контекст. Но к сожалению, я был слишком наивен и лучшего мнения о собеседнике.
К сожалению, я не могу вместить ответ в одно предложение, чтобы вы не запутались. Поэтому предлагаю на этом остановится. Вы правы, а я не прав, как хотите, мне уже надоело.
Но вы же и правда бред несёте mt19937 не использует /dev/random или нечто подобное, передавая одинаковый сид в него вы всегда будете получать одинаковую последовательность независимо от платформы, потому что это детерминированный алгоритм без истинной случайности. И почему вы так прицепились к криптографии хотя рандом используется в миллионе других вещей, и активнее всего как мне кажется в графике (шумы). Очень странное оправдание для раста.
Где конкретно я сказал, что mt19937 использует /dev/random для реализации алгоритма? Я специально перепрочитал всю ветку, нигде такого не написано! Во втором шаге (предыдущий коммент) нет ни одной ссылки, на то что на вход алгоритма обязательно необходимо передавать имеено такой сид из /dev/random. Ни где не указано, что в mt19937 конкретно есть проблема с многопоточностью, я указывал только на проблемы с криптостойкостью, о чем свидетельствуют множество статей в области кибербеза.
И почему вы так прицепились к криптографии хотя рандом используется в миллионе других вещей, и активнее всего как мне кажется в графике (шумы)
Специально для вас цитирую себя:
Я сказал где-то, что так делать обязательно? Без проблем, считайте как хотите, rust - на уровне концепта, не даёт это сделать "из коробки", чтобы какой-нибудь программист не взял эту функцию из коробки в основу своего криптоалгоритма. Если он может так сделать, то rust потеряет свою главную фичу - безопасность. Когда программист использует сторонние либы для таких целей, то ответственность с языка снимается.
Нигде не написано, что это круто и всем нужно так делать.
Еще раз повторяю: есть проблема на ПЕРВОМ шаге (это цифра 1) алгоритма, а именно получение данных источника сида. Не буду повторятся, проблемы я уже описал выше (почитайте, пожалуйста и попробуйте это в голове сохранить).
Ко второму шагу у меня вопросов нет, я его лишь УПОМЯНУЛ в рамках вопроса о криптостойкости, отметив проблему (вполне нейтрально) плюсов в этом вопросе (в контексте обсуждаемого вопроса): "почему C++ смог, а rust нет".
А сейчас давайте вернемся к моим первоначальным тезисам:
1) в Rust главная фича - это безопасть.
2) в std должны попадать только те вещи, которые повторяемы на любой платформе.
3) C++ вешает ответственность на самого программиста, Rust - такое не позволяет.
4) я не даю нравственных оценок, хороши ли перечисленные политики или плохи. Более того я указываю на проблемы в этих политиках на примере ассинхронщины.
Теперь давайте рассуждать в рамках ЭТИХ тезисов, почему rand (де-факто стандарт генерации случайных чисел в Rust) не попал в std:
1) Есть платформозависимая часть, которая будет работать неопределенно в мультипотоке. Плюс могут быть проблемы с переносимостью и поддержкой на разных ОС (компилятор должен собрать из всех native компонентов рабочий код, за исключением платформ где явно не указана дирректива #[no_std]).
2) Можно ли реализовать в стандартной либе только алгоритмы, выкинув формирование сида. Да можно, но это может привести к неопределенному поведению, если программист все же решит юзать системные вызовы.
3) Нельзя допустить, чтобы какие-то не криптостойкие штуки попали в std, потому что может найтись уникум их использующий, там где нельзя (криптография). А как мы знаем, сегодня один ChaCha12 (используется в библиотеке rand) классный и хороший, а завтра опубликуют серию разгромных статей на этот счет. Плюс тот же mt19937 быстрее, насколько я знаю, поэтому для статистических расчетов предпочтительней использовать его, зачем ограничивать программиста только ChaCha12? Поэтому если программист хочет использовать конкретный алгоритм, то пусть юзает сторонние либы, разбирается в них, это уже проблемы не Rust, а пользователя.
Понимаете, когда я веду дисскуссию об определенных вещах, то стараюсь сохранить контекст, того что мне писали или я писал. Но когда приходится цитировать самого себя же - это несколько грубо по отношению ко мне. Также, хочу отметить, если вы хотите узнать мнение человека, то спросите, не надо додумывать за него, если все же хотите додумать, то вам к психологу.
В заключении отвечу на последний ваш тезис:
Очень странное оправдание для раста.
Я не оправдываю Rust, я с ним живу, до этого более 10 лет писал на плюсах, поэтому привык сам решать, что безопасно, а что нет. Но в тоже понимаю Rust Foundation, если они будут такое тащить в std, то рано или поздно вылезут имбецилы из другого лагеря, которые будут орать: а где ваша безопасность (я не только сейчас про криптостойкость алгоритмов, но и про безопасную работу с ОС), вот тут такие возможности натворить фигню. Если честно, меня это шликанье на безопасность вообще бесит, особенно со стороны комьюнити (кто проходил собесы на Rust, то поймет). Я выбирал Rust по другим причинам.
P.S. А ведь если уметь поддерживать беседу более, чем в одно сообщение, не вырывать из контекста, и не заниматься демагогией, то можно было бы упрекнуть меня за реальные и интересные противоречия: как тогда живет hashmap? Почему нельзя сделать публичным randomizer внутри std, который используется в коллекциях? работа с ФС и файлами реализована, а вот с этим нет, почему? Вот это действительно странно!
Уже есть си с 4 плюсами. Это C#
Ничто уже не заменит С и С++. А вот некоторые полезные находки из тех, кого некоторые считают заменителями должны быть переняты.
Rust не станет (С++)++, а Carbon — возможно, но нескоро