Live data from Hacker News

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

erlang-solutions.com

41–50 of 70 posts

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

#41
post #39

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, dynamo…

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.

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

#42
post #39

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, dynamo…

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.

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

#43

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.

I use Erlang the Movie and its Sequel https://www.youtube.com/watch?v=rRbY3TMUcgQ&t=9s whenever I teach my classes at Oxford Uni. #studentlife :-)

Genius.

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

#44
post #42
post #39

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, dynamo…

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 goi…

For fault-tolerance in case the box is unresponsive for whatever reason, I think you would have to have a network behind a load balancer. So the issue of network latency still exists, but probably to a lesser extent?

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

#45
post #44
post #42

Earlier quoted context omitted.

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 goi…

For fault-tolerance in case the box is unresponsive for whatever reason, I think you would have to have a network behind a load balancer. So the issue of network latency still exists, but probably to a lesser extent?

Yes, obviously some things will need to be persisted, and some of those things might be some of your queue entries -- so a persisted network queue (and network things to dequeue from it) can definitely be a necessity for that reason as well.

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

#46

Earlier quoted context omitted.

Is Elixir more than just a ruby syntax of erlang? Because I prefer Erlang’s syntax.

That's mostly it. Personally I find Elixir's syntax confusing. For example: Losing the ; and . function endings from Erlang you can put same-named functions throughout your module. I tried doing def create def handle(:create) def update def handle(:update) But the compiler warns. So that loss isn't helpful. Atoms require a : because variable names are lowercase. Uppercase variable names and lowercase module names is…

> Uppercase variable names and lowercase module names is easier to read in Erlang

This is ENTIRELY subjective and not a rational argument. It's in fact the exact opposite for me, but my prior language was Ruby.

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

#47
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. :)

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

#48

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?

If true, it's astounding so few programmers wrote systems that handle such astounding amounts of data.

That's what people used to think of Symbolics Lisp machines. Customers would assume Symbolics had a team of thousands of programmers, when really it was about a dozen.

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

#49

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.

I use Erlang the Movie and its Sequel https://www.youtube.com/watch?v=rRbY3TMUcgQ&t=9s whenever I teach my classes at Oxford Uni. #studentlife :-)

You caught the advancing of the movie to the 9 second mark in your URL. (I can't stand when youtube does this automatically, such as when adding videos to playlists...)

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

#50
post #18

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.

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…

In my case I found I was already starting to write Ruby in a very functional way (PORO which is like POJO, only setting properties at object instantiation, focusing on data expressed in built-in classes instead of custom classes, etc.) and that seemed to ease the transition quite a bit.

I've found that "immutability all the way down" has eliminated an entire class of bugs related to unexpected mutation, deadlocking/concurrency issues, etc.

Post reply on HN