RDF, Typescript and Deno - Part 3b

One of my all-time favourite programming languages is Prolog. In Prolog terms, my investigation of RDF, Typescript and Deno has reached this step:

  !,
  fail.

“Cut, fail” indicates to the Prolog interpreter to stop exploring this branch of the evaluation tree, and go back to a previous choice point to try a different path. It won’t cause the program to halt altogether (unless the program has run out of choices to make), but will make it back up to a previously non-cut choice point.

So to make this relevant to the topic at hand (finally!): I’m giving up on Deno as vehicle for exploring the JavaScript rdflib package. Deno is, for certain purposes, great. rdflib is, for certain purposes, great. They just don’t play nice together.

Some of the issues I ran into included:

What I did like

There are definitely things to like about Deno. It’s fast. It’s nicely optimised for running small scripts effectively: I would imagine that it’s a perfect vehicle for AWS Lambda functions, for example. When the type checking is working (see above), it works well in VsCode. It’s nice not having to start a project with a load of package.json wrangling. The security model is a good idea in principle, although I’d anticipate adding --allow-read, --allow-net, etc, as reflexes without properly thinking about it. The weakest part of any security protocol is the humans!

For all of the good things above, I think (extrapolating from just one data point: always a dubious idea!) that Deno isn’t going to be a good choice for large NPM modules or libraries that were written firmly during a “pick any runtime engine you like, as long as it’s Node” era. Which means waiting for libraries to get updated or rewritten, or taken on writing that functionality yourself. For something big and hairy like RDF (and SPARQL, and JSON-LD, and etc etc) that’s a deal-breaker for most teams and non-superhuman individuals.

What next

To ponder. I still have a desire to write an rdflib tutorial, because there aren’t many good ones around. On the other hand, I’m not that into writing in Node Express. Previous to this experiment with Deno, my tools-of-choice for writing the server-side element of an app were Ruby-on-Rails or Python Flask.

All-in-all, I’m glad I tried the experiment. And I might come back to Deno in future, to see if the integration with larger NPM modules has changed significantly.

I am not done with Deno (see what I did there? :))

 newer · index · older