Hacker News Digest

Эндрю Шмеляун создал систему, позволяющую незнакомцам отправлять ему сообщения через чековый принтер. Он вдохновился другом, у которого на сайте была похожая функция, но хотел сделать её более физической. Эндрю использовал старый термопринтер Epson TM-T88IV, купленный на eBay за $50, который работает за счёт нагрева специальной бумаги, покрытой термочувствительным веществом. Поскольку принтер не распознаётся его Mac Mini, он подключил его к Raspberry Pi 4.

Для реализации проекта Эндрю выбрал PHP с фреймворком Laravel, создав сайт с простой формой без JavaScript. Система сохраняет сообщения в базу данных на случай, если принтер выйдет из строя или закончится бумага. Принтер имеет ограниченный набор символов (только стандартный алфавит, цифры и базовые знаки клавиатуры), поэтому сообщения проходят валидацию на предмет специальных символов. Ширина текстового поля соответствует ширине печати (42 символа).

• Пользователи делятся опытом с дешёвыми китайскими термопринтерами, драйверы и библиотеки для них, а также вспоминают проект Little Printer и другие попытки сделать «интернет-подключённые» термопринтеры.
• Обсуждаются вопросы безопасности при работе с термобумагой, влияние BPA и аналогичных пластификаторов, а также трудности с поставками безопасной бумаги.
• Участники делятся личным опытом: кто-то использует принтер как «интернет-факс», кто-то печатает стикеры из чека, кто-то пытается повторить Little Printer.
• Поднимается вопрос о том, что такие проекты могут быть использованы для печати зинов и других офлайн-контента.
• Также обсуждается, что при должном подходе можно было бы сделать такие проекты более доступными и устойчивыми к спаму и злоупотреблениям.

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Гибридный PHP: PHP + Go и Rust

Раньше у нас был монолит на PHP 8.3 («мама») и несколько микросервисов на Go («дети»). Такой стек давал скорость там, где нужно, и скорость разработки везде остальном.

По правилу 80/20 20 % эндпоинтов приносят 80 % нагрузки. Раньше мы выносили их в Go-сервисы, но это усложняло инфраструктуру. Теперь можно оставить логику в монолите и всё равно получить высокую производительность.

Новые инструменты

• FFI – вызов C-кода прямо из PHP.
• Расширения на Rust – безопасный и быстрый код без C.
• FrankenPHP – worker-режим до 4× быстрее; теперь можно писать расширения на Go и вызывать их из PHP.

Зачем не переписать всё на Go или Rust?

• Переписывание дорого и рискованно.
• PHP отлично справляется с 80 % задач, а критичные 20 % можно ускорить расширениями на Rust/Go.

Итог: современный PHP даёт и скорость разработки, и максимальную производительность там, где это критично.

• Участники жалуются, что монолитные фреймворки (Spring, Laravel, Phoenix) быстро дают результат, но превращают legacy-код в кошмар при обновлении зависимостей.
• Обсуждают гибридные схемы «PHP + Rust/Go/C», но предупреждают о росте сложности отладки и найма.
• Некоторые считают современный PHP (≥8.x) недооценённым и упрекают индустрию в стереотипах 5.x-времён.
• Упоминаются альтернативные рантаймы (FrankenPHP, RoadRunner, Workerman) и эксперименты с встраиванием PHP в nginx.
• Пакетный менеджер Composer критикуется как «не тот уровень», ждут «Astral для PHP».

• Простота — главное в долгоживущем коде: понятность и уверенность при изменениях.
• Программы должны быть «одноразовыми», как Кенни, а не «неубиваемыми», как Терминатор.
• Laravel начинался как хобби на PHP 5.3 и вырос до 70 человек; Тейлор всё ещё единственный куратор ядра.
• Первым коммерческим продуктом стал Forge — решение собственной боли.
• Не ломай обратную совместимость без крайней нужды; «умники» всегда уходят, а их хитрости остаются.
• Лучшие проекты — те, кто не изобретает велосипеды и следует конвенциям.
• Споры закрываются сравнением реального кода: «покажи, как будет выглядеть».
• Фасады остаются популярнее DI, но Laravel постепенно добавляет типы и статический анализ.
• Культура тестирования изменилась после курса Adam Wathan.
• Сейчас задача — передать ответственность команде и оставаться интересным.

• Участники обсуждают, что Laravel учит «не писать код как Laravel»: пример — баг в cache tagging, который просто убрали из документации.
• Поддержка старых версий Laravel (3–4) описывается как кошмар, требующий полного переписывания, тогда как Rails и Symfony позволяют плавные апгрейды.
• Сообщества Laravel, Symfony, Drupal и WordPress различаются культурно: Laravel ориентирован на быстрый MVP и продажу продуктов, Symfony — на стандарты и долгосрочную поддержку.
• Несколько человек жалуются на плохое качество аудио и просят поп-фильтр.