Hacker News Digest

Кратко:
С декабря 2026 г. CocoaPods Trunk станет только для чтения — новые версии и pod-ы добавлять нельзя. Существующие сборки продолжат работать, пока живы GitHub и jsDelivr.

Что меняется:

• Подачи новых Podspec будут отклоняться на уровне сервера.
• Репозиторий CocoaPods/Specs пометят как archived.
• Использование prepare_command в новых Podspec запрещено (май 2025).

График:

• май 2025 — блок prepare_command.
• конец 2025 — массовое письмо всем авторам Podspec.
• сен–окт 2026 — повторное уведомление.
• 1–7 ноя 2026 — тестовое отключение.
• 2 дек 2026 — финальный переход на read-only.

Обратная связь:

• Команда: [email protected]
• Orta: [email protected] или Bluesky @orta.io

• CocoaPods официально уходит в историю: мейнтейнеры решили прекратить развитие, признав превосходство Swift Package Manager.
• Пользователи благодарны за годы поддержки, но многие рады избавиться от «захвата» проекта xcworkspace и постоянных проблем с CDN.
• Критика SPM: не хватает команды outdated, баги в Xcode, плохие сообщения об ошибках; до 30 % пакетов ещё не перенесены.
• React Native, Flutter, Unity, Capacitor пока тесно зависят от CocoaPods; переход на SPM только в зачаточном состоянии.
• ~100 k старых pod-ов рискуют остаться без обновлений: придётся форкать и мигрировать вручную или ждать сообщества.

• Токио Tokyo
• Канда Kanda
• Акихабара Akihabara
• Окачимати Okachimachi
• Уэно Ueno
• Угисудани Uguisudani
• Ниппори Nippori
• Ниси-Ниппори Nishi-Nippori
• Табата Tabata
• Комагомэ Komagome
• Сугамо Sugamo
• Оцука Ōtsuka
• Икэбукуро Ikebukuro
• Мэдзиро Mejiro
• Такадабаба Takadanobaba
• Син-Окубо Shin-Ōkubo
• Синдзюку Shinjuku
• Ёёги Yoyogi
• Харадзюку Harajuku
• Сибуя Shibuya
• Эбису Ebisu
• Мэгуро Meguro
• Готанда Gotanda
• Осаки Ōsaki
• Синагава Shinagawa
• Таканава Gateway Takanawa Gateway
• Тамати Tamachi
• Хамамацутё Hamamatsuchō
• Симбаси Shimbashi
• Юракутё Yūrakuchō

Линии: Keihin-T. · N'EX · Saikyō · Sōbu · Ueno-T. · Yamanote
о проекте

• Пользователи делятся воспоминаниями о мелодиях станций Яманотэ: кто-то слушал их специально, кто-то узнал детскую песенку в «Гиндза», а кому-то они вызывают ностальгию.
• Несколько человек показали свои творческие проекты: психоделический коллаж, треки на основе мелодий, флаттер-приложение с объявлениями.
• Узнаём, что JR East постепенно отказывается от уникальных мелодий из-за нехватки персонала и переводит линию на единый звук.
• Появились просьбы добавить другие линии (Тозай, Чуо), сделать рингтоны и даже мод для симулятора.
• Кто-то предлагает проводить конкурсы мелодий в других странах, чтобы повторить японский опыт «маленькой радости».

TextKit 2 (NSTextLayoutManager) появился на WWDC21, но уже 4 года не оправдывает надежд. Архитектура продумана: NSTextContentManager, NSTextElement, NSTextLayoutManager. На практике работает только NSTextContentStorage → NSTextStorage, а элементы должны наследовать NSTextParagraph. UITextView/NSTextView не принимает альтернатив.

Баги многочисленны: «extra line fragment», регрессии между версиями, часть отчётов без ответа.

Viewport — главная боль. Он лениво раскладывает только видимую область, поэтому высота документа постоянно пересчитывается и «прыгает» при прокрутке. Постоянные инвалидации и кэширование усложняют код.

• TextKit 2 выглядит «сырым»: демо работает, но стоит отойти от happy path — всплывают баги, плохая документация и отсутствие публичного списка проблем.
• Основной способ использования — кастомизация UITextView/NSTextView; попытки полностью заменить их приводят к боли.
• На macOS TextKit 2 сломал даже TextEdit: появились глюки прокрутки и повреждение текста.
• «Дрожание» скроллбара из-за lazy layout и оценок высоты считается «как задумано», но выглядит неприемлемо; решения есть (Flutter, эвристики), но не встроены.
• Apple, судя по всему, не додогфудила API: внутренние приложения не отловили острые углы, поэтому теперь каждый разработчик получает синяки.

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

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

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

  • Плюсы: встроенные редакторы, удобные интерфейсы.
  • Минусы: дороже, часто баги, привязка к конкретному редактору.

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

Вывод
LLM — полезный инструмент для рутины и прототипов, но не заменяет мышление и глубокое понимание.

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.