75b12c28e4a338a5675fb7380f6f69c1370ceb57 — EuAndreh 9 months ago 6fd412e + e8d9017
Merge branch 'wip'
A _drafts/2020-02-11-on-webassembly-killing-javascript.md => _drafts/2020-02-11-on-webassembly-killing-javascript.md +205 -0
@@ 0,0 1,205 @@
title: On WebAssembly killing JavaScript
date: 2020-02-11
layout: post
lang: en
ref: on-webassembly-killing-javascript
When discussing WebAssembly (WASM), I often see people portraiting it too much
as a JavaScript replacement, but I think this framing misses the point of some
of the aspects on how WASM can be a great tool: being a portability oportunity,
which means increasing the reach to code.

If you think of WASM strictly as a optimization of JavaScript, that's where
you'll end up: WASM is the same as JavaScript, but faster.

But there's a more interesting aspect (to me) of it: portability. That means you
can now write multiplatforme code that runs everywhere. I mean, everywhere, even
in the browser. Let's imagine how you could write SQLite and mke it run on the Web.

# SQLite

If I were to create, say, SQLite today, I would consider adding web support for
it. SQLite already is available almost everywhere[^1]. This is due to it having
very so few dependencies,

Imagine having writing SQLite today

There are also other legimate uses of WASM, such as WASI and etc.

Here's how I would start writing an application that could run on any POSIX
system and, on top of that, could run on the browser:

// api.h

extern void platformDependentPersistInt(int);
extern int platformDependentRetrieveInt();

// api-posix.c

/* POSIX implementation of "api.h" interface to be used in non-web contexts */

#include <stdio.h>

void platformDependentPersistInt(int n) {
  FILE* fp = fopen("/tmp/persisted.txt", "w+");
  fprintf(fp, "%d", n);

int platformDependentRetrieveInt() {
  FILE* fp = fopen("/tmp/persisted.txt", "r");
  int persisted = fgetc(fp);
  return persisted;

// api-wasm.js

/* WASM implementation of "api.h" interface to be used in web contexts */

export const platformDependentPersistInt = (n) =>
  localStorage.setItem("persisted", n.toString());

export const platformDependentRetrieveInt = () =>

// add.h

int add(int a, int b);
void persistInt(int n);
int retrieveInt();

// add.c

#include "api.h"

int add(int a, int b) {
  return a * a + b;

void persistInt(int n) {

int retrieveInt() {
  return platformDependentRetrieveInt();

// main.c

#include <stdio.h>
#include "add.h"

int main() {
  int added = add(4, 5);
  printf("Adding 4 and 5: %d\n", added);

  int persisted = retrieveInt();
  printf("Persisted number: %c\n", persisted);
  return 0;

// index.html

<script type="module">
 import * as api from "./api-wasm.js";

   .instantiateStreaming(fetch("add.wasm"), { env: api })
   .then(({instance: {exports}}) => {
     const added = exports.add(4, 5);
     console.log("Adding 4 and 5:", added);

     const persisted = exports.retrieveInt();
     console.log("Persisted number:", persisted);

In order to
// server.py

#!/usr/bin/env python
import SimpleHTTPServer
import SocketServer

PORT = 8001

class Handler(SimpleHTTPServer.SimpleHTTPRequestHandler):

Handler.extensions_map['.wasm'] = 'application/wasm'

httpd = SocketServer.TCPServer(("", PORT), Handler)

print "serving at port", PORT

Dependency graph:
api-posix.c api-wasm.js
main.c index.html

Compiling and running the POSIX code:
$ clang -o add main.c add.c api-posix.c
$ ./add
Adding 4 and 5: 21
Persisted number: 6

Compiling and running the WASM
$ clang                   \
    --target=wasm32       \
    -nostdlib             \
    -Wl,--no-entry        \
    -Wl,--export-all      \
    -Wl,--allow-undefined \
    -o add.wasm           \
$ ./server.py

After opening the browser, the console shows:
Adding 4 and 5: 21
Persisted number: 6

Rust, C, Zig

No Emscripten, no GC, no runtime

Emscripten 11KB

# Limitations

"System call" cost in WebAssembly.

WASM is very new, no flush guarantees.

Confusing dependency tree

AFAICT you can't package WASM with JavaScript.

[^1]: [Platforms supported by SQLite are](https://sqlite.org/features.html):
    "Android, *BSD, iOS, Linux, Mac, Solaris, VxWorks, and Windows (Win32,
    WinCE, WinRT) are supported out of the box. Easy to port to other systems".


A _drafts/2020-02-20-book-review-database-internals.md => _drafts/2020-02-20-book-review-database-internals.md +24 -0
@@ 0,0 1,24 @@
title: Book review - "Database Internals"
date: 2020-02-20
layout: post
lang: en
ref: book-review-database-internals
I'm now reading the "Database Internals" book, by Alex Petrov. I'm liking it a
lot, and I have a similar feeling at the end of each chapter of when I was
reading "Designing Data-Intensive Applications": each chapter has some
references to other books, articles and resources, and I feel like I should go
and reach all of them to have a deeper understanding of the subject.

It gives just enough historical background in the text itself to show that the
author does have knowledge in this area.

# Chapter 1: Introduction and Overview

The covering of basic vocabulary (column vs wide-column) is very good and
straightforward, and the fundamental trade-offs are shown very clearly, like
in-memory and disk-based storage, primary-keys and offset lookups, etc.

Finishing this chapter I was happy with it's content and looking forward for a
more in-depth tour of many of the concepts presented here.

A _drafts/2020-03-30-data-formats-a-comparison.md => _drafts/2020-03-30-data-formats-a-comparison.md +10 -0
@@ 0,0 1,10 @@
title: Data formats - a comparison
date: 2020-03-30
layout: post
lang: en
ref: data-formats-a-comparison
Avro, EDN, etc. (The Language of the system)

Look at column store data formats too? Parquet, ORC, etc. (Database Internals book)