Hacker News Digest

В статье разбираются рекурсивные макросы в C, которые автор называет самой неприятной частью языка, несмотря на его 60-летнюю историю успеха. Макросы критически важны для многих систем, так как позволяют абстрагировать сложность, добавлять проверки и обеспечивать безопасность, но их система имеет серьёзные ограничения. Основная проблема: макросы в C не поддерживают рекурсию, что, по мнению автора, могло быть как случайностью эволюции системы, так и сознательным решением для предотвращения бесконечных циклов компиляции.

Автор мотивирует необходимость рекурсивных макросов возможностью обрабатывать переменное количество аргументов, что особенно ценно для создания безопасных вариадических функций. Цель статьи — создать макрос, считающий количество аргументов, что позволит автоматически добавлять проверки и избегать ошибок, связанных с ручным подсчётом. Хотя система макросов кажется устаревшей, она остаётся единственным механизмом компиляции времени в C, делая изучение этих техник важным для разработчиков.

• Обсуждение охватывает историю и ограничения препроцессора C, включая его влияние на языки C и C++, а также затрагивает вопросы безопасности (DoS-риски) и читаемости кода.
• Участники обсуждают, что препроцессор не предназначен для сложной метапрограммирования, и что современные языки предлагают более безопасные и выразительные альтернативы.
• Также обсуждается, что хотя препроцессор и может быть использован для продвинутых задач метапрограммирования, он требует нестандартных и сложных приемов, что делает его использование непрактичным и потенциально опасным.
• Некоторые участники упоминают, что препроцессор может быть использован для создания сложных макросов, которые могут быть использованы для создания DSL или для экспериментов с синтаксисом языка, хотя это может быть опасным.
• В целом, обсуждение подчеркивает, что хотя препроцессор может быть использован для сложных задач, он не предназначен для этого и что современные языки предлагают более безопасные и выразительные средства для решения таких задач.

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

Исследования показывают, что некоторые языки с зависимыми типами, такие как Idris, сохраняют часть информации о типах во время выполнения. Это позволяет выполнять проверки типов во время выполнения, открывая новые возможности для метапрограммирования и рефлексии. Однако такая сохранение типов увеличивает размер исполняемых файлов и может снижать производительность.

• Обсуждение показало, что зависимые типы (dependent types) — это не только академическая концепция, но и практически применимы в языках вроде Zig и TypeScript, хотя с ограничениями.
• Участники обсуждали, что в TypeScript условные типы и в Zig comptime демонстрируют схожие с зависимыми типами идеи, но не покрывают полный спектр возможностей зависимых типов.
• Были подняты вопросы о том, что такое "зависимые типы" и как они отличаются от обычных обобщённых типов, с упором на то, что в большинстве языков нет полной поддержки зависимых типов.
• Обсуждались примеры, где тип возвращаемого значения может зависеть от входного значения, и как это может быть реализовано в разных языках.
• Также обсуждались границы между статическим и динамическим анализом типов, и как они влияют на возможность компилятора вычислять и оптимизировать код.

LISP просуществовал 21 год к 1980 году, потому что представляет собой приблизительный локальный оптимум в пространстве языков программирования. Маккарти отмечает, что язык накопил некоторые "балластные" элементы, которые следует устранить, и упустил возможности для улучшений. Языку помогло бы совместное обслуживание, особенно в создании и поддержке библиотек программ. Компьютерно проверяемые доказательства корректности программ теперь возможны для чистого LISP и некоторых расширений, но для полного использования математической основы языка требуется больше теории и упрощения самого языка.

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

• Обсуждение показало, что Lisp и его диалекты всё ещё живы, но в нишевых формах: от Clojure на JVM до CHICKEN Scheme, компилирующего в C.
• Участники отмечают, что язык остаётся мощным инструментом, но его экосистема и сообщество сильно сократились, и нет признаков возвращения в мейнстрим.
• Некоторые подчеркнули, что Lisp-языки всё ещё важны для AI-исследований, генетического программирования и метапрограммирования.
• Сообщество отметило, что популярность языка упала не из-за технических причин, а из-за смены парадигмы в разработке ПО от символического AI к нейронным сетям и статистическому программированию.

Zig — это современный язык системного программирования, который предлагает альтернативу C и C++ с акцентом на безопасность, производительность и простоту. Он исключает неопределённое поведение благодаря строгой проверке типов и управлению памятью без сборщика мусора, что делает его особенно привлекательным для низкоуровневых задач. Zig также предоставляет мощные инструменты для метапрограммирования и кроссплатформенной компиляции.

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

• Критики выражают сомнения в целесообразности использования Zig для крупных проектов из-за отсутствия гарантий памяти, как в Rust или Swift, и нестабильности языка до версии 1.0.
• Сторонники Zig отмечают его сильные стороны: простоту, явный контроль над выделением памяти, отличную совместимость с C и возможность писать код без использования кучи.
• Обсуждаются практические примеры успешного использования Zig в реальных проектах (Tiger Beetle, Ghostty), несмотря на нестабильность.
• Поднимается вопрос о своевременности выхода книги по языку, который всё ещё активно меняется, что может быстро сделать издание устаревшим.
• Утверждается, что безопасность памяти — это спектр, а не бинарный выбор, и что простота Zig может снижать количество логических ошибок в целом.

Проект предлагает необычный взгляд на C++ как на интерпретируемый язык, оспаривая традиционное представление о нём исключительно как о компилируемом. Автор демонстрирует, что с помощью современных инструментов и техник C++ можно использовать в интерактивном режиме, подобно Python или JavaScript. Это открывает возможности для быстрого прототипирования и экспериментальной разработки без необходимости полной перекомпиляции.

Ключевая идея заключается в использовании JIT-компиляции и REPL-окружений, что делает C++ более гибким и доступным для исследовательских задач. Такой подход может сократить время разработки и упростить тестирование идей, сохраняя при этом все преимущества производительности и низкоуровневого контроля, характерные для C++.

• Участники обсуждают техническую реализацию проекта, предполагая использование метапрограммирования шаблонов, DSL и специальных флагов компилятора (GCC/Clang).
• Высказывается недоумение и замешательство по поводу принципов работы проекта, а также желание получить более подробное текстовое объяснение.
• Предлагаются альтернативные инструменты для интерпретации C++ (Clang-Repl, Xeus cling, AngelScript).
• Несколько пользователей делятся положительными впечатлениями от видео и творческого подхода автора.
• Один из комментариев содержит ироничное замечание о значении слова "based" в данном контексте.

• Крис Латтнер (LLVM, Swift) делает новый язык Mojo, чтобы ML-код был быстрым и удобным.
• Проблема: GPU-ядра пишутся на CUDA/OpenCL вручную, медленно и зависят от одного вендора.
• Решение: язык с метапрограммированием и типами, который «знает» об аппаратуре и генерирует оптимальный код под любую платформу.
• Цель: один код → любой GPU/CPU, открытая экосистема, no lock-in.

• Mojo обещает «Python++, но быстрый», но до сих пор нет полноценных классов, а «полный суперсет» превратился в мягкое «всё ещё не Python».
• Лицензия проприетарная — для многих это стоп-фактор: «сделайте GPL или идите лесом».
• Экосистема Python неподвластна: все уже завязаны на PyTorch/CUDA, а Mojo пока не даёт причин мигрировать.
• Julia, Elixir/Nx, CuPy, Triton, Numba — всё уже умеют «быстро + GPU», без нового языка.
• Итог: Mojo выглядит технически интересным, но «ещё один закрытый язык» в 2025 году воспринимается как ненужный риск.

Плюсы Nim 2

• Память: по умолчанию ORC/ARC (RAII, деструкторы, move/copy), а не трассирующий GC. Можно --mm:none или --mm:atomicArc.
• Компилируется в C/C++/Obj-C/JS; выбираем компилятор (gcc, nvcc, …).
• Лёгкая интеграция: {.importc.}, {.importcpp.}, {.importjs.}, {.compile.} для сторонних файлов.
• Метапрограммирование: макросы, static исполнение кода на этапе компиляции, генерация CUDA.
• Краткость: мало шаблонного кода (чат на 70 строк).
• Производительность ≈ C/C++/Rust; поддержка SIMD, CUDA.

Минусы и подводные камни

• Генерируемый C/C++ код нечитаем — не цель проекта.
• Нет атомарных счётчиков в ORC по умолчанию (требуется флаг).
• Некоторые старые статьи/комментарии описывают Nim 1.x (GC по умолчанию).
• Синтаксис чувствителен к отступам и регистру (но это субъективно).

Мини-пример: простой key/value формат

import std/[tables, strutils]

type Config = object
  host*: string
  port*: int

proc loadConfig(path: string, T: typedesc): T =
  let data = readFile(path).splitLines()
  var kv = initTable[string, string]()
  for line in data:
    let parts = line.split('=')
    if parts.len == 2:
      kv[parts[0].strip()] = parts[1].strip()

  result.host = kv.getOrDefault("host", "localhost")
  result.port = parseInt(kv.getOrDefault("port", "8080"))

let cfg = loadConfig("app.conf", Config)
echo cfg.host, ":", cfg.port

Файл app.conf:

host = 0.0.0.0
port = 9000

Всё компилируется в один бинарник без GC-задержек.

• Пользователи отмечают редкую, но полезную возможность Nim — определять собственные операторы.
• Хвалят макросы, интегрированные в систему типов и перегрузку, сравнивая язык с «статически типизированным Lisp».
• Критика: сложности с Windows (Nimble-зависимости тянут GCC, Defender блокирует бинарники) и неоднозначная «фантастическая» интеграция с C++.
• Обсуждают объём JS-артефактов: для мелких примеров — десятки килобайт, но без оптимизации могут быть мегабайты.
• Для WASM рекомендуют компилировать в C и прогонять через Emscripten, но стандартные JS-биндинги не работают.
• Вопросы IDE: есть nimsuggest и быстрая настройка для Neovim, но плагинов для JetBrains почти нет.

• Zig вызывает интерес благодаря мощному comptime и «inline else», позволяющим абстрагироваться без рантайм-оверхеда.
• Участники сравнивают его метапрограммирование с C, D и Rust, отмечая, что похожие идеи уже были, но Zig может сделать их популярнее.
• Главный упрек Zig — отсутствие гарантий memory- и data-race safety, из-за чего многие считают его неподходящим для многопоточного кода.
• «comptime unreachable» воспринимается как способ доказать компилятору недостижимость кода, а не как runtime-assert.
• Некоторые считают, что язык ещё нестабилен и экосистема незрела, поэтому широкое внедрение отложено.

Whenever I start to feel like a real programmer making games and webapps and AI-enhanced ETL pipelines, I inevitably come across the blog post of a C++ expert and reminded that I am basically playing with legos and play-doh. I had to do a UML thing for the first time in years for