I've been a senior or staff engineer at several companies companies that have their backend tech stacks either primarily or entirely in Elixir. Two of those companies are now unicorns, Divvy (my current company) and Podium. I've seen elixir work great for small teams (~10-15 engineers total) and scale for that company as it went to 100-200 engineers.
Engineers at both unicorn companies consider Elixir one of the reasons they were able to grow the way they did, both in terms of customer count and engineers. Sure, it was hard to find people who had production experience with the language. Didn't really matter; deploy it with Docker (and eventually Kubernetes) the way you would anything else, and if you need clustering then libcluster can manage most of that for you.
Learning OTP is a nice-to-have, but 98% of the time your devs don't actually need in-depth understanding of it (assuming you're a typical web-based startup). Web servers hitting a database is naturally pretty scalable as long as you design your database decently. Scaling your database is _way_ more important to scaling technical systems than your choice of programming language.
Even if your team doesn't need a deep understanding of OTP, _you_ should have a good understanding of GenServer, GenStatem, Application, and Supervisor so you can evaluate 3rd party libs or develop in-house libs. Most devs who are working in product need to focus more on how to write well-factored code to interact with data services like Postgres, Redis, or Kafka.
Yeah, there's a lot of hype around hot code loading, ETS, Mnesia, and the like. Don't use them unless you absolutely have to. ETS is fine for a local cache once you have a generic garbage-collector as long as you don't care about losing that cache on deploy. You probably care, so just use Redis most of the time.
The claim that it's impossible to hire Elixir devs is way overblown. Just hire smart people; software engineering principles are applicable across languages even if the languages have different paradigms. You might have to find new ways of implementing those principles, but discussions around good boundaries and extensible code are more important than "when should I use if vs case vs cond vs pattern-match in a function head?". Podium hired a _lot_ of engineers right out of dev bootcamps. They paid for that in code quality for sure, but even the most green engineers were able to get going in Elixir pretty quickly. As long as you have one or two "seed" engineers who are willing and able to teach others, the hiring problem isn't really a problem.
I'll get a lot of flack for this one, but if your company has a monolithic codebase, Umbrella Applications are a great way to enforce internal boundaries if you're on Elixir 1.11 and have warnings-as-errors set up. Keep splitting any sub-apps that start getting large and the warnings-as-errors will prevent circular dependency hell for you.
If you're doing a service-oriented or microservices architecture, Elixir is pretty great. Synchronous communication is pretty easy to set up if you want synchronous communication; Absinthe makes a great API gateway, gRPC support is decent on both the client and server sides (though testing still needs to be improved with the gRPC lib...)
If you're using plain ol' HTTP, there are a plethora of HTTP client libs that scale well (and a number that don't without effort - some painful lessons at Divvy on that one). Phoenix is a great HTTP server framework, and LiveView is great if you don't want your team to have specialized frontend vs backend devs or get an MVP off the ground.
Kafka support is... fine, I guess. As long as you only need basic Consumer/Publisher capabilities, anyways. If you need anything more advanced, you have to go somewhere else to get the stateful processing capabilities that Flink or Kafka Streams or KSQL will give you.
Redis support is good, with varying options for high-level vs low-level implementations.
The hardest part of working in the ecosystem is the ecosystem itself. The built-in tooling is amazing, but Ruby/Java/JS/<insert other top 10 tiobe language here> will always have a larger selection of libraries.
Engineers at both unicorn companies consider Elixir one of the reasons they were able to grow the way they did, both in terms of customer count and engineers. Sure, it was hard to find people who had production experience with the language. Didn't really matter; deploy it with Docker (and eventually Kubernetes) the way you would anything else, and if you need clustering then libcluster can manage most of that for you.
Learning OTP is a nice-to-have, but 98% of the time your devs don't actually need in-depth understanding of it (assuming you're a typical web-based startup). Web servers hitting a database is naturally pretty scalable as long as you design your database decently. Scaling your database is _way_ more important to scaling technical systems than your choice of programming language.
Even if your team doesn't need a deep understanding of OTP, _you_ should have a good understanding of GenServer, GenStatem, Application, and Supervisor so you can evaluate 3rd party libs or develop in-house libs. Most devs who are working in product need to focus more on how to write well-factored code to interact with data services like Postgres, Redis, or Kafka.
Yeah, there's a lot of hype around hot code loading, ETS, Mnesia, and the like. Don't use them unless you absolutely have to. ETS is fine for a local cache once you have a generic garbage-collector as long as you don't care about losing that cache on deploy. You probably care, so just use Redis most of the time.
The claim that it's impossible to hire Elixir devs is way overblown. Just hire smart people; software engineering principles are applicable across languages even if the languages have different paradigms. You might have to find new ways of implementing those principles, but discussions around good boundaries and extensible code are more important than "when should I use if vs case vs cond vs pattern-match in a function head?". Podium hired a _lot_ of engineers right out of dev bootcamps. They paid for that in code quality for sure, but even the most green engineers were able to get going in Elixir pretty quickly. As long as you have one or two "seed" engineers who are willing and able to teach others, the hiring problem isn't really a problem.
I'll get a lot of flack for this one, but if your company has a monolithic codebase, Umbrella Applications are a great way to enforce internal boundaries if you're on Elixir 1.11 and have warnings-as-errors set up. Keep splitting any sub-apps that start getting large and the warnings-as-errors will prevent circular dependency hell for you.
If you're doing a service-oriented or microservices architecture, Elixir is pretty great. Synchronous communication is pretty easy to set up if you want synchronous communication; Absinthe makes a great API gateway, gRPC support is decent on both the client and server sides (though testing still needs to be improved with the gRPC lib...)
If you're using plain ol' HTTP, there are a plethora of HTTP client libs that scale well (and a number that don't without effort - some painful lessons at Divvy on that one). Phoenix is a great HTTP server framework, and LiveView is great if you don't want your team to have specialized frontend vs backend devs or get an MVP off the ground.
Kafka support is... fine, I guess. As long as you only need basic Consumer/Publisher capabilities, anyways. If you need anything more advanced, you have to go somewhere else to get the stateful processing capabilities that Flink or Kafka Streams or KSQL will give you.
Redis support is good, with varying options for high-level vs low-level implementations.
The hardest part of working in the ecosystem is the ecosystem itself. The built-in tooling is amazing, but Ruby/Java/JS/<insert other top 10 tiobe language here> will always have a larger selection of libraries.