If you're looking for an "every feature I will ever need to implement has a library for it" experience a la Rails or JS, you might not be happy with Elixir (although we shall see what 5 more years does to the ecosystem).
I don't have problems wrapping a service's API and creating my own library every once in a while, if it means I don't have to trade off slapping together a 5+ service behemoth just to get a good concurrent queue working. This is where Elixir/OTP shines: the hard stuff is easy.
I've tried -- and failed -- to replicate what Elixir does in this regard, in several other programming languages. Age those tries incurred hundreds of coding lines. Only Rust came close, although it's a bit verbose, but the code still did the job.
Scala's parallel collections handled this cleanly. I believe they've been removed from the built in libraries (still available as a JAR though), but the idea was that you'd just add a .par call in your data processing chain and it would use a parallel collection instead of a regular sequential one.
These examples from the documentation (https://docs.scala-lang.org/overviews/parallel-collections/o...) show how to turn a regular sequential computation:
val list = (1 to 10000).toList
list.map(_ + 42)
list.par.map(_ + 42)
One of the areas where Elixir and Erlang shine is distributed applications.
For anyone who has written socket code, the ability to easily send regular Elixir data structures as messages to processes that may run locally or remotely is pretty awesome. And once you realize that you can also send closures over the network (ie. one node can send a snippet of code to another node and it'll be executed there), mind blown.
Do you have any insight on the underlying thread pool? Can you control the size? Is it automatically determined?
Erlang/Elixir default to CPU threads but the number of parallel thread schedulers can be manually changed as well.
I’d like to ask the same question about observables in JS (e.g. RxJS)
As a fairly experienced dev I prefer the technology to slap me hard on the cheek and not make me triple check things.
But Golang's concurrency is definitely a big step up from all the naked multithreading we had to endure and groom for decades -- that is unequivocally true!
I still find Erlang/Elixir's message passing paradigm superior though. Plus every "process" there (a fiber / green thread basically) is being transparently parallelized on another CPU core without you thinking about it at all.
As a personal scoreboard:
1. Erlang/Elixir's messages.
2. OCaml's "domain" effects (mutable shared state managed by multiple threads in a safe manner).
3. Golang's channels and messages.
The community is excellent though. You'll rarely find such a welcoming and ready-to-help community as ElixirForum (although the occasional exceptions do happen like everywhere else).
Elixir is not about the syntax or anything. It's about (a) the underlying runtime, (b) the very powerful metaprogramming facilities and (c) Phoenix / Absinthe / a few others.
Definitely not for everyone or everything, just thought I'd share the thought.
- https://alex-min.fr/open-sourcing-my-phoenix-boilerplate/ - https://hex.pm/packages/stripity_stripe
As for Stripe, this looks pretty mature to me https://github.com/code-corps/stripity_stripe
Definitely not a lot of "official" libs/clients in Elixir, companies aren't gonna spend a lot of resources maintaining that.
1. Install Phoenix, expect the command to be available because everyone is raving about it.
2. Missing command.
3. Dig through docs.
4. Pull the development branch of Phoenix because phx_gen_auth is only available there.
5. Run the generator within the Phoenix git repo because it won't allow me to run it elsewhere using a development version.
6. Use the generator.
7. Never figure things out because the phx_gen_auth command is barely documented and now I've got files everywhere that I don't understand.
I tried implementing API authentication as well and while I got it working, it was less pleasant than my usual Django stack.
Another example. The colossal amount of docs referring to a missing Phoenix plugin for Guardian that got removed in a random update made me scratch my head and spend an hour digging through their changelog and commits to figure out why my code wasn't working. The change was not documented at all.
All in all, there were roadblocks every step of the way with poor docs and big undocumented breaking changes in libraries like Guardian. I want to love this thing but it made me so unproductive in the first couple weeks of using it for basic web/api development that I simply noped out.
Generally the docs for Elixir libraries are very good, but you have indeed found some poorly documented things. I might suggest scraping together something simple and then trying out parts of the ecosystem that offer something new, like channels, live_view, broadway, or something else that takes advantage of OTP. Otherwise you're only going to see the gaps compared to Django and none of the benefits.
[1] https://pragprog.com/titles/phoenix14/programming-phoenix-1-...
I haven't used guardian (not a fan of JWT) so I can't comment on it.
And I like it much better than a library because the code is just plain phoenix/ecto that is can customize easily.
But the last time I tried (weeks ago), it was a total pain. I could barely find documentation for the authentication packages I was trying for Phoenix and the docs I did find were usually outdated. Packages were unmaintained left and right and there's no official libraries for things like Stripe.
It was a real shame because I seriously align with the ideology behind it. It just slows me downvand for that reason I can't use it.