Howdy Alchemists! So we produce a fair few articles. Our latest #TalkConcurrency campaign has been great with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt. We’ve loved the reaction from the community.
We have a few ideas of what to do next then - funnily enough - we thought we’d ask you straight up!
What resources, videos, blogs, ANYTHING do you need? What’s lagging out there? We’ll do our best to make it happen. Yes, we’re called Erlang Solutions, but we’re open to many programming languages and ideas. It would be great to hear from you!
I’d love to see an Elixir book from @rvirding Or maybe even an Elixir for Erlangers book from him I know this is wishful thinking tho as I’ve asked him on numerous occasions already - just thought maybe the ES team might have more luck
On a more serious note, how about an article on unique/unusual/cool(!) ways people are using Elixir and Erlang?
I love to read about Erlang and Elixir doing things that would be impossible or difficult in other languages
I’ve seen some talks about Erlang/Elixir used server side in online multiplayer games, a series about this would be interesting imo
Kind of relating to what @AstonJ said above and my online multiplayer point from above, anything that’s harder to do in other languages is interesting. Or for me, coming from Ruby, that suddenly having the possibility to back a big online game with lots of users or embeeded systems seems to extend my arsenal quite a bit.
Elixir/Erlang at (massive) scale - some of the stories are shared to some extent but looking at the WhatsApps, discords, Ericsson and ??? and their experience seems interesting and maybe good advertisements for the system as such as engineers tend to love this
as recent threads here show, how to deal with deployments is still kind of a hot debated topic
speaking of hot debated, we recently had a hot debate about umbrellas (there are many more threads diverging from there)
I second this. As a complete newbie to programming, whilst I am lucky that I have a friend who introduced me to Elixir and Erlang, my (obviously subjective) impression is that I encounter introductions (for Elixir) as ‘being-better-than-javascript/oop’, but which can fall short of adding definition.
Use-cases featured alongside educational resources (or just in general) that highlight the strengths or, if you like, selling points could prove beneficial.
Of course there are arguments against such an idea, such as confusing complete beginners like me or putting them off with too much detail, but it’s just a thought.
I’m currently interested in machine learning and I understand that it’s a broad topic, but still love to see where elixir/erlang can stand or help in there.
As others have mentioned here, I’m interested in deployments. I’d love to know the de-facto way (at least at the moment) is of deploying Elixir apps. Is it using docker? If so, I’d love to read about the setup. It it using something else? Fantastic, would love more information about these things. How does one deal with configuration in relationship with deployments? How does set up and configure additional nodes for production? I know, this is a big topic that touches many different things and I’m sure each solution “depends” on something. But, I’d love to know a sane, yet professional way of doing things. Thanks for offering to write about these things. Fantastic effort on your end.
Hope I am not too late here. Note that I am not only talking about learning resources here but possible BEAM / library improvements.
Two general points that I can’t help but notice:
(1)
Deployment, as already mentioned. We either need a de-facto singular solution with configuration options to satisfy the different needs the various projects have, or we need complete step-by-step tutorials that are kept up-to-date.
(2)
We need some form of strong static typing contracts. I am not saying it has to be included in the languages – it already has been proven impossible by the process inbox mechanism – but some sort of contracts (textual, or Erlang / Elixir DSL terms). They can be reused for a number of purposes:
Produce defguard definitions.
Produce dialyzer checks with contracts.
Produce Ecto schemas and validator functions (including for required fields).
Produce StreamData generators.
Generate ExUnitProperties property tests.
Generate Absinthe types (which in turn can reuse the produced defguard definitions as well?).
…And maybe some sort of a generic validation mechanism. What I find particularly worrying is that many people seem to roll their own validation libraries – this to me indicates that the community is clearly divided on this topic and will hugely benefit from some standardization. (I quite like Ecto's way of doing things though; I do not see the benefit in further fragmentation in this area.)
I am currently toying with the strong typing contracts for a few hobby projects of mine and already have preliminary successful results. So far what I do is very crude and dumb but it seems to produce Ecto schemas and ExUnitProperties property tests just fine.
Nobody is asking for the BEAM to become strongly statically typed (at least not until future improvements move this idea back into the realm of possibility). I do believe that some sort of strong static typing contracts are necessary for the future of the BEAM however – especially having in mind that they can be reused for a number of purposes which will hugely benefit a lot of projects where programmers have to manually keep Dialyzer checks / Ecto schemas / defguards in sync.
I’d like to see more real-world examples of debugging and operating Elixir/Erlang systems. Less “here I’m tracing a toy app” and more “here’s how we do tracing in production” or “here’s how we solved this tricky bug”. Lots of ugly detail of real world situations
We need some form of strong static typing contracts
I’d love to see this! I’m working on a statically typed language for the BEAM but I think there would be great value of more static typing tools working with Elixir and Erlang themselves.
Currently I roll my own crude macros that attempt to validate the shape of data as much as possible at compile time, but it’s a real faff and not hugely effective.
Maybe we should join forces at some point. Many people can benefit. I am currently doing a few hobby projects that parse ancient data (think type contracts written in COBOL PICTURE notation) and I found that macro-based (or Code.compile_string_to_quoted sometimes) reusing of contracts to generate property tests to be really useful.
We should probably try and extract something useful for the average Phoenix app maintainer out of our ideas!
Another cool resource would be to show erlang and/or elixir being used in ways that they normally aren’t such as machine learning, compilers, game development, etc.
I know that the BEAM might not be best suited for doing these tasks, but it would still be cool to see that it is possible.
Inspiring talks, scalability problems are exciting, however in addition to those…!:
I would like to hear more stories about code maintenance and evolving pre-existing systems based on the BEAM.
Stories about the reasons (whys, hows, …) of a move to the BEAM ecosystem.
Also, taking into account that you can write bad code in every programming language
I am not sure if there is some literature that talks about functional languages on the BEAM that make code maintenance easier.
For ex: compared to an OOP language
Or maybe even an Elixir for Erlangers book from him 
