Hacker News Digest

Cloudflare и VoidZero совместно с Максом Швенком из Owner.com работают над tsrs — портом компилятора TypeScript на Rust, который развивается в составе инструментальной цепочки Oxc. Это не форк: команда TypeScript сохраняет полный контроль над языком, а порт обязан строго следовать её решениям, иначе со временем станет несовместимым. Ранние замеры обещают до 8 раз большей скорости и примерно на 70% меньше памяти по сравнению с TypeScript 7.0 при том же числе обработчиков проверки типов. При этом TypeScript 7.1 beta уже до 2.5 раз быстрее 7.0, и часть оптимизаций пришла из tsrs.

Попробовать экспериментальную версию можно через npm install tsrs и npx tsrs. Rust выбран не только ради скорости: важна и сборка в WebAssembly, что упрощает запуск полноценной среды разработки прямо в браузере. По умолчанию tsrs использует адаптивную конфигурацию, зависящую от типа машины: она потребляет больше памяти, но работает ещё быстрее. Авторы подчёркивают, что раньше масштабные порты почти не удавались, а теперь передовые ИИ-модели способны выполнять их за считанные дни.

Процесс сопровождается автоматикой: агенты ежедневно проверяют изменения, собирают диффы и заводят задачи, а ночью прогоняют тесты Next.js против Vinext, выявляя расхождения. Тот же подход применят к TypeScript, стараясь не вносить отличий в поведение и возвращая улучшения производительности в кодовую базу TypeScript на Go. Пока есть расхождения, например порядок вывода диагностик, но к стабильному релизу их сведут к минимуму. В планах — более глубокая интеграция tsrs в стек Cloudflare, в том числе для типозависимых правил линтера в Oxlint.

tsrs демонстрирует до 8-кратный рост скорости и снижение потребления памяти на ~70%. Эти показатели достигнуты не только за счет Rust, но и благодаря алгоритмическим оптимизациям, которые планируют перенести в TypeScript 7.1. Основным драйвером порта стала необходимость легкого компилятора для WASM-песочницы, где Rust предпочтительнее тяжелого Go-runtime. При этом арена-модель памяти в tsrs вызывает опасения, так как скрывает unsafe-код и может быть небезопасной. Также отмечается, что AI-генерация порта ускоряет разработку, но требует тщательного ревью из-за риска архитектурных ошибок. tsrs хорошо масштабируется при многопоточном запуске и поддерживает инкрементные проверки, хотя bun остается эффективнее по общим метрикам.

Автор рассказывает, как потерял работу не потому, что модель оказалась лучше него, а потому что она была дешевле. Как последний инженер в компании, он стоил дороже, чем подписка на «Fable» — модель, которую руководство сочло достаточной, чтобы дотянуть до слияния. Это не первое его увольнение: раньше ему приходилось самому сообщать подчинённым об уходе, зная об этом за неделю. На этот раз, узнав о своём увольнении, он несколько часов держался, а потом пульс подскочил выше ста ударов в минуту и не спадал больше недели.

Масштаб проблемы шире одного человека: шестеро или семеро знакомых из группы по «DevOps» потеряли работу или получили уведомление за последний месяц, включая сотрудника одной из FAANG-компаний, которому выдали шесть месяцев выходного пособия и уничтожили личные вещи. Другой нанимающий менеджер лишился должности через неделю после того, как генеральный директор запоздало опубликовал статью о том, что «ИИ меняет разработку». Автор подчёркивает: корректнее говорить не «ИИ забрал мою работу», а «ИИ поспособствовал упразднению моей роли».

При этом модели, по его мнению, всё ещё не заменяют опытного инженера: им не хватает вкуса в продуктовых решениях и предвидения последствий — роста издержек, сложности, доступности. Но они уже достаточно хороши, чтобы под присмотром переносить проверенное поведение между платформами: «Shopify» переписал приложение с «React Native» на нативный код, а порт «TypeScript» на «Rust» воспроизвёл даже исходные баги. В итоге модели не заменили людей — они убедили тех, у кого есть деньги, тратить их иначе.

Тред подтверждает, что компании увольняют инженеров ради экономии, заменяя их дешевыми подписками на AI-модели (например, Fable), или используют ИИ как предлог для сокращений ради краткосрочной прибыли (@glimshe, @philipodonnell). Это напоминает прошлый опыт замены сотрудников дешевым аутсорсингом (@voidifremoved, @TrackerFF). Мнения о возможностях LLM разделились. @gregwebs и @echelon считают, что модели уже способны генерировать готовый код, поэтому роль инженера трансформируется в техническое руководство и управление ИИ. Другие (@dofm, @TrisEck) уверены, что моделям не хватает вкуса и продуктового чувства. @jdw64 приводит пример приложения на моделях Astra и Fable, которое оказалось полно багов, что доказывает невозможность полной замены квалифицированного программиста. Пострадавшим инженерам советуют создавать собственные проекты с помощью тех же моделей для сохранения дохода (@laylower), а также относиться к работе как к средству, а не центру жизни (@sajithdilshan, @danw1979).

Claude Haiku 5.5 — это новая быстрая и дешёвая модель от Anthropic, предназначенная для задач с высоким объёмом и чувствительностью к стоимости: суммаризация, классификация, запросы к базе данных и работа суб-агентов в коде. Она в среднем на 75% дешевле, чем Haiku 4.5, и является самой быстрой моделью компании на сегодняшний день, что делает её идеальной для живой поддержки клиентов и использования в браузерах. Haiku 5.5 также впервые в линейке Haiku поддерживает регулируемую настройку усилий — пользователи могут выбирать между оптимизацией по стоимости или по интеллекту.

В тестах Haiku 5.5 показывает сильные результаты: например, в OSWorld 2.1 (offline subset) достигает 72.4% точности, что значительно выше, чем у Haiku 4.5 (15.7%), и близко к Sonnet 5.5 (83.9%). В задачах мультидисциплинарного рассуждения (Humanity’s Last Exam) модель набирает 45.9% без инструментов и 57.4% с ними. В агентном кодировании (Terminal-Bench 4.0) Haiku 5.5 решает 39.2% задач — существенный рост по сравнению с 0.0% у Haiku 4.5. Одновременно с запуском Haiku 5.5 Anthropic снизил цену на чтение кэша у Sonnet 5.5 на 50%, что делает её на ~20% дешевле в агентных задачах, и ввёл ежемесячные API-кредиты для подписчиков Max и Team (до $500), чтобы стимулировать создание новых агентов и приложений на Claude Platform. Обновлены также Python и TypeScript SDK с поддержкой computer и browser use в бета-версии.

Claude Haiku 5.5 быстрее и в 9 раз дешевле Haiku 4.5, показав рост на два уровня в DataAnalyticsBench. Модель является самой быстрой у Anthropic (131 токен/сек на OpenRouter, задержка до 2 сек) и демонстрирует лучшее соотношение качества, скорости и цены в RAG-системах с технической документацией. Она превосходит GPT-6 Luna в компьютерном использовании и агентном кодировании, а по общей производительности сопоставима с Qwen-3.8 и Sonnet 5.5. При объеме до 100K токенов цена Haiku 5.5 совпадает с GPT-6 Luna ($0.10/MTok input, $0.50/MTok output), однако из-за того, что токенизация Haiku 5.5 потребляет в 1.5 раза больше токенов, реальная выгода снижается. После порога в 100K стоимость Haiku 5.5 растет до $2.50/MTok, что делает Luna выгоднее для длинных запросов (особенно свыше 272K). Модель позиционируется как суб-агентная: она эффективна в простых операциях и автоматизации, но уступает Opus 5.5 в генерации сложных UI (например, LCARS) и глубоком статистическом анализе. Отмечены возможные регрессии: ошибки в простых задачах (подсчет букв в слове «diminished»), утечки промптов и случаи, когда модель работает хуже Haiku 4.5. Для бизнес-пользователей ценность модели повышают API-кредиты для Max и Team-подписчиков ($100–$500). Haiku 5.5 становится альтернативой GLM и DeepSeek, возвращая доверие пользователей после неудач версии 4.5. Рекомендации: — Haiku 5.5: для максимальной скорости, низкого бюджета и малых объемов данных. — GPT-6 Luna: для запросов свыше 100K токенов. — Sonnet или Opus 5.5: для сложных рассуждений и создания UI.

Node.js претерпел значительные улучшения: теперь поддерживает весь современный ECMAScript, включая нативную работу с TypeScript без require(), а устаревшие API заменены на более удобные и стандартизированные интерфейсы. Автор вернулся к Node после длительного использования Deno и был приятно удивлён тем, насколько платформа стала приятной в использовании — особенно после миграции проекта на SvelteKit, где сборки стали на 15% быстрее даже без полной оптимизации под Node-specific API.

Для управления версиями и пакетами он выбрал FNM и PNPM, настроив алиасы npm=pnpm и npx=pnpx для совместимости с гайдами, а также добавил в pnpm-workspace.yaml политики minimumReleaseAge: 1440 и trustPolicy: no-downgrade, чтобы откладывать обновления и избегать потенциально вредоносных пакетов — мера, продиктованная недоверием к NPM из-за его истории с post-install скриптами и угрозами безопасности. Что касается TypeScript, Node запрещает stripping типов внутри node_modules по философским причинам — чтобы не поощрять публикацию пакетов на TypeScript и избежать "засорения" экосистемы продуктами Microsoft, поэтому автор использует Tsdown для сборки.

Миграция с Deno оказалась простой: замена Deno.serve на Hono с node-адаптером, Deno.fs на node:fs, а @std/path на node:path — и всё заработало. Несмотря на ностальгию по Deno, автор констатирует его упадок: runtime потерял инновационный drive, стал жертвой стартап-культуры, а проблемы с JSR (429 ошибки), ZSH-интеграцией и конкуренцией в HTTP-запросах сделали его непригодным для daily use. В итоге Deno удалён через brew uninstall deno, а Node стал новым "лучшим другом" — не потому что идеален, но потому что наконец-то стал достаточно хорош, чтобы им пользоваться без страданий.

Node.js стал более стабильным и предсказуемым благодаря улучшениям, но Deno сохраняет уникальные преимущества: встроенные инструменты (тест-раннер, линтер, тип-чекер), безопасность по умолчанию (явное разрешение на сеть и файловую систему), простота работы с TypeScript, автоматическая генерация документации из TSDoc через JSR, сборка в один исполняемый файл и поддержка десктоп-приложений — функции, которых нет в Node.js нативно. Это делает Deno привлекательным для новых проектов, несмотря на снижение активности команды и отсутствие прозрачного роадмапа после увольнений. Node.js по-прежнему остаётся базовым runtime для enterprise-сред, где важна стабильность, а не новизна, и не требует изменения архитектуры приложения. Bun показывает высокую производительность, но ограничен в GPU-задачах. Переход на новые рантаймы следует оценивать по реальным потребностям: стабильность, безопасность и поддержка, а не по тренду. Deno не поддерживает нативный запуск OpenSSL в дочерних процессах, что ограничивает его в некоторых производственных сценариях. Участники спорят, превзошёл ли Node.js Deno, но конкретные примеры его превосходства не приведены. Deno по-прежнему предлагает возможности, которые Node.js не воспроизводит, особенно для разработчиков, ценящих минимальную конфигурацию и отсутствие управления npm-пакетами.

Балдур Бьярнасон описывает, как его карьера в разных сферах — от авторства до разработки и образования — оказалась экономически неустойчивой, а профессиональные сообщества отвергали междисциплинарных специалистов, считая их либо слишком «техничными» для творческих ролей, либо наоборот. С приходом генеративного ИИ спрос на его образовательные проекты резко упал: курсы, книги и тренинги перестали востребоваться, а коллеги начали закрывать бизнес. Разработчики всё чаще используют чат-боты вместо системного обучения, что Bjarnason называет «обратным, неопределённым» подходом к образованию.

Аксель Раушмайер, автор популярных бесплатных онлайн-книг по JavaScript и TypeScript, сообщает, что его доход от продаж упал с уровня, достаточного для жизни (2024), до нуля (2026), несмотря на рост трафика — почти весь он теперь генерируется AI-сканерами, которые не приносят рекламных доходов. Из-за этого он вывел свой блог и книги из сети, чтобы защитить своё произведение от несанкционированного использования ИИ-компаниями. Салма Алам-Нэйлор, бывший специалист в DevRel, описывает выгорание из-за давления на роль, которая не может приносить краткосрочную прибыль, и отмечает, что разработчики заменили живое обучение и обмен опытом на бесконечную прокрутку короткого контента и диалоги с чат-ботами. Она считает, что ИИ крадёт тщательно созданные учебные материалы, стирая личность и труд преподавателей, и ушла в менее заметную разработческую работу. Джош В. Комо также подтверждает, что его бизнес моделей онлайн-курсов и интерактивных tutorialов разрушен ИИ, который централизует знания и commodifies их, вместо того чтобы обучать глубине и навыкам. Автор подчёркивает, что веб — радикально демократическая среда, и её разрушение угрожает inclusivity и самоопределению. Восстановление веб-развития возможно только через сеть людей, поддерживающих друг друга, изучающих технологии на практике, формирующих лучшие практики и делящихся знаниями — без оплаты труда преподавателей и исследователей это невозможно. ИИ-компании appropriating чужой труд не могут быть оправданы.

Обсуждение показывает, что падение спроса на образовательные продукты связано не только с ИИ, но и с изменением поведения обучаемых: исчезла мотивация к глубокому обучению, пользователи предпочитают задавать вопросы напрямую ChatGPT вместо поиска учебников или видео. Авторы контента сталкиваются с резким падением доходов: продажи книг и курсов упали до нуля, а бесплатные блоги получают трафик от AI-кrawler'ов, который не приносит рекламных доходов. Платформы, сохранившие высокое качество и интерактивность (например, Boot.dev), смогли сохранить рост доходов, в отличие от тех, кто полагался на пассивный текстовый контент. Студенты и разработчики используют ИИ для автоматизации рутинных задач (запоминание API), чтобы сосредоточиться на высших уровнях абстракции: анализе моделей, архитектурных компромиссах и доменной логике. Есть спор: некоторые считают, что ИИ приводит к «умственному вырождению» («vibe coding»), другие видят в этом естественную эволюцию — как переход от ручного HTML к фреймворкам. Преподаватели отмечают, что традиционные методы (видео, курсы, книги) становятся нерентабельными: ИИ-генерируемый контент дешевле и быстрее, но хуже по качеству, что подрывает доверие к образовательным продуктам. ИИ позволяет создавать персонализированные обучающие системы (Discord-боты с тестами и планами на основе учебников), превосходя традиционное преподавание по эффективности. Рынок страдает не только от ИИ, но и от общего спада в IT: люди перестали инвестировать в обучение, не видя возврата на инвестиции — это вопрос экономической целесообразности, а не качества. Новые поколения разработчиков, выросшие с ИИ, не испытывают потребности в глубоком понимании базовых технологий, меняя саму суть «уметь программировать». Совет: образовательные институты должны переосмыслить обучение — учить суждению, системному мышлению и оценке качества AI-сгенерированных решений, чтобы готовить специалистов, способных доверять, но не слепо полагаться на ИИ. Многие авторы прекратили создавать контент, чувствуя себя обманутыми: их труд скопирован ИИ, доходы исчезли, а платформы не защищают авторские права или не компенсируют убытки. ИИ уничтожил экономику «free content»: раньше реклама и спонсорство поддерживали качественные блоги, теперь AI-кrawler'ы потребляют контент, но не кликают на рекламу — делая его финансово невыгодным. Опытные разработчики считают, что падение спроса на курсы — не катастрофа, а возвращение к естественному обучению: «just do it», а не «watch a video». Качество новых технических книг резко упало — многие созданы ИИ без участия автора («AI slop»), вызывая недоверие у покупателей. Образование в веб-разработке не умерло, но трансформировалось: ключевая задача — научить строить надёжные системы, а не писать код, потому что код генерируется ИИ, а суждение — нет.

Pi Durable — это фреймворк для создания долгоживущих, устойчивых к сбоям и гибких агентов, способных работать в любой среде с JavaScript-рантаймом. Он не заменяет Pi как код-агента, а предоставляет универсальную основу для построения агентных приложений, включая самого Pi. Фреймворк построен на принципах минимализма и изменяемости, делится кодом с Pi (например, pi-ai), и позволяет экспериментировать с новыми архитектурами без риска для основного продукта. Весь исходный код без тестов составляет около 15 000 строк (150–250 тыс. токенов), но для большинства задач достаточно меньшей части — например, хранилища занимают всего 3 000 строк и легко подменяются.

Харнесс в Pi Durable — это сочетание хранилища и механизма для параллельного запуска множества разговоров с LLM. Он предоставляет инструменты, которые модели могут вызывать, и среды их выполнения (локальная машина, удалённая VM, песочница). Разговор — это транскрипт взаимодействия пользователя с агентом (LLM + настройки + инструменты). Каждый вызов модели или инструмента — это задача. Хранилище может быть in-memory, SQLite или JSONL, с возможностью подключения собственных бэкендов через простой интерфейс. На SQLite активные данные (транскрипты, задачи, отправки) держатся в памяти, а остальное — на диске, что обеспечивает эффективность и устойчивость к сбоям. Один процесс владеет хранилищем, другие клиенты подключаются к нему.

Pi Durable поддерживает бесконечно длинные диалоги, выживает при катастрофических сбоях и позволяет нескольким людям управлять одним агентом одновременно. Пример — агент для планирования отпуска (~1300 строк TypeScript, mostly TUI), который демонстрирует параллельный поиск (погода, музеи, поезда), устойчивость к перезапуску (только незавершённые задачи повторяются), переключение между суб-агентом и главным, и автоматическое формирование плана из результата. Для запуска достаточно собрать проект и выполнить две команды; для использования в своих проектах — установить три пакета через npm. Выбор TypeScript обусловлен простотойbootstrap, но порт на Rust или ассемблер не исключён в будущем.

Обсуждение подтверждает практическую ценность Pi Durable для длительных задач: аналитика, мониторинг cron‐задач, автоматическое создание PR и ежедневный триаж алертов. Pi Durable не предоставляет встроенный sandbox; разработчики должны подключать собственный (например, Gondolin от Earendil) в соответствии с политиками. Спор: одни считают фреймворк должен быть sandbox‐агностичным, другие видят отсутствие first‐class sandbox‐а недостатком. Разговоры в Durable реализованы как линейный список записей с указателем на предшествующий (fork); ветвление дерева заменено плоской структурой. requestId используется как ключ идемпотентности для exactly‐once, но некоторые считают, что одного ID недостаточно. Токенизация кода зависит от модели: 15 000 строк ≈ 150 000 токенов GPT и 250 000 токенов Claude. Создание хранилища, координирующего несколько экземпляров vanilla Pi, сложно и может превзойти выгоды от durability. Для синхронизации внешних хранилищ с состоянием разговора рекомендуется задача‐синхронизатор (например, SyncToPostgres). Многопользовательский режим отмечен как важный плюс для удалённых контрольных инструментов. Durability достигается хранением JSON‐документов локально и минимизацией объёма данных в памяти. Совет: не «запекать» инструменты по умолчанию; лучше предоставить профиль с опцией включения нужных. Совет: добавить полити‐движок для sandbox‐ов (например, интеграция с NVIDIA openshell). Pi Durable позиционирует себя как более агностичный по сравнению с LangChain, Vercel Eve, OpenAI Agents и другими решениями. Вопрос синхронизации состояния агента и состояния VM/контейнера остаётся открытым. Жалобы на читаемость шрифта кода в статье не относятся к техническим аспектам.

Reladraw — это текстовый язык для создания диаграмм с точным, но гибким позиционированием элементов. В отличие от Mermaid или Graphviz, где расположение автоматизировано, и draw.io, где нужно вручную перетаскивать узлы, Reladraw позволяет задавать относительные позиции: below, right of, level with — без ручного указания координат. Например, диаграмма архитектуры из 10 узлов и связей описывается всего 7 строками кода, что делает её легко редактируемой и версионируемой. Результат рендерится в SVG без внешних зависимостей.

Инструмент доступен как CLI-утилита через npm install -g reladraw и интегрируется с AI-агентами (Claude, Copilot и др.) через плагины. На данный момент версия 0.11.1 — ранняя, с нестабильным синтаксисом, но уже работает: парсер, движок макета и рендерер написаны на TypeScript. Проект открыт для обратной связи — особенно ценятся примеры диаграмм, которые невозможно выразить текущим синтаксисом. Лицензия Apache-2.0, но торговая марка «reladraw» не включена в разрешения.

Обсуждение подтверждает, что необходимость точного позиционирования в диаграммах действительно существует и Reladraw закрывает этот пробел, однако пользователи указывают на баги (тёмные темы, кривые стрелки), просят интеграцию в markdown и IDE, а также сравнивают его с D2/TALA и задаются вопросом, стоит ли создавать новый язык или расширять существующие инструменты вроде Mermaid.

• Большинство комментаторов считают, что текущие инструменты (Mermaid, Graphviz, draw.io) либо автоматизируют расположение, либо требуют ручного перетаскивания, и поэтому им не хватает детального контроля, который предоставляет Reladraw.

• Относительные позиции (below, right of, level with) воспринимаются как достаточный уровень точности для большинства диаграмм, избавляя от необходимости указывать абсолютные координаты.

• Совет: Разработчикам рекомендуется создать плагины для популярных редакторов (VS Code, Obsidian) и поддержать блоки кода ```reladraw в markdown, чтобы упростить использование в документации.

• Совет: Полезно отделить топологическую часть языка (стрелки, группы) от инструкций по расположению, что позволит использовать Reladraw как слой раскладки для других DSL, например C43.

• В обсуждении отмечены баги: некорректный рендер кривой стрелки при указании from/to и проблемы с переключением тем в Safari, где тёмный фон делает текст нечитаемым.

• Совет: Необходимо добавить поддержку тем и исправить рендеринг в разных браузерах, а также обеспечить более стабильный веб‐интерфейс перед выпуском.

• Некоторые пользователи упомянули D2 с открытым движком TALA, который уже предоставляет ручной контроль над расположением и иногда генерирует более качественные макеты, чем Mermaid.

• Спор: Одна сторона считает, что вместо создания нового языка следует добавить ограничения размещения в Mermaid, чтобы не фрагментировать экосистему; другая сторона аргументирует, что только отдельный язык может гарантировать детерминированный результат без вмешательства движка раскладки.

• Есть интерес к автоматическому преобразованию описаний архитектуры, сказанных устно, в Reladraw‐диаграммы, что может облегчить взаимодействие с AI‐агентами.

• Совет: Рассмотреть возможность импорта/экспорта из/в форматы draw.io, чтобы пользователи могли мигрировать существующие схемы в Reladraw без потери информации.

This is very needed in the AI coding age! I find diagramming is one of the best ways for high bandwidth alignment between my mental model and the agent’s. I have been working on this problem a bit as I see good visuals as a key bottleneck in faster development while maintaining a real… — @apinstein

CI стал узким местом из‑за ускорения разработки: тестовый набор вырос в четыре раза, но проверка изменений отстаёт, увеличивая время ожидания и стоимость инфраструктуры. Чтобы ускорить обратную связь, мы оптимизировали время ожидания PR и потребление раннер‑времени, снизив среднее время ожидания с более 6 минут до чуть более 5 и вдвое сократив машинное время на тест.

Улучшения реализованы в четырёх направлениях: переход на более быстрые сторонние раннеры с лучшим кэшем ускорил задачи в среднем на 34 % (tsc — на 52 %); замена tsc на tsgo сократила медианное время проверки типов на 73 %; переписывание линт‑правил на работу с AST вместо TypeScript уменьшило время линтинга API на 68 % и полного репозитория — на 55 %, а также подготовило почву для перехода на Oxlint; увеличение количества тестовых шардов с 4 до 8 при одновременном улучшении параллелизма сократило время настройки с 8,3 до 7,5 минут, позволив запускать больше тестов одновременно. Без этих усилий тестовый набор занимал бы около 11 минут — почти вдвое дольше текущего показателя. С темпом роста около 2000 тестов в неделю дальнейшая оптимизация CI останется непрерывным процессом.

Ускорение разработки с помощью ИИ создало новый системный узкий пункт в виде CI. Решение проблемы требует не только оптимизации инфраструктуры, но и пересмотра архитектуры, процессов и ролей. Для ускорения пайплайнов и снижения затрат рекомендуют: — переход с GitHub Actions на сторонние раннеры с быстрыми CPU, производительным хранилищем и кэшем (например, blacksmith.sh); — использование Bazel для достижения времени сборки около 10 секунд при разогретом кэше в крупных проектах; — применение RWX как более гибкой альтернативы Bazel с кэшированием по содержимому и графовым выполнением задач. Для повышения эффективности разработки и тестирования: — разделять сервисы на изолированные компоненты с чёткими контрактами; — в Vitest балансировать нагрузку по длительности выполнения тестов, а не по количеству файлов. После оптимизации CI критическими узкими местами становятся деплой, откат и человеческое тестирование (QA), так как важно обеспечить удобство и любовь пользователей к продукту. Автоматизация продукт-менеджмента остается более сложной и важной задачей, чем автоматизация кода. Для соло-разработчиков целью является сокращение времени сборки до 5 минут для комфортной работы с агентами. Компании (например, Linear) обычно приступают к глубокой оптимизации инфраструктуры при достижении масштабов вроде 100M ARR. Существует спор о влиянии ИИ: одни считают, что погоня за скоростью ведет к падению качества, энергозатратности и неэффективному «бросанию кода на стену», другие отмечают рост числа приложений и незаметные, но частые улучшения UX (например, в YouTube для Android). Стартапы YC растут быстрее благодаря ИИ, в то время как крупные корпорации (Apple, Microsoft, Nintendo) не используют передовые инструменты разработки. Системы неизбежно становятся громоздкими со временем, и сейчас этот цикл проходят Linear и другие инструменты.

Автор делится размышлениями о том, как меняется процесс обучения программированию в эпоху больших языковых моделей (LLM). Он отвечает на письмо читателя, который, несмотря на отсутствие формального образования в области CS, смог создать сложную систему на TypeScript/JavaScript с использованием LLM, но теперь сталкивается с трудностями при попытке превратить её в надёжный продукт. Читатель ощущает, что построил нечто, что работает, но не полностью понимает, и зависит от ИИ даже для базовых решений, что вызывает вопрос: действительно ли он владеет навыком или лишь создал иллюзию компетентности?

Автор признаёт, что сам не имеет чёткой позиции по поводу LLM, но склонен к скептицизму, несмотря на их полезность. Он отмечает, что когда LLM работают хорошо, это вызывает раздражение, поскольку ставит под сомнение ценность десятилетий накопленного опыта. Когда они ошибаются, хотя и раздражают, хоть что-то остаётся под контролем человека. Он связывает своё отношение не только с личным опытом, но и с экономическими рисками: если LLM вытеснят программистов раньше других профессий, это может привести к массовой безработице в знаниевой экономике, которую общество, возможно, не выдержит.

Что касается обучения, автор подчёркивает, что его собственный путь — через книги, документацию и примеры кода — сегодня неприменим для новичков. Он сам теперь может быстро осваивать новые языки, читая чужой код, но это возможно только благодаря глубокому фундаменту, построенному без ИИ. Для изучения чего-то действительно необычного, например, APL, всё равно нужны учебники. Он избегает использования LLM для открытых вопросов вроде «что изучать дальше?», предпочитая задавать только проверяемые, фальсифицируемые вопросы — например, можно ли сделать код короче — чтобы ответ можно было немедленно проверить на практике. В итоге он выступает за осознанное, критичное использование LLM: как инструмента для уточнения, а не замены понимания.

LLM ускоряют создание кода и MVP, но не заменяют глубокое понимание архитектуры, логики и причин сбоев. Инструменты усиливают разрыв между поверхностными и компетентными разработчиками: эксперты используют ИИ для рутины, а новички рискуют попасть в ловушку, создавая рабочий код без навыков отладки и анализа. Программирование остается процессом управления сложностью, структурирования и мышления. Без умения программировать традиционным способом (чтение документации, эксперименты) невозможно оценить качество кода LLM и поддерживать систему при сбоях. Рекомендации по обучению: — Использовать LLM в проектах, но глубоко разбирать сгенерированный код, заменяя зависимость от ИИ пониманием. — Изучать языки, требующие работы со структурой и абстракциями (например, Clojure, Common Lisp), так как LLM берут на себя синтаксис и бойлерплейт. — Сохранять навыки критического мышления и причинно-следственного анализа. Роль программиста смещается от написания кода к управлению абстракциями, оценке качества и принятию архитектурных решений. Главным правилом остается: если вы не можете объяснить, почему код работает, вы не сможете его исправить.

QM — это многопользовательская система агентов для команд, где каждый сотрудник получает изолированное рабочее пространство с собственными файлами, ключами, кронами и навыками, но при этом может сотрудничать в каналах Slack и проектах. Система поддерживает одновременную работу в веб-интерфейсе и Slack с единым профилем, а все действия выполняются в изолированных песочницах, что исключает конфликты между пользователями.

Основа QM — открытый, модельно-независимый ядро на TypeScript, работающее с Node.js и Fastify, которое поддерживает разные LLM (Pi, Claude Code, OpenCode и др.) через единый интерфейс. Данные хранятся в Postgres, а инструменты и навыки — в персонализированных песочницах. Организации настраивают систему через директорию deploy/layers/<org>, сохраняя ядро неизменным и легко обновляемым. Для безопасности и контроля доступа предусмотрены гранты на навыки, админ-контроль и автоматизированные процессы (кроны, веб-приложения). Система позволяет автоматизировать поиск по внутренним данным, писать письма под стиль сотрудника, запускать тесты в репозиториях и публиковать внутренние инструменты — всё с изоляцией и масштабируемостью.

Пользователи считают QM интересной, но требуют чёткого описания возможностей и ограничений. Система может быть полезна для команд, но требует лучшей документации, поддержки и индивидуальной настройки. Некоторые считают, что её функционал можно реализовать другими инструментами, например Claude Cowork. Критики указывают на ограничения и риски безопасности, другие — на её применимость в отдельных случаях. Акцент делается на необходимости обеспечивать безопасность и эффективность, избегая слепого доверия готовым решениям.

Инструмент @openai/codex-security — это CLI и TypeScript‑SDK, позволяющие обнаруживать, проверять и исправлять уязвимости в коде. Требуется Node 22 или новее и Python 3.10 +, а также доступ к Codex Security. Установка через npm i @openai/codex-security, вход командой npx codex-security login и сканирование репозитория npx codex-security scan .. Для CI можно использовать переменную OPENAI_API_KEY вместо входа, а при наличии обоих учетных записей интерактивный скан запрашивает выбранный метод; в неинтерактивных режимах приоритет остаётся у API‑ключа. Параметр --auth chatgpt или --auth api-key позволяет явно указать источник.

Результаты сканирования сохраняются в рабочем каталоге Codex Security; если запись недоступна, задайте CODEX_SECURITY_STATE_DIR на записываемую директорию. Для работы с TypeScript‑SDK импортируют CodexSecurity из пакета, создают экземпляр, вызывают run('.'), выводят reportPath и закрывают соединение close(). Всё необходимое о параметрах сканирования, настройке CI и дополнительных опциях описано в официальной документации. Интересный факт: при конфликте учётных данных интерактивный режим предлагает выбрать источник, а в автоматизированных пайплайнах предпочтение отдаётся API‑ключу, что упрощает интеграцию в существующие workflow. Кроме того, можно фильтровать результаты по уровню угрозы через --severity и экспортировать отчёт в JSON для дальнейшего анализа.

Тред обсуждает практический опыт использования Codex Security: пользователи отмечают высокие затраты и ограничения по скорости запросов, что может быть проблемой для крупных проектов. Есть споры о его эффективности — одни считают инструмент полезным для обнаружения уязвимостей, другие сомневаются в его способностях. Рекомендуется использовать опцию --max-cost для контроля расходов. Codex Security сравнивают с Snyk и Strix, обсуждая его потенциальное влияние на рынок безопасности.

Bun изначально появился как Zig‑порт esbuild, получивший сразу набор функций: транспилятор JavaScript/TypeScript, пакетный менеджер, тест‑раннер, HTTP‑клиент и др. За год он стал скачиваться более 22 млн раз в месяц и поддерживается компаниями Vercel, Railway, DigitalOcean и другими. Однако из‑за низкоуровневого кода на Zig в проекте накопилось множество критических багов — use‑after‑free, утечки памяти, гонки, которые приходилось фиксировать вручную.

Переписав ядро на Rust, команда добавила AddressSanitizer, постоянно запускает fuzzing и выпускает безопасные Release‑Safe‑билды. Это позволило полностью устранить use‑after‑free, утечки в crypto.scrypt, tlsSocket.setSession и другие уязвимости, а также сократить размер бина и ускорить warm‑install в 7 раз. Rust‑реализация обеспечивает системную защиту от подобных ошибок, делает Bun более надёжным и готов к дальнейшему развитию.

• Исключительно быстрый переход от Zig к Rust с помощью Claude Code, протестировавшего 100 % тестов за 11 дней.
• Стоимость переписывания оценивается в $165 000 токенов, что дешевле найма полноценной команды.
• Критика направлена на отсутствие открытого анализа проблем, а не на эмоции; многие отмечают рост надёжности и уменьшение размера бинарника.
• Дискуссия подчёркивает, что такой подход возможен только при наличии зрелых тест‑сьютов и опыта автора, а также вызывает вопросы о долгосрочной поддержке и выборе стека.

Deno’s runtime includes a dedicated section for desktop application development, offering a full suite of tools and APIs to build cross‑platform GUI programs. It walks developers through project setup, backend integration, HTTP serving, framework choices, and OS‑specific packaging, while also covering advanced features such as WebGPU rendering, hot‑module replacement, DevTools, auto‑update mechanisms, error reporting, and distribution pipelines.

The guide is organized into many subsections—configuration, backends, serving, frameworks, Windows, WebGPU, bindings, menus, tray & dock, dialogs, notifications, HMR, DevTools, auto‑update, error reporting, distribution, and comparison—allowing developers to pick the exact capabilities they need. Notable points include built‑in auto‑update support, WebGPU for modern graphics, and a modular architecture that lets you enable only the pieces you use, making large‑scale desktop projects more maintainable. It also details testing approaches, continuous‑integration hooks, and the CLI commands for scaffolding, bundling, and publishing desktop applications. Security is built‑in, requiring explicit permissions for file, network, and environment access, while TypeScript is supported natively. The documentation also compares different frameworks, helping developers choose the most suitable one for their use case.

• Обсуждается внедрение общего CEF‑рантайма для Deno Desktop, чтобы сократить размер бинарников до нескольких мегабайт.
• Планируется интеграция с системой прав Deno, чтобы пользователь мог удобно просматривать и управлять разрешениями.
• Сравнение с Tauri и другими решениями: возможность использования собственного CEF, несколько бекендов (CEF, WebView, raw) и вопросы размера пакетов.
• Текущий размер приложений остаётся высоким (от 15 МБ с сжатием до 40‑440 МБ), вызывают вопросы по оптимизации и будущей поддержке мобильных платформ.

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

Фреймворк предлагает гибкость синтаксиса — от привычного HTML до более лаконичных вариантов Concise и JS — и поддерживает TypeScript для строгой типизации. Marko обеспечивает разделение concerns, управляемые компоненты, вложенную реактивность и неизменяемое состояние, что упрощает разработку масштабируемых приложений. Интеграция с экосистемой включает file-based routing и возможность использования как простых шаблонов, так и мощных компонентов по мере роста проекта.

• Обсуждение вращается вокруг того, что веб-разработка циклически возвращается к идеям, похожим на ColdFusion и JSP, и это вызывает у участников разговора разные чувства от ностальгии до раздражения.
• Участники обсуждают, что такое "HTML-основнный" язык, и как он отличается от JSX и других подходов, и почему мы снова и снова возвращаемся к этой идее.
• Обсуждение затрагивает вопрос о том, что некоторые считают, что эволюция веб-технологий просто движется по спирали, где старые идеи периодически перерабатываются и выдаются как новые.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.

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

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

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

Команда 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.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

Диалог высмеивает современную тенденцию усложнять разработку на Rails, добавляя множество инструментов вроде Vite, React, TypeScript, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky, Docker и Redis. Всё это оправдывается стремлением к «современности» и скорости, но приводит к громоздкой настройке.

В противовес этому демонстрируется простота «ванильного» Rails: один командой запускается мгновенно работающее приложение с быстрой загрузкой и формами. Ключевая идея — Rails уже содержит всё необходимое, а избыточные инструменты лишь создают сложность без реальной выгоды. Фраза «Просто используй Rails, блин!» резюмирует мысль: не усложняй там, где это не нужно.

• Участники обсуждают растущую сложность современных веб-фреймворков, отмечая, что Rails предлагает более простой и "батарейками включенный" подход по сравнению с перегруженными инструментами JS-экосистемы.
• Многие выражают ностальгию по классическому Rails, критикуя такие новые решения, как Hotwire и Stimulus, за сложность освоения и недостаток документации, в то время как другие защищают их как "путь Rails".
• Поднимается тема чрезмерного усложнения проектов (over-engineering), особенно для небольших команд, где монолитные фреймворки (Rails, Django) часто продуктивнее разделения на фронтенд и бэкенд.
• JS-экосистема подвергается критике за постоянное "изобретение велосипедов", сложность инструментов и модульность, которая приводит к усталости от инструментария, хотя некоторые защищают её гибкость.
• Отмечается, что выбор инструментов должен определяться конкретными задачами проекта, а не модными тенденциями, и что проверенные временем технологии часто эффективнее для небольших и средних приложений.

Python-разработчики всё чаще используют аннотации типов, чтобы повысить надёжность кода в условиях роста проектов от прототипов до промышленных систем. Гибкость динамической типизации, которая раньше ускоряла эксперименты в AI и data science, теперь становится риском для стабильности. Решение предложено в PEP 484 (2014) — постепенная статическая типизация, позволяющая добавлять аннотации без полного переписывания кода.

Ключевые преимущества: раннее обнаружение ошибок через статический анализ, улучшенная документация и автодополнение в IDE, а также упрощение рефакторинга крупных кодовых баз. Это особенно важно для команд с разнородным опытом разработчиков, где явные типы снижают когнитивную нагрузку и ускоряют онбординг.

• Критика Python type hints как нарушающих дух языка, добавляющих излишнюю сложность и не дающих преимуществ в производительности.
• Поддержка type hints как ценной документации, улучшающей читаемость, рефакторинг и предотвращающей ошибки.
• Сравнение с другими статически типизированными языками (TypeScript, Rust), где система типов интегрирована лучше.
• Прагматичный подход: использование type hints выборочно, как подсказок, а не строгого требования.
• Влияние type hints на работу с ИИ-инструментами, улучшая автодополнение и понимание кода.

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

Cap'n Web — это новая система RPC для браузеров и веб-серверов, созданная Cloudflare на чистом TypeScript. Она наследует философию объектно-ориентированных возможностей (object-capability) от Cap'n Proto, но оптимизирована для веб-стека: использует JSON для сериализации, работает поверх HTTP, WebSocket и postMessage(), весит менее 10 КБ и не требует схем или шаблонного кода. Поддерживает двусторонние вызовы, передачу функций и объектов по ссылке, а также конвейеризацию промисов для сокращения задержек.

Настройка занимает буквально несколько строк: клиент подключается через WebSocket, а сервер реализуется как класс с методами, которые автоматически становятся удалёнными процедурами. Например, метод hello(name) на сервере можно вызвать из браузера как api.hello("World"). Система интегрируется с TypeScript для типобезопасности и работает в Cloudflare Workers, Node.js и современных браузерах. Это делает распределённое программирование почти неотличимым от локального, с учётом сетевых реалий.

• Обсуждение Cap'n Web как упрощённой, schemaless версии Cap'n Proto RPC для TypeScript/JavaScript с поддержкой передачи функций и двусторонних вызовов.
• Сравнение с другими технологиями: проводятся параллели с GraphQL (решение проблемы N+1, но без DataLoader), tRPC/ORPC (схемы vs schemaless), gRPC-web (сложность) и старыми системами вроде Java RMI или .NET Remoting.
• Подняты вопросы о безопасности (риски из-за отсутствия схем и передачи произвольных колбэков), состоянии сервера (статусность vs статусность) и проблемах отладки (сложность отслеживания сетевых запросов).
• Обсуждаются технические детали: пайплайнинг промисов для уменьшения RTT, выполнение .map() на сервере через DSL, управление памятью и сборкой мусора для долгоживущих соединений.
• Запросы на расширение: поддержка других языков (Rust, Elixir), стриминг, генераторы, версионирование API и бинарная совместимость с Cap'n Proto.

Многие библиотеки в экосистеме JavaScript стали избыточно сложными из-за попыток обработать все возможные крайние случаи, даже те, что на практике почти не встречаются. Например, функция clamp, предназначенная для ограничения чисел, превращается в монстра, проверяющего строки, валидирующего типы и значения, что приводит к появлению микробиблиотек вроде is-number с 90 млн загрузок в неделю. Это результат плохого технического дизайна: вместо чёткого определения ожидаемых входных данных разработчики добавляют слои проверок для гипотетических сценариев.

Правильный подход — проектировать функции под конкретные типы данных, оставляя валидацию значений на усмотрение вызывающей стороны. Библиотеки вроде is-arrayish или pascalcase, принимающие разнородные входы, лишь увеличивают сложность и зависимости без реальной пользы. Стоит вернуться к простоте: в большинстве случаев достаточно встроенных методов языка, а специализированные решения нужны только для узких задач, а не как стандарт.

• Обсуждение критикует избыточное использование зависимостей в JavaScript/TypeScript для простых задач, таких как проверка типов, что ведет к раздуванию экосистемы.
• Участники связывают проблему с историческими особенностями JavaScript: отсутствием строгой типизации и богатой стандартной библиотеки в прошлом.
• Поднимается вопрос о дизайне контрактов функций: следует ли валидировать входные данные внутри функции или возлагать эту ответственность на вызывающую сторону.
• Отмечается культурное различие между сообществами: в Python принята модель "согласованных взрослых", а в JS — оборонительное программирование.
• Обсуждается роль статической типизации (TypeScript) и стандартных библиотек как способа уменьшить потребность в микро-пакетах для проверок.

Deno подала официальную петицию в Ведомство по патентам и товарным знакам США, чтобы оспорить товарный знак Oracle на слово «JavaScript». После сбора более 27 тысяч подписей под открытым письмом проект перешёл к ключевой стадии discovery, требующей серьёзных ресурсов. Цель — доказать, что термин стал общедоступным обозначением языка, а не брендом Oracle, и освободить его для использования разработчиками, конференциями и авторами без юридических рисков.

Для усиления позиции Deno запустила кампанию по сбору $200 тыс. на экспертные опросы, показания свидетелей из индустрии и академической среды, а также юридические расходы. Oracle уже официально отвергла аргументы о generic-статусе термина. Успех дела важен не только для JavaScript, но и для принципов товарного права: победа корпорации создаст прецедент присвоения общеупотребимых понятий.

• Критика сбора средств VC-финансируемой компанией Deno для суда с Oracle из-за товарного знака "JavaScript"
• Сомнения в успехе и целесообразности дела против Oracle с её огромными ресурсами и возможными негативными последствиями для сообщества
• Предложения альтернативных решений: переход на использование названий "JS", "ECMAScript" или "TypeScript"
• Восприятие инициативы как PR-хода или маркетингового хода, а не искреннего общественного служения
• Поддержка цели освобождения названия, но с оговорками относительно мотивов и методов Deno

Почему PostHog стал похож на ОС
Мы устали от типичных сайтов: бесконтентные скроллы, одинаковые вкладки, пустое пространство. Новый PostHog.com работает как ОС в браузере: окна «прилипают», есть горячие клавиши, закладки, можно читать новости, смотреть демо и играть одновременно.

Что внутри

• Проводник Windows для магазина мерча
• Продуктовые страницы в стиле PowerPoint
• Редактор документов с возможностью правки
• Форумы как Outlook Express
• Плеер QuickTime, таблицы вместо дизайна, скринсейвер и обои
• 50+ горячих клавиш

Техника
Контент отделён от визуального слоя: продукты описаны в JSON, темы и цветовые схемы настраиваются, клиентские цитаты и логотипы хранятся в одном месте и подтягиваются автоматически. Всё собрано в прод-ветке на Tailwind + TypeScript.

• Сайт PostHog выглядит как десктоп ОС в браузере: окна, таски, «окна в окнах».
• Кому-то нравится визуальный стиль и ностальгия по 90-м, но почти все жалуются на тормоза, жрущий CPU JS и поломанные привычные хоткеи/кнопки.
• Пользователи теряются: непонятно, где контент, как начать читать и что вообще продаёт компания.
• Критика сводится к «изобретаю заново мой менеджер окон», «ломает SEO и accessibility», «не работает Back, не скроллится, на мобиле ужасно».
• Некоторые считают это крутым маркетинг-ходом и «growth-hack», но сомневаются, что кто-то будет реально пользоваться.

grok-code-fast-1 — новая модель xAI для агентного кодинга: быстрая, дешевая, заточена под ежедневную работу.

• Скорость: архитектура с нуля, оптимизация инференса, кеш >90 %. Десятки вызовов инструментов до того, как вы прочтёте первую строку мыслей.
• Цена: 0,20 $/1 M входных, 1,50 $/1 M выходных, 0,02 $/1 M кешированных токенов.
• Языки: TypeScript, Python, Java, Rust, C++, Go.
• Инструменты: grep, терминал, редактирование файлов — «родная» работа в IDE.
• Партнёры: временно бесплатно в Cursor, GitHub Copilot, Cline, Roo Code, Kilo Code, opencode, Windsurf.

Производительность

• 190 токенов/сек, SWE-Bench-Verified 70,8 %.
• Оценки реальными разработчиками: быстро и надёжно для рутинных задач.

• Кто-то хвалит grok-code-fast-1 за скорость и качество, сравнивая с gpt-5-mini, другие считают «быстро, но тупо».
• Основная критика: упор на скорость вместо качества, неточные или вредные изменения кода, сомнительные внутренние бенчмарки.
• Несколько человек жалуются, что модель случайно удаляет код и скрывает кнопки «стоп».
• Подняты этические и экологические вопросы: нелегальные газовые турбины и «обученный нацистский бот».
• Часть пользователей просто рада быстрой бесплатной модели в Cursor/VS Code для простых задач.

Rust повышает производительность разработки, несмотря на сложность.
Ключевые факторы:

• Жёсткий компилятор ловит ошибки до запуска, уменьшая время отладки.
• Модель владения устраняет гонки и утечки памяти, снижая количество багов.
• Инструменты: Cargo, Clippy, rustfmt и rust-analyzer ускоряют цикл «написание → проверка → запуск».
• Сообщество предлагает качественные крейты и быструю помощь.
• Производительность кода сравнима с C/C++, но без segfault и UB.

В итоге меньше времени тратится на отладку, больше — на новые функции.

• Автор статьи рассказал, как Rust позволяет безболезненно рефакторить большие кодовые базы благодаря строгой типизации и проверкам компилятора.
• Многие участники согласились, что статическая типизация (Rust, Haskell, OCaml-подобные языки) повышает уверенность при изменениях, особенно в многолюдных проектах.
• Часть комментаторов считает сравнение с TypeScript «нечестным»: TS компилируется в JS и наследует его недостатки, а приведённый баг с window.location.href — это особенность DOM, а не языка.
• Некоторые отметили, что Rust тоже не идеален: async/синхронные блокировки, медленная компиляция и «множество способов сделать одно и то же» могут снижать удобство.
• Общий вывод: преимущество Rust в безопасности и рефакторинге особенно заметно на больших проектах, но язык требует времени на изучение и не всегда лучше «классических» статически типизированных альтернатив.

Перешёл в компанию, где стек — Python. Выбор был не из-за языка: Python мне всегда казался гигантским красным флагом. Тем не менее, начинаю к нему привыкать.

Почему я любил Ruby

Ruby — мой первый «язык-любовь»: всё объект, if можно переписать блоками, method_missing позволяет метапрограммировать. Он черпал у Smalltalk и Lisp, и это вдохновляло.

Почему ненавидел Python

Python казался «хуже Ruby» и «ещё хуже Scheme». if — оператор, а не выражение; lambda уродливые; до Python 3 print вообще был оператором. Один «правильный» способ делать всё раздражал.

Типы для нетипизированного

Потом пришёл TypeScript: мощная система типов, narrowing, conditional types. Плохие конструкции языка прощаются статическим анализом.

Я изменился

TypeScript научил: отсутствие match или if-выражения пережить, если компилятор проверит инициализацию. Rust показал, что мутабельность — не зло.

Python изменился

Теперь в Python есть type hints, match с деструктуризацией, а print — функция.

• Автор рассказал, как после появления VSCode и LSP перестал использовать языки без типов и теперь не хочет возвращаться к Ruby без нормальной типизации.
• Участники обсуждают, что Ruby остаётся элегантным и «радостным», но его отказ от постепенной типизации (включая Sorbet) отталкивает многих.
• Python, напротив, эволюционирует: появились аннотации типов, LSP, но язык стал сложнее и уже не «выучить за выходные».
• Некоторые считают, что страсть к Ruby — это ностальгия, а промышленность требует стабильности и инструментов, которые дают статические языки.
• Общий вывод: выбор языка всё чаще диктуется экосистемой, инструментами и личными приоритетами, а не чистой «красотой» синтаксиса.

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

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

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

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

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

Вывод
LLM — полезный инструмент для рутины и прототипов, но не заменяет мышление и глубокое понимание.

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.

Задача: перенести TypeScript-утилиту Ruler на Rust, проверить идентичность через bash-тест.
Модели: GPT-5 (новый, превью) и Claude 4 Sonnet.

GPT-5

• Сразу прочитал код, составил подробный plan.md, получил одобрение.
• Работал почти без остановок, дважды отчитывался о статусе.
• Сначала написал bash-скрипт, который запускает оригинал и порт во временной папке и сравнивает вывод.
• Затем сгенерировал структуру src/, Cargo.toml, CLI-аргументы, логику apply/init/revert, обработку конфигов и MCP.
• Итеративно правил код, пока тест не прошёл «зелёным».
• Время: ~20 мин, 1 коммит, ветка feat/rust-port.

Claude 4 Sonnet

• Та же инструкция.
• Сразу начал писать Rust, но упустил bash-тест; пришлось напомнить.
• Тест написал быстрее, но менее читаемый.
• Порт делал «пачками»: сначала CLI, потом логика, потом MCP.
• После 3-х итераций тест прошёл.
• Время: ~30 мин, 3 коммита.

Вывод

• GPT-5 агентнее: сам планирует, реже спрашивает, меньше ошибок.
• Claude надёжнее в деталях, но требует чётких шагов.
• Оба справились, но GPT-5 ощущается «ближе к одной команде — один результат».

• Пользователи сомневаются в объективности сравнений: результаты сильно зависят от системных промптов, харнесов и задач.
• Критика выбора моделей: вместо топ-версии Claude Opus сравнивали более дешёвый Sonnet, что искажает оценку «лучшей» модели.
• Стоимость vs качество: большинство разработчиков не готовы платить 10× за Opus, поэтому GPT-5 рассматривают как «cost-effective» вариант.
• Опыт в продакшене: многие находят Claude Code (Sonnet/Opus) надёжнее при работе с большими кодовыми базами и TDD, тогда как GPT-5 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.