Gnu Octave Meets Jupyterlite: Compute Anywhere, Anytime
Posted3 months agoActive3 months ago
blog.jupyter.orgTechstory
excitedpositive
Debate
20/100
JupyterliteGnu OctaveScientific ComputingOpen Source
Key topics
Jupyterlite
Gnu Octave
Scientific Computing
Open Source
The integration of GNU Octave with JupyterLite enables running Octave code in the browser without servers, sparking excitement and discussion about its potential applications and related technologies.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
3h
Peak period
18
6-12h
Avg / period
7
Comment distribution42 data points
Loading chart...
Based on 42 loaded comments
Key moments
- 01Story posted
Oct 19, 2025 at 11:48 AM EDT
3 months ago
Step 01 - 02First comment
Oct 19, 2025 at 2:36 PM EDT
3h after posting
Step 02 - 03Peak activity
18 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 21, 2025 at 5:42 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45635069Type: storyLast synced: 11/20/2025, 1:42:01 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Octave could be embedded as a C library for some time:
https://stackoverflow.com/questions/9246444/how-to-embed-the...
https://docs.octave.org/latest/Standalone-Programs.html
There is an OpenCL package to provide GPU acceleration:
https://gnu-octave.github.io/packages/ocl/
Unfortunately it looks like they did it wrong, by providing explicit GPU types and functions, instead of converting unmodified Octave code to run directly with GPU acceleration implicitly:
https://octave.sourceforge.io/ocl/function/oclArray.html
It would be awesome if Octave got implicit GPU acceleration in the browser with something like OpenCL. Unfortunately it looks like OpenCL was never ported to WebGL, so WebCL isn't implemented yet:
https://en.wikipedia.org/wiki/WebCL
https://www.khronos.org/webcl/
WebCL is apparently being replaced by WebGPU:
https://stackoverflow.com/questions/11532281/how-to-use-webc...
https://gpuweb.github.io/gpuweb/
https://developer.chrome.com/docs/capabilities/web-apis/gpu-...
- unsolicited opinion -
It's always astonishing to me how the obvious path is rarely taken by industry, because writing open solutions is self-evidently less profitable than writing proprietary ones. Look up the history of the blue LED and countless other innovations to see how that works and why.
I'm hopeful that AI will relieve programmer burden enough that we can explore these obvious roads not traveled. Because we're off on a very long tangent from what mainline computer science evolution might have looked like without tech's wealth inequality.
Unfortunately I see two major (rarely discussed) pitfalls looming with AI:
1) Every tech innovation brings a higher workload for the same pay. The amount of knowledge required to be a full stack developer in 2025 in higher than in 2015, which was higher than in 2005, which was higher than in 1995, and so on. Yet starting pay has not increased with inflation.
2) With AI bringing pair programming everywhere, we may see a decline in overall code quality if humans don't have to deal with it directly. Extended pair programming can lead to over-engineered codebases that can only be read by teams of humans instead of individuals. So whereas one untrained hobbyist could build a website in 1995 using principles like data-driven design, declarative programming and idempotence, today it requires a team to untangle the eventualities of imperative nondetermistic async code that from a user perspective is equivalent to simply hiding the progress bar in the browser.
That's why I'm such a proponent of alternative methods. Abstractions that are quite verbose to represent in, say, Python, can be expressed as one-liners in Octave. The only way to get more concise would be to move towards more of a functional assembly language like Lisp, at the cost of the syntactic sugar provided by array-based languages.
TL;DR: I believe that the most direct path from J.A.R.V.I.S./Star Trek style AI prompts to readable but efficient code is through DSLs like Octave/MATLAB, and some of the lost ways of doing business logic in the 1980s like Spreadsheets, HyperCard and Microsoft Access or FileMaker. Open tools like a GPU accelerated Octave would help us gain more leverage in writing software and possibly speed the evolution of AI itself by helping us more closely express abstractions in code.
This strongly agrees with you: https://alexalejandre.com/languages/end-of-programming-langs...
See https://stackoverflow.com/questions/12084246/differences-bet...
Anyone who runs up against a limitation of Octave has probably hit the point where they should consider switching, but not to Matlab or some other scripting language, but to Fortran or maybe Julia or something.
Therefore, I disagree with the accepted answer in that StackOverflow thread. The language is only good in the first place for short codes anyway, so fixing any little octave/matlab regionalisms is not a big deal. And, since it is a mathematical experiments, you should understand what every line of code does, so running the code without reading it is not really an option.
Python is trash, by comparison.
You also don't have the rats nest that is python environment and package management.
Just objectively not an accurate description of Python
There's plenty of satellites, rockets, re-entry vehicles whose guidance and control code were designed and written using MATLAB/Simulink and then "autocoded" to C using "MATLAB Coder".
While not my preferred way of doing things, it is popular for this purpose throughout the aerospace industry.
The language itself is awful.
As a programming language freak, I must disagree... in what other programming language can you solve a linear system Ax=b in one line
without any external libraries or imports, just with the base language?I never used any official matlab "toolbox", but still love the language via the octave interpreter. It's so clean and straightforward!
Why does this matter in the least? Like you must understand that this is a library call right? Like just put `import numpy as np` in your PYTHONSTARTUP and it's the exact same UX in python.
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONST...
Not a general purpose one, but good enough.
Also, qalc from libqalculate for trivial stuff.
(Source: I did a PhD using a mixture of Octave for numerical stuff, Perl for text-processing and automation, and C++ for the parts that were too slow. Choose the right tool for the job.)
Most people encounter large FORTRAN IV or FORTRAN 77 heirloom codes, and assume that's what Fortran is like in 2025.
YouTube playlist: https://www.youtube.com/playlist?list=PLiPvV5TNogxIS4bHQVW4p...
Using Octave for a beginning ML class felt like the worst of both worlds - you got the awkward, ugly language of MATLAB without any of the upsides of MATLAB-the-product because it didn't have the GUI environment or the huge pile of toolbox functions. None of that is meant as criticism at Octave as a project, it's fine for what it is, it just ended up being more of a stumbling block for beginners than a booster in that specific context.
It comes with vendor support and "official-ness" for lack of a better word.
Things are changing rapidly in this area but it wasn't very long ago that most people reacted to open-source software as something weird that shouldn't be trusted.
Python is not a particularly fast language in the first place due to bad utilization of memory, hash table lookups everywhere and a high function call overhead.
It is a great example of GNU's contribution to the advancement of human kind.
It is highly recommended for numerical mathematics and can be extended with GNU-Fortran or GNU-C. It comes bundled with many extensions.
It is mostly a DSL for numerics.
Scilab is another recommended similar package but comes with less extensions.
* c++ * python * R * lua * javascript
Try them here:
* https://jupyter.org/try-jupyter/lab/ * https://jupyterlite-xeus.readthedocs.io/en/stable/lite/lab/i...
Or create your own deployments by using this template repo: * https://github.com/jupyterlite/xeus-lite-demo