Haile hailelagi

Every atomic object has a timeline (TL) of writes:
- A write is either a store or a read-modify-write (RMW): it read latest write & pushed new one.
- A write is either tagged Relaxed, Release, or SeqCst.
- A read observes some write on the timeline:
  - On the same thread, future reads can't go backwards on the timeline.
  - A read is either tagged Relaxed, Acquire, or SeqCst.
  - RMWs can also be tagged Acquire (or AcqRel). If so, the Acquire refers to the "read" portion of "RMW".
Each thread has its own view of the world:

Shared write timelines but each thread could be reading at different points.

Big-O Time Complexities for Elixir data structures

Map [1]

Operation	Time Complexity
Access	`O(log n)`
Search	`O(log n)`
Insertion	`O(n)` for <= 32 elements, `O(log n)` for > 32 elements [2]
Deletion	`O(n)` for <= 32 elements, `O(log n)` for > 32 elements

A half-hour to learn Zig

This is inspired by https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/

Basics

the command zig run my_code.zig will compile and immediately run your Zig program. Each of these cells contains a zig program that you can try to run (some of them contain compile-time errors that you can comment out to play with)

Learning Rust

The following is a list of resources for learning Rust as well as tips and tricks for learning the language faster.

Warning

Rust is not C or C++ so the way your accustomed to do things in those languages might not work in Rust. The best way to learn Rust is to embrace its best practices and see where that takes you.

The generally recommended path is to start by reading the books, and doing small coding exercises until the rules around borrow checking become intuitive. Once this happens, then you can expand to more real world projects. If you find yourself struggling hard with the borrow checker, seek help. It very well could be that you're trying to solve your problem in a way that goes against how Rust wants you to work.

How to think about Monads

UPDATE 2021: I wrote this long before I wrote my book Functional Programming Made Easier: A Step-by-step Guide. For a much more in depth discussion on Monads see Chapter 18.

Initially, Monads are the biggest, scariest thing about Functional Programming and especially Haskell. I've used monads for quite some time now, but I didn't have a very good model for what they really are. I read Philip Wadler's paper Monads for functional programming and I still didnt quite see the pattern.

It wasn't until I read the blog post You Could Have Invented Monads! (And Maybe You Already Have.) that I started to see things more clearly.

This is a distillation of those works and most likely an oversimplification in an attempt to make things easier to understand. Nuance can come later. What we need when first le

Common

export OPT=/opt
export BUILDS=/some/where/mini_linux
mkdir -p $BUILDS

Linux kernel

async/await is just the do-notation of the Promise monad

CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.

In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.

First, let's illustrate the 3 styles by implementing

	#![feature(slice_split_once)]

	use std::{
	cmp::{max, min},
	collections::hash_map::Entry,
	env::args_os,
	fs::File,
	io::{stdout, Write as _},
	path::Path,
	};

	// SPDX-License-Identifier: MIT
	pragma solidity 0.8.16; // (10M optimization runs)

	interface MonacoInterface {
	struct CarData {
	uint32 balance; // Where 0 means the car has no money.
	uint32 speed; // Where 0 means the car isn't moving.
	uint32 y; // Where 0 means the car hasn't moved.
	Car car;
	}

	const zero = () => false;
	const isZero = (a) => a == zero();

	const succ = (a) => () => a;
	const pred = (a) => a();

	const converToPeano = (n, acc = zero()) => n === 0 ? acc : converToPeano(n - 1, succ(acc))

	const _0 = zero(),
	_1 = succ(_0),