I think it's important to note that as much really good work as TJ Holowaychuk did for the early NodeJS community, much of the speed of that work is that he was replicating the functionality of Ruby gems. All the lessons learned by the original authors come cheap, and you can do a good deal of head-down coding that way.

This also helps with recruiting, as the tools work similarly. I didn't spend a lot of time in Rails, and decided not to go that way again, but I did appreciate that I got to recycle some of that new thinking when I started writing Node.

Phoenix also seems to be designed to recruit Rails developers. You could do worse than porting missing tools and crates from Ruby, and as far as I'm aware nobody has nominated themselves as the TJ of Elixir.

(assuming you confused CJ with TJ) This just is not true Having coworkers who personally knew TJ, he was a brilliant mind in his own right, and even if you think that is true, reimplementing functionality in another language but sticking with that languages current design patterns, working within the confines of that languages quirks to provide a cohesive, fluent, and extensible API is no small task.

What the parent posted isn't a criticism, they never said it was a small task or that TJ Holowaychuck's work in the nascent Node ecosystem wasn't brilliant. Just that there is low-hanging fruit available when a new technology of the NodeJS type arrives. If someone has the drive and skill to build high-quality [re]implementations of a large number of key libraries, based on what is available in other (much more established) platform/s, then all being well, that person can do it quite rapidly as the problem space has already been mapped (which then in turn has a huge catalytic effect, particularly as all the APIs they create will follow common patterns).

If you need a library for something in Java, it probably exists. There's several languages on the JVM these days that give you full Java interop - Clojure being my personal choice.

I think Elixir's big selling point is getting the BEAM runtime wrapped in a more modern language with more modern tooling. Lots of the positives people list about Elixir are due to BEAM, which you can also get in Erlang.

> I haven't written Java since I was a freshman in college (2009) and that was like a few months. I basically know nothing about the ecosystem.

I was in love with Ruby and hated Java around 2009, but the latter has gotten so much better with IntelliJ IDEA, to the point where I have to admit that working with JavaFX from IntelliJ was likely my most serene programming job ever. To me, the whole ecosystem is only worthwhile because of JetBrains.

Robust IDE support for Elixir is probably a must-have requirement for many nowadays. I am really tempted by the design of Elixir and find Java/Go/C++ aesthetically repulsive, but I'll happily forget about that if I can keep my refactoring muscle memory.

Thankfully JetBrains isn't the only option.

Fair enough, all the OG IDEs from 2009 are still around. And on the lightweight end of the spectrum, VS Code has excellent tooling support for some languages like Dart/Flutter.

What's interesting is my company hired a bunch of ex-ruby/rails people who transitioned over to Python. A year later, we tried to explore elixir and all those ex-ruby devs were adamantly against adopting it - they figured async python would be better. Very odd, since I figure it would be easier to adopt if you come from Ruby... but perhaps the Ruby community isn't that into functional programming?

It was very interesting experience being a long-time Pythonista having to be like "Isn't this awesome language with a Ruby-like syntax great???" and being told nah, let's just use async python by people who had spent years writing Ruby code.

I guess it depends on the programmer. I've fallen in love with more functional style of coding. The idea of data in and data out makes me feel like it's so much easier to follow what is going on compared to having objects with side effects and mix ins and instance variables. I try to write as much of my Ruby / Rails avoiding the things I mentioned, but its pretty hard to avoid in a larger codebase.