Hacker News Digest

Написанная на Rust утилита ut предлагает разработчикам набор инструментов для повседневных задач, вдохновляясь функциональностью it-tools.tech. Она включает конвертеры, генераторы хешей, кодировщики и другие инструменты для работы с данными, кодом и системами. Проект стремится объединить распространённые утилиты в одном месте, упрощая доступ без переключения между сервисами.

Использование Rust обеспечивает высокую производительность и безопасность, а модульная архитектура позволяет легко расширять функционал. Это решение особенно полезно для команд, ценящих локальные инструменты без зависимости от облачных сервисов.

• Предложения по распространению: упаковать как Python и NPM модули для удобного запуска через uvx или npx, использовать cargo-dist для автоматизации.
• Критика архитектуры: обсуждается целесообразность единого бинарника (по аналогии с BusyBox) против множества отдельных утилит в духе UNIX-философии "делай одно дело хорошо".
• Вопросы к функционалу: предостережения против включения слишком большого количества функций (например, HTTP), предложения добавить конкретные команды (uuidv7, retry).
• Замечания по реализации: критика требований к вводу (только UTF-8, чтение stdin до EOF), отсутствие тестов для кода, созданного с помощью ИИ.
• Общая оценка: инструмент воспринят как удобный "швейцарский нож" с продуманными умолчаниями, но вызвал дискуссию о разумных пределах его роста.

UTF-8 — гениальное решение: 1–4 байта на символ, полная совместимость с 7-битным ASCII.
Старший бит первого байта сразу говорит, сколько байт идёт дальше:

Паттерн 1-го байта	Длина	Пример
0xxxxxxx	1	ASCII
110xxxxx	2
1110xxxx	3
11110xxx	4

Продолжения всегда 10xxxxxx.
Программа читает байт, по префиксу понимает длину, выделяет «полезные» биты, получает кодовую точку Unicode и выводит символ.

Пример:
хинди «अ» = 11100000 10100100 10000101 → U+0905.

Файл Hey👋 Buddy (13 байт):
H e y 👋 B u d d y
👋 кодируется 4 байтами 11110000 10011111 10010001 10001011 → U+1F44B.

• UTF-8 — гениальное, простое и обратно-совместимое с ASCII решение, придуманное Кеном Томпсоном и Робом Пайком за ужином.
• Продолжение-байты 10xxxxxx позволяют за O(1) найти границы символа, не парся весь поток.
• Критика: Unicode «раздулся» (комбинирующие символы, эмодзи, 25-байтовые «графемы»), а UTF-8 не сам компактен для нелатиницы.
• Спор о «переполнении»: 4 байт хватает на 21 бит → 2 097 152 кодовых точек; 5-6 байт запрещены специально.
• Некоторые считают, что красота UTF-8 — не комитетное изобретение, а удачный частный хак, вышедший в мировой стандарт.

Новый экспериментальный JSON-API в Go

Go 1.25 предлагает encoding/json/v2 и encoding/json/jsontext — переработанные пакеты для работы с JSON. Они решают давние проблемы стандартного encoding/json и пока доступны только по флагу GOEXPERIMENT=jsonv2.

Главные недостатки старого API

• Неточности синтаксиса: принимает невалидный UTF-8, дублирует ключи, трактует числа как float64.
• Производительность: 2-3× медленнее современных альтернатив; каждый вызов тратит память на рефлексию.
• Гибкость: нельзя пропустить неизвестные поля, работать с потоковым JSON, получать исходный текст, сохранять порядок ключей, использовать сторонние типы.

Что нового в v2

• Три пакета
  – jsontext — низкоуровневое чтение/запись токенов, сохраняет формат.
  – json — высокоуровневый marshal/unmarshal, совместим с v1, но строже и быстрее.
  – jsontext можно использовать отдельно для потоковой обработки.

• Строгость
  UTF-8 проверяется, дубли ключей — ошибка, числа не теряют точность.

• Производительность
  Без рефлексии в hot-path, 2-3× быстрее, меньше аллокаций.

• Новые возможности
  Пропуск неизвестных полей, сохранение порядка, работа с any, доступ к сырому JSON, совместимость с v1 через теги.

Как попробовать

GOEXPERIMENT=jsonv2 go mod download

import "encoding/json/v2"

Фидбек приветствуется: golang.org/issue/71497.

• Вышел экспериментальный encoding/json v2: новый API, лучшая производительность, но спорные решения по nil-значениям.
• Часть пользователей рада росту скорости и модульному пакету jsontext; другие считают, что костыли с nil → null остались.
• Кто-то уже прогнал тысячи тестов — почти всё прошло; кто-то нашёл регрессию аллокаций. Авторы просят больше отзывов.
• Сравнения со сторонними библиотеками (Sonic, goccy) показывают выигрыш в CPU, но проигрыш в безопасности и поддержке ARM.
• Обсуждение выродилось в холивар: «почему за 15 лет JSON до сих пор не решён» vs «две v2 за всю историю — отличный результат».

В 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» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.