Hacker News Digest

Архив Эдсгера Дейкстры содержит более тысячи его неопубликованных рукописей, известных как "EWDs", которые он рассылал десяткам получателей на протяжении более 40 лет. Дейкстра, один из основоположников компьютерных наук (1930-2002), внёс фундаментальный вклад в алгоритмы, языки программирования, операционные системы и формальную верификацию, за что получил высшую награду ACM - премию Тьюринга. Большинство его работ остались недоступными для широкой публики, пока не были оцифрованы и представлены на этом сайте в виде PDF-документов.

Исходные материалы, включая дневники и переписку, хранятся в Техасском университете. Архив включает несколько индексов для поиска, а также растущее количество транскрибированных текстов и переводов на разные языки. Дейкстра часто возвращался к уже обсуждавшимся темам, предлагая новые взгляды или более точные формулировки, что отражено в системе перекрёстных ссылок между документами.

• Дискуссия охватывает темы от индексации массивов до философии обучения программированию, включая ссылки на конкретные эссе и письма Дейкстры.
• Участники обмениваются ссылками на тексты Дейкстры, обсуждают его взгляды на обучение программированию, индексацию и стиль написания кода.
• Обсуждение затрагивает влияние Дейкстры на современную практику разработки ПО, включая дискуссии о том, как его идеи могут быть применимы или неприменимы в современном контексте.
• Участники также обсуждают влияние Дейкстры на современные языки программирования и стиль написания кода, включая дискуссии о том, как его идеи могут быть применимы в современной разработке ПО.
• Некоторые участники также обсуждают, как идеи Дейкстры могут быть использованы в обучении новых программистов и как его идеи могут быть применимы в современной разработке ПО.

Tabloid — это язык программирования, созданный для генерации кликбейтных заголовков. Его название отсылает к бульварным газетам (tabloid), известным сенсационными и провокационными заголовками. Язык, судя по всему, использует специфический синтаксис, имитирующий стиль броских заголовков, привлекающих внимание. Для доступа к реализации Tabloid требуется включить JavaScript, что указывает на веб-ориентированный характер проекта.

Разработка такого языка представляет собой интересный эксперимент на стыке программирования и медиа-риторики. Хотя подробности реализации остаются неясными без включенного JavaScript, концепция сама по себе уникальна — она объединяет техническую составляющую с приемами массовой коммуникации. Возможно, Tabloid создан как сатирический комментарий или как инструмент для изучения психологии вовлекающего контента.

• Язык Tabloid пародирует стиль таблоидных заголовков, предлагая такие ключевые слова, как "BREAKING NEWS" и "COMPLETELY WRONG".
• Пользователи предлагают улучшения: добавить оператор "CONSIDERED HARMFUL", сделать так, чтобы программы ничего не делали, или использовать "TRUTH"/"FAKE NEWS" как булевы значения.
• Обсуждение включает сравнения с другими сатирическими языками, такими как LOLCODE и TrumpScript, и шутки о бесполезности языка как отражении кликбейта.
• Сообщество оценило юмор и оригинальность идеи, отметив, что язык может быть полезен для обучения парсингу или просто как забавный эксперимент.
• Технические аспекты включают предложения по определению массивов через "Top Five Most Popular Quirks" и обсуждение грамматики для парсеров.

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

Мне не хватает содержимого статьи, которую нужно пересказать. Вы предоставили только фразу "What the hell have you built", но не сам текст Hacker News.

Чтобы я мог создать точный и ёмкий пересказ на русском языке в формате Markdown (~170 слов в двух абзацах), пожалуйста, предоставьте содержимое статьи, которую вы хотите, чтобы я обработал.

• Обсуждение вращается вокруг переусложнения, вызванной стремлением использовать "крутые" технологии вместо простых решений, что приводит к излишней сложности и отвлекает от решения реальных проблем стартапа.
• Участники обсуждения подчеркивают, что вместо того, чтобы использовать проверенные временем инструменты, разработчики часто выбирают сложные стеки технологий, что может быть вызвано как желанием продемонстрировать свои навыки, так и нежеланием заниматься "скучными" задачами.
• Также поднимается вопрос о том, что выбор технологий часто определяется не техническими потребностями, а социальными факторами, включая желание произвести впечатление на техническое сообщество или даже просто прокрастинация.
• Участники также обсуждают, что вместо того, чтобы фокусироваться на создании MVP, который может быть реализован с использованием простых и надежных инструментов, разработчики могут тратить время на изучение и внедрение ненужной сложности, что может привести к потере фокуса на продукте и его проблемах.

Radiant Computer представляет собой проект по созданию персонального компьютера с нуля, свободного от исторического багажа и влияния Big Tech. Авторы считают, что современная вычислительная индустрия движется к менее свободному миру, где системы проектируются вокруг моделей вовлеченности и слежки, а не потребностей пользователей. Их система предлагает альтернативу: без браузера, с собственной сетью, напоминающей ранний интернет, без соцсетей, скриптов и трекеров.

Ключевая философия проекта заключается в том, что код - это родная среда вычислений, и Radiant делает его доступным для всех. Каждое приложение существует как код, который можно читать, редактировать и расширять, давая пользователям полный контроль. Проект также исследует, как генеративный ИИ может сделать программирование доступным для более широкой аудитории, одновременно сохраняя приватность данных и создавая пространство для фокуса и творчества.

• Проект Radiant Computer представляет собой попытку создать новую вычислительную платформу с нуля, включая ОС, язык программирования и даже аппаратное обеспечение, но пока не представлено никаких конкретных результатов.
• Критики указывают на то, что проект выглядит как вейпор, не предлагает никаких конкретных технических деталей и не демонстрирует прогресса.
• Некоторые комментаторы выражают сомнение в способности команды реализовать заявленные амбиции, учитывая, что они не предоставляют никакой конкретной информации о текущем состоянии дел.
• Некоторые комментаторы также отмечают, что проект не предлагает никаких конкретных технических деталей, что делает его похожим на вейпор.
• Некоторые комментаторы также отмечают, что проект не предлагает никаких конкретных технических деталей, что делает его похожим на вейпор.

Недавно обнаруженное письмо Роберта Гука к Готфриду Лейбницу 1681 года демонстрирует удивительные параллели между научным мышлением XVII века и киберпанк-культурой XX века. Гук поддерживал идею Лейбница о создании универсального языка науки ("Characteristica Universalis"), который можно рассматривать как прототип языков программирования. "Если бы мы могли найти знаки, подходящие для выражения всех наших мыслей так точно, как арифметика выражает числа, мы могли бы во всех предметах, поддающихся рассуждению, достичь того, что достигается в арифметике и геометрии", — писал Лейбниц.

Особенно примечателен оптимизм Гука, который видел в этом языке не только инструмент научного прогресса, но и способ обеспечения свободы мысли. "Регулярное использование [такого языка] я считаю величайшим противовесом, который может помешать его прогрессу", — отмечал он, подразумевая сопротивление авторитетов. Норберт Винер видел в проекте Лейбница предтечу кибернетики, а автор статьи находит в письме Гука раннее проявление хакерского менталитета, сочетающего техническое мастерство с духом DIY-контркультуры.

• Обсуждение началось с цитаты Хука о языке, который, как оказалось, был частью более широкого обсуждения влияния Хука и Лейбница на науку и их взаимодействия с Ньютоном.
• Участники обсуждали точность транскрипта, особенно в отношении слов "exercise" и "course", и правильное размещение запятых.
• Были упомянуты такие темы, как влияние Хука на современную научную мысль, его вклад в микроскопию и его взаимодействие с Лейбницем и их общий интерес в создании универсального языка науки.
• Также обсуждались влияние Хука на Лейбницу и наоборот, их взаимное влияние на Ньютона и их общий интерес в создании универсального языка науки.
• Участники также упомянули влияние Хука на современную культуру, включая его влияние на литературу киберпанка и научную фантастику.

Книга Ксавье Леруа исследует эволюцию управляющих конструкций в языках программирования, от ранних операторов goto до современных алгебраических эффектов. Работа представляет собой историческое путешествие по дизайну языков, уделяя особое внимание механизмам контроля выполнения программ. Книга охватывает структурированное программирование 1960-х, генераторы и корутины в императивных языках, а также продолжения и операторы контроля в функциональных языках.

Книга разделена на четыре части: управляющие конструкции для императивных языков, операторы контроля для функциональных языков, от исключений к алгебраическим эффектам и обработчикам, а также рассуждения о контроле и эффектах. Особую ценность представляют многочисленные примеры кода на разных языках — от Fortran и Algol 60 до OCaml и Haskell. Работа сочетает историю, практические примеры и теорию, предлагая оригинальный сравнительный взгляд на языки программирования и обширное введение в алгебраические эффекты — современную область исследований в PL.

• Критика исключений как "glorified come from", сравнение с POSIX сигналами и setjmp/longjmp.
• Дискуссия о checked исключениях в Java vs подход "ошибки как данные" для ожидаемых сбоев.
• Вопрос производительности алгебраических эффектов и ответ: реализация возможна через монады, оптимизирована в OCaml 5.
• Упоминание Xavier Leroy как автора CompCert, LinuxThreads и ключевой фигуры OCaml/Rocq.
• Шутка про INTERCAL и "come from" как пример необычного синтаксиса.

Исследователь из Карлова университета предлагает отождествить Unix-исполняемые файлы с методами Smalltalk, открывая путь к объединению этих систем. Хотя Unix и Smalltalk существенно различаются в деталях, они демонстрируют поразительные сходства в своей общей структуре. Автор утверждает, что если файлы Unix соответствуют объектам Smalltalk, то исполняемые файлы должны соответствовать методам, а процессы — активациям этих методов. Это позволяет легко реализовать Smalltalk VM через файловую систему Unix.

Однако серьезные накладные расходы, связанные с Unix-процессами, ставят под сомнение практическую реализацию этого подхода. Тем не менее, автор видит несколько путей решения этой проблемы, которые позволят реализовать преимущества Smalltalk в Unix без изоляции в герметичной среде. Такое объединение сохранит плюральность языков Unix, в отличие от необходимости писать все методы на Smalltalk, и позволит преодолеть фрустрацию от существующих, но недостаточно развитых возможностей Unix в области персистентности, динамического обновления ПО, единообразия и открытости GUI.

• Пользователи обсуждают, что Xerox PARC мог бы стать основой для UNIX, но вместо этого остался в истории как упущенная возможность.
• Конференция ICFP/SPLASH 2024 стала поводом вспомнить о том, как давно не было никаких прорывов в области ОС и языков программирования.
• Участники обсуждают, что современные исследования в области ОС и языков программирования не предлагают ничего нового, а лишь переосмысливают старые идеи.
• Участники также отмечают, что даже такие концепции как компонентное программирование и модулярность, которые когда-то были новаторскими, сегодня являются лишь переосмыслением старых идей.
• В обсуждении также поднимается вопрос о том, что сообщество открытого кода могло бы внедрить эти идеи, но вместо этого сосредотачивается на полемике вокруг лицензий и "open source"-а.

Новый язык программирования стоит создавать, если он позволяет выразить идеи или концепции, которые невозможно или неудобно описывать в существующих языках. Это не просто вопрос синтаксиса или семантики, но и всей экосистемы, включающей библиотеки, инструменты и сообщества. Например, Python ценят за богатство библиотек, делающих его универсальным, а Go — за простую модель параллелизма. Таким образом, язык программирования определяется синтаксисом, семантикой и экосистемой, которые вместе открывают новые направления для исследования и творчества. Создавайте смелые, даже непрактичные языки, чтобы исследовать неизведанное, а не просто решать известные задачи.

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

Ричард Столлман выступает против превращения GCC бэкенда в библиотеку, аргументируя это защитой свободного программного обеспечения. Он предупреждает, что компании неизменно стремятся сделать ПО несвободным, и некоторые создали бы несвободные дополнения к GCC, если бы им это позволили. Именно требование GPL заставило авторы фронтендов для C++ и Objective-C сделать их свободными, так как они не могли использовать их иначе. Столлман подчеркивает: "Все, что упрощает использование GCC бэкендов без фронтендов, ставит под угрозу наше влияние на то, чтобы новые фронтенды оставались свободными".

Проект GNU с высокой вероятностью не примет такие изменения, если они появятся, и это "твердый вывод, основанный на десятилетии размышлений". Столлман приглашает всех заинтересованных лиц связаться с ним лично для обсуждения их идей, потенциальной пользы и альтернативных подходов, призывая задуматься о важности будущих свободных фронтендов и интересов проекта в целом.

• Пропущенное предложение интегрировать LLVM в GCC стало ключевым событием в истории компиляторов, но оно было упущено из-за сбоя в почтовой переписке.
• Это стало причиной того, что LLVM вместо того, чтобы стать частью GCC, стал основой для большинства новых языков и проектов.
• Парадокс в том, что GCC и LLVM сегодня по сути предлагают одинаковую производительность, но LLVM лицензирован более свободно, что способствует его популярности.
• В то же время, GCC остаётся под GPL, что отталкивает некоторых разработчиков, которые не хотят, чтобы их код был связан с GPL.
• В конечном счёте, это привело к тому, что LLVM стал основой для большинства новых языков программирования, в то время как GCC медленно движется к облесению.

Rust-разработчик взглянул на Vec<T> и обнаружил, что вместо ожидаемых трёх полей ptr, len, capacity внутри структура скрыта целая иерархия обёрток: RawVec, RawVecInner, Unique, NonNull и NonNull<T> — всё ради безопасности и гибкости. Это вызвало вопрос: зачем такая сложность, если можно было обойтись тремя полями? Ответ оказался в том, что каждый слой добавляет безопасность и абстракцию, защищая от ошибок с указателями.

• Обсуждение развивалось вокруг того, что стандартная библиотека Rust предоставляет безопасные абстракции над низкоуровневыми деталями, но при этом не скрывает их полностью, и что это влияет на то, как код на Rust выглядит и ощущается.
• Участники обсуждали, что сложность реализации Vec в стандартной библиотеке Rust отражает компромисс между безопасностью и производительностью, и что это влияет на то, как разработчики думают о системе типов и управлении памятью в Rust.
• Также обсуждались вопросы о том, как документация и обсуждение в сообществе Rust может быть улучшена, включая сравнение с C++ и обсуждение того, как язык программирования влияет на то, как мы думаем о коде.
• Участники также затронули тему того, что сложность реализации может отпугнуть новичков, но что это может быть уменьшено путем улучшения документации и обучающих материалов.
• В конце концов, обсуждение завершилось тем, что участники сошлись на том, что хотя Rust и предоставляет мощные и безопасные абстракции, это не делает его легким для новичков без качественного обучения и документации, и что это может быть улучшено.

Поисковая система DuckDuckGo второй год подряд пожертвовала 25 тысяч долларов Фонду Perl и Raku для поддержки развития языка программирования. Эти средства направляются в Фонд поддержки ядра Perl, который финансирует ключевые улучшения языка.

Среди недавних достижений — модуль builtin, система классов, лексические методы и стабилизация экспериментальных функций вроде сигнатур и try/catch. Разработчик Пол Эванс, получающий финансирование от фонда, внёс значительный вклад в эти нововведения. Многолетняя поддержка спонсоров позволяет фонду увереннее планировать будущее и продолжать работу над развитием Perl.

• DuckDuckGo пожертвовала $25k проекту Perl в рамках благотворительных взносов на общую сумму $1.1M
• В сообществе ведутся дебаты о современной релевантности Perl, где одни отмечают его упадок после неудачи с Perl 6, а другие защищают его как мощный и полезный язык
• Участники делятся личным опытом работы с Perl, отмечая его влияние на их карьеру и сложности, такие как проблемы с версиями библиотек
• Perl продолжает использоваться в крупных компаниях (Craigslist, eBay) и проектах с открытым исходным кодом (OpenBSD)
• Обсуждается необходимость и способы поддержки open-source проектов через публичные пожертвования от брендов

• Разработка инструментов для мониторинга здоровья и окружающей среды: обнаружение микропластика в продуктах, отслеживание мигреней, создание приложений для фитнеса и анализа снов.
• Создание платформ для разработчиков и IT-специалистов: новые языки программирования, системы хранения данных, инструменты для генерации PDF и мониторинга серверов.
• Разработка нишевых сервисов для конкретных отраслей: платежные системы для SaaS, ПО для хирургов, управление детскими садами, анализ орбит небесных тел.
• Создание образовательных и развлекательных продуктов: головоломки, игры, карты старых местностей, многоязычные книги для детей, платформы для совместного мышления.
• Запуск и развитие стартапов в области e-commerce и потребительских товаров: крафтовые напитки, умные часы, электронные значки, дизайнерское ПО и инструменты для ресторанов.

Forth — это уникальный язык программирования 1970-х годов, который до сих пор используется в некоторых нишевых приложениях. Его ключевая особенность — работа со стеком: числа помещаются на стек, а операции (например, +) забирают верхние элементы и возвращают результат. Например, последовательность 5 2 + 10 * вычисляет выражение 10 * (5 + 2) без скобок благодаря обратной польской записи.

Определения новых слов создаются через : и ;. Например, : foo 100 + ; добавляет 100 к верхнему элементу стека. Forth требует точного соблюдения пробелов: +; будет воспринято как одно слово, а не два. Это минималистичный язык, который учит мыслить иначе, расширяя программистский кругозор.

• Участники делятся ресурсами для изучения Forth (Jones Forth, видео, книга) и отмечают его ценность для расширения кругозора и создания собственных языков.
• Обсуждаются технические ограничения и нишевое применение Forth (встраиваемые системы с малыми ресурсами), а также его уникальные особенности, такие как использование двух стеков.
• Критикуется автоматическая прокрутка на странице проекта, делающая его неудобным в Safari и Firefox, но отмечается работоспособность с отключенным JS.
• Пользователи делятся впечатлениями от экспериментального проекта FXYT, предлагают улучшения (демо-программы в интерфейсе) и задают вопросы по реализации (например, рисование круга).
• Высказывается мнение о непрактичности Forth для создания крупных приложений и сложности решения базовых задач (например, чтения строк из файла).

Метод public static void main(String[] args) больше не нужен для первой программы на Java. Теперь достаточно:

void main() {
    var name = IO.readln("Как тебя зовут? ");
    IO.println("Привет, " + name);
}

Наконец-то избавились от этого ужасного кода. Помню, как в школе спрашивал старшеклассника о значении этого метода — он не знал. Позже он бросил колледж и стал ютубером по Minecraft. Какая жизнь.

Выскажитесь в комментариях — дайте волю эмоциям.

• Пользователи обсуждают нововведение в Java 21 (JEP 445), которое упрощает объявление метода main, убирая необходимость в public static void main(String[] args).
• Многие вспоминают, как изучали этот синтаксис в начале своего пути в программировании и как со временем он становился понятным.
• Есть мнение, что изменение полезно для начинающих, так как уменьшает количество "магических заклинаний", которые нужно запомнить, чтобы написать первую программу.
• Часть участников скептически относится к изменению, считая, что явное объявление метода main было визитной карточкой Java и не создавало реальных проблем.
• Некоторые сравнивают это изменение с аналогичными упрощениями в других языках, например, в C#.
• Обсуждается, является ли это изменение лишь синтаксическим сахаром или же реальным улучшением языка, упрощающим его изучение.

Titania — экспериментальный язык от автора Odin.
Цель: максимум производительности, минимум «магии», ясный код.

Ключевые идеи

• Статическая типизация, компиляция «в ноль»
• Нет GC: ручной или автоматический RAII
• Процедурный, но с мощными шаблонами и compile-time вычислениями
• Прямая работа с SIMD, FFI, встраиваемый ASM
• Синтаксис: C-подобный, но короче; нет препроцессора

Статус
Публичный прототип, API меняется. Собирается LLVM или собственный бэкэнд.

• Участники обсуждают язык Wirthwhile: критикуют обязательное объявление всех переменных в начале функции, но @munificent объясняет, что это упрощает однопроходную компиляцию.
• Появляются вопросы о мотивации создания ещё одного языка и его отличиях от Oberon-07; @khaledh напоминает, что автор — создатель Odin.
• Предлагаются экспериментальные синтаксические идеи: спец-символ «.» для перевода строки и отказ от println; сообщество отмечает конфликт с методами и контекстно-зависимость грамматики.

AI-кодинг: компилятор, а не магия

LLM — это компилятор: английский вместо C, выхлоп — код.
Работает лишь для тривиальных задач; чуть сложнее — приходится писать спецификации длиннее самого кода.
Английский не имеет спецификации, выхлоп недетерминирован, изменение в одном месте ломает всё.
Казаться быстрее на 20 %, реально медленнее на 19 % (arxiv.org/abs/2507.09089).

«ИИ заменит программистов» так же, как компиляторы заменили ассемблер и Excel — бухгалтеров: инструмент, а не чудо.
Миллиардные инвестиции в «vibe coding» — повторение провала self-driving.
Вместо хайпа стоит делать лучшие языки, компиляторы и библиотеки.

• Опытные разработчики спорят: кто-то экономит часы на рутине, кто-то теряет скорость из-за «зайцев» и недопонимания кода.
• AI-инструменты (автодополнение, Claude Code, Cursor) дают +20–50 % к старту, но требуют навыка «prompt-инженерии» и постоянного контроля.
• «Вайб-кодинг» без понимания архитектуры быстро даёт MVP, но приводит к техдолгу и невозможности поддержки.
• Независимые исследования пока не подтверждают значительного ускорения для сеньоров в сложных кодовых базах; выгода заметнее в шаблонных CRUD-задачах.
• Рынок и инвесторы толкают AI-хайп из-за страха пропустить «новое интернет», а не из-диоказанной эффективности.

Содержимое PDF-файла представляет собой бинарные данные, которые нельзя напрямую интерпретировать как текст. В представленном фрагменте — это служебные структуры PDF (объекты, потоки, метаданные), а не читаемый текст документа.
Перевод и сокращение невозможны, поскольку отсутствует осмысленный текстовый контент.

• Брукс по-прежнему прав: основная трудность — «существенная сложность» предмета, а не инструменты.
• За 40 лет не появилось ни одного «серебряного пули», дающего 10× прирост продуктивности.
• Экосистемы (Python, AWS и др.) снизили accidental complexity, но добавили новую через зависимости и «слоёный пирог».
• LLM и ИИ ускоряют рутину, но не решают существенную сложность и не умеют формулировать требования.
• Культура SWE изменилась: скорость вытеснила ответственность, код пишут «на скорую руку» и быстро забывают.

### Скалярные типы
- `u8` 0…255  
- `i8` -128…127  
- `bool` true/false  
- `u16`, `i16`, `f32`, `u32`, `i32`, `u64`, `i64`, `f64`, `u128`, `i128`, `usize`, `isize`, `char`

### Составные
- `(T, U)` кортеж  
- `struct` именованные поля  
- `enum` варианты  
- `union` пересекающиеся данные  
- `[T; N]` массив фикс. длины  
- `()` юнит

### Безразмерные
- `[T]` слайс  
- `str` строковый слайс  
- `dyn Trait` трейт-объект  
- `&[T]`, `&mut [T]`, `&str`, `&mut str`, `&dyn Trait`, `&mut dyn Trait`

### Ссылки
- `&T` shared  
- `&mut T` mutable

### Диапазоны
- `a..b`, `..b`, `a..`, `a..=b`, `..=b`, `..`

### Утилиты
- `Option<T>`  
- `Result<T, E>`  
- `Ordering`  
- `Arguments` (format!)

### Асинхронность
- `Poll<T>`  
- `Context`  
- `Pin<T>`

### Анонимные
- `fn()` item  
- `|x| …` closure  
- `async fn` / `async ||`  
- `impl Trait`

### unsafe
- `UnsafeCell<T>`  
- `ManuallyDrop<T>`  
- `PhantomData<T>`

### Сырые указатели
- `*const T`, `*mut T`

### Указатели на функции
- `fn(T…) -> U`

### Паника
- `PanicInfo`, `Location`

### Недостижимый
- `!` never

• Пользователи сравнивают визуализацию «Elements of Rust» с периодической таблицей и другими подобными гайдами (например, cosmic.mearie.org), отмечая, что она выглядит красиво на десктопе, но неудобна на мобильных и требует горизонтального скролла.
• Некоторые находят подборку полезной для быстрого погружения, особенно если уже знакомы со статически типизированными языками.
• Критика: «таблица» кажется произвольной в группировке типов, не объясняет, почему важные концепты рядом, и из-за плотности информации может отпугнуть новичков.
• Упоминаются аналоги из C/C++, а также ссылки на другие Rust-гайды, попадавшие на HN.
• Для строковых представлений в стандартной библиотеке есть трейты Display и Debug; сериализация JSON доступна через сторонние крейты (например, serde).

Контракты для C  
C++ почти утвердила контракты (P2900); я попробовал адаптировать идеи для C.  
Пока это черновик, без реализации в компиляторах.

Главное:  
- `pre`/`post` — проверяемые условия на входе/выходе функции.  
- Не ломают ABI.  
- Компонуются и позволяют оптимизатору выкинуть лишние проверки.  
- Если условие — константа, оно как `static_assert`: ошибка компиляции.

Базовые примитивы  
```c
contract_assert(условие, "текст");   // всегда проверяется, при лжи — abort
contract_assume(условие, "текст");   // компилятор верит, иначе UB

Пример функции

// заголовок
void *my_malloc(size_t s) pre(s) post(r: r);

// реализация
inline void *my_malloc(size_t s) {
    contract_assert(s, "size != 0");
    defer { contract_assert(defer_return_value, "ok"); };
    return malloc(s);
}

defer выполняет post-проверку при любом выходе.
Инлайн даёт компилятору видеть контракт; внешняя декларация сохраняет привычное разделение .h/.c.

Польза: читаемость, статический анализ, оптимизация.

• Участники спорят, что считать «контрактом»: от assert до полноценных спецификаций, проверяемых компилятором.
• Проблема С/С++: нет единого стандарта, каждый реализует по-своему (Digital Mars — с 90-х, Frama-C, C23 unreachable()).
• Часть сообщества считает контракты костылем для слабой типизации: «если типы не выражают инварианты, добавь ещё один слой».
• Критика С23: макрос contract_assume вызывает UB через unreachable(), что делает поведение непредсказуемым и оптимизацию агрессивной.
• Альтернативы: переходить на Ada/SPARK, Rust, OCaml — там контракты либо встроены, либо доказываются статически.

V как Go с шоколадкой
Go — это ваниль: просто, быстро, без фанатизма. V же — «ваниль++»: тот же вкус, но сверху посыпка из фич.

Карты

langs := {"elixir": {"score": 100}}
score := langs["elixir"]["score"] or { -1 }

Фиксированные типы, or {} вместо if err != nil, spread-оператор ... для слияния.

Структуры

struct Language {
pub mut:
    score int = -1
    name  string @[required]
}

Методы можно вешать прямо на массивы, поля можно помечать @[required], дефолты и флаги CLI задаются в одном месте.

WithOption

fn new_server(opts ServerOptions) ! { ... }

Встроенный «функциональный» паттерн: new_server(port: 8080, debug: true).

Enum и лямбды

Enum’ы есть, лямбды короткие: nums.filter(it % 2 == 0).

Подводные камни

• net.http пока не дотягивает до Go.
• veb (веб-фреймворк) сырой.
• Сборка сложнее: нужен v и C-компилятор.
• Параллелизм есть, но экосистема молода.

Итог

V — это Go с синтаксическим сахаром и парой острых углов. Для экспериментов — огонь, для продакшена — пока нет.

• Участники спорят, действительно ли V лучше Go: одни отмечают быструю компиляцию и «красивые» фичи, другие — нестабильность компилятора и отсутствие надёжности.
• Поддерживающие Go указывают на его зрелость, стабильность GC, удобство кросс-компиляции и отказ от «лишнего».
• Сторонники V хвалят синтаксис (const по умолчанию, sum types, простой С-интерфейс), но признают, что язык пока «сырой».
• Некоторые считают V «предупреждением» о том, почему Go часто говорит «нет» новым возможностям.
• Есть мнение, что ни Go, ни V не решают задачу «лёгкого C для приложений»; предлагают смотреть на Zig или Free Pascal.

Red — язык нового поколения, вдохновлённый Rebol. Компилирует в нативный код, охватывает от системного программирования до высокоуровневых скриптов и кроссплатформенных GUI. Поддерживает современные примитивы параллелизма, не требует установки и настройки: всё умещается в один файл ≈ 1 МБ.

• Проект Red вызывает ностальгию, но разработка фактически стоит: 32-битные бинарники, проблемы на macOS, отсутствие 64-битной версии.
• Пользователи ищут «простой кроссплатформенный язык + GUI» и обсуждают альтернативы: LiveCode, Tcl/Tk, Dart/Flutter, Iced (Rust), Nushell.
• Сообщество жалуется на «срыв» после ухода в блокчейн/ICO и низкий bus-factor.
• Некоторые считают REBOL/Red «функционально-императивным» и homoiconic, но интерес к языку снизился из-за барьеров запуска.

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

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

Я пишу свой язык Baba Yaga — чисто из любви к эстетике кода. Рабочий интерпретатор есть, но полноценной среды пока нет; планирую браузерный «бесконечный холст» в духе Smalltalk.

Язык — эксперимент ради удовольствия: неизменяемость, функциональный стиль, минимальный синтаксис, базовые «батарейки». Это Toki Pona для Haskell.

Синтаксис и типы

Объявления переменных и функций одинаковы; скобки не нужны, каррирование бесплатно.

transport : "Chicken House"
add : x y -> x + y
add5 : add 5

Базовые неизменяемые типы: Int, Float, String, Bool, List, Table.

numbers : [1, 2, 3]
person : {name: "Lucy", age: 23}

Типы можно указать явно; без аннотаций всё проверяется только во время вызова.

Управление потоком

Единственный способ — when (pattern matching). Нет if/else или switch.

describe : x ->
  when x is
    0 then "Zero"
    _ then "Something else"

processUser : user ->
  when user is
    {name: n, age: a, active: true} -> "Adult: " .. n
    _ -> "Unknown"

Пример: жизнь Конвея уже работает.

• Участники делятся опытом создания языков: @codr7 показал фреймворк Shi, @aldousd666 рассказал о своих интерпретаторах, начавшихся в 2006-м.
• Разгорелся спор о синтаксисе: одни хвалят «:» для присваивания, другие защищают «=» как уже устоявшийся символ.
• Кто-то предлагает отказаться от точек с запятой, кто-то считает их полезным разделителем.
• Обсуждаются математические корни обозначений: одни считают «=» сравнением, другие — утверждением.
• Предлагаются альтернативы: «:=», «<-», «=>», а также идея вызывать функции в порядке чтения.

Go всё ещё плох

Кратко: автор 10+ лет критикует Go за архитектурные ошибки, которые легко было избежать.

1. Ошибки: неверная область видимости

bar, err := foo()
if err != nil { … }
if err = foo2(); err != nil { … }
// err висит до конца функции, хотя нужен только в двух строках

Читателю приходится тратить время, выясняя, где err ещё используется.

2. Два вида nil

var i interface{}
var s *S
fmt.Println(s == nil, i == nil, s == i) // true, true, false
i = s
fmt.Println(s == nil, i == nil, s == i) // true, false, true

Один «billion-dollar mistake» не хватило — сделали два.

3. Непереносимость

Условная компиляция через комментарии в начале файла — «аристотелевский» подход: теория без практики. Реальные проекты страдают.

4. append без чёткого владения

a := []string{"hello", "world", "!"}
foo(a[:1]) // внутри append
fmt.Println(a) // результат зависит от капасити слайса

Поведение неочевидно и требует знания внутренностей.

5. defer вместо RAII

В Java и Python ресурс закрывается автоматически при выходе из блока.
В Go приходится вручную писать defer foo.Close() и гадать, какие ресурсы вообще требуют закрытия.

• Go хвалят за простоту, быструю компиляцию, встроенные инструменты и удобную конкурентность.
• Критикуют «двойной nil», слабую систему типов, проблемы GC, неинтуитивный defer и скудные абстракции.
• Многие считают его «достаточно хорошим» для бэкендов и CLI-утилит, особенно при скорости разработки.
• Крупные проекты жалуются на «смерть тысячей порезов» и трудности отладки из-за строгости компилятора.
• Часть сообщества видит в Go компромисс между Node/Python и Rust, другие — устаревший язык без современных фич.

Recto — язык, где код — это вложенные прямоугольники. Он не читается сверху вниз, а воспринимается пространственно: структура и рекурсия задаются формой, а не текстом.

Идея

Большинство языков — линейны: слова идут одно за другим. Recto отказывается от этой традиции и возвращается к древним «картам мыслей» — пиктограммам, звёздным картам, схемам. Главное требование к языку:

1. Понятен человеку и машине.
2. Может быть создан человеком и машиной.

Линейность не обязательна: можно представить «приложение», где жест или выражение лица превращается в сетку эмодзи, и всё работает.

Примеры

• Hello Recto — прямоугольник, внутри которого текст Hello Recto.
• Арифметика — прямоугольники-числа и операторы встраиваются друг в друга, образуя выражения.
• Факториал — рекурсивный прямоугольник ссылается на себя.

Почему это важно

Recto показывает, как можно писать, парсить и мыслить кодом без строк и файлов. Он открывает путь к языкам, где значение рождается из формы, а не последовательности символов.

Попробовать: Recto Pad | Google Colab | GitHub

• Участники обсуждают Recto как «2D-язык», но многие считают его всё же 1D с «скобками и лишними шагами».
• Поднимаются примеры других 2D/3D-языков: PATH, Befunge, Hexagony, Orca, Unreal Blueprints, Racket 2d.
• Спор о том, считать ли нотный стан или речь по-настоящему многомерными; автор статьи настаивает на их 1D-основе.
• Предлагаются улучшения: полноценная графическая среда, Unicode-рамки, поддержка VR/AR, именованные параметры.
• Упомянуты эксперименты с «временем» как измерением (EmiT, ICFPC 2024).
• Автору пожелали сил в борьбе с раком и скинули ссылки на GoFundMe и CaringBridge.

Universalis: язык, который читают эксперты, а пишут LLM
Автор: Erik Meijer

• Цель — дать знатокам предметной области возможность формулировать задачи естественным языком и получать готовые программы без участия разработчиков.
• Средство — язык Universalis (в честь Лейбница), исполняемый нейро-компьютером Automind. Код похож на Excel-формулы, обёрнутые в «живые» описания.

Пример
Вопрос: «Алиса купила килограмм яблок за @B и продала за @S. Какой процент прибыли @P?»
Ответ-Universalis:

[@D is (@S-@B)]  
[@P is (@D/@B)*100]

Вводим @B=10, @S=17 → @P=70 %.

Особенности

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

• Критика: статья расплывчата, синтаксис «языка» меняется, управляющие конструкции описаны прозой, примеры сводятся к «сделай всё за меня».
• Сомнения: это реальный язык или фантазия LLM?
• Опасения: упрощение ведёт к потоку «мусорного» кода.
• Технические детали: под капотом Kotlin DataFrames, возможна ad-hoc типизация.
• ACM Queue обвиняют в рекламе без упоминания ограничений.
• Перспектива: рано или поздно придётся заново изобретать модули, типы, ошибки, параллелизм и т.д.

I learned recently that the creator of the Iosevka typeface did so using their own Lisp implementation.The typeface:https://github.com/be5invis/IosevkaThe language:https://github.com/be5invis/PatELTheir tool which they used to build the language:https://github.com/be5invis/patris

The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be d

Strange to read this article and find no mention of Julia (but APL, Mojo, MLIR BQN etc.. which are not exactly widely used languages). It checks many of the boxesUser-Extensible Rank Polymorphism is just beautiful with the broadcast dot syntax. I don't think any other language ha

I think this page describes "what" but not "why" of Carbon.Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.The most important attribute of Carbon is not the specifics of the syntax but the fact that it'