Análisis crítico de V 0.4.3: documentación inconsistente y gestión de memoria problemática
Un repaso de seis meses sobre V revela lagunas en la docs y fallos de memoria en los modos manual y autofree.
El autor de la reseña ha pasado medio año evaluando V (commit b66447cf11318d5499bd2d797b97b0b3d98c3063) y publica un informe que cubre documentación, tipos básicos y, sobre todo, gestión de memoria. La conclusión es clara: los modos manual y autofree todavía presentan fugas que hacen inviable su uso en aplicaciones reales.
Documentación y tipos básicos
V agrupa toda su referencia en un único archivo docs.md. Entre los primeros capítulos aparecen los tipos i128 y u128 con el prefijo soon, indicando que aún están en desarrollo. Otro punto curioso es que int era siempre de 32 bits, pero a partir de la versión 0.4.3 se vuelve de 64 bits en sistemas de 64 bits y mantiene 32 bits en arquitecturas de 32 bits. La documentación rara vez menciona estos cambios, lo que obliga al desarrollador a buscar información en los commits o en Discord.
Gestión de memoria: modo manual
En el modo manual V delega todas las asignaciones a malloc y deja la responsabilidad de liberar la memoria al programador. El artículo muestra varios casos donde funciones aparentemente inocuas, como string.is_ascii(), generan fugas porque internamente usan bytes() sin liberar el buffer resultante. El problema se extiende a la biblioteca estándar y a frameworks como vweb: los ejemplos oficiales crean objetos que nunca se liberan, provocando pérdidas de memoria en servidores web y en utilidades de línea de comandos.
Gestión de memoria: modo autofree
El modo autofree se activa con la bandera -autofree y, según la documentación, debería liberar entre el 90 % y el 100 % de los objetos mediante llamadas a free insertadas por el compilador, dejando el resto al recolector de basura (GC). En la práctica, el autor encontró que sólo el 0,1 % de los objetos se liberaron automáticamente, mientras que el 99,9 % dependió del GC. Un test con Valgrind mostró una fuga de 2 bytes en un programa mínimo que imprime un struct con un []bool.
Impacto para los equipos de desarrollo
Para los equipos que consideran V para proyectos críticos, la revisión sugiere que la promesa de una gestión de memoria sin GC todavía está lejos de cumplirse. La documentación incompleta y la escasa atención a los detalles de la biblioteca estándar hacen que sea necesario invertir tiempo adicional en auditorías de memoria, especialmente si se opta por el modo manual.
En resumen, V 0.4.3 ofrece una sintaxis atractiva, pero la inmadurez de su ecosistema –documentación, tipos y gestión de memoria– limita su adopción en entornos de producción. Queda por ver si futuras versiones cumplirán con las expectativas de los desarrolladores y cerrarán las brechas señaladas en esta revisión.
