Hacker News Digest

Автор исследует сложность обработки исключений JVM при декомпиляции Java-байткода. Изначально предполагалось, что метод декомпиляции управляющих потоков, разработанный автором, можно легко расширить для обработки исключений, но оказалось, что множество крайних случаев значительно усложняют задачу. JVM использует стековую архитектуру, где обычные управляющие конструкции реализуются явно, а исключения обрабатываются неявно через отдельную таблицу исключений. Эта таблица связывает регионы инструкций с обработчиками, но JVM не требует соблюдения иерархической вложенности обработчиков, что приводит к пересекающимся диапазонам и нарушает интуитивные ожидания.

Реальные Java-файлы часто содержат такие "неестественные" конструкции, что делает проблему важной для любого декомпилятора. Автор также отмечает сложность обработки try...finally блоков, где код finally должен выполняться независимо от возникновения исключения, но передача управления после его завершения зависит от контекста. Эти особенности байткода и компилятора javac создают значительные препятствия для создания корректного декомпилятора, особенно при попытке восстановления исходной структуры кода.

• Обсуждение началось с примера кода, который выглядит как баг, но на самом деле является корректным поведением в Java и других языках, где finally блок не может перехватить return/throw, но может перехватить continue/break.
• Участники обсудили, что в действительности это не баг, а фича, и что в большинстве языков finally не может перехватить return/throw, но может перехватить continue/break.
• Обсуждались также вопросы, что в некоторых языках, таких как C#, такие конструкции вообще не допускаются.
• Также было отмечено, что в Java 25 такой код будет компилироваться и работать, но в более ранних версиях Java это вызовет ошибку компиляции.

Flowistry - это плагин для IDE, разработанный специально для языка программирования Rust. Его основная функция - помочь разработчикам сосредоточиться на релевантном коде, упрощая навигацию и понимание сложных проектов. Плагин использует статический анализ для определения связей между различными частями кода, что позволяет быстро понять, как разные компоненты взаимодействуют друг с другом.

Проект создан разработчиком Will Crichton и доступен на GitHub. Flowistry стремится решить распространенную проблему в больших кодовых базах - необходимость просматривать множество несвязанного кода для понимания контекста. Плагин предоставляет инструменты для визуализации зависимостей и определения путей данных в программе, что значительно ускоряет процесс отладки и рефакторинга кода на Rust.

• Инструмент Flowistry показывает, как данные течут в коде, но требует MIR и работает только с Rust.
• Обсуждение развилось вокруг того, почему это нельзя сделать для других языков и почему это не входит в rust-analyzer.
• Некоторые участники выразили желание увидеть подобные визуализации для TypeScript, C#, Python и других языков.
• Обсуждались вопросы товарного знака VSCode и ограничений, которые накладывает набор инструментов на то, что можно включить в IDE.
• Участники также обсудили, какие еще инструменты могли бы помочь в понимании кода и какие еще есть инструменты для других языков.

В C# операции с массивами автоматически проверяют границы для безопасности, что может снижать производительность. Компилятор способен убрать проверки в идеальных условиях, например, в цикле с известными границами, но при передаче индексов извне проверки остаются, что видно по ассемблерному коду.

Можно использовать небезопасный код с указателями для полного избежания проверок, но это рискованно: ошибки ведут к сбоям или уязвимостям. Решение — тип Span<T>, который объединяет ссылку на данные и их длину, обеспечивая безопасный нулевой копирование доступ без дополнительных проверок. Это позволяет писать высокопроизводительный код без ущерба для безопасности, сочетая низкоуровневую эффективность с управляемыми гарантиями.

• Использование Span<T> и ReadOnlySpan<T> позволяет избежать лишних выделений памяти и повысить производительность, особенно при работе со строками и массивами.
• Эти структуры предоставляют безопасные, безграничные представления памяти, заменяя необходимость в небезопасном коде и указателях.
• Оптимизации с помощью Span<T наиболее эффективны в сценариях с интенсивной обработкой данных (например, парсинг, игры), а не в типичных CMS, где узкие места обычно в БД или кэше.
• Внедрение Span<T в .NET стандартизировало ранее фрагментированные подходы к работе с памятью, улучшив interoperability между библиотеками.
• Хотя Span<T предлагает контроль, сравнимый с Rust, он ограничен моделью сборки мусора C#, тогда как Rust предоставляет более строгие гарантии времени жизни на уровне компилятора.

В C# 14 появились операторы условного присваивания для null, которые позволяют безопасно присваивать значения свойствам или индексаторам без бесконечных проверок if.

Если вы работали с C#, вам знаком код вроде:

if (config?.Settings is not null) 
{
    config.Settings.RetryPolicy = new ExponentialBackoffRetryPolicy();
}

Теперь это можно записать одной строкой:

config?.Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy();

Новые операторы работают как с обычными присваиваниями, так и с составными (+=, -=), а также могут комбинироваться с оператором объединения с null (??=):

customer?.Name ??= "Guest";

Важно помнить: если левая часть выражения равна null, правая часть не выполняется, что предотвращает побочные эффекты.

• Введение оператора ?. для присваивания (a?["b"] = c) как логическое завершение существующей функциональности null-conditional операторов, повышающее консистентность языка.
• Критика нового синтаксиса как избыточного, усложняющего язык и маскирующего проблемы дизайна данных, приводящие к глубоким цепочкам проверок на null.
• Опасения по поводу снижения читаемости и удобства отладки из-за скрытого поведения (пропуск присваивания при null) и потенциального чрезмерного использования.
• Поддержка функции как способа сократить шаблонный код и сделать его менее многословным, аналогично реализациям в Swift, Kotlin и Ruby.
• Споры о том, следует ли языку C# продолжать агрессивно добавлять новые функции, рискуя стать перегруженным и менее доступным, как C++.
• Замечание, что данное изменение не добавляет новой семантики, а лишь расширяет существующий синтаксис, завершая его реализацию.
• Упоминание, что более востребованные функции (например, discriminated unions) разрабатываются отдельно и их появление не связано с этим изменением.

Blocky Planet — демо на Unity, превращающее кубические воксели Minecraft в полностью разрушаемую сферическую планету из 20+ блоков.

Частые вопросы

• Где играть? Бесплатно на itch.io (Windows + web).
• Зачем? Вдохновился старым демо Jordan Peck и хотел добавить текстуры и масштабное разрушение.
• Будет ли игра? Вряд ли: мало времени, а путь от демо до релиза огромен.
• Сколько времени? ~1 месяц по 15 ч/нед. Пост занял вдвое дольше.
• Стек: Unity 6, C#, Job System + Burst, но без DOTS.
• Код? Пока закрыт — стыдно.
• Текстуры? Нарисованы вручную или скриптами; многие блоки ≈ шум + тонировка.
• Идеи/вопросы? Пишите в реддит-пост.

Делаем сферу

Простой способ — отфильтровать блоки внутри заданного радиуса, но тогда гравитация не совпадает с «верхом» блоков. Нужно:

1. Наложить 2D-квадратную сетку на 3D-сферу.
2. Сохранять ширину блоков при удалении от центра.

Карта без искажений — миф

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

• Автор продемонстрировал работающий «кубический» voxel-мир на сфере, где основной проблемой остаётся вертикальное искажение.
• Комментаторы сравнили проект с Space Engineers, Seed of Andromeda, PlanetSmith, Minetest и другими попытками создать «Minecraft на планете».
• Предложены альтернативы: геодезические сферы, торо-сфера (Eco), шестигранные воксели, HEALPix, S2, а также уменьшение игрока при приближении к ядру.
• Пользователи отметили удовольствие от орбитальной механики и мечтают о гибриде Minecraft + Kerbal Space Program.

Zig выглядит почти как Rust, но делает синтаксис ещё приятнее за счёт более простой семантики и ряда изящных решений.

Числа
Литералы 92 всегда имеют тип comptime_int; при присваивании они неявно приводятся к нужному типу. Суффиксов нет.

Строки
Многострочные «сырые» строки пишутся через \\ в начале каждой строки; \ не экранируется, отступы не портятся, а лексер работает построчно.

Структуры
.{ .x = 1, .y = 2 } — запись поля через .x = совпадает с присваиванием, что позволяет грепом находить именно записи, а не чтения.

Типы
Все типы префиксные: u32, [3]u32, ?[3]u32, *const ?[3]u32. Разыменование постфиксное: ptr.*.

Идентификаторы
Синтаксис @"имя с пробелом" позволяет обходить ключевые слова и экспортировать любые имена.

Функции
fn add(x: i32, y: i32) i32 — без стрелки ->, так как лямбд нет, а возвращаемый тип всегда обязателен. pub fn main() void {}.

Переменные
const и var; часто используемое const короче, чем в Rust, но всё же длиннее Kotlin-овского val.

• Обсуждение разделилось: кому-то синтаксис Zig кажется «прекрасным» минимализмом, другим — «шумным» и «капризным».
• Спор о порядке «имя: тип» vs «тип имя»: одни хотят видеть тип первым, другие — имя.
• Критика деталей: @-префиксы, .{}, отсутствие лямбд, перенос строк, orelse без пробела.
• Плюсы: raw-строки Zig решают проблему отступов; обработка ошибок через try нравится многим.
• Сравнения: Kotlin, C#, Go, Rust, D — каждый считает «своё» лучше.
• Итог: «красота» синтаксиса субъективна и во многом привычна; после практики Zig начинает нравиться.