erllambda library provides all functionality needed to build and deploy fully functional AWS Lambda functions, written entirely in Erlang.
Abstract: The actor model has been a model of choice for building reliable distributed systems. On one hand, it ensures that message-processing is serialized within each actor, preserving the familiar sequential programming model. On the other hand, programs written in the actor model are location-transparent. The model is sufficiently low-level to express arbitrary message protocols. Composing these protocols is the key to high-level abstractions. Unfortunately, it is difficult to reuse or compose message protocols with actors. Reactors, proposed in this paper, simplify protocol composition with first-class typed channels and event streams. We compare reactors and the actor model on concrete programs. We identify obstacles for composition in the classic actor model, and show how to overcome them. We then show how to build reusable, composable distributed computing components in the new model.
|chunked-hello-world||demonstrate chunked data transfer with two one-second delays|
|compress-response||send a response body compressed if the client supports it|
|cookie||set cookies from server and client side|
|echo-get||parse and echo a GET query string|
|echo-post||parse and echo a POST parameter|
|error-hook||provide custom error pages|
|eventsource||eventsource emitter and consumer|
|hello-world||simplest example application|
|markdown-middleware||static file handler with markdown preprocessor|
|rest-hello-world||return the data type that matches the request type (html, json or text)|
|rest-basic-auth||basic HTTP authorization with REST|
|rest-pastebin||create text objects and return the data type that matches the request type (html, text)|
|rest-stream-response||stream results from a data store|
|ssl-hello-world||simplest SSL application|
|static-world||static file handler|
|web-server||serve files and list directory entries|
In this, I describe why Erlang is different from most other language runtimes. I also describe why it often forgoes throughput for lower latency.
TL;DR – Erlang is different from most other language runtimes in that it targets different values. This describes why it often seem to perform worse if you have few processes, but well if you have many.
From time to time the question of Erlang scheduling gets asked by different people. While this is an abridged version of the real thing, it can act as a way to describe how Erlang operates its processes. Do note that I am taking Erlang R15 as the base point here. If you are a reader from the future, things might have changed quite a lot—though it is usually fair to assume things only got better, in Erlang and other systems.
Toward the operating system, Erlang usually has a thread per core you have in the machine. Each of these threads runs what is known as a scheduler. This is to make sure all cores of the machine can potentially do work for the Erlang system. The cores may be bound to schedulers, through the +sbt flag, which means the schedulers will not “jump around” between cores. It only works on modern operating systems, so OSX can’t do it, naturally. It means that the Erlang system knows about processor layout and associated affinities which is important due to caches, migration times and so on. Often the +sbt flag can speed up your system. And at times by quite a lot…
LFE, Lisp Flavoured Erlang, is a lisp syntax front-end to the Erlang compiler. Code produced with it is compatible with “normal” Erlang code. An LFE evaluator and shell is also included.
“In this book, you will find descriptions of programs that you can compose (write) in Erlang.The programs will usually be short, and each one has been designed to provide practice material for a particular Erlang programming concept. These programs have not been designed to be of considerable difficulty, though they may ask you to stretch a bit beyond the immediate material and examples that you find in the book Introducing Erlang…”