Zasper - uma alternativa moderna e eficiente ao JupyterLab desenvolvida em Go

• O Zasper é uma IDE projetada para suportar alta concorrência
  • Oferece consumo mínimo de memória e excelente desempenho, lidando com múltiplas conexões simultâneas
  • Adequado para executar aplicações de dados no estilo REPL, como Jupyter Notebooks
• Atualmente tem suporte completo no Mac e suporte limitado no Linux
• Benchmark
  • O Zasper usa 4x menos RAM e CPU em comparação com o JupyterLab.
  • O JupyterLab usa cerca de 104,8 MB de RAM e 0,8 CPU, enquanto o Zasper usa 26,7 MB de RAM e 0,2 CPU.
• Motivos para criar o Zasper
  • Há ferramentas front-end similares ao JupyterLab no mercado, como Databricks Notebooks e Deepnote Notebooks, mas a maioria não é gratuita e exige trabalho na nuvem.
  • O Zasper funciona suavemente na máquina local e garante máxima eficiência ao aproveitar efetivamente os recursos disponíveis.
  • A linguagem Go fornece ótimo suporte para protocolos REST, RPC e WS, e se destaca em concorrência e desempenho.
  • Python é adequado para tarefas assíncronas centradas em I/O, mas tem limitações para cargas de trabalho centradas em CPU.
• Oferece diversos recursos, incluindo editor, terminal, launcher, Jupyter Notebook, controle de versão, paleta de comandos e modo escuro
• Oferecido em duas modalidades: app Electron e app web
• Roadmap
  • O Zasper tem como objetivo ser um ecossistema de IDE para cientistas de dados e engenheiros de IA, com as próximas direções de desenvolvimento como:
    • Suporte a aplicações de dados personalizadas, não apenas Jupyter Notebooks
    • Facilitar a integração com ferramentas existentes
    • Fornecer o Zasper Hub para implantação self-hosted na nuvem

[GN⁺]

Opinião no Hacker News

• O autor do Zasper afirmou que o processamento do kernel Jupyter do Zasper é construído com goroutines em Go e é melhor do que a abordagem em Python do JupyterLab.

  • O Zasper usa cerca de 1/4 da RAM e da CPU em comparação com o JupyterLab.
  • Recursos como busca ainda não foram otimizados e ainda são lentos.
  • Está sendo desenvolvido em tempo integral por uma única pessoa e deve melhorar com o tempo.
  • Espera uma reação positiva para a primeira versão.

• O Marimo chama a atenção como uma alternativa ao Jupyter que combina as vantagens do Streamlit e do Jupyter.

• Questionaram se a redução de memória e CPU é realmente significativa.

  • Como o código Python usa mais recursos, não está claro o quanto a multithreading do Go ajuda.

• Há a opinião de que, embora o JupyterLab seja antigo, ele continua moderno graças ao desenvolvimento contínuo.

• Foi apontado que a alternativa só funciona no macOS, com suporte parcial no Linux e suporte apenas ao IPython.

  • Mencionou-se que o ganho de desempenho do Go é compensado pelo uso do Electron.

• Explicaram que querem uma interface parecida com o RStudio no Jupyter e que é importante ter uma funcionalidade para executar blocos de código.

  • Gostam da função "open console for notebook" do JupyterLab, mas não conseguiram descobrir como enviar texto ou alternar o foco por atalhos de teclado.
  • Por esse motivo, não usam a implementação do Jupyter do VSCode.

• Foi sugerido que seria interessante considerar o Wails para a interface do usuário.

  • Apesar do grande esforço dedicado ao Go, lamentaram o uso do Electron.

• Perguntaram quais seriam as vantagens em comparação com o suporte de notebook do Jupyter no VSCode.

• Perguntaram se a saída é perdida quando uma conexão ativa de frontend é desconectada e reconectada.

• Parece um projeto que substitui o frontend do JupyterLab e mantém a conexão com o kernel do Jupyter.

  • Em teoria, parece que seria possível suportar também kernels de JavaScript e outras linguagens.
  • Foi mencionado que o projeto foi testado apenas com o kernel IPython e demonstrou interesse em como ele pode evoluir.