So...not Elixir.
I think your first and third bullets are correct, but not entirely relevant.
That is, yes, it's hard to find people that know Elixir already, but if you can take a dev and get them competent in two weeks does it matter? Your experience with Scala != experience with Elixir.
Likewise, when it comes to ecosystem - maybe it matters, maybe it doesn't. In Scala you can leverage the JVM; I feel like the ecosystem isn't really a problem then. In Elixir, you have a lot of things available both natively in Elixir, and in Erlang. Less than the JVM, for sure, but unless your problem domain includes something that doesn't exist for Elixir, it doesn't matter.
For your second...that seems more how you write code than your language choice. And a claim that Erlang/Elixir's approach to 'let it fail' means you are spending too much time writing robust code seems...false; if anything it's less than having to catch and think about Java's checked exceptions, let alone if you ever ask "wait, what happens if we go off the happy path here?"
That said, I agree with you if you are planning to be a unicorn and scale to 1000+ engineers then you definitely should go with the well-worn path just because it's the only way to satisfy your insatiable hiring funnel.
On the other hand, if your aspirations are to focus on a simple but great product and keep the team tight rather than chase growth at all costs, Elixir/Erlang could be a super power to scale a cohesive product to massive scale with a very small team (eg. WhatsApp).
It's not entirely clear whether your experience is only with Scala or whether you've used both. If it's the former then I'd suggest that others try Elixir for themselves rather than take a recommendation based on experience with another language.
The points I raised earlier in the context of choosing a language for building a company apply to all of those. I don't see why Elixir is exempt - do you mind explaining?
It runs in a different VM, it's a different paradigm (or mash-up of paradigms which, in turn, is the source of one of your contention points when learning/ramping hires), it's a statically typed language so requires usually more upfront thinking and a better understanding of domain modelling (getting it right from the start), it's notorious for being complex (don't know if it's warranted or not, but it's a normal complaint even from people who seem to like the language).
Elixir/Erlang does need a bit of honest study to hone (this is the same with everything though, JS for instance is quite complex when you take a step back and look at what you need to understand to write decent maintainable code), but the payoff is much higher because it doesn't change with every tide. Code you wrote 4 years ago, if idiomatic, will be idiomatic today, and I'll go off on a limb here and say it will be in 4 years time too.
(btw didn't downvote you)
I'm not trying to derail into discussing how Scala is a shade better or worse than Elixir in some aspect - the main point I'm trying to drive home is that they're both in an entirely different class compared to Ruby/Node/Python.
Your points don't necessarily apply super well.
Point 1 is about hiring and teaching. There's going to be a different candidate pool of people interested in learning Elixir vs Scala, and while I don't know Scala my understanding (heh, see what I'm doing here?) is that it's a pretty large, complex language. So your experience onboarding and training new devs doesn't really apply. In particular your comment about "many ways to shoot yourself in the foot" doesn't resonate with me as an Elixir developer at all. It's a small, simple language, and there's really only one way to do most things.
Point 3 also doesn't necessarily apply. Yes, Elixir is smaller, but for all I know the libraries are better than in Scala or vice versa. I haven't run into too many missing libraries, and the ones we use are generally "production quality", though I don't really know what that means. They have tests, documentation, etc. But again, maybe that's a language culture thing. Dead simple testing, a great doc generation system, and compiler help, combined with general practices prevalent in the community, mean libraries are pretty robust and easy to use. Furthermore, erlang interop is super easy and done a lot. I know Scala has the JVM in principle, but I don't know to what extent you can lean on those libraries, to what extent it's typically done culturally, and to how smoothly they work with the rest of the code.
In short, I think "my Elixir was Scala" is an interesting take and worth sharing. But I think you're leaning too hard on that relationship, without clearly demonstrating that you know Elixir itself, in order to make strong recommendations against using Elixir.
I would recommend Elixir for a startup.
I made a similar comment on a previous article about Elixir: https://news.ycombinator.com/item?id=27194517
I'd not recommend Scala for other reasons: being multi paradigm makes it hard to learn, read, re-read and collaborate on. Kotlin would be a more sensible choice on the JVM imho (no implicit nulls, fully OO at the core with FP where it makes sense in that context, sum-types, exhaustiveness checks, no exception/annotation frenzy like Java).
And Erlang misses types. Gleam[1] looks cool, and seems to be picking up steam.
Rust is an amazing choice if you need that kind of low-level control over performance in all it's dimensions (except built times).
There is a great danger in this. Hence I prefer a language that is smaller and helps me to avoid cruft being checked in to version control. Linters are a solution, I've seen it work in JS/TS project. Not sure if C++/Scala have linters up to the feature level of JS/TS linters.
Compared to what? Java? Kotlin?
And only initial development? Or also maintenance?
And why potentially and not certainly? What can make that difference?
“Different” than what? Its not the 1990s where everyone learns only C++/Java-style static class-based OOP anymore.
> I worked at a well-known everyday consumer tech company where the payments platform went down for the better part of a day as people scrambled to figure out what went wrong. Noone had read the de-facto Scala bible which warned that catching `Throwable` could break your code.
That’s a pretty horrid example for “Scala is a hiring problem because its a different paradigm”; lesson one for exception handling in every language I’ve used that has exceptions is never catch everything, only catch specific exceptions that you know what to do with. And in virtually every language, catch-everything is a minefield waiting to blow up in your face.
There are also upsides that you have to weigh up when choosing a language. I don’t find your arguments particularly persuasive.
I also didn't want to make things "just work" and refactor later, because I think that's just overall terrible advice. The cost of going back and rewriting your architecture is enormous. Might as well use tools you feel confident can scale with your startup than hack something together and have a complete mess on your hands.
What about for not-startups (whatever those are)? I'm attempting to use Elixir for a new component of a kind of startup like product in a 50 year old company. So kinda startupie, kind very not. But more generally, I'm curious what changes with the "for startups" qualifier?
Having said that, I would not recommend Elixir or Scala or anything similar for startups. The 3 main reasons:
1) It's a hiring problem.
There aren't enough qualified people who can fill these roles. Expect a lot of on-the-job training that's more challenging than you'd think since these languages/frameworks are different paradigms. Famously, the complaint I heard in Scala circles was "There are too many ways to shoot yourself in the foot." I worked at a well-known everyday consumer tech company where the payments platform went down for the better part of a day as people scrambled to figure out what went wrong. Noone had read the de-facto Scala bible which warned that catching `Throwable` could break your code.[1]
2) You really, really don't need to get things perfectly right from the get-go.
> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses: you’ve created an environment that’s optimized for your founding engineers to build something quickly in the first 7 months, but the price is a set of recurring obstacles which your engineers will pay down over the next 7 years.
With rare exceptions, most companies throw away or rewrite their initial infra once they hit scaling issues. Having these scaling issues means you've likely hit product-market fit, secured more funding, and hired a badass team to solve said scaling issues.
3) The ecosystem is smaller.
Because the language/framework is deeper, it requires more investment to learn. In turn, fewer production-level libraries get built on top of it. That's when you end up needing to build a lot of things yourself. At which point - you've slowed down _even more_ vs. DynamicLang where you can run `dynamic-package add audit-trail` or something and get the 80/20 solution in 5 minutes.
[1] http://www.tzavellas.com/techblog/2010/09/20/catching-throwa...