Hacker News Digest

Автор создал новый шрифт Avería, усреднив все шрифты на своём компьютере. Идея родилась из интереса к типографике и креативному программированию. Сначала он накладывал буквы разных шрифтов с низкой прозрачностью, а затем использовал ImageMagick и PHP для математического усреднения изображений. Выравнивание по базовой линии и началу координат дало более чёткие результаты, чем простое наложение. Автор обнаружил, что строчная буква 'g' имеет две распространённые формы, а большинство шрифтов демонстрируют высокую корреляцию.

Когда простой метод дал размытые результаты, автор начал искать способы сохранить чёткие края. Он экспериментировал с пороговыми значениями для создания монохромных изображений, но столкнулся со сложностью математического усреднения форм. После изучения крив Безье и метрик шрифтов, он выбрал простой подход: разбиение контура каждой буквы на 500 равноотстоящих точек и усреднение соответствующих позиций. За месяц работы над проектом он создал Avería — название, связанное со словом "average" (среднее), но на испанском означающее "поломка".

• Обсуждение началось с демонстрацией шрифта Averia как примера "усреднённого" шрифта, что вызвало обсуждение его визуального качества и ассоциаций с "uncanny valley".
• Участники обсудили, что Averia выглядит мутновато и непривычно, что вызвало дискуссию о том, какие именно параметры делают шрифт читаемым и приятным.
• Были подняты вопросы о том, как средний шрифт может влиять на читаемость и какие именно параметры делают его таким.
• Также обсуждались вопросы авторского права и атрибуции, так как Averia был создан как "усреднение" всех шрифтов в системе.
• Участники также затронули тему того, что именно делает шрифт визуально привлекательным и читаемым, и какие параметры важны для этого.

Инженеры часто иррационально подходят к выбору языков программирования, принимая решения на основе идентичности, эмоций и эго, а не технических преимуществ. Автор делится историей о компании Takkle, где опытный CTO инициировал переход с PHP на Perl, что привело к девятимесячной задержке, увеличению расходов с $200K до $500K в месяц и, в конечном итоге, к банкротству компании. Несмотря на то, что PHP был «достаточно хорош» для Facebook, подобного решения не приняли.

В течение своей карьеры автор наблюдал повторяющуюся эту модель в Google, MongoDB и других компаниях. Он описывает случай, когда VP Engineering представил руководству обоснование выбора Rust, хотя Go объективно соответствовал заявленным критериям лучше. Оказалось, что другие языки даже не рассматривались — решение было основано на хайпе. Автор подчеркивает, что при обсуждении языков программирования всегда происходит два диалога: видимый технический и невидимый, связанный с идентичностью инженера.

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

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

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

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

MAML — это минималистичный формат для данных, который сохраняет читаемость для человека и при этом остаётся простым для машинной обработки. Он сочетает лучшее из JSON, дополняя его комментариями, многострочными строками и необязательными запятыми и кавычками.

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

Делай вклад в цифровые общественные блага

Помоги проектам, которые борются с климатом, голодом и прочими глобальными задачами. Ниже — готовые к первому PR репозитории.

Проект	Язык	Направление
mautic	PHP	маркетинг-автоматизация
credebl	TypeScript	децентрализованная идентичность
avni-webapp	JavaScript	медицинские данные
the-turing-way	TeX	воспроизводимая наука
X-Road	Java	обмен данными между госорганами
OpenTermsArchive	JavaScript	прозрачность сервисов
OpenFn Lightning	Elixir	автоматизация workflow
android-fhir	Kotlin	мобильная медицина
casa	Ruby	волонтёрство для детей
ODK Collect	Kotlin	сбор данных в поле
cht-core	JavaScript	цифровое здравоохранение
policyengine-app	Jupyter	расчёт последствий политик
querido-diario	Python	открытые госгазеты
ODK Central	JavaScript	сервер для форм
decidim	Ruby	участие граждан

Фильтр по языку и Целям устойчивого развития (SDG) на сайте.

• Участники приветствуют инициативу списка проектов с «good first issue», но сомневаются в кураторстве: много проектов без активных задач, не все связаны с социальным влиянием.
• Предложено скрывать репозитории с 0 issues и добавлять метрики активности (коммиты, разработчики, возраст), как в Re-Decentralise.
• Новички спрашивают, считать ли правку опечаток «настоящим» вкладом; большинство советует упоминать, но честно указывать уровень участия.

Mago — набор инструментов для PHP, помогающий писать чище и быстрее.
Анализ кода, форматирование, линтинг и прочие утилиты в одном месте.

• Mago — это новый набор PHP-инструментов (форматтер, линтер, LSP) на Rust, но пока в бета-статусе: не парсит PHPDoc, не понимает встроенные классы без \, выдаёт тысячи ложных ошибок.
• Автор признал README обманчивым и обещает уточнить roadmap и неготовые фичи (магические @method/@property, type-инференд).
• Пользователи сравнивают проект с uv/ruff для PHP, но сомневаются в необходимости: у PHP уже есть Composer, PHPStan, Psalm, которые развиваются быстрее и без разрыва экосистемы.
• Основной аргумент «на Rust» воспринимается слабо: сообщество не видит, почему переписывать инструменты на другом языке, если нет денег и людей (в отличие от Sorbet/tsgo, у которых спонсоры).
• PHP Foundation и крупные проекты (WordPress, Laravel, Википедия) деньги имеют, но пока никто из них Mago не финансирует.

• PHP и JS любят те, кто делает, а не спорит.
  С ними легко найти людей, которые быстро понимают бизнес и уже многое запустили.

• Стереотипы устарели.
  PHP8 ≠ PHP3, ES12 ≠ старый JS. NPM и Composer давно задали темп остальным экосистемам.

• Красота не главное.
  Главное — скорость, деплой «залил и забыл», тонна готовых библиотек и простое масштабирование. PHP-режим CGI позволяет переписывать код по кусочкам без утечек памяти.

• Игра в «как красиво» внутри грязного языка — весёлая.
  Когда язык не навязывает стиль, каждый найденный элегантный приём приносит удовольствие.

• Низкий порог = большое сообщество.
  Через копипаст и тюнинг index.php школьник за выходные делает рабочий сайт. Такие языки не снобствуют и охотно принимают новичков.

• Хороший код зависит не от языка, а от:

  • понимания продукта;
  • тестов и стат-анализа;
  • CI/CD и коммуникации в команде.

  У PHP/JS сегодня: Psalm, PHPStan, ESLint, TypeScript, JetBrains-IDE — инструментов больше, чем у «серьёзных» языков.

• Легаси — это не грязь, а деньги.
  Рабочий продукт с кучей пользователей = возможность каждым коммитом улучшать жизнь людям уже сегодня.

• PHP славится «shared nothing»-моделью: каждый запрос живёт изолированно и гарантированно умирает, устраняя утечки памяти и упрощая масштабирование.
• Современный PHP (8+) — это типизированный язык с Composer, Psalm, PSR-стандартами и активным сообществом; стереотипы 2000-х больше неактуальны.
• Большинство негатива идёт от унаследованного кода (WordPress, Magento, Drupal) и «skill-issue» разработчиков, а не от самого языка.
• Для простых внутренних инструментов, лендингов и «сайтов-в-один-файл» PHP остаётся идеальным выбором: дёшево, сервер есть у любого хостера, деплой — drag-and-drop.
• Если нужен фреймворк без Laravel/Drupal, смотрят на Symfony, ProcessWire или пишут на чистом PHP с композер-пакетами.

Гибридный 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 — на стандарты и долгосрочную поддержку.
• Несколько человек жалуются на плохое качество аудио и просят поп-фильтр.

• Сделал блог-фреймворк на XSLT: демо, код.
• Зачем? Для себя. После пары «вайб-промптов» понял, что 20-летний стандарт покрывает всё, что надо.
• Хочу: писать чистый HTML, без WYSIWYG и Markdown; RSS «из коробки»; единый шаблон на все посты; немного JS для картинок и тем.
• XSLT = один файл-шаблон, XML-контент. Браузер сам превращает XML в HTML. RSS тоже XML, поэтому тот же индекс используется и для ленты.
• Публикация: создал пост, добавил в index.xml, залил — всё. Без сборок и бэкенда.

• Участники вспомнили XSLT как способ превращать XML в HTML прямо в браузере, но большинство считают технологию устаревшей и медленной.
• Предложено заменить RSS на Atom из-за более чистого формата дат и лучшей поддержки.
• Некоторые используют XSLT на сервере (PHP, SaxonJS), где он работает быстро и безопасно.
• Браузеры удаляют XSLT из-за рисков безопасности и низкого спроса; IBM предложила свой JIT-движок, но его вряд ли примут.
• SEO и кэширование вызывают сомнения: динамически собранные страницы могут быть плохо проиндексированы.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

Репозиторий демонстрирует, как обойтись без движков шаблонов, используя лишь стандартные XML-технологии.

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.

Кратко: стандартизировать в браузерах XSLT 3.0 нецелесообразно.
Технология мало используется, реализация сложна, а современные подходы (JS-шаблонизаторы, Web Components, SSR) решают те же задачи быстрее и проще.

• Пользователи мечтают о «навсегда-статическом» сайте без обновлений зависимостей; кто-то до сих пор использует PHP-include, кто-то — <template>+JS.
• Появилась фантазия «а вдруг браузеры вернут XSLT 3.0»; сторонники называют это разделением данных и представления, скептики — «громоздким XML-гипертекстом».
• Поддержка XSLT в браузерах всё ещё есть, но фактически мертва: Google убирает упоминания из спецификаций, а правительственные сайты жалуются на поломки.
• Основные претензии к XML/XSLT: чрезмерная многословность, сложность ручного редактирования, жёсткая типизация и «всегда есть пять способов записать то же самое».
• JSON и современные SSR-шаблонизаторы оказались проще и быстрее, поэтому даже ностальгирующие разработчики признают: «красивый, но неудобный» стандарт проиграл конкуренцию сетевым эффектам и эргономике.

Кратко:
PHP-фонд предлагает реализовать только компиляторные обобщения (generics) для интерфейсов и абстрактных классов.
Синтаксис:

interface Repository<Item> {
    public function find(int $id): Item;
}

class UserRepo implements Repository<User> { … }

• Все проверки типов происходят на этапе компиляции.
• Ошибки ловятся до запуска кода.
• new Repository<User>() по-прежнему невозможно, но и не усложняется.

Почему не полные обобщения?
Полноценные runtime-generics требуют сложного вывода типов и резко замедляют работу, особенно при объединённых типах и массивах.

Откуда идея?

• 2023-2024: эксперименты Arnaud Le Blanc показали, что 80 % пользы можно получить без 80 % сложностей.
• 2025: Gina Banyard разрабатывала «ассоциированные типы» и поняла, что их легко переформулировать как ограниченные обобщения.

Вопрос сообществу:
Поддержите ли вы такой вариант и проголосуете ли «за»?

• В обсуждении разбираются плюсы и минусы добавления дженериков в PHP.
• Участники спорят, не приведёт ли это к «размагничиванию» типов, и объясняют разницу между reified (типы сохраняются в рантайме, как в C#) и erased (типы стираются, как в Java) дженериками.
• Поднимается вопрос: почему class Repo<T> {} труднее реализовать, чем class BlogPostRepo extends BaseRepo<BlogPost> {}.
• Многие разработчики просят хотя бы строго типизированные массивы, считая их более полезными, чем полноценные дженерики.
• Часть команды уже использует PHPStan и strict_types, считая этого достаточным без изменений ядра языка.

The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be d

Java is more akin to the Corolla. Utterly insipid (by design), lacking in refinements compared to competitors like the Mazda3, and made for people who just see it as a way to get from point A to point B.PHP is the Hyundai Elantra of programming. It used to be popular because of l