cohawk

Over the weekend I spun up a new Elixir :ecto, "2.2.7" project that I was able to get working with CockroachDB and this adapter fork - with some caveats I wanted to share to help others.

1. Only the root user can create databases This requires you configure the Ecto.Adapters.Postgres username as root or else the mix ecto.create command will always fail. You can go back and change your configured username to something else after the database has been created, or create your database and user permissions using cockroach sql and skip the mix ecto.create command.

2. Configuring Ecto primary_key ID to be created by CockroachDB By default when configuring your Ecto.Schema using autogenerate: false it appears either CockroachDB, Ecto or the Postrex adapter (I did not investigate this) uses the BIGINT unique_rowid() function as the default value for IDs

@primary_key {:id, :id, autogenerate:

seboudry

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns                     on recent CPU
L2 cache reference ........................... 7 ns                     14x L1 cache
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns                     20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs 4X memory

campoy

package main

import (
	"bufio"
	"fmt"
	"os"
	"time"
)

const numWorkers = 3

freeformz

A slightly updated version of this doc is here on my website.

Why I Like Go

I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. Several other people have asked me the same question recently, so I figured it was worth posting.

Goroutines

The first 1/2 of Go's concurrency story. Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing). They are as simple as go f(x), where f() is a function.