top | item 18655391

Twenty Years of Open Source Erlang: A Retrospective from the trenches

287 points| francescoc | 7 years ago |erlang-solutions.com | reply

66 comments

order
[+] andruby|7 years ago|reply
I used Erlang before Elixir and it was awesome, albeit with a syntax that required getting used too. I've often looked at bridging the gap between Ruby and Erlang, and closely watched and tested solutions like Reia [0], Erlectricity [1] and Ernie [2].

I was delighted when Jose started getting involved in the space and released Elixir. Thanks Jose!

[0] http://reia-lang.org

[1] https://gilesbowkett.blogspot.com/2007/05/erlectricity-erlan...

[2] https://github.com/mojombo/ernie

[+] sb8244|7 years ago|reply
Ernie was my first foray into Erlang (run many production elixir apps now). It's still humming along in one of our legacy services. Never had an issue or downtime event
[+] the_clarence|7 years ago|reply
Is Elixir more than just a ruby syntax of erlang? Because I prefer Erlang’s syntax.
[+] dudul|7 years ago|reply
Elixir's syntax may look more aesthetically pleasing than Erlan's, but Erlang's is way more consistent and simpler once you get used to it/understand the rules.
[+] fmap|7 years ago|reply
The article is underselling Erlang's meteoric success. "Adoption was slow during the first few years." - After 5 years there was an international conference devoted to Erlang, a global community around it and the language enjoyed commercial success from the beginning.

It just goes to show that Erlang fills a real niche that is ill served by most other programming languages. Programming distributed systems remains painful in 2018 - not because there aren't any theoretical solutions to make it easier, but because there are astonishingly few practical systems that offer built-in support. Erlang is such a practical system and if you didn't already look into the language it is well worth your time to pick it up. :)

[+] binaryapparatus|7 years ago|reply
What an amazing language. I am working on a Elixir project, with a lot of Erlang peaces used directly. Integration is flawless and beautiful to observe. I do have many languages in my toolbox but only few of them were truly exciting for me, Haskell six or so years ago and Elixir/Erlang/OTP this year.
[+] Sileni|7 years ago|reply
I've really wanted to dig into functional languages like this, because I love the theoretical benefits they provide, but haven't really sunk my teeth into one in a way that would let me understand the flavor.

Let me ask, were you immediately drawn to Haskell and Erlang, or was it a feeling that grew while working with them? Would you recommend working with Haskell or Erlang directly before trying out a language like Elixir, or should I go high level down?

Thanks

[+] jimbokun|7 years ago|reply
I had never watched Erlang the Movie before, this is truly a gem:

https://www.youtube.com/watch?v=uKfKtXYLG78

This is a great way to explain the benefits of Erlang. Anyone who has tried to write robust, distributed systems should immediately see the benefits. Even all of these years later.

[+] innocentoldguy|7 years ago|reply
I've been engineering software for almost 30 years and no languages have ever been more enjoyable for me to work with than Erlang and now Elixir. I'd like to thank the teams behind both languages for making my career interesting again.

Specifically, I love working with pattern matching, OTP, and the functional nature of both languages. Thanks Erlang (and Elixir) guys!

[+] whizzkid|7 years ago|reply
Not specifically Erlang but I have used Elixir and it was one of the rare languages that blew my mind when it comes to new ways of thinking when implementing things.

How not to love some of these features!

   [first, second | remaining_of_people] = list_of_people


   greeting = fn
     %{name: name} -> "Hello, #{name}!"
     %{} -> "Hello, Anonymous Stranger!"
   end
[+] losvedir|7 years ago|reply
Full time Elixir dev here. This was a very neat walk down memory lane. Thanks for sharing! Since Elixir is so new, and I wasn't that aware of Erlang prior to it, it's sometimes easy to forget just how long Erlang has been around!
[+] xutopia|7 years ago|reply
I didn't hear about Erlang as much as I did since Elixir came out and showed me the power of the VM and its ecosystem. As a ruby developer it's easy to pick up Elixir and I'm learning so much more about functional programming and systems than I did ever before.
[+] justbaker|7 years ago|reply
The Elixir core oddly was my first taste of an Erlang project. I'm amazed at how the ecosystem and language has expanded since 2011. Jose Valim is a very personable person and thriving code ecosystems are built around individuals like that.
[+] dudul|7 years ago|reply
I really like Erlang and Elixir, but I'm really worried when I see a tech stack that is still trying to figure out deployment and runtime configuration of systems.

I'm not trying to be inflammatory here. As per many resources such as "Phoenix in Action" deployment is still a major culprit. And Dockyard themselves (one of the major Elixir shops, where McCord works actually) have a full time guy on the payroll to try to solve the problem of runtime configuration.

It just sucks, because these are 2 major concerns of any production-ready stack.

[+] lemur-dev|7 years ago|reply
While I agree that deployment can still improve, it is mostly because it doesn’t have the same polish as everything else Elixir ships with. In any case, it has already improved considerably over the last year.

My first application was deployed to Heroku and it just worked. For AWS, we had to do some research but once we got Distillery running, everything worked without major concerns. And Distillery uses Erlang releases which have been around for decades so we can rely on its stability.

Btw, runtime configuration works like a breeze in Distillery 2.0, which is the result of Paul’s amazing work at Dockyard (among other things).

[+] toast0|7 years ago|reply
Deployment for Erlang needs to be a lot more flexible than other systems, because you have the opportunity to hotload code as a core feature [1], having your deployment solution invoke code loads is totally scriptable, but seems more likely to want human eyes watching than a traditional push, stop, start cycle.

OTP does provide the application construct which is supposed to provide some amount of configuration and start/stop/update support; although my team doesn't use the update support, we just push code and hotload it or stop and start beam depending on the changes.

[1] of course, you can hotload code in most languages if you try hard enough, I've done it in C and almost did it in perl; as long as you can load code and get a function pointer at runtime, you should be able to make it work.

[+] apabepa|7 years ago|reply
I am not sure what you mean with production-ready here.

Erlang has certainly been used in production, not only Whatsapp but also have a lot of production systems in telecom where requirements on up-times etc are pretty high.

If you mean that there are no ready made off-the-shelf standard way to handle runtime configuration and deployment I guess it is because the big telcom products usually roll their own per product so it haven't made it into the OTP backlog.

[+] brightball|7 years ago|reply
It’s not so much an issue as it is something they want to make cleaner for new users. If you are coming for a background in other languages, the process doesn’t behave like you’re already used to.

So much of the work that Jose and Chris put into Elixir and Phoenix is striking the balance between what’s possible and what the onboarding experience looks like for new users.

[+] rkangel|7 years ago|reply
For one datum, as an inexperienced Phoenix user, it took me 1 day to get a Phoenix app deployed and running on Google App Engine flex, including DB and some other details.
[+] yawaramin|7 years ago|reply
Yeah but an Erlang deployment is roughly equivalent to a Kubernetes deploy (more powerful in some ways), are you similarly worried about the amount of effort it takes to set up a k8s cluster?
[+] mahesh_rm|7 years ago|reply
Kudos to Francesco and the guys at Erlang Solutions for their outstanding work in the open source high concurrency field!
[+] francescoc|7 years ago|reply
Thanks, but it is not only us at ESL. Thank Joe, Mike, Robert and Jane, the OTP team and Ericsson first and foremost, and the community as a whole. It has been an amazing journey, looking forward to the next 20 years :-)
[+] dhab|7 years ago|reply
My limited understanding of erlang/elixir is that it helps easily run actor model programs (fail-safe loosely defined as something with retries built-in) in a grid of long-running interconnected instances. With more and more focus on "serverless" development that I am being exposed to, I am curious to know if it is a good fit in this space. Say if you are constrained to use AWS serverless solutions - sqs, sns, dynamodb, lambda, cognito, api-gateway ... etc, with event-sourcing (for event-drivenness) with retries (automatic/configurable), (why) would using erlang/elixir vs say nodejs/typescript/go/haskell/java be a good choice (let's assume you equally love these languages for the sake of not getting in to 'but X is better than lang Y')?
[+] busterarm|7 years ago|reply
From my perspective, I see it as a different way of achieving the same end goal. With "serverless", someone still has to maintain servers somewhere and if your company is big enough, AWS is actually the more expensive option.

So if you are running your own infrastructure on bare metal, application development in erlang/elixir lets you better take advantage of the operations staff that you already have because running that infrastructure is much less complicated than the alternatives.

[+] lotyrin|7 years ago|reply
The modern serverless paradigm is a way to give these more traditional computing runtimes/languages a lot of the features of Erlang/OTP.

The downside to having all of these things in services on the network and outside of the runtime is latency. Imagine a runtime where everything is a message, everything goes into inboxes/queues but passing many of those messages is zero-copy, doesn't hit a network interface, and going from the calling code to the called code isn't even a OS level context switch -- so the message is written to and read from a core/thread's local cache lines.

[+] eeZah7Ux|7 years ago|reply
No. Kubernetes & friends implement most of the features of Erlang in a language-independent manner.
[+] tormeh|7 years ago|reply
Erlang truly is something. It's amazing how much effort is expended trying to achieve even a semblance of its functionality in other languages/ecosystems.
[+] cdelsolar|7 years ago|reply
I forget where I read that there were estimated to be only about 1K professional Erlang coders in the world. That seems absurdly low. Does anyone believe this is actually true?
[+] francescoc|7 years ago|reply
Incorrect, it probably got confused with the number of Erlang developers at Ericsson. Not all use it on a daily basis, but estimates on their developers, testers and system integrators is in that range.
[+] jimbokun|7 years ago|reply
If true, it's astounding so few programmers wrote systems that handle such astounding amounts of data.