Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails

My plea to the Rails community and Rails senior devs:

1) Fully embrace SPAs as an option, React and Vue are ubiquitous among my peers. I've seriously seen people who have difficulty understanding a for loop that know how to use react at a basic level.

2) Increase your outreach to hackathons and universities, I'd love to see more Rails companies coming out to the big hackathons and mentoring students. At the biggest hackathon in MLH (Bitcamp 2019) I couldn't find a Rails or Ember mentor. I'd also love to see more courses on coursera and other places that teach Rails, in my search for Rails courses on Coursera I only found 1 course (although Traversy media has been making some great content on youtube)!

I’m surprised it’s Python/Node taking that mindshare. From my perspective (fintech industry), it looked like 100% of the decreasing usage of Rails by other fintech startups have been due to choosing Elixir’s Phoenix framework instead.

Out of curiosity, as a non-fintech Elixir/Phoenix dev, what particular facets of Elixir/Phoenix are fintech startups finding attractive/useful?

A lot of finance is built on event sourcing (without calling it that), in that you can’t just overwrite your existing DB state with new state; everything has to be a ledger with a history, and you have to be able to trace the “provenance” of your data—what version of your business rules were used to compute any derived results, both so that those results (and results derived further from them) can be recomputed when you update your logic; and so you that you can use the version of the business rules appropriate to a given dataset (e.g. the tax laws appropriate for the year a given invoice was generated) when auditing that dataset, or when migrating that dataset to a new storage format.

Basically, you want:

• a runtime that forces a functional/immutable programming style (because it’s so much harder to avoid errors in algorithms that operate on mutable data), and which has lots of persistent data structures to make this style efficient;

• concurrency for processing unrelated batches;

• workload isolation (where one batch-job workload crashing doesn’t bring down your whole job processor);

• runtime inspectability and tracing (because it’s hard/illegal to replicate production customer data in staging to get matching conditions)

• a solid library to transit data between a DBMS and native record types (a Record-Relational Mapper lib), with fluent syntax for advanced relational querying features;

• and, of course, a solid Rails-like backend MVC framework to stick on top, to give people an API and web app view into your system†.

So, a lot of these companies are choosing an Elixir+Phoenix stack 85% because of ERTS, 10% because of Ecto, and 5% because of Phoenix itself.

For the companies that realize that what they’re doing is Event Sourcing, the https://github.com/commanded/commanded CQRS/ES framework is also an exciting “feature” of the Elixir ecosystem.

† Sometimes this is considered a separate need—you can build the business event-processing system, in Elixir, as a custom e.g. gRPC API service; and then you can use whatever you want for the web-API/web-app service that fronts it. Sometimes these shops use Rails for the web layer! But just as likely they use Node (because they delegate the front-end layer—now free of business logic—to the front-end devs, and front-end devs know JS) or Elixir+Phoenix (if the same backend devs writing the event-processing system are tasked with writing the web layer.)