be careful of library versions and old code with deno

I have always been impressed with Deno ( https://deno.land ). It was designed and implemented as a secure server-side JavaScript and Typescript runtime by the same developer who create Node.js, Ryan Dahl ( https://en.wikipedia.org/wiki/Ryan_Dahl ). I’ve always been impressed by Deno because Deno is written in Rust.

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.

building and running deno 1.8 on a jetson xavier nx

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.