Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt
Planet = erlang.
Remembering Joe, a Quarter of a Century of Inspiration and Friendship
I first came across the name Joe Armstrong in 1994, when I bought the first edition of Concurrent Programming in Erlang, a book he co-authored. Our first interaction happened in 1995, when I was looking for a company interested in sponsoring my Master’s thesis. I dialled the number for Ellemtel Utvecklings AB, home of the Ericsson computer science laboratory, asking to be connected to Joe Armstrong. Getting a Hello, my unprepared opening line was Skall jag ta det på Engelska, or would you prefer if I took it in Swedish? A silent pause was followed by laughter, the same laughter many of us have come to associate with Joe.
Shouting at each other through the walls
Internships at the computer science lab were an immersion in enthusiasm and creativity. The lab had an academic, non conformist, almost anti-establishment, feel to it. Segregated to the corner of the building, pipe and cigarette smoke coming from some of the rooms. I am sure the cleaning staff were asked to “forget” the department existed, or maybe, they did not dare venture in there after hours. ISO 9000 reviews (and office moves) were a conspiracy to get Joe (and Robert) to clean their desks. But what mattered was not how neat your desk was, but the drive to innovate with an aim to further our understanding in computer science. You did not use an existing web server, you wrote your own so as to understand how HTTP worked and suggest improvements and extensions. You did not take Ericsson’s high security for granted, you found your way around firewalls and tried to outsmart the highly paid system administrators. When I got distributed Erlang working between my University and Ericsson UNIX accounts, I asked Joe if this was right. He walked in the hall and laughed loudly. It was his call for a show and tell, sharing knowledge with his curious colleagues who quickly make their way to his office. Sometimes, there was no need to make it there in person. Mike and Robert were always given the office next to his, so they could shout at each other through the walls.
Ahead of his time
Brainstorming sessions with Joe were the best. We once spent a good part of an afternoon finding a solution to a problem. I ended up working into the early hours of the morning on the implementation, and indeed, it worked. When Joe walked into the office the following day, he pops his head into my room and says You know the solution we came up with yesterday? Forget about it, it will not work. My jumping up and down saying it does work, it works, here it is, was fruitless. He replied, no, we were wrong, and walked off. He was often ahead of his time, in both thoughts and problems he was solving, and had probably discovered some edge and borderline cases to our solution which was too frivolous to share. This is where you learnt to filter his ideas, take those you understood or believed in and parked those you did not like or understand.
Solution to a problem
Sometimes, you would be walking outside his office, he would wave you in and share one of his daily epiphanies, hacks or articles and academic papers on a one-on-one basis. One of these hacks happened in conjunction with a major Erlang release in 1995. They had snuck in List Comprehensions and Funs in the language (product management had prioritized other features) and Joe showed me how they allowed you to implement clean and easy to maintain code, hiding recursive patterns and isolating side effects in a single location. Showing me the shortest implementation of QuickSort I had ever seen, he mentions you can solve the Eight Queens problem in six lines of code. I spent two nights trying to figure out a solution in my head, to no avail. Weary of a third sleepless night, I ask Joe for a solution only to be told: I have no idea, I never solved it myself. Look on the internet. WebCrawler and Lycos, whom had been around for a year, failed to provide a solution. Whilst I love Joe to bits, that particular day, I could have strangled him.
I think he was used to it (mentee students wanting to strangle him), as he claimed that we have always mistreated geniuses ahead of their time. Guttenberg was bankrupted, Galileo escaped the death penalty when put on trial, whilst Darwin’s theories were mocked by many. Fast forward to ten - fifteen years ago, governments and corporations alike were, instead of embracing peer to peer, persecuting those who built services on top of them. Ok, governments and corporations might not have strangled anyone, but they sure did sue them or try to put them in jail. Joe was disgusted by their treatment (he was the one who showed me how bittorrent worked), but he did smile when I told him one of the Pirate Bay founders claimed in an interview he was going to use his time in jail to learn Erlang. (I’ve looked everywhere for the article where I read about it, if anyone has a link, please send it to me francesco.cesarini@erlang-solutions.com)
Leaving Ericsson
In December 1998, a few days after Erlang was released as open source, Joe and some of his Computer Science Lab colleagues left to found Bluetail, later acquired by Alteon Websystems, who in turn got acquired by Nortel. We were both very busy building products these years, and met mainly at conferences and workshops. I do recall being told of the buzz at Nortel when Erlang Solutions launched its first website, and when the dotcom bubble burst, receiving a call from Pekka, a colleague of his, saying he, Joe, Robert, Jane and many others in the team had just been fired! It did not take long for Nortel, in 2003, to start advertising for Erlang developers with ten years of experience, not realising they had recently let go seven of the ten people who at the time fit the bill. Nortel would not have hired me, at the time I only had 8 years of Erlang. You’ve got to love random acts of management.
Seeing his redundancy as an opportunity, he decided to make a stint in academia, working on his PhD through SICS, the Swedish Institute of Computer Science. Making reliable distributed systems in the presence of software errors is a must read for anyone trying to understand the rationale behind systems you write once and run forever. Folklore (Joe after a few beers) has it that after a couple of years at SICS, he walks into his supervisor’s office and submits the full thesis. His supervisor looks up surprised and says, This is not how it is supposed to work. I should be giving you feedback as you write it. Oh, goes Joe, Let me know what you think. After SICS, Joe returns to Ericsson, completing the full circle. In 2014, becoming an Adjunct Professor at KTH, continuing to inspire students through his magical ability to pique their curiosity. Just like he inspired me back in 1995.
Quest to learn
Joe knew that programming languages were not about popularity or beauty contests. They were all about solving problems and progressing the industry. He was just as excited about Rich Hickey, Don Syme or Simon Peyton-Jones’s success stories, and wished Haskell, F# and Clojure to do as well. More recently, he got all excited about Sylvan Clebsch’s Ponylang. When we had dinner with the Go team, he enthusiastically explained Erlang’s concurrency error handling mechanisms to Ken Thompson. He was encouraging Ken to integrate similar semantics in Go. Erlang will not be around forever, he once told me in the 90s. Something better will come along. I don’t think we realised back then, that whatever will come along, is going to be heavily influenced by his work!
There were obviously languages he did not like, C++, Java and JavaScript (read Node.js), backed by well motivated reasons. But despite not liking them, he wanted to meet the inventors behind these languages in his quest to learn more, understand their motivation and share his ideas. He asked me to try and get Brendan Eich to speak at the Erlang Factory in San Francisco and was hoping to meet Bjarne Stroustrup at Code Mesh in London. I once had to drag him out of Google in Mountain View when James Gosling was in his office and we happened to walk outside. Joe asked me if I thought it would be impolite for him to just go in and introduce himself, to which I suggested (for the sake of our host) that it might be better not to, and instead, get a proper introduction.
The Trio, or even Quartet!
We are talking about Joe, but let’s not forget that for a good part of his career, he was part of a team together with Robert and Mike. They were led by a patient Bjarne, who gave them free rein in solving telecom-related and being interested in what, and not how. It was the space they needed to innovate. I am not sure any of them on their own have been able to create Erlang, but together, they were able to leverage each other’s strengths and succeeded at creating both Erlang and OTP. I tried multiple times to get them on stage together to show the dynamics of the trio, but it was always scripted (even Joe’s parts!). I succeeded the third time, at the 2015 San Francisco Erlang Factory Keynote, From WhatsApp to Outer Space, where the last 15 minutes of the talk, they go off script and start asking each other questions, to the roaring laughter of the audience. It shows Joe to be the inventor, Robert to be the one interested in aesthetics and Mike the finisher and end user with industry experience. It was wonderful to see their team dynamics, friendship and bonds still in place and going strong, twenty years on.
Beyond Erlang
In more recent years, Joe started talking about topics beyond Erlang. His Strangeloop keynote, The Mess We’re In, focused on one of his pet peeves in the software industry. As a result of computers becoming faster, software seems to become more complex, and hence, slower. He refers to the laws of physics, something the software industry has tried to defy for decades. Joe (a physicist by training) applied the laws of physics to computer science and distributed systems. Synchronously passing messages, shared memory or attempting to share data faster than the speed of light. If you hear a programmer say you can’t do this, it defies the laws of physics, you now know where their quote comes from.
One of the many projects he was planning on doing after retirement was to interview his heroes, and if he got enough interviews, publish the results in a book. He suggested interviewing Alan Kay on stage at Code Mesh in London in 2016. I have never seen a conference audience so mesmerised. A similar reaction happened in the Let’s #TalkConcurrency panel discussion in November 2018, where we were able to get Sir Tony Hoare, Carl Hewitt and Joe Armstrong to discuss the past, present and future of concurrency models. Joe was originally supposed to run the interview, but as many of us felt he had just as much to say as Tony and Carl, we got him on the panel instead. I am glad we did, as we covered three different, but overlapping approaches to concurrency, each created to solve a different problem. Travelling to Cambridge with Joe for the recording, it was obvious he was not well. His lungs were at 60% capacity, and he often ran out of breath. The pulmonary fibrosis was evident. But we all hoped they would be able to keep it under control.
Lung Research
On Saturday April 20th, 2019, I get the dreaded WhatsApp message that Joe had just passed away. Just the day before, the news was more positive, they had narrowed down the diagnosis and had adapted the treatment accordingly. Unfortunately, it was too late. Joe leaves behind his wife, Helen, his children Claire and Thomas and two cats, Zorro and Daisy, who figure in various programs. Joe had named a previous generation of cats Wittgenstein and Schopenhauer but reality, in the form of Helen, renamed them; they became known as Tubby and Tiger. He also leaves behind many friends, colleagues, students and followers who will continue his work, spreading his ideas and ensuring they evolve and keep on getting embedded in mainstream programming practices.
We are all glad Joe got to see how his work has impacted the world around him, and how Erlang Style Concurrency and OTP are being adopted in the realm of distributed, fault tolerant systems which have to scale on multi-core architectures. Basically, the immediate future.
Thank you Joe for being yourself. Thank you Helen for supporting him in doing what he loved the most. And thank you Claire and Thomas for helping bring up an older brother called Erlang. As the old saying goes, no one truly understands concurrency until they have their second child (or cat).
- Helen and Claire kindly requested donations to be made to lung research, with Claire starting a fundraiser on Facebook: https://www.facebook.com/donate/312270252802913/312270286136243?sfns=mo
[DEMO] MongooseIM integration with RabbitMQ
Erlang OTP 22.0-rc3 is available for testing!
img src=http://www.erlang.org/upload/news/
This is the 3rd release candidate for OTP 22.0
Erlang/OTP 22 is a new major release with new features and improvements as well as incompatibilities.
There are no major highlight for this release, as the main focus of this is bugfixes and polish.
Please consult the readme for a detailed changelog for the release.
The intention with this release is to get feedback from our users. All feedback is welcome, even if it is only to say that it works for you, as it lets us know that the release candidate got some testing.
Highlights in release candidate 2
Potential Incompatibilities
- gen_* behaviours: If logging of the last N messages through sys:log/2,3 is active for the server, this log is included in the terminate report.
- reltool: A new element, Opts, can now be included in a rel tuple in the reltool release specific configuration format: {rel, Name, Vsn, RelApps, Opts}.
- All external pids/ports/refs created by erlang:list_to_pid and similar functions now compare equal to any other pid/port/ref with same number from that node.
- The old legacy erl_interface library is deprecated as of OTP 22, and will be removed in OTP 23. This does not apply to the ei library.
- VxWorks is deprecated as of OTP 22 and will be removed in OTP 23.
Additional highlights in release candidate 2
- A simple socket API is provided through the socket module. This is a low level API that does *not* replace gen_[tcp|udp|sctp]. It is intended to *eventually* replace the inet driver. It also provides a basic API that facilitates the implementation of other protocols than TCP, UDP and SCTP. Known issues are; No support for the Windows OS (currently), a small term leakage. This feature will be classed as experimental in OTP 22.
- ssl: Basic support for TLS 1.3 Server for experimental use.
- In OTP 22, HiPE (the native code compiler) is not fully functional. The reasons for this are new BEAM instructions for binary matching that the HiPE native code compiler does not support. If erlc is invoked with the +native option, and if any of the new binary matching instructions are used, the compiler will issue a warning and produce a BEAM file without native code.
- erts: Added the NIF function enif_term_type, which helps avoid long sequences of enif_is_xyz by returning the type of the given term. This is especially helpful for NIFs that serialize terms, such as JSON encoders, where it can improve both performance and readability.
- crypto: The new hash_info/1 and cipher_info/1 functions returns maps with information about the hash or cipher in the argument.
Highlights in release candidate 1
Erts:
- Support for Erlang Distribution protocol to split the payload of large signals into several fragments.
- ETS option write_concurrency now also effects and improves scalability of ordered_set tables.
- The length/1 BIF used to calculate the length of the list in one go without yielding, even if the list was very long. Now it yields when called with long lists.
- A new (still experimental) module socket is introduced. It is implemented as a NIF and the idea is that it shall be as "close as possible" to the OS level socket interface.
Compiler:
- The compiler has been rewritten to internally use an intermediate representation based on Static Single Assignment (SSA). The new intermediate representation makes more optimizations possible.
- The binary matching optimizations are now applicable in many more circumstances than before.
- Type optimizations are now applied across local function calls, and will remove a lot more redundant type tests than before.
- All compiler options that can be given in the source file can now be given in the option list on the command line for erlc.
Standard libraries:
- Cover now uses the counters module instead of ets for updating counters. The new function cover:local_only/0 allows running Cover in a restricted but faster local-only mode. The increase in speed will vary depending on the type of code being cover-compiled, as an example the compiler test suite runs more than twice as fast with the new Cover.
- SSL now uses the new logger API, including log levels and verbose debug logging.
For more details see
http://erlang.org/download/otp_src_22.0-rc3.readme
Pre built versions for Windows can be fetched here:
http://erlang.org/download/otp_win32_22.0-rc3.exe
http://erlang.org/download/otp_win64_22.0-rc3.exe
Online documentation can be browsed here:
http://erlang.org/documentation/doc-11.0-rc3/doc
The Erlang/OTP source can also be found at GitHub on the official Erlang repository:
Thank you for all your contributions!
Episode @079 - ¡ Viva La LFE! with Robert Virding
Episode @079 - ¡ Viva La LFE! with Robert Virding by Johnny Winn
Let’s #TalkConcurrency with Carl Hewitt
Goodbye Joe
Thoughts on ElixirConf EU
470 Attendees & 30 Speakers
The fifth annual ElixirConf EU was held this year in Prague, Czech Republic. It saw 470 attendees, and 30 speakers, from all over the world, where the ones that had travelled the furthest came all the way from Australia and New Zealand. I have been to all of the European editions of the conference, and it is nice to see the number of attendees grow. In just a couple of years, we have gone from the size of a major meet-up group to enough people to fill an auditorium! Exciting times. And while I cannot think of a time in the history of Elixir that has not been exciting, I would say that this year was special.
New companies adopting Elixir
At this point in time, we have a language that is very stable. It is built on top of one of the most hardened foundations in the industry: The Erlang Virtual Machine. Not only that; the community has a very strong toolset for building large scale applications at their disposal. One could say we have solid answers for building software. That is why many companies and organizations, such as Flyiin; Toyota Connected; Bleacher Report; Vamp, and many more, have adopted Elixir and is now running it in production, and many have done so for a couple of years at this point. The talks reflected this as they covered library design; architectural design; stories of larger systems successfully being partly rewritten and refactored; and solutions to hard problems such as handling millions of messages were shown. All solutions to truly difficult problems.
But we did not forget the newcomers to the community. For them, and more experienced community members, we had talks about the functional foundations of the language, its tooling, and various ways of testing Elixir projects. And talks about the practical, yet not so approachable areas of our toolbox, such as Evadne Wu talking about ETS (the Erlang Term Store, a built-in “Redis”-like, in-memory key/value store baked right into the Erlang Runtime System), and a comprehensive guide to what happens when you boot your application by Michał Muskała. Also, Bram Verburg gave a talk about the SSL module, this will become a valuable resource for the community going forward when we seek to secure our network applications.
Broadway, Scenic, Telemetry, MQTT
While the Elixir language itself has been announced to be a stable and feature-complete language, it is important to not stagnate. It is now up to us, the community, to build the extensions we want to see. Right now, besides pushing the boundaries of concurrent data pipelines, as Jose Valim showed in his keynote about Broadway, one of the frontiers is creating graphical applications using the Scenic framework, and we saw a couple of talks exploring this. Tonći Galić showed how far he could get building a GameBoy emulator with Elixir, and our former colleague Ju Liu showed how to implement a classic painting, both with Scenic. Another frontier is the Nerves project which enables us to build embedded hardware solutions using Elixir. The project is going strong, and Paul Wilson gave an inspiring talk about the video solution they use at their office to include their colleagues working remotely, all built with Nerves.
Erlang Solutions had two speakers on the program, my colleague Arkadiusz Gil and myself. Arkadiusz announced his Telemetry project, which provides the community with a unified way of getting metrics out of an Elixir application. Personally, I see this as one of the missing pieces in our Elixir toolbox, and I am happy to see a solution that can benefit the entire community. My own talk was about my Tortoise MQTT client. I have given a couple of conference talks before, and I think this was the biggest audience I have ever spoken for. While public speaking can be scary I think the audience made it great. I got some good questions about MQTT and Tortoise, and the conversations I had after the talk in the hall were really good. I would definitely recommend the experience to anyone. It is hard work, but rewarding. Be on the lookout for «call for talk proposals» at future conferences—personally I would recommend Code Elixir LDN and ElixirConf US which both currently accept talk proposals.
But, what really makes a conference worthwhile is the community, and they meet in the hallway track. The maturity of the language and the ecosystem reflect on the community members as well. In the meeting area, you would meet seasoned community members, always willing to share their excitement and knowledge, as well as equally excited newcomers eager to absorb the knowledge. The buzz on the floor seemed to revolve around the recent addition to the Phoenix Web Framework: LiveView. Chris McCord did a great job of showing some examples from the community in his keynote: amongst the examples was a game built by a designer with only a couple of months of Elixir experience.
That is pretty exciting. A stable, and approachable language on a stable foundation.
Last thoughts
Personally, I really enjoy the ElixirConf conferences. To me, they are the highlight of the year. I think the conference experience shows a community that is still excited about the possibilities the Elixir language provides, even five years in. We have long surpassed the stage of «Wouldn’t it be awesome if we could use Elixir for this» to «We have built this with Elixir, and it is awesome.» Not only are we exploring concurrent data pipelines, but we are also continuing to branch out into other fields, such as graphics and hardware, and with Phoenix LiveView we have something truly unique in our web application framework, where others will have to catch up to us. I think this year’s edition of the conference provided a good mix of basic talks, and solid knowledge from people who now have years of experience, and showed some good leads to where we can take Elixir, and what we can do with the language next. I look forward to seeing where we are at the next ElixirConf, and where we will take it from there.
Persistent connections with gen_statem
Our applications often interact with external systems. In many cases, we need a persistent connection to one or more of these external services. For example, if your application makes continuous use of a database, you’ll likely want to stay connected to such database so that you can avoid spending time and resources connecting and disconnecting each time you perform a request. With Erlang and Elixir, the natural abstraction to maintain a persistent connection is a process. In this post, we’ll have a look at how we can take advantage of the gen_statem behaviour to write state machine processes that act as persistent connections to external systems.
Juegos en el Backend: Leprechaun
El juego Gems of War tiene un modo de caza tesoros bastante adictivo. El problema con este juego es que debes disponer de un recurso limitado para poder jugar. Al final o pagas o solo puedes jugar un par de veces al día con suerte. ¿Qué tal si nos hacemos el juego entre Elixir y JavaScript?