What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
Elixir for Ruby developers: the three most important differences
11–20 of 78 posts
Re: Elixir for Ruby developers: the three most important differences
#12What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
Re: Elixir for Ruby developers: the three most important differences
#13Earlier quoted context omitted.
It's particularly good when you have concurrent users. Also, if you just have a web app that won't need other clients then LiveView gives you SPA-style development without the need to write a web-API layer. Personally, I use it for any web app I'm making. It's a very simple language at its core and is just as good for tiny things as it is for large ones.
I know a lot about what the BEAM is good for, I'm curious about actual things people are doing with it. The last time I used it seriously, we used Erlang as the high level language for these: https://www.icare-world.com/us/product/icare-eidon/ and it was a great fit for that kind of semi-embedded environment.
A slightly cool thing its enabled is that I have a monolith with a single microservice. All the microservice does is process messages from the main app to process images, upload them to S3, then notify back when it's done. The cool thing is that they can be run on two separate connected BEAM instances communicating via the built-in message passing with no need for an HTTP API. I haven't deployed this, yet, though.
Maybe that's still not what you're looking for but I was really happy when I figured out I could do that :D
Re: Elixir for Ruby developers: the three most important differences
#14Earlier quoted context omitted.
It's particularly good when you have concurrent users. Also, if you just have a web app that won't need other clients then LiveView gives you SPA-style development without the need to write a web-API layer. Personally, I use it for any web app I'm making. It's a very simple language at its core and is just as good for tiny things as it is for large ones.
I know a lot about what the BEAM is good for, I'm curious about actual things people are doing with it. The last time I used it seriously, we used Erlang as the high level language for these: https://www.icare-world.com/us/product/icare-eidon/ and it was a great fit for that kind of semi-embedded environment.
Re: Elixir for Ruby developers: the three most important differences
#15What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
Re: Elixir for Ruby developers: the three most important differences
#16What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
Re: Elixir for Ruby developers: the three most important differences
#17Re: Elixir for Ruby developers: the three most important differences
#18I love Elixir, Phoenix and LiveView. A drawback is the size of the community, and as a function of that, availability of libraries for various things. It is not bad. It is also not great. That said, the community itself deserves high marks for their willingness to help and do so in a friendly manner.
1. receiving an answer from a core contributor (valim, McCord, etc)
2. Having the answer become part of the documentation for the language or library
As an aside, the elixir community has a different didactic approach to many others: the documentation in elixir is genuinely instructive (vs a descriptive reference).
As an example, I've been able to download the elixir, Phoenix, and ecto docs and work on an app entirely offline, on an airplane ride, and never felt like I needed to Google anything.
A common elixir answer to "where are all the blog posts" is "read the docs. No, seriously."
Re: Elixir for Ruby developers: the three most important differences
#19I love Elixir, Phoenix and LiveView. A drawback is the size of the community, and as a function of that, availability of libraries for various things. It is not bad. It is also not great. That said, the community itself deserves high marks for their willingness to help and do so in a friendly manner.
The community is small, but that means that a reasonable question on elixirforums (not a stateless discord/slack, pun intended) has a good chance of: 1. receiving an answer from a core contributor (valim, McCord, etc) 2. Having the answer become part of the documentation for the language or library As an aside, the elixir community has a different didactic approach to many others: the documentation in elixir is genui…
This is indeed very common the forums, ha. Also common is for people to actually then go read the docs and be like, "Oh crazy, I'm not used to this!" Not to over-sell the quality of the docs, of course they aren't perfect but they really are particularly good.