Erlang Solutions, a consultancy for Erlang and Elixir, publishes posts on the BEAM, XMPP messaging, case studies, and industry trends.
HN commenters link it for practical BEAM material such as distribution without EPMD, tracing in Elixir, and company case studies.
Here is the list of things that I feel are still holding Elixir back from wider adoption:
1. Not enough companies sharing their experience - most companies want to lead and not follow. There has been a lot of success with Elixir but too often I've heard companies not wanting to indicate they're using Elixir out of concern that it will tip off their competition (I've heard this from two companies now, big ones) or they just don't have a culture of sharing. The most impactful case study on Elixir was one of the first, the Bleacher Report case study https://www.erlang-solutions.com/case-studies/bleacher-report-case-study/. They did an excellent job of articulating the direct business value of transitioning from Rails to Phoenix. We need more of these stories shared
2. Lack of talent - this is a chicken or egg problem but one thing that comes up quite often. If there were more companies actively hiring in Elixir there would be more devs learning Elixir but companies are reluctant to hire for Elixir because there aren't enough devs. Most of the courses/guides are aimed at transitioning Senior level talent. At DockYard through our Academy https://academy.dockyard.com/ we decided to tackle this from the opposite end and commit to producing high quality junior Elixir engineers.
3. Higher price point for talent - the recent Stack Overflow surveys regularly rank Elixir at the top for cost. Personally I think this stat is being influenced by the fact that Elixir has a higher % of…
I don't know how the Erlang GC works so I can't really comment on that
If you're interested, here are a few helpful blogposts on the subject:
- This is a pretty short and readable post, though it's a bit old (2008): "Garbage Collection in Erlang" [0]
- A more detailed (and recent -- 2015) blogpost: "Erlang Garbage Collection Details and Why It Matters" [1].
- And this is the most up-to-date description, from April 2016 concerning Erlang R19, by Lukas Larsson, who works on the Erlang VM -- it is long, but well-written and has nice illustrations [2].
[0] http://prog21.dadgum.com/16.html
[1] https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
[2] https://www.erlang-solutions.com/blog/erlang-19-0-garbage-collector.html
That’s an “it depends” for me. I do always want the transcript, but let’s appreciate that a competent lecturer brings a topic to life. You don’t have to be Richard Feynman, but you do have to reveal and conceptualise at a pace an informed and inquisitive brain latches onto.
Most video content is not at this level; it’s often either glibly oversimplified (content marketing), bogged down in minutiae (how-to guides), or buried under irrelevancies (what’s up guys).
There is something I’d often prefer to consume as a AV recording, and that is interviews/panel discussion. The nuances of articulation, even body language may be informative. Compare and contrast the transcript with the video at https://www.erlang-solutions.com/blog/let-s-talkconcurrency-panel-discussion-with-sir-tony-hoare-joe-armstrong-and-carl-hewitt.html for example.
Interesting. Here is also a podcast about the topic: https://thinkingelixir.com/podcast-episodes/017-jit-compiler-for-beam-with-lukas-larsson-and-john-hogberg/
Had a brief look at asmjit; as it seems it only supports x86 and x86_64 and is not really an abstraction (i.e. a platform independent IR). I will try to find out why they didn't use e.g. LLVM or sljit.
EDIT: according to this article (https://www.erlang-solutions.com/blog/performance-testing-the-jit-compiler-for-the-beam-vm.html) the speed-up factor caused by the JIT is about 1.3 to 2.3 (as a comparison the speed-up between the PUC Lua 5.1 interpreter and LuaJIT 2.0 is about factor 15 in geometric mean over all benchmarks, see http://luajit.org/performance_x86.html).
Can you articulate the kinds of business problems Erlang is particularly well-suited to solve?
When you choose Erlang for a project, what kind of return on investment do you think it typically offers? Does it lead to significant cost savings or help generate more revenue in ways that other languages might not?
In situations where Erlang is chosen, what are some concrete examples of how it has demonstrably increased efficiency, reduced errors, or enabled new business opportunities that wouldn't have been as feasible with other technologies?
Edit: I guess if I'd done any research myself before asking, I might've found this: https://www.erlang-solutions.com/blog/which-companies-are-using-erlang-and-why-mytopdogstatus/
Highlights (emphasis mine):
> Open source maintainers can request a free license by emailing safe@erlang-solutions.com and including a link to their [GitHub] repository. Once approved, we provide a SAFE license for one month or up to a year, depending on the project’s needs, at no cost.
The legalese[1] (is incoherent but apparently) does not pass the Curl test, that is, the maintainer of Curl—who gets money by providing commercial support for his completely FOSS project—wouldn’t be allowed to use this had it applied to him:
> You can only use SAFE for open-source software. Any commercial use is prohibited.
[1] https://www.erlang-solutions.com/policies/safe-for-open-source-projects/