fmtlib fmt conquista GitHub Trending, ma la vera storia è la manutenzione
fmtlib fmt ha raggiunto il primo posto in una snapshot della hot list GitHub Trending datata 3 settembre 2026, pur non avendo pubblicato una nuova release quel giorno.
Questa distinzione conta. La classifica proveniva da un aggregatore che monitora GitHub Trending, ma il suo record non forniva un orario di acquisizione verificato né l'aumento giornaliero di stelle. GitHub, inoltre, non pubblica un archivio permanente e verificabile in modo indipendente per ogni elenco Trending.
L'ultima release stabile era fmt 12.2.0, pubblicata il 16 giugno, secondo la cronologia delle release del progetto. Ha aggiunto un'interfaccia C11, ampliato il supporto ai moduli C++ e proseguito il lavoro della libreria sulle prestazioni.
L'evento non è quindi una tradizionale storia di lancio. Dimostra che una libreria infrastrutturale consolidata può attirare improvvisamente ampia attenzione mesi dopo una release.
Quell'attenzione riporta anche in primo piano una domanda rilevante per i team C++. Se ora esistono std::format e std::print, perché la libreria indipendente che ha contribuito a definirli resta così visibile?
La classifica è reale, ma la sua causa non è verificata
L'evento verificato è una posizione nelle tendenze, non un annuncio di prodotto di settembre.
La snapshot BettaFish fornita ha collocato fmtlib/fmt al primo posto della sua hot list GitHub Trending per il 3 settembre. Tuttavia, l'aggregatore non ha fornito un orario di pubblicazione preciso, l'intervallo della classifica o il conteggio giornaliero delle stelle.
Queste omissioni impediscono una spiegazione sicura dell'impennata. Potrebbero aver contribuito un post sui social, un progetto downstream, un tutorial popolare o la normale attività su GitHub. Dalla sola classifica non è possibile stabilire un singolo fattore scatenante.
Non esiste inoltre una release corrispondente datata 3 settembre. La pagina delle release del progetto identifica la 12.2.0 come l'ultima versione stabile disponibile nel record delle fonti verificate.
Quella versione è arrivata oltre due mesi prima della classifica osservata. Trattare l'apparizione nelle tendenze come una release fonderebbe due eventi distinti e creerebbe una cronologia falsa.
GitHub Trending misura di per sé l'attenzione, non l'adozione in produzione. Una posizione elevata può riflettere un rapido cambiamento nell'interesse della community, ma non rivela download delle dipendenze o versioni distribuite.
All'elenco mancano anche i dettagli metodologici necessari per confronti rigorosi. GitHub descrive i repository come di tendenza in un periodo selezionato, ma non espone la formula completa della classifica.
Un repository può quindi salire senza un singolo evento da prima pagina. Gli sviluppatori potrebbero incontrarlo tramite aggiornamenti dei pacchetti, documentazione, discussioni sui compilatori o il grafo delle dipendenze di un altro progetto.
Questo schema è particolarmente plausibile per fmt. Il codice di formattazione si trova alla base di sistemi di logging, strumenti a riga di comando, database e servizi, dove spesso resta invisibile agli utenti finali.
Il repository aveva circa 23.500 stelle e 2.900 fork in una recente visualizzazione indicizzata di GitHub. Questi totali indicano un pubblico già esistente, non un progetto apparso dal nulla.
La sua storia comprende inoltre migliaia di commit. Una base di codice matura può tornare in Trending quando il lavoro di manutenzione accumulato diventa nuovamente rilevante per gli sviluppatori.
La conclusione più prudente è limitata ma utile. fmtlib fmt ha ottenuto un notevole picco di attenzione su GitHub il 3 settembre, mentre la causa immediata resta non verificata.
Questa incertezza non svuota la classifica di significato. Sposta la storia da un presunto lancio verso le ragioni per cui questa libreria continua a riemergere.
fmtlib fmt 12.2 ha esteso la sua portata al C
La versione 12.2 è importante perché fmt si è espansa oltre il suo familiare ruolo nel C++, continuando al tempo stesso a ottimizzare il lavoro quotidiano di formattazione.
Il maggiore cambiamento di portata è stato fmt-c, un'interfaccia C11 fornita tramite l'header fmt/fmt-c.h. Utilizza _Generic, una funzionalità C11 che seleziona un'espressione in base al tipo di un argomento.
Questo design porta la formattazione guidata dal tipo in C senza fingere che C disponga di template C++. Gli sviluppatori chiamano fmt_print con stringhe di formato basate su parentesi graffe e valori ordinari.
Il tradizionale printf dipende da una stringa di formato le cui specifiche di conversione devono corrispondere agli argomenti successivi. Una mancata corrispondenza può produrre avvisi, output errato o comportamento indefinito.
La nuova interfaccia punta a intercettare più errori tramite il dispatch basato sui tipi. Offre inoltre ai programmatori C accesso al modello di formattazione già familiare a molti utenti C++ e Python.
Si tratta di un'espansione, non di una sostituzione dell'identità centrale di fmt. Il progetto continua a descriversi come un'alternativa open source a C stdio e C++ iostreams nella sua panoramica del progetto.
La versione 12.2 ha introdotto anche un distinto target CMake fmt::fmt-module. Un target CMake raggruppa i requisiti di build affinché i progetti downstream possano utilizzare una libreria in modo coerente.
Il target supporta i moduli C++20, che consentono ai compilatori di elaborare interfacce dichiarate invece di analizzare ripetutamente header testuali. fmt ha inoltre aggiunto copertura di integrazione continua per build basate sui moduli.
I moduli promettono confini più puliti e un migliore comportamento di build da anni. L'adozione reale resta disomogenea perché il supporto di compilatori, librerie standard e sistemi di build deve allinearsi.
Un target mantenuto offre ai team un percorso di integrazione supportato. Non garantisce che ogni combinazione di toolchain si comporti in modo identico.
Il lavoro sulle prestazioni è rimasto centrale. La release ha abilitato per impostazione predefinita la cache di lookup completa di Dragonbox, salvo quando le build ottimizzano esplicitamente per la dimensione del binario.
Dragonbox è un algoritmo per convertire valori binari in virgola mobile in testo decimale. Questa conversione compare in log, serializzazione, diagnostica, dashboard e software scientifico.
Il progetto riporta un miglioramento di velocità approssimativamente compreso tra il 10 e il 25 per cento grazie alla modifica della cache. Il benchmark pubblicato ha misurato 22,07 nanosecondi per double nella configurazione con cache completa.
La configurazione compatta ha misurato 29,55 nanosecondi nella stessa configurazione documentata. Si tratta di benchmark prodotti dal progetto su un Apple M1 Pro con Clang 17.
Mostrano il meccanismo in quell'ambiente di test, non un'accelerazione universale dell'applicazione. La maggior parte dei programmi trascorre solo una parte del proprio tempo di esecuzione nella formattazione di valori in virgola mobile.
La versione 12.2 ha inoltre riportato un miglioramento di circa il 3 per cento nella formattazione degli interi. Le operazioni di append in blocco hanno migliorato l'output tramite iteratori back-insert usati con container e stringhe personalizzate.
Anche la dimensione delle build di debug ha ricevuto attenzione. Il progetto afferma che il suo bloat test è sceso da circa 200 kilobyte a 85 kilobyte nella configurazione pertinente.
Altre modifiche hanno riguardato la formattazione senza perdita dei percorsi del file system, std::unexpected, overload println con stile e argomenti di larghezza posizionali per l'API compatibile con printf.
Nessuno di questi elementi, da solo, spiega una classifica di settembre. Insieme, mostrano un progetto che estende la propria superficie senza abbandonare il lavoro di manutenzione.
Il C++ standard mette pressione a fmt senza sostituirlo
Il confronto centrale è fmt contro la formattazione della libreria standard, ma i due restano collegati anziché nettamente contrapposti.
Il C++ moderno include ora std::format, che produce testo formattato, e std::print, che invia output formattato a uno stream. Ciò riduce la necessità di una dipendenza esterna.
Il dettaglio storico importante è che fmt ha contribuito a stabilire questa direzione. Il progetto si identifica come un'implementazione di C++20 std::format e C++23 std::print.
Victor Zverovich, maintainer di fmt, ha anche redatto la proposta che ha introdotto nella norma la moderna funzionalità di formattazione. La proposta sulla formattazione ha sviluppato esplicitamente un'alternativa più sicura al tradizionale output formattato.
La standardizzazione cambia la decisione di adozione all'interno di una codebase. I team possono preferire una funzionalità fornita dal proprio compilatore e dalla libreria standard invece di gestire un altro pacchetto.
Questa opzione diventa interessante in ambienti conservativi. Meno dipendenze possono semplificare le revisioni di sicurezza, i controlli sulle licenze, gli aggiornamenti e la riproducibilità delle build nel lungo periodo.
Il percorso standard ha ancora dei vincoli. La disponibilità delle funzionalità dipende dalle versioni dei compilatori, dalle implementazioni della libreria standard e dalla modalità del linguaggio selezionata da ciascun progetto.
Un team che supporta toolchain enterprise meno recenti non può presumere che ogni target disponga di un supporto completo alla formattazione C++20 o C++23. I prodotti multipiattaforma spesso avanzano al ritmo dell'ambiente supportato più datato.
fmt può offrire un'interfaccia più coerente tra questi ambienti. Può inoltre rilasciare miglioramenti senza attendere il ciclo pluriennale di standardizzazione e distribuzione delle toolchain.
La libreria offre API che vanno oltre una lettura rigorosa della superficie standard. Tra queste figurano la formattazione di intervalli, stili di colore e testo, helper per file di output e integrazioni progettate attorno al proprio calendario di release.
L'API C11 della versione 12.2 rende più netta questa differenza. std::format appartiene al C++, mentre fmt presenta ora un unico modello di formattazione per progetti sia C sia C++.
Questo non rende fmt automaticamente preferibile. Ogni dipendenza crea lavoro di aggiornamento, test di compatibilità ed esposizione ai cambiamenti upstream.
L'inclusione di fmt nel codice del progetto può complicare le build quando un'altra dipendenza porta una versione diversa. I sistemi collegati dinamicamente devono considerare anche la compatibilità dell'interfaccia binaria dell'applicazione.
La libreria standard offre un altro tipo di stabilità. Le sue funzionalità seguono specifiche pubblicate e gli sviluppatori possono aspettarsi orizzonti di supporto lunghi una volta che le implementazioni maturano.
Tuttavia, la standardizzazione non congela la rilevanza del progetto originale. Può trasformare la libreria indipendente in un laboratorio upstream per idee di implementazione ed esperimenti sulle prestazioni.
Questa relazione crea il rovesciamento centrale dell'articolo. Il successo all'interno dello standard potrebbe far sembrare fmt superflua, ma convalida anche le sue scelte progettuali.
La classifica di settembre suggerisce che gli sviluppatori riconoscono ancora il progetto upstream come uno strumento attuale. Non stabilisce quanti lo stiano scegliendo al posto di std::format.
Una decisione utile parte quindi dai vincoli. I team dovrebbero confrontare baseline dei compilatori, funzionalità richieste, policy sulle dipendenze e prestazioni misurate dell'applicazione.
Non dovrebbero trattare una posizione in Trending come una prova tecnica. Né dovrebbero presumere che la standardizzazione abbia eliminato ogni ragione per utilizzare la libreria originale.
Cosa non dimostrano i benchmark di fmt
fmt pubblica numeri sulle prestazioni convincenti, ma gli sviluppatori devono distinguere i test mirati sulla formattazione dai risultati dell'intera applicazione.
Il README del progetto include un benchmark che confronta diversi metodi di formattazione. Nella configurazione documentata, fmt 12.1 ha completato il test in 0,44 secondi.
Lo stesso test ha registrato 0,66 secondi per printf, 1,63 secondi per std::ostream e 3,89 secondi per Boost Format. Il benchmark ha formattato due milioni di record in /dev/null.
Queste misurazioni supportano un'affermazione circoscritta sulle operazioni e sull'ambiente testati. Non dimostrano che sostituire un'API ridurrà la latenza totale di un'applicazione nella stessa proporzione.
I carichi di lavoro di produzione includono allocazione, sincronizzazione, file system, operazioni di rete, parsing e logica aziendale. La formattazione può dominare alcune pipeline di logging, mentre altrove può risultare appena rilevabile.
Anche la paternità dei benchmark conta. I numeri provengono dal progetto fmt e dai suoi repository di benchmark associati, non da un laboratorio indipendente.
La metodologia è disponibile, offrendo agli sviluppatori un modo per riprodurla. La riproducibilità è più preziosa che ripetere un titolo sulle prestazioni privo di contesto.
I team dovrebbero testare stringhe di formato rappresentative, tipi di argomenti, flag del compilatore e destinazioni di output. Un microbenchmark che scarta l'output non può modellare ogni carico di lavoro su file o console.
Anche il tempo di compilazione merita la stessa cautela. Il test di bloat pubblicato da fmt genera 100 unità di traduzione e richiama ripetutamente ogni metodo di formattazione.
Il progetto riporta un tempo di compilazione ottimizzata di cinque secondi per una revisione di fmt testata. Indica 1,6 secondi per printf e risultati molto più lunghi per iostreams e Boost Format.
Questo confronto spiega perché la struttura degli header e l'istanziazione dei template contano. Non prevede il tempo di build di un grande servizio con header precompilati, unity build o ampio codice generato.
La release 12.2 comporta anche i normali rischi di migrazione. Nuovi target, formattatori e percorsi prestazionali interagiscono con toolchain che i manutentori non possono controllare pienamente.
Le segnalazioni pubbliche delle issue illustrano questo limite. Una segnalazione del 2026 ha sollevato una questione di codifica che coinvolge EBCDIC e altri set di caratteri di esecuzione non compatibili con ASCII.
Un'issue non equivale a una vulnerabilità confermata. È una prova del fatto che le dichiarazioni di portabilità richiedono test oltre i diffusi ambienti UTF-8.
Il changelog non rilasciato per la 12.2.1 offre un altro segnale utile. Elenca correzioni per un blocco su pipe chiusa, la formattazione di caratteri interi, durate in virgola mobile e diversi casi di integrazione.
Questo è normale per una libreria attiva. Dimostra anche perché i team di produzione dovrebbero seguire le patch release invece di adottare una versione major o minor una volta sola e poi dimenticarsene.
Nel ciclo 12.2 il progetto ha aggiunto artefatti di rilascio, provenienza della supply chain, analisi CodeQL e una policy di sicurezza. Queste misure migliorano le informazioni disponibili per gli utenti downstream.
Non eliminano il rischio legato alle dipendenze. I team hanno comunque bisogno di bloccare le versioni, monitorare le vulnerabilità, produrre build riproducibili e validare rispetto ai compilatori supportati.
I gruppi di ingegneria possono rendere questo lavoro più semplice conservando le decisioni di aggiornamento e le prove dei test in una knowledge base tecnica ricercabile. L'obiettivo è la tracciabilità, non il volume della documentazione.
La lettura scettica è quindi semplice. fmt dispone di prove ingegneristiche credibili, ma i suoi risultati migliori restano specifici del carico di lavoro e in parte auto-riportati.
Un'infrastruttura matura può diventare di tendenza senza un lancio
La posizione di fmt mostra come l'attenzione degli sviluppatori possa riscoprire un'infrastruttura che ha già influenzato la piattaforma che la circonda.
Le applicazioni consumer diventano di tendenza di solito in occasione di lanci visibili. I repository infrastrutturali seguono spesso un ritmo diverso, perché gli sviluppatori li incontrano attraverso cambiamenti nelle dipendenze e problemi tecnici.
Una libreria di logging potrebbe esporre fmt tramite un messaggio di errore. Un aggiornamento del compilatore potrebbe rivelare una macro o un overload incompatibile. Una migrazione della build potrebbe spingere un team a riconsiderare un'integrazione header-only.
Ciascuno di questi percorsi può portare gli sviluppatori al repository senza produrre un annuncio coordinato. Questo rende più difficile attribuire un interesse improvviso, ma non lo rende meno rilevante.
L'elenco degli utenti noti di fmt include database, terminali, giochi, sistemi infrastrutturali e strumenti per sviluppatori. Il progetto cita ClickHouse, Envoy, PyTorch, Windows Terminal e spdlog tra molti esempi.
L'elenco è mantenuto dal progetto, quindi non va interpretato come un censimento completo delle dipendenze. Illustra comunque come il codice di formattazione attraversi livelli software diversi.
L'attrattiva della libreria parte da un problema banale. I programmi trasformano costantemente valori tipizzati in testo per utenti, log, diagnostica, file e messaggi di rete.
L'I/O formattato di C è conciso, ma attribuisce la responsabilità agli specificatori di conversione. Gli iostreams di C++ offrono un comportamento basato sui tipi, ma possono diventare prolissi e mantenere stato di formattazione.
La formattazione basata sulle parentesi graffe offre una terza strada. La stringa di formato descrive posizione e presentazione, mentre gli argomenti tipizzati rimangono valori separati.
Il controllo a tempo di compilazione può rifiutare alcune combinazioni non valide prima dell'esecuzione di un programma. Ciò è particolarmente utile nel logging, dove percorsi di errore eseguiti raramente possono altrimenti nascondere errori.
Conta anche l'estensibilità. Un progetto può definire come formattare il proprio tipo e riutilizzare quel comportamento tra logging e output rivolto agli utenti.
La libreria standard ora copre gran parte di questo ambito. fmt continua a competere grazie alla portabilità, alle aggiunte più recenti e alla cadenza dei rilasci.
Il supporto C della versione 12.2 amplia nuovamente il pubblico. I progetti con linguaggi misti possono valutare un approccio comune alla formattazione senza convertire i propri componenti C in C++.
Il cambiamento mette pressione anche su altri approcci di formattazione. printf resta onnipresente, stabile e disponibile quasi ovunque, ma la sua sintassi e il comportamento variadico comportano rischi noti.
Le librerie wrapper C possono migliorare la sicurezza tramite annotazioni del compilatore o interfacce generate. fmt-c applica invece la selezione generica C11 e la sintassi di formattazione esistente del progetto.
Resta ignoto se questo approccio otterrà un'adozione significativa in C. Il risultato Trending di settembre misura la curiosità, non un uso duraturo della nuova API.
I dati dei package manager offrirebbero un segnale di adozione più forte. Lo farebbero anche gli aggiornamenti delle dipendenze downstream, esempi ripetuti nella community e report di compatibilità da grandi codebase C.
Finché questi elementi non emergeranno, la classifica va letta soprattutto come un evento di scoperta. Ha riportato una libreria consolidata nel percorso degli sviluppatori che esplorano repository attivi.
Questo resta strategicamente importante per l'open source. I progetti maturi competono per l'attenzione dei manutentori, i contributori, la diversità dei test e la visibilità mentale accanto ai repository più nuovi.
Un breve picco può portare nuove segnalazioni di issue e patch. Può anche attirare utenti che si aspettano supporto senza comprendere la capacità del progetto.
I manutentori affrontano quindi un compromesso tra l'espansione dell'interfaccia e la preservazione della prevedibilità che gli utenti consolidati apprezzano. fmt 12.2 tenta entrambe le cose attraverso nuove superfici e correzioni mirate.
Tre segnali mostreranno se l'attenzione durerà
Il prossimo test non è la classifica Trending di domani, ma se l'attenzione si trasformerà in release, adozione downstream e risultati credibili tra toolchain diverse.
Il primo segnale è fmt 12.2.1. Il changelog del progetto etichetta questa versione come imminente e registra già correzioni e aggiunte.
Una patch release tempestiva mostrerebbe che i manutentori stanno trasformando il feedback successivo alla 12.2 in un pacchetto stabile. Ritardi prolungati aumenterebbero l'importanza di usare commit non rilasciati o mantenere patch locali.
I contenuti contano quanto la tempistica. I team dovrebbero osservare se le correzioni elencate per pipe chiuse, formattazione, CMake e moduli arriveranno senza introdurre comportamenti incompatibili.
Questo segnale rafforzerebbe la narrazione sulla manutenzione. Non dimostrerebbe che l'apparizione in Trending abbia aumentato direttamente l'attività di sviluppo.
Il secondo segnale è l'adozione di fmt-c. Cercate aggiornamenti di pacchetti, repository C downstream, esempi nella documentazione e segnalazioni di issue basate su deployment reali.
Alcune dimostrazioni possono validare la sintassi, ma un uso ripetuto tra compilatori e sistemi operativi testerebbe la portabilità pratica dell'interfaccia.
La domanda chiave è se gli sviluppatori C accetteranno una nuova dipendenza per la formattazione guidata dai tipi. Le codebase esistenti hanno investimenti profondi in printf, wrapper e logging specifico della piattaforma.
Se fmt-c comparirà in progetti downstream significativi, l'attenzione di settembre sembrerà collegata a una reale espansione. Se l'adozione resterà limitata, rimarrà un esperimento degno di nota.
Il terzo segnale è il movimento tra fmt e le funzionalità della libreria standard. Le release dei compilatori e i cambiamenti nelle baseline dei progetti renderanno std::format e std::print disponibili a più team.
Alcune codebase migreranno verso lo standard. Altre manterranno fmt per piattaforme più vecchie, API aggiuntive o un accesso più rapido alle correzioni.
I report pubblici sulle migrazioni possono rivelare quali vincoli prevalgono. I test comparativi dovrebbero includere tempo di build, dimensione del binario, throughput di formattazione, portabilità e impegno di manutenzione.
Un'ondata di migrazioni alla libreria standard indebolirebbe l'argomento a favore di fmt come dipendenza predefinita. Non ne cancellerebbe il ruolo di riferimento implementativo e sede di sviluppo.
Una continua adozione di fmt mostrerebbe che la sola disponibilità degli standard non risolve le scelte infrastrutturali. La cadenza dei rilasci e gli ambienti supportati resterebbero decisivi.
Gli sviluppatori che valutano fmtlib fmt dovrebbero quindi ignorare la tentazione di trasformare il primo posto in classifica in un verdetto. Partite dalle modifiche della 12.2, poi riproducete i test rilevanti all'interno della vostra build.
Verificate il compilatore più vecchio che supportate. Testate i moduli solo dove l'intera toolchain li supporta e analizzate le modifiche a livello di patch prima di aggiornare i sistemi di produzione.
Per i progetti C, prototipate fmt-c su percorsi reali di logging o diagnostica anziché su esempi isolati. Misurate avvisi, dimensione dell'eseguibile, throughput e comportamento in caso di errore.
La classifica di settembre ha fornito uno spunto utile, non una risposta. La vostra prossima baseline della toolchain renderà sufficiente la formattazione standard, oppure fmt risolve ancora oggi un concreto problema di compatibilità?
