Clice 1.0 ya aísla cada archivo C++ en su propio proceso

Clice llegó a la versión 1.0 el 15 de noviembre de 2026, después de cuatro meses de pruebas alfa que arrancaron el 19 de julio y de superar los 1.000 commits en su repositorio, según el anuncio de su creador ykiko. Es un language server de C y C++ escrito enteramente en C++23, pensado para reemplazar a clangd o ccls en tu editor.

El proyecto lleva dos años y medio de desarrollo y se apoya, igual que sus dos predecesores, en LLVM y Clang para entender el código. Pero clice no es un fork ni una mejora incremental de esos dos: su autor lo rediseñó desde cero para resolver problemas arquitectónicos que clangd y ccls arrastran desde hace años, en particular qué pasa cuando el compilador se cae en medio de una edición (fuente).

Un language server de C++ que no se cae entero cuando el compilador explota

Como cualquier implementación del Language Server Protocol, clice no depende de un editor específico: cualquier cliente LSP (VS Code, Neovim, Emacs, Helix) puede conectarse a él para obtener resaltado, autocompletado, ir a definición y los demás servicios habituales. La ganancia de usar clice en vez de clangd no está en el editor, sino en lo que pasa del otro lado del protocolo cuando el compilador tiene un mal día.

Un proceso por archivo, no un hilo compartido

clangd compila con varios hilos dentro de un único proceso. El problema es que Clang puede crashear o filtrar memoria en casos límite, algo mucho más común de lo que parece cuando editás código a medio escribir: la inmensa mayoría de quienes prueban un compilador lo hacen sobre código completo, y casi nadie prueba sobre código incompleto, que es justamente donde el compilador recurre a heurísticas de mejor esfuerzo (fuente). Cuando eso pasa en clangd, el servidor entero se reinicia y perdés ir a definición, resaltado y autocompletado hasta que vuelve a levantar.

clice resuelve esto con un pool de procesos, al estilo de un navegador moderno. Cada compilación corre en un proceso hijo aislado: si un worker se cae, el resto del servidor sigue respondiendo y las funciones que dependían de otros archivos no se interrumpen. Ese diseño también facilita administrar memoria y priorizar qué se compila primero, algo que un modelo de hilos compartidos dentro de un mismo proceso no permite hacer con la misma granularidad (fuente).

Por debajo, todo esto corre sobre una librería de concurrencia estructurada construida sobre libuv y corrutinas de C++20. Un único event loop en el hilo principal coordina tanto los procesos hijos, vía IPC, como los hilos internos del propio servidor, lo que le permite a clice comportarse como un programa concurrente complejo sin la explosión de locks y condiciones de carrera típica de ese tipo de arquitecturas (fuente).
clice aísla cada compilación en un proceso separado desde su versión 1.0.

Módulos C++20 con caché en disco, no solo soporte parcial

La otra brecha que clice ataca es el soporte de módulos de C++20. Con un compile_commands.json que incluya los archivos de módulo, clice escanea las dependencias por su cuenta y construye lo que necesita de forma perezosa, sin importar qué build system o compilador usés. Eso cubre autocompletado, resaltado, ir a definición y hover dentro de archivos de módulo, algo que clangd todavía ofrece de forma muy limitada y sin caché persistente (fuente).

Los PCH y PCM que clice construye se guardan en disco y se reutilizan entre sesiones, así que no hay que reconstruir todo el árbol de módulos cada vez que abrís el editor. El proyecto incluso incluye una herramienta propia que genera automáticamente los wrappers de módulo para librerías de terceros, y clice corre sobre su propio código fuente para ofrecerse sus propios servicios conscientes de módulos (fuente).

El resto del stack técnico sigue la misma lógica. Para serializar datos (TOML, JSON, bincode y los propios argumentos de línea de comandos) usa reflection estática construida con templates y conceptos de C++20, con anotaciones declarativas al estilo de las macros de Rust y sin boilerplate manual (fuente). El diseño es data-oriented, casi sin funciones virtuales fuera de las interfaces de callback que exige Clang, y se apoya en std::format, std::expected, std::ranges y std::views en vez de las APIs más viejas de C++98/11.

La build es hermética y reproducible con Bazel, usando un toolchain unificado para compilación cruzada consistente entre plataformas. Los binarios salen optimizados con PGO y LTO, y los artefactos de build no dependen de nada más que las librerías del sistema (fuente).

Contexto de compilación: el problema de los headers que no compilan solos

Muchos headers de C++ no son autocontenidos: dependen de qué archivo los incluye para tener sentido, y un mismo header puede usarse desde decenas de puntos de inclusión distintos con configuraciones distintas. clangd maneja esto de forma implícita y a veces inconsistente. clice en cambio modela explícitamente el concepto de contexto de compilación: podés elegir qué comando de compilación aplica a un archivo fuente, o desde qué sitio de inclusión se debe interpretar un header (fuente).

Cuando abrís un header que no es autocontenido, clice detecta su contexto automáticamente, así que funciona sin configuración extra desde el primer uso. Pero también permite agrupar comandos de compilación en configuraciones completas, por ejemplo para alternar entre una build de debug y una de release sin perder el resto del estado del editor (fuente). En proyectos con varias configuraciones de build activas a la vez, eso evita falsos positivos de errores que en realidad son solo del contexto equivocado.

clice frente a clangd y ccls

clangd es la alternativa más usada hoy: también basada en Clang y mantenida dentro del propio proyecto LLVM. ccls es la otra opción conocida del mismo espacio, más liviana y también dependiente de Clang, aunque la fuente de este artículo no detalla su soporte de módulos, así que no la comparamos en esa columna (fuente). La tabla resume en qué difiere clice de clangd, los dos proyectos sobre los que sí hay datos suficientes para comparar:
AspectocliceclangdArquitectura de compilaciónPool de procesos aisladosMultihilo dentro de un procesoEfecto de un crash del compiladorSolo afecta al workerReinicia todo el servidorSoporte de módulos C++20Completo, con escaneo automáticoMuy limitadoCaché de PCH/PCMPersistente en disco entre sesionesNo persistente
Para un equipo chico que ya convive bien con los límites actuales de clangd, cambiar de inmediato no se justifica: la ganancia principal de clice aparece cuando el equipo edita archivos grandes con templates pesados o módulos, justo los casos donde el compilador de Clang es más frágil. ccls sigue siendo la opción más liviana de instalar cuando el objetivo es solo autocompletado básico, sin pretender soporte avanzado de módulos.

Qué significa para vos si mantenés un proyecto C++ grande

Si trabajás en backend o infraestructura con una base de código C++20 o C++23 grande, y hoy usás clangd, el primer chequeo es simple: ¿tu editor se reinicia solo cuando editás un archivo a medio terminar? Si la respuesta es sí, ese es exactamente el problema que clice ataca de raíz con su pool de procesos. Probarlo primero en una rama personal, sin migrar a todo el equipo el mismo día, es la forma más barata de confirmarlo.

Si además tu proyecto ya usa o está evaluando módulos C++20, el chequeo es distinto: necesitás un compile_commands.json que incluya los archivos de módulo. Con eso, clice puede dar autocompletado y navegación dentro de los módulos sin que tengas que reconstruir nada manualmente cada vez que abrís el editor, algo que hoy clangd no te da (fuente). Si tu equipo todavía no tocó módulos, la ganancia inmediata sigue siendo la estabilidad del servidor, no los módulos.

Si tu infraestructura de build ya usa Bazel o estás evaluando migrar a una build hermética, clice también sirve como referencia de implementación real: un proyecto de las dimensiones que describe su propio anuncio, compilado con PGO y LTO y sin dependencias fuera de las librerías del sistema. Si estás decidiendo si vale esa inversión en tu pipeline de CI, el caso de clice es un punto de comparación concreto (fuente).

Lo que discute la comunidad: qué tan 'moderno' es moderno

En el hilo de Hacker News sobre el lanzamiento, parte de la conversación giró en torno al propio nombre del proyecto. El usuario omoikane planteó que 'modern C++' probablemente hace referencia al libro Effective Modern C++ de Scott Meyers, usado para contrastar los estándares posteriores a C++98/11 frente a esa era anterior del lenguaje (comentario).

Esa lectura importa más allá de la anécdota. clice no usa 'moderno' como adjetivo de marketing: cada feature que elige (corrutinas, módulos, reflection estática, conceptos) corresponde a algo que C++98/11 no tenía y que todavía hoy muchos proyectos grandes en producción no usan. La arquitectura del propio language server funciona como demostración de que esas features aguantan software complejo de cientos de miles de líneas, no solo ejemplos de blog (fuente).

Limitaciones y cuándo esperar antes de migrar

clice es software nuevo. Cuatro meses de alfa con feedback real de usuarios tempranos es un historial corto comparado con los años de producción que tienen clangd y ccls, aunque el propio autor sostiene que las funciones core ya son estables en el uso diario (fuente).

El ecosistema alrededor de C++20/23 todavía es incómodo. El propio creador admite que hacer funcionar todo ese flujo (módulos, build hermética con Bazel, toolchain xclang) de punta a punta le tomó un esfuerzo considerable de rastrear issues y adaptar cosas a mano (fuente). Si tu proyecto no usa Bazel ni módulos, parte de esa inversión en infraestructura no te sirve todavía, y vas a depender de que tu propio build system genere bien el compile_commands.json.

El riesgo concreto de adoptar clice ahora no es que falle una vez: es que un bug nuevo en una herramienta que recién cumplió cuatro meses de alfa te interrumpa en medio de un sprint, justo el tipo de fricción que un language server debería eliminar. Por eso conviene probarlo primero en un repo secundario o en tu propio entorno, no en la máquina de todo el equipo el mismo día del release. Tampoco hay todavía datos públicos de adopción (descargas, cantidad de proyectos en producción) más allá de los 1.000 commits y los cuatro meses de alfa que reporta el propio anuncio.
El autor de clice lleva dos años y medio desarrollándolo antes de llegar a 1.0.

Referencias

• clice v1.0 Released: Welcome to Modern C++: anuncio oficial del lanzamiento, arquitectura multiproceso, soporte de módulos y detalles de build.- Hilo de Hacker News sobre el lanzamiento de clice 1.0: discusión de la comunidad sobre el proyecto.- Comentario de omoikane en Hacker News: hipótesis sobre el origen del término 'modern C++' ligado al libro de Scott Meyers.

Seguimos el tema en @programacion.