fmtlib fmt lidera GitHub Trending, pero la verdadera historia es el mantenimiento
fmtlib fmt alcanzó el primer puesto en una captura de la lista de tendencias de GitHub fechada el 3 de septiembre de 2026, a pesar de no haber publicado ninguna versión nueva ese día.
Esa distinción importa. La clasificación procedía de un agregador que rastrea GitHub Trending, pero su registro no incluía una hora de captura verificada ni el aumento diario de estrellas. GitHub tampoco publica un archivo permanente y auditable de forma independiente para cada lista de Trending.
La versión estable más reciente era fmt 12.2.0, publicada el 16 de junio, según el historial de versiones del proyecto. Añadió una interfaz para C11, amplió la compatibilidad con módulos de C++ y continuó el trabajo de rendimiento de la biblioteca.
Por tanto, el evento no es una historia de lanzamiento convencional. Es evidencia de que una biblioteca de infraestructura consolidada puede atraer de repente una amplia atención meses después de una versión.
Esa atención también reabre una cuestión relevante para los equipos de C++. Si std::format y std::print ya existen, ¿por qué la biblioteca independiente que ayudó a darles forma sigue siendo tan visible?
La clasificación es real, pero su causa no está verificada
El hecho verificado es una posición en tendencias, no un anuncio de producto en septiembre.
La captura suministrada de BettaFish situó a fmtlib/fmt en primer lugar de su lista de tendencias de GitHub del 3 de septiembre. Sin embargo, el agregador no proporcionó una hora precisa de publicación, un intervalo de clasificación ni el número diario de estrellas.
Esas omisiones impiden explicar con seguridad el repunte. Una publicación en redes sociales, un proyecto dependiente, un tutorial popular o la actividad rutinaria de GitHub podrían haber contribuido. No puede establecerse un único desencadenante a partir de la clasificación por sí sola.
Tampoco existe una versión coincidente fechada el 3 de septiembre. La página de versiones del proyecto identifica la 12.2.0 como la última versión estable disponible en el registro de fuentes verificado.
Esa versión llegó más de dos meses antes de la clasificación observada. Tratar la aparición en tendencias como un lanzamiento fusionaría dos acontecimientos distintos y crearía una cronología falsa.
GitHub Trending mide atención, no adopción en producción. Una posición alta puede reflejar un cambio rápido en el interés de la comunidad, pero no revela descargas de dependencias ni versiones desplegadas.
La lista también carece del detalle metodológico necesario para comparaciones estrictas. GitHub describe los repositorios como tendencias durante un periodo seleccionado, pero no expone la fórmula completa de clasificación.
Por tanto, un repositorio puede ascender sin un único acontecimiento de titulares. Los desarrolladores podrían encontrarlo mediante actualizaciones de paquetes, documentación, debates sobre compiladores o el grafo de dependencias de otro proyecto.
Ese patrón resulta especialmente plausible para fmt. El código de formateo está por debajo de los sistemas de registro, las herramientas de línea de comandos, las bases de datos y los servicios, donde a menudo permanece invisible para los usuarios finales.
El repositorio tenía aproximadamente 23.500 estrellas y 2.900 forks en una vista reciente indexada de GitHub. Esos totales confirman una audiencia existente, no un proyecto aparecido de la nada.
Su historia también abarca miles de commits. Una base de código madura puede volver a Trending cuando el trabajo de mantenimiento acumulado adquiere una relevancia renovada para los desarrolladores.
La conclusión más segura es limitada, pero útil. fmtlib fmt obtuvo un notable aumento de atención en GitHub el 3 de septiembre, mientras que la causa inmediata sigue sin verificarse.
Esa incertidumbre no vacía de significado la clasificación. Desplaza la historia de un supuesto lanzamiento hacia las razones por las que esta biblioteca sigue reapareciendo.
fmtlib fmt 12.2 amplió su alcance a C
La versión 12.2 importa porque fmt se expandió más allá de su habitual papel en C++ mientras seguía optimizando el trabajo de formateo cotidiano.
El mayor cambio de alcance fue fmt-c, una interfaz para C11 proporcionada mediante el encabezado fmt/fmt-c.h. Utiliza _Generic, una característica de C11 que selecciona una expresión según el tipo de un argumento.
Este diseño lleva el formateo dirigido por tipos a C sin fingir que C tiene plantillas de C++. Los desarrolladores llaman a fmt_print con cadenas de formato basadas en llaves y valores ordinarios.
El printf tradicional depende de una cadena de formato cuyos especificadores de conversión deben coincidir con los argumentos posteriores. Una discrepancia puede producir advertencias, resultados incorrectos o comportamiento indefinido.
La nueva interfaz busca detectar más errores mediante el despacho basado en tipos. También proporciona a los programadores de C acceso al modelo de formateo que ya conocen muchos usuarios de C++ y Python.
Se trata de una expansión, no de una sustitución de la identidad central de fmt. El proyecto sigue describiéndose como una alternativa de código abierto a stdio de C e iostreams de C++ en su descripción general del proyecto.
La versión 12.2 también introdujo un objetivo de CMake independiente, fmt::fmt-module. Un objetivo de CMake empaqueta los requisitos de compilación para que los proyectos dependientes puedan consumir una biblioteca de manera uniforme.
El objetivo admite módulos de C++20, que permiten a los compiladores procesar interfaces declaradas en lugar de analizar repetidamente encabezados textuales. fmt también añadió cobertura de integración continua para compilaciones basadas en módulos.
Los módulos han prometido límites más limpios y un mejor comportamiento de compilación durante años. La adopción real sigue siendo desigual porque deben alinearse la compatibilidad del compilador, la biblioteca estándar y el sistema de compilación.
Un objetivo mantenido ofrece a los equipos una vía de integración compatible. No garantiza que todas las combinaciones de cadenas de herramientas se comporten de forma idéntica.
El trabajo de rendimiento siguió siendo central. La versión habilitó por defecto la caché de búsqueda completa de Dragonbox, salvo cuando las compilaciones optimizan explícitamente el tamaño binario.
Dragonbox es un algoritmo para convertir valores binarios de punto flotante en texto decimal. Esta conversión aparece en registros, serialización, diagnósticos, paneles y software científico.
El proyecto informa de una mejora de velocidad aproximada del 10 al 25 por ciento gracias al cambio de caché. Su benchmark publicado midió 22,07 nanosegundos por double para la configuración de caché completa.
La configuración compacta midió 29,55 nanosegundos con la misma configuración documentada. Se trata de benchmarks elaborados por el proyecto en un Apple M1 Pro con Clang 17.
Muestran el mecanismo en ese entorno de prueba, no una mejora universal de la velocidad de las aplicaciones. La mayoría de los programas dedica solo una parte de su tiempo de ejecución al formateo de valores de punto flotante.
La versión 12.2 también informó de una mejora aproximada del 3 por ciento en el formateo de enteros. Las operaciones de anexado masivo mejoraron la salida mediante iteradores de inserción al final utilizados con contenedores y cadenas personalizadas.
El tamaño de las compilaciones de depuración también recibió atención. El proyecto afirma que su prueba de hinchamiento se redujo de unos 200 kilobytes a 85 kilobytes con la configuración correspondiente.
Otros cambios abordaron el formateo sin pérdida de rutas del sistema de archivos, std::unexpected, sobrecargas de println con estilos y argumentos de ancho posicionales para la API compatible con printf.
Ninguno de esos elementos explica por sí solo una clasificación de septiembre. En conjunto, muestran un proyecto que amplía su superficie sin abandonar el trabajo de mantenimiento.
El C++ estándar presiona a fmt sin sustituirlo
La competencia central es fmt frente al formateo de la biblioteca estándar, pero ambos siguen conectados en lugar de estar claramente enfrentados.
El C++ moderno incluye ahora std::format, que produce texto formateado, y std::print, que envía salida formateada a un flujo. Eso reduce la necesidad de una dependencia externa.
El detalle histórico importante es que fmt ayudó a establecer esta dirección. El proyecto se identifica como una implementación de std::format de C++20 y std::print de C++23.
Victor Zverovich, mantenedor de fmt, también fue autor de la propuesta que introdujo la moderna funcionalidad de formateo en el estándar. La propuesta de formateo desarrolló explícitamente una alternativa más segura a la salida formateada tradicional.
La estandarización cambia la decisión de compra dentro de una base de código. Los equipos pueden preferir una funcionalidad proporcionada por su compilador y biblioteca estándar en lugar de gestionar otro paquete.
Esa opción resulta atractiva en entornos conservadores. Menos dependencias pueden simplificar la revisión de seguridad, las comprobaciones de licencias, las actualizaciones y la reproducibilidad de compilación a largo plazo.
La vía estándar sigue teniendo limitaciones. La disponibilidad de funcionalidades depende de las versiones de los compiladores, las implementaciones de bibliotecas estándar y el modo de lenguaje seleccionado por cada proyecto.
Un equipo que admita cadenas de herramientas empresariales más antiguas no puede asumir que todos los objetivos disponen de compatibilidad completa con el formateo de C++20 o C++23. Los productos multiplataforma suelen avanzar al ritmo de su entorno compatible más antiguo.
fmt puede proporcionar una interfaz más coherente entre esos entornos. También puede publicar mejoras sin esperar al ciclo de varios años de estandarización y distribución de cadenas de herramientas.
La biblioteca ofrece API más allá de una lectura estricta de la superficie estándar. Estas incluyen formateo de rangos, colores y estilos de texto, asistentes para archivos de salida e integraciones diseñadas según su propio calendario de versiones.
La API de C11 de la versión 12.2 refuerza esa diferencia. std::format pertenece a C++, mientras que fmt presenta ahora un modelo de formateo para proyectos tanto de C como de C++.
Esto no hace que fmt sea automáticamente preferible. Cada dependencia crea trabajo de actualización, pruebas de compatibilidad y exposición a cambios aguas arriba.
Integrar fmt como código fuente puede complicar las compilaciones cuando otra dependencia incorpora una versión distinta. Los sistemas enlazados dinámicamente también deben considerar la compatibilidad de la interfaz binaria de aplicación.
La biblioteca estándar ofrece otro tipo de estabilidad. Sus funcionalidades siguen especificaciones publicadas, y los desarrolladores pueden esperar horizontes de soporte prolongados una vez que las implementaciones maduren.
Sin embargo, la estandarización no congela la relevancia del proyecto original. Puede convertir la biblioteca independiente en un laboratorio aguas arriba para ideas de implementación y experimentos de rendimiento.
Esa relación crea la inversión central del artículo. El éxito dentro del estándar podría parecer que hace innecesario a fmt, pero también valida las decisiones de diseño de fmt.
La clasificación de septiembre sugiere que los desarrolladores todavía reconocen el proyecto aguas arriba como una herramienta actual. No establece cuántos lo eligen frente a std::format.
Por tanto, una decisión útil comienza con las limitaciones. Los equipos deben comparar las bases de compiladores, las funcionalidades necesarias, la política de dependencias y el rendimiento medido de la aplicación.
No deben tratar una posición en Trending como prueba técnica. Tampoco deben asumir que la estandarización ha eliminado todas las razones para usar la biblioteca original.
Lo que los benchmarks de fmt no demuestran
fmt publica cifras de rendimiento convincentes, pero los desarrolladores deben separar las pruebas de formateo específicas de los resultados de aplicaciones completas.
El README del proyecto incluye un benchmark que compara varios métodos de formateo. Con su configuración documentada, fmt 12.1 completó la prueba en 0,44 segundos.
La misma prueba registró 0,66 segundos para printf, 1,63 segundos para std::ostream y 3,89 segundos para Boost Format. El benchmark formateó dos millones de registros hacia /dev/null.
Esas mediciones respaldan una afirmación limitada sobre las operaciones y el entorno probados. No muestran que sustituir una API reduzca la latencia total de una aplicación en la misma proporción.
Las cargas de trabajo de producción incluyen asignación de memoria, sincronización, sistemas de archivos, operaciones de red, análisis y lógica de negocio. El formateo puede dominar algunas canalizaciones de registro y apenas tener presencia en otros casos.
La propiedad del benchmark también importa. Las cifras proceden del proyecto fmt y sus repositorios de benchmarks asociados, no de un laboratorio independiente.
La metodología está disponible, lo que ofrece a los desarrolladores una vía para reproducirla. La reproducibilidad es más valiosa que repetir un titular de rendimiento sin contexto.
Los equipos deben probar cadenas de formato representativas, tipos de argumentos, opciones del compilador y destinos de salida. Un microbenchmark que descarta la salida no puede modelar todas las cargas de trabajo de archivos o consola.
El tiempo de compilación merece la misma cautela. La prueba de bloat publicada por fmt genera 100 unidades de traducción y llama repetidamente a cada método de formateo.
El proyecto informa un tiempo de compilación optimizada de cinco segundos para una revisión probada de fmt. Enumera 1,6 segundos para printf y resultados mucho más largos para iostreams y Boost Format.
Esa comparación explica por qué importan la estructura de los encabezados y la instanciación de plantillas. No predice el tiempo de compilación de un servicio grande con encabezados precompilados, builds unity o mucho código generado.
La versión 12.2 también conlleva riesgos habituales de migración. Los nuevos objetivos, formateadores y rutas de rendimiento interactúan con toolchains que los mantenedores no pueden controlar por completo.
Los informes públicos de incidencias ilustran ese límite. Un informe de 2026 planteó una preocupación de codificación relacionada con EBCDIC y otros conjuntos de caracteres de ejecución que no son compatibles con ASCII.
Una incidencia no equivale a una vulnerabilidad confirmada. Es evidencia de que las afirmaciones de portabilidad requieren pruebas más allá de los entornos UTF-8 convencionales.
El registro de cambios no publicado de la 12.2.1 ofrece otra señal útil. Enumera correcciones para un bloqueo por tubería cerrada, el formateo de caracteres enteros, duraciones de punto flotante y varios casos de integración.
Eso es normal en una biblioteca activa. También demuestra por qué los equipos de producción deben seguir las versiones de parche en lugar de adoptar una versión mayor o menor una vez y olvidarse de ella.
El proyecto añadió artefactos de lanzamiento, procedencia de la cadena de suministro, análisis CodeQL y una política de seguridad durante el ciclo 12.2. Estas medidas mejoran la información disponible para los usuarios downstream.
No eliminan el riesgo de dependencias. Los equipos siguen necesitando fijación de versiones, monitoreo de vulnerabilidades, builds reproducibles y validación con los compiladores compatibles.
Los grupos de ingeniería pueden facilitar ese trabajo si mantienen las decisiones de actualización y la evidencia de pruebas en una base de conocimiento técnico consultable. El objetivo es la trazabilidad, no el volumen de documentación.
Por tanto, la lectura escéptica es sencilla. fmt cuenta con evidencia de ingeniería creíble, pero sus mejores cifras siguen siendo específicas de cada carga de trabajo y parcialmente autodeclaradas.
La infraestructura madura puede ser tendencia sin un lanzamiento
La posición de fmt muestra cómo la atención de los desarrolladores puede redescubrir una infraestructura que ya ha influido en la plataforma que la rodea.
Las aplicaciones de consumo suelen convertirse en tendencia en torno a lanzamientos visibles. Los repositorios de infraestructura a menudo siguen un ritmo distinto porque los desarrolladores los encuentran mediante cambios en dependencias y problemas técnicos.
Una biblioteca de logging puede exponer fmt a través de un mensaje de error. Una actualización del compilador puede revelar una macro o sobrecarga incompatible. Una migración de build puede llevar a un equipo a replantearse la integración solo mediante encabezados.
Cada vía puede llevar a los desarrolladores al repositorio sin producir un anuncio coordinado. Eso hace que el interés repentino sea más difícil de atribuir, pero no menos relevante.
La lista de usuarios conocidos de fmt abarca bases de datos, terminales, juegos, sistemas de infraestructura y herramientas para desarrolladores. El proyecto menciona a ClickHouse, Envoy, PyTorch, Windows Terminal y spdlog, entre muchos otros ejemplos.
Esa lista es mantenida por el proyecto, por lo que no debe leerse como un censo completo de dependencias. Aun así, ilustra cómo el código de formateo se propaga por diversas capas de software.
El atractivo de la biblioteca comienza con un problema cotidiano. Los programas convierten constantemente valores tipados en texto para usuarios, logs, diagnósticos, archivos y mensajes de red.
La E/S formateada de C es concisa, pero deposita la responsabilidad en los especificadores de conversión. Los iostreams de C++ proporcionan comportamiento basado en tipos, pero pueden volverse verbosos y conservar estado de formateo.
El formateo basado en llaves ofrece una tercera vía. La cadena de formato describe la colocación y la presentación, mientras que los argumentos tipados siguen siendo valores separados.
La comprobación en tiempo de compilación puede rechazar algunas combinaciones inválidas antes de que se ejecute un programa. Esto resulta especialmente útil en logging, donde las rutas de error que rara vez se ejecutan pueden ocultar errores.
La extensibilidad también importa. Un proyecto puede definir cómo debe formatearse su propio tipo y reutilizar ese comportamiento en el logging y la salida orientada al usuario.
La biblioteca estándar ya cubre buena parte de este terreno. fmt sigue compitiendo mediante portabilidad, incorporaciones más recientes y cadencia de lanzamientos.
La compatibilidad con C de la versión 12.2 vuelve a ampliar la audiencia. Los proyectos multilenguaje pueden evaluar un enfoque común de formateo sin convertir sus componentes C a C++.
El cambio también presiona otras rutas de formateo. printf sigue siendo ubicuo, estable y disponible casi en todas partes, pero su sintaxis y comportamiento variádico conllevan riesgos conocidos.
Las bibliotecas envoltorio de C pueden mejorar la seguridad mediante anotaciones del compilador o interfaces generadas. fmt-c aplica en su lugar la selección genérica de C11 y la sintaxis de formateo ya existente del proyecto.
Aún se desconoce si ese enfoque logrará una adopción significativa en C. El resultado de Trending de septiembre mide curiosidad, no el uso sostenido de la nueva API.
Los datos de gestores de paquetes ofrecerían una señal de adopción más sólida. También lo harían las actualizaciones de dependencias downstream, los ejemplos repetidos de la comunidad y los informes de compatibilidad de grandes bases de código en C.
Hasta que aparezcan, la clasificación se interpreta mejor como un evento de descubrimiento. Devolvió una biblioteca consolidada a la ruta de los desarrolladores que exploran repositorios activos.
Eso sigue siendo estratégicamente importante para el código abierto. Los proyectos maduros compiten por la atención de mantenedores, contribuyentes, diversidad de pruebas y presencia mental junto con repositorios más nuevos.
Un breve auge puede traer nuevos informes de incidencias y parches. También puede atraer usuarios que esperan soporte sin entender la capacidad del proyecto.
Los mantenedores se enfrentan entonces a una disyuntiva entre ampliar la interfaz y preservar la previsibilidad que valoran los usuarios establecidos. fmt 12.2 intenta ambas cosas mediante nuevas superficies y correcciones específicas.
Tres señales mostrarán si la atención perdura
La próxima prueba no es el puesto de Trending de mañana, sino si la atención se convierte en lanzamientos, adopción downstream y resultados creíbles entre toolchains.
La primera señal es fmt 12.2.1. El registro de cambios del proyecto etiqueta esa versión como próxima y ya registra correcciones y añadidos.
Un lanzamiento oportuno de parche mostraría que los mantenedores están convirtiendo los comentarios posteriores a la 12.2 en un paquete estable. Los retrasos prolongados aumentarían la importancia de consumir commits no publicados o mantener parches locales.
El contenido importa tanto como el calendario. Los equipos deberían observar si las correcciones enumeradas para tuberías cerradas, formateo, CMake y módulos llegan sin introducir comportamientos incompatibles.
Esa señal reforzaría la historia de mantenimiento. No demostraría que la aparición en Trending incrementó directamente la actividad de desarrollo.
La segunda señal es la adopción de fmt-c. Busque actualizaciones de paquetes, repositorios C downstream, ejemplos de documentación e informes de incidencias basados en despliegues reales.
Unas pocas demostraciones pueden validar la sintaxis, pero el uso repetido en compiladores y sistemas operativos pondría a prueba la portabilidad práctica de la interfaz.
La pregunta clave es si los desarrolladores de C aceptan una nueva dependencia para el formateo dirigido por tipos. Las bases de código existentes tienen inversiones profundas en printf, envoltorios y logging específico de cada plataforma.
Si fmt-c aparece en proyectos downstream relevantes, la atención de septiembre parecerá vinculada a una expansión genuina. Si la adopción sigue siendo limitada, seguirá siendo un experimento notable.
La tercera señal es el movimiento entre fmt y las funcionalidades de la biblioteca estándar. Los lanzamientos de compiladores y los cambios en las bases de referencia de los proyectos pondrán std::format y std::print a disposición de más equipos.
Algunas bases de código migrarán hacia el estándar. Otras mantendrán fmt para plataformas antiguas, APIs adicionales o un acceso más rápido a correcciones.
Los informes públicos de migración pueden revelar qué restricciones predominan. Las pruebas comparativas deberían incluir tiempo de compilación, tamaño del binario, rendimiento de formateo, portabilidad y esfuerzo de mantenimiento.
Una oleada de migraciones a la biblioteca estándar debilitaría el argumento a favor de fmt como dependencia predeterminada. No borraría su papel como referencia de implementación y espacio de desarrollo.
La adopción continuada de fmt mostraría que la disponibilidad de estándares por sí sola no resuelve las decisiones de infraestructura. La cadencia de lanzamientos y los entornos compatibles seguirían siendo decisivos.
Por tanto, los desarrolladores que evalúan fmtlib fmt deberían ignorar la tentación de convertir el primer puesto en un veredicto. Empiecen por los cambios de la 12.2 y después reproduzcan pruebas relevantes dentro de su propio build.
Comprueben el compilador más antiguo que admiten. Prueben módulos solo donde el toolchain completo los admita y examinen los cambios de nivel de parche antes de actualizar sistemas de producción.
Para proyectos en C, creen un prototipo de fmt-c en rutas reales de logging o diagnóstico, en lugar de hacerlo con ejemplos aislados. Midan advertencias, tamaño del ejecutable, rendimiento y comportamiento ante fallos.
La clasificación de septiembre ofreció una indicación útil, no una respuesta. ¿Su próxima base de referencia de toolchain hará suficiente el formateo estándar, o fmt sigue resolviendo hoy un problema concreto de compatibilidad?
