It's not only the price, but also availability. In 2010 I had to choose a technology stack for a new project (in Germany). Personally I would have loved to choose Rails. It was very promising and solved many repeating patterns of web dev in a very systematic way. But: I didn't know one single Ruby/Rails dev. Back then not too many startups used Rails in Germany; the most prominent one was Soundcloud. On the other hand I knew many PHP devs, although none of them had programmed in a web framework before, rather they were using their own set of self-developed solutions for various things, Smarty for templating, no ORM, etc. Their approach was way inferior. But nonetheless I decided to choose PHP + the Symfony framework. It was a good decision. Because I had access to PHP devs, I could hire PHP devs, give them enough time to get familiar with the Symfony framework. But most importantly: I could hire them easily in Germany and yes, they did not cost a fortune.
Today I would love to start a project in Elixir/Phoenix (or more realistically: Python/Django), but I don't know any Elixir devs in Berlin. And I don't know too many web devs using Django in Berlin. Again if I had to build a static website, I would choose PHP (+ Laravel framework). And if it was a dynamic web app, I'd choose Node+React. It's all about availability and feasibility.
(1) You keep saying you didn't know technology X or Y devs in Berlin. Sorry to partially derail but why is remote forbidden in your organization? I mean, you're pointing at a limitation that's rather easy to overcome.
(2) Bigger developer availability == good for business, you claim. That's very 50/50, neither side of this argument is anywhere remotely universally correct. "If all you know are hammers all problems look like nails". I've had PHP devs ruin near-perfect projects in teams where I was working. Their reliance on the arcane-but-overall-working comparison operator alone introduced at least 150 bugs over a year.
Bigger dev pool != better for business. It just helps you treat people like replaceable cogs in a bigger machine. That's not the same thing at all.
(3) Known tech != quick onboarding. You yourself pointed out your new hires needed to learn Symfony. And you claim to be interested in Elixir and Phoenix. Well, for one thing, Elixir is extremely easy to learn as a language; secondly, it's OTP (the Erlang / Elixir concurrency framework) that's hard.
So what you said could absolutely apply to Elixir. The language is learned extremely quickly and then people have to spend some time getting to know a framework. It's the same everywhere really.
I feel your comment was putting too much weight on local physical availability of programmers and that's the wrong metric to use when assessing new (and possibly better) tech.
The project had a very tight budget. That's why relocating devs from across Germany / Europe was not an option.
Also, even if the funding was better: One important aspect is: What if key developers (in that fancy new technology) leave the project? How fast can you find new devs? If it is a widespread technology (say: Node/Express + React) there is no risk. But think of hiring Erlang developers in your region.
I like Scheme (and it's influence on JS), I love functional programming, I like Ruby a lot, I really love Elixir. I like Python and Django a lot. But when it comes to setting up a project there are many aspects that determine my decision for technology. Some very important ones: What are my tech alternatives to tackle a problem? How wide spread is that technology in my region? How fast can I hire talented people in that tech?
I do acknowledge that a small team of good Python+Django devs for instance can work more efficiently than a team of PHP devs who don't appreciate software engineering qualities (not saying that there aren't really profound PHP devs out there, but many PHP devs who don't have profound software engineering qualities). There are only three real alternatives for web dev in Germany (if you have a tight budget): PHP based, Node/Express+React/Angular or Ruby/Rails based. I wouldn't even consider Python/Django, and forget about Elixir/Phoenix.
Known tech is quicker onboarding. Not all business have the capacity to train devs on new Lang's, but if your company does have that extra capacity then sure, no problem.
You ignored my point but I'll still repeat -- onboarding new language is relatively quick (several days). Onboarding new frameworks for languages people know is much slower.
So no, I disagree. Known language is not quicker onboarding for a framework. You'll save 4-10 workdays out of the several dozens needed for one to become an expert in a framework.
IMO framework + codebase. Even if we're talking about companies using off-the-shelf frameworks and not something homemade, the project using that framework uses it in its own, peculiar and usually undocumented way, and figuring that out is even more difficult than figuring out the framework. This cost is present in pretty much every software job.
It grinds my gears to hear that legend over and over -- "new language is very risky and slow to adopt!", even though a lot of us know that the language itself is the lowest barrier of all.
On top of framework and codebase I'd also add organizational or team coding style. It becomes a bloody mess pretty damn quickly. I've personally spent 6 months being onboarded in a very finely tuned and hacked to oblivion Rails project -- a technology I knew pretty damn well at the the time -- and then it took me 3 weekends to get my own Elixir / Phoenix project off the ground... and for it be useful in business terms as well.
So these "new language risks" are vastly overstated and are simply an excuse for dogmatic people to not act in the project's best interest.
Today I would love to start a project in Elixir/Phoenix (or more realistically: Python/Django), but I don't know any Elixir devs in Berlin. And I don't know too many web devs using Django in Berlin. Again if I had to build a static website, I would choose PHP (+ Laravel framework). And if it was a dynamic web app, I'd choose Node+React. It's all about availability and feasibility.
Edit: punctuation