Hacker News Digest

Разработчики создали неофициальную "Tier 4" цель Rust для поддержки старых версий Windows, включая 9x, Me, NT, 2000, XP и Vista. Этот проект позволяет компилировать Rust-код для работы на устаревших системах, которые больше не поддерживаются официальными версиями Windows. Статус "Tier 4" указывает на низкий приоритет поддержки, что означает отсутствие гарантий стабильности и минимальное внимание к совместимости.

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

• Поддержка старых ОС в Rust исторически обеспечивалась из-за требований Firefox (особенно Windows XP), что выделяло его среди других языков.
• Разработчики сталкиваются с трудностями при работе с устаревшими системами (Windows 7/8/Vista), вынужденно используя старые версии инструментов (например, Java 8) из-за отсутствия поддержки.
• Существуют неофициальные решения для поддержки старых платформ ("Tier 4" для Windows Vista, компиляция в C через Nim, Kotlin/Scala для Java 8), а также экспериментальные проекты (Rust на C64).
• Отказ языков и рантаймов от поддержки старых ОС критикуется как "злонамеренный" или связанный с политикой запланированного устаревания.
• Rust обеспечивает лучшую, чем в среднем, поддержку офлайн-сборки (cargo --offline), что критично для изолированных сред.

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

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

Пример с функцией userCoworkers показывает, как чистый код постепенно усложняется: сначала добавляется мутабельная коллекция, затем логирование. Юмор в том, что даже с побочными эффектами метод остаётся чистым снаружи, а задание «просто вернуть число» ставит под вопрос, как вообще избежать функциональных подходов. Финальный совет — спросить у менеджера, как сложить числа без чистых функций — подчёркивает абсурдность таких запретов.

• Важность написания читаемого кода с учетом целевой аудитории (уровня навыков читателей) и необходимости согласования стиля в команде.
• Критика восприятия функционального программирования (ФП) как исключительно сложного, с указанием, что проблема часто в неидиоматичном коде, излишне длинных цепочках методов или специфических особенностях языков (например, Haskell), а не в ФП как парадигме.
• Необходимость обучения, код-ревью и парного программирования для внедрения сложных концепций и выравнивания уровня команды, особенно при использовании нишевых языков (например, Scala).
• Споры о балансе между простотой (для младших разработчиков) и продвинутыми практиками, где чрезмерное упрощение может привести к посредственному коду, а сложность — к проблемам читаемости.
• Роль менеджмента в разрешении конфликтов через технические решения, которые могут ограничивать инструменты или стили (например, запрет ФП), иногда без глубокого понимания причин проблемы.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости: "libpupa": "1.2.3" Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это: "liblupa": "0.7.8" То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.