Live data from Hacker News

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

erlang-solutions.com

31–40 of 70 posts

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

#31
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

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

#32
post #12

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

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.

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

#33
post #17

Earlier quoted context omitted.

My sentiment exactly :) I'm grateful that Elixir is putting Erlang under the spotlights. That it is doing a lot to conveying all the Erlang/OTP concepts and practices. But each time I use it - and I know I may be the odd duck based on slack, blog posts, etc - I feel like the syntax is so complex, with 4 different manners to write the same thing. And I'm not talking about "ways to do things", but literally syntactic w…

> literally syntactic ways to do the same thing. Yup! They are not that many though (6 rules) and they are all documented here: https://hexdocs.pm/elixir/syntax-reference.html#syntactic-su...

Does the shorthand lambda belong on this list?

Thanks for all the work!

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

#34
post #8

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…

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

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

#35
post #8

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…

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 easier to read in Erlang.

The syntactic sugar is too clever for readability imo.

The package management through mix is decent. I used to use an erlang.mk file, looking at hex it looks like the Erlang ecosystem is quite evolved.

Phoenix + Ecto seem to be very actively maintained, useful if you're writing web apps.

When I tried Cowboy a few years ago some of the documentation was out of date, so that's a point in Elixir's favor.

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

#37
post #8

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…

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

You have macros in Elixir

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

#38

Earlier quoted context omitted.

> literally syntactic ways to do the same thing. Yup! They are not that many though (6 rules) and they are all documented here: https://hexdocs.pm/elixir/syntax-reference.html#syntactic-su...

Does the shorthand lambda belong on this list? Thanks for all the work!

Oh, that's a very good question! It doesn't because the list linked above is about syntactical equivalence and the shorthand `&` has its own AST. But now you made me wonder if we should add it to the list anyway (with a caveat) as it would make the list more complete.

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

#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, 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')?

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

#40
post #8

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…

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

Elixir is more than syntax. Or rather, it is not even about the syntax :) This is a common question, so I even gave a talk about it some time ago: https://www.youtube.com/watch?v=V5fMQcSy3y8

Elixir features meta-programming, structs and protocols, first-class documentation, strong focus on the tooling, some abstractions that make concurrency more accessible (such as tasks and streams), etc.

However, Erlang and Elixir share a lot! They have the same data-types (with the same names and even the same syntax for almost all of them), the runtime is the same, and the same foundation about processes, fault-tolerance and distribution.

My suggestion is to go with whatever "touches your heart" because, even if Elixir has its own features, they are more alike than they are different and most concepts you learn for one will also apply to the other.

Post reply on HN