Hacker News Digest

• Сообщается о коронографических наблюдениях ближайшей солнечноподобной звезды α Cen A инструментом MIRI на JWST в августе 2024, феврале и апреле 2025. Достигнута чувствительность для обнаружения планет с T_eff≈225–250 K (1–1,2 R_Jup) на угловых расстояниях 1"–2" и пыли экзозодикального диска на уровнях >5–8 яркостей солнечной зодиакальной пыли. Отсутствие экзозоди даёт рекордный верхний предел — всего в несколько раз выше солнечной зодиакальной, что в ≥10 раз чувствительнее предыдущих измерений для иных систем.

• В августе 2024 обнаружен точечный источник S1 с F_ν(15,5 мкм)=3,5 мЯн на расстоянии 1,5" от α Cen A. Единственный успешный ролл-угол не позволяет однозначно подтвердить, что это планета. Анализ исключает фон/передний план. В феврале и апреле 2025 S1 не найден. Если S1 — то же, что объект C1 из VLT/NEAR (2019), то существует 52% вероятность, что кандидата S1+C1 не увидели в двух последующих наблюдениях JWST/MIRI из‑за орбитального смещения.

• С учётом ненахождений получены семейства динамически устойчивых орбит для S1+C1 с периодами 2–3 года. Они указывают на эксцентриситет e≈0,4 и значительное наклонение относительно плоскости орбиты α Cen AB (взаимный наклон i≈50° или ≈130°). По фотометрии и орбитальным свойствам кандидат может иметь T≈225 K, радиус ≈1–1,1 R_Jup и массу 90–150 M_⊕, что согласуется с пределами по РВ.

• Принято в ApJL; 34 стр., 22 рисунка, 10 таблиц. Тематики: экзопланеты и звёздная/солнечная астрофизика. DOI: 10.48550/arXiv.2508.03814. Версия v1 от 5 августа 2025.

• Обсуждается возможное обнаружение газового гиганта в обитаемой зоне Альфы Центавра A; интерес прежде всего в потенциальных обитаемых спутниках, если среди них окажется землеподобный и водный.
• Оценки: температура ~225 K (-48 °C), радиус ~1–1.1 радиуса Юпитера, масса ~90–150 масс Земли, что согласуется с ограничениями по радиальной скорости.
• Подсчёт гравитации даёт ~9.7 м/с² у «поверхности», но участники уточняют, что у газового гиганта нет твердой поверхности; также исправляют единицы измерения.
• Отмечают, что Проксима — ближайшая звезда вообще, но Альфа Центавра A — ближайшая солнечного типа (расстояние ~4.34 св. года).
• Скепсис насчёт «землеразмерных» спутников: такие луны в Солнечной системе отсутствуют, а для удержания воды нужна масса, близкая к земной.
• Обсуждают межзвёздные полёты: от ионных двигателей, солнечных парусов и «ускоряющих модулей» до фантастических идей по манипуляции гравитацией; ссылка на Project Hyperion.
• Предлагают неформальные названия (Полифем и Пандора) и отмечают, что 225 K — некомфортно, но потенциальные луны могли бы иметь более благоприятные условия.

• Сатира «Правила, по которым большая империя может быть уменьшена до малой» была напечатана в Public Advertiser 11 сентября 1773 года как пара к «Эдикту короля Пруссии». Франклин ценил их краткость, ёмкость и необычную форму, но «Правила» предпочитал за разнообразие и «энергичные концовки абзацев». В одной он предлагал взглянуть на политику метрополии глазами колонистов, в другой — вообразить себя колонистами. Цель — заставить публику по‑новому увидеть американский вопрос накануне парламентских дебатов и дела о Хатчинсоне и Оливере. Оба текста быстро разошлись и многократно переиздавались по обе стороны Атлантики.

• Эффект был двояким: сатира редко убеждает — открытых она развлекает, упорных злит. Франклин понимал риск: желая осветить колониальные жалобы, он мог все усугубить. По его мнению, правительство публично игнорировало нападки, чтобы не раздувать их, но именно они во многом объяснили ярость против него в начале 1774 года.

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

• Для Public Advertiser. «Правила, по которым БОЛЬШАЯ империя уменьшается до МАЛОЙ. [Частно представлены одному недавнему министру при вступлении в должность; публикуются впервые.]»

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

• Правило I: большая империя — как большой пирог — легче всего убывает с краёв. Начинайте с дальних провинций: избавляясь от них по периметру, потянутся и следующие.

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

• Обсуждение крутится вокруг «Правил» Франклина (1773) как сатирического отклика на политику Британской короны; отмечают, что он провёл в Британии 13–15 лет, тщетно пытаясь повлиять на парламент и короля, и вернулся в 1775.
• Несколько участников считают текст предвестником Декларации независимости и примером того, как сарказм поляризует, а не убеждает.
• Обсуждают «элитную слепоту» и повторяющиеся паттерны власти; некоторые видят уроки для современных империй и Pax Americana, другие предостерегают от редукционистских исторических аналогий.
• Уточняют контекст: в Британии были и сторонники умеренности; критика лорда Норта; корректируют хронологию событий до Лексингтона и Конкорда (1775).
• Замечают особенности типографики XVIII века: частая капитализация слов как стилистика/эмфаза, старинное начертание «s» как «ſ».
• В ветке уходит ответвление о «непрерывности» Китая: спорят о циклах объединения/распада, различиях династий и современного государства, приводят контрпримеры (например, Тайпинское восстание).
• Рекомендуют ресурсы: оригинальную верстку на archive.org, музей Франклина в Лондоне, подкаст «The Rest Is History» о Войне за независимость.

• время — 4732 использ.; последнее появл. 08/07/2025 08:49
• для — 4751; последнее 08/07/2025 08:49
• медитация — 509; последнее 08/07/2025 08:49
• неделя — 4017; последнее 08/07/2025 08:49
• война — 3974; последнее 08/07/2025 08:49
• трамп — 4711; последнее 08/07/2025 08:49
• ии — 4565; последнее 08/07/2025 08:49
• после — 4649; последнее 08/07/2025 08:49
• просто — 4748; последнее 08/07/2025 08:49
• последний — 4454; последнее 08/07/2025 08:49
• как — 4747; последнее 08/07/2025 08:49
• который — 4514; последнее 08/07/2025 08:49
• о — 4745; последнее 08/07/2025 08:49
• the — 4757; последнее 08/07/2025 08:49
• торговля — 2083; последнее 08/07/2025 08:49
• эффект — 1653; последнее 08/07/2025 08:49
• президент — 3584; последнее 08/07/2025 08:49
• тарифы — 2665; последнее 08/07/2025 08:49
• io — 2480; последнее 08/07/2025 08:49
• расширяется — 95; последнее 08/07/2025 08:49
• пошлины — 639; последнее 08/07/2025 08:49
• полночь — 1772; последнее 08/07/2025 08:49
• ошеломляющий — 439; последнее 08/07/2025 08:49
• страны — 4866; последнее 08/07/2025 08:49
• взяли — 8866; последнее 08/07/2025 08:49
• начать — 2796; последнее 08/07/2025 08:49
• объявил — 3688; последнее 08/07/2025 08:49
• мужчина — 4577; последнее 08/07/2025 08:49
• снег — 958; последнее 08/07/2025 08:49
• анан — 76; последнее 08/07/2025 08:49
• снеговик — 202; последнее 08/07/2025 08:49
• развлечения — 3310; последнее 08/07/2025 08:49
• ich — 3267; последнее 08/07/2025 08:49
• die — 4390; последнее 08/07/2025 08:49
• mein — 2276; последнее 08/07/2025 08:49
• мастурбация — 712; последнее 08/07/2025 08:49
• sind — 5177; последнее 08/07/2025 08:49
• сила — 3583; последнее 08/07/2025 08:49
• сам — 2763; последнее 08/07/2025 08:49
• друзья — 3607; последнее 08/07/2025 08:49
• гигант — 1239; последнее 08/07/2025 08:49
• вместе — 3278; последнее 08/07/2025 08:49
• месяцы — 2845; последнее 08/07/2025 08:49
• вещи — 4425; последнее 08/07/2025 08:49
• смотреть — 4485; последнее 08/07/2025 08:49
• демократия — 2165; последнее 08/07/2025 08:49
• однажды — 3766; последнее 08/07/2025 08:49
• те — 4467; последнее 08/07/2025 08:49
• что-либо — 4208; последнее 08/07/2025 08:49
• делаю — 4378; последнее 08/07/2025 08:49

• Обсуждают сайт, который сканирует посты Bluesky и отмечает слова из словаря, которых ещё не встречал; часть ложных срабатываний связана с языком (французские посты, имена собственные вроде “Wheal”, названия групп типа “eluvium”).
• Некоторые удивлены, что среди “невиденных” попадаются вполне обычные английские слова, а также что сайт у некоторых показывает 0 из‑за блокировки скриптов или задержки загрузки.
• Автор сайта пояснил: бэкенд простой — SQLite с таблицами для статистики и слов; не ожидал популярности.
• Технически обсуждают использование Jetstream вместо «firehose», способы токенизации и структуры данных: хеш‑таблицы/множества, trie, оценка памяти ~25 МБ на 250–275k слов.
• Замечают, что проверено лишь ~4.9 млн постов (≈0.28% из 1.7 млрд), поэтому покрытие ограничено; метаданные о языке в Bluesky могут быть некорректны, что ухудшает точность.
• Есть опасения о пропускной способности и стоимости «firehose», но Jetstream считается достаточно легковесным; у части пользователей всё работает в Firefox без аккаунта.
• Появляются шутки и критика: кто‑то просто постит словарь, смешные “двойные находки”, замечания о дизайне, а также сомнения к другим проектам автора (ошибочная классификация “right‑leaning”).

Проект Hyperion исследует возможность пилотируемых межзвездных полетов на поколенческих кораблях с использованием нынешних и ближайших технологий. Такой корабль рассчитан на многовековой путь: экипаж живет и сменяется поколениями, поддерживая замкнутую экосистему с сельским хозяйством, жильем и системами жизнеобеспечения.

Инициатива i4is объявила победителей международного конкурса дизайна поколенческого корабля для 250‑летнего перелета к обитаемой планете. Междисциплинарные команды проектировали среду, способную поддерживать и развивать общество при жестких ресурсных ограничениях.

Условия конкурса требовали совместной работы архитекторов, инженеров и социальных ученых над ключевыми аспектами закрытого общества на века, включая:

• Обитаемость для 1 000 ± 500 человек
• Искусственную гравитацию за счет вращения
• Достойные условия жизни и базовые потребности
• Надежные контуры жизнеобеспечения: пища, вода, отходы, атмосфера
• Механизмы передачи знаний и культуры

Подробнее о требованиях — по ссылке на документ.

Благодарности жюри

Работы оценивали эксперты из архитектуры, инженерии и социальных наук (Университет Хьюстона; NASA‑JPL; Университет штата Аризона; Университет штата Орегон; Университет Южной Калифорнии).

1 место

Команда: Giacomo Infelise, Veronica Magli, Guido Sbrogio', Nevenka Martinello, Federica Chiara Serpe

Отзыв жюри

Chrysalis выделился системной целостностью и инновационной модульной архитектурой, глубокой проработкой (включая производство в космосе и подготовку экипажа в Антарктике). Модульная оболочка гибка и масштабируема; большой Купол придает выразительность. Сильны планирование строительства корабля и защита от радиации; конструктив реалистичен. Культурный блок можно развить, но концепт убедителен и зрелищен, отсылает к «Раме» и мировым кораблям 1980‑х.

2 место

Команда: Julia Biernacik, Jakub Kot, Aleksandra Wróbel, Jacek Janas, Michał Kucharski, Wiktoria Kuchta, Natalia Łakoma, Katarzyna Śliwa Наставник: д-р хаб. Michał Kracik Факультет промышленного дизайна (студия «Дизайн для экстремальных сред»), Академия изящных искусств в Кракове

Отзыв жюри

WFP Extreme отмечен за общий уровень и акцент на культуре и обществе: одежда, духовные пространства, «такси‑капсула», персонализированная униформа, защита от радиации. Системная целостность и интерьер при искусственной гравитации требуют доработки, но конструктив уместен для орбитальных применений. Балансирует технические амбиции с тонким видением будущей космической жизни.

• Обсуждение крутится вокруг концепции поколенческих звездолётов и конкурса дизайнов: многие впечатлены идеями и визуалами, но сомневаются в реализуемости.
• Критика охватывает социальные аспекты (учёт женщин, психическое здоровье, подростки на борту, эвтаназия как TBD), управляемость общества и этику многовекового эксперимента.
• Технические возражения: неверные расчёты скорости/времени, колоссальные энергетические и финансовые затраты, ненадёжность замкнутых экосистем (пример Biosphere 2), проблемы с воспроизводством без защиты магнитного поля.
• Обсуждают минимально жизнеспособную популяцию и варианты расширения генетического пула (замороженные эмбрионы), а также альтернативы: замороженные экипажи/эмбрионы, нанобот-/фон-Нейман‑зонды, рельсовые ускорители и орбитальные суперструктуры.
• Скептики ссылаются на художественные и научно-популярные примеры (KSR “Aurora”, “Aniara”, Хайнлайн) как иллюстрации «неизвестных неизвестных» и социальной деградации на пути.
• Есть и прагматики: «реальность» как единственный тест — не один «ковчег», а множество разных подходов; сначала нужно решить земные проблемы и освоить замкнутые биосистемы.
• Итоговый тон смешанный: от воодушевления образовательной ценностью и дизайном до убеждённости, что при нынешних технологиях поколенческие корабли — красивая, но несостоятельная фантазия.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.

• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.

• Вкус демо: простой файл

  from litestar import Litestar, get
  
  @get("/greet")
  async def greet(name: str) -> str:
      return f"Hi, {name}!"
  
  app = Litestar([greet])
  

  Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.

• Масштабирование кода, а не трафика:

  • Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
  • Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
  • В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.

• В 70‑х некоторые системы (например, PDP‑10) имели 9‑битовые байты, но стандарт закрепился за 8 битами. Если бы байт был 9‑битным, ряд исторических случайностей сыграли бы нам на руку.

• IPv4: при 9‑битовых байтах адрес IPv4 был бы 36‑битным (~64 млрд адресов). Этого хватило бы до 2030‑х без массового NAT и тормозов с IPv6; позже проблему решили бы мягкими рыночными механизмами.

• UNIX time: 32‑битные метки ломаются в 2038, а 36‑битные прожили бы до 3058. Отрицательные охватывали бы времена с 882 года — достаточно для исторических нужд.

• Юникод: вместо 16‑битных 65 тыс. символов было бы 18‑битных 262 тыс. — хватило бы без болезненной унификации CJK; сейчас всех символов ~155 тыс. UTF‑9 стал бы скорее компрессией и уступил бы GZip; либо однобайтно‑двухбайтная схема при умеренной экономии на эмодзи.

• Указатели и память: 36‑битные ОС дали бы до 32 ГБ на процесс (вместо 2 ГБ у 32‑битных). Серверы всё равно виртуализируют; меньшие указатели экономят память и ускоряют код, хотя строки стали бы длиннее — общий баланс близок к нулю.

• Прочие выигрыши:

  • 18‑битные AS‑номера не иссякли бы; порты/PID/UID просторнее.
  • Кодирование инструкций x86/A64 чуть опрятнее; Thumb работал бы лучше.
  • Полуточные 18‑битные числа прижились бы раньше; экзотика 4–5 бит не взлетела бы.
  • Расширенный ASCII влез бы с греческим и стал бы «натовской» кодовой страницей; UTF‑9 привилегировал бы почти всю Западную Европу.
  • Права Unix умещались бы в один байт (без «липких» битов). Оctal стал бы нормой вместо hex.
  • 18‑битный цвет 6/6/6 даёт различия на грани восприятия; потеря альфа‑канала неприятна.

• Издержки? Существенных нет: адресация по битам не используется; деления на девять не требуется; размеры страниц/блоков ОС могли бы остаться прежними, ядру не пришлось бы менять основы работы.

• Обсуждение крутится вокруг гипотетического мира с 9-битными байтами: часть участников отмечает аппаратную неудобность непоказательных (не 2^n) размеров и сложность для мультипликаторов, адресации и сдвигов.
• Скептики считают аргументы «добавим по одному биту и всё станет лучше» натянутыми: решения о размерах всё равно принимались бы иначе, а выигрыш в 12.5% не компенсирует издержки и усложнение.
• Приводятся исторические примеры: PDP-8/10 с 12/36-битными словами, 6-битные коды, термин «octet» для однозначности; упоминается даже N64 с «внутренними» 9-битными байтами для GPU.
• По сетям: 36-битный IPv4 дал бы ~64 млрд адресов, но это лишь отсрочка дефицита; проблемы ASLR и безопасности 32-битной адресации 36 битами решаются слабо, переход на 64 бита всё равно был бы.
• Есть идеи альтернатив: 10-битные байты, тернарные системы, 9-й бит как признак продолжения для варинтов/инструкций, либо как служебный (ECC/контроль/метка данных).
• Отмечают экономику кремния: лишние провода/логика удорожают дизайн; если уже расширять шину, логичнее идти к степеням двойки (например, к 16 битам на «байт»).
• Итоговый тон дискуссии: 9 бит могли бы немного смягчить отдельные «почти-не-хватает» пороги (16/32-бит), но в целом это привнесло бы больше сложностей, чем пользы; ключ — лучше прогнозировать размеры, а не «маскировать» ошибки лишним битом.

MS used to have uservoice pages. They ignored issues, no matter how highly-voted they were. I once asked someone at MS about this, and they said they take their cues from other sources, like what industry partners ask them to fix at conferences.What a waste of time to have uservo

In my 20s I did a year long internship in Japan and lived in a dorm owned by the company I worked for.Single room with bed and desk, bathroom down the hall, shared cafeteria on the first floor with breakfast and dinner served every day (lunch expected to be eaten at the office).N

Моя предыдущая статья о обобщённых структурах данных в C готовила почву к теме: структура, которая заменяет динамические массивы, даёт стабильные указатели и хорошо работает с аренными аллокаторами. Её переоткрывали много раз под разными именами: “levelwise-allocated pile” (2001), в Zig — Segmented List, частично похожая на C++ std::deque. Мне нравится название Per Vognsen — Segment Array.

Скачать мой однофайловый заголовок segment_array.h можно, подписавшись на рассылку.

Идея проста: фиксированный массив указателей на сегменты; каждый следующий сегмент вдвое больше предыдущего; новые сегменты выделяются по мере необходимости. Поскольку элементы не двигаются, указатели на них стабильны, не остаются “дыры” в арене, а доступ по индексу — за O(1).

Реализация

Структура на C:

typedef struct { u32 count; int used_segments; u8 *segments[26]; } SegmentArrayInternal;

Почему всего 26 сегментов? Из 64 бит указателя обычно реально используются 48, так что 49 сегментов уже перекрывают адресное пространство (~256 ТиБ). Я предпочитаю индекс u32 (до ~4 млрд элементов) — это даёт 32 сегмента. Ещё убираем 6 маленьких (1..32), начинаем с 64, остаётся 26 сегментов — хватает для 4 294 967 232 элементов (чуть меньше UINT32_MAX). Фиксированный массив рядом со структурой снижает риск промаха кэша.

Размеры сегментов — степени двойки: проще математика и быстрые сдвиги для индексов.

#define SMALL_SEGMENTS_TO_SKIP 6

#define log2i(X) ((u32) (8*sizeof(unsigned long long)
- __builtin_clzll((X)) - 1))

u32 capacity_for_segment_count(int segment_count) { return ((1 << SMALL_SEGMENTS_TO_SKIP) << segment_count) - (1 << SMALL_SEGMENTS_TO_SKIP); }

void *_sa_get(SegmentArrayInternal sa, u32 index, size_t item_size) { int segment = log2i((index >> SMALL_SEGMENTS_TO_SKIP) + 1); u32 slot = index - capacity_for_segment_count(segment); return sa->segments[segment] + item_sizeslot; }

log2i использует __builtin_clzll (подсчёт ведущих нулей) для быстрого вычисления номера сегмента.

Clang оптимизирует _sa_get до ~10 инструкций x86-64 (-O3), так что узким местом будет память, а не вычисления индекса. При последовательной итерации можно обходить сегменты напрямую; в segment_array.h есть макрос.

Выделение нового элемента:

u32 slots_in_segment(int segment_index) { return (1 << SMALL_SEGMENTS_TO_SKIP) << segment_index; }

void *_sa_alloc(SegmentArrayInternal *sa, size_t item_size) { if (sa->count >= capacity_for_segment_count(sa->used_segments)) { size_t segment_size = item_size * slots_in_segment(sa->used_segments); sa->segments[sa->used_segments++] = malloc(segment_size); } sa->count++; return _sa_get(sa, sa->count-1, item_size); }

Замечание: можно сделать ёмкость строго степенью двойки, если первые два сегмента одинакового размера. Код станет менее изящным, но это спасает от ~50% потерь памяти при использовании как массива бакетов в хеш-таблице со степенью двойки.

Дженерики

Я применяю технику из прошлой статьи для типобезопасного хранения любого типа. Макрос связывает тип с общей структурой:

#define SegmentArray(type)
union {
SegmentArrayInternal internal;
type *payload;
}

Дальше макросы используют payload, чтобы передавать сведения о типе…

• Обсуждается структура «сегментированный массив» (экспоненциальные сегменты), её плюсы и минусы, и сравнение с существующими решениями: std::deque, ropes, Zig std.SegmentedList, rust-array-stump, plf::colony.
• Критика терминологии: это не «массив» в классическом смысле из‑за неконтигуозной памяти; многие API ожидают сплошной/страйдовый буфер и не подойдут.
• Производительность: при локальных L1-итерациях вычислительная часть индексации может быть ощутима; для больших объёмов память становится бутылочным горлышком. Предлагаются оптимизации итерации по сегментам и замечания про clz/bsr/lzcnt и опции компилятора.
• Виртуальная память как альтернатива: резервирование большого диапазона и по мере роста коммит страниц/guard pages; отмечены плюсы на Linux (MAP_POPULATE, mremap), но плохо для embedded/WASM.
• Сравнение с deque: фиксированные блоки vs экспоненциальные, поддержка prepend, рандом-доступ есть; реализация MSVC критикуется за малый размер блока, GNU/libc++ лучше.
• Недостатки сегментов: ухудшение предвыборки/кэш-локальности при линейной итерации, отсутствие стабильной непрерывности для API, сложность с хеш-таблицами при росте (rehash), потенциальный перерасход памяти при экспоненциальных размерах.
• Предложения: настраиваемый минимальный размер сегмента, функции «склейки» мелких сегментов, разбор условий, когда экспоненциальные сегменты оправданы, и замечания о чрезмерной макротрюковости в C/C23.

• Исправления

  • Уточнено сообщение об ошибке с некорректной терминологией. (Louis Pilfold)
  • JS: устранён сбой при использовании echo в модуле с функцией process. (Peter Saxton)
  • Форматер: не переносит комментарий перед assert за него; корректно форматирует сообщения после echo/panic/todo/assert/let assert с комментарием перед ними; компилятор не генерирует неверный код для assert с пайпами на JS. (Giacomo Cavalieri)

• Форматирование битовых массивов

  • Трейлинг-Запятая управляет разбиением: с запятой — много строк; без — в одну строку.
  • Если несколько сегментов на строке и убрана завершающая запятая, форматер сохраняет сегменты по одному на строку. (Giacomo Cavalieri)

• Компилятор и генерация кода

  • echo поддерживает пользовательское сообщение: echo 11 as "lucky number" печатает контекст и значение в stderr. (Giacomo Cavalieri)
  • В сгенерированном JS doc-комментарии превращаются в JSDoc. (Giacomo Cavalieri)
  • Уменьшен размер кода case на JS. (Surya Rose)
  • Удаление неиспользуемого кода на этапе генерации (usage-based DCE). (Louis Pilfold)
  • Улучшена поддержка echo для списков символов, ошибок и циклических ссылок JS. (Louis Pilfold)
  • Улучшен внешний вид ошибок и предупреждений: контекстные метки выделяются иначе, чем источник проблемы. (Giacomo Cavalieri)
  • Подсказка при импорте с точкой вместо слеша, с примерами корректного синтаксиса. (Zij-IT)
  • Предупреждение при затенении импортированного имени верхнеуровневой константой/функцией. (Aayush Tripathi)
  • Улучшено сообщение об неизвестной переменной, если, вероятно, имелась в виду проигнорированная (_x → x), с подсказкой. (Giacomo Cavalieri)
  • Оптимизирован матчинг-паттернов на JS.

• Обсуждение посвящено релизу Gleam: многие хвалят дизайн языка, читаемость, статическую типизацию и паттерн-матчинг; приводят пример кода и делятся позитивным опытом использования в проектах.
• Есть ссылки на пост о версии 1.12.0 и доклад на YouTube; некоторые ждут дальнейшего созревания экосистемы и возможности шаринга кода между фронтендом и бэкендом.
• Критика: отсутствие интерфейсов/тайпклассов и оператора композиции; кому-то синтаксис и «Error -> Error» кажутся неэлегантными; snake_case непривычен после TypeScript.
• В ответ отмечают осознанную простоту языка и официальную позицию Gleam по отказу от тайпклассов.
• Существенная часть треда уходит в спор о «идеологичном» футере сайта (инклюзивность, антинацистская позиция, права транс-людей): часть считает это лишним, другие — важным для безопасности и качества сообщества.
• Подчеркивается, что Gleam — это не только язык, но и сообщество с явным кодексом поведения; отсутствие позиции тоже является позицией.
• Некоторые участники призывают вернуться к техническим темам релиза, чтобы не повторять одни и те же дискуссии.