The Erlangelist

Ah, true. You are right this assumes some familiarity. Definitely a gap. Check this out: https://www.theerlangelist.com/article/spawn_or_not Written by one of the very best Elixir mentors. I believe it will dispel most (hopefully all) of your doubts and clear things up.

> ..but things like macros in Ecto.... Well, The whole language itself is built on macros. The following series of articles certainly helped me stop worrying and love the macros.. https://www.theerlangelist.com/article/macros_1 Some interesting insights from the article: "Elixir itself is heavily powered by macros. Many constructs, such as defmodule, def, if, unless, and even defmacro[1] are actually macros...." [1] https://github.com/elixir-lang/elixir/blob/v1.18.2/lib/elixir/lib/kern…

EDIT: Paste this hacky snippet into your browser's console to save all of the links into your clipboard: (() => { let result = [...document.querySelectorAll('td a')] .map((link) => link && !link.href.includes('ycombinator') && !link.href.includes('javascript:void') ? link.href : '' ) .filter(Boolean); result = [...new Set(result)]; result.sort(); copy(result.join('\n\n')); })(); Just to help, here's a compiled-list of all of the links shared here so…

If you're interested in Erlang/Elixir, https://www.theerlangelist.com/

Very good articles about Elixir and Erlang https://www.theerlangelist.com/

As a Ruby dev turned Elixir dev: no. I mean, they both have `do..end` blocks, which I don't love in either language. But the similarities pretty much end there. Here's the view of someone who went from Erlang to Elixir: https://www.theerlangelist.com/article/why_elixir

Julia Evans' blog is one of my favorites! It was a big inspiration for starting my own blog (https://andythemoron.com). I also love High Scalability and Dan Luu's blog which have been mentioned in other comments. I "follow" several which are mostly defunct, but in terms of blogs that still feature active updates: Evan Klitze's blog: lots of topics around Linux, C++, etc. https://eklitzke.org/ Sutter's Mill: lots of "state of the world" for C++, but also context, history, etc. https://herbsutter.com/ IT Hare: C++, game programming http://ithare.com/ The Erlangelist: Erlang/Elixir http://theerlangelist.com/ null program: lots of miscellaneous topics http://nullprogram.com/ Fluent C++: the name speaks for itself http://www.fluentcpp.com/ Another Programmer's Blog: Linux, C, C++, C#, MSSQL https://www.stev.org/

I also recommend the six parts series starting with http://theerlangelist.com/article/macros_1

I've only dabbled with both, but the reasons often given is that (apart from surface syntax) the advantages of Elixir over erlang is a powerful macro system, a more cohesive standard library (with some nice things like the pipeline operator), and some very nice tooling (mix is great). With all that being said, erlang is a great language as well, so just pick whatever you like the most. Here is a short article that outlines some advantages. http://theerlangelist.com/article/why_elixir

In Elixir, |> does not flip arguments. It lets you chain together multiple functions by inserting the result of the previous function as the first argument of the following function. Here's an example from http://www.theerlangelist.com/2014/01/why-elixir.html The following code computes the sum of squares of all positive numbers of a list: list |> Enum.filter(&(&1 > 0)) |> Enum.map(&(&1 * &1)) |> Enum.reduce(0, &(&1 + &2))

RabbitMQ is IMHO probably the best open source example tackling a large, complicated real world problem with graceful degradation (e.g. if a queue keeps crashing). Elixir has a lot of smaller but very high quality libraries to learn from. You may be interested in how Ecto & Postgrex manage DB connections, in particular how connection sockets are “borrowed” so data doesn’t get repeatedly messaged (read: copied) between processes. Bandit / Thousand Island also make interesting decisions for process structure in HTTP1.1 vs HTTP2. I think a common mistake is to create processes mimicking classic OOP structure, like an OrderProcessor, ShippingManager, etc. Processes in Erlang are a unit of fault tolerance, not code organization. This means more usually you’ll have one process per request, potentially calling code from many different modules; since requests are the things you want to fail separately from each other. In RabbitMQ’s case for instance connections and queues are processes, but exchanges are not. It would feel natural to model the problem as three processes with messages going Connection -> Exchange -> Queue, but in reality an exchange is a set of routing rules that can be applied by a connection directly, which avoids a lot of complexity and overhead. Last thing I’d note is supervision trees etc. are really about handling _unexpected_ errors (Joe uses the terms faults and errors with different meanings iirc). If you want a web request to be retried a few times with…

While I don't disagree entirely, I find that Elixir is actually quite functional. Using processes for state as if they're objects is generally considered bad practice. I can highly recommend this article (also just in general for people curious about Elixir): http://theerlangelist.com/article/spawn_or_not A quote: > But before starting, since this is going to be a long article, I want to immediately share my main points: > Use functions and modules to separate thought concerns. > Use processes to separate runtime concerns. > Do not use processes (not even agents) to separate thought concerns. > The construct “thought concern” here refers to ideas which exist in our mind, such as order, order item, and product for example. If those concepts are more complex, it’s worth implementing them in separate modules and functions to separate different concerns and keep each part of our code focused and concise. > Using processes (e.g. agents) for this is a mistake I see people make frequently. Such approach essentially sidesteps the functional part of Elixir, and instead attempts to simulate objects with processes.

I don't actually agree that the ecosystem is weaker than Rails. There may be fewer hex packages than Ruby gems, but after 10 years worth of doing my own Rails work and cleaning up other people's messes, I can safely say that most of the gems in the ecosystem are antithetical to well-designed modular software. Bottom line, learning to write software well is hard, no matter what language you're in. What is probably weaker in the Elixir sphere is the amount of blog posts that go deeper than "Yay elixir", but there are some really high-quality books that are a good subsitute. Here's the order I usually recommend for new Elixirians: 1) Dave Thomas' Programming Elixir 2) Sasa Juric (http://theerlangelist.com/) Elixir in Action (blog is also great) 3) Programming Phoenix (Jose Valim, Chris McCord, Bruce Tate) 4) Lance Halvorsen's Functional Web Development with Elixir, OTP, and Phoenix should probably be in there somewhere but I'm not sure where, as I haven't had a chance to read it yet. 5) Designing for Scalability with Erlang and OTP is a good followup when you're comfortable with the syntax and concepts from OTP [1] https://pragprog.com/book/elixir13/programming-elixir-1-3 [2] https://www.manning.com/books/elixir-in-action?a_aid=sjuric [3] https://pragprog.com/book/phoenix/programming-phoenix [4] https://pragprog.com/book/lhelph/functional-web-development-with-elixi… [5] http://shop.oreilly.com/product/0636920024149.do

Programming languages, being technologies, are subject to the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect). This means that the younger a language is, the lower its life expectancy. This is why the neomania in JavaScript framework land is so chaotic. Even if a better framework emerges and takes off in popularity over a few months, it's unlikely to last in the mainstream for another year. When I'm choosing something to study programming-wise, I use this heuristic as part of the decision-making process. For example, studying algorithms and data structures is more robust than studying Vue.js or GraphQL, which are not likely to be around in a few years. Elixir was just released 5 years ago, and despite some success, has not taken off as much as the absolute top programming languages released around that time. For example, Go, released just 2 years earlier, is by far the most successful of new languages from the last 10 years. Given my skeptical mindset towards neomania, it might surprise you to hear that I'm a huge proponent of Elixir! Here are my reasons for studying Elixir and using it exclusively for my non-work projects, despite there being countless other recent, appealing languages: - Although the language is young, it's built on Erlang, which is 30 years old. Even if Elixir fails, there is a lot of knowledge transfer between the two languages (probably 90% of what I learn from using Elixir transfers directly over even if I switch to exclusively…

I have more than 10 years of professional experience using C++, C# and Ruby to develop "classical" business web and desktop apps. I started using Erlang two years ago to implement a push server, and fell in love with it immediately. The language has its quirks, but the virtual machine is fantastic, and it really makes it easier to manage massive concurrency, which is almost always the case on the server side. If you find the language too strange, you should also check Elixir, a Ruby flavored language which compiles to the Erlang bytecode and can normally cooperate with other Erlang code. Starting this year, I am adding new feature for my Erlang based system using Elixir as much as possible. At the moment, you should really be familiar with Erlang to be able to fully understand and utilise Elixir. Other alternatives to Erlang would be Go, Scala/Akka, or reactor based platforms such as node.js or EventMachine. Also, probably Haskell and Clojure, but I'm not really familiar with those. Personally, I find them all to be inferior to Erlang VM, although Go and especially Scala/Akka are really close. I wouldn't recommend reactors despite my great affection for both Ruby and Javascript. Some detailed ramblings on what I really love about Erlang can be found on my blog: http://www.theerlangelist.com/2012/12/yet-another-introduction-to-erla… http://www.theerlangelist.com/2013/01/erlang-based-server-systems.html

> Performance comes second. I want to state that performance is too generalize here. BEAM VM also have a goal of low latency which can be consider as performance. I'm not entirely sure if GO is aiming for that or not. I would never do any numerical stuff on BEAM though, it's very slow. This article is a bit dated but is interesting between Go and Erlang: https://www.theerlangelist.com/article/reducing_maximum_latency

Sasa Juric, and the folks at pusher wrote a couple of blog posts on this: http://theerlangelist.com/article/reducing_maximum_latency

> functional-Ruby. It is not. I understand why people from Ruby really what it to be "like a Ruby", but it is a completely different language. People confuse this by not understanding the erlang runtime and end up writing really poor code. This should be one of first articles new people to elixir should read. http://theerlangelist.com/article/spawn_or_not

Phoenix is definitely production ready, as I am using it in many production systems now. 1) You have to eventually get into OTP. Elixir language is ok but all the stuff which makes it attractive is OTP and it's concurrency. If you are building a very small API you don't have to learn OTP ans you can get very far with that. 2) I find Phoenix documentation very good and the number of examples are increasing a lot day by day. 3) The default included bootstrap is just to show the landing page. You have to add your own css which you have to do if you use any other framework or library. 4) Phoenix is nothing like Django or Rails. Phoenix is very modular. See http://theerlangelist.com/article/phoenix_is_modular

There is a post from the author that documents what has diverged between Elixir in Action and Elixir 1.2. More than simply updating code examples, it actually gives context around all of the changes. http://theerlangelist.com/article/eia_elixir_12

Or you could just step over Node, and grab on to Elixir[1] Why Elixir - http://www.theerlangelist.com/2014/01/why-elixir.html [1] http://elixir-lang.org/

"Erlang based systems obtain many of the aforementioned properties from the Erlang concurrency model. Erlang handles the concurrency itself instead of relying on the OS. A concurrent entity in Erlang, called Erlang process, is much lighter than a standard OS process or thread, initially using about 3 KB of memory on a 64bit system. In a typical Erlang systems, you can easily create hundreds of thousands or maybe even millions of Erlang processes. The Erlang virtual machine uses its own scheduler which ensures that each process gets a fair share of execution time. The scheduler also distributes processes over available CPU cores, using as few OS threads as possible (by default only as much as the number of available CPU cores)." http://www.theerlangelist.com/2012/12/yet-another-introduction-to-erla… It is kind of like Node in that it is very easy to do concurrent stuff, except instead of nested callbacks and all that jazz, you write 'processes' which are designed to share nothing. They run akin to OS threads in that one process crashing won't bring down the whole system (unlike Node). As no state is shared it also means that they can easily (i.e. it is built into the VM, and switched on by default) be scaled up to run over many cores. If you are interested, you might want to look at Elixir (a language built on top of the Erlang VM) which has a more Ruby-esque syntax: http://elixir-lang.org/ EDIT: Should also point out that I think "Jessica's" comment was just…