Live data from Hacker News

The Dino, the Llama, and the Whale (Deno and Jupyter for Local AI Experiments)

deno.com

11–16 of 16 posts

Re: The Dino, the Llama, and the Whale (Deno and Jupyter for Local AI Experiments)

#11
post #8
post #3

I have had a quick play around with Deno notebooks. The pain points for me were in image and UI outputs. There is such a large base of support for the Python side, it will take quite a lot of work to catch up. The various python bits seem to be quite dependent on the implementation platform though. Colab, jupyter-lab and integrated into an editor are quite different beasts. Being able to display an entity that carrie…

Can you give an example of UI and image outputs that don't work with deno? I'm truly curious.

In the article, there’s an example where a graph object needs to be:

- converted to png

- converted into a promise of an array buffer

- awaited

- converted into a Uint8Array

- passed to Deno.jupyter.image

Just to display it in the notebook. In Python Jupyter, you can just return many types and the library/Jupyter will figure out how to render them.

A few lines of code isn’t much but in my experience for interactive coding to be productive you have to remove every bit of friction and boilerplate you can.

Re: The Dino, the Llama, and the Whale (Deno and Jupyter for Local AI Experiments)

#14
post #11
post #8

Earlier quoted context omitted.

Can you give an example of UI and image outputs that don't work with deno? I'm truly curious.

In the article, there’s an example where a graph object needs to be: - converted to png - converted into a promise of an array buffer - awaited - converted into a Uint8Array - passed to Deno.jupyter.image Just to display it in the notebook. In Python Jupyter, you can just return many types and the library/Jupyter will figure out how to render them. A few lines of code isn’t much but in my experience for interactive c…

Thanks!

Re: The Dino, the Llama, and the Whale (Deno and Jupyter for Local AI Experiments)

#16
post #4

I like the idea of Jupyter supporting more languages, but isn’t the main issue that most AI tooling is deeply tied to Python? How do we solve that?

By not building tooling in Python.

llamacpp is a high performative open source solution capable of inference of large number of published LL models both in CPU and in GPU. It's written in C++.

It's easy to download and build in Windows or Linux.

It can be used as a command line tool, linked and used as a library from a variety of languages, including Python, or communicated with through a simple REST service which is also part of the same repo. It even has a simple Web frontend (built with React I believe) which allows you to use it for simple conversations (no bells and whistles).

And yet the author is using Ollama which itself is a wrapper around llamacpp (as most of them are) written in Python.

We're creating the problems that need soling.

Post reply on HN