Protobuf tiene soporte para LSP
El nuevo soporte para el Protocolo de Servidor de Lenguaje (LSP) de Protobuf, de Buf, está provocando un renovado escrutinio tanto del formato como de sus herramientas, especialmente en comparación con JSON, REST y los flujos de trabajo emergentes impulsados por LLM. Los comentaristas debaten si los esquemas estrictos y los IDL como Protobuf están dejando de ser necesarios o si se vuelven más críticos en un mundo de modelos probabilísticos, citando compensaciones en rendimiento, ergonomía, versionado e interoperabilidad multilenguaje. El lanzamiento también plantea dudas sobre los LSP frente a las integraciones específicas de IDE, el soporte previo de Protobuf en editores e incluso el tono de los anuncios corporativos de código abierto.
Rol de Protobuf y los esquemas en la era de los LLM
- Algunos sostienen que los LLM reducen la necesidad de herramientas de esquemas pesadas, monorepos e infraestructura de microservicios centrada en protobuf.
- Otros discrepan con fuerza, afirmando que la generación de código probabilística hace que los contratos estrictos y compartidos sean más importantes.
- La divergencia depende de si los sistemas futuros mantienen a los LLM “in-band” para el comportamiento o si los tratan como ayudantes que siguen entregando el control a capas deterministas y bien tipadas.
Protobuf vs JSON: rendimiento y practicidad
- Un bando informa que gRPC/protobuf es más lento y menos fiable que JSON para algunos clientes de Google Cloud en Python, criticando la complejidad, los pasos de compilación y la ergonomía de protobuf.
- Otros insisten en que protobuf, por lo general, es más rápido y más compacto en la red, y que las ventajas de JSON son la usabilidad y la ubicuidad, no el rendimiento.
- Varios señalan advertencias específicas del ecosistema: implementaciones de JSON muy optimizadas en JS e implementaciones débiles de protobuf en Python pueden invertir las afirmaciones de rendimiento esperadas.
Esquemas, versionado y pruebas
- Quienes lo apoyan valoran protobuf por el intercambio de datos agnóstico del lenguaje, con seguridad de tipos, y por sus reglas de evolución compatibles hacia atrás.
- Algunos afirman que, si “entiendes protobuf”, a menudo puedes evitar las pruebas entre sistemas porque el comportamiento de la evolución de esquemas es predecible.
- Los críticos argumentan que aun así necesitas validación y pruebas para la lógica de negocio (por ejemplo, interdependencias entre campos), así que protobuf no elimina las verdaderas fuentes de fallos.
- Aclaraciones: renombrar y reordenar campos es compatible a nivel de wire siempre que se mantengan los números de campo y los tipos; renumerar o mover campos dentro o fuera de
oneofs puede ser problemático, especialmente con formatos JSON/texto o generadores de lenguaje concretos.
El enfoque de LSP y parsing de Buf
- El LSP de Buf se integra como un subcomando
buf lsp serve, construido sobre el mismo parser/compiler que impulsa la CLI. - Algunos ven esto como el primer LSP de protobuf robusto y completo según la especificación; a los anteriores se les critica por aceptar proto inválido o por carecer de validación completa.
- Debate sobre la implementación del LSP: reutilizar el parser “real” del lenguaje frente a parsers separados y tolerantes a fallos (tree-sitter o personalizados). Las opiniones difieren sobre si la corrección y la recuperación ante errores pueden coexistir en un único parser.
LSPs, IDEs y experiencia de desarrollador
- Algunos dicen que protobuf ya tenía buen soporte de IDE (por ejemplo, plugins para IntelliJ), cuestionando las afirmaciones de “primer soporte moderno”.
- Otros sostienen que las herramientas basadas en LSP son más “modernas” por su integración agnóstica del editor, aunque los plugins profundos de IDE pueden ser más potentes.
- Una minoría se queja de que los LSP introducen una latencia apreciable; otros consideran que los retrasos son insignificantes.
- Se especula con que los LSP/IDEs podrían volverse menos centrales a medida que avancen las herramientas de programación basadas en LLM, pero esto sigue siendo discutido.
Tono de la entrada del blog
- La frase original “You’re welcome” en el título de la publicación se percibe ampliamente como arrogante o torpe; a unos pocos lectores les parece exagerada la reacción.
- La empresa posteriormente reconoce el desliz, cambia el título y añade una edición explicando la intención y los comentarios.