Beam/Erlang/Elixir Concept Explanations
beam-wisdoms.clau.se
beam-wisdoms.clau.se
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.
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.
Fully static typing doesn’t bring its benefits without costs.
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.
With elixir reloading a single module is fast because of the functional architecture so I can at least drop down into the REPL instead.
That's all to say that the mental overhead is just comfort more than anything.
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.
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.
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.
How is the the job market surrounding this as well for Elixir / Erlang devs?
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.htmlI 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! :)
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.
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).
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 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).
I have been dipping my toe in functional land through fantasyland / ramda
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!
Erlang/Elixir strike me as very pragmatic and, compared to Haskell/Lisp/Clojure/Scala/Julia/etc., they seem more beginner-friendly.
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.
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.
> 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.
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!).
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
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...
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.