Философия Glyphc

Glyphc соединяет системное программирование и машинное обучение в одном пути: от читаемого исходника к нативному C/CUDA-артефакту, который можно проверить, отладить и изменить.

Glyphc — это не «ещё один язык» и не попытка заменить Python, PyTorch или LLVM одним универсальным инструментом. Это единый toolchain для двух связанных, но специализированных языков:

• Glyph (.glyph) — системный язык с явным владением памятью, статической проверкой и читаемым C-эмитом;
• NeuralScript (.ns) — типизированный DSL для описания небольших статически известных вычислительных графов с CPU/CUDA AOT-кодогенерацией;
• glyphc — общий компилятор, CLI, LSP, тестовый runner и distribution point.

Сейчас общий toolchain и общая инфраструктура уже реальны. Полностью единый IR для обоих языков — направление развития, а не утверждение о текущей реализации.

Зачем существует Glyphc

Python удобен для экспериментов, но часто скрывает стоимость memory layout, dispatch, запусков и GPU-операций. C/C++ дают контроль над железом, но могут превращаться в хрупкий, слабо проверяемый слой вокруг ML-графа.

Glyphc строит мост между этими мирами:

• программист может оставаться рядом с hardware и memory layout;
• модель описывается как типизированный граф, а не как набор строковых вызовов;
• Python runtime и PyTorch bindings не являются обязательными;
• результат можно прочитать, скомпилировать обычными инструментами и встроить в C/C++-приложение.

Мы не обещаем убрать Python, CUDA, libc или системные зависимости. Мы убираем необходимость в тяжёлом промежуточном слое, который мешает видеть исходный код, сгенерированный код и поведение железа.

Четыре фундаментальных принципа

1. AI-First и читаемость человеком

AI-first означает структуру, удобную для машинного чтения, а не гарантию, что LLM никогда не ошибётся.

В проекте для этого используются:

• явные маркеры @module, @fn, @struct, @enum;
• фиксированная структура network, layer, forward, train и grad;
• контракты-клозы #guard;
• машинно-читаемые diagnostics с line:column;
• детерминированный codegen;
• отсутствие скрытой семантики там, где достаточно явной конструкции.

Эти элементы создают attention anchors для человека и LLM: модель видит границы функций, модулей, типов и вычислительных этапов вместо того, чтобы угадывать намерение по свободному тексту.

Правильная формулировка:

Glyphc оптимизирован для AI-assisted development, но correctness всё равно проверяется компилятором, тестами и человеком.

2. Hardware-First и Zero-GC

В Glyph нет tracing garbage collector. Владение памятью и освобождение ресурсов выражены явно, а flow-sensitive анализ отклоняет некоторые опасные операции вроде повторного free() или использования освобождённого значения до переприсваивания.

Текущая модель включает:

• явное освобождение;
• drop(box);
• refcounted buffers для List и Map;
• статический анализ потока использования;
• отсутствие обязательного GC runtime.

Полные scope-based RAII и move semantics пока не реализованы в объёме, достаточном, чтобы заявлять полную совместимость с ownership-моделью Rust. Это направление развития, а не скрытая функция.

AOT-пайплайн идёт через читаемый C/C++/CUDA-код. Это позволяет приблизиться к производительности сгенерированного C, но не является доказательством 1.0x–1.05x от «физических возможностей железа». Такие утверждения должны подтверждаться benchmark-протоколом на конкретной платформе.

3. ML-First: тензоры и autograd как типизированные данные

В NeuralScript тензор — это не строка и не безымянный массив. У него есть ранг, размерности, dtype и проверяемые связи между операциями.

Компилятор проверяет:

• совместимость формы операндов;
• ранг cross_entropy и classifier heads;
• соответствие входов и выходов network;
• размерности embedding, attention, normalization и dense layers;
• ошибки до запуска CUDA-кода.

В проекте есть символическое связывание и разрешение dimension aliases. Это полезный shape-механизм, но пока не следует называть его полной реализацией Union-Find для произвольных constraint-графов.

Автоматическая дифференциация задаётся блоками grad { ... } (не #grad), а fusion pass объединяет поддерживаемые группы вроде GEMM + activation + normalization. Это ограниченный, наблюдаемый codegen-pass, а не обещание автоматически оптимизировать любой граф.

4. Автономность deployment без ложного zero-dependency

Мы не называем систему полностью независимой от ОС: libc, pthread, компилятор, CUDA runtime и GPU driver по-прежнему важны.

Что действительно можно сказать:

• Python runtime не обязателен;
• PyTorch bindings не обязательны;
• tracing GC не обязателен;
• сгенерированный C/CUDA-код можно статически слинковать;
• C-ABI (ns_runtime.h) позволяет встроить результат в существующее C/C++-приложение.

Поддержка автономного inference 27B-моделей, cold-start 1.5–3 секунды и динамической библиотеки в один файл пока являются целями развития, а не текущими возможностями v2.1.0.

Что Glyphc сознательно не обещает

Эта таблица — часть дизайна, а не юридический дисклеймер. Она защищает проект от обещаний, которые невозможно проверить.

Сильные стороны

1. Уникальное сочетание: системный язык и специализированный AOT ML DSL используют один toolchain.
2. Инспектируемость: C/CUDA-результат остаётся исходным кодом, который можно прочитать и изменить.
3. Явная память: нет обязательного GC и неявных пауз, за которые отвечает runtime.
4. Статическая проверка форм: ошибки neural graph обнаруживаются до запуска тяжёлого обучения.
5. C/C++ интеграция: generated runtime можно использовать как C-ABI внутри существующей системы.
6. AI-friendly структура: строгие маркеры и стабильные diagnostics помогают LLM и инструментам анализа.
7. Воспроизводимость: sorted generic/constant emission и regression tests устраняют случайный порядок функций.

Слабые стороны

1. Scope шире, чем у большинства языков: systems и ML требуют разных специалистов и длинной дорожной карты.
2. NeuralScript пока не является полной заменой PyTorch: у него ограниченный набор операторов и статических форм.
3. Native fp16, ROCm и Metal ещё не являются полноценными production backend’ами.
4. C backend ориентирован на POSIX/GNU C; Windows binary release есть, но native Win32 runtime требует отдельной работы.
5. Экосистема, package manager и Marketplace-расширение ещё находятся на ранней стадии.
6. Производительность не должна заменяться маркетинговыми числами: нужны воспроизводимые hardware-specific benchmarks.

Формула продукта

Пиши системно. Описывай вычисления. Компилируй прозрачно.

English:

Write systems. Describe tensors. Compile both to native artifacts you can inspect.

Glyphc не пытается быть Python, PyTorch, LLVM и Rust одновременно. Его уникальная роль — нативный AI без обязательного Python-слоя, с типизированными графами и инспектируемым C/CUDA-результатом.

Направление развития

1. Стабилизировать memory model и опубликовать crate в crates.io.
2. Сделать NNS numerical test suite и расширить поддерживаемые операции.
3. Реализовать настоящий fp16/bf16 path либо окончательно обозначить его как experimental.
4. Добавить NNS LSP diagnostics, package management и VS Code Marketplace.
5. Расширить shape inference, включая rank-3+ случаи.
6. Принять решение по native ROCm и Metal, не выдавая placeholders за полноценные backend’ы.
7. Публиковать benchmark artifacts вместе с CPU, compiler и CUDA versions.