Live data from Hacker News

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

erlang-solutions.com

61–70 of 70 posts

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

#61
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…

To me, the bigger downside is system complexity. If everything is an BEAM process, then testing, debugging and generally understanding is much easier. Things like spinning up a dev 'deployment' become trivial and things are going to behave in production as I expect them to.

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

#62
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…

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.

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

#63

Earlier quoted context omitted.

You have macros in Elixir

Erlang has macros... http://www1.erlang.org/documentation/doc-4.8.2/doc/extension... ...but I think they work differently, or are more limited in scope.

Erlang macros are basically text substitution. It's similar to C pre-processor directives.

Elixir macros are a completely different beast, they can manipulate the AST Lisp-style. A very elegant example is Elixir's unicode module, which reads unicode data tables and turns them into function definitions at compile time [1].

Compare this to the equivalent module in plain old Erlang, which has to be generated by a separate script, in a pre-compilation step in the Makefile, that literally prints blocks of code [2].

[1] https://github.com/elixir-lang/elixir/blob/v1.7.4/lib/elixir...

[2] https://github.com/erlang/otp/blob/OTP-21.2/lib/stdlib/uc_sp...

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

#64
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…

For managed deployment (with a free tier) check out https://www.gigalixir.com/

Founder of gigalixir here in case you have any questions.

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

#68
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…

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?

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

#69
post #53

Earlier quoted context omitted.

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…

> They have the same data-types (with the same names and even the same syntax for almost all of them), As someone who mostly has just used Erlang, but has looked at Elixir some, I think one of the things I appreciate about Elixir is some of the Erlang warts that you've managed to work around, like having strings be Erlang binaries.

I agree with davidw, 100%

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

#70
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…

For managed deployment (with a free tier) check out https://www.gigalixir.com/

Satisfied occasional user of Gigalixir here! I have a side project chugging along on their free tier.
Post reply on HN