"Note how we have grouped dependent processes together in one subset of the tree and related processes in another, starting them from left to right in order of dependency. This forms part of the supervision strategy of a system and in some situations is put in place not by the developer, who focuses only on what particular workers have to do, but by the architect, who has an overall view and understanding of the system and how the different components interact with each other." (p.175)
Though perhaps these days Designing Elixir Systems with OTP works just as well. However it doesn't hurt to have some fluency in Erlang in order to get access to some of the deep dive material.
Erlang however is more than just a programming language.
"When we were designing Erlang and the basic ideas of how to use the language features we were thinking more along the lines of operating systems rather than of applications. I tend to think of it not so much as a language with concurrency but more of an operating system with a language." [ref]
Might just be familiarity bias though
You have to be careful because it isn't uncommon for individuals without prior exposure to a (single paradigm) functional language coming from Ruby to be lead astray (confused) by that familiarity - i.e. it can get in the way. The concurrent programming aspect just piles on top of that. You have to realize as quickly as possible that you are "not in Kansas anymore".
The first hurdle is pattern matching.
The second hurdle is understanding recursion and the whole concept of tail recursion versus non-tail recursion.
And the third kind of hurdle is thinking concurrently.
Again, the issue is that you will try to solve problems with familiar patterns that are not relevant or even potentially counterproductive in Elixir/Erlang so some up front training/learning is probably a good idea.
Can not wait to see how that is compared to Rails.
Typically you find that you have to do without the creature comforts from the much larger ecosystem that you may have grown accustomed to. If you can get past that it is very easy to get enthusiastic about Phoenix/Ecto.
My information is about two years out of date but I figured I share with you what I found beneficial while I was learning Elixir/Erlang and I have observed during my time as forum moderator.
I'm pleased to see that in this year's stack overflow 2022 survey Phoenix is the most loved web framework; I suspect this has a lot to do with LiveView which was introduced in 2018. In my judgement the Erlang VM gives LiveView a big technical advantage over the later competitors Laravel Livewire and Rails Hotwire - but those have larger communities and ecosystems.
But this style of web application (server based SPA) is subject to some very specific constraints in the wider range of all possible web application styles.
Though Phoenix is also a great platform for API servers and "regular" server routed websites with EEx templates but competition in that space is even fiercer.
Elixir and Erlang in my view are undervalued especially given that the Erlang VM is a lot more prevalent than people realize.
Robert Virding
@rvirding
@YungTseTech @jlouis666 Well then, just more cases where it's in wide use but you don't see it or know about it. It's really great it's being used but a bit depressing that no one knows about it as you continually hear "what's Erlang, why should I learn/use it as no one uses it?"
11:36 AM - 13 Jun 2019
"60% of the world mobile traffic is going through Erlang" (24m48s)
That said the mainstream inclination is to go the K8s, Docker, Go-lang route.
If you have any more questions why not ask them here?
Though for more up to date information I'd just sign up at elixirforum.com and ask away there. The community has always been very welcoming. And many members are on slack as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you know how to design effective supervision trees which is a skill in itself.
For the longest time Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems was one of the best ways to learn about OTP.
"Note how we have grouped dependent processes together in one subset of the tree and related processes in another, starting them from left to right in order of dependency. This forms part of the supervision strategy of a system and in some situations is put in place not by the developer, who focuses only on what particular workers have to do, but by the architect, who has an overall view and understanding of the system and how the different components interact with each other." (p.175)
Though perhaps these days Designing Elixir Systems with OTP works just as well. However it doesn't hurt to have some fluency in Erlang in order to get access to some of the deep dive material.
"When we were designing Erlang and the basic ideas of how to use the language features we were thinking more along the lines of operating systems rather than of applications. I tend to think of it not so much as a language with concurrency but more of an operating system with a language." [ref]
You have to be careful because it isn't uncommon for individuals without prior exposure to a (single paradigm) functional language coming from Ruby to be lead astray (confused) by that familiarity - i.e. it can get in the way. The concurrent programming aspect just piles on top of that. You have to realize as quickly as possible that you are "not in Kansas anymore".
[ref]
So something like Learn Functional Programming with Elixir may be helpful to get some distance from Ruby.
In terms of mindset I think this is relevant:
Again, the issue is that you will try to solve problems with familiar patterns that are not relevant or even potentially counterproductive in Elixir/Erlang so some up front training/learning is probably a good idea.
Typically you find that you have to do without the creature comforts from the much larger ecosystem that you may have grown accustomed to. If you can get past that it is very easy to get enthusiastic about Phoenix/Ecto.
This is amazingly in depth. Do you mind if I contacted you with more questions regarding elixir? Probably though email?
My information is about two years out of date but I figured I share with you what I found beneficial while I was learning Elixir/Erlang and I have observed during my time as forum moderator.
I'm pleased to see that in this year's stack overflow 2022 survey Phoenix is the most loved web framework; I suspect this has a lot to do with LiveView which was introduced in 2018. In my judgement the Erlang VM gives LiveView a big technical advantage over the later competitors Laravel Livewire and Rails Hotwire - but those have larger communities and ecosystems.
But this style of web application (server based SPA) is subject to some very specific constraints in the wider range of all possible web application styles.
Patterns for Building JavaScript Websites in 2022
Ryan Carniato for This is Learning ・ Jun 8 ・ 9 min read
Though Phoenix is also a great platform for API servers and "regular" server routed websites with EEx templates but competition in that space is even fiercer.
Elixir and Erlang in my view are undervalued especially given that the Erlang VM is a lot more prevalent than people realize.
"60% of the world mobile traffic is going through Erlang" (24m48s)
That said the mainstream inclination is to go the K8s, Docker, Go-lang route.
What is easier to scale, Go with Docker and Kubernetes or Erlang / Elixir + OTP?
If you have any more questions why not ask them here?
Though for more up to date information I'd just sign up at elixirforum.com and ask away there. The community has always been very welcoming. And many members are on slack as well.