9 điểm bởi GN⁺ 2025-01-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Zasper là một IDE được thiết kế để hỗ trợ đồng thời quy mô lớn
    • Nó cung cấp mức sử dụng bộ nhớ tối thiểu và tốc độ tốt, đồng thời xử lý được nhiều kết nối cùng lúc
    • Phù hợp cho việc chạy ứng dụng dữ liệu kiểu REPL như Jupyter Notebook
    • Hiện tại được hỗ trợ đầy đủ trên Mac, và hỗ trợ giới hạn trên Linux
  • Benchmark
    • Zasper sử dụng RAM và CPU ít hơn 4 lần so với JupyterLab.
    • JupyterLab sử dụng khoảng 104.8 MB RAM và 0.8 CPU, trong khi Zasper sử dụng 26.7 MB RAM và 0.2 CPU.
  • Lý do tạo ra Zasper
    • Trên thị trường có các công cụ giao diện giống JupyterLab như Databricks Notebooks và Deepnote Notebooks, nhưng hầu hết không miễn phí và buộc phải làm việc trên đám mây.
    • Zasper hoạt động mượt mà trên máy cục bộ, tối ưu hóa việc tận dụng tài nguyên sẵn có để mang lại hiệu suất tối đa.
    • Go cung cấp hỗ trợ tuyệt vời cho các giao thức REST, RPC và WS, đồng thời vượt trội về đồng thời và hiệu năng.
    • Python phù hợp với tác vụ bất đồng bộ tập trung vào I/O, nhưng có giới hạn ở các tác vụ dựa trên CPU.
  • Cung cấp nhiều tính năng, bao gồm editor, terminal, launcher, Jupyter Notebook, quản lý phiên bản, command palette, dark mode
  • Có cả dạng ứng dụng Electron và ứng dụng web.
  • Lộ trình
    • Zasper đặt mục tiêu trở thành một hệ sinh thái IDE mạnh mẽ cho nhà khoa học dữ liệu và kỹ sư AI, với định hướng phát triển trong tương lai như sau:
      • Hỗ trợ các ứng dụng dữ liệu tùy chỉnh bên cạnh Jupyter Notebook
      • Tạo điều kiện tích hợp dễ dàng với các công cụ hiện có
      • Cung cấp Zasper Hub để tự triển khai trên cloud

1 bình luận

 
GN⁺ 2025-01-03
Ý kiến trên Hacker News
  • Tác giả của Zasper cho biết xử lý nhân Jupyter của Zasper được xây dựng bằng goroutine của Go, tốt hơn cách tiếp cận của Python trong JupyterLab

    • Zasper tiêu thụ RAM và CPU khoảng 1/4 so với JupyterLab
    • Chức năng tìm kiếm... và các tính năng khác chưa được tối ưu hóa, nên còn chậm
    • Anh ấy đang phát triển toàn thời gian một mình và sẽ cải thiện trong tương lai
    • Hy vọng sẽ nhận được phản hồi tích cực cho bản nháp đầu tiên
  • Marimo thu hút sự chú ý như một giải pháp thay thế Jupyter kết hợp ưu điểm của Streamlit và Jupyter

  • Có người đặt câu hỏi liệu việc giảm sử dụng bộ nhớ và CPU có thực sự có ý nghĩa hay không

    • Do mã Python sử dụng nhiều tài nguyên hơn, chưa rõ threading của Go có giúp ích đến đâu
  • Có ý kiến cho rằng JupyterLab mặc dù đã lâu đời nhưng vẫn hiện đại nhờ được phát triển liên tục

  • Chỉ ra rằng giải pháp thay thế chỉ chạy trên macOS và chỉ hỗ trợ một phần trên Linux, đồng thời chỉ hỗ trợ IPython

    • Việc cải thiện hiệu năng bằng Go được cho là bị triệt tiêu bởi việc sử dụng Electron
  • Cho thấy mong muốn có giao diện tương tự RStudio trong Jupyter, và nhấn mạnh tính năng quan trọng là có thể thực thi các khối mã

    • Thích tính năng "open console for notebook" của JupyterLab, nhưng chưa tìm thấy cách gửi văn bản hoặc chuyển tiêu điểm bằng phím tắt
    • Vì lý do này nên họ không sử dụng triển khai Jupyter trong VSCode
  • Có người đề xuất cân nhắc dùng Wails cho giao diện người dùng

    • Dù đã đầu tư nhiều vào Go, họ tỏ ra tiếc nuối vì lại dùng Electron
  • Hỏi rằng Zasper có lợi thế gì so với cách tích hợp Jupyter Notebook của VSCode

  • Hỏi liệu có mất đầu ra hay không khi ngắt kết nối rồi kết nối lại ở frontend đang chạy

  • Nhìn chung đây có vẻ là một dự án thay thế frontend của JupyterLab trong khi vẫn giữ kết nối với kernel Jupyter

    • Về mặt lý thuyết, nó dường như có thể hỗ trợ kernel JavaScript hoặc các ngôn ngữ khác
    • Họ đề cập rằng dự án hiện chỉ được kiểm thử với kernel IPython, và bày tỏ quan tâm đến hướng phát triển tiếp theo