Twenty Years of Open Source Erlang: A Retrospective from the trenches
erlang-solutions.com
erlang-solutions.com
I was delighted when Jose started getting involved in the space and released Elixir. Thanks Jose!
[1] https://gilesbowkett.blogspot.com/2007/05/erlectricity-erlan...
There’s only one way to do a given thing and you can learn each of the things the syntax can do in a weekend.
It was my first non-C-like, non-assembler language and I loved it.
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 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...
Thanks for all the work!
I too vastly prefer Erlang’s syntax to Elixir’s. It helps me think like Erlang, and most of my functions are just a few lines long. Thanks Garrett[0].
[0]: http://www.gar1t.com/blog/solving-embarrassingly-obvious-pro...
I don't love that there are two ways to make lambdas but it's nit the worst thing in the world.
The funny thing is, if you try to add those features to the other language, they are usually refused. Erlang wants to avoid new syntactical expressions to keep it simple while Elixir's extensibility is bound to a set of limited AST rules (and we don't want to add new ones).
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.
This is ENTIRELY subjective and not a rational argument. It's in fact the exact opposite for me, but my prior language was Ruby.
http://www1.erlang.org/documentation/doc-4.8.2/doc/extension...
...but I think they work differently, or are more limited in scope.
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...
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.
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.
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. :)
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
Elixir is beautiful but probably few notches easier to understand and write than Haskell. Reason I would start with Haskell is that it doesn't hide functional logic with syntactic sugar. For example variables in Elixir are not mutable but since you can assign to the variable already used in function, it can prevent programmer from understanding what immutable really means.
I've found that "immutability all the way down" has eliminated an entire class of bugs related to unexpected mutation, deadlocking/concurrency issues, etc.
I'm currently learning Elixir and writing about it so that anyone interested in Elixir can learn with me as I learn it. The goal is to help other learn Elixir as well.
I make some comparisons to features in C# and Javascript, and the occasional reference to other languages like Python, but you don't have to know any of those in order to benefit.
If you're interested, come check it out: https://inquisitivedeveloper.com/
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.
Specifically, I love working with pattern matching, OTP, and the functional nature of both languages. Thanks Erlang (and Elixir) guys!
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!"
endI'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.
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.
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.
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).
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.
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.
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.
I didn't do well in the class (it was a bit out of my league at the time) but I ended up in a career in software dev anyway