Getting to know - Pablo Costas Sánchez

Welcome to another edition in our Getting to Know Us series. Getting to know us consists of articles and interviews about a wide variety of people in our ecosystem, with the main goal of making their work with BEAM technologies visible. Some have been around a long time, while others may seem new to you, but they all share a love for this ecosystem. If you know of interesting work that deserves more visibility, let us know at marcom@erlef.org!

Pablo Costas Sánchez is a Software Engineer deeply interested in creating, maintaining, and shipping distributed software. His biggest contribution has been extending one of the most powerful Property-Based Testing tools out there, PropEr, with parallel and distributed execution. He is currently one of the organizers of SpawnFest and an active member of our Foundation. Today we get to know him.

How did you decide to learn programming and what were your first steps on it?

I was always a nerdy kid to be honest. In my childhood I loved video games, especially World of Warcraft, and I decided that I wanted to host a server myself so that some friends and I could change aspects in the game. To do that you have to know a bit of C++. I was 15 years old or so and I did not know about programming at all. I really liked this experience and I wanted to further my knowledge in the area.

When did you meet the BEAM ecosystem and how did you decide to learn Erlang and Elixir?

In our second year at University, if I recall correctly, we were introduced to more programming languages. We have a course focused on Java and covered some functional programming concepts using OCaml on another. There was also another course on concurrency and parallelism which involved using C and working with threads, along with its challenges and complexities. As part of our coursework, we also had to complete an assignment using Erlang.

At first, I found the syntax of Erlang quite challenging, together with its concurrency model. I asked the professor that was teaching the class for recommended reading material. He suggested the book “Programming Erlang” by Joe Armstrong. I binge-read it over the weekend, and the following week I was able to tackle the homework with ease. I seriously loved it. After that I continued to research more about the language and the community.

Then in the following year, I had the opportunity to take a course of programming for software development dictated by Laura M. Castro. She has been in the community for decades and she guided me in the right direction, for example by presenting me with the Erlang Ecosystem Foundation and recommending some conferences to me, such as Lambda Days. That is how I got into this world.

What are some of your favorite technical highlights in Erlang/OTP, Elixir, etc. that have occurred over the past few years?

I like the approach to concurrency and how resilient the whole virtual machine is. More recently, and although I expect everyone to be saying the same, the JIT has been a great surprise; I was not expecting the huge improvements derived from it and it is an incredible piece of work to be honest. I also really like the concept of genservers, so that you can keep a state and run jobs for longer periods of time, besides the selling point of being able to spawn short-lived lightweight processes in the machine for everything else. Once you get used to the actor model that Erlang uses, concurrency becomes so much easier. Now, I cannot go back to other programming languages without missing things from the BEAM.

You worked in a contribution to the Property-Based Testing tool PropEr which extends it with parallel execution. Could you tell us more about this implementation? Why did you decide to do this implementation? How did you carry it out?

It all started thanks to Laura, she is a huge testing nerd, and she got me to enjoy this part of software development when I took a subject she teaches about different approaches to testing software. By the time I had to do my bachelor’s degree thesis, all I knew was that I wanted to have Laura as my supervisor, because she is awesome, very kind, and she is an active member of the community that I wanted to be part of. So, we started talking and throwing ideas at each other and she told me about this very nice tool that is used in the Erlang and Elixir ecosystems to do Property-Based Testing. I found this method of testing quite fascinating, and the basis for the final project was that weirdly enough, even though the tool is written in Erlang and should be easy to parallelize so the tests would not run sequentially, that was not the case. So, we got in touch with Kostis Sagonas, who is one of the creators of the tool, to try to see if it was a feasible task on which we could have his guidance too, and he was interested in the idea!

For those who want a more technical background, Property-Based Testing is a testing approach on which you define logical statements, or properties, that capture partial correctness that a program has to satisfy. For example, if I have a program that is capable of reversing a list of numbers that it receives as its input, one property that could be defined would be that ‘reversing the reverse of a list should result in a list equal to the original list’. You could come up with more properties, but as an example I think that one is sufficient.

The magic thing that happens then is that Property-Based Testing tools, such as PropEr (Erlang), QuickCheck (Haskell), or Hypothesis (Python), among others, is that they are able to generate inputs to test those properties, and those inputs increase as the testing goes on, as usually properties are checked a number of times with different randomly generated inputs. If the tool happens to find a case in which the property does not satisfy, so a bug in your program, it is then able to automatically shrink the input to provide the user with the minimum input needed to prove that the property is failing.

So, given that generating these randomized inputs is already a resource-intensive task, and even more so when one wants to scale the number of tests a property goes through, the idea was to parallelize how we generate the input and divide it into chunks, amongst many processes, so the tests of small inputs could be run in parallel with those of large inputs.

For those that don’t know about the SpawnFest, could you tell us what it is about? What about your experience both as a participant and as an organizer member?

SpawnFest is an open source-focused hackathon that typically takes place over a weekend, lasting 48 hours. The event provides an opportunity for developers to come together and collaborate on open-source projects. I really like that every year you can see people with very nice ideas giving back to the community. They often build things from scratch, but people might also make use of things that already exist to tackle problems that they have dealt with and believe that all the community has, and would like to offer new ways of dealing with them. It has been running since 2011, and I have both participated as a contestant (in other words, as someone who submits code) and as an organizer. In the 2018 edition, I participated with a colleague of mine from university and we tried to implement a distributed approach to compile C files, wrapped in Elixir. It was a really nice experience and I had tons of fun.

Then, two years later Brujo Benavides, who was organizing Spawnfest back then, posted in the Erlang Slack that he needed some help with organizing the next edition. Some people got in touch with him, myself included, and that year I ended up organizing SpawnFest 2020 together with Paulo Ferraz Oliveira, Filipe Varjão, and Bryan Paxton. The 4 of us run that one SpawnFest edition together, and then Paulo, Filipe, and I the one after too.

You are currently a member of the Education Working Group of the Foundation. How can you describe their task?

The Erlang Ecosystem Foundation is a non-profit organization established a few years ago by people from Erlang, Elixir and other various communities. Its goal was to have a bigger organization to help to grow the community. To do so, it has different working groups that tackle different issues altogether, and I am part of the Education Working Group because I really like helping people learn how nice the BEAM languages are, and to get them to become part of the community.

There are always seniors moving from one programming language to another, but the biggest influx of developers coming into tech communities in my opinion is from students, or people learning if you will, so contributing to a working group that tries to improve the way that we teach the languages from the community and that focuses on the diversity problems existing in the tech industry is something I am very happy to help with.

At the Education working group we can help with running courses, improving the teaching material that professors and teachers can use, but mostly I help with the diversity program the EEF has for conferences. We want to help people who cannot attend BEAM events, with a focus usually on underrepresented people in the tech communities, such as LGTB+ people, people of different ethnic, women or people that otherwise cannot attend. The Erlang Ecosystem Foundation has been running a Diversity Program for the past few years (shout-out to Miriam Pena, who mostly ran it by herself until I joined last year or so). I have seen that it works very well, so I am happy that we have it in our community.

Why did you decide to join the Erlang Ecosystem Foundation and what do you like about working with the community?

That is an easy one: because of the friendly and supportive people I have met, online and in-person. When I was a student, I had the opportunity to meet well-known members from the BEAM world who were always kind and approachable, and I want to follow in their footsteps by giving back to the community in a similar way.

I think that having a single big organization on which you can rely can be very helpful. I have seen the Foundation assist with many things that are of benefit to the community, like getting a stipend to help a smaller conference happen, or have a Diversity Program, or general assistance maintaining tools/projects that people use, but currently are lacking in resources to be maintained; the Erlang Ecosystem Foundation is there to help with things that one cannot do alone.

We’re eager to hear your stories, please share them at marcom@erlef.org!