Zasper - Un reemplazo moderno y eficiente de JupyterLab desarrollado en Go

• Zasper es un IDE diseñado para soportar alta concurrencia
  • Ofrece un uso mínimo de memoria y un rendimiento sobresaliente, y maneja múltiples conexiones concurrentes
  • Es adecuado para ejecutar aplicaciones de datos con estilo REPL, similar a Jupyter Notebook
  • Actualmente tiene soporte completo en Mac y soporte limitado en Linux
• Benchmark
  • Zasper usa 4 veces menos RAM y CPU que JupyterLab.
  • JupyterLab usa alrededor de 104,8 MB de RAM y 0.8 de CPU, mientras que Zasper usa 26,7 MB de RAM y 0.2 de CPU.
• Por qué se creó Zasper
  • En el mercado existen herramientas frontend similares a JupyterLab como Databricks Notebooks y Deepnote Notebooks, pero la mayoría no es gratuita y obliga a trabajar en la nube.
  • Zasper funciona sin problemas en la máquina local y aprovecha eficazmente los recursos disponibles para garantizar la máxima eficiencia.
  • Go ofrece un excelente soporte para los protocolos REST, RPC y WS, destacando por su concurrencia y rendimiento.
  • Python es adecuada para tareas asíncronas centradas en I/O, pero tiene límites en trabajos centrados en CPU.
• Ofrece funciones como editor, terminal, lanzador, Jupyter Notebook, control de versiones, paleta de comandos y modo oscuro
• Disponible en dos formatos: app de Electron y app web.
• Hoja de ruta
  • Zasper apunta a una ecosistema IDE potente para científicos de datos e ingenieros de IA, y su desarrollo futuro contempla lo siguiente:
    • Soporte para apps de datos personalizadas, además de Jupyter Notebook
    • Facilitar la integración con herramientas existentes
    • Proveer Zasper Hub para despliegue con autoalojamiento en la nube

[GN⁺]

Comentarios de Hacker News

• El autor de Zasper explicó que el manejo del kernel de Jupyter en Zasper está construido con goroutines de Go y que es mejor que el enfoque de Python de JupyterLab.

  • Zasper usa aproximadamente 1/4 de RAM y CPU en comparación con JupyterLab.
  • Funciones como la búsqueda aún no están optimizadas y aún se sienten lentas.
  • Está siendo desarrollado a tiempo completo por una sola persona y se mejorará en el futuro.
  • Espera recibir una buena respuesta ante este primer borrador.

• Marimo llamó la atención al parecer una alternativa a Jupyter que combina lo mejor de Streamlit y Jupyter.

• Se cuestionó si la reducción de memoria y uso de CPU realmente importa.

  • Dado que el código de Python consume más recursos, no está claro cuánto ayuda el threading de Go.

• Hubo una opinión de que, aunque JupyterLab es viejo, se mantiene moderno gracias a su desarrollo continuo.

• Señaló que la alternativa solo se ejecuta en macOS, tiene soporte parcial en Linux y solo admite IPython.

  • Comentó que el rendimiento adicional de Go podría estar siendo contrarrestado por el uso de Electron.

• Explicó que quería una interfaz tipo rstudio en Jupyter y que es importante poder ejecutar bloques de código.

  • Le gustó la función "open console for notebook" de JupyterLab, pero no pudo encontrar cómo enviar texto o cambiar el enfoque con atajos de teclado.
  • Por esta razón, no usa la implementación de Jupyter de VSCode.

• Sugirió que consideraran Wails para la UI.

  • Se mostró decepcionado de que se haya usado mucho esfuerzo en Go y aún así se haya optado por Electron.

• Se preguntó qué ventajas tiene frente al soporte de notebooks Jupyter en VSCode.

• Preguntó si, al desconectar y reconectar desde un frontend en ejecución, la salida se pierde.

• Vio esto como un proyecto para reemplazar el frontend de JupyterLab y mantener la conexión con el kernel de Jupyter.

  • Teóricamente podría dar soporte a kernels de JavaScript y otros lenguajes.
  • Mencionó que el proyecto se probó solo con el kernel IPython y mostró interés en su dirección futura.