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

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

В С++ завезли некую «поддержку» сборки мусора (declare_reachable и т.д.), но что-то я не слышал о реализациях. Правда активно и не следил. Но всё-таки думаю, что не всё так просто.

но большая часть реализации все равно сделана в unsafe.

Как посчитал? (:

string_view еще не забанили в стандарте?

Да ты что. Это же наоборот относительно свежая и полезная штука. Наоборот: завезли span (аналог слайсов).

Да, это приятная особенность раста. Но это капля в море.

А какие именно сущности тебе кажутся именно бесполезным усложнением?

Я сам не фанат наследования, но подструктурное наследование мне нравится, то есть, использование куска структуры как аргументу у функции другой структуры. Естественно, такой подход улетает в дикий unsafe на transmute.

Такой подход просто не будет в общем случае работать: компилятор раста имеет право переупорядочивать поля структуры. Можно, конечно, попросить поведение как в С (#[repr(C)]), но не уверен, что стоит просто ради такого хака. Если структуры связаны, то почему бы это и не выразить кодом?

struct A {
    ...
}

struct B {
    a: A,
    ...
}

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

они проигнорированы в расте

Например?

Переполнение в арифметике? Обрабатывать каждую операцию было бы чересчур. В этом плане мне нравится подход С# с их checked/unchecked, но он на исключениях.

Или ты об OOM? Учитывая overcommit подход не так уж плох. Да и думаю, что после недавней истории с ядром прикрутят возможность обрабатывать нехватку памяти.

или реализованы в виде паники

Так ведь ты этого и хотел?.. Но вообще есть инструменты, которые помогают с этим бороться. Включаешь нужные линты у clippy и он будет ругаться на [] и прочие штуки, которые могут паниковать.

Они просто забили на эту проблему, типа «и так сойдет».

Можно так сказать. А можно сказать, что здравый компромисс между удобством написания кода и «гарантиями». (:

Какой там страховки нет? Defer какой-нибудь есть, целостность указателей поддерживается через сборщик мусора. Что еще нужно?

В расте получив Result нельзя не обработать его. Нельзя написать код типа такого:

val, err := foo(...)
bar(val)

К слову, ты бы писал какой-нибудь 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)) }
        })

«Средняя»?

Предлагаю сравнивать с питоном для пущего драматизма

Предлагаю. Гугл сравнил и выбрал питон, бг-г-г.

но большая часть реализации все равно сделана в unsafe.

Как посчитал?

Оно прописано в rayon::prelude. Более ранние примеры без rayon вполне себе явно писаны на unsafe, вроде упомянутого мной;

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

В rayon все эти unsafe-ы засунуты сразу под интерфейс.

string_view еще не забанили в стандарте?

Да ты что. Это же наоборот относительно свежая и полезная штука. Наоборот: завезли span (аналог слайсов).

Да, правда, все-таки решили с ней жить:

https://github.com/isocpp/CppCoreGuidelines/issues/1038

Правда, уже завезли проверки времени жизни в шланг и MSVC:

https://pspdfkit.com/blog/2020/the-cpp-lifetime-profile/

А какие именно сущности тебе кажутся именно бесполезным усложнением?

На каждый чих, то есть, операцию, нужно перед компилятором делать три ку, чтобы он позволил твоей программе выполниться. «let mut», «unsafe», все типы в функциях опиши, да еще и с модификаторами. Поменялся тип — давай по кругу переписывай аргументы или пиши обобщения, что еще хуже. Паскаль требует конкретные типы, но он компилирует 200 тысяч строк в секунду! Чем эта тупая железяка занята во время компиляции, если она так медленно компилирует, но даже несмотря на это не может за меня додумать типы, их модификаторы, и проверить их на корректность. Как делает какой-нибудь хаскель. Хуже чем Раст по многословности разве что Ада:

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

К слову о том, почему на аде никто не пишет — там ты должен девять раз ку сделать для того, чтобы компилятор дал добро. Но в итоге Ариана все равно бабахнула — вот вам и «безопасность».

Такой подход просто не будет в общем случае работать: компилятор раста имеет право переупорядочивать поля структуры

А не все ли равно, какой порядок? Генерируешь новый экземпляр мономорфной функции под конкретную структуру — вот и все дела. Вплоть до копирования.

Если структуры связаны, то почему бы это и не выразить кодом?
struct B {
a: A,
...
}
Тогда можно будет отдать честную ссылку на подструктуру. Ну а если содержимое «случайно совпало», то может и правда не надо? Тем более, что в новой версии что-то может и поменяться

Go реализует такую композицию через делегацию (type embedding):

type B struct {
    A
}

И внезапно ты можешь дергать поля A как поля B.

они проигнорированы в расте

Например? Переполнение в арифметике? Обрабатывать каждую операцию было бы чересчур. В этом плане мне нравится подход С# с их checked/unchecked, но он на исключениях.

Да, ты все правильно понял, на исключениях. А есть еще вагон и маленькая тележка ошибок в стандартной библиотеке, которые тоже никак не возвращаются, а вместо этого кидают панику. И как бы получается, что Rust тоже вроде как работает на исключениях. Но с другой стороны и передачей ошибки возвратом. Это, между прочим, одна из ключевых причин, почему до сих пор Rust не принят для полноценного написания модулей в ядре Linux — там такие вольности поведения недопустимы.

В расте получив Result нельзя не обработать его. Нельзя написать код типа такого

Ну типа это обоюдоострый меч: плохо, что нельзя, и хорошо, что нельзя.

Да, люди мигрируют на шланг, потому что там адекватнее разработчики.

А мне нравится gcc.

В 2021 году они всё ещё поддерживают Windows XP: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100726

Andrew Pinski 2021-05-24 05:14:21 UTC Windows XP is bare min that is supported by newer GCC’s.

А clang прекратил поддержку в 2015: https://www.opennet.ru/opennews/art.shtml?num=42894

Clang 3.7 является последним выпуском с поддержкой Windows XP и Windows Vista, в Clang 3.8 требования к версии будут повышены до Windows 7

В С++ тоже любят говорить про «zero cost». Означает ли наличие не бесплатных абстракций, что нам врут?

С++ никогда в жизни не говорил про «zero cost». Ты не найдёшь этого в словах Страуструпа. Был и есть только «zero overhead».

https://en.cppreference.com/w/cpp/language/Zero-overhead_principle

Так что да, врут или ошибаются сами.

почти наверняка уже будет выпилена в C++23 :)

http://open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2186r2.html

В 2021 году они всё ещё поддерживают Windows XP: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100726

Пацаны на лоре заценят твои вкусы.

почти наверняка уже будет выпилена в C++23 :)
http://open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2186r2.html

Собственно, выпиливают только strict pointer safety, которую никто не использует, потому что она кривая by-design. GC никуда от этого не исчезает.

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

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

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

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

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

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

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

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

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

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

Предлагаю. Гугл сравнил и выбрал питон, бг-г-г.

Ну да, когда это удобно, то ставим плюсик питону за гугл. Вот только гугл и Go сделал и в С++ комитете состоит и в раст вкладывается. Думаю очевидно, что у них там зоопарк языков, да и вообще проекты сильно разные.

Оно прописано в rayon::prelude.

Что оно? Если библиотека предоставляет safe интерфейс, то так ли важно, что там внутри? Или у тебя есть доказательства, что в rayon абстракции протекают?

В любом случае, даже в rayon не большинство кода unsafe, это уже просто враньё.

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

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

«let mut»

Серьёзно? А писать const в С++ тебя не напрягает? Причём делать это приходится чаще, чем писать mut в расте. Ну если, конечно, не забивать на указания константности. Или предпочитаешь иметь всё мутабельным, главное пару лишних букв не написать?..

«unsafe»

Ну не пиши ансейф, делов-то.

все типы в функциях опиши

И это прекрасно. Когда я читаю код, то хочу понимать, что происходит, а не гадать как в питоне каком-нибудь.

Почему ты вообще за динамику не топишь? Вот уж где минимум «лишней писанины».

А не все ли равно, какой порядок? Генерируешь новый экземпляр мономорфной функции под конкретную структуру — вот и все дела. Вплоть до копирования.

Похоже я неправильно тебя изначально понял. То есть, имея struct A { ... } и struct B { A, ... } ты хочешь на второй структуре вызывать методы первой?

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

Например? Если их так много, то потрудись хоть парочку примеров привести что ли.

Ну типа это обоюдоострый меч: плохо, что нельзя, и хорошо, что нельзя.

И чем же оно в этом конкретном случае плохо? В расте ты тоже можешь проигнорировать ошибку, но это будет более очевидно из кода. А в Go val, err := foo(...) ни к чему не обязывает.

почти наверняка уже будет выпилена в C++23 :)

Забавно. А не знаешь: пользовался ли этими функциями ещё хоть кто-нибудь? Всё-таки в стандарт не тащат «на всякий случай». Значит кто-то был заинтересован?

HP вроде хотели целый GC добавить в С++. Но в С++11 попала лишь та часть, а дальше hp забили делать свой компилятор и так и не протащили (необязательный) GC в стандарт, а остальным это и не надо было.

https://www.hpl.hp.com/techreports/2009/HPL-2009-360.pdf

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

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

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

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

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

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

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

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

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

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

Что оно? Если библиотека предоставляет safe интерфейс, то так ли важно, что там внутри? Или у тебя есть доказательства, что в rayon абстракции протекают?
В любом случае, даже в rayon не большинство кода unsafe, это уже просто враньё

В Rayon большинство кода — это клей для итераторов на 14 тыс строк, где большая часть unsafe кода тусит в slice/mergesort.rs и slice/quicksort.rs — 30 unsafe на 1000 строк.

Ядро же rayon, которое и работает с потоками, содержит 60 unsafe-ов на 4000 тыс строк. По поводу того, мало ли это или нет? Когда я смотрю на вот такие «алгоритмы»

    pub fn spawn_handler<F>(self, spawn: F) -> ThreadPoolBuilder<CustomSpawn<F>>
    where
        F: FnMut(ThreadBuilder) -> io::Result<()>,
    {
        ThreadPoolBuilder {
            spawn_handler: CustomSpawn::new(spawn),
            // ..self
            num_threads: self.num_threads,
            panic_handler: self.panic_handler,
            get_thread_name: self.get_thread_name,
            stack_size: self.stack_size,
            start_handler: self.start_handler,
            exit_handler: self.exit_handler,
            breadth_first: self.breadth_first,
        }
    }

    /// Returns a reference to the current spawn handler.
    fn get_spawn_handler(&mut self) -> &mut S {
        &mut self.spawn_handler
    }

    fn get_breadth_first(&self) -> bool {
        self.breadth_first
    }

    /// Takes the current thread start callback, leaving `None`.
    fn take_start_handler(&mut self) -> Option<Box<StartHandler>> {
        self.start_handler.take()
    }

то понимаю, что 4000 строк они набрали не на реализации логики планировщика. Помнится, в таком стиле еще были ренжи для крестов написаны, когда на 5 строк алгоритма — 50 строчек вспомогательных объявлений.

Серьёзно? А писать const в С++ тебя не напрягает? Причём делать это приходится чаще, чем писать mut в расте. Ну если, конечно, не забивать на указания константности. Или предпочитаешь иметь всё мутабельным, главное пару лишних букв не написать?

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

И это прекрасно. Когда я читаю код, то хочу понимать, что происходит, а не гадать как в питоне каком-нибудь

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

То есть, имея struct A { ... } и struct B { A, ... } ты хочешь на второй структуре вызывать методы первой?

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

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

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

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

Например? Если их так много, то потрудись хоть парочку примеров привести что ли

Я приводил в начале треда пример с Arc, где с ходу получилось найти UB с дедлоком, которые закрыты assert-ами, но не до конца — дедлок остался. 25 тысяч assert-ов в стандартной библиотеке на 300 тыс строка кода — они пишут в достаточно близком к моему стилю так-то. Естественно, вылезет это всё только в рантайме, как на расте, так и на сишке.

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

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

А не знаешь: пользовался ли этими функциями ещё хоть кто-нибудь? Всё-таки в стандарт не тащат «на всякий случай». Значит кто-то был заинтересован?

JS пишется на крестах, и там нужно взаимодействовать с GC-кодом. Unity какой-нибудь тоже тесно взаимодействует с C#. Но по итоге конкретно упомянутыми фичами никто так и не воспользовался, потому их убрали из стандарта. Остальные функции для выделения GC-объектов никто не убирал.

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

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

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

то же делается в Си

struct A
{
   int member1;
};

struct B
{
   struct A;
   int member2;
}

открой для себя -fms-extensions

только без гарантий правильности доступа по указателю

без каких каких гарантий?

открой для себя -fms-extensions

Кайф. И да, MS является лидером во введении адекватных фич в Си. Они же сделали атомарную семантику для volatile, они сделали UB-безопасные функции для работы со строками, они сделали групповое компилирование с детектирование неизмененных файлов. А теперь я еще и про композицию анонимных структур узнал.

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

Чот сложились в линию факты, а именно — стремление того же гугла использовать узкий набор технологий для реализации всех проектов, и я осознал, что твой ответ может иметь несколько иную интерпретацию. Да, я прав по поводу того, что слишком иную технологию освоить будет тяжело. Проблема решена таким образом, что писать ты будешь на любом языке, на котором тебе прикажут писать. А прикажут тебе писать на Python, JS, Java, C++, во вторую очередь на каких-нибудь Go, Dart, Kotlin, или даже C#. И вместо того, чтобы инженеры мигрировали между компаниями — их мигрируют внутри одной компании. В каком-то смысле это тупо выгоднее.

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

Это показывает, как недалеко на самом деле ушли все современные-новомодные языки.

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

Сам придумал, что нас бесит? Лично меня бесит, что в расте нет исключений и нормального ООП.

И вообще: я абсолютно убеждён, что искусственные ограничения, нацеленные на code monkey, стратегически всегда проиграют фичастости, нацеленной на профи. (А уж если за надуманные ограничения надо вообще пороть.) Просто потому что сложную задачу реализовать примитивными средствами сложнее, чем средствами сложными. Гуглить статью «Закон сохранения сложности» на РСДН.

Недавно поржал, прочитав, что в go добавляют дженерики и исключения. Не долго же они продержались в рамках философии «простой язык для code monkey».

UPD. Что до безопасности, лично я за неё всеми четырьмя конечностями – если она не ограничивает меня в существенных для меня вещах, т.е. не даётся слишком большой ценой. (Полагаю, сказал за всех или почти за всех.) Например, на умные указатели в плюсах я переехал с большим удовольствием.

Выглядит похожим.

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

Если это правда, то разговоры о том, что «С++ свободен так как развивается комитетом, а раст - язык корпорации», которые любят заводить на лоре, звучат ещё смешнее.

Не звучат, потому что С++ развивается не одним только гуглом.

Для раста есть cxx, правда я эту штуку не щупал, не знаю насколько жизнеспособно.

Это прослойка к С с классами.

В С++ тоже любят говорить про «zero cost». Означает ли наличие не бесплатных абстракций, что нам врут?

При чем здесь С++? Речь идет про раст. Зачем вы пытаетесь переводить стрелки?

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

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

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

В раст вкатиться и начать выдавать приличный код куда проще чем в С++, при этом по скорости он особо проигрывать не будет. Можно апеллировать к тому что новый с++ тоже неплох, но он неплох до момента когда придется погрузиться в старый либо пытаясь что-то починить, либо натолкнувшись на ошибки реализации, короче в с++ нельзя вкатится не вкатываясь в его 30 летний бекграунд, ну хотя бы в 15 летний, с 03 стандарта начиная

Привычка - вторая натура, касательно «нормального ооп».

С одной стороны да, с другой – был уже один такой, которому нормальный ООП был поперёк жопы. Эйхом звали. И как он только не сдох от засранной тысячами разрабов кармы. В итоге мелкомягкие таки-впилили в TS классы.

Трейты ничем не хуже, очень похоже на интерфейсы джавы, плюс обобщенное программирование.

А, точно, у жавы с некоторых пор в интерфейсах можно задавать методы с default-реализацией, но нельзя задавать поля (состояние). В отличие от скаловских, которые по сути ничем не хуже классов со множественным наследованием. И как по мне, по сравнению со скалой это довольно дурацкое и неудобное ограничение. Вся эта священная борьба с наследованием реализаций – идиотизм: во-первых, оно в том или ином виде в итоге всё равно оказывается в языке, т.к. без него никуда (полиморфизм), только не в человеческом виде, а на костылях через жопу; а во-вторых и в главных, изгадить идиотской реализацией можно любую идею – о чём имеется столь же древняя, сколь и прекрасная цитата из статьи Фаулера «Is Design Dead?»:

«Суть в том, что часто паттерны используются чересчур активно. Известна история о программисте, который, прочитав в первый раз книгу Банды Четырех, ухитрился использовать 16 паттернов в 32 строчках кода. Помню замечательный вечер, подогретый всего-навсего одним стаканчиком солода, когда мы с Кентом набрасывали статью под названием «Не паттерны проектирования: 23 дешевых трюка», где рассказали о таких вещах, как использование оператора «if» вместо паттерна «стратегия». В каждой шутке есть доля правды. Паттерны нередко используются там, где без них вполне можно было бы обойтись, однако это не делает хуже саму идею. Весь вопрос в том, как вы их используете.»

В частности, для ООП (UPD: который тоже по сути является лишь паттерном) очень простой и в тоже время очень строгий критерий говнокода – несоблюдение LSP.

короче в с++ нельзя вкатится не вкатываясь в его 30 летний бекграунд, ну хотя бы в 15 летний, с 03 стандарта начиная

С этим спорить трудно. Как известно, программисты делятся на тех, кто освоил C++ когда тот ещё был простым, и на тех, кто его никогда не освоит. Хотя на cppcon одна известная в тех кругах крутая баба-преподша вполне убедительно (по крайней мере на первый взгляд) объясняла, как надо нынче обучать новичков плюсам: в жопу const char* и прочую адресную арифметику, юзаем string как чёрный ящик. Т.е. она даёт плюсы как высокоуровневый язык. (UPD3: И в этом качестве современный C++ наверняка можно дать как вполне себе безопасный.)

Что до меня, то т.к. я из первой категории (коммерчески писал на плюсах в середине 90-х … начале нулевых) и вообще байтодрочер, то для меня существенно, что на плюсах я могу писать и в раст-стиле, и не в раст. (UPD2: Например, buildtime-часть моего веб-сервера – на высокоуровневом C++, а runtime – байтодрочерская на «C с классами».) Кто-то то ли на реддите, то ли ещё где-то выдал очень понравившийся мне камент: что раст он юзать не будет, но изучал не зря: будет более осмысленно писать на плюсах.

И как по мне, по сравнению со скалой это довольно дурацкое и неудобное ограничение

Причём я сталкивался с неудобством жавовских default-реализаций без состояния на практике: нужно было присобачить к классу какой-то вспомогательный mixin, добавляющий несколько новых методов, делегирующих куда-то к другому объекту. А вот объект-то как раз в интерфейс не впихнуть (в отличии от скаловских trait-ов).

UPD: Во, вспомнил: это были две параллельные иерархии сущностей: для основной базы и архивной. Поскольку у разрабов системы – хибер головного мозга, использовать один класс для двух таблиц одинаковой структуры но с разными именами было нельзя. И суперклассы у всех этих сущностей уже были. Мечталось хотя бы общий код из этих классов вынести в общий trait, и делегировать к нему. Но из-за ограничений языка пришлось этот код копипастить.

Это же совершенно разные проекты с разными задачами, зачем сравнивать время их сборки?

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

Вы про это?

Очередного обсуждения Rust тред (комментарий)

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

Вот два эмулятора терминала, китти (на С) гораздо более функциональный, другой на расте.

https://pastebin.com/ptakPwje

Во первых в kitty более половины кода на питоне. Во вторых С это не С++, конечно С собирается быстрее, но почему-то мало людей хочет писать прикладной софт на чистых сях, а за плюшки плюсов приходится платить.

Этот пример показателен. Вроде бы программы выполняют одну задачу, но одна из них наполовину из скриптов, которые не надо компилировать. Так что я продолжаю считать, что такие сравнения некорректны и не информативны. Нужно реализовать один и тот же алгоритм на С++ и на Rust и проверить время компиляции. Я это делал, Rust получился существенно быстрее плюсов.

Во первых в kitty более половины кода на питоне

Часть внутренних функций.

Во вторых С это не С++, конечно С собирается быстрее

И с++ быстрее. Вот с консолью.

https://pastebin.com/pjLqKX53

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

Можете собрать компилятор раста.

HP вроде хотели целый GC добавить в С++.

Ничего себе, совсем мимо меня прошло. Ссылку добавил в закладки, как-нибудь почитаю подробнее. Даже интересно поменялось бы что если бы GC в стандарт таки протащили…

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

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

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

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

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

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

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

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

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

так Д же есть, вот приблизительно оно бы и вышло.

Лично меня бесит, что в расте нет исключений и нормального ООП

Бесит, что нет горечи и нет приятного вкуса крови во рту?

Недавно поржал, прочитав, что в go добавляют дженерики и исключения. Не долго же они продержались в рамках философии «простой язык для code monkey»

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

В Go полиморфизм ввели не с той стороны, необобщенные интерфейсы довольно многословно описывают средний алгоритм в вакууме. А если есть обобщения, то сами интерфейсы уже становятся не нужны. Примерно как в Rust, где trait по сути является именованным обобщением.

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