Hacker News Digest

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

Команда Swift представила предварительную версию инструментария для FreeBSD 14.3+, доступную для архитектуры x86_64. В комплекте компилятор и рантаймы Swift, необходимые для разработки. Для работы требуются зависимости: zlib-ng, python3, sqlite3, libuuid и curl. Разработчики предупреждают, что компилятор всё ещё находится в разработке и не является частью официального релиза.

Существует несколько известных проблем: некорректные отчёты Thread Sanitizer, неспособность LLDB выполнять Swift-выражения, зависание плагинов в SwiftPM, проблемы с C++ interop. Для FreeBSD 15 требуется временный workaround через установку пакета compat14x-amd64. Команда работает над добавлением поддержки aarch64 и распространением пакета для всех минорных версий FreeBSD 14. Пользователям рекомендуется сообщать о найденных ошибках на GitHub.

• Swift на FreeBSD — давно ожидаемое событие, но вопросы остаются: кто будет поддерживать порт, какие зависимости потребуются и какие части стека (например, SwiftUI) останутся проприетарными.
• Появление Swift на FreeBSD подчеркивает, что язык выходит за пределы экосистемы Apple, но при этом неясно, насколько он может быть полезен вне iOS/macOS-разработки.
• Обсуждение также затрагивает, что Swift в отличие от .NET или JVM не имеет полноценной кроссплатформенной стратегии, что ограничивает его применимость.
• Участники обсуждения отмечают, что язык не предоставляет официальной поддержки для серверной разработки, что делает его менее привлекательным для бэкенда.
• Наконец, обсуждение поднимает вопрос о том, что Swift в отличие от .NET или JVM не имеет полноценной кроссплатформенной стратегии, что ограничивает его применимость.

Эксперименты — основа хорошего вкуса в программировании. Автор признается, что в детстве пробовал многое (гитару, боевые искусства), но с программированием не экспериментировал, хотя и восхищался играми. Позже он понял, что эксперименты — ключевой элемент его обучения. Примеры экспериментов: настройка чувствительности мыши в играх, конфигурация Linux, кастомизация механических клавиатур. Цитируется мнение: «Когда ты экспериментируешь и выбрасываешь результаты — это практика, которая должна быть мимолетной, исследовательской и частой».

Хороший вкус формируется через использование разных инструментов, отбор подходящих и отказ от неподходящих. Автор подчеркивает, что «никакое время, потраченное на обучение, не пропало зря». Он призывает сомневаться в общепринятых нормах, экспериментировать и ломать вещи. Важно найти баланс: автор не тратит все время на настройку neovim, но регулярно пробует новые технологии (GLSL, Rust, Swift), чтобы расширить кругозор и развить способность отличать посредственность от мастерства.

• Обсуждение свелось к тому, что «taste» и «tinkering» — это не про элитарность, а про любознательность и готовность экспериментировать.
• Участники обменялись историями о том, как раньше они тоже «игрались» с настройками, но со временем пришли к минимализму и перестали это делать.
• Поднялась тема о том, что «taste» в разработке ПО — это не про эстетику, а про умение выбирать правильные инструменты и не тратить время на бессмысленные оптимизации.
• Некоторые участники выразили обеспокоенность тем, что статья не раскрывает, что именно делает «taste» важным и почему он важен.
• В итоге обсуждение сошлось на том, что «taste» — это не врождённое качество, а навык, который развивается с опытом и вовремя отпускает человека от бессмысленных занятий.

Swift.org анонсировали выпуск Swift SDK для Android, открывая новые возможности для кроссплатформенной разработки. Этот релиз стал результатом многолетних усилий сообщества и работы Android workgroup, которая расширяет возможности Swift за пределы традиционных платформ. SDK доступен в виде nightly preview релизов и может быть получен вместе с установщиком Windows или скачан отдельно для Linux и macOS.

Уже опубликовано руководство по началу работы и примеры приложений, демонстрирующие end-to-end рабочие процессы. Проект swift-java обеспечивает взаимодействие между Java и Swift, автоматически генерируя безопасные и производительные привязки. Интересно, что более 25% пакетов в Swift Package Index уже поддерживают Android, что упрощает перенос существующих проектов на новую платформу. Команда также работает над документом видения для будущих разработок Swift на Android и отслеживает прогресс через проект board.

• Обсуждение в основном вращается вокруг трёх тем: «кроссплатформенный» Swift теперь позволяет писать Android-приложения на Swift, но не решает проблему UI-фреймворков, а также не затрагивает вопросы лицензирования и тулинга.
• Участники обсуждения отмечают, что даже если Swift теперь работает на Android, это не делает его «флаттером» — он не предоставляет нативный UI, и разработчики всё ещё должны решать, как реализовать UI, что делает его менее привлекательным, чем Flutter или React Native.
• Некоторые участники высказывают мнение, что вместо того, чтобы пытаться сделать Swift кроссплатформенным, было бы лучше, если бы Apple открыла Xcode и позволила бы использовать его на других платформах.
• Обсуждение также затрагивает вопрос о том, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.
• Участники также обсуждают, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.

Пол Хадсон создал приложение Hacktivate, чтобы научить детей 13+ основам кибербезопасности через формат игры "захвати флаг". В отличие от современных компьютеров, которые слишком защищены для экспериментов, приложение предлагает 240 уникальных заданий по SQL-инъекциям, взлому хэшей, стеганографии и другим практическим навыкам. "Я хочу вернуть тот же опыт, который был у меня, новому поколению", — объясняет автор, стремясь сделать обучение одновременно увлекательным и структурированным.

Приложение использует безопасную песочницу, где все действия происходят внутри игры, не затрагивая реальные системы. Задания варьируются от базовых вопросов о представлении данных (hex, binary, ASCII) до сложных криптографических задач с современными алгоритмами. "Моя цель — не превратить всех в опытных пентестеров за один день, а вдохновить новое поколение хактеров на эксперименты и обучение в безопасной среде", — подчеркивает Хадсон. Приложение уже доступно на iPhone, iPad и Mac.

• Пользователи обсуждают, как раннее влияние нехватки ресурсов в странах третьего мира сформировало их навыки и мотивацию к самообучению и творческому подходу к решению проблем.
• Поднят вопрос о том, что микротранзакции в приложениях могут быть неэтичными, особенно для детей, и что существует альтернативная версия приложения без них.
• Упомянуто, что разработчик приложения, Paul Hudson, ранее преподавал автору Swift и UIKit, что подчеркивает его вклад в обучении сообщества разработчиков.
• Участники обсуждают, что важно сохранять баланс между монетизацией и доступностью образования, и что существует версия приложения без микротранзакций.

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

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

• Критики выражают сомнения в целесообразности использования Zig для крупных проектов из-за отсутствия гарантий памяти, как в Rust или Swift, и нестабильности языка до версии 1.0.
• Сторонники Zig отмечают его сильные стороны: простоту, явный контроль над выделением памяти, отличную совместимость с C и возможность писать код без использования кучи.
• Обсуждаются практические примеры успешного использования Zig в реальных проектах (Tiger Beetle, Ghostty), несмотря на нестабильность.
• Поднимается вопрос о своевременности выхода книги по языку, который всё ещё активно меняется, что может быстро сделать издание устаревшим.
• Утверждается, что безопасность памяти — это спектр, а не бинарный выбор, и что простота Zig может снижать количество логических ошибок в целом.

На RustConf 2025 обсуждалась совместимость Rust и C/C++, где Чендлер Каррут сравнил подходы Rust и экспериментального языка Carbon. Rust предлагает инструменты вроде bindgen и cxx для взаимодействия, но они слабо подходят для сложного legacy-кода C++ (brownfield), где тесные связи и большой API усложняют миграцию. Carbon же задуман как полностью совместимый с C++ язык, позволяющий постепенно переписывать проекты файл за файлом без смены компилятора, с акцентом на аннотации для безопасности памяти.

Каррут считает, что Rust не скоро решит проблему полной интероперабельности с C++, тогда как Carbon предлагает эволюционный путь, аналогичный переходу от JavaScript к TypeScript. Это даёт пространство для Carbon, особенно в крупных legacy-проектах, где полный переход на Rust непрактичен. Вывод: два языка могут сосуществовать, решая разные аспекты миграции к безопасным языкам.

• Обсуждается сложность и подходы к миграции с C/C++ на современные языки (Rust, Kotlin, Swift), включая инструменты для конвертации и постепенного перехода.
• Поднимаются вопросы о важности качественной интероперабельности между языками и недостатках C как языка-«клея» из-за отсутствия современных функций безопасности.
• Высказываются сомнения в универсальности Rust для полного переписывания из-за архитектурных несовпадений с идиоматическим C++.
• Отмечается, что такие проекты, как Carbon, нацелены на крупные кодобазы (вроде Google) и инкрементальный рефакторинг без полного переписывания.
• Упоминается, что принятие Rust в Linux пока ограничено (драйверы, отдельные подсистемы), а будущее Kotlin и Swift вне их экосистем (Android/Apple) остается под вопросом.

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

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

• Разработчик создал игру, использующую датчики движения AirPods для управления через повороты головы, что было воспринято как креативное и ностальгическое решение.
• Пользователи высоко оценили инновационность концепции, проведя параллели с ранними днями App Store, когда приложения были простыми и нестандартными.
• Были высказаны некоторые технические проблемы (например, ошибка отключения AirPods) и пожелания по доработке игрового процесса, включая возможность управления через iPhone.
• Обсуждались технические детали получения данных с гироскопа AirPods и потенциальные аналогичные применения технологии для навигации и доступности.
• Часть пользователей отметила побочные эффекты от игры, такие как укачивание и боль в шее, а также необходимость оптимизации размера приложения.

Memory Integrity Enforcement (MIE) — пятилетняя разработка Apple, объединяющая возможности собственных чипов и ОС для постоянной защиты памяти без потери производительности. Это крупнейшее обновление безопасности памяти в истории потребительских ОС.

Атаки на iOS ограничены шпионским ПО уровня государств: ценой миллионы долларов, они используют цепочки эксплойтов, основанные на уязвимостях безопасности памяти. Чтобы закрыть этот вектор, Apple:

• создала безопасный язык Swift и переписывает на нём код;
• в iOS 15–17 ввели «типизированные» аллокаторы kalloc_type и xzone malloc, усложняющие эксплуатацию;
• в 2018 году первыми внедрили PAC в A12 для защиты целостности управления;

Оценив стандарт MTE (2019), Apple нашла в нём слабые места и совместно с Arm доработала спецификацию до Enhanced MTE (EMTE, 2022). Ключевые требования Apple: синхронная проверка тегов, постоянная работа и скрытность тегов от злоумышленника. Для этого потребовались глубокие доработки железа, ядра, драйверов и приложений.

• Apple представила Memory Integrity Enforcement (MIE) — систему аппаратно-программной защиты от повреждения памяти, работающую синхронно и по умолчанию на iPhone 17.
• MIE использует расширенное тегирование памяти (EMTE), что резко сокращает число рабочих эксплойт-цепочек: даже при наличии багов восстановить цепь не удалось.
• 4-битные теги (1/16 шанс угадать) защищены частым перевыбором seed и мгновенным крашем при промахе, что делает вероятностные атаки непрактичными.
• Критики отмечают: механизм не спасает от цепочек поставки и усложняет джейлбрейки, превращая устройства в «коммерческие терминалы» без возможности «покопаться внутри».
• Спор об «отсутствии массовых вредоносов» для iPhone: приводятся примеры XcodeGhost, Pegasus и других, но Apple считает их узкими кампаниями, а не эпидемиями.

Проблема выражений и её решения

Проблема выражений: нужно добавлять новые типы данных и новые операции без изменения старого кода.
В ООП-языках легко добавлять типы (наследование), но сложно — операции (менять интерфейс).
В функциональных языках наоборот: легко добавлять функции, сложно — варианты данных.

Пример на C++
Базовый класс Expr с двумя методами: Eval() и ToString().
Новый тип — просто новый класс-наследник.
Новая операция — правим базовый класс и все наследников, нарушая OCP.

Функциональный подход (Haskell)
Типы данных и функции разведены:

data Expr = Constant Double | BinaryPlus Expr Expr
eval (Constant x) = x
eval (BinaryPlus a b) = eval a + eval b

Добавить операцию легко: пишем новую функцию.
Добавить вариант Expr — правим сам тип и все функции, pattern-match’и которых его затрагивают.

Как быть

• Визитор (ООП) — двойная диспетчеризация, но код всё равно растёт.
• Мультиметоды (CLOS, Clojure) — выбор по типу всех аргументов, код не трогается.
• Type-class / протоколы (Haskell, Clojure) — «открытые» функции, реализуемые вне исходного модуля.
• Tagless-final / finally-tagless — выразить язык как набор операций, интерпретаторы добавляются без изменения AST.

Итог: ни один стиль не побеждает; выбираем язык и технику, которая даёт нужную сторону расширяемости.

• Суть проблемы: нужно добавлять новые типы данных и новые операции без переписывания старого кода и без потери статической безопасности.
• Классический подход: O·T матрица — каждая операция реализуется для каждого типа; при росте O или T взрывается boilerplate.
• Языковые решения:
  – трейты/impl в Rust, typeclass в Haskell, протоколы в Swift позволяют добавлять операции «сбоку»;
  – enum (суммарные типы) упрощают добавление операций, но затрудняют новые варианты данных.
• Продвинутые техники: tagless-final, object algebras, data types à la carte, multiple dispatch, visitor-pattern.
• Ограничения: «сиротское правило», отсутствие виртуальных extension-методов, необходимость заранее знать все комбинации при раздельной компиляции.
• Вывод: идеального языка нет; выбор зависит от того, что важнее — расширять типы или операции — и насколько нужна статическая типизация.

• Крис Латтнер (LLVM, Swift) делает новый язык Mojo, чтобы ML-код был быстрым и удобным.
• Проблема: GPU-ядра пишутся на CUDA/OpenCL вручную, медленно и зависят от одного вендора.
• Решение: язык с метапрограммированием и типами, который «знает» об аппаратуре и генерирует оптимальный код под любую платформу.
• Цель: один код → любой GPU/CPU, открытая экосистема, no lock-in.

• Mojo обещает «Python++, но быстрый», но до сих пор нет полноценных классов, а «полный суперсет» превратился в мягкое «всё ещё не Python».
• Лицензия проприетарная — для многих это стоп-фактор: «сделайте GPL или идите лесом».
• Экосистема Python неподвластна: все уже завязаны на PyTorch/CUDA, а Mojo пока не даёт причин мигрировать.
• Julia, Elixir/Nx, CuPy, Triton, Numba — всё уже умеют «быстро + GPU», без нового языка.
• Итог: Mojo выглядит технически интересным, но «ещё один закрытый язык» в 2025 году воспринимается как ненужный риск.

• В iOS Clock много мелких, но раздражающих проблем: «AM/PM» не успевает зафиксироваться при быстром свайпе, кнопки «Отложить/Стоп» расположены по-разному в будильнике и таймере, а таймер иногда не звонит.
• Пользователи жалуются на неудобное вертикальное колесо: длинный линейный список вместо кругового, нет быстрого перехода к 00, сложно попасть точно.
• Обнаружен «хак» в UIPickerView: чтобы имитировать бесконечный скролл, Apple просто делает очень длинный список строк; реального кольцевого буфера нет.
• Некоторые просят добавить «пропустить завтра» для повторяющихся будильников, календарные будильники и нормальное числовое поле ввода.
• Часть проблем решается переходом на 24-часовой формат или Siri, но общий консенсус: дефолтное приложение давно требует переработки.

Кратко:
С декабря 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-ов рискуют остаться без обновлений: придётся форкать и мигрировать вручную или ждать сообщества.

sosumi.ai — Apple-доки для ИИ
Замените developer.apple.com на sosumi.ai, и LLM получит Markdown вместо «включите JavaScript».

Пример:
https://sosumi.ai/documentation/swift/array

MCP

{ "mcpServers": { "sosumi": { "command": "npx", "args": ["-y", "mcp-remote", "https://sosumi.ai/mcp"] } } }

Ресурс: doc://swift/array
Инструмент: search(query) — поиск по документации.

Проект неофициальный, не копирует массово, кеширует 30 мин, соблюдает ToS Apple.

• Проект Sosumi.ai превращает документацию Apple в «AI-дружественный» Markdown, потому что LLM плохо читают динамически-рендерящийся HTML.
• Некоторые считают, что «AI-readable» лишнее — достаточно просто «Markdown» для людей.
• Есть просьбы: локальный архив, поддержка других сайтов, easter-egg со звуком Sosumi.
• У Apple уже есть частично похожее решение, но оно скрыто в Xcode.
• Автор обещает выложить код в open-source после приборки.

Xcode 26 Beta 7

• macOS 15.4+ требуется
• Swift 6.1 и Swift 6.0.3 включены
• iOS 18.4, macOS 15.4, watchOS 11.4, tvOS 18.4, visionOS 2.4 SDK обновлены

Новое

• Swift Testing теперь по умолчанию
• Preview canvas работает без симулятора
• Metal debugger поддерживает mesh shaders
• Instruments добавлен шаблон Swift Concurrency

Исправлено

• SourceKit-LSP не крашится при больших проектах
• Simulator корректно отображает Dynamic Island
• TestFlight теперь принимает билды с App Intents

Известные проблемы

• CarPlay симулятор не запускается
• XCTest может зависать при parallel testing
• SwiftUI .animation(.default) ломает navigation transitions

Устарело

• Interface Builder для watchOS storyboards
• bitcode полностью удалён

Скачать

• Apple Developer Portal

• Apple добавил в Xcode бета-версию интеграции с Claude (Sonnet 4) и GPT-5, но модели не поставляются в комплекте: нужен оплаченный аккаунт у Anthropic/OpenAI и передача кода на внешние серверы.
• Пользователей беспокоят приватность, утечки исходников и отсутствие офлайн-режима; многие считают, что Apple «Sherlock’нула» сторонние плагины.
• Критика Xcode усилилась: баги, медлительность и плохой UX остаются нерешёнными, а встроенный ИИ не компенсирует недостатки.
• Наблюдается ирония: Microsoft, первой внедрившей Copilot, теперь теряет эксклюзивность, поскольку Apple, Google и JetBrains внедряют собственные или альтернативные модели.

Люди слишком уверены в себе. В коде это проявляется так:

if currentLocation.distance(to: target) < 100 {
    print("Вы прибыли!") // А точно ли? 🤨

GPS-координаты приблизительны, но Bool требует выбора. Мы «схлопываем волновую функцию» слишком рано.

В 2014 г. исследователи предложили тип Uncertain<T>, встроенный в систему типов. Я портировал идею на Swift:

import Uncertain

let loc = Uncertain<CLLocation>.from(currentLocation)
let nearby = loc.distance(to: target) < 100
if nearby.probability(exceeds: 0.95) {
    print("Вы прибыли!") // с 95 % уверенности
}

Сравнение возвращает не Bool, а Uncertain<Bool> — вероятность истинности. Под капотом используется распределение Рэлея и метод Монте-Карло; выборка происходит только при необходимости, а SPRT экономит вычисления.

let speed = 400 / Uncertain<Double>.normal(mean: 60, sd: 5)
let ok = speed < 6
print(ok.probability(exceeds: 0.9))

Такой подход делает неопределённость первоклассной и заставляет писать более умный код.

• Обсуждение крутится вокруг идеи «Uncertain<T>» — типа данных, который носит и распространяет неопределённость (ошибки, распределения вероятностей) через обычные вычисления.
• Участники вспоминают похожие подходы: interval arithmetic, вероятностное программирование, fuzzy logic, а также библиотеки Boost, gvar, monad-bayes и Pyro.
• Отмечают, что GPS-ошибки редко бывают круглыми и независимыми; важно учитывать ковариацию и корреляции между переменными.
• Кто-то мечтает о таблицах, где можно вводить «1 m ± 10 cm» и получать правильную пропагацию погрешностей, а кто-то — о языках, где «Uncertain» был бы типом по умолчанию.
• Главный вопрос: почему, несмотря на множество реализаций, такие типы всё ещё не стали мейнстримом в продакшене.

• Пользователи хвалят Bitrig за «волшебство» и качество SwiftUI-интерфейсов, но жалуются на вылеты, пропадание проектов и отсутствие входа через Apple.
• Основные запросы: экспорт кода в Xcode, локальная сборка без облака, поддержка WebKit, возможность донастройки после генерации и BYOK-доступ к LLM.
• Не-разработчики рады простоте, но переживают о лимите в 100 сообщений/мес и сборе данных.
• Команда подтверждает: интерпретатор вызывает реальные фреймворки iOS, а не их клоны.

fenster — сверхкомпактная кроссплатформенная GUI-библиотека.

• Особенности:

  • Окно, пиксельный буфер, ввод с клавиатуры/мыши.
  • Один .h файл, ~400 LOC, зависимости: X11 (Linux), Cocoa (macOS), Win32 (Windows).
  • Поддержка C/C++, Zig, Odin, Rust, Go, JS (WASM), C#, Swift, Pascal, Nim, Lua, Python, Ruby, OCaml, Fortran.

• Быстрый старт (C):

#define FENSTER_IMPL
#include "fenster.h"
int main() {
  struct fenster f = {.width = 320, .height = 240, .title = "demo"};
  uint32_t buf[320*240];
  for (fenster_open(&f); fenster_loop(&f) == 0; ) {
    // рисуем
    fenster_sync(&f, buf);
  }
  return 0;
}

• Сборка: cc demo.c -o demo (Linux: -lX11, macOS: -framework Cocoa, Windows: без флагов).

• API (C):

  • fenster_open, fenster_close, fenster_loop, fenster_sync.
  • Поля: width, height, title, keys[64], mouse.

• Лицензия: MIT.

• Fenster — это минимальная C-библиотека, создающая окно с пиксельным буфером, а не полноценный GUI с кнопками и меню.
• Участники отмечают отсутствие скриншотов и просят добавить их в README.
• Название «Fenster» переводится как «окно» на немецком, африкаанс, шведском и других языках.
• Некоторые считают polling-цикл ошибкой, другие считают его допустимым для такой простой задачи.
• В блог-посте нашли опечатку в sizeof и ограничение кода 8-битными цветами.
• Проект вызывает интерес для визуализации данных и как лёгкая альтернатива raylib.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

MapLibre Tile — новый формат векторных тайлов, призванный заменить Mapbox Vector Tile (MVT).
Основные цели:

• меньше размер (до 50 % экономии);
• быстрее парсинг (до 2× ускорения);
• простота реализации без внешних зависимостей.

Ключевые улучшения

• FlatBuffers вместо Protocol Buffers → компактнее и без распаковки.
• структурированные слои: геометрия, атрибуты, индексы — отдельные буферы, что ускоряет выборку.
• delta-кодирование координат и ID → ещё меньше байт.
• встроенный R-tree для быстрого поиска объектов в тайле.

Совместимость

• Поддержка JS, C++, Swift, Kotlin.
• Рендерится в MapLibre GL JS ≥ 5.0 без изменений API.
• Обратная совместимость: конвертер MVT → MLT доступен.

Roadmap
Q4 2024 — стабильная спецификация, конвертеры, примеры.

• Участники рады ускорению декодирования и уменьшению размера тайлов, но опасаются сложности внедрения вне MapLibre.
• Некоторые считают, что узкое место не в загрузке/декодировании, а в памяти и рантайме при множестве слоёв.
• Уже ведётся работа над MapLibre GL JS/Native (Java, JS, Rust, TS); CLI-кодировщик почти готов.
• Ожидается интеграция с Planetiler и, возможно, форк tippecanoe; документация и анонсы через новостную рассылку MapLibre.

Fallinorg – нажмите один раз и Mac станет чистым.
Файлы упорядочены, работает офлайн, данные не уходят в сеть.

Основное

• Локальный ИИ анализирует содержание, а не только имена.
• Полностью офлайн, без интернета.
• Поддержка .txt и PDF на английском.
• Свои папки – вы выбираете, куда складывать.
• Оптимизировано для Apple Silicon.

Покупка

Предпродажа: $9.49 единоразово
— неограниченное количество файлов
— выбор папок
— приватность
— поддержка по e-mail

Купить и скачать

FAQ

• Как анализирует? Sentence Transformers локально.
• Приватность? Всё на вашем Mac.
• Форматы? .txt и PDF, скоро больше.
• Папки? Вы решаете.
• Интернет? Не нужен.
• Intel? Пока нет; пишите на [email] для уведомления.
• Возврат? Пишите на [email] с причиной.
• Обновления? Все мелкие бесплатны; крупные – со скидкой для ранних покупателей.

Подпишитесь на рассылку, чтобы быть в курсе.

• Пользователи жалуются на 357-МБ Python-окружение и просят перейти на CoreML или ONNX Swift-bindings.
• Критика пресейл-цен и отсутствия пробной версии; создатель обещает прояснить условия и добавить roadmap.
• Запросы: поддержка epub/cbr/OCR-многоязычности, пользовательские категории, CLI-версия, Spotlight-импортер.
• Сейчас приложение работает только с PDF/txt, но расширение типов файлов и локализация в планах.
• Найдены опечатки и краши; создатель оперативно исправляет и просит репорты на GitHub.

Как я случайно стал неофициальным разработчиком Apple Wallet для PureGym

47 секунд: зарождение злодея
Каждый вход в PureGym занимал 47 секунд: открыть приложение, дождаться загрузки, нажать «Gym access», дождаться QR. 6 дней в неделю — 282 секунды жизни на вход. Решил оптимизировать.

Восьмилетний PIN
8 лет подряд использую один и тот же 8-значный PIN на турникете. Он никогда не протухал. А QR-код обновляется каждую минуту — спектакль безопасности.

mitmproxy и GitHub
Попытка «заснять» QR и положить в Wallet провалилась — код умирает за минуту. На GitHub нашёл кучу недовольных разработчиков и старые репозитории PureGym.

PassKit: забытый ребёнок Apple
QR-коды PureGym — это обычные signed passes Apple Wallet. Формат .pkpass — ZIP с JSON и подписью. Сгенерировал собственный pass: pass.json, manifest.json, подписал через openssl.

Swift-backend на Vapor
Написал сервис на Vapor:

• авторизация по логину/паролю PureGym
• парсинг JSON с QR-кодом
• генерация нового .pkpass каждые 6 часов
• отдача по deeplink https://pass.puregym.local/{id}

The Great Gym Heist
Запустил сервер на домашнем Raspberry Pi. Первый вход — 3 секунды, без приложения. Через неделю 50+ человек используют мой сервис. Никто не заметил.

Apple Watch
Добавил Watch-расширение: показ pass на двойное нажатие боковой кнопки. Работает даже без телефона.

Цифры

• 47 → 3 секунды входа
• 282 → 18 секунд в неделю
• 50+ пользователей
• 0 жалоб

Бонус
Сделал push-уведомления, если pass не обновился. Добавил темную иконку для Vision Pro.

Неловкая правда
PureGym мог бы сам выдать Wallet-pass за день работы. Но 8 лет никто не заметил.

Этика
Никаких персональных данных не храню, только токен. Если закроют — открою исходники.

Что дальше
Планирую добавить NFC-таг у входа: поднёс Watch — дверь открылась.

• Пользователи делятся опытом работы с ужасным официальным приложением PureGym: медленный старт, отключение фоновой музыки, веб-обёртка вместо нативного клиента.
• Автор статьи сделал собственный Swift-бэкенд и Apple Wallet-пасс, чтобы мгновенно получать обновляющийся QR-код и не ждать 7 секунд загрузки.
• Обсуждают безопасность: 8-значный PIN выдаётся самим сервисом, может быть скомпрометирован, а API, похоже, не имеет нормального rate-limit.
• Сообщают аналогичные истории с другими сетями (TrainMore, Fitness SF, Better) и спорят, почему компании не добавляют Wallet: «не приоритет», «слишком дорого поддерживать», «никому не платят за UX».
• Поднимают юридические вопросы: использование неофициального клиента может нарушать ToS или законы (CFAA в США), но многие считают это разумным «гражданским хакингом».

Проблема
На ноутбуках Mac с «чёлкой» большинство игр по умолчанию выбирают разрешение всего экрана (включая область под чёлкой), хотя рисовать можно только ниже неё. Из-за этого картинка сжимается и размывается. API CGDisplayCopyAllDisplayModes выдаёт смешанный список: полные и фактически доступные 16:10-режимы, но без пометок. Разница в высоте всего 74 px, но её достаточно, чтобы всё выглядело мутно.

Решение
Игрокам: в настройках графики выбирайте 16:10-разрешение.
Разработчикам: фильтруйте список режимов, оставляя только те, что помещаются в safe-area. Пример:

extension NSScreen {
    func safeAreaResolutions() -> [CGDisplayMode] {
        let w = frame.width - safeAreaInsets.left - safeAreaInsets.right
        let h = frame.height - safeAreaInsets.top - safeAreaInsets.bottom
        return CGDisplayCopyAllDisplayModes(...)?
            .filter { $0.width <= w && $0.height <= h } ?? []
    }
}

Какие игры страдают
Практически все, если не задан 16:10 вручную: Shadow of the Tomb Raider, Resident Evil, No Man’s Sky и др.

Что может сделать Apple

• Разделить списки режимов или пометить их флагом.
• Добавить CGDisplayModeGetUsableBounds.
• Сделать 16:10-режим выбором по умолчанию для полноэкранных игр.

• Круглые углы и вырезы экрана вызывают у многих раздражение: вместо идеальной геометрии приходится снова «ломать» картинку ради эстетики.
• Проблема размытого рендеринга в играх на Mac сводится к тому, что игры выбирают «первое» разрешение из списка, не учитывая safe-area и выреза.
• Разработчики жалуются на отсутствие документации и «магическое» поведение macOS, из-за чего каждая игра решает проблему по-своему.
• Часть пользователей считает вырез незаметным, другие вынуждены подключать внешний монитор или отказываться от игр.
• Общий вывод: Apple мало заботится о гейминге на Mac, рынок мал, а документация и инструменты оставляют желать лучшего.