Rust 1.78 is available for this platform, so we’ll build Deno from its sources via Rust.

First, if you haven’t already, install Rust following the very simple directions on the Rust website ( https://www.rust-lang.org/learn/get-started ). Be advised that you’ll need to install curl and protobuf-compiler; the first to handle the installation of Rust, and the second to handle the build of deno. You should install these two packages before installing Rust and then using Rust to build deno.

After installing the two packages mentioned earlier and then installing Rust, perform cargo install deno and then go away for about 45 minutes until it’s done.

Why do it this way? First because you should install Rust, and install it locally to your login account, not globally. Second, because once again if you use apt to install rust, you only get version 1.74, not the current 1.78 stable release. When you install rust using the website’s method, you also get rustup, which allows you to keep your copy of Rust up-to-date. And if you want to do any kernel development you’ll need an up-to-date kernel (which you do have) and versions of Rust greater than or equal to version 1.77. Third, when you build deno yourself you get a whole slew of Rust crates that you can tinker with in other projects. Finally, you should use deno over node.js because the same creator of node, Ryan Dahl, is also the creator of deno; deno is far more robust and secure than node.js.

Finally, to learn more about deno and how to use it, go to https://docs.deno.com/runtime/manual and have at it.

It’s been a while since I built Deno via Rust’s cargo. Once it’s installed you can run deno upgrade and it will pull down the latest release and install it for you. That works pretty well for any supported environment, unless you’re using Ubuntu 23.10 on a Raspberry Pi 5. If you try to install Deno the officially documented way, you get the following:

Error: Official Deno builds for Linux aarch64 are not available.

Which means you’re going to build it from source. Fortunately Rust is available for this environment or else this post wouldn’t be here.

While building Deno I did run into one significant problem. The build failed right in the middle:

A little bit of search led me to install protoc via sudo apt install protobuf-compiler. Once installed I followed the directions about setting CARGO_TARGET_DIR and restarted the build, which then went on to build successfully. I checked for life:

$ which deno/home/pi/.cargo/bin/deno$ deno --versiondeno 1.40.2 (release, aarch64-unknown-linux-gnu)v8 12.1.285.6typescript 5.3.3

And now I’m the proud “owner” of Deno on this Raspberry Pi 5. By the way, if you want to see how the Raspberry Pi handled the task, here’s a taste of it via btop:

You’ll note that all four cores on the processor are running 100%, yet the temperature was around 60°C. This shows how well the active cooling is working on the Raspberry Pi 5.

I have moved away from Node to Deno in part because I can clone the entire Deno source tree and play around in it, and in part because over time I’ve grown tired of Node and its various peculiarities. I can do this because I’m retired, but if I ever decided to venture out back into the world I sincerely doubt that my Deno skills would be consider an asset; the world seems to run overwhelmingly on Node.

While I was tinkering with Deno I kept wondering where its name came from. As I sat staring at the screen, I noticed that Deno has the same four letters as Node, and that Deno is spelled in alphabetical order. That’s when I suddenly tried this:

Both Node and Deno will evaluate the same JavaScript function on the command line, which is: split the string ‘node’ into a list of individual ASCII characters, sort the list, then join the sorted list back into a string. I have no idea if this is what Ryan Dahl did, but it seems a simple enough thing to do.

Unfortunately that doesn’t mean I’ve been using Deno. After my initial infatuation with Deno I left my work with Deno to rest idle. I had lots of grand ideas, but right now I’ve not got much to show for it except a bunch of small to medium sized incomplete (and I’m being charitable by calling them incomplete) projects. Because I’m building a head of steam around Micro Python and Circuit Python embedded work, I thought I’d create a local HTTPS server to handle all of them. A tiny cloud, if you will.

So I dusted off one of the promising incomplete projects and began to work with it again. That’s when I ran into errors all over the place with code that did work when I stopped. As usual I whittled one of the problems down to a few lines of example code that would produce one of the errors. Here’s what it looks like.

import { serve } from "https://deno.land/std/http/server.ts";const server = serve({ port : 8000 });for await (const server_request of server) {server_request.respond({ body: "Deno server instance created\n" });}

Running it produces the following:

opos@fedora:~/Develop/DenoWork$ deno run --allow-net my-server-bad.js Listening on http://localhost:8000/error: Uncaught TypeError: server is not async iterablefor await (const server_request of server) {   ^at file:///home/popos/Develop/DenoWork/my-server-bad.js:3:36

So code that once worked no longer does. Line 3 in the source is the culprit. So I go googling and rapidly find the solution on Stack Overflow ( https://stackoverflow.com/questions/70963882/deno-serve-imported-from-std-http-server-ts-is-not-async-iterable ). Sure enough, when I follow the advice in that post and make one change, it works like it did when I put it aside.

import { serve } from "https://deno.land/std@0.106.0/http/server.ts";const server = serve({ port : 8000 });for await (const server_request of server) {server_request.respond({ body: "Deno server instance created\n" });}

The correction was to add the “@0.106.0” version to the import statement in line 1. Just lovely. So, do I go through my code and start locking down versions on everything? Or do I do the right thing and learn the new way of doing things? I’m retired and things like this are my hobby, not a paying job. There’s a part of me that wants to be lazy and just lock everything down and live with that. But there’s the other part that is yelling about being a lazy bum and a hypocrite for wanting the easy way out. I think what I’ll do is sit back for a bit and rethink how I want all of this to be. Maybe if I learn the New Ways, then I should rewrite from the ground up. And this time don’t let it go for over a year.

I’ve been wrestling with building Deno on my Jetson Xavier NX running Nvidia’s version of Ubuntu 18.04.2 as part of L4T, or Linux For Tegra (although I tend to think of ‘T’ for Tensorflow). Deno is a reimplementation, if you will, of NodeJS in Rust, attempting to correct many of the bad design decisions that went into Node over time. Deno was created by Ryan Dahl, the original creator of NodeJS, so he should know where the skeletons of Node are buried.

The problem with installing and working with Deno on the Xavier is that it’s Arm-based, whereas all the other environments are x86-based. You can thus download and update (deno upgrade) Deno natively, whereas on the Xavier you need to install a native distribution of Rust, then build deno on the platform with cargo build deno. This worked for all of deno versions up to 1.6.7, then 1.7 was released and building deno on Arm failed repeatedly due to a failure to build librusty_v8. I filed a bug report over two weeks ago, and then, three days ago, I got a response from one of the devs telling me that there was “no pre-built 0.17.0 static library for aarch64 but there is one if you upgrade to 0.20.0.” Sure enough, when I re-ran cargo build deno and watched the task pull and build all the libraries, it pulled librusty_v8 version 0.20.0, which successfully built along with everything else. I have since closed the bug (see https://github.com/denoland/rusty_v8/issues/630 ).

The big draw for me is Deno’s experimental support for WebGPU API. I ran the example given in the release notes ( https://deno.land/posts/v1.8 ) and copied the results into the top of this post. I doubt that JavaScript running on Deno will replace Python as the front-end for ML running on the Jetson Xavier, but I can see it supporting Python, especially with web-based development. I am no fan of Python’s web frameworks, and I’ve lost my disdain for JavaScript over the past 12 months due to another task that showed I could use minimal JavaScript to cleanly solve a knotty problem. Deno also gives me plenty of powerful examples of programming in Rust, so there’s that angle.

Since retirement I’ve explored more interesting languages and their uses than I ever did in the last five years of my regular employment. It wasn’t so much ageism as it was my employer’s adamant insistence that development was their way or the highway. I’m now free to follow my own path(s) and finding what I’m learning to be new, interesting, and challenging in a good way.