I'd say that it's all in the eye of the beholder.

Not so long ago, everything FP or reactive programming was considered academic. Heck, even virtual machines, garbage-collectors, threads or distributed programming were considered academic. These days, who doesn't use most of these bricks?

Which means... sadly, it means that I have no clue what the future holds for Elixir, or Erlang, or any technology that is perhaps a bit too much in advance on its time.

I'm endlessly fascinated by the strong opinions people in software develop about tooling. I never saw it with such intensity anywhere else... I'd like to get more into that someday. Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost...

> Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost

It is both of those things, I think, and more. For me, at least in Elixir's case having come from Ruby, it is also that I am acutely aware that Elixir virtually eliminates entire classes of bugs that in some cases took me months to run down in Ruby.

I don’t think it’s a SWE thing at all. Just bog standard human behavior.

People like consistency. They hate change. If they get used to a specific tool or way of doing things, I’m pretty sure you’ll find similar behaviors.

The key is time spent with a tool. I would expect if you took away an engineer’s favorite CAD software, even if it costs many thousands of dollars, you’d see a similar reaction. Would they be able to do their job with another tool? Certainly. Will you hear about it? Even more certain.

I moved away from Rails and then back to it because I really wanted to join a particular company. The answer to 2 is somewhat yes, but Elixir no longer counts. People "build" with Elixir, it's the builders FP. This isn't my opinion (I try not to have one on this subject, fed of language snipes) just the general attitude I've noticed.

> Elixir, it's the builders FP

I'm really glad to hear that, because to me it does seem like Elixir is the FPL that is closest to satisfying a GSD mentality and not getting caught up in too many interesting rabbit holes.

We (Ockam.io) are definitely building very real and critical things with Elixir. We filled our remaining open position for it last week though so we’re not currently hiring for an Elixir person. Just wanted to point out there’s definitely companies out there that value it for non-academic reasons.

What was your method for hiring; were you looking for Elixir people who can come in hot, or people interested in it specifically that want to learn, or just "good software people" who'd be WILLING to learn it, or something else entirely?

I wasn’t the hiring manager for those roles, so I’m not 100% sure. If by “can come in hot” you mean people with existing Elixir experience, then based on who we hired I’d say that previous experience would have been required.

What does GSD mean, please?

Get shit done

Answered already, but in $previousjob we had a team named that, for the reason given. I thought it was kind of clever but unique - 3 jobs hence I work for another company that has the same, so maybe more ubiquitous than I'd thought.

I find being a "builder's FP" more true of something like Rust than Elixir, in my experience. This is mainly due to the lack of static and algebraic types in Elixir, which makes debugging very difficult, as well as more annoying to reason about the problem domain, because you can't represent it in types as well.

> lack of static and algebraic types in Elixir, which makes debugging very difficult

In about 6 years of working with Elixir, I've found it easier to debug than pretty much every other language I've ever worked in. But to be fair, I've mostly been working on code I've written myself in that time (although you'd be surprised what you forget in a year and then go back to).

You can also add typespecs; I know it's opt-in, but it's something, and it will get checked.

Algebraic types are orthogonal to functional programming.

Functional Programing can be static or dynamic.

Also, Rust isn't an FP language, per say, it has way more in common with the imperative programming paradigm with some ergonomics lifted from the ML family of languages, specifically around it's type systems.

I think people who are earnest about the sentiment aren't screening specific languages. They're trying to find people who think hard about business problems and follow with implementation.

We do this. Our hiring process is impossible to pass for people who fixate on implementation. We have people do a simulated building exercise, and the developers that do well let the user needs drive the implementation.

We think we've noticed a correlation between some dev communities and people who lead with implementation. We've seen a little of this with Elixir, but I'm not really worried about it. We've found a number of people who really enjoy Elixir that are also user-first.

When you talk to a manager, you should lead that you are interested in building great products. Even if my company is using functional technologies, I want people who are professionally interested in learning business domains. It's great that you're interested in functional programming, but my fear is that I will hire someone who puts great effort into changing the culture to use avant-garde tech in a place that doesn't provide return on investment. (Or worse, drags us into a culture of malcontent!)

That isn't to say Erlang, but I've also seen an organization that struggled to hire because it couldn't find enough Clojure expertise and saw good developers onboard slowly because they had to learn domain, language, and paradigm in a practical environment.

There is a secondary worry in hiring people who present as tech-forward: if we need to make pragmatic decisions that mean using industry standard technology, will they leave out of frustration? If we need to make a decision to leave some technical debt there for business reasons and address it later, will this cause difficulties with the developer? ____

(That said, I know a fair number of good developers who have struggled to find work in this environment. It has nothing to do with Elixir.)

> I want people who are professionally interested in learning business domains

You can want in one hand, as the saying goes. If you select for people that care about business domains you're more likely selecting people good at feigning interest in your business(aka liars, or otherwise honest people who need to eat). Even if you get what you want you won't do well in the long run. I rarely see people who aren't passionate about technology avoid making a mess of it.

I have genuine interest in both. I build things because it's awesome to make someone's day better. It's a demotivator for me to put out software that doesn't work well. Technology is a means to that goal.

Because I'm wired that way, it's a lot easier to find people who are also wired that way. But I can say that there are absolutely places for people who are wired to be passionate for technology for its own sake. (Some of Fintech and adtech is a good place, for example.)

And if you feel you need to lie to work in a place with a product driven culture, then great. But don't be disappointed when the job is listening to calls with users and your conversations are around "which of these approaches will make the user's life better?" and there are technology radars that are justified by users' needs.