Skip to content

Latest commit

 

History

History
48 lines (33 loc) · 2.37 KB

tonotdo.adoc

File metadata and controls

48 lines (33 loc) · 2.37 KB

deno jekyll

Deno seems to be a forward looking scripting engine:

  • capabilities-based security

  • built-in dependency management

  • ok-ish typed scripting language

  • with WASM, ability to get extra from the CPU and to have better re-usability

Crucially, it has the ability to eval code, which is neat for end-user defined plugins.

It’d be prudent to migrate Jekyll+Asciidoctor setup to Deno

Asciidoc parser

Event-based Asciidoctor parser in Rust will solve one of the major problems of Asciidoctor — the fact that it is tied to the ruby implementation. This asciidoctor spec though, preferably in a way which doesn’t require running arbitrary user code during parsing to deal with macros and includes.

A Shell

Basically, a better shell. Good opportunity to try out Smalltalk?

A Database

  • pure relational model (no nulls and bajilion of slightly different joins)

  • complex domains (user-defined “scalar” types)

  • scriptable: includes a WASM interpreter to specify functions on scalars. No constraints by build-in functions, and a must-have for custom scalar types.

  • non-textual wire format - sending SQL over a socket is just stupid. SQL injection should be impossible, queries should be specified as trees, not as text (like WASM).

  • nice surface language for queries — I strongly dislike SQL’s concrete syntax.

A Garbage Collected functional language

Just to learn how to write complex runtimes.

Rust/Linux

A Rust user-space which runs directly on top of Linux kernel, without libc trying to pretend that it is the interface. Potential benefits:

  • Hackability — written in Rust & builds with cargo build, so everyone can contribute throughout the stack, from pid1 to end-user applications.

  • API stability — there’s user space api usapi crate which is perpetually at 1.x version.

  • ABI stability — program build against 1.x version of usapi is guaranteed to work on all future systems. No glibc like symbol-versioning nonsense, where you have to build on an old system for compatibility — you can just say usapi = "=1.1.0" in your Cargo.toml to target that particular version.

  • Power — the API should be sufficiently powerful to build desktop applications, it should encompass GUI, multimedia, fonts and localization. Bonus points for stdio-based API to write "terminal" applications without escape codes.