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-подобных систем.

Source maps — это механизм, позволяющий браузеру отображать минифицированный JavaScript обратно на исходный код с правильными именами переменных и форматированием. Когда вы видите ошибку в bundle.min.js:1:27698, source maps переводят её в src/index.ts:73:16, показывая точное место возникновения проблемы в оригинальном TypeScript коде. Этот процесс работает на трёх этапах сборки: транспиляция TypeScript в JavaScript, бандлинг модулей в один файл и минификация, где на каждом шаге сохраняется связь с исходным кодом.

Формат source maps — это JSON-файл с расширением .js.map, где ключевое поле mappings использует VLQ-кодирование для сжатия данных о позициях. Каждое сегмент в mappings содержит информацию о связи между сгенерированным кодом и оригиналом: путь к исходному файлу, строку и столбец, а также оригинальное имя переменной или функции. Это позволяет DevTools эффективно отображать отладочную информацию, несмотря на значительное отличие между минифицированным и исходным кодом.

• Обсуждение началось с похвалы удобства чтения на мобильных устройствах и быстро перешел к семантике терминов "delta" и "offset" в контексте кодирования разностей в source-map.
• Участники обсудили, что "delta" и "offset" технически описывают одно и то же явление, но первый термин чаще используется в математике и физике, тогда как второй более универсален.
• Была затронута тема инструмента для восстановления исходных исходников из веб-приложений, использующих source maps.
• В конце обсуждение свелось к тому, что оба термина могут быть использованы взаимозаменяемо, и выбор между ними часто сводится к личным предпочтениям и контексту использования.

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

Исследования показывают, что некоторые языки с зависимыми типами, такие как Idris, сохраняют часть информации о типах во время выполнения. Это позволяет выполнять проверки типов во время выполнения, открывая новые возможности для метапрограммирования и рефлексии. Однако такая сохранение типов увеличивает размер исполняемых файлов и может снижать производительность.

• Обсуждение показало, что зависимые типы (dependent types) — это не только академическая концепция, но и практически применимы в языках вроде Zig и TypeScript, хотя с ограничениями.
• Участники обсуждали, что в TypeScript условные типы и в Zig comptime демонстрируют схожие с зависимыми типами идеи, но не покрывают полный спектр возможностей зависимых типов.
• Были подняты вопросы о том, что такое "зависимые типы" и как они отличаются от обычных обобщённых типов, с упором на то, что в большинстве языков нет полной поддержки зависимых типов.
• Обсуждались примеры, где тип возвращаемого значения может зависеть от входного значения, и как это может быть реализовано в разных языках.
• Также обсуждались границы между статическим и динамическим анализом типов, и как они влияют на возможность компилятора вычислять и оптимизировать код.

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

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

Vercel представил Workflow DevKit — библиотеку, добавляющую надёжность, устойчивость и наблюдаемость в асинхронный JavaScript. С помощью простого директивного подхода "use workflow" разработчики могут превращать обычные TypeScript-функции в долговременные процессы, способные приостанавливаться, возобновляться и сохранять состояние. Это устраняет необходимость в ручной реализации очередей и механизмов повторных попыток.

Библиотека предлагает декларативный API для определения и использования рабочих процессов, поддерживает шаги с директивой "use step" и предоставляет встроенные инструменты наблюдаемости — отслеживание выполнения, возможность паузы, повтора и "путешествия во времени" по шагам с автоматическим сбором трассировок, логов и метрик. Код работает одинаково на локальной машине, в Docker, на Vercel или любом другом облаке, обеспечивая переносимость без привязки к платформе.

• Обсуждение в основном крутится вокруг критики Vercel Workflow за то, что он представляет собой еще один слой абстракции, который скрывает детали реализации и ограничивает прозрачность, а также заставляет разработчиков использовать магические строки вроде "use workflow", что делает код менее читаемым и более трудным для отладки.
• Участники также отмечают, что это похоже на попытку создать vendor lock-in, поскольку Workflow требует специфичной для Vercel инфраструктуры, и что это может быть частью более широкой тенденции к созданию проприетарных инструментов вместо использования открытых стандартов.
• Некоторые участники также высказывают сомнения в том, что Vercel Workflow может быть не более чем оберткой вокруг очередной системы очередей/конечных автоматов, и что это может быть не более чем попытка создать vendor lock-in.
• Также поднимается вопрос о том, что если бы Vercel предоставил бы возможность самостоятельно хостить "Workflow" движок, это могло бы быть более приемлемо для сообщества, и что это могло бы быть шагом в сторону открытости и само-хостинга.

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

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

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

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

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

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

Пожалуйста, предоставьте ссылку на статью или более подробную информацию о Sandbox SDK, о которой вы хотите получить пересказ. Без доступа к исходному материалу я не могу создать точный и ёмкий пересказ в требуемом формате.

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

Пользователь работает с несколькими моделями одновременно, каждая из которых выполняет атомарные коммиты. Основной стек — TypeScript и React, развернутый на Vercel.

Основная идея — использование инструмента codex (предположительно, внутренний инструмент или API) в качестве основного драйвера для разработки. Вместо того чтобы писать код вручную, пользователь использует несколько экземпляров codex (до 8 одновременно), каждый из которых работает над своей частью задачи. Каждый агент коммитит изменения самостоятельно, что позволяет поддерживать чистую историю.

Ключевые моменты:

• Контекст и координация. Несмотря на то, что агенты работают параллельно, пользователь тщательно управляет их работой, чтобы избегать конфликтов. Например, при работе над крупными изменениями он сначала запускает один агент для оценки, а затем уже основную группу.
• Инкрементальный подход. Вместо того чтобы пытаться решить все сразу, пользователь разбивает задачи на мелкие, атомарные шаги. Например, при обновлении зависимостей он не просто запускает скрипт, а сначала проверяет каждое изменение, затем тестирует, и только потом обновляет.
• Отказ от излишеств. Пользователь избегает сложных систем вроде прекоммит-хуков для валидации, так как они замедляют процесс. Вместо этого он полагается на то, что агенты достаточно умны, чтобы не допускать ошибок.
• Практичность. Инструменты выбираются по принципу "работает — не трогай". Например, codex используется вместо Claude Code, потому что последний стал слишком абстрактным (например, он может часами "думать" над простой задачей). codex же просто делает.

В целом, подход напоминает принцип "двигайся быстро и не ломай" (move fast and don't break things), но с уклоном в "двигаться быстро", даже если иногда что-то сломается. Это компенсируется скоростью: один агент может заменить целую команду, и даже если он ошибся, это быстро фиксится.

• Дискуссия разделилась на два лагеря: «AI пишет почти весь код» против «никакой AI не заменит разработчика»; при этом обе стороны сходятся в том, что важно уметь читать и ревьюить весь код, независимо от того, кто его написал.
• Участники обсуждали, что 300k строк кода, которые, как утверждается, были написаны ИИ, на самом деле могут быть просто увеличены в 10-15 раз по сравнению с тем, что написал бы человек, и что это вызывает сомнения в надёжности такого подхода.
• Поднимался вопрос о том, насколько можно доверять ИИ-написанному коду, и какие именно навыки требуются, чтобы эффективно использовать такие инструменты.
• Также обсуждалось, что важно ли вообще писать статьи о таких инструментах, если они не раскрывают, как именно они используются, и какие именно задачи они решают.

Диалог высмеивает современную тенденцию усложнять разработку на 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-экосистема подвергается критике за постоянное "изобретение велосипедов", сложность инструментов и модульность, которая приводит к усталости от инструментария, хотя некоторые защищают её гибкость.
• Отмечается, что выбор инструментов должен определяться конкретными задачами проекта, а не модными тенденциями, и что проверенные временем технологии часто эффективнее для небольших и средних приложений.

Функциональное программирование принесло во фронтенд мощные абстракции: React с компонентами как функциями от состояния, Redux с предсказуемыми редюсерами и TypeScript для типобезопасности. Однако эти принципы — чистота функций, неизменяемость данных и явные побочные эффекты — вступили в конфликт с природой веба, где DOM мутабелен, CSS каскадируется глобально, а пользовательские события асинхронны и хаотичны. Вместо адаптации к платформе разработчики стали строить слои абстракций, фактически объявляя войну встроенным механизмам браузера.

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

• Критика излишнего усложнения фронтенд-разработки из-за увлечения функциональным программированием и абстракциями в ущерб простоте и нативным возможностям платформы.
• Споры о читаемости и уместности использования методов массивов (map, filter, reduce) вместо классических циклов, а также о качестве кода на CSS.
• Обсуждение проблем управления состоянием и иерархией данных в UI, включая сравнение React с другими подходами и фреймворками.
• Вопросы к эволюции веб-платформы и стандартов, которые не успевают за потребностями разработчиков и популярными решениями из фреймворков.
• Замечания о качестве статьи-первоисточника: построение на спорных утверждениях (straw man) и продвижение авторской технологии (HTMLX).

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

Доступен в публичном превью для JavaScript и TypeScript экосистем. Агент анализирует код на предмет совместимости, выявляет устаревшие методы и даже предлагает модернизацию синтаксиса. Пользователи получают $15 ежемесячного кредита. Ключевое преимущество — сокращение рутины и предотвращение застоя обновлений в бэклоге за счёт автоматизации стратегических решений.

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

• Компании ищут инженеров для работы с AI/ML, включая роли Senior Machine Learning Engineer, ML Scientist и разработчиков для создания AI-инструментов в различных областях, таких как биология, недвижимость и безопасность.
• Предлагаются позиции в software development, включая Full Stack, Backend, Frontend и MLOps инженеров, с использованием технологий Python, Kotlin, TypeScript, Rust и других, для удаленной, гибридной или офисной работы.
• Есть вакансии в сфере облачных технологий и инфраструктуры, такие как Cloud Engineer, SRE и DevOps, с фокусом на AWS, GCP, Azure и управление масштабируемыми системами.
• Несколько ролей связаны с разработкой в нишевых областях: квантовые вычисления, 3D-моделирование, финансовые технологии (алготрейдинг), видеоигры и управление цепочками поставок.
• Предложения включают позиции разного уровня, от начинающих до ведущих инженеров и архитекторов, с вариантами визовой поддержки, релокации и конкурентными зарплатами в диапазоне от $120k до $240k+ в зависимости от опыта и локации.

• Разработчики ищут удалённую работу, многие открыты к релокации, предпочитают гибридный формат или готовы к редким командировкам.
• Основные технологические стеки включают Python, JavaScript/TypeScript, React, Node.js, облачные платформы (AWS, GCP) и контейнеризацию (Docker, Kubernetes).
• Специализации варьируются от full-stack, data engineering и машинного обучения до дизайна продуктов и UX/UI.
• Ключевые интересы: работа с LLM, AI-агентами, компьютерным зрением, распределёнными системами и дизайн-системами.
• Многие кандидаты имеют опыт более 10 лет, опыт построения масштабируемых продуктов и решения сложных бизнес-задач.

В TypeScript-коде Microsoft активно используются устаревшие var вместо современных let и const, несмотря на их проблемы с областью видимости. Это связано с Temporal Dead Zone (TDZ) — зоной, где переменные объявлены, но не инициализированы. При использовании let и const обращение к переменным в TDZ вызывает ошибки, что повышает надёжность, но требует вычислительных ресурсов.

Переход на var в критичных к производительности участках дал TypeScript до 8% ускорения в бенчмарках, поскольку var избегает проверок TDZ. Это демонстрирует компромисс между безопасностью кода и производительностью, особенно в крупных проектах, где даже небольшие оптимизации значимы.

• Обсуждается производительность let/const против var в JavaScript, где var может давать выигрыш до 8% из-за отсутствия проверок TDZ (Temporal Dead Zone).
• Поднимается вопрос о дизайне JS: хоистинг и TDZ считаются проблемными и неочевидными особенностями языка, усложняющими оптимизацию.
• Участники спорят, является ли текущая реализация лексической области видимости в JS "ужасной" или это просто особенность, которую нужно принять.
• Обсуждаются возможные решения: более умный анализ TDZ в движках, трансляция в var на этапе сборки или использование других языков (например, Lua) как примера.
• Затрагивается практический аспект: TypeScript перешел на таргет ES2018+, что неожиданно привело к падению производительности из-за использования let вместо var.

Glide — это форк Firefox с расширяемой архитектурой, ориентированной на клавиатурное управление. Его главная особенность — конфигурация на TypeScript, которая позволяет пользователям настраивать браузер практически без ограничений. Например, можно создавать собственные сочетания клавиш для автоматизации рутинных задач, таких как клонирование репозитория GitHub и открытие его в Neovim, или переключение на вкладку с календарём. Это решает проблемы, характерные для традиционных расширений, которые часто сталкиваются с ограничениями безопасности в Firefox.

Glide заимствует концепцию режимов из Vim, автоматически переключаясь между normal, insert и ignore в зависимости от контекста. Он также поддерживает навигацию с помощью подсказок (hint mode), позволяя управлять элементами страницы без мыши. Ключевые преимущества включают интеграцию с внешними инструментами, сохранение совместимости с расширениями Firefox и возможность тонкой настройки под индивидуальные workflow.

• Пользователи положительно оценивают форк Firefox, отмечая важность альтернативы браузерам на Chromium и наличие компактного режима.
• Обсуждаются технические детали поддержки проекта: интеграция обновлений и исправлений безопасности от Firefox, использование системы патчей.
• Ключевая особенность — ориентация на управление с клавиатуры (vim-подобные привязки), что сравнивается с расширениями Vimium и VimFX.
• Запрашивается возможность гибкой настройки (поддержка dotfiles, установка расширений, кастомизация CSS, дополнительные функции для хинтов).
• Поднимаются вопросы совместимости: работа на внутренних страницах браузера (chrome://), перенос настроек из Firefox и поведение в текстовых полях.

Handy — это бесплатное приложение с открытым исходным кодом для преобразования речи в текст, которое работает локально на вашем компьютере. Оно позволяет диктовать текст в любое поле ввода, просто нажимая и удерживая комбинацию клавиш (по умолчанию Ctrl+Z), а затем вставляя расшифровку после отпускания. Настройки включают переключение между режимом удержания и однократного нажатия для начала и остановки транскрипции.

Приложение полностью приватное — аудио не отправляется в облако, всё обрабатывается на устройстве. Handy позиционируется как доступный инструмент, свободный от подписок, с возможностью кастомизации и поддержкой сообщества через спонсоров like Wordcab и Epicenter. Проект приглашает к участию в разработке и финансировании.

• Пользователи обсуждают высокое потребление ресурсов современных десктопных приложений, приводя примеры, где даже простые действия занимают значительный объем памяти (~120MB).
• Представлены альтернативные и похожие инструменты для преобразования речи в текст (STT), такие как Whispy (Linux), hns (CLI), Gnome расширение и VoiceInk, с акцентом на локальность и минимализм.
• Обсуждаются технические детали проектов: использование моделей Whisper и Parakeet, поддержка GPU/CPU, кроссплатформенность, языки разработки (TypeScript, Rust, Go) и вопросы шумоподавления.
• Участники сравнивают качество и удобство локальных решений с облачными сервисами (например, Groq) и встроенными функциями ОС (macOS dictation, iPhone STT).
• Затрагиваются темы приватности, производительности на слабом железе, удобства использования для программирования и запросы на аналогичные инструменты для преобразования текста в речь (TTS).

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

Lua_u_

Lua_u_ (строчная u, /ˈlu.aʊ/) — это быстрый, компактный, безопасный, постепенно типизированный встраиваемый язык сценариев, основанный на Lua.

Мотивация

Примерно в 2006 году Roblox начал использовать Lua 5.1 в качестве языка сценариев для игр. Со временем мы значительно развили реализацию и язык: для поддержки растущей сложности игр на платформе Roblox, увеличения размеров команд и написания большого объёма кода (более 1 млн строк к 2020 году) нам пришлось инвестировать в производительность, удобство использования, инструменты языка и ввести постепенную систему типов. Подробнее…

Песочница

Luau ограничивает набор стандартных библиотек, доступных пользователям, и реализует дополнительные функции песочницы для возможности запуска непривилегированного кода (написанного разработчиками игр) вместе с привилегированным кодом (нашим). Это создаёт среду выполнения, отличающуюся от традиционной для Lua. Подробнее…

Совместимость

По возможности Luau стремится быть обратно совместимым с Lua 5.1 и одновременно включает функции из более поздних версий Lua. Однако Luau не является полным надмножеством более поздних версий Lua — мы не всегда согласны с решениями Lua и имеем другие варианты использования и ограничения. Все функции Lua после 5.1, а также их статус поддержки в Luau, документированы здесь.

Синтаксис

Luau синтаксически обратно совместим с Lua 5.1 (код, действительный для Lua 5.1, также действителен для Luau); однако мы расширили язык набором синтаксических функций, делающих его более привычным и эргономичным. Синтаксис описан здесь.

Анализ

Для упрощения написания корректного кода Luau включает набор инструментов анализа, которые могут выявлять распространённые ошибки. Они состоят из линтера и проверки типов, интегрированных в исполняемый файл командной строки luau-analyze. Проверки линтера описаны здесь, а руководство по проверке типов можно найти здесь.

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

В дополнение к полностью кастомному фронтенду, реализующему парсинг, линтинг и проверку типов, среда выполнения Luau включает новый байткод, интерпретатор и компилятор, сильно оптимизированные для производительности. Интерпретатор Luau может конкурировать с интерпретатором LuaJIT в зависимости от программы. Также доступен опциональный компонент для ручной JIT-компиляции на платформах x64 и arm64, который может значительно ускорить определённые программы. Мы продолжаем оптимизировать среду выполнения и переписывать её части для ещё большей эффективности. Хотя наша общая цель — минимизировать время, которое программисты тратят на настройку производительности, некоторые детали о характеристиках производительности предоставлены для любознательных.

Библиотеки

Как язык Luau является полным надмножеством Lua 5.1. Что касается стандартной библиотеки, некоторые функции пришлось удалить из встроенных библиотек, а некоторые — добавить; обратитесь к полной документации для подробностей. Когда Luau встраивается в приложение, сценарии обычно получают доступ к дополнительным функциям библиотек, специфичным для приложения.

© 2025 Roblox.

• Переход на Luau обусловлен системой типов, но язык имеет шероховатости и слабую документацию, а сообщество практически отсутствует.
• Luau значительно сложнее и объёмнее стандартного Lua, что связано с реализацией системы типов и дополнительных возможностей.
• Существуют альтернативные реализации и среды выполнения Luau, такие как Lune, предназначенные для использования вне Roblox.
• Сообщество отмечает проблемы обратной совместимости между различными форками Lua (LuaJIT, Luau, PUC Lua), что создаёт фрагментацию.
• Luau сравнивают с Teal, но они fundamentally разные: Teal — это транспилятор, а Luau — полноценный форк Lua с собственной средой выполнения.
• Разработчики Roblox работают над улучшением поддержки Luau вне своей платформы, включая создание standalone-рантаймов.
• Несмотря на критику, инженерные решения в Luau, особенно в области производительности, оцениваются как впечатляющие.

Система плагинов

Система плагинов позволяет расширять функциональность IINA с помощью JavaScript. Вы можете управлять воспроизведением, вызывать API mpv, получать доступ к сети и файловой системе, добавлять пользовательские элементы интерфейса и многое другое. Система плагинов доступна в IINA версии 1.4.0.

Простой API, мощные возможности

Несколькими строками кода можно реализовать функции, точно соответствующие вашим потребностям. С помощью официального плагина User Scripts можно просто копировать и вставлять фрагменты кода в IINA без написания пакетов плагинов.

Примеры кода:

• Отображение названия видео крупным шрифтом поверх видео
• Сворачивание окна при паузе и возобновление при восстановлении

Возможности системы плагинов

• Ядро: Управление воспроизведением и получение/установка статусов
• MPV: Доступ к API mpv для расширенного контроля
• События: Регистрация обработчиков событий IINA и mpv
• HTTP: Выполнение HTTP и XMLRPC запросов
• Плейлист: Управление плейлистом и добавление пунктов меню
• Субтитры: Регистрация загрузчиков субтитров
• Меню: Добавление пунктов меню с горячими клавишами
• Оверлей: Отображение веб-контента поверх видео
• Боковая панель: Добавление вкладок с пользовательским содержимым
• Отдельные окна: Создание окон со сложным интерфейсом
• Глобальный контроллер: Управление несколькими экземплярами плеера
• Файлы: Доступ к файловой системе и временным файлам
• Настройки: Хранение предпочтений и страниц настроек
• Утилиты: Системные диалоги и запуск исполняемых файлов
• Консоль: Логи для отладки

Начало работы

Вместе с IINA поставляется инструмент командной строки iina-plugin для создания, сборки и запуска плагинов. Полная документация с руководствами и ссылками на API доступна на docs.iina.io.

Полезные ресурсы:

• Официальный плагин User Scripts
• Определения TypeScript для API плагинов

• IINA позиционируется как современный, незаметно работающий медиаплеер для macOS, который многие пользователи воспринимают как часть операционной системы.
• Плеер является графическим фронтендом для mpv, поддерживает множество форматов, удобное управление с клавиатуры и гармонично вписывается в среду macOS.
• Обсуждаются возможности новой плагинной архитектуры на Lua/JS, которая позволяет создавать интерактивные дополнения, например, визуализации или веб-окна.
• Некоторые пользователи отмечают проблемы с воспроизведением контента через Online Media плагин и предпочитают использовать yt-dlp для загрузки видео.
• В сравнении с другими плеерами (VLC, Infuse) IINA хвалят за простоту и дизайн, но критикуют за некорректное управление цветом (HDR) и высокое энергопотребление в прошлом.
• Часть пользователей не видит compelling-причин переходить на IINA с встроенных плееров или VLC, так как те уже справляются с большинством задач.
• Infuse 8 упоминается как мощная альтернатива для экосистемы Apple из-за синхронизации по iCloud и работы с сетевыми ресурсами.
• Поднимается вопрос архитектурных компромиссов при создании плагинных систем: тесно связанные плагины против слабосвязанных out-of-process решений.

Делай вклад в цифровые общественные блага

Помоги проектам, которые борются с климатом, голодом и прочими глобальными задачами. Ниже — готовые к первому PR репозитории.

Проект	Язык	Направление
mautic	PHP	маркетинг-автоматизация
credebl	TypeScript	децентрализованная идентичность
avni-webapp	JavaScript	медицинские данные
the-turing-way	TeX	воспроизводимая наука
X-Road	Java	обмен данными между госорганами
OpenTermsArchive	JavaScript	прозрачность сервисов
OpenFn Lightning	Elixir	автоматизация workflow
android-fhir	Kotlin	мобильная медицина
casa	Ruby	волонтёрство для детей
ODK Collect	Kotlin	сбор данных в поле
cht-core	JavaScript	цифровое здравоохранение
policyengine-app	Jupyter	расчёт последствий политик
querido-diario	Python	открытые госгазеты
ODK Central	JavaScript	сервер для форм
decidim	Ruby	участие граждан

Фильтр по языку и Целям устойчивого развития (SDG) на сайте.

• Участники приветствуют инициативу списка проектов с «good first issue», но сомневаются в кураторстве: много проектов без активных задач, не все связаны с социальным влиянием.
• Предложено скрывать репозитории с 0 issues и добавлять метрики активности (коммиты, разработчики, возраст), как в Re-Decentralise.
• Новички спрашивают, считать ли правку опечаток «настоящим» вкладом; большинство советует упоминать, но честно указывать уровень участия.

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

Что внутри

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

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

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

Асинхронное программирование 2.0
Автор: Ankur Goyal, 19 авг 2025

Я перестал писать код руками. Описываю задачу — агент пишет TypeScript/Rust/Python, тесты и коммитит. Я возвращаюсь только на ревью. Это не «вайб-кодинг», а новый цикл: чётко определяю → делегирую → проверяю.

Как работает

1. ТЗ как код: «снизить задержку поиска с 800 до 200 мс, убрав аллокацию в цикле».
2. Автопроверка: юнит- и интегра-тесты, типы, бенчи, линтеры — всё в CI.
3. Жёсткое ревью: агенты ошибаются, поэтому читаю PR дольше, чем писал раньше.

Плюсы

• Параллельно веду 4–5 задач: одну в фокусе, остальные в фоне.
• Система всё равно моя: архитектура и решения остаются моими.

Braintrust
Собственный агент Loop принимает описание eval-задачи и в фоне улучшает промпты, датасеты и скоры.

• «Async programming» в статье — это не про async/await, а про делегацию коду ИИ-агентам; название вызывает путаницу и споры.
• Ключевой шаг — чётко описать задачу; критики считают это самым трудным и редким навыком.
• Опасения: атрофия собственных навыков, взрыв технического долга, потеря удовольствия от программирования.
• Сторонники отмечают высокую скорость итераций и полезность ИИ для «скучного» кода (тесты, скрипты).
• Опыт офшоринга показывает: без точных спеков результат — задержки и недопонимание; ИИ ускоряет получение «среднего» кода, но не решает проблему спецификаций.

Vicinae — минималистичный лаунчер для ПК:

• нативный, быстрый, расширяемый
• Rust + Tauri
• плагины на JS/TS
• MIT

• Пользователи в восторге: Vicinae — качественный лончер-аналог Raycast для Linux, лёгкий в установке и работе на i3, Hyprland и др.
• Основной плюс — совместимость с расширениями Raycast, но часть из них пока не работает (например, raindrop.io).
• Разработчик планирует улучшить поддержку расширений, добавить ресайз окна и порт под macOS ARM.
• Проект открыт к контрибуциям, но слияние с другим форком маловероятно из-за разных стеков.

Алгебраические эффекты на практике в Flix

Алгебраические эффекты — уже не академия. Это рабочий инструмент, который сегодня делает код:

1. Тестируемым — «что» отделено от «как»; mock-и и DI не нужны.
2. Прозрачным — сигнатура функции сразу показывает все побочные действия (IO, сеть, исключения).
3. Гибким — async/await, корутины, backtracking реализуются обычными библиотеками, без изменения языка.

В отличие от монад, эффекты понятны без теории категорий и работают «из коробки» в языке Flix.

---

Мотивирующий пример

Без эффектов:

def calculateSalary(base, percent) -> float:
    # может отправить письмо бабушке

С эффектами (Flix):

def calculateSalary(base: Float64, percent: Float64): Float64 \ {Email} =
    ...

Сигнатура не лжёт: любой вызов Email будет отслежен компилятором.

---

Обработчики эффектов (интуиция)

Эффект = операция + обработчик.
Код бросает операцию, обработчик решает, что с ней делать.

eff Ask {                     // объявляем эффект
    pub def ask(): String
}

def greet(): String \ Ask =   // используем
    "Hello " + Ask.ask()

def main(): Unit =            // обрабатываем
    println(greet() with Ask {
        def ask() = "World"
    })

---

Реальный проект: рекомендательная система фильмов

Задача: достать данные из SQLite, вызвать внешний AI-сервис, кешировать результат, логировать.

Эффекты: Db, Http, Log, Cache.

def recommend(user: String): List[Movie] \ {Db, Http, Log, Cache} = 
    Cache.getOrElse(user, 
        for {
            prefs <- Db.query(user)
            _     <- Log.info("Prefs loaded")
            recs  <- Http.post("ai.example.com", prefs)
            _     <- Log.info("AI answered")
            _     <- Cache.put(user, recs)
        } yield recs)

Тест: подменяем обработчики на in-memory реализации — никаких реальных запросов.

---

Куда дальше

• Попробовать онлайн: https://play.flix.dev
• Документация: https://doc.flix.dev
• Репозиторий: https://github.com/flix/flix

Flix ещё молод, но уже поддерживает эффекты, регионы, структурную конкурентность и Datalog.

• Участники восторгаются идеей алгебраических эффектов: они проще монад, решают «цветную» проблему функций и позволяют гибко компоновать побочные эффекты.
• Примеры уже есть: экспериментальная реализация в OCaml 5, библиотеки Effect и Effectively для TypeScript, языки Koka, Effekt, Unison.
• Отличие от ОО-интерфейсов: эффекты явно указывают контекстные требования (Net, IO) и позволяют подменять реализацию динамически, а не статически.
• Критика: система всё равно «окрашивает» код, требует прокидывать эффекты через весь стек вызовов и пока выглядит академично/громоздко.
• Практические вопросы: как скрыть «дебажный» вывод, не нарушая типов, и можно ли обойтись без переписывания сигнатур каждой промежуточной функции.

• "строка" – ищет фразу целиком, без учёта регистра
• from:ник – посты конкретного автора
• lang:код – фильтр по языку (en, ru…)
• #тег – по хэштегу
• условие условие – логическое И
• условие OR условие – логическое ИЛИ
• ( ) – группировка

• Спор о «парсинге, а не валидации»: кто-то пишет собственные проверки, кто-то берёт готовые библиотеки (Zod, Clap, argparse, docopt, yargs и др.).
• Rust/PowerShell/argparse хвалят за строгие типы и понятные ошибки; JS/TS-рантайм критикуют за лишние зависимости.
• Проблема: как сообщить сразу ВСЕ ошибки, а не падать на первой; как выдавать человекочитаемые сообщения.
• «Непредставимые состояния» хороши в ядре программы, но на границе ввода нужны гибкие структуры и recovery.
• CLI ≠ API: парсим только синтаксис, доменные ограничения уносят глубже; иначе получаем перегруженный интерфейс.

• Lit — простая, быстрая библиотека для Web Components
• Bluesky: lit.dev

---

Основные плюсы

• Simple
  Минимум шаблонного кода: реактивность, декларативные шаблоны, продуманные фичи.

• Fast
  ≈ 5 КБ (сжато), рендер только изменённых частей, без виртуального DOM.

• Web Components
  Нативные кастом-элементы работают в любом фреймворке и без него.

---

Мини-пример

import {html, css, LitElement} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
  static styles = css`p { color: blue }`;
  @property() name = 'Somebody';
  render() {
    return html`<p>Hello, ${this.name}!</p>`;
  }
}

<simple-greeting name="World"></simple-greeting>

Попробовать в Playground

---

Возможности

• Custom Elements — встраиваются как обычные теги.
• Scoped styles — Shadow DOM изолирует CSS.
• Reactive properties — автоматический перерендер при изменении.
• Declarative templates — нативные литералы, без компиляции.

---

Что строят на Lit

• Shareable Components — капсулы для любого стека.
• Design Systems — единые компоненты под разные фреймворки.
• Sites & Apps — постепенное улучшение или полные приложения.

---

Кто использует

Adobe Spectrum, Alaska Auro, Cisco Momentum, Home Assistant, IBM Carbon, Lion, Pharos, PWA Starter, SAP UI5, Shoelace, Hilla, Clarity, Wired Elements и др.

---

Учимся и общаемся

• Туториалы
• Playground
• Документация
• Get started

• Кто-то рад избавиться от Lit, считая его лишним слоем; другие называют «недооценённой» и «лучшей абстракцией» над Web Components.
• Пользователи хвалят маленький размер, отсутствие бойлерплейта и лёгкость внедрения в legacy-проекты, но жалуются на shadow DOM (проблемы a11y, стили) и отсутствие SSR.
• Некоторые вообще отказались от фреймворков и пишут «сырые» web-компоненты, считая, что Lit лишний.
• Вопросы к мейнтейнеру: SSR, реактивность свойств, взаимодействие со сторонними компонентами, работа без бандлера.

Next.js выводит из себя

Наконец-то написал пост: злость лучший мотиватор.
В $COMPANY упал сервис на Next.js, а логов в проде нет. Задача — добавить логирование.

Middleware
Дока обещает: «Middleware выполняется до рендера, удобно для логов».
Пробуем pino + AsyncLocalStorage:

// middleware.ts
export async function middleware(req: NextRequest) {
  LoggerStorage.enterWith(requestLogger());
  logger()?.debug({ url: req.url }, "start");
  return NextResponse.next();
}

Запускаем — логи летят в браузер. Почему? Runtime по умолчанию edge. Меняем на nodejs — в новом проекте работает, в боевом нет.

Страницы и layouts
Пишем в компоненте:

logger()?.info("from page");

Тишина. logger() возвращает null: рендер и middleware живут в разных async-контекстах.

Решение
Передаём requestId через заголовки:

// middleware.ts
const id = crypto.randomUUID();
loggerInstance.child({ requestId: id }).debug("start");
return NextResponse.next({ headers: { "x-request-id": id } });

// page.tsx
const id = headers().get("x-request-id");
loggerInstance.child({ requestId: id }).info("from page");

Итог: чтобы просто логировать, нужно городить костыли через заголовки.

• Пользователи жалуются на игнорирование сотен старых issue, перегруженность абстракциями и постоянные «канареечные» решения, которые не доходят до продакшена.
• Сообщество считает Next.js «самой худшей» технологией: сложно понять, где выполняется код, нельзя цепочкой middleware, а апи-шлюзы выглядят «как будто их писали выпускники буткемпа».
• Разработчики предлагают уходить на Remix, React Router v7, Nuxt, SolidStart, Deno Fresh или даже «чистый HTML/CSS» ради простоты и контроля.
• Представитель Vercel признаёт DX-проблемы и обещает улучшения, но многие уже мигрируют на Vite или Django/Rails/Phoenix.

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 в безопасности и рефакторинге особенно заметно на больших проектах, но язык требует времени на изучение и не всегда лучше «классических» статически типизированных альтернатив.

Trace — полный путь одного запроса через все сервисы.
Span — отдельный шаг в этом пути (функция, SQL, HTTP-вызов).
Root span — первый span (обычно входящий HTTP-запрос).
Child span — вложенный шаг.
Context — передаёт trace_id и текущий span по асинхронным вызовам.
Sampler — решает, записывать ли трассировку.
Exporter — отправляет spans в OneUptime, Jaeger и т.д.

---

Структура span

• name — короткое имя операции
• start/end time — длительность
• status — OK / ERROR
• attributes — произвольные метки (user_id, db.table)
• events — точки во времени (exception, cache hit)
• links — связи с другими traces

---

Быстрый старт в Node.js / TypeScript

npm i @opentelemetry/api @opentelemetry/sdk-node \
      @opentelemetry/auto-instrumentations-node

// tracing.ts
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  serviceName: 'my-api',
  traceExporter: new OTLPTraceExporter({ url: 'https://otlp.oneuptime.com' }),
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

---

Ручная инструментация

import { trace } from '@opentelemetry/api';
const tracer = trace.getTracer('my-service');

async function getUser(id: string) {
  return tracer.startActiveSpan('db.users.findById', async (span) => {
    span.setAttributes({ 'db.table': 'users', 'user.id': id });
    try {
      const user = await db.users.findById(id);
      span.setStatus({ code: SpanStatusCode.OK });
      return user;
    } catch (e) {
      span.recordException(e);
      span.setStatus({ code: SpanStatusCode.ERROR, message: e.message });
      throw e;
    } finally {
      span.end();
    }
  });
}

---

Express/Fastify middleware

import { trace } from '@opentelemetry/api';

export function traceMiddleware(req, res, next) {
  const span = trace.getTracer('http').startSpan(`${req.method} ${req.route?.path || req.url}`);
  trace.getActiveContext().with(trace.setSpan(trace.getActiveContext(), span), () => {
    res.on('finish', () => {
      span.setAttributes({
        'http.status_code': res.statusCode,
        'http.method': req.method,
        'http.route': req.route?.path,
      });
      span.end();
    });
    next();
  });
}

---

Практические советы

• Именование: verb noun (GET /users, db.users.insert).
• Атрибуты: добавляйте user.id, order.id, region.
• Ошибки: span.recordException(err) + span.setStatus({code: ERROR}).
• Sampling: head-based (решение на старте) или tail-based (после завершения).
• Антипаттерны: слишком мелкие spans, отсутствие span.end(), захардкоженные ID.

---

Сборка всего вместе

1. Запустите SDK на старте приложения.
2. Добавьте auto-instrumentations (http, express, pg, redis).
3. Дополните ручными spans для критичных операций.
4. Отправляйте traces в OneUptime → исследуйте flame-графы, ищите узкие места.

• OTEL хвалят как стандарт, но реальные реализации сильно разнятся между вендорами и часто усложняют жизнь.
• Базовые понятия: span — это интервал работы с уникальным ID и ссылкой на родителя, trace — DAG спанов, рассказывающий историю запроса.
• Авто-инструментация почти даром даёт данные для JVM-приложений, но вне веб-бэкендов примеров мало и приходится искать «правильный» подмножество.
• Некоторые жалуются на объём кода и хранилище (десятки ТБ трейсов за неделю), другие считают это разовой настройкой и платой за прозрачность системы.
• Появляются упрощающие обёртки (Logfire, otelize) и примеры интеграции, но документация по дашбордам Grafana всё ещё вызывает трудности.

Перешёл в компанию, где стек — 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 — это ностальгия, а промышленность требует стабильности и инструментов, которые дают статические языки.
• Общий вывод: выбор языка всё чаще диктуется экосистемой, инструментами и личными приоритетами, а не чистой «красотой» синтаксиса.

Добро пожаловать!
Интерактивный гид по деталям велосипеда.

Если картинки не появились — они ещё грузятся.
Без JS или со скрин-ридером изображения не покажутся, но описания и код доступны: bike.ts. Подробности о проекте — здесь.

• Медленное посимвольное появление текста раздражает большинство; автор уже отключил анимацию.
• Просят добавить «показать всё сразу» или хотя бы построчный вывод, а также разрешить выделение текста.
• Контенту не хватает ключевых деталей: каретки, совместимости втулок, стандартов ISO-размеров колёс.
• Часть советов — сделать навигацию (хлебные крошки, ссылки) и улучшить CTA-кнопку.
• Несмотря на критику, многие хвалят эстетику и видят в проекте вдохновляющий пример «passion project».

Материализованные представления очевидно полезны

Разработчики постоянно перетасовывают данные между системами и форматами.
Возьмём таск-трекер: нужно показывать количество задач в каждом проекте. Сначала всё просто:

const getTaskCountForProject = (id) =>
  db.query('select count(1) from tasks where project_id = $1', [id]);

Скорость не устраивает → добавляем Redis-кеш:

const getTaskCountForProject = async (id) => {
  const key = `project:${id}:task-count`;
  let cnt = await redis.get(key);
  if (cnt !== null) return +cnt;
  cnt = await db.query('select count(1) ...', [id]);
  await redis.set(key, cnt, { ex: 3600 });
  return cnt;
};

Пользователи жалуются: счётчик устаревает. Приходится чистить кеш при каждом insert/delete.
Делаем инкрементальные обновления:

await redis.incr(`project:${id}:task-count`);

Но если сервер упадёт между записью в БД и Redis, счётчик сломается навсегда.
Переносим счётчик в ту же БД и обновляем в транзакции, либо пишем триггер — логика в БД снова в моде.

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

• Пост хвалят за честность, но автор не уточняет СУБД, хотя SQL выглядит как Postgres.
• Postgres-материализованные представления требуют ручного REFRESH; авто-обновления дают коммерческие продукты (Materialize, Snowflake, MSSQL, ReadySet, Feldera, RisingWave) и расширение pg_ivm.
• Convex, Zero и др. используют инкрементное обслуживание представлений (IVM) «под капотом».
• Счётчики через COUNT(*) без IVM не масштабируются; кто-то предлагает денормализацию и триггеры, кто-то — индексы по FK.
• ScyllaDB-материализованные представления считаются багованными; важно понимать конкретную реализацию.

Rust — это язык с жёсткой внутренней связностью.
Он не сложен из-за плохой документации, а потому что его концепты переплетены: замыкания, трейты, заимствование, Send/Sync, итераторы и прочие вещи нужны сразу. Поняв их, вы получаете мощный и последовательный инструмент.

Мини-пример.
20 строк кода на Rust, отслеживающие изменения файлов:

use notify::{Watcher, RecursiveMode};
fn main() -> Result<(), notify::Error> {
    let mut w = notify::recommended_watcher(|r| {
        if let Ok(e) = r {
            println!("{:?} {:?}", e.kind, e.paths);
        }
    })?;
    ["pages", "templates", "static"].iter()
        .try_for_each(|p| w.watch(p.into(), RecursiveMode::Recursive))?;
    loop { std::thread::park(); }
}

Даже здесь нужно знать: Result, замыкания, итераторы, трейты Display, 'static, Send.
На JavaScript то же заняло бы 5 строк и не потребовало бы ни трейтов, ни заимствований.

Вывод.
Внутри Rust прячется «меньший, чище» язык с ясным видением: безопасность без сборщика мусора, абстракции без потерь, композиция через трейты. Этот язык появляется, когда все части складываются в единую картину.

• JS-пример из поста содержит несколько багов (null-файл, for-in вместо for-of), которые TypeScript не всегда ловит.
• Автору ставят в вину, что он «забыл» упомянуть async/await, Promise, модули и прочие скрытые концепции JS.
• Комментаторы спорят, можно ли выкинуть из Rust «половину» фич и остаться при этом «малым и чистым»; большинство считает, что нет.
• Многие советуют новичкам не начинать с Rust: компилятор будет целыми днями выдавать ошибки, прежде чем программа запустится.
• Несколько человек упоминают Gleam, Zig и Austral как «упрощённые» альтернативы, но подчёркивают, что это уже другие языки.

AGENTS.md — открытый формат инструкций для AI-агентов, используется >20k проектов.
Это «README для агентов»: единое место для команд сборки, тестов, стиля кода и прочих деталей, которые не нужны людям, но критичны для ИИ.

## Команды
- `pnpm i` — зависимости  
- `pnpm dev` — запуск  
- `pnpm test` — тесты  

## Стиль
TypeScript strict, одинарные кавычки, без точек с запятой, функциональный стиль.

Зачем отдельный файл?

• README — для людей, AGENTS.md — для агентов.
• Не загромождает документацию.
• Один формат подходит всем: Codex, Amp, Jules, Cursor, Factory, RooCode и др.

Как использовать

1. Создайте AGENTS.md в корне.
2. Добавьте: обзор проекта, команды сборки/тестов, стиль, security, правила PR.
3. В монорепозиториях кладите отдельные файлы в каждый пакет; агент читает ближайший.

Примеры

• openai/codex
• apache/airflow
• temporalio/sdk-java
• PlutoLang/Pluto

Ещё 20k примеров

• Участники спорят, нужен ли отдельный AGENTS.md или достаточно README/CONTRIBUTING.
• Одни считают файл полезной «эргономичной ручкой» — люди охотнее пишут инструкции для ИИ, чем для людей.
• Другие критикуют: это не формат, а просто соглашение; нет импортов, иерархии, стандарта между агентами.
• Практики варьируются: кто-то хранит роль-файлы в .agent, кто-то делает симлинки на CLAUDE.md, кто-то использует .agdocs/guides/.
• Общий вывод: AGENTS.md пока временный костыль, пока ИИ не научится полноценно читать человеческую документацию.

Reality Defender API
Два вызова кода — и ваша система получает признанные наградами модели для обнаружения дипфейков. Бесплатный тариф: 50 проверок аудио/изображений в месяц.

Почему Reality Defender API

• Простота — загрузка файла и получение результата.
• Гибкость — SDK на Python, TypeScript, Java, Go, Rust.
• Прозрачность — исходники открыты.
• Доступность — 50 сканов/мес без карты.

Тарифы

План	Цена	Включено
Free	$0	50 сканов/мес, аудио+изображение, 1 пользователь
Growth	от $399/мес	50+ сканов, аудио+изображение+видео, чат
Enterprise	по запросу	неограниченный объём, мультисид, видео+текст, стриминг, интеграции Zoom/Teams/Webex, расширение Chrome, персональная поддержка

Где применять

• Верификация личности (KYC, безопасный доступ)
• Мошенничество (имперсонация, соц-инженерия)
• Модерация контента
• Анализ СМИ и факт-чекинг
• Исследования и тесты

Поддерживаемые форматы

Аудио (до 100 МБ, 12 с – 5 мин): wav, flac, mp3, m4a, aac, ogg, opus; 8 языков.
Изображения (до 10 МБ): jpg, jpeg, png, gif, webp.
Видео (до 250 МБ): mp4, mov; аудио как выше.

Начать бесплатно | Документация SDK

• Участники сомневаются в надёжности «детекторов ИИ» и предсказывают бесконечную «кошку-мышь» между генераторами и детекторами.
• Предлагают альтернативу: криптографическую подпись контента, но признают, что добровольные стандарты легко обходятся.
• Основатели Reality Defender отвечают: ансамбль моделей выдаёт лишь вероятность 1-99 %, API закрыт, таргетинг по паттернам и лимит 50 бесплатных сканов мешают злоупотреблениям.
• Уже используется крупными банками и корпорациями для проверки подлинности медиа и документов.

Node.js v22.18.0 LTS
31 июля 2025

Главное

• TypeScript без конфигурации
  .ts файлы запускаются напрямую:

  echo 'const foo: string = "World"; console.log(`Hello ${foo}!`);' > file.ts
  node file.ts   # → Hello World!
  

  Ограничения описаны здесь. Отключить: --no-experimental-strip-types.

Ещё важное

• amaro обновлён до 1.1.0
• import.meta.main в ESM
• fs лучше справляется с всплесками событий через AsyncIterator
• permission передаёт флаги модели разрешений при spawn
• sqlite поддерживает readBigInts на уровне соединения
• url добавлен fileURLToPathBuffer
• watch новый флаг --watch-kill-signal
• Worker стал асинхронно disposable

Другое

• npm 10.9.3, sqlite 3.50.2, обновления minimatch, acorn, googletest
• мелкие исправления в crypto, build, assert и др.

• Node.js теперь умеет запускать .ts-файлы «из коробки», вырезая типы без транспиляции, но поддерживает лишь подмножество TS (без enum и т.п.).
• Новая возможность не распространяется на node_modules, что вызывает вопросы о библиотеках и приватных пакетах.
• Многие радуются упрощённому DX, но часть пользователей уже сталкивается с ошибками обновления из-за ограниченного набора фич.
• Критики считают, что Bun и Deno давно решают эти задачи лучше и быстрее, однако Node остаётся «де-факто» стандартом.
• Итог: шаг вперёд для Node, но полноценная замена tsc/Bun пока невозможна; выбор рантайма по-прежнему зависит от проекта.

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 — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.

• Выбор хранилища метаданных рабочих процессов оказался ключевым. Нужно было простое: чекпойнт состояния и восстановление после сбоя. Postgres выбрали за технические возможности, а не только за популярность и 40-летнюю проверку временем.

• Масштабируемые очереди
  Классическая таблица-очередь страдает от конкуренции: все воркеры пытаются взять одни и те же задачи. Postgres решает это через FOR UPDATE SKIP LOCKED: строки блокируются и пропускаются, если уже захвачены. Воркеры без конфликтов берут следующие N записей, позволяя обрабатывать десятки тысяч задач в секунду.

• Наблюдаемость
  Каждый шаг сохраняется, поэтому можно строить дашборды и фильтры. SQL позволяет писать сложные запросы напрямую; индексы по created_at, executor_id, status ускоряют выборки из миллионов записей без лишних затрат.

• Exactly-once для шагов с БД
  Обычно гарантируется «по крайней мере один раз», но если шаг меняет данные в той же транзакции, что и чекпойнт, Postgres обеспечит, что изменения зафиксируются ровно один раз даже после перезапуска.

• Пользователи хвалят DBOS за простоту миграции с graphile-worker и отсутствие необходимости менять инфраструктуру.
• Сравнения с Temporal, Azure Durable Functions, Inngest, Restate и Cloudflare: DBOS выглядит проще и легче, но Temporal/Cloudflare критикуют за сложность самостоятельного хостинга и высокую цену.
• Некоторые жалуются, что «сервер» DBOS (Conductor) не open-source, что ограничивает самостоятельное развёртывание.
• Планы по добавлению Java, C#, Go и поддержке сообщества уже анонсированы; Python и TypeScript уже поддерживаются.
• Отмечена возможность комбинировать DBOS с Dagster/Oban/pgflow для более сложной оркестрации.

Задача: перенести 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 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

• Introducing GPT-5 — YouTube

• Пропустить навигацию

• Поиск / Поиск голосом

• Войти

• Смотреть позже • Поделиться • Копировать ссылку • Покупки

• Нажмите, чтобы включить звук • 2x

• Если воспроизведение не началось, перезапустите устройство.

• Вы вышли из аккаунта. Просмотры могут влиять на рекомендации на ТВ. Чтобы избежать этого, отмените и войдите на YouTube на компьютере.

• Отмена • Подтвердить

• 37:35 • 7 августа, 10:00 GMT-7

• Далее • Прямой эфир запланирован • Играть

Introducing GPT-5

• OpenAI • Подтверждено • 1,65 млн подписчиков
• Подписаться • Подписаны
• 6 522 ожидают • Запланировано на 7 авг. 2025
• 1K • Поделиться • Скачать • Сохранить
• Комментарии отключены

Описание

• Introducing GPT-5

• Присоединяйтесь к Сэму Альтману, Грегу Брокману, Себастьену Бюбеку, Марку Чену, Янну Дюбуа, Брайану Фиоке, Ади Ганешу, Оливеру Годеману, Саачи Джайн, Кристине Каплан, Тине Ким, Элейн Я Ле, Фелипе Миллону, Мишель Покрасс, Якубу Пахоцки, Максу Шварцеру, Ренни Сонгу, Жожену Вану — они представят и продемонстрируют GPT‑5.

• OpenAI: Видео • О канале • Twitter • LinkedIn

• Участники обсуждают качество ИИ для повседневного программирования: один отмечает сильное превосходство Anthropic (Sonnet 3.7/4 и Claude Code), причём в Cursor опыт хуже, чем в самом Claude Code, и OpenAI‑модели он почти не использует.
• Есть надежда, что GPT‑5 сократит отставание OpenAI, хотя мнения пользователей сильно расходятся.
• Другой комментатор ожидает, что грядущие анонсы покажут радикальное влияние на рынок: веб‑ и JS/TS‑разработчики могут стать частично или полностью невостребованными.
• При этом подчёркивается, что речь ещё не об «AGI» — максимум о ~10% от обещанных возможностей AGI.
• Отмечается ночной «слив», указывающий на фокус на кодинге; предполагается, что для названия «GPT‑5» OpenAI должен предложить существенное преимущество над Anthropic.

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

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

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

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

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

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

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

Простой компилятор TypeScript для вычисления выражений с пометкой comptime на этапе сборки. Полезно для переноса вычислений из рантайма в компиляцию. Вдохновлено Bun macros и Zig comptime.

Внимание: вы сами отвечаете за безопасность выражений, вычисляемых на этапе компиляции. Изоляции нет. Импорты comptime допускаются только в файлах проекта (не в node_modules), но можно импортировать из node_modules как comptime.

Содержание

• Что такое comptime.ts?
• Примеры: 1) простая сумма; 2) CSS без рантайма; 3) константы во время сборки
• Установка
• Использование: Vite, Bun, CLI, API
• Принудительная оценка и промисы, отказ от «вирусности»
• Запуск кода после comptime, как работает, ограничения, практики, отладка, поддержка, лицензия

Что это comptime.ts вычисляет выражения при компиляции, сокращая работу в рантайме.

Примеры

1. Простая сумма import { sum } from "./sum.ts" with { type: "comptime" }; console.log(sum(1, 2)); // => console.log(3);

2. Emotion CSS без рантайма import { css } from "@emotion/css" with { type: "comptime" }; const style = csscolor: red; font-size: 16px;; div({ class: style }); // => const style = "css-x2wxma"; div({ class: style });

Примечание: импорт @emotion/css удаляется. Стили нужно вывести отдельно (после comptime или плагином бандлера).

1. Константы на этапе сборки import { ms } from "ms" with { type: "comptime" }; const HOUR = ms("1 hour"); // => const HOUR = 3600000;

Поддерживаются многие выражения (включая индексацию и импортированные константы), результат должен быть сериализуем в JSON. Импорты с type: "comptime" удаляются; лишнее убирает ваш бандлер.

Установка bun add comptime.ts pnpm add comptime.ts npm install comptime.ts

Использование

• Vite: import { comptime } from "comptime.ts/vite"; export default defineConfig({ plugins: [comptime()] });

Только в прод-сборке, если поведение совпадает с рантаймом: export default defineConfig({ build: { rollupOptions: { plugins: [comptime()] } } });

• Bun: import { comptime } from "comptime.ts/bun"; await Bun.build({ entrypoints: ["./index.ts"], ou ... })

• Обсуждение крутится вокруг идеи “comptime”/макросов в JS: часть хочет Rust‑подобные макросы и proc‑макросы (вплоть до JSX как jsx! или вообще писать фронт на Rust/wasm), другая сторона категорически против макросов в TS/JS.
• Есть путаница в терминах: “макросы” vs “comptime”; участники критикуют переиспользование терминов и вспоминают неудачный опыт sweet.js.
• Практические вопросы: можно ли делать агрессивный dead‑code elimination через if (comptime …) как в C препроцессоре? Ответ: само comptime подставит true/false, но для выкидывания веток нужен отдельный шаг минификатора/бандлера (Vite/Bun поддержат).
• Дискуссия об импорте with { type: 'comptime' }: одни считают это неправильным использованием атрибута type (ожидается соответствие MIME), другие указывают, что спецификация оставляет семантику type открытой.
• Обсуждают границы возможности: поддержка типов/генериков на уровне comptime (как в Zig) пока ограничена; возврат именованных функций и сложные случаи с замыканиями не поддерживаются из‑за требований к гарантиям и сохранению функций между процессами.
• Альтернативы: настроить сборку для JSX без макросов; использовать библиотеки вроде lite-jsx; для Rust‑фронта рекомендуют Dioxus/Leptos; спорят о реальной применимости wasm и памяти/управления ей в вебе.
• Применимость: идея удобна для предсборки (например, markdown) и константной подстановки, но не заменяет полноценных препроцессоров/макросистем уровня Rust/Zig.