Hacker News Digest

Datastar — это «гипермедийный» фреймворк, который позволяет строить реактивные веб-приложения без JavaScript-кода. Он использует HTML-атрибуты и SSE-потоки для связи с сервером, а не JSON-API. Библиотека весит всего 10,75 КиБ и не требует сборки, что делает её идеальной для быстрого прототипирования. Примеры включают в себя чат-приложение, доска Kanban и т.д.

• Datastar и его автор Делани Гиллиан продвигают идею минималистичного подхода к веб-разработке, но критики указывают на то, что это может быть маркетинговым ходом, поскольку Pro-версия платная, а также что фреймворк может быть переоценённым решением, которое не решает фундаментальные проблемы веб-разработки.
• Обсуждение выявило, что Datastar не предоставляет никаких новых решений для проблем, с которыми сталкиваются разработчики, и вместо этого фокусируется на уже известных проблемах, таких как сложность, с которой сталкиваются разработчики, и не предлагает никаких новых решений.
• Участники обсуждения также подняли вопрос о том, что Datastar может быть не более чем просто ещё одним инструментом в арсенале веб-разработчика, и что его ценность может быть переоценена, в то время как другие инструменты, такие как HTMX и Alpine.js, могут предложить схожий функционал без необходимости платить за Pro-версию.
• Некоторые участники обсуждения также выразили обеспокоенность тем, что Datastar может быть не более чем попыткой монетизировать open-source проект, и что это может быть неэтичным, особенно если это не делает ясным, какие именно функции являются Pro-версией эксклюзивными.
• В конце концов, обсуждение подошло к выводу, что хотя Datastar и может быть полезным инструментом в определённых контекстах, его ценность может быть переоценена, и что его подход может не подходить для всех.

Краткий пересказ:
lavandula — это минималистичный веб-фреймворк на C, который обещает «скорость C и удобство Python». Проект с открытым исходным кодом, лицензия MIT. Сейчас он находится в стадии альфа-тестирования: базовый роутинг, middleware, JSON-ответы и простой шаблонизатор уже работают. Пример «Hello, world» компилируется в 12 КБ статического бинарника, а полноценный REST API сервис — меньше 100 КБ.

Планы: добавить встроенный ORM, WebSocket и SSE, а также CLI-генератор проектов. Поддержка Windows пока нестабильна, но Linux и macOS уже можно использовать. Сообщество приветствует вклад: обсуждение ведётся в Discussions, а примеры кода и бенчмарки публикуются в репозитории.

• Проект получил похвалу за чистоту и современный стиль кода, но также вызвал споры о практичности и безопасности C-фреймворков.
• Участники обсуждали, насколько целесообразно писать веб-приложения на C, и поднимались вопросы о безопасности и удобстве использования.
• Некоторые отметили, что проект может быть полезен для обучения и как отправная точка для других языков или фреймворков.
• Были также упоминания о том, что проект может быть развит с добавлением функций вроде шаблонизатора или поддержки HTTPS.
• Некоторые комментарии подчеркнули важность тестов и обработки ошибок в коде, а также отметили, что проект может быть использован как основа для других языков или фреймворков.

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

В примерах показано, как сократить размер данных в 4–8 раз по сравнению с традиционными подходами, например упаковывая несколько булевых значений в один байт или используя битовые маски для хранения состояний. Это не только экономит память, но и улучшает производительность за счёт лучшей локализации данных и уменьшения аллокаций. Практический вывод: для критичных к производительности задач стоит рассматривать низкоуровневую оптимизацию данных, даже если она усложняет код.

• Проблемы совместимости кода для x86 и ARM архитектур, включая необходимость использования библиотеки SIMDe для эмуляции x86 intrinsics на ARM.
• Обсуждение особенностей и ограничений NEON (ARM SIMD) по сравнению с SSE (x86 SIMD), включая отсутствие инструкции movemask и предложенные альтернативы.
• Потенциальные применения алгоритма для эффективной битовой упаковки и распаковки данных в задачах, чувствительных к пропускной способности памяти (например, в data warehouses).
• Критика методологии бенчмарков и сравнений в исходном исследовании, анонс собственной работы по схожей тематике.
• Рекомендации к дополнительным материалам по теме: научная статья обобщающая алгоритмы и статья о симуляции bit packing на NEON.

HTMX предлагает декларативный подход к веб-разработке через HTML-атрибуты, что могло бы сократить потребность в JavaScript, если бы браузеры поддерживали такие семантики изначально. Однако автор отмечает, что HTMX не предоставляет чёткой структуры, подобной SPA-фреймворкам, что ведёт к риску создания спагетти-кода, как в случае с jQuery.

В ответ на это был создан MESH — фреймворк, сочетающий модульный SSR с гидрацией, где каждый компонент соответствует одному эндпоинту. Это позволяет писать бэкенд с фокусом на HTML, сохраняя ощущение работы с SPA. Для демонстрации использовались Go, Templ и Declarative Shadow DOM, с небольшим хаком для обхода ограничений HTMX внутри теневых DOM. Ключевая идея — обеспечить единственно верный способ структурирования кода, избегая хаоса.

• Обсуждается применимость HTMX для различных типов приложений: отличное решение для многостраничных приложений, но может быть неоптимальным для сложных SPA-подобных интерфейсов с интенсивным взаимодействием (например, drag-and-drop).
• Представлены альтернативные подходы и фреймворки: MESH (один эндпоинт на компонент), Data-Star (обновление по SSE), Blazor, Leptos, а также использование чистого JS или Web Components.
• Поднимаются технические нюансы HTMX: поведение по умолчанию при замене контента (innerHTML), обработка ошибок, ограничения парсера DOM при работе с Shadow DOM.
• Критикуется тенденция добавления абстракций поверх HTMX, что, по мнению части участников, противорит его философии простоты и возврата к истокам.
• Отмечается ценность HTMX и подобных инструментов как реакция на сложность современных JS-фреймворков и возможность быстрой разработки без сборки.

Rust: «неразумная» скорость сортировки

• Сортировка в Rust быстрее C++ и Go благодаря LLVM, агрессивному векторизатору и ручным оптимизациям.
• Алгоритм: pdqsort (pattern-defeating quicksort) + векторизованный партиционер.
• Ключевые приёмы:
  • 128-битные SIMD-операции (SSE/AVX) для фильтрации элементов;
  • branchless-код, предикты, минимизация кэш-промахов;
  • специализированные пути для малых типов (u8, u16, u32, u64, f32, f64) и копируемых структур;
  • ручная развёртка циклов, инлайн, отказ от стандартных абстракций.
• Сравнение: на случайных u64 Rust ~2× быстрее libstdc++, ~3× быстрее Go; на почти отсортированных — ещё больше.
• Память: всё делается in-place, доп. буфер 1 КБ максимум.
• Сложность: O(n log n) в среднем, O(n log n) worst-case (pdqsort гарантирует).
• Код открыт, можно подсмотреть и перенести на другие языки.

• Универсальный лайфхак: «сначала отсортируй данные» — и задача часто сводится к O(log n).
• Но глобальная сортировка дороже с ростом объёма; иногда проще пересмотреть подход или использовать хэш-таблицу.
• Современные unstable-sort и foldhash настолько быстры, что ручные оптимизации часто проигрывают и требуют лишней памяти.
• Для 4 уникальных значений подсчёт или perfect-hash проще и быстрее полной сортировки; эксперимент ставит границы, а не решает продакшен-задачу.

Как создать инструкцию по установке MCP-сервера

1. Определите тип сервера

   • stdio – локальный процесс.
   • sse – удалённый HTTP-эндпоинт.

2. Соберите метаданные

   • Название, описание, автора, ссылку на репозиторий.
   • Требования: Node.js, Python, Docker и т.д.
   • Порт (для SSE), путь к исполняемому файлу (для stdio).

3. Сформируйте claude_desktop_config.json
   Пример stdio:

   {
     "mcpServers": {
       "my-server": {
         "command": "node",
         "args": ["build/index.js"],
         "env": { "API_KEY": "xxx" }
       }
     }
   }
   

   Пример SSE:

   {
     "mcpServers": {
       "my-server": {
         "url": "http://localhost:3000/sse",
         "headers": { "Authorization": "Bearer xxx" }
       }
     }
   }
   

4. Сгенерируйте инструкцию

   • Установите зависимости (npm i, pip install -r requirements.txt).
   • Скопируйте claude_desktop_config.json в %APPDATA%\Claude\ (Win) или ~/Library/Application Support/Claude/ (macOS).
   • Перезапустите Claude Desktop.

5. Проверьте работу
   Откройте Claude → шестерёнка → Developer → MCP → убедитесь, что сервер “Connected”.

6. Опубликуйте
   Добавьте README.md с шагами выше и примером конфига.

• Пользователи хотят не просто «забронировать», а исследовать: «покажи самые дёшевые окна в Токио за 3 месяца».
• Все сходятся, что полностью автономное бронирование пока ненадёжно: доверие к ИИ низкое, цены скачут, а условия договора надо принимать вручную.
• MCP-серверы рассматриваются как новая «AI-API» — удобно для агентов, но бизнес может быстро закрыть доступ, если это ударит по рекламе и контролю.
• Kiwi и прочие агрегаторы могут зарабатывать на самой продаже билетов и страховках, а не на рекламе, но риски покупки у посредников остаются.
• Пока что MCP-инструменты лучше работают как «умный поиск с последующим подтверждением человека», а не как полностью автономный консьерж.

FFmpeg/asm-lessons — репозиторий с уроками по ассемблеру для FFmpeg.
Цель: научиться писать высокопроизводительные рутины на x86-64, ARM и других архитектурах, ориентированные на мультимедиа-задачи.

Содержание (кратко):

• Уроки: от базовых инструкций до векторных расширений (SSE/AVX, NEON).
• Примеры: реализация IDCT, фильтров, цветового преобразования.
• Тесты: юнит-тесты и бенчмарки для сравнения C vs asm.
• CI: автоматическая проверка на x86-64 и ARM через GitHub Actions.

Как начать:

1. Клонируйте репо.
2. Установите nasm, yasm или llvm-mingw.
3. Соберите пример: make lesson01.

Полезные ссылки:

• Документация FFmpeg
• x86 SIMD
• ARM NEON

• Пользователи восхищаются масштабом FFmpeg и экономией вычислений даже при небольших улучшениях.
• Обсуждаются случаи, когда ручная сборка быстрее intrinsic’ов, и инструменты для поиска «горячих точек».
• Некоторые ждали более глубокой связи с FFmpeg, а не общее введение в ассемблер.
• Поднимаются вопросы портативности (пока только x86-64), необходимости математических подготовок и перегруженности NASM-макросами.
• Большинство соглашается: писать LLVM IR вручную нет смысла, проще использовать inline-assembly или векторные инструкции.