> А дефер-то оказывается есть? А как же "no hidden control flow"!

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

В defer нет hidden control flow. Я описал выше почему. Ты его видишь в функции, он ЯВНЫЙ. А деструкторы неявные. И пока ты туда не заглянешь - не узнаешь что и как они там освобождают.

Более того постоянно приходится туда смотреть чтобы понять что именно там он освобождает. А ещё может выкинуть exception в С++. Ну в Rust, который содран с С++, всё +- также должно быть.

> Парирую троллинг пруфами)

Я там выше накидал пруфов как в безопасном языке в стабильной версии 1.44 можно сделать

let i: i8 = -1
let k: u8 = i

И получить "переполнение" или как там правильно это назвать. Настолько он безопасный) Тихо, незаметно, без ошибок.

> Т.е писать ты будещь в СИ стиле..

Выше я ОЧЕНЬ подробно написал насколько Zig безопасный, сколько гарантий и проверок он даёт (больше чем Rust) и что он БЕЗОПАСНЕЕ чем Rust.

Добавлю ещё const по умолчанию для всех параметров функций и переменных.

Он в сотни раз безопаснее С. Но при этом более низкоуровневый чем С! Или все эти проверки для тебя "тоже самое что и С"?)

Память ты ВСЕГДА менеджишь ручками в Rust и C++, просто неявно, это не managed языки.

И очень-очень плохо 😆 По простому это говнокод и костыли.

> Думаю мейнтейнары ядра тоже так подумали

Те в ядре норм что какой-то там деструктор будет рекурсивно (!) вызываться хрен знает когда, когда его даже не просили об этом?) Это там где есть обработчики прерывания и очень важен максимальный перформанс и надёжность?

Или мне нужно освободить страницу памяти КАК МОЖНО быстрее, я пишу page.Drop(), а потом деструктор всё равно вызывается, хотя он нахрен не нужен 😆 И внутри у меня стоит if (flag) { free() } чтобы он второй раз не освободил память 😆

Это из реальной жизни. Все эти "абстракции" типа "итераторы", "конструкторы/деструкторы", перегрузка операторов, перегрузка функций, шаблонные функции и весь template код всё это лютое #@&!.

Это лютейший over engineering. Для 2000х Rust был бы неплох.

У Zig это всё сделано значительно лучше. Даже типа строка нет. Потому что никаких строк нет нигде. Есть просто набор байт и их интерпретация (кодировка). Справится любая библиотека. Нет "методов", есть только функции с "сахаром" в виде объект.функция().

> Please note that Zig is not a fully safe language

Покажи мне ХОТЬ ОДИН в мире безопасный (по-настоящему) язык программирования. Знаю 20 языков программирования, и ни одного безопасного.

> Multithreading safety and race detection are areas of active research

Аналогично. Это active research не только в языке, а вообще в мире в индустрии. Или где-то решена эта проблема?

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

Lock-free алгоритмы даже в научных статьях неправильные, некорректные, с ошибками (не моё мнение, эксперта
)😆 Как говорится, welcome to real world, из однопоточного джаваскрипт-манямирка.

Вообще ты должен бы это всё знать, хотя бы на уровне "active research".

Это не значит что в языке не работают мьютексы или атомики. Это значит долгое вдумчивое ВГЛЯДЫВАНИЕ в код. И никакой Rust тебе не поможет. Или лови месяцами ошибку на тестах.

Это касается любого языка программирования где есть потоки.

> Более того говорят что operator overloading это плохо...

Ядро Linux - 40 миллионов строчек кода.

Ну-ка, расскажи мне про перегрузку операторов и на что ты там перезагружаешь операцию + ? Как-то не смог найти применение в жизни этой "фичи".

Вот складываешь ты int + int и всё хорошо, а потом тебе прилетает строка в шаблонную функцию и ты сравниваешь две гигабайтные строки 😆 Надёжно, быстро, безопасно 😆

Если ты про перегрузку функции - это бесполезная и глупая фича. Но иногда бывает полезна и нужна, иногда.

В Zig ты пишешь функцию, которая принимает аргумент anytype. И проверяешь этот тип как хочешь. И вызываешь для int +, для строк concat, и ничего для остального.

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

Это как если бы ты руками эти две функции написал.

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

Попробуй на Rust такое написать 😆

У С++ многие вещи только только появились, if constexpr и так далее

> In order to accomplish this, Zig programmers must manage their own memory, and must handle memory allocation failure.

А что, если у тебя памяти нет, Rust тебе как-то поможет? Или ошибки выделения памяти уже в Rust обрабатывать не нужно?)

> Нужно ли отказываться от ...

Я считаю что у Rust была хорошая задумка, а реализация полное ...

Будут лучше языки для ядра. Но Rust займёт его место, а зоопарка Торвальдс не допустит - остальные на помойку.

Если это не так, то в целом я ничего против не имею. Я так, набросил чтобы поспорить и поболтать, прокрастинация такая.

Но Zig для ядра лучше подходит.