Beam/Erlang/Elixir Concept Explanations(beam-wisdoms.clau.se)
beam-wisdoms.clau.se
Beam/Erlang/Elixir Concept Explanations
http://beam-wisdoms.clau.se/en/latest/index.html
68 comments
Google does provide elixir clients for most of their products: https://github.com/googleapis/elixir-google-api
Yes I was using them. But its just the repo and the documentation is quite lacking compared to the other languages. Like with most things it I referred to is workable but has just quite a bit more friction.
I have a problem with a lack of static types. Was that an issue for you?
This is always a preference issue. You get strong types but the nature of hot loading and communication across clusters doesn’t leading to static typing being a practical trade off. The moment you add it, you end up with a need for contract enforcement across nodes that changes most of what the platform is designed around.
In practice, static typing just doesn’t add much other than headaches to a project of this style. Doesn’t mean you’re wrong for wanting them, just that the language might not be for you if you feel like you need them that much.
In practice, static typing just doesn’t add much other than headaches to a project of this style. Doesn’t mean you’re wrong for wanting them, just that the language might not be for you if you feel like you need them that much.
I understand why dynamic typing might be needed for code reloading and multiple nodes. However for an overwhelming number of uses a single erlang node is sufficient and code reloading itself comes with additional complexity that it is only useful for rare applications. On the other hand hand static types give you cheap and easy freedom from a large class of bugs. Erlang spends a lot of time bringing reliability through sophisticated patterns such a supervision trees etc etc but then totally fails by having dynamic typing. I love Elixir/Erlang but I would say that here (provocatively perhaps) the platform is penny wise and pound foolish: It spends a lot of time on sophisticated strategies while omitting the most elementary one: static types. I like the platform but like every platform it does have weaknesses. To me, personally, missing static types is a weakness.
You may want to take a look at https://gleam.run/
Gleam might be what you need then. The combination of strong types, dialyzer, guard clauses and pattern matching has been more than enough in my experience.
Fully static typing doesn’t bring its benefits without costs.
Fully static typing doesn’t bring its benefits without costs.
My biggest issue with the language. I make use of typespecs where possible but it's a far cry from anything enforced.
[deleted]
In fact yes. You can use Typespecs and I tried to make up for it with tests. However it did not really come close to the safety and convenience of static typing for me.
> good debugging workflow
Most of use use IO.inspect/2, pry, :observer, :recon, and Phoenix dashboard for that.
> if you deploy to Kubernetes then there is a lot of overlap with Beam/OTP for deployment management etc.
These things are complementary. Releases are great for multi-stage docker builds. Libcluster is nice for allowing different containers to talk to one another without any messaging glue. Supervision can crash and restart at a sub container level.
Most of use use IO.inspect/2, pry, :observer, :recon, and Phoenix dashboard for that.
> if you deploy to Kubernetes then there is a lot of overlap with Beam/OTP for deployment management etc.
These things are complementary. Releases are great for multi-stage docker builds. Libcluster is nice for allowing different containers to talk to one another without any messaging glue. Supervision can crash and restart at a sub container level.
Yes you can also get breakpoints and some interactive debugging with the VSCode plugins. But its just not even close to the full interactive debugging of e.g a fully supported lang in Jetbrains. This is very much down to personal preference and I know that there is very powerful debugging and tracing facilities in Beam/OTP
For me, debugging was always too slow in JetBrains. I don’t know if it was a result of the IDE or the language (Python) but I would always end up using print statements instead.
With elixir reloading a single module is fast because of the functional architecture so I can at least drop down into the REPL instead.
With elixir reloading a single module is fast because of the functional architecture so I can at least drop down into the REPL instead.
Same as you. The language looks nice but despite having tried Elixir multiple times this past 4 years, the tooling and lack of Jetbrains support always makes me stop and run back to Ruby.
I learned functional programming first and I find it the opposite. And I find the context switch from functional to not is always difficult, namely because I can't just assume things are immutable and I have to go out of my way to make it so.
That's all to say that the mental overhead is just comfort more than anything.
That's all to say that the mental overhead is just comfort more than anything.
[deleted]
Nix/NixOps has some similar issues with Kubernetes overlap IMO. The easy answer is "lol, our tooling is better, just embrace it entirely and forget Kubernetes."
But it's not that simple— Kubernetes is everywhere, especially once you're into things like short-lived CI environments. Kubernetes is by far the best way to do autoscaling Jenkins or GitLab CI runners; at this point it's kind of the obligation of the non-k8s systems to integrate and interoperate as best they can.
But it's not that simple— Kubernetes is everywhere, especially once you're into things like short-lived CI environments. Kubernetes is by far the best way to do autoscaling Jenkins or GitLab CI runners; at this point it's kind of the obligation of the non-k8s systems to integrate and interoperate as best they can.
Yes exactly. The beautiful thing is, you can install a well designed phoenix app on some bare Metal servers and you will have the features of half of GCP. Monitoring, deployment management, rolling deployments, dashboards, PubSub, in Memory database, load balancing etc. but this made it feel like an all or nothing decision to me. (Slightly exaggerated)
> But I fear its not for me. At least not yet.
What do you mean not yet - what do you think is gonna change?
> pure functional programming is too much mental overhead for me
This means Elixir is just not for you, I don't think you have to be in an endless eternal debate about it. There is quite the disconnect between Hacker News hype and the real world sometimes.
What do you mean not yet - what do you think is gonna change?
> pure functional programming is too much mental overhead for me
This means Elixir is just not for you, I don't think you have to be in an endless eternal debate about it. There is quite the disconnect between Hacker News hype and the real world sometimes.
As said. If the tooling and commercial language support would be better I might give it another shot. Also this was in the context of writing web software with deadlines. Given the time I would probably immerse myself deeper. I specifically wrote this post to give a bit of warning since I feel on HN it is considered tres chic and I would have liked to read a bit a of balanced criticism before discovering it myself. Not taking sides in functional vs OOP here.
I've had the same, as an on/off thing. I recently went deep into an interview process with an Elixir shop, but pulled out for a more stable tech.
I really like Elixir, and I think there is space for it. However, from a web app perspective I realised that what I really liked about Elixir wasn't related to BEAM, processes, or the actor model; but architectural. The consistent layout of Phoenix applications is simple and pragmatic, and as someone overly subjected to dependency injection I appreciate it. I've successfully replicated the architecture in other languages, but it's more of an uphill battle.
That's not to say the BEAM doesn't give advantages. Per process garbage collection and preemptive scheduling yields an exceptionally pleasant environment. There are almost no GC pauses, and you can literally spin up 1000 infinite loop processes on a Phoenix node without effecting your latency.
I'd like to see better tooling for Elixir before I'm ready to commit harder. Some simple things are missing. Notable to me: the language server can't use type specs to provide code completion, and doesn't have the refactoring actions of more advanced systems. I miss being able to rename a function without grep.
I really like Elixir, and I think there is space for it. However, from a web app perspective I realised that what I really liked about Elixir wasn't related to BEAM, processes, or the actor model; but architectural. The consistent layout of Phoenix applications is simple and pragmatic, and as someone overly subjected to dependency injection I appreciate it. I've successfully replicated the architecture in other languages, but it's more of an uphill battle.
That's not to say the BEAM doesn't give advantages. Per process garbage collection and preemptive scheduling yields an exceptionally pleasant environment. There are almost no GC pauses, and you can literally spin up 1000 infinite loop processes on a Phoenix node without effecting your latency.
I'd like to see better tooling for Elixir before I'm ready to commit harder. Some simple things are missing. Notable to me: the language server can't use type specs to provide code completion, and doesn't have the refactoring actions of more advanced systems. I miss being able to rename a function without grep.
Very curious about the recent surge of Elixir / Erlang posts on HN, is there a reason for this?
How is the the job market surrounding this as well for Elixir / Erlang devs?
How is the the job market surrounding this as well for Elixir / Erlang devs?
Elixir shops are learning quickly that the best bet is probably to hire a senior dev that wants to learn and just give them a couple of weeks to learn.
As for the surge in interest, I can’t speak for everybody but when I dove into the language I realized it addressed virtually every short term and long term problem that I’ve experienced in my programming career. The rules it sets out force things to be done in such a way that many issues are avoided as a by product.
I find it balances all of my concerns better than anything else (productivity, performance, maintainability, scalability, learning curve, concurrency, stack simplification, capability, refactorability).
As for the surge in interest, I can’t speak for everybody but when I dove into the language I realized it addressed virtually every short term and long term problem that I’ve experienced in my programming career. The rules it sets out force things to be done in such a way that many issues are avoided as a by product.
I find it balances all of my concerns better than anything else (productivity, performance, maintainability, scalability, learning curve, concurrency, stack simplification, capability, refactorability).
We do this. We're only a small 12-person software agency, we have two Elixir developers right now.
When we hired the 2nd, we looked for someone who had good knowledge of Node, Rails, Laravel or whatever and were excited to learn Elixir/Phoenix. Then they completed a Udemy course and started practicing. It worked out pretty great!
When we hired the 2nd, we looked for someone who had good knowledge of Node, Rails, Laravel or whatever and were excited to learn Elixir/Phoenix. Then they completed a Udemy course and started practicing. It worked out pretty great!
If you are one of these shops please email me :)
I have been dipping my toe in functional land through fantasyland / ramda
I have been dipping my toe in functional land through fantasyland / ramda
Shops that will allow devs the leeway to learn and level up will definitely have an advantage. Oh btw - we're hiring - [email protected]
Yeah, I'd be into that.
I am starting my first Elixir role tomorrow. I come in with no real-world experience (edit: no real-world experience with Elixir specifically - I have a mid-senior level of experience using other languages), just some tutorials (Elixir Koans and Pragmatic Studio) which helped me submit a decent code sample. There aren’t a ton of Elixir roles, but hiring managers also recognize the shortage of devs so for a junior or mid-senior role they might overlook a lack of formal experience with the language. Elixir roles also seem to have pay scales as well as work arrangement flexibility that are higher-than-average.
Geography-wise, I’ve noticed growing, “hipster” cities like Columbus (where I live), Denver, and Austin have a pretty decent share of the Elixir job postings (although, again, if you want to live elsewhere there are lots of fully-remote Elixir roles out there).
Geography-wise, I’ve noticed growing, “hipster” cities like Columbus (where I live), Denver, and Austin have a pretty decent share of the Elixir job postings (although, again, if you want to live elsewhere there are lots of fully-remote Elixir roles out there).
I don't really know about the job market, but Erlang/OTP has been a very fine piece of technology for the past 30 to 40 years.
Elixir is quite new (2015) and with every release it gains in maturity, and the ecosystem is growing. IMHO, Mix was a game changer in terms of tooling.
Also, with tools like Horde[0] and libcluster[1], it became very easy to setup an Erlang/Elixir cluster on Kubernetes.
When you work with distributed systems, the OTP framework is a godsend, it's no surprise to me that it's finally getting traction.
Also, I like to use Rambo[2] to call small go/rust binaries that I ship with my Docker images, useful for features where performance is important.
Elixir is quite new (2015) and with every release it gains in maturity, and the ecosystem is growing. IMHO, Mix was a game changer in terms of tooling.
Also, with tools like Horde[0] and libcluster[1], it became very easy to setup an Erlang/Elixir cluster on Kubernetes.
When you work with distributed systems, the OTP framework is a godsend, it's no surprise to me that it's finally getting traction.
Also, I like to use Rambo[2] to call small go/rust binaries that I ship with my Docker images, useful for features where performance is important.
[0] - https://hexdocs.pm/horde/readme.html
[1] - https://hexdocs.pm/libcluster/readme.html
[2] - https://hexdocs.pm/rambo/Rambo.html> Elixir is quite new (2015) and with every release it gains in maturity, and the ecosystem is growing.
One thing I really like is that it's considered mostly done. The community has the wisdom of not always trying to add new features and deprecating old ones. There's no 2.0 planned but that doesn't stop people from doing impressive work like Nx. I don't know about the ecosystem, but the language itself seem like a stable investment.
One thing I really like is that it's considered mostly done. The community has the wisdom of not always trying to add new features and deprecating old ones. There's no 2.0 planned but that doesn't stop people from doing impressive work like Nx. I don't know about the ecosystem, but the language itself seem like a stable investment.
> Elixir is quite new (2015)
I suppose you can say that; that’s when it 1.0ed. But Elixir was surprisingly stable pre-1.0; I was writing production Elixir 0.6 code at Spawngrid in 2012!
Really, the 1.0 announcement felt more like a formality than anything; there was no discontinuous switch from “throwing features at the wall” to “considered engineering.” Changes to Elixir have always been considered — and props to Jose Valim for that! :)
I suppose you can say that; that’s when it 1.0ed. But Elixir was surprisingly stable pre-1.0; I was writing production Elixir 0.6 code at Spawngrid in 2012!
Really, the 1.0 announcement felt more like a formality than anything; there was no discontinuous switch from “throwing features at the wall” to “considered engineering.” Changes to Elixir have always been considered — and props to Jose Valim for that! :)
More demand than supply, definitely. It’s hard to hire Erlang/Elixir devs from outside.
Some companies just avoid using the platform because of that, but others (like my own company, Covalent) hire devs who seem like they’re experienced in learning languages generally, and then train them in Erlang/Elixir internally.
These devs don’t move around much, though — a company willing to do internal promotion/education is usually pretty good at retaining talent. So new companies looking for Elixir devs still don’t find as many as they’d like.
(An interesting other side effect of this dynamic is that it’s easier to hire senior Erlang/Elixir people than junior ones, since most Elixir devs you’ll find that have ever used the language for anything serious, learned it at work, and so usually have a decent chunk of their career already behind them.)
Some companies just avoid using the platform because of that, but others (like my own company, Covalent) hire devs who seem like they’re experienced in learning languages generally, and then train them in Erlang/Elixir internally.
These devs don’t move around much, though — a company willing to do internal promotion/education is usually pretty good at retaining talent. So new companies looking for Elixir devs still don’t find as many as they’d like.
(An interesting other side effect of this dynamic is that it’s easier to hire senior Erlang/Elixir people than junior ones, since most Elixir devs you’ll find that have ever used the language for anything serious, learned it at work, and so usually have a decent chunk of their career already behind them.)
As a sample size of 1 I can say I didn't have an issue finding an Elixir job and those I did speak to were keen to get an Elixir dev asap. For context I have a few years in Elixir and over 10 as a developer in general. Better yet, the jobs in question were remote only.
I'm retired but look around a bit for interesting jobs using Erlang, and I don't see a whole lot of listings that mention it. More that mention Elixir. And one company (smarkets) that specifically calls out that they're not using it anymore.
But, some of that is I think because, as others noted, it's hard to find Erlang developers, it's easier to target for good developers and convince them to learn Erlang on the job. So I'm guessing some places use it and don't mention it.
I was working at an Erlang shop and out of all of our hires and interviews I did, we hired one person with Erlang experience (from a conference) and I recall interviewing one other candidate with experience. Oh and we had an intern who did a college course with Erlang, but interned in a client group that was limited to j2me (sorry!).
But, some of that is I think because, as others noted, it's hard to find Erlang developers, it's easier to target for good developers and convince them to learn Erlang on the job. So I'm guessing some places use it and don't mention it.
I was working at an Erlang shop and out of all of our hires and interviews I did, we hired one person with Erlang experience (from a conference) and I recall interviewing one other candidate with experience. Oh and we had an intern who did a college course with Erlang, but interned in a client group that was limited to j2me (sorry!).
I guess the reason is enough people upvote it? HN is pretty popular for nichier tech like Clojure, Julia etc. It gets as many votes as Java I think because the community in general likes reading about exotic stuff.
Are Erlang/Elixir really that exotic? I interpret exotic in our context to mean a language aimed at academics and very advanced programmers but lacking mainstream appeal.
Erlang/Elixir strike me as very pragmatic and, compared to Haskell/Lisp/Clojure/Scala/Julia/etc., they seem more beginner-friendly.
Erlang/Elixir strike me as very pragmatic and, compared to Haskell/Lisp/Clojure/Scala/Julia/etc., they seem more beginner-friendly.
I don't think Erlang/Elixir is many people's first language, no. It's advanced.
Someone who is doing their 1st programming project would be better off choosing javascript / php / ruby if they are building for the web. It's quite unlikely their first use cases will be 2 million concurrent web sockets.
So given it's not mainstream and it has the advanced aura I think it's fair to call it exotic or " language aimed at academics and very advanced programmers but lacking mainstream appeal" as you just said.
I don't think Elixir is aimed at academics, though. It's very clear that it tries to be as pragmatic as possible.
Yeah agree, you can erase academics from that sentence. Academics mostly use Python and R and Python is actually super pragmatic.
To clarify, by “aimed at academics” I meant CS academics, not researchers in other fields.
I honestly don’t see why a beginner couldn’t learn Elixir. You can start with if/else, and later learn how to do things more elegantly with pattern matching. You don’t have to use processes and GenServers right away (and even afterwards, you can use a library/framework which provides an abstraction). The ecosystem has many advanced features and use cases, but simple programs are not much harder to write than they are in Python or Ruby.
In some ways, getting programmers to start out thinking about “everything as an expression” and immutability-by-default might help them write elegant and robust code earlier in their journeys.
In some ways, getting programmers to start out thinking about “everything as an expression” and immutability-by-default might help them write elegant and robust code earlier in their journeys.
> but simple programs are not much harder to write than they are in Python or Ruby.
Even if they are just a bit harder it makes it a questionable choice for a beginner. And let's not forget the huge amount of Stackoverflow answers a stack like Python/Ruby have.
> immutability by default
I don't know that beginners should think about that stuff.
Even if they are just a bit harder it makes it a questionable choice for a beginner. And let's not forget the huge amount of Stackoverflow answers a stack like Python/Ruby have.
> immutability by default
I don't know that beginners should think about that stuff.
There was a class aimed at middle school? Iirc Students where they were taught erlang and by the end of two classes they had built a crude networked chat system, which, believe it or not, gets their attention. You can't really do that so easily in any other language system.
> I don't know that beginners should think about [immutable by default].
Yeah. Beginners should not have to think about mutability. So, immutability by default is the right choice. Details like "why don't integers mutate when passed to a function versus a dict" should not ever have to be answered to a beginner.
> I don't know that beginners should think about [immutable by default].
Yeah. Beginners should not have to think about mutability. So, immutability by default is the right choice. Details like "why don't integers mutate when passed to a function versus a dict" should not ever have to be answered to a beginner.
Right, no one has ever built a chat system with Node or PHP or Python...just super hard. Like importing a library and 10 lines of code hard.
yeah try doing that with a room of 12-year olds. They will immediately tune out when you don't bother to explain what "import" is, or when you have to explain how APIs work, what options are, why you need option X, why 3rd party API of your choice requires this function signature?. Dead in the fucking water.
That is taking an off the shelf solution and adding some glue. I bet it's much easier to build such a system from scratch, using Erlang/BEAM, since communication is in its' "DNA".
Erlang/BEAM is also off the shelf solution, whose to say what's the "right amount" of abstraction a beginner should use?
If you really wanna teach a student what's happening in the computer have them use assembly or maybe C, that's pretty much the only way.
1) It’s worthy of the praise and attention, ( The BEAM is a marvel of engineering).
2) It’s just “exotic” enough for people who work in Java/Ruby/JS to be interested to read and upvote. The articles shared tend to be easy to understand and bite sized.
3) There’s enough demand out there and Elixir Devs are usually paid pretty well, that market( for the time being,) is pretty small.
It's not a particularly recent trend irt HN: https://www.flickr.com/photos/stilist/3348380060/
As far as I've seen, Elixir job market for Europe is almost nonexistent, sadly.
Don't upset the zealots by talking about reality please, you will get downvoted to oblivion.
Great resource, thank you. I've been slowly transitioning my programming time to Elixir/Phoenix the last couple years. Every couple weeks I dive in, but mostly going back to Rails. But recently with the `1.6.0-rc.0` release, this time it might stick. HEEx templates are fantastic, esbuild as the default is a really good choice, LiveView is getting some traction, and the packages seem to be picking up. Fantastic language & framework in general.
I would love to get into erlang and beam. As far as I know, Beam must be a great tool for servers and webservers in general. But can I use the language in other scenarios, too? For example commandline tools, desktop Gui's or games?
Command line can work, there's even escript for shorter tasks: "escript provides support for running short Erlang programs without having to compile them first, and an easy way to retrieve the command-line arguments."
GUIs are a challenge, I think there might be some change since this thread in 2017 [1], but the most supported way is wxWidgets and the interface is most unErlanglike. I gather it's similar to GUI programming in c++/mfc style which I never could understand. I do have an erlang program with a small gui (just a fixed sized bitmap output window, no controls, no inputs, no text other than titlebar), and I made it work with wx, but it felt a lot nicer with ex11.
ex11 is ancient, was an academic thesis project/proof of concept and is pretty much raw x11. Erlang and x11 work well together, Erlang is built for distributed systems and x11 is a distributed systems protocol. On the other hand, x11 doesn't include a widget library, the client has to bring one, ex11 has some widgets, but they're very basic. It also relies on x11 font rendering which is not very common anymore. If you wanted to build a mainstreamish GUI on ex11, you'd need to spend a lot of time on building a modern looking toolkit. (And make sure people have an X server)
Games are outside of my ability, but while it's certainly possible, I think the confines of immutable data and lack of shared state would tend to make things cumbersome. Screen output would also be a challenge. It might make netcode easier, though, because of the general need to do explicit communication may mean you're already thinking about how things interact and can avoid some of the pitfalls of synchronization.
[1] https://groups.google.com/g/erlang-programming/c/-0uH3DfnYvM...
GUIs are a challenge, I think there might be some change since this thread in 2017 [1], but the most supported way is wxWidgets and the interface is most unErlanglike. I gather it's similar to GUI programming in c++/mfc style which I never could understand. I do have an erlang program with a small gui (just a fixed sized bitmap output window, no controls, no inputs, no text other than titlebar), and I made it work with wx, but it felt a lot nicer with ex11.
ex11 is ancient, was an academic thesis project/proof of concept and is pretty much raw x11. Erlang and x11 work well together, Erlang is built for distributed systems and x11 is a distributed systems protocol. On the other hand, x11 doesn't include a widget library, the client has to bring one, ex11 has some widgets, but they're very basic. It also relies on x11 font rendering which is not very common anymore. If you wanted to build a mainstreamish GUI on ex11, you'd need to spend a lot of time on building a modern looking toolkit. (And make sure people have an X server)
Games are outside of my ability, but while it's certainly possible, I think the confines of immutable data and lack of shared state would tend to make things cumbersome. Screen output would also be a challenge. It might make netcode easier, though, because of the general need to do explicit communication may mean you're already thinking about how things interact and can avoid some of the pitfalls of synchronization.
[1] https://groups.google.com/g/erlang-programming/c/-0uH3DfnYvM...
Erlang/Elixir is great for internal command-line tools where a several-second startup time is acceptable. If you're looking to distribute the CLI tool externally, it's worth considering other languages.
BEAM would make a fine engine for GUI stuff but the toolkit bindings just don't exist. As another poster mentioned, LiveView + Electron could make a very compelling pair.
Erlang/BEAM has been used multiple times as a gaming network server language, but to my knowledge it has never been involved in the UI.
BEAM would make a fine engine for GUI stuff but the toolkit bindings just don't exist. As another poster mentioned, LiveView + Electron could make a very compelling pair.
Erlang/BEAM has been used multiple times as a gaming network server language, but to my knowledge it has never been involved in the UI.
Commandline tools yes (though that's not it's strong point). Desktop GUIs could be done though I've not looked into it, if I were then I'd look at making a desktop Electron app and use something like Phoenix LiveView with that to create the GUI.
Games are a tricky one, it all depends on what you are doing with the game. I develop a middleware server for an RTS and for that it shines but it would not suit the gameplay side of things very well (you can of course still use it for anything!).
Repo for reference: https://github.com/beyond-all-reason/teiserver
Games are a tricky one, it all depends on what you are doing with the game. I develop a middleware server for an RTS and for that it shines but it would not suit the gameplay side of things very well (you can of course still use it for anything!).
Repo for reference: https://github.com/beyond-all-reason/teiserver
Of course, if you're crazy enough you can shape almost any language for any purpose. I only mention this because I consider Elixir / Erlang one of the best examples of this, because Wings3D is written in Erlang. Who would use a language designed for concurrency and network reliability to write a GUI intensive 3D modelling program for desktops? It was what the author knew and he made it work!
Erlang includes erlang bindings for wxWidgets as used by observer and debugger. It is certainly possible to use them for making desktop GUIs.
I like the teaching style and the lower-level BEAM focus. Bookmarked it!
Please someone update the link to the HTTPS version.
As a long-time professional Erlang developer, I'm frustrated about "Rubyists" sticking their toe into the ecosystem via Elixir and then declaring they don't like it. In many ways, the shift to Elixir has been a bad thing.
BUT the tooling was a bit lacking (e.g JetBrains IDE, good debugging workflow), the library support was a bit spotty (e.g for Auth, everything high quality but often abandoned). Then if you use e.g GCP there is no real first class language support and if you deploy to Kubernetes then there is a lot of overlap with Beam/OTP for deployment management etc. this and I feel for most quick web development pure functional programming is too much mental overhead for me (maybe this comes down to practice). I feel way more productive with e.g Go or Node.
I have mad respect for Jose Valim and the community for delivering such an exceptional project in a world saturated with languages and frameworks. But I fear its not for me. At least not yet.