Васянский перевод https://github.com/ok-ryoko/multiring.zig/blob/a812375a84d64c7bf9dbec37b6b446e531e3b9d2/docs/DESIGN.md#choice-of-programming-language

# Выбор языка программирования

При работе с узлами в некоторых контекстах тип узла важен, а в других — нет. Таким образом, выбранный нами язык должен облегчить нам достижение полиморфизма, желательно над фиксированным ограниченным набором типов. (Существует только два типа узлов.) Размеченные объединения в Zig нам подходят идеально. Go предоставляет нам интерфейсы, но они слишком мощные — нам не нужно определять произвольное количество типов узлов. Более того, в Go нет встроенного типа для перечислений (они эмулируются с помощью построителя констант iota). Си предоставляет нам только глобальные (прим. пер.: без привязки к пространствам имён) перечисления.

Zig снабжает нас контрактом unreachable, а также синтаксисом захвата для разыменования опциональрых указателей (прим. пер.: судя по всему, это if (optional) |non_optional| { ... } ). Си и Go не предоставляют эквивалентных функций.

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

Мы ценим удобство сопровождения, поэтому считаем, что выбранный нами язык должен предоставить нам надежный опыт разработки. Go предоставляет выразительный интерфейс командной строки go, соедржащий команды для форматирования, анализа, создания и тестирования кода Go, а также управления модулями Go. Инструменты Зига выразительны, но не завершены: отсутствует (отдельный) инструмент статического анализа, а менеджер пакетов ещё не стабилен. С другой стороны, Си не предоставляет стандартизированных инструментов разработчика вообще, оставляя нам свободу смешивать и подбирать нужные нам компоненты, вплоть до реализации самого языка. Используем ли мы GNU Compiler Collection (GCC), Clang/LLVM или что-то ещё? Требуется довольно много времени для исследования разных выборов, которые мы, возможно, даже не задействуем.

Си уже более 50 лет, и он стабилен, используется повсеместно, а также имеет ряд международных стандартов и конкурирующих наборов инструментов. По состоянию на май 2023 года Си занимает 2-е место в индексе TIOBE. Go не так зрел, как Си (ему более 10 лет), но он стабилен и широко используется, занимая 12-е место в индексе TIOBE. Go занял свою нишу в экосистемах Интернета, контейнеров и утилит командной строки. Напротив, Zig не является ни стабильным, ни широко используемым. Выбор Zig вместо C и Go означает, что разработчику придётся выделить ресурсы для того, чтобы идти в ногу с последней стабильной версией языка и брать на себя риск внесения критических изменений. Это также означает уменьшение доступности проекта.

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

Змейка на Зиг с использованием семейства библиотек zig-gamedev. Лицензия Expat.

https://github.com/btipling/btzig-snake

#игры

Шаблон для Zig решебника Advent of Code, для master'а (сейчас 0.12.0-dev.1754+2a3226453). На 2023 уже первая задача есть https://adventofcode.com/2023 .

https://github.com/SpexGuy/Zig-AoC-Template

Сайт автора кстати http://zed.karelia.ru/go.to/feed.back/other , судя по всему TG у него нет)

обратный цикл без целочисленных знаковых типов (i32, isize т.д.):

// все типы начиная с u1.
const steps: u32 = 5;
// Работает в диапазоне [1, maxInt]

var i = steps - 1;
while (i < steps) : (i -℅= 1) {
    // Что-то делаем
}

Примерная логика такая:
i = 4
i = 3
i = 2
i = 1
i = 0
(переполнение) i = maxInt
maxInt >= steps, цикл стопается.

На большинстве (емнип?) архитектур без потерь производительности.

или так (диапазон тот же):

С новым годом всех!!! (у меня +6)
🦀🦀🦀 🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊⚡

https://github.com/spanzeri/vkguide-zig

Порт vkguide.dev на Zig

https://ziglang.org/news/2024-financials/

Финансовый отчёт за 2023 + призывают пожертвовать ещё)
#upstream

Тама стрим недавно закончилсч, с планом на 2024 год: https://www.youtube.com/watch?v=5eL_LcxwwHg

#upstream #видео

Если кто-то будет в Ульяновске / Питере, то я буду выступать с докладом про Зиг и эмулятор для MMORPG на Стачке 🙂

https://nastachku.ru

Даешь Зиг в массу :3

Бо‌льшую часть компилятора хотят вынести в отдельные файлы и компилировать по мере надобности прямо во время работы. Первым делом выносят zig fmt и zig reduce.

По идее, это позволит легче контрибутить в сам проект или патчить после установки (т.к. файлы прямо тут, в папке lib/), уменьшить размер всего набора пакетов Zig и уменьшить время сборки (хотя по сути оно будет просто „размазано” в рантайме, но учитывая что не весь код используется для компиляции, доожно быть несущественно).

Из того, что должны оставить: компиляцию нативным бэкендом и запуск дочерных процессов. Грубо говоря, если вы скачиваете Zig для x86_64 на Линукс какой-нить, в самом исполняемом файле "zig" будет только x86_64 backend и этот самый запуск, для Hello World этого хватит.
Но если вы захотите сделать zig fmt или скомпилировать с помощью aarch64 backend, он скомпилирует эти файлы в lib/ и будет уже ими управлять. Т.к. система кэширования уже есть, одного раза должно хватить (пока не измените там код).

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

#upstream

Полностью переработанный autodoc, там слишком много чего технического поменяли, так что пишу только то, что полезно самим пользователям.
https://github.com/ziglang/zig/pull/19208

Для документации стандартной библиотеки:
* До: Собирается за 13.3 секунды, ест гигабайт памяти, выхлоп 47 мегабайт.
* После: Собирается за 24 миллисекунды, ест 90 мегабайт памяти, выхлоп 12 мегабайт.

И ещё закрывает 9 issues. Из минусов: теперь требует поддержку WebAssembly в браузере, т.к. основная логика написана на Zig, который компилируется потом в WASM. Ну и часть нагрузки теперь перенесена с сборщика на браузер клиента. Зато несёт больше интерактивности.

> lib/docs/ziglexer.js was an implementation of Zig language tokenization in JavaScript, despite Zig already exposing its own tokenizer in the standard library. When I saw this added to the zig project, a little part of me died inside.

#upstream

Zig defer Patterns

#блоги

Думаю, большинство уже слышало про это, кроме errdefer comptime unreachable

https://github.com/ziglang/zig/pull/19459

Черновой запрос на слияние, добавляющий поддержку синтаксиса "labeled continue inside a switch", т.е. computed goto (таблицы переходов). Пример кода (немного упрощено, с новых тестов):

const std = @import("std");

const Tag = enum {
    a,
    b,
    c,
};

pub fn main() !void {
    const tag: Tag = .a;
    const result = brk: switch (tag) {
        .a => continue :brk .c, // 1
        .b => break :brk false, // 3
        .c => continue :brk .b, // 2
    };

    try std.testing.expect(result == false);
}

В этом примере, switch с меткой brk сначала перейдёт в ветку .a, которая говорит "продолжить и перейти в ветку .c*, которая тоже говорит "продолжить и перейти в ветку .b", где блок прерывается.

#upstream

Для понимания можно ещё проще пример сделать:

const bit: u1 = 0;

label: switch (bit) {
    0 => continue :label 1,
    1 => continue :label 0,
}

Тут получился обычный бесконечный цикл, где switch скачет от 0 до 1 и обратно.

Автор планирует добавить поддержку чисел, булевых значений, перечислений (enum) и помеченных объединений (tagged union), но не знает, нужно ли поддерживать error values.

Чем это отличается от обычного:

var tag: Tag = .a;
const result = brk: while (true) switch (tag) {
    .a => {
        tag = c;
        continue :brk;
    },
    .b => break :brk false,
    .c => {
        tag = b;
        continue :brk;
    },
};

В варианте с while-switch таблицы переходов может и не появиться, нет гарантий, это зависит от оптимизатора.
А в варианте с labeled continue она будет гарантированно создана во всех режимах сборки (в том числе Debug).

Ну и размер самой таблице зависит от того, какой тип принимает switch, т.е. в u8 или enum(u8) может быть до 255 вхождений, а в u16 уже 65 535.

Это всё включено в размер сгенерированного кода, поэтому при необдуманном пользовании бинарник может сильно распухнуть (ну как я понял), а при обдуманном хорошо так поднять производительность.

Я тут пока лазил в кишках компилятора (с @field химичу), заметил одну вещь: пропускать указатель (т.е. писать "ab.cc" вместо "ab.*.cc") можно не только в полях, но и в декларациях (типы добавил для наглядности)

const std: type = @import("std");
const std_ref: *const type = &std;

test {
    _ = std_ref.ArrayList(u8).init(std_ref.testing.allocator);
}

ZLS при этом молчит (ломается походу) и не даёт автокомплит для std_ref.

Сначала подумал, что у себя в форке что-то там сломал, но на мастер ветке то же самое.