Hacker News Digest

I'm genuinely interested in the world around me, and I like being entertained as much as the next person, but the problem with social media for me is that it creates a simulacrum of the world which does not correspond to the tangible reality I see around me.I would go further and

Python is quickly turning into a crowded keyword junkyard Source link indicating PEP 810 was accepted:https://discuss.python.org/t/pep-810-explicit-lazy-imports/1... This will be huge at the place I work!I’m unfamiliar with the PEP process. How long until this makes it into a Pyt

Команда Skald переписала бэкенд с Python на Node.js всего через неделю после запуска, идя против стандартного совета стартапам сначала "делать то, что не масштабируется". Основная причина — сложность с асинхронностью в Python, особенно при работе с Django. Автор отмечает, что писать качественный асинхронный код на Python "очень сложно и неинтуитивно", в отличие от JavaScript с его event loop или Go с goroutines.

Django до сих пор не имеет полной поддержки асинхронности: нет нативного асинхронного файлового ввода-вывода, ORM не поддерживает async, а для интеграции синхронных и асинхронных функций требуется постоянно писать sync_to_async и async_to_sync. Даже крупные компании вроде PostHog, несмотря на наличие AI-фич, продолжают использовать традиционный WSGI вместо полного перехода на асинхронность. В итоге команда пришла к выводу, что Django скоро начнет создавать проблемы с производительностью даже при небольшом количестве пользователей.

• Обсуждение в основном вращается вокруг того, что Python/async-экосистема остаётся незрелой, а Django-ORM не предназначена для асинхронной работы, что делает выбор между «старым, но проверенным» и «новым, но сырым» неоднозначным.
• Участники спорят, стоит ли жертвовать удобством разработки и экосистемой ради производительности, или же лучше переписать всё на Node/TypeScript, если речь идёт о высоконагруженном REST API.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

Автор изучает необычный стиль написания кода Артура Уитни, создателя языков программирования A, K, Q и высокопроизводительных баз данных kdb и Shakti, используемых в финансовой индустрии. Основное внимание уделено компактному интерпретатору языка K размером всего около 50 строк на C, который демонстрирует уникальный подход Уитни к программированию. Код насыщен макросами и использует необычные синтаксические конструкции C, что делает его трудным для понимания, но потенциально эффективным для быстрого восприятия всей логики целиком.

Автор мотивирован изучению этого стиля кода по нескольким причинам: желание писать более компактный код, возможность более быстрого понимания сложных систем при концентрации всей логики в одном месте, а также то, что чтение кода стало важнее его написания в его работе. Интересно, что Уитни использует тип char * как для строк, так и для целых чисел, что является одним из его необычных подходов. Несмотря на первоначальную сложность, автор смог разобраться в большинстве частей кода к концу изучения.

• Код стиля Артура Уитни (Arthur Whitney) — это микро-DSL на препроцессоре C, который вдохновлялся APL; читать его лучше всего, если вы знакомы с APL, иначе он может казаться нечитаемым.
• Подход «сначала напиши, потом сделай это читаемым» противоположен современному подходу «сначала сделай это читаемым, потом напиши код».
• Сторонники и противники такого стиля спорят о том, является ли это «искусством» или «самообфускацией»; в то время как другие считают, что это просто вопрос привычки и что читаемость может быть улучшена с помощью современных инструментов.
• Некоторые комментаторы отмечают, что стиль кода Уитни может быть трудным для чтения, но он также может быть более выразительным и эффективным для тех, кто привык к APL.
• В конце концов, обсуждение пришло к выводу, что важно не только то, как стиль кода влияет на читаемость и поддерживаемость, но и то, как команда работает вместе, чтобы поддерживать и развивать код в течение длительного времени.

• Компании ищут специалистов от фронтенда до научных исследователей, охватывая такие области как AI, финтех, здравоохранение, игры, инфраструктура и многое другое.
• Многие предложения включают удалённую работу и гибридные форматы, но также есть требования к часовым поясам или периодическим встречам.
• Стартапы и устоявшиеся компании предлагают различные уровни компенсации: от зарплаты и акций до контрактов и опционов.
• Некоторые роли требуют конкретных навыков, таких как опыт с определёнными языками программирования, инфраструктурой или фреймворками.
• Некоторые позиции требуют наличия разрешения на работу в США или Европе.

• Разнообразие технологий охватывает от классических стеков (Java/Spring, C++, Python) до современных стеков (TypeScript, Next.js, Rust, Go) и специализированных инструментов (Unity, Unreal, embedded, data engineering, QA, low-code, etc.)
• Участники демонстрируют глобальный охват: от США и Канады до Европы, Азии, Австралии и Латинской Америки, что подчеркивает международный характер рынка.
• Почти все открыты к удаленной работе, но при этом большинство не готовы к релокации, что подчеркивает гибкость и предпочтение к удаленной работе.
• Некоторые участники подчеркивают свою готовность к релокации, особенно внутри США или в крупных технологических центрах.
• Некоторые участники подчеркивают свою готовность к релокации внутри ЕС или в Северной Америке, что может быть важно для компаний, которые ищут таланты в этих регионах.

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

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

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

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

В 2025 году обновился инструмент ucs-detect для проверки поддержки Unicode в эмуляторах терминалов, теперь тестирующий DEC Private Modes, sixel-графику, размер пикселей и версию ПО. Методика проверки основана на отправке видимого текста с последующими управляющими последовательностями для определения позиции курсора, с сравнением результатов со стандартом Python wcwidth. Основная проблема эмуляторов — корректное отображение широкого спектра Unicode-символов в фиксированной сетке без нарушения читаемости.

Лидером тестов стал новый эмулятор Ghostty, разработанный с нуля на языке Zig и показавший наилучшую поддержку Unicode. Почти не уступил ему Kitty, реализовавший алгоритм разбиения текста, близкий к спецификации Python wcwidth. Оба эмулятора корректно поддерживают Variation Selector 15. Среди неожиданных результатов — низкая производительность: iTerm2 и Extraterм потребляли чрезмерное количество CPU, а GNOME Terminal на базе VTE работал более 5 часов. Полные результаты доступны на сайте проекта.

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

OpenAI is generating $13B a year in revenue. Let’s be generous and say $20B. They’ve signed commitments to spend something like $1.4 trillion on compute. An asset that to date has proven to have a hyper-depreciation cycle.Someone has to come up with $1.4 trillion in actual cash,