Por qué lo dejé todo y empecé a escribir C de nuevo

• Estudió 5 años en una escuela de informática en Francia y trabajó 20 años como desarrollador freelance
• Trabajó principalmente en proyectos de clientes con Ruby on Rails
• Al empezar a aprender Common Lisp, escribió un protocolo de administración de servidores que generaba un parser ASN.1
  • Generó código C desde Common Lisp para desarrollar un servidor SNMP
• Después de eso, escribió varios proyectos basados en Common Lisp:
  • cl-unix-cybernetics – el proyecto con más estrellas en GitHub
  • Desarrollo de cl-streams y cffi-posix
  • cl-facts – un triple store que funciona como una base de datos de grafos en Common Lisp
    • Rápido, con transacciones atómicas y soporte para transacciones anidables
    • Compatible con unwind-protect
    • Se puede usar aprendiendo solo 3 macros
    • Presentado en el European Lisp Symposium (ELS)
• Aunque perdió clientes al enfocarse en el desarrollo con Common Lisp, mantuvo una fuerte convicción en el potencial de Lisp

Límites de las máquinas virtuales (VM) y los contenedores

• Expertos señalan problemas en las VM y los contenedores:
  • Las VM desperdician CPU y ancho de banda innecesariamente
  • Los contenedores basados en cgroups de Linux tienen vulnerabilidades de ejecución remota de comandos (RCE) y escalación de privilegios
  • Cada año se descubren nuevas vulnerabilidades de seguridad
• Al preferir OpenBSD, evitó problemas de herramientas DevOps como Terraform y Ansible

Límites de Common Lisp y problemas de rendimiento

• En Clojure y otros entornos, surgieron problemas de rendimiento por el GC (recolector de basura):
  • Hubo casos de fracaso al desarrollar juegos de estrategia que procesaban miles de unidades
  • El GC de la JVM implica problemas de rendimiento y costo

Decisión de cambiar a C

• Reconoció los límites de rendimiento y portabilidad de Common Lisp:
  • Linux, OpenBSD, GTK+ y GNOME están escritos en C
  • Finalmente cambió a C para resolver los problemas de rendimiento y portabilidad

Desarrollo del nuevo lenguaje KC3

• Desarrollo de la biblioteca de utilidades libc3 → lenguaje C3 → renombrado a KC3
• Características de KC3:
  • Tiene intérprete (ic3) y compilador (c3c)
  • Crea estructuras de datos desde buffers UTF-8 y las convierte de vuelta
  • Programación defensiva → minimización de bugs desde el inicio
  • Sin problemas de seguridad
  • Sistema de tipos basado en union etiquetadas con enum

Logros basados en KC3

• cl-facts porteado a C89:
  • Desarrollo completado durante el periodo de Covid-19
  • Implementación de adición de triples, borrado, sistema de consultas recursivas, transacciones, logging, persistencia, etc.
• Escritura de parser y generador para tipos algorítmicos:
  • Incluye structs, listas enlazadas, maps, tablas hash, números complejos, tuplas, bloques de código, etc.
  • Recibió gran inspiración de José Valim (creador de Elixir)
• ikc3 – un REPL que muestra los resultados de evaluación de KC3
• kc3_httpd – desarrollo de un servidor web basado en un framework MVC
  • La página del blog actual también se sirve con kc3_httpd
• Creación de un sitio web de documentación → uso del convertidor de Markdown a HTML de KC3

Conclusión

• Cambió a C con base en la experiencia obtenida en Common Lisp
• KC3 logra resultados sobresalientes en rendimiento, seguridad y portabilidad
• Planea ofrecer más macros y ejemplos relacionados con KC3 en el futuro

[GN⁺]

Comentarios en Hacker News

• Estoy en desacuerdo. Usé mucho VB cuando era joven, luego aprendí Java, C y C++ en la universidad, y usé principalmente C.

  • Me convertí en desarrollador principal de Xfce y trabajé en ello durante 5 años.
  • Después cambié al desarrollo backend y usé Java, Scala y Python. Estos lenguajes traen otros problemas, pero me gustaban sus bibliotecas estándar y sus sistemas de gestión de dependencias.
  • Volví a Xfce 12 años después, y C sigue siendo difícil. Hay muchos problemas como fugas de memoria, desreferencias de punteros NULL y condiciones de carrera.
  • Al usar Rust, he sido más productivo que con C.

• Me identifico totalmente con ese sentimiento. Durante años sentí un fuerte impulso de desarrollar algo en C puro.

  • Mi lenguaje principal es C++, pero realmente disfruto usar bibliotecas antiguas de C. Sus interfaces son simples y básicas.
  • Cuando desarrollo métodos en C puro, me gusta poder concentrarme 100% en los algoritmos.
  • C me obliga a hacer el trabajo por mí mismo. No oculta la magia ni la complejidad.
  • La gente a mi alrededor intenta usar las funciones más modernas de C++, pero yo cada vez intento quitar más características de C++.

• Empecé a programar en C hace mucho tiempo, y todavía a veces quiero volver a esa época.

  • Pero cuando realmente intento escribir una aplicación lista para producción en C, me doy cuenta de por qué lo dejé.
  • Hay demasiadas cosas que uno tiene que hacer por su cuenta, sin ayuda de la computadora.
  • Si hoy tuviera que elegir un lenguaje de bajo nivel, probablemente elegiría Ada. Es parecido a C, pero con mucho más apoyo del compilador.

• Después de leer la entrada del blog, me quedé confundido sobre lo que el autor quería transmitir.

  • Me pregunto si la razón por la que su programa no se usa realmente tiene que ver con el lenguaje.
  • Puede haber problemas relacionados con el consumo de memoria.
  • El autor no mencionó lecciones aprendidas ni estadísticas de usuarios.
  • No se añadieron funciones nuevas; parece que solo lo reescribió como ejercicio.

• Se dio un ejemplo de código de kc3.

• C fue mi primer lenguaje, e hice aplicaciones simples de consola y juegos pequeños.

  • Pero no quiero volver. Las herramientas de compilación y la gestión de dependencias están anticuadas.
  • Zig es mi nuevo C. Incluye un compilador de C y permite usar headers de C sin wrappers.
  • Uso Go cuando necesito un lenguaje simple, y Rust cuando necesito rendimiento y seguridad.

• A veces programo en C como hobby. Pero hay demasiado trabajo repetitivo y se vuelve aburrido.

  • Escribir un compilador en C es como lidiar con uniones etiquetadas.
  • Pensé en escribir un generador para reducir el trabajo repetitivo, pero todavía no lo he hecho.
  • Al desarrollar proyectos en C, he considerado usar un lenguaje embebido para prototipado.

• C tuvo éxito porque era práctico.

  • No es seguro, pero te deja hacer lo que quieras.

• No entiendo nada.

  • Me pregunto qué es la killer app, cuáles son los problemas relacionados con CL y si C era la única opción.
  • También me pregunto si realmente está seguro de que no hay problemas de seguridad al ejecutar el código de KC3.

• Este texto se lee como una historia de advertencia sin final feliz.