Hacker News Digest

Задача
Лондонское агентство Strand ведёт сотни маркетинг-проектов в год. Финансовый учёт раньше велся вручную через таблицы. В 2020 г. команда из трёх разработчиков запустила прототип финансовой системы; он быстро стал критически важным, и потребовалось обеспечить надёжность и простоту поддержки при минимальных ресурсах.

Решение
Strand выбрал язык Gleam на платформе BEAM:

• Безопасность: чистый код не падает; сбои внешних сервисов изолируются лёгкими процессами.
• Практичность: язык мал, однозначен, осваивается за день; доступны 40 лет библиотек Erlang/Elixir.
• Опыт разработки: единый пакет с форматтером, автодополнением и понятными ошибками; сборка мгновенная.

Система обрабатывает курсы валют, синхронизирует данные с внешним ПО и продолжает расти без роста технического долга.

• Вероятно, языки вроде Gleam выиграют у ИИ благодаря строгой типизации и быстрой обратной связи.
• Некоторые новички застревают в «абстракционном аду» и советуют сначала освоить Erlang/Elixir.
• Производственные истории успеха Gleam на BEAM вдохновляют.
• Однофайловые исполняемые файлы можно собрать через компиляцию в JavaScript + Node SEA или Burrito, но полноценный VM-free релиз пока нет.
• Качество примеров и стабильность языка становятся важнее их количества для LLM.
• Чистые, референциально прозрачные языки удобны ИИ для параллельного тестирования блоков кода.

Предупреждение: это сатира, не используйте в проде. Читая, вы клянётесь не повторять описанное.

Проблема

Managed NAT Gateway в AWS тарифицирует исходящий трафик по 0,07 $/ГБ и убивает стартапы счетами за облако.

Решение

Вместо него для веб-хуков можно:

• поднять exit-ноду Tailscale с публичным IP;
• привязать её к той же VPC;
• получить шифрование и экономию до 700 %.
  Это единственный безопасный фрагмент статьи.

---

S3 как очередь

AWS начинался с S3, SQS и EC2. S3 — это malloc() для облака:

• выделяете «память» (бакет);
• кладёте туда объекты любой длины;
• освобождаете, когда надоедает.

Аналогия с C: malloc() → указатель, free() → удаление объекта. Ошибка выделения → ENOMEM, дальше — краш.

---

Как превратить S3 в очередь

1. Писать сообщения в виде объектов с ключом queue/<uuid>.json.
2. Читать через ListObjectsV2 и GetObject.
3. Удалять после обработки.
4. Повторять раз в секунду — получаем «очередь» с задержкой ~1 с и бесплатным исходящим трафиком внутри региона.

Плюсы:

• нет платы за NAT Gateway;
• S3 дёшев и масштабируем;
• можно шифровать объекты.

Минусы:

• eventual consistency: сообщения могут дублироваться или задерживаться;
• rate limit 3 500 PUT/COPY/POST/DELETE и 5 500 GET/HEAD на префикс;
• ListObjects дорогой (0,005 $ за 1 000 запросов);
• придётся реализовать ack/nack, dead-letter и backoff самому.

---

«Продвинутые» техники

• Long polling: ждать, пока в бакете появится новый объект.
• Fan-out: несколько читателей по префиксам.
• Batching: складывать сообщения в один объект gzipом.
• Priority: префиксы high/, low/.
• FIFO: ключ queue/<timestamp>-<uuid>.json.
• DLQ: префикс failed/.
• Крон: Lambda по расписанию чистит старые сообщения.

---

Итог

S3-очередь — это пародия на архитектуру, но она работает и экономит деньги. Для настоящих задач используйте SQS, Kafka или RabbitMQ.

• Участники вспомнили, как в 90-х использовали Microsoft Exchange вместо дорогого TIBCO, а Amazon Video — S3 вместо очереди, и оба решения оказались «костылями».
• Подчеркивают, что очередь — это просто быстрый конечный автомат, но самописные варианты на SQL или Git-вебхуках быстро ломаются под нагрузкой.
• Некоторые шутят, что любую технологию можно превратить в очередь или базу, если использовать её «достаточно неправильно».
• Обсуждают юридические проблемы с IP, когда хобби-проект пересекается с работой, и сравнивают цены AWS с Whole Foods.
• В итоге сходятся во мнении: костыль может работать, но рано или поздно придётся платить за правильное решение.

Mosh — мобильная оболочка, заменяет SSH.

• Роуминг: меняйте сеть (Wi-Fi, LTE, Ethernet) — соединение живёт.
• Сон и обрывы: ноут спит, связь пропадает — Mosh ждёт и возобновляет.
• Без задержки: локальный эхо-ввод, предсказания подчёркиваются при плохой связи.
• Простота: не требует root, работает как обычный процесс, логинится через SSH, затем переключается на UDP.
• UTF-8: единственная кодировка, чинит юниксовые баги.
• Control-C: UDP-протокол не блокирует буферы, всегда прерывает процесс.

Поддерживаются GNU/Linux, BSD, macOS, Solaris, Android, Chrome, iOS.

• Mosh по-прежнему решает проблему «роуминга» и высокой латентности, но многие перешли на SSH поверх WireGuard/Tailscale.
• Часть пользователей жалуется на баги рендеринга, отсутствие проброса портов и OSC52, а также на замороженную разработку.
• Альтернативы: Eternal Terminal, shpool, wezterm, а также анонсируемый Rust-проект на WebRTC.
• На iOS популярен ShellFish (с tmux и интеграцией Files), Blink Shell теряет позиции.
• Для мобильных/спутниковых каналов Mosh всё ещё «спасательный круг», но кто-то предпочитает просто «терпеть» дропы через tmux/screen.

Почему воюющие страны продолжают торговать

В новой книге «Торговля в условиях войны» МИТ-экономист Мария Гринберг анализирует, почему государства не прерывают торговлю даже в разгар конфликта.

• Исторические примеры
  • Вторая мировая: Великобритания импортировала немецкие красители под бомбардировками.
  • Первая мировая: Лондон торговал с Германией почти всю войну.
  • Индия и Пакистан — во время войн 1947–49 и 1965.
  • Хорватия и Югославия — в 1992 году.

• Логика лидеров
  Решение вести торговлю основано на компромиссе:
  – военный риск: противник может получить стратегически важные товары;
  – экономический ущерб: разрыв торговли ведёт к потере рынков и выгод для третьих стран.

Гринберг показывает, что государства сознательно продолжают обмен невоенными товарами, если выгода превышает риск.

• Торговля между воюющими сторонами — обычное дело: интересы государств и отдельных компаний/людей редко совпадают, а выгоды от сделок могут перевешивать идеологию.
• Примеры: Украина до 2025 г. прокачивала российский газ, США покупают российские удобрения, европейские страны продолжают закупать газ у РФ, одновременно поставляя оружие Украине.
• Технически остановить потоки сложно: газ нельзя просто «переключить», а разрыв контрактов влечёт штрафы.
• Элиты обеих сторон часто живут за границей (Дубай) и координируют схемы, в то время как солдаты и граждане несут издержки.
• Прогнозы о длительности войн почти всегда ошибочны: исключения — Война в Заливе 1991 и Шестидневная война 1967.

Коротко о «strongly happens-before»

В C++20 появилось новое отношение strongly happens-before (SHB), потому что старое happens-before оказалось недостаточно строгим.

Пример кода

std::atomic<int> x{0}, y{0};

// thread-1
x.store(1, seq_cst);
y.store(1, release);

// thread-2
int b = y.fetch_add(1, seq_cst); // b = 1
int c = y.load(relaxed);         // c = 3

// thread-3
y.store(3, seq_cst);
int a = x.load(seq_cst);         // a = 0

Почему нужен SHB

• Каждый атомарный объект имеет modification order — полный порядок всех записей.
• Классические правила coherence (write-write, read-read, read-write, write-read) связывают happens-before с этим порядком.
• Но при смешанных memory_order (например, release + seq_cst) между потоками могут образоваться «дыры», где старое happens-before не гарантирует ожидаемую последовательность.

Отличие SHB от HB

• SHB добавляет требование: если операция A strongly happens-before B, то все наблюдатели видят записи A раньше записей B, даже при разных memory_order.
• Для seq_cst SHB совпадает с HB; для release/acquire HB может быть, а SHB — нет.

Итог

Если пользуетесь только seq_cst, можно не заморачиваться. При смешанных порядках SHB — формальный способ не получить «невозможные» значения.

• Участники обсуждают различие между «strong happens-before» в Java и более слабой моделью C++.
• Код из статьи считается не «простым», а академическим примером; порядок запуска потоков ОС не гарантирует.
• Наблюдаемые в комментариях значения могут показаться странными, но они допустимы при отсутствии дополнительной синхронизации.
• Смысл слабых моделей памяти — формально описать множество всех допустимых исполнений, учитывая кэши, оптимизации компилятора и т. д.
• Добавление ещё одного атомика для «упорядочивания» может, наоборот, запретить именно тот «неинтуитивный» порядок, который автор статьи исследует.

Кратко: ИИ — полезный инструмент, но не заменяет мышление. Используйте его для автодополнения, генерации диаграмм или быстрого поиска, но не для архитектуры, написания статей или кода «под ключ». Долгосрочная зависимость ведёт к потере навыков и остановке обучения.

---

Когда стоит использовать ИИ

• Короткий горизонт: автодополнение, мелкие функции — +20 % скорости.
• Длинный горизонт: архитектура, стратегия — чем дальше план, тем выше риск ошибок.
  Правило: решайте за 6 недель (Shape Up), не стройте дорожные карты на годы.

---

Бездушный текст

Генеративный текст не несёт опыта, чувств и «души». Читатели это почувствуют, а вы потеряете способность создавать новые идеи.

---

Отвлечение

Grammarly, Copilot, Cursor не дают 2 секунд подумать. Мы перестаём быть за рулём и теряем поток. Выключите подсказки, чтобы вернуть мышление.

---

Не поймите превратно

Я пользуюсь ИИ каждый день, но осознанно: выключил Copilot и Grammarly.
Совместное «LLM + человек» полезно, но человеческие инсайты, рождённые через труд и опыт, не заменить.

---

Мнения экспертов

• Paul Graham: писать вручную — единственный способ мыслить ясно.
• Nathan Baugh: ИИ помогает черновикам, но финал должен быть человеческим.
• Ted Gioia: музыка без человеческого вкуса превращается в шум.
• Mitchell Hashimoto: код, написанный ИИ, сложнее поддерживать.
• Andrew Ng: ИИ ускоряет, но не устраняет обучение.
• Harry Dry: маркетинг без эмпатии не работает.
• Jason Fried: автономные «вайб-кодеры» создают технический долг.
• David Perell: писатель должен оставаться «диктатором», а не «редактором» ИИ.
• Ezra Klein: общество рискует потерять навык глубокого чтения и письма.

---

Кого заменит ИИ?

• Писателей? Нет. Спрос на живые тексты вырастет.
• Data-инженеров? Рутину возьмёт ИИ, но архитектуру и контекст — человек.
• Генерация картинок? Быстро, но художник нужен для вкуса и деталей.

---

Как распознать ИИ-текст

• Идеальный слог без шероховатостей.
• Отсутствие личных историй и чувств.
• Повторяющиеся обороты и «водянистые» формулировки.

---

AI-slop: компании, которые теряют

• Сайты, залитые шаблонными статьями.
• Стартапы, где продукт = обёртка над GPT.
• Бренды, потерявшие уникальный голос.

---

Учиться с ИИ

• Используйте как репетитора: задавайте вопросы, проверяйте ответы.
• Не копируйте код слепо — разбирайте каждую строку.
• Создавайте flash-карты из объяснений ИИ, но добавляйте собственные примеры.

---

Будущее

• Через 5 лет «ручная» работа станет премиальной.
• Навык «писать без ИИ» будет цениться как «готовить из нуля».
• Победят те, кто использует ИИ как велосипед для ума, а не как инвалидную коляску.

---

Что почитать дальше

• «Writing Manually»
• «Shape Up» (Basecamp)
• «The Work of Art in the Age of Mechanical Reproduction» — Вальтер Беньямин
• «Deep Work» — Cal Newport

• Пользователи переходят от «Claude Code» к отдельному приложению, чтобы не терять контроль над кодом.
• Многие считают, что ИИ справляется с 70–90 % задач, но «последние 10–25 %» требуют человека, иначе страдает качество и безопасность.
• Есть опасение, что чрезмерное доверие ИИ лишит новых разработчиков опыта «низкоуровневого» программирования.
• Предлагают режимы обучения, где ИИ объясняет каждое изменение и проверяет понимание, чтобы снизить будущую зависимость.
• Дискуссия сводится к тому, что навык «писать код» эволюционирует в навык «задавать правильные вопросы и проверять ответы».

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

• Участники делятся опытом операций и наркоза: кто-то описывает «эйфорию выжившего», кто-то — страх перед операцией и осознание своей смертности.
• Обсуждается природа сознания: одни считают его эмерджентным явлением, другие — пассивным наблюдателем мозговых функций, третьи отрицают устойчивое «я».
• Несколько человек упоминают, что пережитое изменило их приоритеты и восприятие жизни надолго.
• Часть комментаторов подозревает, что сама статья написана с помощью ИИ, и жалуется на «LLM-стиль» коротких фраз и «гулов».

• Почему Pi?
  На слабом железе быстрее всплывают ошибки конфигурации, поэтому эксперимент с TrueNAS на Pi 5 — отличный способ учиться.

• Проблема: нет UEFI
  Pi официально не поддерживает UEFI. Используем форк rpi5-uefi.

• Подготовка Pi 5

  1. Обновите EEPROM до ≥ 2025-06-09 (sudo rpi-eeprom-update -a, при необходимости переключитесь на beta-канал).
  2. Скачайте последний релиз rpi5-uefi, распакуйте содержимое .zip в FAT32-раздел microSD.
  3. Вставьте карту, подключите HDMI, включите Pi. Должен появиться EDK2 Boot Manager.

• Установка TrueNAS

  1. Скачайте ARM-образ TrueNAS (например, 25.04.2) с truenas-releases.jmay.us.
  2. Запишите ISO на USB-накопитель (Etcher).
  3. Загрузитесь с USB через UEFI Boot Manager.
  4. Установите TrueNAS на любой диск, кроме microSD и установочной флешки (второй USB или NVMe).

• Кто-то давно отказался от TrueNAS/FreeNAS в пользу самостоятельной настройки Samba+NFS+ZFS на мини-ПК.
• Многие считают Raspberry Pi слабым и ненадёжным для NAS: проблемы с SATA/USB, отсутствие ECC, низкая пропускная способность.
• Другие успешно годами держат Pi-4 с Ubuntu+Samba+Jenkins, но используют внешние USB-хабы и не нагружают систему.
• TrueNAS критикуют за громоздкий UI, «лагающие» бэкапы Time Machine и лишний оверхед на слабом железе.
• Часть участников предпочитают готовые решения (QNAP, Synology) или Proxmox+ZFS на Intel N100: быстрее, стабильнее, проще.

• Исследование Стэнфорда: с 2022 г. занятость американцев 22–25 лет в профессиях, наиболее подверженных ИИ, упала на 13 %.
• Под ударом — кол-центры, бухгалтеры, разработчики ПО.
• Данные ADP показывают: молодёжь теряет места, тогда как общая занятость растёт.

• Участники сомневаются, что AI уже массово «забирает» работу: в бухгалтерии и других «уязвимых» сферах его практически не используют, а при попытке применения он «галлюцинирует».
• Многие считают, что заявления о сокращениях из-за AI маскируют реальные причины: офшоринг в Индию/Филиппины, экономический спад, высокие ставки и реорганизацию работы.
• Отмечается исчезновение начальных позиций: компании не увольняют, а просто перестают нанимать молодых, лишая их пути входа в профессию.
• Ряд комментаторов подчеркивает, что руководство предпочитает сокращать штат, а не усиливать сотрудников AI, чтобы сохранять контроль и снижать расходы.
• Сторонники «техно-оптимизма» напоминают: автоматизация шла десятилетиями, и в долгосроке она делает товары и услуги дешевле, но краткосрочные потери рабочих мест требуют адаптации.

Булево значение почти всегда маскирует более точный тип.
Проверь, не дата-время ли это: is_confirmed лучше заменить на nullable confirmed_at. Вы получите момент подтверждения и сможете анализировать баги по времени.

Если поле описывает роль или статус (is_admin, failed), превращайте в enum.

enum UserRole { User, Admin, Guest, SuperAdmin }
enum JobStatus { Queued, Started, Failed, Done }

Enum упрощает добавление новых состояний и защищает от забытых веток.

Проверка прав тоже не должна возвращать bool.

enum PermissionCheck { Allowed, NotPermitted(reason: String) }

Так код читабельнее и можно вернуть причину отказа.

Когда же использовать bool? Только как временную переменную-флаг для сложного условия, чтобы не вычислять его дважды или дать имя.

• Основной спор: стоит ли хранить «события» как булевы флаги или как nullable-даты/enum’ы, чтобы не терять данные (время события).
• Противники: это нарушает KISS, раздувает схему и вводит двусмысленность (null = не случилось или ошибка?).
• Сторонники: булевы поля не «помнят» контекст, легко образуют недопустимые комбинации флагов, а дата или enum выразительнее.
• Для параметров функций булевы флаги считаются плохо читаемыми; спасают именованные аргументы, отдельные функции или бит-маски.
• Встраиваемые/индустриальные системы часто считают булевы типы оптимальными по памяти и не применяют совет к себе.