Hacker News Digest

Плюсы Nim 2

• Память: по умолчанию ORC/ARC (RAII, деструкторы, move/copy), а не трассирующий GC. Можно --mm:none или --mm:atomicArc.
• Компилируется в C/C++/Obj-C/JS; выбираем компилятор (gcc, nvcc, …).
• Лёгкая интеграция: {.importc.}, {.importcpp.}, {.importjs.}, {.compile.} для сторонних файлов.
• Метапрограммирование: макросы, static исполнение кода на этапе компиляции, генерация CUDA.
• Краткость: мало шаблонного кода (чат на 70 строк).
• Производительность ≈ C/C++/Rust; поддержка SIMD, CUDA.

Минусы и подводные камни

• Генерируемый C/C++ код нечитаем — не цель проекта.
• Нет атомарных счётчиков в ORC по умолчанию (требуется флаг).
• Некоторые старые статьи/комментарии описывают Nim 1.x (GC по умолчанию).
• Синтаксис чувствителен к отступам и регистру (но это субъективно).

Мини-пример: простой key/value формат

import std/[tables, strutils]

type Config = object
  host*: string
  port*: int

proc loadConfig(path: string, T: typedesc): T =
  let data = readFile(path).splitLines()
  var kv = initTable[string, string]()
  for line in data:
    let parts = line.split('=')
    if parts.len == 2:
      kv[parts[0].strip()] = parts[1].strip()

  result.host = kv.getOrDefault("host", "localhost")
  result.port = parseInt(kv.getOrDefault("port", "8080"))

let cfg = loadConfig("app.conf", Config)
echo cfg.host, ":", cfg.port

Файл app.conf:

host = 0.0.0.0
port = 9000

Всё компилируется в один бинарник без GC-задержек.

• Пользователи отмечают редкую, но полезную возможность Nim — определять собственные операторы.
• Хвалят макросы, интегрированные в систему типов и перегрузку, сравнивая язык с «статически типизированным Lisp».
• Критика: сложности с Windows (Nimble-зависимости тянут GCC, Defender блокирует бинарники) и неоднозначная «фантастическая» интеграция с C++.
• Обсуждают объём JS-артефактов: для мелких примеров — десятки килобайт, но без оптимизации могут быть мегабайты.
• Для WASM рекомендуют компилировать в C и прогонять через Emscripten, но стандартные JS-биндинги не работают.
• Вопросы IDE: есть nimsuggest и быстрая настройка для Neovim, но плагинов для JetBrains почти нет.

Rupert’s property — возможность прорезать в выпуклом многограннике отверстие, достаточное для прохода точно такого же многогранника. До недавнего времени считалось, что это верно для всех выпуклых многогранников.

На этой неделе Steininger и Yurkevich нашли контрпример: выпуклый многогранник с 90 вершинами, не обладающий Rupert’s property.

• 240 рёбер, 152 грани.
• Проверено 18 млн вариантов отверстий + дополнительная математика.
• Назван noperthedron (игра слов: «нет Rupert»).

Историческая справка
Принц Руперт предположил, что в единичном кубе можно вырезать отверстие, через которое пройдёт куб с ребром ≈ 1,06. Подтвердил Джон Уоллис; позже Ньивланд нашёл максимальный размер.

Анимации

• Куб
• Октаэдр
• Видео — 26 многогранников с Rupert’s property и 5 подозрительных (включая триакис-тетраэдр, который всё-таки «проходит»).

Ссылка на статью
arXiv:2508.18475

• На SIGBOVIK-2025 Том7 опубликовал доказательство, что не всякий выпуклый многогранник обладает свойством Руперта: найден «Noperthedron», который не является Rupert.
• Формулировка «Всякий ли выпуклый многогранник Rupert?» уже была добавлена в репозиторий формальных гипотез Google; обсуждается, насколько трудно будет формализовать новое доказательство в Lean.
• Участники вспомнили, что Мэтт Паркер и Numberphile делали видео о том, как куб можно протянуть через такой же куб.
• Имя «Noperthedron» дано в честь шуточного термина «Nopert» из статьи Том7.

16 января 2003 г. «Колумбия» стартует с семью астронавтами на борту. Через 82 с после старта кусок изоляционной пены со скоростью 29 тыс. км/ч ударяет по кромке левого крыла, повредив теплозащитную плитку.

На Земле инженеры Boeing за 28 слайдов PowerPoint объясняют риски: испытания проводились с пеной в 600 раз легче. Главный слайд — график, где толщина пены и урон выглядят незначительными. NASA решает, что повреждение не критично, отклоняет варианты спасения (выход в открытый космос, запуск второго шаттла) и разрешает возвращение.

1 февраля 2003 г., 09:00 по восточному времени. «Колумбия» входит в атмосферу, повреждённое крыло не выдерживает температуры, шаттл разрушается на высоте 61 км. Погибают все семь человек.

Презентация, где ключевые риски затерялись среди аббревиатур и мелкого шрифта, стала примером «смерти от PowerPoint» буквально.

• Участники спорят, виноват ли PowerPoint в катастрофе «Колумбии»: одни считают, что проблема в самом инструменте, другие – в разрыве между инженерами и руководством.
• Подчёркивается, что слайд из статьи – пересозданный, а оригинальный доклад Тафта (Tufte) рекомендует отдавать предпочтение полноценным текстовым отчётам вместо презентаций.
• Несколько комментаторов напоминают: у «Колумбии» не было топлива до МКС, запасов жизнеобеспечения и стыковочного оборудования для возможной спасательной миссии.
• Выясняется, что скорость пенопластового блока при ударе была существенно меньше скорости полёта шаттла, а сама пена превышала масштаб испытаний в десятки раз.
• Общий вывод: не PowerPoint убивает проекты, а культура, в которой ключевые риски сводятся до нечитаемых тезисов и не доходят до принимающих решения.

Всё ПО содержит баги; чем сложнее код, тем запутаннее ошибки. Однажды я столкнулся с «однострочным» фиксом, который спас пользователей от случайных отказов Anubis.

Как всё началось
Anubis — WAF, который проверяет, что клиент — настоящий браузер. Основной способ — proof-of-work: клиент считает хэши, ограничивая скорость подключения. Чтобы экран-заглушка исчезал быстрее, JS-код использует максимум ядер CPU.

Проблема
Firefox тормозит, если задействовать все ядра; оптимум — половина. В коде было:

threads = Math.max(navigator.hardwareConcurrency / 2, 1)

Все мои тестовые устройства (MacBook, Ryzen, iPhone, Steam Deck…) имели чётное количество ядер, поэтому navigator.hardwareConcurrency / 2 всегда получался целым. Но если устройство с нечётным числом ядер (например, 3), результат — 1.5. JavaScript-числа — это IEEE-754, и дробная часть приводила к багу «invalid response», потому что логика расчёта nonce рассчитана на целые.

Фикс
Округлил до ближайшего целого:

threads = Math.max(Math.floor(navigator.hardwareConcurrency / 2), 1)

Одна строчка — и исчезли случайные отказы на нечётных CPU.

• Разработчики Anubis не учли, что бывают процессоры с нечётным числом ядер (3, 9 и т.д.), из-за чего проверка «кол-во ядер = степень двойки» ломается.
• Пользователи жалуются: на телефонах с 9 ядрами (S24+) тест висит и жрёт батарею, а без JS сайты работают быстрее.
• Часть комментаторов считает PoW-валидацию бесполезной: боты всё равно запускают JS, а легитимные пользователи платят тем же временем/энергией.
• Предлагают отказаться от PoW в пользу «Proof of React» или просто убрать жёсткую привязку к числу ядер.
• Некоторые отключают JS и cookies по умолчанию и обходят Anubis, но всё чаще просто уходят с сайтов.

Официальный сервер Elixir по протоколу LSP
Репозиторий elixir-lang/expert содержит реализацию Language Server Protocol для языка Elixir.

• Цель — обеспечить редакторам и IDE полную поддержку Elixir: автодополнение, навигация, рефакторинг, диагностика.
• Архитектура — сервер написан на самом Elixir, использует GenLSP для обработки JSON-RPC сообщений.
• Функции
  • анализ кода в реальном времени через mix compile --warnings-as-errors;
  • подсказки по типам и документации из @spec и @doc;
  • поиск определений и ссылок по всему проекту;
  • форматирование через mix format;
  • встроенный отладчик и поддержка IEx.
• Установка — добавьте зависимость {:expert, "~> 0.1"} в mix.exs или установите плагин для VS Code / Vim / Emacs.
• Вклад — принимаются PR и issue; следуйте гайду CONTRIBUTING.md.

• Новый LSP «Expert» — результат объединения усилий всех существующих реализаций (ElixirLS, Lexial, next-ls).
• Архитектура продумана до мелочей: поддержка разных версий языка и защита пространств имён приложений.
• Название «Expert» вызвало споры: кто-то считает его высокомерным, кто-то — забавным и в духе экосистемы.
• Это первый «официальный» LSP под эгидой elixir-lang, но без постоянного участия core-команды.
• MCP напрямую не поддерживается; для LLM-контекста рекомендуют TideWave.

• Речь не о «смерти» скейлинга, а о том, как масштабироваться дальше при 4–8-часовых METR-задачах.
• Основной тормоз — нехватка качественных данных: интернет почти исчерпан, а человеческие тексты кишат ошибками.
• Многие предлагают выход: видео, аудио, 3D, симуляции, синтетика, RL-циклы с верифицируемыми наградами.
• Сравнение с человеком: мозг учится на крошечном объёме данных и опыте, значит, архитектуры пока неэффективны.
• Кто-то считает, что задача не в количестве данных, а в их структуре и способе подачи (curriculum, пост-обработка).

FuckUpMySite — преврати любой сайт в хаос.

• Деструкция: 0 %
• Лозунг: fuckfuckfuckfuckupupupupmymymymysitesitesitesite
• Девиз: «Некоторые просто хотят смотреть, как горит веб».

Попробуй на: Sentry.io, Hacker News, Apple, Stack Overflow
Кнопка: «FUCK THIS SITE UP»

😈 Настройки хаоса

(3 из 6 активны)

• 🔥 Пылающий курсор — курсор поджигает страницу
• 🤪 Comic Sans всё — весь текст Comic Sans
• 👻 Фальшивые курсоры — множество поддельных теней
• 🪰 Назойливая муха — жужжит по экрану
• 🏃 Убегающие кнопки — прячутся от мыши
• 🔨 Попап-лопатка — ложные окна, которые нужно закрывать

Не все сайты дружат с хаосом. Нашёл баг? Напиши в Twitter.

• Участники обсуждают сайт-шутку, который «ломает» любую страницу: Comic Sans, ползающие жуки, огонь и т.д.
• Браузеры (Chrome, Firefox, Safari) блокируют его как «опасный», что вызывает смех — предупреждение идеально вписывается в дух проекта.
• Некоторые сравнивают его с Katamari Hack, Desktop Destroyer, netdisaster и старыми оверлеями 90-х.
• Работает не везде: падает на Whitehouse.gov, opennet.ru, сайтах с Anubis, а также на самом себе.
• Люди делятся ссылками на «испорченные» версии Fox News, Apple и др.; кто-то просит npm-пакет для розыгрыша.

Современный веб без JS
Фреймворки вроде React и NextJS часто превращают сайты в тяжёлые, медленные и ошибочные конструкции. Виной тому не столько сами фреймворки, сколько килобайты трекеров и плохой код. Тем не менее, многим проектам JavaScript вовсе не нужен — HTML и CSS способны на многое.

CSS не так плох
Негатив к CSS часто идёт от незнания основ. Его считают «карандашом для рамок», хотя это полноценный язык. Центрировать div сегодня тривиально: display: flex; justify-content: center; align-items: center;. В девтулзах есть интерактивный редактор flexbox, забыть синтаксис невозможно.

Писать стало приятно
CSS-фичи последних лет убрали боль:

• Вложенность без препроцессоров
• Кастомные элементы <cool-thing shadow>
• Логические свойства, clamp(), aspect-ratio, @container, :has() и др.

Пример старого vs нового
До:

.post > .buttons .like:hover { color: var(--like-color-hover); }

После:

.post {
  .buttons .like:hover { color: var(--like-color-hover); }
}

Итог
Я не призываю отказаться от JS полностью, но показываю, что большинство сайтов могут обойтись без него, если грамотно использовать современный CSS.

• Некоторые считают CSS «ужасным» и «загадочным», другие — наоборот, хвалят его эволюцию (nesting, flexbox, :has).
• Часть споров сводится к «CSS vs JS»: Tailwind-фанаты и «CSS-only» энтузиасты доказывают, что можно обойтись почти без скриптов.
• Поднимаются боли: каскад, специфичность, нелогичные названия свойств, отсутствие системности.
• Появляются практические советы: уже работают sibling-index(), @mixin, Web Components, а WYSIWYG-редакторы могут вернуться.
• Вопросы доступности и обучения: где взять современный учебник/справочник и как сделать компоненты доступными без JS.

• YouTube
  О платформе • Пресс-центр • Авторское право • Связаться • Авторам • Реклама • Разработчикам
  Условия • Конфиденциальность • Правила и безопасность • Как работает YouTube • Тест новых функций • NFL Sunday Ticket
  © 2025 Google LLC

• Документальный фильм о Гвидо ван Россуме вызвал противоречивые отзывы: кто-то похвалил прагматизм создателя Python, кто-то остался разочарован.
• Некоторые зрители сравнили его с «Java Movie» и «React-документалкой» и нашли новый фильм слабее.
• Критика касается «слишком глянцевого» монтажа и ощущения «переобожествления» героя.

Я основал стартап в 22 года, открыл счёт в Chase в пригороде Лос-Анджелеса, вложив почти все сбережения — 20 000 $. Через полгода пришёл сид-раунд ~1 млн $, и тот же сотрудник Alex из отделения позвонил «просто проверить». Я отмахнулся.

Два года тишины, потом раунд А на 10 млн $ — снова звонок Alex, снова «всё ок». Ещё два года — раунд B на 24 млн $. Та же история. В итоге на счету 35 млн $, и новый финансовый директор предлагает перейти в SVB: «они понимают стартапы». Я перевёл всю сумму за 30 $ комиссии и забыл про Chase.

На следующий день Alex звонит взволнованно: «Почему ушли?» Я коротко: «Сменили банк». Больше не говорили.

Позже, в 2017-м, зашёл в лос-анджелесский Chase по личным делам. Менеджер узнал меня:
— Вы же основатель {название компании}?
— Да.
— Alex до сих пор рассказывает, как «его» клиент ушёл с 35 миллионами, потому что он не уделял внимания.

• Автор и комментаторы делятся курьёзами и провалами при работе с банками: от исчезновения $900 у Chase до необходимости ехать во Флоренцию, чтобы закрыть счёт в итальянском банке.
• Основной вывод: обычные retail-банки (Chase, BoA, Citi) плохо справляются с крупными суммами и стартапами — вызывают «Алекса» с проверками, режут транзакции и не дают персонального менеджера.
• Стартапам советуют сразу открывать счёт в специализированных бизнес-банках (Mercury) или переходить в private banking, где нет таких проблем.
• Несколько человек потеряли деньги без объяснений и так и не получили их обратно — главный аргумент «уйти от Chase».
• Сам автор признаёт, что просто копить миллионы на обычном счёту — не лучшая идея, но не раскрывает, что именно нужно делать вместо этого.