“David Chisnall looks at the concurrency models exposed by Go (a new language from Google) and Erlang (a more mature language, originally from Ericsson), considering the relative expressiveness of each…”
“Parallelism and concurrency are both very fashionable notions. Lots of languages and tools are advertised as good at these things – often at both things.
I believe that concurrency and parallelism call for very different tools, and each tool can be really good at either one or the other. To oversimplify:
- Erlang, Rust, Go and STM Haskell are good at concurrency
- Flow, Cilk, checkedthreads and parallel Haskell are good at parallelism…”
“The amqp.lua package adds support for sending messages to RabbitMQ via LuaJIT FFI. This allows a Lua programmer to communicate with other programs using enterprise grade messaging infrasturcture. The module amqp.lua makes use of LuaJIT’s awesome foreign function interface (FFI) to invoke the librabbitmq’s functions directly. It exposes a simplified interface to librabbitmq natively, but also preserves the ability of an intrepid programmer to use the full depth of the upstream library…”
“The Erlang shell is a funny thing. I think a lot of people who used the language for a short while quickly got annoyed by the lack of support for features that are often considered very basic, such as history or history search (now supported since R16A), or lack of full support for Emacs shortcuts, or the fact that it doesn’t use readline, but only emulates it (wrapping Erlang’s shell in
rlwrap is often recommended). Users of more advanced REPLs such as the one provided with Factor, or Dr. Racket, are likely disappointed with the visual support that’s available in Erlang. Not being able to declare inline modules is a bit annoying as modules are only accepted in files, not in the shell.
In this post, I want to explain how the Erlang shell works, why such features can be somewhat difficult or easy to add in, and also showcase some of the really neat features it has that few other shells provide…”
“From time to time the question of Erlang scheduling gets asked by different people. While this is a quite abridged version of the real thing, it can act as a stand-in to describe how Erlang works 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…”
“For years I’ve tried my damnedest to get away from C. Too simple, too many details to manage, too old and crufty, too low level. I’ve had intense and torrid love affairs with Java, C++, and Erlang. I’ve built things I’m proud of with all of them, and yet each has broken my heart. They’ve made promises they couldn’t keep, created cultures that focus on the wrong things, and made devastating tradeoffs that eventually make you suffer painfully. And I keep crawling back to C…”
“This is an Erlang/OTP tutorial for novice Erlang programmers. If you are familiar with Erlang’s syntax, know how to compile modules and are curious to discover OTP and how to leverage its power in your own Erlang applications this tutorial is for you. To kick off we are going to create a non-OTP server and supervisor, examine their shortcomings and then turn our code into a proper OTP application.
This tutorial will look at:
- How to build a non-OTP server from scratch and how to automatically restart it using a non-OTP supervisor.
- What the shortcomings of our implementation are and how to addresses them with OTP.
- Very briefly, tools such as rebar to smothen our OTP journey and OTP’s folder conventions.
- How to use OTP’s gen_server and supervisor behaviour.
- The OTP application behaviour to tie it all together…”
“The solution uses:
- Less than 20 large instances running on Azure
- An in-memory database
- A full blown custom LISP language written in C to implement queries, which is many times faster that having a VM (with a garbage collector) online all the time
- Erlang for communication between nodes
- Modified TCP_TIMEWAIT_LEN for an astonishing drop of 40K connections, saving on CPU, memory and TCP buffers…”