Очередного обсуждения Rust тред

И тем не менее, на С++ пишут далеко не только «performance critical» код. Хватает и тупой бизнес-логики.

Разумеется. Необходим ли там С++? Спорно. Скорее всего, хватит джавы или шарпа.

Ну нет, иначе бы они не возникали в сколь-нибудь серьёзных проектах

Это малая часть всех ошибок.

Ансейф кода нет, а результат быстрее, чем у С++.

И медленнее, чем у С.

Ансейф кода нет, а результат быстрее, чем у С++.

И медленнее, чем у С

На выделение памяти смотри. Самая быстрая версия Rust на полтора процента (1.5%) быстрее самой быстрой версии C++, но жрет памяти в два раза больше крестовой и сишной.

Необходим ли там С++? Спорно. Скорее всего, хватит джавы или шарпа.

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

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

К слову, ты бы писал какой-нибудь LibreOffice на джаве?

Это малая часть всех ошибок.

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

И медленнее, чем у С.

И тем не менее. Наглядный пример, что безопасный раст может быть быстрее.

Можно ли написать на С++ быстрее? Наверняка, как и то, что из раста можно ещё выжать. Будет ли unsafe решение быстрее? Вероятно. Но главный вопрос в том: достаточно ли скорости среднего safe решения? Мне кажется, что для многих применений да и в этом и заключается преимущество.

К слову, ты бы писал какой-нибудь LibreOffice на джаве?

Я когда-то давно думал, что он написан на жаве.

Это малая часть всех ошибок

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

Если у Си отвратительно мало гарантий, то в Rust гарантии отвратительно дорогие. То есть, один сорт говна сменили другим. Я за дополнительные проверки, но только если они не выносят бессмысленно мозг кодеру. UB ты никак не сможешь устранить полностью в достаточно крупном и/или нестандартном проекте, а вот снизить — очень даже можно. Даже C++ снижает вероятность UB, но C++ позаимствовал слишком много плохих черт от Си.

Можно ли написать на С++ быстрее? Наверняка, как и то, что из раста можно ещё выжать. Будет ли unsafe решение быстрее? Вероятно. Но главный вопрос в том: достаточно ли скорости среднего safe решения? Мне кажется, что для многих применений да и в этом и заключается преимущество

Это не среднее safe решение. Посмотри на исходную реализацию на Java:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectraln...

Посмотри, например, на реализацию на Go:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectraln...

А теперь реализация на Rust:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectraln...

struct Racy<T>(T);
unsafe impl<T: 'static> Send for Racy<T> {}
fn parallel<'a, T, F>(v: &mut [T], ref f: F)
        ...
        let f = Racy(f as *const F as *const usize);
        let raw = Racy((&mut chunk[0] as *mut T, chunk.len()));
        thread::spawn(move|| {
            let f = f.0 as *const F;
            let raw = raw.0;
            unsafe { (*f)(i * size, std::slice::from_raw_parts_mut(raw.0, raw.1)) }
        })

«Средняя»?

Я когда-то давно думал, что он написан на жаве.

Джава там есть, но плюсов намного больше. Не знаю как меняется соотношение со временем.

Это не среднее safe решение.

Так я такого и не говорил. Странно искать на сайте с «бенчмарками» средние решения - туда приходят писькомерством заниматься.

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

в Rust гарантии отвратительно дорогие

Ты это повторяешь раз за разом. (:

Могу только не согласиться, объективно измерить вряд ли получится. Считаю, увеличивающаяся популярность раста показывает, что интерес пусть и к таким «дорогим» гарантиям есть. Можешь, конечно, опять сослаться на гугл, который набирает кодеров тысячами и «душит их творчество загоняя в рамки». Вот только если в гугле плохие программисты, то в средней конторе они ещё хуже.

Опять же, ты говоришь про гарантии, но совершенно не готов за них «платить». Тебя корёжит от раста, который действительно гарантирует не так уж много, пытаясь оставаться достаточно привычным/удобным. Формально доказывать весь код никто не будет (может и жаль) и ты первый от такого взвоешь.

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

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

По поводу варианта с rayon я уже ответил выше и ниже — там ансейф запихнут в саму либу, это что-то вроде Numpy и Pandas. Если развернуть реализацию Rayon в сорцы, то получится еще страшнее.

Считаю, увеличивающаяся популярность раста показывает, что интерес пусть и к таким «дорогим» гарантиям есть

Питон стал популярнее Лиспа — и что это значит, что «есть интерес» к еле ползающим приложениям, которые никак нельзя ускорить, кроме как переписать на Си? Я не спорю, что в нынешнем его состоянии Rust — это уже данность, которую исправить не получится и за ней будущее, ближайшие десять лет альтернативы на горизонте не появится, и кодеры дальше будут катать вату, ожидая очередной сборки растового проекта.

Опять же, ты говоришь про гарантии, но совершенно не готов за них «платить». Тебя корёжит от раста, который действительно гарантирует не так уж много, пытаясь оставаться достаточно привычным/удобным. Формально доказывать весь код никто не будет (может и жаль) и ты первый от такого взвоешь

Речь идет о том, что я должен захотеть за единственную гарантию отсутствия UB заплатить медленной сборкой и дополнительным доказательством отсутствия этого UB компилятору. При том, что есть C++, который уже убрал из Си часть UB, который собирает примерно так же медленно, но по крайней мере сборка лучше параллелизуется.

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

В случае моего проекта в Расте отсутствуют инструменты, которые дали бы какие-то гарантии, поскольку это изменяемое разделяемое состояние, то есть, сплошной unsafe.

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

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

Давай не будем отвечать тут всем форумом за код какого-то чувака. В бенчмарках не глядя берут все что «быстрее».

Я бы вообще поделил на категории: fastest vs idiomatic. Например для Rust в idiomatic сделал бы самое быстрое из возможных safe решение. Будет медленнее - ШТОШ, повод фиксить математические API. Для разработчиков был бы кейс

Я бы вообще поделил на категории: fastest vs idiomatic. Например для Rust в idiomatic сделал бы самое быстрое из возможных safe решение. Будет медленнее - ШТОШ, повод фиксить математические API. Для разработчиков был бы кейс

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

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

Если развернуть реализацию Rayon в сорцы, то получится еще страшнее.

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

Только что это покажет?

В случае моего проекта в Расте отсутствуют инструменты, которые дали бы какие-то гарантии, поскольку это изменяемое разделяемое состояние, то есть, сплошной unsafe.

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

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

Поживём - увидим.

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

«Оставить долю UB» звучит как «быть немного беременной». Ну а если без аналогий, то мне кажется, что с меньшими гарантиям раст был бы менее интересен: в конце-концов С++ уже есть.

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

«В идеале» можно было бы включить в бенч специализированный ящик который бы решал задачу вызовом единственной функции. Или делать расчеты на GPU. Если бы так можно было, то и питон бы выехал на первое место. Программа на Си, занявшая первое место, хоть и сложная, но всё решение содержится в ней. В программе на Rust почти всё решение содержится в подключаемой библиотеке — по правилам такая программа должна была быть дисквалифицирована, но ее почему-то оставили. При этом полностью идеоматичного кода на Rust там нет вообще, хотя есть идеоматичный код, например, на Си — это к вопросу об объективности сравнения.

«Оставить долю UB» звучит как «быть немного беременной». Ну а если без аналогий, то мне кажется, что с меньшими гарантиям раст был бы менее интересен: в конце-концов С++ уже есть

Rust немножко беременный в любом случае, потому что в крупном проекте неизбежно потребует применения unsafe.

Rust немножко беременный в любом случае, потому что в крупном проекте неизбежно потребует применения unsafe.

С какого количества строк начинается крупный проект?

С какого количества строк начинается крупный проект?

Десятки тысяч строк, в данном случае. И я сейчас не имею в виду целенаправленное вынесение unsafe фич в отдельный проект — нет, unsafe фичи написанные для реализации проекта считаются единым целым с проектом.

Десятки тысяч строк, в данном случае.

Мне откровенно лень сейчас искать, тем более, что поиск усложняется наличием всяких deny(unsafe_code) и прочего, что содержит слово «unsafe». Прям сейчас под рукой есть маленький проект (~20к строк), где ансейфа вообще нет, но исходники показать не могу.

Но вообще оспорить утверждение хочется. Если когда-нибудь будет не лень, то дам знать. (:

И я сейчас не имею в виду целенаправленное вынесение unsafe фич в отдельный проект — нет, unsafe фичи написанные для реализации проекта считаются единым целым с проектом.

Это ты заранее заготовил путь к отступлению, если такой проект найдётся? Мол если в самом проекте нет ансейфа и даже во «внутренних» библиотеках тоже, то в хоть какой-нибудь из используемых уж точно найдётся. Кстати, в чём тут вообще принципиальная разница брать готовое (с ансейфом внутри) или самому завернуть абстракцию в модуль/библиотеку?

Ну и в целом я не считаю ансейф проблемой. Если он вынесен в отдельную библиотеку (с безопасным интерфейсом и тестами) - так вообще замечательно. Опять же, в реальной жизни может понадобится сишную либу использовать (а ffi - unsafe) или бывает удобно пометить трейт как ансейф. В общем, это удобный инструмент и избегать его «просто потому что ансейф» смысла мало. Очень может оказаться, что твоё утверждение окажется справедливым. Но я всё равно считаю, что растовый (явный) ансейф намного лучше сишного.

Десятки тысяч строк, в данном случае.

Кстати, sqlx (~50к строк) ансейф использует только для SQLite, zola (~17к) вообще не использует.

Прям сейчас под рукой есть маленький проект (~20к строк), где ансейфа вообще нет, но исходники показать не могу

Ну это на грани, можете начинать заготавливать ансейфы «на вырост». Вы же не используете в этом проекте ящики от васяна?

И я сейчас не имею в виду целенаправленное вынесение unsafe фич в отдельный проект — нет, unsafe фичи написанные для реализации проекта считаются единым целым с проектом.

Это ты заранее заготовил путь к отступлению, если такой проект найдётся?

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

Кстати, в чём тут вообще принципиальная разница брать готовое (с ансейфом внутри) или самому завернуть абстракцию в модуль/библиотеку?

Вот и я о том же. Челы с becnhmarking game выставили напоказ программу, которая завязана на ящик от васяна. Пусть васян и проверенный, пусть он много труда вложил в отладку и доводку либы, но это по прежнему не std.

Ну и в целом я не считаю ансейф проблемой. Если он вынесен в отдельную библиотеку (с безопасным интерфейсом и тестами) - так вообще замечательно

И тогда единственная существенная разница между C++ и Rust — это что последний больше бьет по рукам за кривое применение интерфейсов unsafe либы. Стоит ли эта «фича» усложнения кода и замедления компиляции?

Кстати, sqlx (~50к строк) ансейф использует только для SQLite, zola (~17к) вообще не использует

В sqlx половина строк — это тесты, которые находятся прямо в сорцах. А половина от оставшейся половины — это объявления констант. В zola без тестов будет где-то 6 тысяч строк.

Вы же не используете в этом проекте ящики от васяна?

Конечно, используем.

К слову, код некоторых васянов легко может быть лучше среднего кода на среднем проекте.

Пусть васян и проверенный, пусть он много труда вложил в отладку и доводку либы, но это по прежнему не std.

Так и Qt, boost и даже abseil - тоже не std.

Стоит ли эта «фича» усложнения кода и замедления компиляции?

Я (как и ты) для себя на этот вопрос давно ответил.

тесты, которые находятся прямо в сорцах

Как будто что-то плохое.

Так и Qt, boost и даже abseil - тоже не std

Да. Непопулярное мнение, но архитектура Qt криво спроектирована, и, как бы это странно не звучало, именно за счет кривой архитектуры, а также благодаря большому числу вложенных в ее разработку человеколет, она стала популярной. Поддерживать ее очень тяжело и очень дорого, потому отдельные проблемы могут тянуться годами и никак не решаться. Мак, например, они так и не довели до ума. По мере развития приложения оно становится всё меньше Qt, и всё больше самим собой. Но да, Qt — это уважаемый и неплохо оттестированный васян.

Я (как и ты) для себя на этот вопрос давно ответил

Я — недавно.

тесты, которые находятся прямо в сорцах

Как будто что-то плохое

Просто, ты их засчитываешь в число строк кода приложения, а ведь они с таким же успехом могли бы быть написаны на каком-нибудь питоне или вообще DSL. Мое эмпирическое правило по прежнему не опровергнуто — примерно на десятках тысяч строк в проектах на расте неизбежно начинаются unsafe-ы.

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

Да, я считаю тесты частью проекта. Если они написаны на каком-то другом языке - ну ОК, тогда это проект написанный на нескольких языках.

Мое эмпирическое правило по прежнему не опровергнуто — примерно на десятках тысяч строк в проектах на расте неизбежно начинаются unsafe-ы.

Количество строк в sqlx ты всё-таки считал очень вольно. В любом случае, мне чтобы опровергнуть это утверждение надо приложить достаточно усилий. Заниматься этим не вижу смысла, хотя и уверен, что просто статистически такие проекты найдутся. При этом ты всегда сможешь сказать, что проект бесполезен и на него нет смысла смотреть.

Что-то похожее на JBCL на Расте уже есть?

Да, я считаю тесты частью проекта. Если они написаны на каком-то другом языке - ну ОК, тогда это проект написанный на нескольких языках

Можно два-три-пять-десять раз протестировать одну функцию, но больше от этого она делать не станет. Можно сделать один глобальный тест с минимумом кода, который покроет большую часть фич — и меньше от этого проект делать не станет. Потому тесты плохо отражают функциональность проекта и включать их объем в оценку сложности кода не имеет смысла.

В любом случае, мне чтобы опровергнуть это утверждение надо приложить достаточно усилий. Заниматься этим не вижу смысла, хотя и уверен, что просто статистически такие проекты найдутся. При этом ты всегда сможешь сказать, что проект бесполезен и на него нет смысла смотреть

Да, тебе нужно будет приложить много усилий, потому что доля таких проектов-исключений мала (если они вообще существуют). Что я и имею в виду под подтверждением моих слов. А вот по поводу «проект бесполезен» я пока что даже не намекал.

Что-то похожее на JBCL на Расте уже есть?

Что это? Оно даже не гуглится.

Библиотека виджетов для оконной среды.

нет, у раста с графикой только зайчатки, все руками, оставайтесь на джаве, для такого «продакшена» он еще не «рейди»

Про Qt зачотне. Что уважаемый Дон скажет по поводу GTK?