Hacker News Digest

Современные терминалы ограничены решениями, принятыми ещё в 1980-х, и состоят из четырёх компонентов: эмулятора терминала, псевдотерминала (PTY), оболочки (shell) и запускаемых программ. Автор отмечает, что внутренняя структура терминалов — это "куча", где многие решения невозможно изменить из-за исторического наследия. В качестве примера приводится цитата Джулии Эванс: "Внутренности терминалов — это беспорядок. Большая часть этого именно такая, потому что так кто-то решил в 80-х, и теперь это невозможно изменить".

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

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

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.

MCP: случайно-универсальная система плагинов

USB-C оказался не только для зарядки и файлов, а ещё для всего, что влезет в разъём. Друг подключил тостер к монитору — и теперь тост выводится по HDMI.

То же самое с MCP (Model Context Protocol). В документации написано: «стандартизированный способ подключать ИИ-модели к данным и инструментам». Уберём слово «ИИ» — получаем универсальный разъём, куда можно подцепить что угодно.

Как автомобильная «прикуриватель-розетка» 1952 года сегодня питает телефоны и мини-печки, MCP может связывать календарь с доставкой еды, базы данных с кофеварками, Git-репозитории с умными лампочками. Протокол не осуждает ваши решения.

Параллель: когда в NFT вместо ссылки на картинку вставили саму картинку в base64, технология стала делать то, что не планировалась.

Итог: MCP — это USB-C для приложений. Пока все думают, что он «для ИИ», он уже работает как универсальный адаптер между любыми сервисами.

• MCP воспринимается как «Web 2.0-2»: повторное открытие мэшапов и RPC-вызовов, но в формате JSON-RPC для LLM.
• Главная ценность — простые, узкие API, которые даже «средний» LLM может вызвать без ошибок.
• Критика: серверы жрут контекст, не хватает инженерии под реальные потоки LLM, безопасность и спам по trust-модели 1995-го.
• Сторонники считают, что MCP — это удобный «универсальный разъём» между сервисами, независимо от наличия ИИ.
• Скептики: это временный костыль, пока LLM не научатся работать с обычными REST/OpenAPI; скоро компании закроют «дыру».

MCP игнорирует 40 лет опыта RPC и обрекает компании на сбои

Проблема
Model Context Protocol (MCP) позиционируется как «USB-C для ИИ», но жертвует надежностью ради простоты. Компании внедряют его в продакшен, не осознавая, что в основе лежит архитектура без базовых механизмов, которые считаются обязательными в RPC-системах с 1982 г.

4 пропущенных урока

1. Типы данных
   UNIX RPC (1982) ввёл XDR и IDL, чтобы 32-битное целое не превратилось в мусор на другой архитектуре. MCP использует схематичный JSON: проверка типов происходит в рантайме, если вообще происходит. В результате ИИ-трейдер может ошибиться в десятичном разряде, а медицинский ассистент — перепутать дозировку.

2. Кросс-языковая совместимость
   CORBA (1991) генерировала привязки под C++, Java, Python и т. д., гарантируя, что исключение на сервере корректно обработается клиентом. MCP оставляет реализацию на усмотрение каждого языка: Python и JavaScript по-разному кодируют Unicode и float, что ведёт к тихим ошибкам интеграции.

3. Безопасность и версионирование
   gRPC и SOAP научились:

   • TLS/mTLS по умолчанию
   • строгая обратная совместимость через IDL
   • единое управление ошибками и таймаутами
     MCP не требует шифрования, не описывает, как менять контракт, и не стандартизирует retry-логику. Каждый инструмент решает сам, как сообщать об ошибке.

4. Масштабирование и наблюдаемость
   Современные RPC-фреймворки включают распределённый трейсинг, rate-limiting, circuit breaker. MCP не предоставляет ни метрик, ни механизмов отказоустойчивости. При миллионах вызовов в день компании получают «чёрный ящик», который нельзя отладить и который падает при первой же нагрузке.

Итог
Простота MCP полезна для прототипов, но в продакшене превращается в долговременный техдолг. Пока MCP не добавит IDL, строгие типы, безопасность и наблюдаемость, внедрять его в критичных системах — значит повторять ошибки, которые отрасль исправляла последние 40 лет.

• Критики считают MCP «USB-C для ИИ»: универсальным, но с расплывчатыми стандартами и слабой типизацией.
• Сторонники отвечают: именно минимализм JSON-over-HTTP обеспечил быструю массовую adoption, в отличие от громоздких SOAP/CORBA.
• Спор о схемах: MCP поддерживает JSON Schema, но валидация не обязательна, поэтому ошибки типов всплывают только в рантайме.
• Поднимаются темы безопасности и трейсинга: нет встроенного аудита вызовов и расходов, что критично для enterprise.
• Общий вывод: MCP сейчас «хорошо достаточно» для веба, но для регулируемых или высоконагруженных сред потребуется или доработка, или новая спецификация.