Show HN: I built a web framework in C 🔥 Горячее 💬 Длинная дискуссия
Краткий пересказ:
lavandula — это минималистичный веб-фреймворк на C, который обещает «скорость C и удобство Python». Проект с открытым исходным кодом, лицензия MIT. Сейчас он находится в стадии альфа-тестирования: базовый роутинг, middleware, JSON-ответы и простой шаблонизатор уже работают. Пример «Hello, world» компилируется в 12 КБ статического бинарника, а полноценный REST API сервис — меньше 100 КБ.
Планы: добавить встроенный ORM, WebSocket и SSE, а также CLI-генератор проектов. Поддержка Windows пока нестабильна, но Linux и macOS уже можно использовать. Сообщество приветствует вклад: обсуждение ведётся в Discussions, а примеры кода и бенчмарки публикуются в репозитории.
Комментарии (179)
- Проект получил похвалу за чистоту и современный стиль кода, но также вызвал споры о практичности и безопасности C-фреймворков.
- Участники обсуждали, насколько целесообразно писать веб-приложения на C, и поднимались вопросы о безопасности и удобстве использования.
- Некоторые отметили, что проект может быть полезен для обучения и как отправная точка для других языков или фреймворков.
- Были также упоминания о том, что проект может быть развит с добавлением функций вроде шаблонизатора или поддержки HTTPS.
- Некоторые комментарии подчеркнули важность тестов и обработки ошибок в коде, а также отметили, что проект может быть использован как основа для других языков или фреймворков.
Cap'n Web: a new RPC system for browsers and web servers 🔥 Горячее 💬 Длинная дискуссия
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 и современных браузерах. Это делает распределённое программирование почти неотличимым от локального, с учётом сетевых реалий.
Комментарии (251)
- Обсуждение 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 doesn't need tools, it needs code
CLI-инструменты часто зависят от платформы/версии, плохо документированы и ломаются при не-ASCII вводе. Агенты путаются в управлении состоянием (например, tmux-сессиями) и теряют контекст после мелкой ошибки. Каждый вызов ещё тормозит из-за предварительной проверки безопасности.
Композиция в CLI работает через bash: цепочки tmux send-keys, sleep, base64 и т.д. MCP сегодня так не умеет.
Выход — MCP-сервер с одним «убер-инструментом»: Python-интерпретатор, сохраняющий состояние между вызовами. Пример — pexpect-mcp: виртуальное окружение + pexpect, позволяющее скриптами управлять интерактивными CLI-программами. Вместо 30 отдельных MCP-функций достаточно одной, принимающей код.
Комментарии (110)
- Участники спорят, нужен ли MCP (Model Context Protocol): кто-то считает его лишним слоем, другие — полезным способом дать LLM структурированные инструменты.
- Критика: MCP ограничивает агента набором команд, не решает безопасность, дублирует OpenAPI и заставляет LLM учиться новому формату вместо bash/API.
- Альтернативы: прямое обращение к HTTP/CLI/WebSocket (UTCP), YAML-описание тулов (hooks_mcp), eval в песочнице (runjs, Bubblewrap).
- Практические проблемы: при 100+ тулов агент путается; приходится писать кучу обвязок вместо «просто вызвать API».
- Общий вывод: MCP пока выглядит сыро, требует лишних усилий и не даёт очевидных преимуществ перед строками/bash/API.