The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

pminten (16) [Avatar] Offline
I'm reading through the book, so far read Chapter 1. It looks good. Your writing style is clear and I like how you don't dumb things down.

There are a few things where I'd like to give feedback. Not because they are terrible but because you might benefit from another perspective. I'll make a post for each separate issue to make things easier to keep apart.

In Chapter 1 you start by extolling Erlang's virtues and then introduce Elixir. The high level picture you seem to paint is that Elixir is Erlang, but with annoying problems fixed. While that fits very well with the previous section on Erlang I do feel that it's a bit inaccurate.

Elixir generally doesn't gain features because Erlang does things badly but because those features make Elixir itself more powerful. In other words the developers don't really look at Erlang that much. Erlang is our base platform and an important influence but it's not the only influence. If you look at the history of the `|>` operator it seems to come from F#. The reducer based enumerations come from Clojure which probably has them from Haskell. Much of the syntax comes from Ruby (whereas much of Erlang's syntax comes from Prolog).

The relation between Elixir and Erlang is, I think, less like C++ and C and more like Ruby and Python. Both languages are shaped by common constraints (in Elixir/Erlang's case directly through the EVM, with Ruby/Python the similar dynamic typing / interpreted language features) but one isn't a direct descendent of the other. Put otherwise when Elixir works like Erlang it's usually because the EVM works that way.

The differences between Elixir and Erlang also originate from the different programming generations that they come from. Erlang is 27 years old, it originated in a very proprietary setting focussed on a single area (telecoms). When it was born the internet barely existed (Erlang was born in the same year that the .nl CCTLD was registered, the first CCTLD outside of the US) and the WWW didn't exist at all.

Elixir on the other hand was born into a world focussed on the web, created by a prominent Ruby on Rails developer. From the get-go it was open source. Although I imagine initially most of the developers came from an Erlang background as the language grew it attracted non-Erlang developers as well, many Ruby developers but also people from other functional languages.

Just an idea: maybe it would help to be clear about the three components of what we generally call Erlang: the Erlang language, the libraries (including OTP) and the EVM. Elixir uses nothing of the Erlang language, part of the libraries and all of the EVM.
sjuric (109) [Avatar] Offline
Re: Chapter 1: Elixir's relation with Erlang
Hi Peter,

Thanks for the valuable feedback!

I definitely agree with you that Elixir relies only on EVM and (partially) the libraries. That's the picture I wanted to paint, but obviously I need to clarify a bit more. I'll reread the chapter and see if I can expand on this.

That said, I do think that Elixir fixes annoying problems of Erlang (the language). I think that's exactly its purpose, and the main benefit it brings to the table. Personally, I find the entire Erlang platform extremely valuable and useful, but when it comes to code organization, the language definitely has its problems. I can sympathize about the context it was built-in, but from today's point of view, the resulting code simply feels too elaborate. Which is exactly where Elixir can help, by making it possible to eliminate a lot of boilerplate, noise, and ceremony.

I find the relationship between Elixir and Erlang to be very unique. It is neither Clojure <-> Java, nor CoffeeScript <-> JavaScript, nor C++ <-> C. Elixir is somehow very similar to Erlang, and yet it adds a lot of additional constructs, that are of course borrowed from other languages and paradigms. I think Jose did a brilliant job of synthesizing many different language constructs into a single language, keeping the language itself fairly simple.

At the end of the day, my own experience is that Elixir simply allows me to organize my code more efficiently, and thus create better intention-revealing, more self descriptive code. Other than that, it harnesses the power of underlying EVM and experience of OTP, and that's where the true strength of the entire platform lies.

Thank you again for the feedback, and feel free to provide further comments!

Best regards,
pminten (16) [Avatar] Offline
Re: Chapter 1: Elixir's relation with Erlang
Maybe it would help to extend the paragraph at the beginning of chapter 1 a bit to give a short high level perspective of Erlang and Elixir and how they relate before diving into Erlang.

Also, you're saying in that paragraph that Elixir is built on top of Erlang. Maybe it would be more correct to say that Elixir runs on the Erlang platform. But then the first sentence of paragraph 1.1 becomes somewhat confusing: "Erlang is a development platform for building scalable and reliable systems that constantly provide service with very little or no downtime." (because Erlang is also the primary language of that platform. I do think it would be helpful to be clear about what things belong to Erlang (the language, not shared by Elixir) and what's part of the Erlang platform (shared by Elixir).

Take a look at <>, that's how I see the relation between Erlang and Elixir.
sjuric (109) [Avatar] Offline
Re: Chapter 1: Elixir's relation with Erlang
Hi Peter,

I believe the confusion arises from ambiguous terminology from my side. When I say "platform" I do not mean the runtime, but the entire package. I later expanded on this in 1.1.4 when I said:

"Erlang is more than a programming language. It is a full blown development platform, consisting of four distinct parts: the language, the virtual machine, the framework, and the tools."

So the word platform really means the entire "thing". Perhaps I should use some other word?

Concerning your diagram, this is similar to how I see the entire combination. Here you can find the slides from my recent presentation on Elixir/Erlang ( It's in Croatian, but it's mostly graphics/code. Check out the slide 12, where I have the similar diagram.

Where we differ in layering, is that I placed stdlibs/OTP on top of Erlang language, because most of these are actually implemented in Erlang (the language) itself.

Thanks for the suggesion, I'll give it a thought, and also consider how to disambiguate the word "platform".

Best regards,
JanaG (4) [Avatar] Offline
Re: Chapter 1: Elixir's relation with Erlang
I also like Jose Valim's explanation of Erlang in his design goals blog:

Elixir is meant to be compatible with the Erlang VM and the existing ecosystem. When we talk about Erlang, we can break it into three parts:

A functional programming language, called Erlang
A set of design principles, called OTP
The Erlang Virtual Machine, referred to as EVM or BEAM

Elixir runs in the same virtual machine and is compatible with OTP. Not only that, all the tools and libraries available in the Erlang ecosystem are also available in Elixir, simply because there is no conversion cost from calling Erlang from Elixir and vice-versa.