Команда Zed перешла на новую облачную инфраструктуру под названием Zed Cloud, построенную на Rust и WebAssembly через Cloudflare Workers. Это решение заменяет старый бэкенд Collab, использовавшийся с основания компании, и призвано снизить операционные затраты на обслуживание сервисов, позволив команде сосредоточиться на развитии основного продукта. Cloudflare Workers обеспечивает простое масштабирование, а такие сервисы, как Hyperdrive для Postgres, Workers KV для временного хранения и Queues для асинхронной обработки задач, обеспечивают необходимую функциональность.

В основе новой системы лежит фреймворк с трейтом Platform, позволяющий писать код независимо от платформы, сохраняя при этом доступ ко всем возможностям Cloudflare Workers. Для этого реализованы две платформы: CloudflarePlatform для работы в продакшене и локальной разработки, и SimulatedPlatform для тестирования, имитирующей практически все компоненты системы. Такой подход обеспечивает гибкость и тестируемость всей инфраструктуры Zed Cloud.

• Обсуждение в основном вращается вокруг трёх тем: использование WebAssembly в облачных сервисах, сравнение производительности и стоимости Rust vs JavaScript в Cloudflare Workers, и перспективы FOSS альтернатив.
• Участники обсуждают, что на данный момент Rust в WASM всё ещё имеет существенные накладные расходы по сравнению с нативным кодом, но при этом отмечается, что Cloudflare Workers и Supabase Edge Functions предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in.
• Также поднимается вопрос о том, что хотя WASM в браузере может и не достигает нативной скорости, он предоставляет беспрецедентную переносимость и безопасность, что делает его идеальным для серверлесс вычислений.
• Наконец, участники высказывают, что хотя Cloudflare и Supabase предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in, но всё ещё остаётся вопрос о том, какие именно преимущества предоставляет использование Rust в WASM в контексте редактора кода, если учесть, что большинство пользователей не будут замечать разницу в производительности, но при этом будут страдать от ограничений вендора.

Представлена реализация eForth на C/C++ с кроссплатформенной поддержкой. Проект работает на Linux, MacOS, Windows, ESP32 и даже в WebAssembly (WASM), что делает его универсальным решением для различных систем.

Код проекта размещен на GitHub в репозитории chochain/eforth. Реализация eForth на C/C++ позволяет использовать этот язык программирования в широком спектре устройств - от настольных компьютеров до встраиваемых систем вроде ESP32, а также в веб-среде через WASM.

• Forth ценен для образования как альтернативный подход к вычислениям наряду с Lisp, демонстрирующий разные способы выражения программной логики.
• Классические реализации Forth на ассемблере противоречат идее 100% C/C++ с кросс-платформенностью, но язык остается простым для реализации с нуля, особенно на стековых процессорах.
• Производительность Forth часто страдает из-за цепочек вызовов подпрограмм, но возможна оптимизация через инлайнинг, использование регистров и native-код для критичных участков.
• Forth сохраняет нишевое применение в embedded-системах благодаря компактности и гибкости от низкоуровневого до высокоуровневого программирования.
• Сообщества вокруг таких языков могут предлагу уникальные решения, но иногда склонны к догматизму и пренебрежению другими подходами.

Проект linux-wasm добавляет поддержку WebAssembly (Wasm) в ядро Linux, позволяя выполнять Wasm-модули непосредственно на уровне ядра. Это открывает новые возможности для безопасного выполнения кода с производительностью, близкой к нативной, без необходимости в традиционных виртуальных машинах или контейнерах. Поддержка включает базовую инфраструктуру для загрузки и выполнения Wasm-кода, а также интеграцию с существующими подсистемами ядра.

Проект находится на ранней стадии разработки, но уже демонстрирует потенциал для создания более легковесных и безопасных систем. Wasm-модули могут изолированно работать в пространстве ядра, что снижает накладные расходы по сравнению с традиционными процессами. Это особенно ценно для встраиваемых систем, IoT-устройств и сценариев, где критичны безопасность и производительность. Разработчики могут использовать существующие Wasm-инструменты для создания кода, который будет выполняться непосредственно в ядре Linux.

• Проект демонстрирует высокую производительность Linux в WebAssembly, но содержит критические баги (например, ошибки доступа к памяти, паники ядра).
• Потенциальные применения включают облачные терминалы, научные окружения (Jupyter), тестирование дистрибутивов и образовательные цели, но требует оптимизации размера рантайма (<1 МБ).
• Техническое отличие от аналогов (container2wasm, XRSH) — отсутствие эмуляции CPU, компиляция бинарных файлов напрямую в WASM и использование WebWorker для процессов.
• Основные проблемы: отсутствие поддержки сетевых сокетов, сырых сокетов, JIT-компиляции и ограниченная совместимость с инструментами (например, Node.js).
• Участники отмечают образовательную ценность проекта и его влияние на развитие WebAssembly, но скептически оценивают массовое внедрение из-за текущих ограничений.

GHC теперь может работать полностью на стороне клиента в браузере через WebAssembly, демонстрируя значительный прогресс в разработке GHC WASM бэкенда. Это позволяет создавать интерактивные Haskell playground прямо в браузере без необходимости серверной части. Однако реализация имеет ограничения: используется байткод интерпретатор вместо компиляции в WASM, а cabal не поддерживается из-за отсутствия поддержки процессов. Для использования сторонних пакетов требуется предварительная компиляция через wasm32-wasi-cabal.

Проект сталкивается с некоторыми техническими вызовами, включая необходимость загрузки и извлечения около 50MB корневой файловой системы, что может вызывать временные зависания интерфейса. В некоторых браузерах, таких как Brave и Safari, возникают дополнительные проблемы с работой веб-воркеров. Тем не менее, эта технология открывает возможности для создания полностью интерактивных онлайн-курсов по Haskell и других веб-приложений, написанных на Haskell, работающих непосредственно в браузере пользователя.

• Обсуждение началось с вопроса о том, что WASM-версия GHC действительно запускает код в браузере, но не решает проблемы «бутстрапа» и воспроизводимых сборок, что делает Haskell невозможным для включения в дистрибутивы.
• Участники обсудили, что язык всё ещё жив, но отсутствие возможности полностью собрать его из исходников делает его «мертвым» с точки зрения дистрибутивов.
• Появились сомнения в том, что Haskell всё ещё актуален, и обсуждались ресурсы для изучения языка и практического применения.
• Также обсудили, что WASM-порт GHC демонстрирует прогресс бэкэнда, но не затрагивает проблему полного порта компилятора на новую архитектуру.
• В конце обсуждение сошлось на то, что язык всё ещё используется в продакшене и имеет практическое применение, а также что WASM может быть полезен не только в браузере, но и в других сценариях.

• DuckDB + S3 + WASM = браузер без бэкенда, но с потенциальными проблемами с памятью и стоимостью трафика.
• Пользователи спрашивают, где учиться таким техникам и как избежать OOM-крашей.
• Обсуждается, что S3 не так уж и дешёв при публичном доступе, а R2/Cloudflare и MinIO могут быть альтернативами.
• Появляется вопрос, как защититься от DDoS и нестабильности памяти в браузере.
• Участники делятся опытом, что DuckDB не всегда стабилен и требует тонкой настройки потоков и памяти, особенно при работе с большими данными.

Команда SpiderMonkey разработала новый инструмент для визуализации компиляции JavaScript и WebAssembly, создав собственный алгоритм расположения графов вместо использования Graphviz или Mermaid. Когда оптимизирующий компилятор Ion активен, система генерирует интерактивные графики, показывающие обработку и оптимизацию функций. Пользователи могут писать JavaScript-код и видеть в реальном времени, как изменяется граф, с возможностью навигации, масштабирования и просмотра различных этапов оптимизации.

Автор статьи не был удовлетворен выводом существующих инструментов, которые не отражали структуру исходного кода и создавали нестабильные макеты. Новый алгоритм, реализованный менее чем в 1000 строк кода, прост, быстр и produces высококачественный результат. Он учитывает специфические ограничения графов управления потоком, такие как наличие хорошо определенных циклов и необратимость потока управления, что позволяет создавать более интуитивные визуализации.

Для разработки автор изучал алгоритм Сугиямы, используемый в Graphviz, но создал собственное решение, специально адаптированное под нужды компилятора. Интерактивный инструмент значительно упрощает анализ и отладку сложных графов компиляции, позволяя отслеживать инструкции и блоки кода на разных этапах оптимизации.

• Обсуждение показало, что специализированные решения для визуализации превосходят универсальные инструменты вроде Graphviz, но сообщество продолжает использовать последние из-за инерции и отсутствия альтернатив.
• Участники жалуются на то, что Graphviz и подобные инструменты не справляются с задачами даже средней сложности, и что их использование часто требует ручной доводки.
• Проект Microdiagram нацелен на создание DSL для каждого типа диаграмм вместо одного языка для всех типов диаграмм.
• Обсуждение также затронуло вопросы производительности и надежности инструментов, а также то, что сгенерированные ими диаграммы не всегда читаемы без дополнительной ручной работы.
• Участники поделились ссылкой на исходники на GitHub, где можно найти код, который может быть использован как стартовая точка для собственных экспериментов в этой области.

Саймон Уиллисон на встрече Claude Code Anonymous в Сан-Франциско рассказал о дилемме между огромной пользой от запуска кодогенерирующих агентов с минимальными ограничениями и сопутствующими рисками. Он представил флаг --dangerously-skip-permissions (или "YOLO mode"), который, по его словам, превращает Claude Code в совершенно другой продукт. В обычном режиме требуется постоянное внимание и подтверждение действий, а в YOLO-режиме агент может самостоятельно решать сложные задачи, пока пользователь занимается другими делами.

За последние 48 часов Уиллисон с помощью YOLO-режима выполнил три проекта: развернул DeepSeek-OCR на NVIDIA Spark за 40 минут, создал демонстрацию работы Pyodide в Node.js для выполнения Python-кода в WebAssembly, и разработал инструмент для анализа репозиториев с помощью SLOCCount. Он подчеркнул, что многие недооценивают ценность кодогенерирующих агентов, никогда не испытав YOLO-режим во всей его мощи, но при этом выразил обеспокоенность потенциальными рисками предоставления ИИ таких широких полномочий.

• Обсуждение в основном вращается вокруг безопасности и ограничений при использовании LLM-агентов: участники обсуждают, насколько важно «сэндбоксить» их действия, чтобы избежать непредвиденных последствий, и какие именно границы должны быть установлены.
• Участники также обсуждают, какие именно ограничения накладывает Anthropic на своих моделей, включая то, что они не могут читать или редактировать файлы, запускать код, или использовать интернет без разрешения.
• Некоторые участники высказывают мнение, что Anthropic может быть слишком осторожна в ограничении способностей моделей, в то время как другие считают, что эти ограничения необходимы для безопасности и предотвращения злоупотреблений.
• Также обсуждается, как именно Anthropic тестирует свои модели на предмет безопасности и как они могут быть улучшены.
• Наконец, участники обсуждают, какие именно последствия могут иметь использование агентов без надлежащих мер предосторожности и какие меры предосторожности могут быть реализованы.

x86-64 Playground — это веб-приложение для экспериментов с ассемблером x86-64, сочетающее онлайн-редактор кода и отладчик в стиле GDB. Пользователи могут писать, компилировать и делаться кодом для популярных ассемблеров, включая GNU As, Fasm и Nasm. Уникальность платформы — возможность пошагового выполнения программ с инспектированием памяти и регистров, а также поддержка перетаскивания и отладки любых статических исполняемых файлов Linux без установки дополнительного ПО.

Приложение ориентировано на академическую среду и изучение бинарной эксплойтации, с интерфейсом, напоминающим GDB+PwnGDB. Разработчики уделили особое внимание мобильному опыту, сделав интерфейс адаптивным и позволяющим встраивать редактор и отладчик на другие сайты. Проект с открытым исходным кодом работает полностью на стороне клиента через Blink Emulator, что обеспечивает конфиденциальность и возможность работы офлайн после загрузки.

• Инструмент позволяет запускать x86-64 машинный код в браузере без бэкенда, используя модифицированный эмулятор blink.
• Проект ориентирован на обучение: интерфейс напоминает GDB, но не реализует продвинутые функции отладчика.
• Пользователи отметили проблемы с инструкцией lzcnt, отсутствие гайдов и неработающие ссылки «Share» и «Guides».
• Появились вопросы о поддержке других архитектур, включая 6502, Game Boy и ARM, а также о возможности GPU PTX.
• Сообщество отметило, что проект полезен как интерактивный учебный ресурс, но не заменяет полноценный отладчик.

Команда Jupyter представила Xeus-Octave - новый kernel для JupyterLite, позволяющий запускать GNU Octave прямо в браузере. GNU Octave - бесплатный аналог MATLAB, теперь доступный без установки благодаря компиляции в WebAssembly. Для решения технических вызовов потребовался специальный инструмент на базе LLVM Flang и Emscripten для компиляции Fortran-кода, а также реализация BLAS/LAPACK, где выбор пал на Netlib LAPACK из-за меньших сложностей сборки.

Ключевым препятствием стало обширное использование блоков общих символов Fortran во внутренних библиотеках Octave, таких как odepack. Версия LLVM v20 на момент тестирования не поддерживала общую символьную линковку для WebAssembly, что потребовало дополнительных усилий для преодоления этого ограничения.

• JupyterLite позволяет в браузере запускать ядра C++, Python, R, Lua, JavaScript и др. без серверной части.
• Octave и MATLAB — это два разных инструмента, и хотя Octave стремится к совместимости, он не является «клоном» MATLAB.
• Сообщество подчеркивает, что Octave — это полноценный язык для численных вычислений, а не просто «бесплатная замена MATLAB».
• Пользователи отмечают, что Octave и MATLAB различаются в деталях, но для базовых задач они взаимозаменимы.
• Обсуждение подняло вопрос о том, что Octave может быть полезен как встраиваемая библиотека, но это требует дополнительной работы.

The Tor Project выпустила альфа-версию Tor Browser 15.0a4, финальную перед стабильным релизом в конце октября. Ключевые изменения включают полное удаление встроенных ИИ-функций из соображений приватности, переименование 'meek-azure' в просто 'meek' для унификации, и улучшенную поддержку тёмной темы.

Важные технические правки: улучшено отображение CJK-иероглифов шрифтом Jigmo, управление WebAssembly теперь делегировано NoScript для совместимости с PDF, а индикатор протокола 'https' в URL-bar теперь всегда виден, как и в Firefox. Эти изменения завершают подготовку к стабильной версии.

• Mozilla и другие проекты продолжают внедрять AI-функции, что вызывает критику из-за конфликта с приватностью и философией открытого ПО.
• Пользователи жалуются на то, что Firefox и подобные браузеры всё больше становятся похожи на Chrome, теряя свою уникальность.
• Сторонники приватности и открытого ПО выражают обеспокоенность по поводу того, что Mozilla и подобные проекты всё меньше соответствуют своим принципам.
• Некоторые пользователи отмечают, что Mozilla всё меньше взаимодействует с сообществом и всё больше ведёт себя как корпорация.

Разработчики Zed анонсировали полноценную версию редактора кода для Windows. Теперь он доступен как в стабильной, так и в тестовой версии, причём последняя обновляется еженедельно. Zed на Windows использует DirectX 11 для рендеринга и DirectWrite для рендеринга текста, что обеспечивает нативное соответствие платформе.

Ключевая особенность — глубокая интеграция с WSL и SSH: пользователи могут открывать папки из WSL прямо в Zed, а все операции I/O происходят через удалённое соединение. Это распространяется на все функции, включая работу с Git, терминалами и отладчиками.

Расширения Zed, основанные на WebAssembly, работают на Windows без дополнительных настроек. Они изолированы через WASI, что обеспечивает безопасность и прозрачность работы с файлами.

Команда призывает пользователей тестировать Zed на Windows, особенно в контексте WSL, различных мониторов и сложных конфигураций клавиатур. Отзывы помогут ускорить фиксацию багов и улучшение платформы.

• Основные проблемы: отсутствие DevContainer, медленный LSP-ответ, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки

Седьмой выпуск журнала Paged Out! знаменует расширение его физического присутствия: печатные версии теперь распространяются на кибербезопасностных конференциях и демопати, а также доступны для покупки через print-on-demand сервисы. Редакция перешла на скриптовое оформление обложек для единообразия, сохраняя приверженность работе с художниками-людьми. Выпуск включает разнообразные технические статьи — от анализа уязвимостей в PDF и аппаратных модулей безопасности до экспериментов с WebAssembly и криптографией, включая даже исследование квантовой передачи ключей BB84. Особый акцент сделан на практических решениях, таких как создание самодостаточного распознавателя рукописных цифр и обход ограничений в системах вроде Wayland. Журнал остается бесплатным и открытым для распространения, включая аудиоверсии для слабовидящих.

• Участники высоко оценили журнал Paged Out!, отметив его интересный контент, качественное исполнение и ностальгические отсылки к старым технологиям.
• Обсуждалась конкретная статья о взломе камеры через звуковую волну (стр. 55/58), которая вызвала восхищение и напомнила о загрузке программ с аудиокассет.
• Были подняты вопросы о возможности печатной подписки и получении печатных копий, на которые создатели ответили, что это в планах, но технически сложно из-за параметров печати.
• Один из пользователей сообщил о получении спам-письма от Google Group, на что автор проекта отреагировал просьбой предоставить details для выяснения и решения проблемы.
• Некоторые пользователи выразили желание иметь печатную версию журнала, находя чтение PDF неидеальным, хотя другие отметили его высокое качество.

Разработчик перевёл свой проект детализированного градостроительного симулятора с Go на Deno, чтобы использовать веб-технологии без потери локальности исполнения. Идея в максимально точной симуляции городских процессов на основе реальных социологических данных, а не упрощённой игровой логики, как в классическом SimCity.

Deno с его встроенным инструментарием и возможностью компиляции в нативный исполняемый файл через webview_deno позволил интегрировать ThreeJS для 3D-вида и React для сложных интерфейсов данных. Это избавило от необходимости использовать Electron и сохранило цели автономности, мультиплеера и кросс-платформенности.

• Критика использования WebView2 из-за негативного восприятия пользователями установки Microsoft Edge и предложения альтернатив, таких как Tauri или локальные веб-приложения.
• Обсуждение технических подходов к созданию игр с использованием веб-технологий (Deno, Bun, WebGPU, React) и сравнение их производительности с традиционными движками вроде Unity.
• Вопросы о целесообразности и практичности выбора Deno в качестве основы для игрового движка, а не просто рантайма.
• Положительные отзывы о образовательной и градостроительной ценности игры, а также предложения по доработке механик и открытию исходного кода.
• Обсуждение бизнес-моделей и коммерческого потенциала инди-игр, созданных как "труд любви", в противовес стремлению к прибыли.

Современные колоночные форматы данных, такие как Parquet и ORC, созданные более десяти лет назад, не справляются с требованиями современных аналитических систем: они неэффективны для широких таблиц с тысячами столбцов, векторными эмбеддингами и большими бинарными объектами, а также не оптимизированы для случайного доступа или обновлений. Их ограниченная расширяемость и проблемы совместимости между версиями библиотек затрудняют внедрение новых методов сжатия, индексации и фильтрации.

Представлен формат F3, разработанный для обеспечения интероперабельности, расширяемости и эффективности. Ключевая инновация — встраивание декодеров в виде компактных WebAssembly-бинарников прямо в файл, что гарантирует совместимость на любой платформе без зависимостей от внешних библиотек. Это позволяет легко добавлять новые схемы кодирования через универсальный API, избегая необходимости переписывать формат при изменениях в обработке данных. Тесты показывают преимущества F3 в организации хранения и декодировании через Wasm по сравнению с существующими решениями.

• Обсуждение формата F3 сосредоточено на его использовании WebAssembly для встраивания декодеров в файлы, что обеспечивает будущую совместимость, но вызывает споры о производительности (10-30% замедление) и безопасности (риск вредоносных payload).
• Участники обсуждают преимущества и недостатки колоночного хранения данных по сравнению с другими подходами, а также сложности внедрения нового формата из-за инерции существующих экосистем (Parquet, ORC).
• Поднимаются вопросы о практичности формата, включая зависимость от WASM, увеличение сложности и потенциальные проблемы с обратной совместимостью интерфейсов для WASM-модулей.
• Отмечается участие известных экспертов (Уэс МакКинни, Энди Павло) как фактор доверия к проекту, но также выражается скептицизм по поводу его жизнеспособности и оптимизации.
• Обсуждаются альтернативы и похожие проекты (Vortex, Anyblox, Arrow), а также необходимость поддержки сообщества, коннекторов и интеграции с популярными инструментами для успеха F3.

Агенты ИИ, работающие с файловой системой, представляют угрозу безопасности, особенно в облачных средах. Злоумышленник может обойти защиту на уровне приложения и заставить агента раскрыть конфиденциальные файлы через системные вызовы. Решение — изоляция на уровне ядра, где сам Linux блокирует доступ к нежелательным ресурсам.

Анализ системного вызова open в ядре Linux показывает три точки отказа: do_open (поздний отказ), link_path_walk (средний) и path_init (ранний). Контейнеризация использует эти механизмы, создавая виртуальную файловую систему и пространства имён, чтобы скрыть реальные файлы от процесса. Это надёжнее, чем полагаться на фильтрацию ввода-вывода в приложении.

• Обсуждение методов изоляции и безопасности для AI-агентов, включая контейнеризацию (runc, podman), Landlock и WebAssembly как потенциальные решения.
• Критика предложенного подхода к песочнице как избыточной или неубедительной для экспертов по безопасности, с акцентом на использование существующих проверенных библиотек и методов.
• Уточнение требований к агенту для код-ревью: доступ только к кодовой базе, истории репозитория, диффам, CI/CD логам и системам отслеживания ошибок.
• Обсуждение практических сложностей реализации, таких как неподдерживаемые системные вызовы в gVisor и необходимость баланса между производительностью и безопасностью.
• Скептицизм относительно новизны и точности объяснения автора, с замечаниями, что описанные методы (chroot) не являются полноценной песочницей или контейнеризацией.

Разработан экспериментальный компилятор Scheme в WebAssembly, который автор сам называет «очень плохим» и минималистичным. Он написан преимущественно на C (97.2%) и способен преобразовывать код Scheme в валидный WASM-модуль, который затем можно запускать через Wasmtime.

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

• Упомянуты проекты на WebAssembly: минимальный OOP рантайм, Forth, компилятор в твите и книга о WebAssembly.
• Обсуждается компилятор Scheme в WebAssembly (Guile Hoot), его особенности и поддержка WASM-GC.
• Затронуты технические вопросы: возможность использования как интерпретатора, поддержка tail call и call/cc.
• Отмечается важность самодостаточных инструментов и независимости от платформ.
• Поднята тема различий между Asm.js и WebAssembly в контексте исторического развития.

Команда Wasmer анонсировала бета-поддержку Python в своей edge-платформе на базе WebAssembly. Это позволяет запускать популярные фреймворки вроде FastAPI, Django и Streamlit, а также библиотеки типа numpy и pandas — всё в песочнице с почти нативной производительностью. Ключевые улучшения включают динамическую линковку, поддержку сокетов, потоков и собственный индекс пакетов.

Производительность впечатляет: тесты показывают, что Python на Wasmer работает всего на 5% медленнее нативного, при этом обеспечивая изоляцию и портативность. Платформа уже обгоняет Cloudflare по поддержке мультитрединга и нативных модулей, а вскоре добавит полную поддержку PyTorch и других тяжёлых библиотек.

• Запуск Python в WebAssembly через Wasmer предлагает производительность, близкую к нативной, и обеспечивает надежную песочницу для выполнения кода.
• Обсуждаются практические применения: встраивание скриптов в приложения, серверные API (FastAPI, Django) и выполнение пользовательского кода в изоляции.
• Поднимаются вопросы о поддержке ключевых библиотек (numpy), асинхронности (asyncio) и межъязыкового взаимодействия (Python-JS).
• Отмечаются существующие альтернативы (Pyodide, контейнеры) и сложности с зависимостями, имеющими нативные расширения.
• WASM рассматривается как более простая и легковесная альтернатива виртуальным машинам и контейнерам для развертывания.

Аккаунт sgi-demos на GitHub содержит коллекцию демонстрационных проектов, связанных с графикой и технологиями Silicon Graphics. Эти материалы представляют историческую ценность, демонстрируя передовые для своего времени визуальные эффекты и интерактивные приложения. Многие примеры иллюстрируют ранние достижения в трёхмерной визуализации и компьютерной анимации.

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

• Участники отмечают схожесть интерфейса демо SGI с меню выбора файлов в Super Mario 64 и предполагают историческую связь через партнерство Nintendo и Silicon Graphics.
• Воспоминания о работе с оборудованием SGI (Indy, O2, Octane, Onyx) и различных демо, таких как Flight, jello, bounce, fsn (3D-файловый менеджер), и их влиянии на современные технологии.
• Обсуждение технических аспектов: нестандартное соотношение сторон экранов SGI, использование неквадратных пикселей, проблемы с отображением ссылок и производительностью в браузере.
• Ностальгические истории о розыгрышах с помощью удаленного воспроизведения звука (telnet, команда say) и случайном показе изображений от предыдущих пользователей на SGI O2.
• Упоминание культурного влияния SGI, включая отсылку к фильму "Парк Юрского периода" ("Это же UNIX!") и роль компании в развитии компьютерной графики и игровой индустрии.

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

В контексте генерации текста цепочки Маркова применяются для предсказания следующего слова на основе предыдущих. Автор, разочаровавшись в сложности и «магии» современных языковых моделей, обратился к этой прозрачной и фундаментальной технике, реализовав автодополнение на Rust и WebAssembly. Это подчёркивает ценность понимания базовых принципов вместо слепого использования сложных систем.

• Обсуждаются ограничения и природа марковских цепей: их линейность, неспособность учитывать контекст за пределами текущего состояния и проблемы с обработкой двумерных данных.
• Упоминаются исторические и юмористические примеры использования марковских цепей для генерации текста: Mark V. Shaney, KingJamesProgramming, спам-сайты и чат-боты в IRC/Slack.
• Проводятся паралле

Завершена работа над Wasm 3.0

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

Сегодня мы рады объявить о выпуске Wasm 3.0 как нового действующего стандарта. Это крупное обновление включает несколько важных функций, разрабатывавшихся до восьми лет.

• 64-битное адресное пространство. Память и таблицы теперь могут использовать i64 вместо i32, расширяя доступное пространство с 4 гигабайт до 16 эксабайт (теоретически). На вебе 64-битная память ограничена 16 гигабайтами, но для невеб-экосистем это открывает возможности для работы с огромными приложениями и наборами данных.

• Множественная память. Теперь один модуль может объявлять и напрямую использовать несколько областей памяти, включая копирование данных между ними. Это позволяет инструментам вроде wasm-merge работать со всеми модулями Wasm и открывает новые возможности для безопасности, буферизации и инструментирования.

• Сборка мусора. Wasm добавляет поддержку автоматически управляемого хранилища через сборщик мусора. Компиляторы могут объявлять layout структур данных через типы struct и array, а также нетипизированные целые числа — всё остальное, включая представление значений исходного языка, остаётся их ответственностью. Wasm предоставляет только базовые строительные блоки, избегая встроенных объектных систем.

• Типизированные ссылки. Расширение системы типов теперь поддерживает богатые формы ссылок, описывающие форму значения в куче, что избегает дополнительных проверок во время выполнения. Эта система также доступна для ссылок на функции, позволяя безопасные косвенные вызовы без проверок типа или границ через инструкцию call_ref.

• Хвостовые вызовы. Важный механизм для языковых реализаций, особенно функциональных языков и внутренних техник (например, заглушек). Вызовы полностью общие и работают как для статических, так и для динамических получателей.

• Обработка исключений. Ранее не было эффективного способа компиляции обработки исключений в Wasm. Теперь исключения определяются через теги с данными, могут быть выброшены и перехвачены обработчиками — новым видом инструкций блока с диспетчеризацией по тегам.

• Расслабленные векторные инструкции. (Описание сокращено)

• Переход на 64-битную адресацию по умолчанию снимает ограничения для ресурсоёмких веб-приложений, таких как видеоредакторы.
• Добавлена низкоуровневая поддержка сборки мусора (GC), позволяющая компиляторам управлять структурой данных.
• Сообщество выражает разочарование отсутствием прямого доступа к DOM и JS-объектам из WebAssembly.
• Множественные памяти и улучшенная типизация ссылок могут оптимизировать взаимодействие с API (например, WebGPU).
• Разработчики отмечают проблемы с опытом использования (DX) и сложность компиляции в WASM.
• Обсуждаются потенциальные применения новых возможностей для языков C#, Java, Go и Python.
• Остаются нерешённые вопросы, такие как работа на микроконтроллерах и поддержка сокетов.

• HTML: справка по элементам, глобальным атрибутам, форматам дат/времени, руководства по адаптивным изображениям, видео и аудио.
• CSS: справка по свойствам, селекторам, @-правилам, единицам измерения; гайды по блочной модели, анимациям, Flexbox, цветам; «поваренная книга» для колонок, центрирования, карточек.
• JavaScript: справка по встроенным объектам, операторам, функциям; гайды по управлению потоком, циклам, объектам, классам.
• Web APIs: File System, Fetch, Geolocation, DOM, Push, Service Worker; гайды по Web Animations, Fetch, History, Speech API, Web Workers.
• Другие технологии: Accessibility, HTTP, URI, WebAssembly, WebDriver, WebExtensions.
• Обучение: курс «Frontend-разработчик», основы HTML, CSS, JavaScript.
• Инструменты: Playground, HTTP Observatory, генераторы теней, радиусов, границ, палитра цветов.

• Участники обсуждают, как использовать тег <template> без фреймворков: он удобен для клонирования больших фрагментов, ускоряет рендер и снижает нагрузку по сравнению с React/Vue.
• Недостаток — приходится вручную связывать данные и DOM; многие хотят единого формата «HTML+CSS+JS» для компонентов.
• Shopify, Salesforce, MedusaJS и Alpine.js уже применяют <template> в продакшене, но спецификация HTML Modules пока не завершена.

AI-модели нуждаются в виртуальной машине

Современные приложения с ИИ включают модель в «обвязку», которая обеспечивает вызов инструментов, поиск контекста, безопасность и прочие сервисы. Первые чат-боты были простым REPL-циклом: запрос → модель → ответ. С появлением протоколов вроде MCP логика управления стала сложнее и требует свойств ОС: изоляции, расширяемости, переносимости, контроля доступа к файлам и инструментам.
Мы предлагаем рассматривать этот слой как виртуальную машину для ИИ-моделей (MVM), где одна из «инструкций» — вызов LLM. Это развязывает разработку моделей от кода интеграции и даёт «write once, run anywhere» аналогично JVM.

Зачем MVM

• Безопасность и приватность «из коробки», а не как дополнение.
• Повторное использование: любая модель подключается к экосистеме инструментов и политик безопасности.
• Переносимость: модель и политики можно поставлять и запускать в разных средах.

Пример работы

1. Пользователь: «Забронируй рейс».
2. MVM передаёт запрос модели.
3. Модель: «вызови booking-tool».
4. MVM проверяет, разрешён ли этот инструмент, и только потом вызывает его.
   Такой контроль есть в любом коммерческом ИИ-продукте; MVM выносит его в стандартизированную платформу.

Инструкции MVM

• загрузка/выгрузка модели и инструментов;
• вызов модели с контекстом;
• парсинг её ответа;
• вызов разрешённых инструментов;
• работа с памятью, историей, вводом пользователя;
• стандартные управляющие конструкции (if, seq, loop).

• Критики считают, что статья расплывчата: «VM для ИИ» сводится к обычной песочнице/контейнеру, а не к полноценной машине.
• Основная проблема — не инструменты, а разрешения: нужно точно ограничить, какие действия и данные доступны агенту, иначе он может, например, купить билет с 37-часовой пересадкой ради 3 $.
• Многие предлагают использовать уже существующие механизмы: Docker, отдельный пользователь, контейнеры, WebAssembly или capability-модель вроде Fuchsia.
• Часть комментаторов указывает, что продвинутые модели (ChatGPT Code Interpreter, OpenHands) уже работают в изолированных средах, но этого всё равно недостаточно.
• Итог: вместо новой «ОС для ИИ» нужно чёткое управление правами и данными; VM лишь метафора для этой задачи.

Плюсы 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 почти нет.

Создал две карточные игры на Go: без LLM — 3 месяца, с LLM — 3 дня

Truco без LLM (3 месяца)

• Начал 18 июня 2024, выбрал Truco — любимая игра детства.
• Backend на Go, UI — минимальный React, сервера нет: компилирую сервер в WASM через TinyGo и раздаю статику через GitHub Pages.
• Без LLM пришлось всё выяснять вручную: 3 месяца экспериментов.
• Игра живёт без рекламы и денег, но люди всё ещё играют.

Escoba с LLM (3 дня)

• Через год решил проверить, как LLM ускорит процесс.
• Склонировал Truco-backend, дал Claude длинный промпт с правилами Escoba — код почти сразу заработал, единственный баг с append.
• Frontend всё равно занял несколько дней: React + WASM-отладка.

Как повторить

1. Backend
   • Структура GameState, CalculatePossibleActions, RunAction, бот.
   • Компилируй в WASM: tinygo build -o main.wasm -target wasm .
2. Frontend
   • Создай игру, отрендери состояние, дай игроку выбрать действие, вызови бота.
3. Шаблоны
   • Форкни Tic-Tac-Toe:
     backend | frontend
   • Демо: играть

• Основной тезис: «написание кода никогда не было узким местом» вызвал споры; кто-то считает, что сложная механика, баланс и полировка требуют больше времени, другие — что код всё же тормоз.
• Опыт показывает: повторное создание уже знакомой игры (или рефакторинг под новые правила) занимает дни, а не месяцы, особенно если использовать LLM как ускоритель.
• Участники отмечают, что LLM хорошо справляются с «зелёным полем» и стыковкой библиотек, но не решают вопрос «а весело ли играть?» — это всё ещё требует живых тестеров и дизайнерской интуиции.
• Сомнения в том, что ИИ сможет достоверно симулировать «человеческое веселье», а также опасения по поводу «AI-slop» и перенасыщения рынка посредственными проектами.

Web Embeddable Common Lisp (WECL) — запуск Common Lisp в браузере через WebAssembly.
Проект экспериментальный; API нестабильны, баг-репорты не принимаются.
Исходники: fossil.turtleware.eu/wecl.

Быстрый старт

Подключите boot.js и wecl.js, пишите код в <script type="text/common-lisp">.
Пример считает обратный отсчёт и выводит «BOOM!».
Демо: easy.html | easy.lisp

JS-FFI

Набор макросов для вызова JavaScript из Lisp:

макрос	назначение
define-js-variable	переменная, выражение подставляется каждый раз
define-js-object	объект, сохраняется в хранилище
define-js-function	функция
define-js-method	метод объекта
define-js-getter/setter/accessor	чтение/запись поля
define-js-script	шаблон JS-выражения
define-js-callback	Lisp-функция, вызываемая из JS
lambda-js-callback	анонимный callback

Типы аргументов: :object, :js-ref, :fixnum, :symbol, :string, :null.

Emacs-интеграция

LIME/SLUG позволяет REPL и отладку прямо из Emacs.

Инъекция в любой сайт

Загрузка WECL в произвольную страницу через bookmarklet или расширение.

Ограничения

• Размер wasm-модуля ≈ 10 МБ (кешируется).
• Нет потоков, FFI неполный, производительность средняя.

Финансирование

Разработка поддерживается подписчиками Patreon.

• Обсуждение началось с альтернативной истории: если бы JS изначально был похож на Lisp, возможно, функциональное программирование стало бы мейнстримом раньше.
• Участники отмечают, что WebAssembly и Gambit-JS уже позволяют писать на Scheme/Common Lisp в браузере, улучшая DX и переиспользование кода.
• Некоторые сомневаются, что Lisp автоматически «функциональнее» JS, и подчеркивают, что императивный стиль часто естественнее.
• Поднимаются риски: рост размера рантайма, проблемы на медленных каналах и возможное доминирование Microsoft, если бы IE/VBScript победил.

Porffor — экспериментальный JS-движок, компилирующий код в WebAssembly и нативные бинарники. Вместо упаковки рантайма (как Node/Bun) он генерирует крошечные (<1 MB) и быстрые (миллисекунды) исполняемые файлы.

porf native hi.js hi   # 12.9 KB
./hi                   # 631 µs

Сравнение с Deno/Bun: размер 16 KB против 80–100 MB, старт в 631 µs против 15–37 ms.

Lambda

На AWS Lambda Porffor показал:

• Node (baseline): до 300 ms холодного старта.
• LLRT: ~3× быстрее Node, но дороже из-за отсутствия managed runtime.
• Porffor: ~12× быстрее Node и ~4× быстрее LLRT, при этом дешевле даже с учётом «managed runtime» Node.

P99 Porffor быстрее P50 у конкурентов.

Итог

Porffor ещё pre-alpha: поддержка JS ≈60 %, нет I/O и Node-совместимости. Подходит для маленьких лямбд без Node-API.
Код и данные бенчмарков: GitHub.

• Porffor — экспериментальный AOT-компилятор JS/TS → WASM → C, обещает убрать «холодные» старты Lambda и дать ~16 мс инициализации, но пока без GC, без полной совместимости с Node API и лишь ~60 % тестов ECMAScript проходит.
• Участники спорят, насколько критичны 200-600 мс холодного старта: кто-то считает проблемой для миллионов мелких запросов, кто-то — редким неудобством, решаемым резервными инстансами или переходом на Go/Rust.
• Сомнения в зрелости: «раньше быстро, пока не реализуешь оставшиеся 20 % фич»; безопасность и поддержка всей экосистемы JS вызывают скепсис.
• Плюсы: возможность компилировать в маленькие бинарники, использовать WASM-рантаймы, обходиться без JIT и доверять «своему» коду.
• Минусы: нет GC (хотят прикрутить WasmGC или Fil-C), нет I/O и полной Node-совместимости, корпоративные пользователи опасаются «экспериментов».

Переосмысление DOM с нуля

Браузеры в странном положении: WebAssembly выстрелил, даже на сервере, а клиентская часть ощущается почти как 10 лет назад. Доступ к веб-API из WASM решают тонким JS-клеем — но зачем вообще лезть в DOM? Просто других опций нет. Пора отправить DOM и его API «на ферму», и вот почему.

Никто уже не знает браузеры целиком — и это часть проблемы.

Модель «документа»

Мало кто осознает, насколько DOM раздут. У document.body в Chrome 350+ ключей, а в document.body.style — около 660 свойств. Граница между свойствами и методами размыта, геттеры могут триггерить релэйаут, висят легаси-штучки вроде onevent. DOM толстеет; страничникам это почти не видно, а приложениям — боль.

Большинство избегают прямой работы с DOM; деклартивности мало и она несовременна. Способов сделать одно и то же много, ни один не приятен.

connectedCallback() {
  const shadow = this.attachShadow({ mode: 'closed' });
  const template = document.getElementById('hello-world').content.cloneNode(true);
  const hwMsg = `Hello ${ this.name }`;
  Array.from(template.querySelectorAll('.hw-text')).forEach(n => n.textContent = hwMsg);
  shadow.append(template);
}

Веб-компоненты пришли поздно, непопулярны: API громоздкий, Shadow DOM плодит уровни вложенности и области видимости. Главная беда — строковая наследственность SGML/XML: состояние хранить в документе плохо; React-подобные это избегают, их «XML» — лишь синтаксис.

HTML почти не менялся 10–15 лет. ARIA стала заплаткой тому, что не дала «семантика HTML». Цели так и не достигли: нет <thread> или <comment>, правила странные. WHATWG (то есть вендоры) добавляет лишь заплатки по краям; даже CSS оброс выражениями — любая шаблонка хочет стать языком программирования.

Редактируемость HTML через contentEditable — теоретически есть, практически — темная магия; у команд Docs/Notion наверняка кошмары. Догмы про «прогрессивное улучшение» и разделение разметки/стилей в мире приложений мало кто исповедует.

Сегодня приложения склеивают HTML/CSS/SVG до «достаточно красиво», ценой огромных оверхедов — это анти-UI тулкит.

Подпись: Ввод Slack

Подпись: Оффскрин-хаки для буфера обмена

Списки и таблицы приходится виртуализировать вручную, перехватывая лайаут, ресайз, драги и т. п. «Прилипший вниз» скролл в чате — вечный TODO. Чем больше виртуализируешь, тем больше заново пишешь «поиск на странице», контекстные меню и пр. Веб стер грань между UI и «текучим контентом» — когда-то это было ново, теперь UI устарел, контент унифицировался.

CSS вывернут наизнанку

CSS не имеет стройной…

• Участники признают, что веб-платформа сложна и разрослась из-за обратной совместимости, множества требований и долгой эволюции; переписывание «с нуля» в реальности лишь добавляет новые слои сложности.
• Многие защищают DOM/HTML/CSS: они кроссплатформенны, поддерживают доступность, приватность, IME/спеллчек и текстовые сценарии, с которыми канвас/кастомные рендеры часто не справляются.
• Критика фокусируется на перегруженности API, «текучих» абстракциях и смешении ролей (CSS как и стиль, и лейаут), предлагаются идеи модульности API, хранение состояния в документе, и дисциплинированное использование Web Components.
• Аргумент «выбросить и заменить» упирается в стоимость миграции и необходимость покрыть весь исторический функционал; успех веба объясняют именно гибкостью, хаками, позже закреплёнными стандартами, и жёсткой обратной совместимостью.
• Проводят параллели с нативными UI-стеками: многие считают веб-технологии более удачными; обсуждают Flutter/WASM/WebGPU как путь к «приложенческому» вебу без ломания существующего.
• Идеи разделения «документы vs приложения» всплывают часто (вплоть до «DOCTYPE app»), но консенсус: нужно сосуществование обоих подходов, а не замена.
• Скепсис к «HTML на Canvas» и «перезапуску браузера» высок: полезнее усиливать существующие примитивы (дешёвый доступ WASM к DOM, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.