I wanted to take a bit of time to reflect over most of that decade. In this post, I’ll cover a few things such as hype phases and how this related to Erlang, the ladder of ideas within the language and how that can impact adoption, what changed in my ten years here, and I’ll finish up with what I think Erlang still has to bring to the programming community at large.

source: HN

This started my whole story with Erlang, which still goes on today. Joe’s book was approachable, the same way he was. He could explain like no other what the principles of Erlang are, what led to its design, and the core approach to fault tolerance that it embodies. It’s one of the few language-specific books that is not content with getting you to write code, but lets you understand why you should write it that way. The language didn’t just have features because they were cool, it had features because they were needed for fault tolerance. What Joe told you applied anywhere else.

source: HN

Live views share functionality with the regular server-side HTML views you are used to writing – you write some template code, and your render function generates HTML for the client. That said, live views go further by enabling stateful views which support bidrectional communication between the client and server. Live views react to events from the client, as well as events happening on the server, and push their rendered updates back to the browser. In effect, we share similar interaction and rendering models with many client-side libraries that exist today, such as React and Ember.

Now in beta.

https://github.com/phoenixframework/phoenix_live_view

source: L

By analyzing the initial test results, proposing a theory, and confirming it by measuring against modified software, we were able to find two bottlenecks on the way to getting to 100k connections per second with Elixir and Ranch. The combination of multiple connection supervisors in Ranch and multiple listener sockets in the Linux kernel is necessary to achieve full utilization of the 36-core machine under the target workload.

source: L

Turns out, busy waiting in BEAM is an optimization that ensures maximum responsiveness. In essence, when waiting for a certain event, the virtual machine first enters a CPU-intensive tight loop, where it continuously checks to see if the event in question has occurred.

In our test, we found that BEAM’s busy wait settings do have a significant impact on CPU usage. The highest impact was observed on the instance with the most available CPU capacity. At the same time, we did not observe any meaningful difference in performance between VMs with busy waiting enabled and disabled.

source: L

My theory is that this is how BEAM makes pattern matching efficient in general: it finds prefixes that can be matched against with select_val. As a corollary if you don’t see a select_val in your bytecode, then you’re not getting the most-efficient pattern matching branching as the pattern checks have to be implemented as separate bytecode instructions, and it might make sense to rearrange clauses that don’t affect semantics to see if a select_val pops out in generated bytecode.

source: L

Fez is an early doors experiment in compiling fsharp to BEAM compatible core erlang. The primary aim is to implement enough of the language to evaluate what how well an ML type of language could become a practical language for writing code to be run on the beam.

source: L

I might summarize this as performance is about more than for loops per second.

source: L

Elixir v1.5 brings many improvements to the developer experience and quality of life. As we will see, many of those are powered by the latest Erlang/OTP 20.

source: L

A microsecond here, a microsecond there, it all adds up.

source: L

I’m talking about the special form with.

source: L

Was Elixir the tool for this project? Probably not. Was it still a fun project and a good learning experience? Absolutely.

source: HN

Some of the details here are environment specific, but they made a useful observation. The loose coupling of components lets problematic pieces be swapped out, and they’ve stepped off the upgrade treadmill being driven by outside interests.

Reading the Pusher articles made me wonder how well would the Elixir implementation perform. After all, the underlying Erlang VM (BEAM) has been built with low and predictable latency in mind, so coupled with other properties such as fault-tolerance, massive concurrency, scalability, support for distributed systems, it seems like a compelling choice for the job.

Because the system doesn’t collapse the first time something bad touches it, Erlang/OTP also allows you to be a doctor. You can go in the system, pry it open right there in production, carefully observe everything inside as it runs, and even try to fix it interactively.

This book is not for beginners.

Buffering, dropping, and back pressure, all in good measure.

In Erlang (and Elixir) supervisors are processes which manage child processes and restart them when they crash.

In Erlang, as in life.

Great observation about web templates having lots of static parts. Concatenating static strings with dynamic strings creates lots more dynamic strings which need to collected or freed, but making a list of strings preempts all that work.