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

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

Очевидно, что аллокатор как сущность должен стоять выше уровнем, чем жизнь объектов, которые он создает. Если в программе сделан event-loop, то все что в него попадает, должно пользоваться аллокатором из main(). (Концептуально вниз передается не аллокатор как сущность, а его интерфейс; сам аллокатор и интерфейс аллокатора поэтому требуют двух разных переменных для своего обозначения)

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

сам аллокатор и интерфейс аллокатора поэтому требуют двух разных переменных для своего обозначения

Ну, то есть, произошло что: в Си мы имеем скрытый аллокатор в библиотеке и его интерфейс в виде malloc/realloc/free/etc. Один штук (с поправкой на многопоточность). Хочешь свой аллокатор — пиши свой. В Zig мы имеем несколько аллокаторов искаропки и их один интерфейс. Ну хорошо, вытащили из библиотеки аллокатор наружу и сказали, как написать с ним рядом другой такой же.

Ладно, это все бантики, удобства и синтаксический сахар. Концептуально не поменялось ничего. Пока киллер-фич не видно. Остальное — вкусовщина. Ждем, пока перестанут апи ломать.

Пока киллер-фич не видно.

Отсутствие зависимости от Glibc и всех прочих рантаймов – не киллер-фича?

Комптайм

Встроенные юнит-тесты

Топовая обработка ошибок

Фигасе концептуально не поменялось. А что тогда для вас будет концептуальным изменением? Если оно само будет писать код по команде сделать зашибись?

Забавно, что когда я размышлял, как бы я перепроектировал стд либу для сишечки с нуля, там было именно это. Добрая идея, хорошо, что кто-то делает такое.

Отсутствие зависимости от Glibc и всех прочих рантаймов – не киллер-фича?

Смотря в чем.

Исторически глибца реализует интерфейсы к ОС-специфичным вещам. Поэтому в идеале, надо перепроектировать саму глубцу, вытащив это из неё в отдельный слой.

Отсутствие зависимости от Glibc и всех прочих рантаймов – не киллер-фича?

Что на практике означает зависимость от своего рантайма, в перспективе размером с glibc. Да напиши для gcc свой загрузочный стаб, так и любую сишную программу от glibc отвязать можно. Вот тот же Croco в своей книжке показал, как это делается.

Встроенные юнит-тесты

Не сказать бы, что это киллер-фича. Навязывает модель разработки.

Топовая обработка ошибок

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

Что на практике означает зависимость от своего рантайма, в перспективе размером с glibc

-rwxr-xr-x 1 glassy glassy 9184 Jun 18 20:13 my-shrink-path
glassy@rockpi:~/p/m/z/bin$ ldd my-shrink-path
        not a dynamic executable

Навязывает модель разработки.

Из-за бесшовного интеропа с С/С++ можно код писать на C/C++, а юнит-тесты к ним и билд-систему использовать на зиге.

но пахнет скрытым рантаймом в духе приплюснутых исключений.

Нет, там большой int-enum для ошибок, и наборы енумов поменьше объединяются своими названиями.

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

На деле мы имеем еще один си-подобный императивный язык со встроенными удобствами, синтаксическим сахаром и аллокаторами искаропки. Своего применения он пока не имеет из-за неразвитой инфраструктуры и отсутствия нативных библиотек на все случаи жизни. В том же Си на практике кроме glibc ничего и не нужно. Ну да для парсинга json есть что-то удобное, для динамических строк есть glib (не путать с glibc). Ну для всего буквально что-то да есть и в ассортименте. А для zig есть что-то свое для того же Постгреса, например?

Смена концепции — это смена парадигмы. Вот Го, хоть и императивный, но с интересной моделью процедур завершения, он имеет свое применение. А тут, ну на каком классе задач мне удобнее Zig? Джсоны парсить? Ну есть в Си удобные библиотеки для этого.

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

Типа удалили файл такой-то — сообщение должно быть таким-то на таком-то наборе правил.

Ну для всего буквально что-то да есть и в ассортименте.

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

Комптайм дает бесплатную рефлексию. Ты в коде называешь структуру Employee, делаешь там поля name и age. Отдельный модуль для работы с постгрес за счет рефлексии и на основании переданного типа создаст таблицу «Employee» с теми же полями, даст все методы для работы. JSON-парсер вроде есть в зиг-std.

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

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

Куда «запустила»-то?? На низкую околоземную орбиту?.. ;P ;))

Я себе проект на несколько сотен строк собирал от 2 до 5 минут в среднем

В тот же день, практически... ;D ;))

И чего они все жалуются, что «медленно»?? ;) :))))))

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

С языка снял…

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