The more I use and learn languages the more I prefer Elixir's (to be honest, Erlang's) programming model. I'm not a types person (yet) so that is not as important to me as the building blocks and how it allows you to organise programs.
I think the first question you should ask yourself is, do you expect the same level of "pick a lib, drop a lib" as you would in RoR, or Nodejs? I haven't had any problem with libs, basically because I'm ok with writing http requests if I need to, or do an auth flow myself - it's not like those things are complex - but the first times it might take you more time than just picking something off that works immediately. On the other hand, the core of what I usually need, is pretty sturdy and extendable - Phoenix/Websockets/Ecto(Postgresql, you might have a different exp with other dbs)/Oban and the standard lib/erlang for all sorts of things that in many languages require external libs (or aren't really doable without taking a sabbatical).
Also I don't know if I live in a parallel world, but in many other languages, even ones with pretty heavy investing, many libraries that aren't just translating http responses into whatever language representation of that, are subpar, or not extendable, or you need to almost learn a new language to use them, they're solving things that shouldn't be a library. There's plenty of good libraries out there, including in nodejs, but comparing for instance its ecosystem is kinda pointless, when perhaps 90% of the libs in there don't really warrant existing, or are to cover basic shortcomings or don't solve really anything, or are specific to being run in a browser.
The second is, are you curious enough about the underlying mechanics and learning the programming model? This is sort of essential, because in most languages/VMs everything is sort of a single program, where all things sprawl from a form of "main()", and in Erlang you organise (or should) your application as many different "main()"s, it's almost like an OS. It's still obviously started from a single point, but once started it's like having multiple applications running in a concerted fashion. There's a curve to learning how to leverage that - and to be honest, not all problems require that - although again, the more I see other languages and use them the more I miss the structured form of programs it allows.
The third is, it's a functional language - if you're not used to it in any way some ways of solving problems might not be apparent immediately - they're not more difficult or complex, they're just different - for me solving problems with OOP is also not straightforward - it doesn't mean it's worse, I just don't practice it as much as I do functional programming. There's also obviously problems that are much better expressible with mutable data, but you have enough scape hatches for those cases that really need it - on the upside there's also plenty of problems that are better expressed in functional languages.
Lastly, some useful patterns and ways of doing things require some "acclimatisation", like using pattern matching to describe functions, conditions, and execution paths, ditching almost completely (almost) exceptions and throws in favour of tagged returns, building reliable sync/async flows etc. The testing history in my view is excellent, as are the tools it includes, mix, iex, releases, and overall I would say it made me a much better programmer. I also would take some people's shitting directly on the language or libs complaints with a grain of salt - I've seen a fair bit of idiotic uses of stuff in it (like holding a hammer by the head), and in those cases ask yourself if the libraries and programs other's use or suggest instead are good software and evaluate them in the same context - complete external tools run by companies vs basic stdlib functionality.