Команда разработчиков Rust запустила опрос по производительности компилятора

Каждый из них надо собрать.

Потому что в rust не завезли shared libraries и каждый бинарь тащит свою неповторимую версию всего на свете.

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

Там сериализация всего на свете в многомегабайтный жсон происходит при каждой компиляции, после чего этот {} высер долго и нудно парсится.

Потому что кто-то решил, что иметь бинарный объектник - недостаточно молодёжно

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

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

Потому что был так спроектирован.

Современные компиляторы могут медлить из-за:

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

Неудачном языке реализации, типа - на функциональном с динамическими типами, со сборкой мусора(хотя это и не так важно), и слишком абстракном и далеким от железки.

Изьянов самого языка - навроде хидеров в си. которые есть просто текстовые подстановки и компилируются по новой всегда(если не сделана прекомпиляция заголовков).

Шаблонизации и ее неумеренного и неправильного использования, плюс слишком больших файлах шаблонов. и это основной тормоз си++.

Глубокая оптимизация, что заметно медлит компиляцию, но это не столь страшно, поскольку релиз редок, а основная разработка идет в режиме отладочной оптимизации максимум или вообще без нее. То есть оптимизации всерьез и нет.

глянул я исхожники rust, бардак в исходниках полнейший.

Я не погромист, я собираю пакеты. Меня не устраивает скорость сборки из-за кучи зависимостей.

а так же в 5-10 раз безопасней C++ и рассказывает в 10-20 раз более понятные ошибки

Сомнительный аргумент, может просто попробовать читать что выводит компилятор то же gcc или clang. Ни разу затупов не было. А если были то читаю доки на C++

Потому что в rust не завезли shared libraries и каждый бинарь тащит свою неповторимую версию всего на свете.

я в шоке, и это современный язык

Даже Линус говорит, что shared libs – это ошибка эволюции.

Линус авторитетный человек, но все же shared libs позволять не разбухать приложению

И выкатывать фикс безопасности сразу для всех, а не пытаться дергать авторов, которые могли уже от старости умереть (для примера - openssl и их фиксы CVE с версиями v,w,x, etc)

Там тоже можно их резко уменьшить опцией?

–Xs

Как посудину назвали, так она и поплыла)

Внимание! Вкидываю новый мем: «заржавейка».

А надо было как у Высоцкого:

"Я скажу, что всегда на футболы хожу

На Спартак и слова восхищенья о брате…"

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

Гы, лол. Да, если выбрать этот вариант (причём даже не нажимая next), то финита-ля-комедия. Без удаления кук уже никуда не пройти.

Это и есть Zig? Ну тогда это как в анекдоте про Запорожский автомобильный завод, который решил выпустить клон автомобиля Порше. Заявлено, что он будет сочетать в себе цену Порше и качество «Запорожца». Модель будет носить имя «Запоршивец» :)

Это ж непонятнее, чем Си в его худших проявлениях. Вот эта точка перед фигурными скобками доставляет особенно. Не, Раст-то отказать, а это чудо отказать с особым цинизмом!

И таки на що Ви надеялись? :)

Плюсую. Это дичь полнейшая, если честно

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

Ну чо тут спорить, да и трудно мне. Я давно пишу на Си, как на основном языке, поэтому просто привык, да и глаз замылился. Наверное, есть язык с более читаемым синтаксисом, типа того же Фортрана. Проблема похожести синтаксиса, как мне кажется, не в том что кто-то будет пальцем тыкать, мол «он такой же, только голый» ((с) бандерлоги), а в том, что пользователи языка, имея Си в голове, будут использовать новый Си-подобный по синтаксису язык неправильно.

Вот эта точка перед фигурными скобками доставляет особенно.

Анонимная структура по месту и назначению. Пушка вообще.

База

Там сериализация всего на свете в многомегабайтный жсон происходит при каждой компиляции

Они конченные?

А можно сделать так, чтобы метод, определенный в теле класса не инлайнился? Желательно стандартными средствами.

спроси у дипсика, он знает все.

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

Зачем эти опросы? Собирали бы телеметрию и всё. Как это принято в отрасли. Опрос всегда даст ответ через призму личного восприятия конкретного разработчика. Т.е. искажённые данные.

Вроде бы монорепа и не плохо.

Но устаёшь воевать за каждый ченьдж со сборкой и тестами во всей монорепе.

При том что бывают промежуточные несобираемые состояния монорепы.

Ну у нас правило простое - master должен собираться. А что ты делаешь на своей ветке- твои приколы, главное чтобы на ПР бамбу смогло это собрать

Это и есть Zig?

Это я ещё не старался. :)

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

А чем именно он вырвиглазный?

const non_null_terminated_msg: [msg.len]u8 = msg.*;

А ты вот эту мешанину сходу понял?

Ну тут только конструкция msg.* не очевидна без контекста.

А в остальном всё понятно - объявляется типизированная константа типа «массив из u8 размера msg.len».

const arch_infos = [_]ArchInfo{
    .{
        .table = .{
            .name = "x64",
            .enum_name = "X64",
            .file_path = "arch/x86/entry/syscalls/syscall_64.tbl",
            .process_file = &processTableBasedArch,
            .filters = .{
                // The x32 abi syscalls are always at the end.
                .abiCheckParams = .{ .abi = "x32", .flow = .@"break" },
                .fixedName = &fixedName,
                .isReservedNameOld = null,
            },
            .header = null,
            .extra_values = null,
            .additional_enum = null,
        },
    },

Нравится?

Ну после JS не пугает. Там такие фрагменты обычное дело, только синтаксис в мелких деталях отличается.

А что конкретно не нравится именно тебе? Вопрос то был не в том, чтобы показать больше кринжа, а твоё мнение послушать.

Привыкшим к такому вывернутому синтаксису понятно. Что-то читаем справа налево, что-то слева направо. Ну бардак же в головах! В общем, https://www.eng.uwaterloo.ca/~comp03a/misc/humour/shootfoot.html

У них там JSON головного мозга что-ли? :)

Что-то читаем справа налево, что-то слева направо.

Здесь вроде всё по порядку читается. Насколько я понимаю, большинство «убийц Си» пытаются в той или иной форме имплементировать правила чтения Паскаля (и вроде бы еще Алгола), когда синтаксические формы в строке читаются линейно.

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

У сишечки уродский синтаксис на самом деле.

Ну после JS не пугает.

Вот это как раз и сильно настораживает. Людей с JS/JSON головного мозга нельзя подпускать к разработке строго типизованных языков программирования.

Запиши то же самое на Си.

сор­ти­руя ре­грес­сии про­из­во­ди­тель­но­сти

Сортируем регрессии, проводим опросы по производительности. Окей. Ускоряем компиляцию? Не, не слышали.

Это ответ в духе «у вас там негров линчуют». У Си своих грехов и неоднозначностей синтаксиса много. Какой-нибудь typedef указателя на функцию, возвращающий массив указателей на функции действительно может мозг сломать. Но часто ли такое пишут? Мне вот за 30 лет ни разу не пришлось.

А тут пытаются не упростить сложное, а усложнить простое. В результате объясняем неизвестное непонятным.

А ту пытаются не упростить сложное, а усложнить простое. В результате объясняем неизвестное непонятным.

Если мне без чтения доки по Zig строка понятна, то в чем именно сложность?

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

const u8  non_null_terminated_msg[msg.len];

NB! Если не считать, что за VLA в Си вообще убивать надо на месте.  

Сложность в точке перед скобками, в точке перед звездочкой. Семантика этой точки и скобок не ясна от слова совсем.

Зачем? На Си я бы вовсе писал бы это по другому. В Си кортежей нет.

Сложность в точке перед скобками

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

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

в точке перед звездочкой

Это вот непонятно, да. Но в любом языке есть что-то новое в синтаксисе.

Я вот как увидел оператор |> в каком-то из новых ЯП, так мне очень понравилась эта идея.

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

Это уже было. APL называется.

Я ж не говорю, что Zig плох. Zig непонятен с первого прочтения. Вот Go — понятен. Rust — ну вроде понятен в каждой строе, но потом начинается: а какая имплементация сегодня у этого интерфейса? Поскольку я не вижу за Zig killer-фичи и не вижу сходу класса задач, для которых zig «как родной» (что есть у того же Go с его Го-рутинами), то и непонятно, зачем эти «упражнения в синтаксисе».

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

Семантика этой точки и скобок не ясна от слова совсем.

Повторю, точка и фигурные скобки – создание анонимной структуры.

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

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

Ненависть я испытываю только к Виндовзз и Биллу Гейтсу лично :) А остальными инструментами предпочитаю пользоваться по назначению, удобству и потребности. Поэтому, если понадобиться — ну будем посмотреть, зачем понадобилось. :)

Дальше а чего оно на алиасинге константные данные портит, на финальной стадии да когда они из релиза в релиз прекратят апи ломать…

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

Just for fun лучше писать на чем-нибудь из другой парадигмы. Вон хоть на Хаскелле.

И чем это тогда лучше, чем пачка маллоков в мейне?

Твой аллокатор должен реализовать четыре функции: alloc, realloc-мамой-клянусь-без-аллокаций, realloc-классический и free.

Предположим, тебе надо распарсить строку JSON в DOM. Ты создаешь аллокатор как арену, и где free() не выполняет никаких действий. Передаешь этот аллокатор в свою функцию парсинга (если парсинг рекурсивный, то делаешь структуру контекста с аллокатором и DOM-аккумулятором). Как с полученным DOM поработал, так просто грохаешь арену. Сокращает уйму процессорного времени.

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

И да, если стоит однократная задача парсить JSON в DOM, то Си-подобные языки с ручным управлением памятью — явно не лучший выбор. А если такая задача возникает каждый раз (при обработке REST-запросов, например), то у вас явно что-то с архитектурой. Или надо делать отдельное приложение под это, и тогда пофигу, что у него с потреблением памяти, или менять формат передачи данных.