I've recently had an interviewer tell me that "Erlang is an academic language" and promptly stop the conversation after that. That's in a company that was attempting to make distributed applications easier to write.

This was both:

- factually wrong;

- a bright red flag that the company doesn't know their own domain as well as they think/claim;

- a bright red flag that their scope is much more limited than what they claim in the job description.

:shrug:

"You wouldn't perchance know what the 'Er' in 'Erlang' is short for, would you?"

Oooooh!! I know this one! Ericsson!

Do I get a prize?

I personally don't mind academic.

However, part of my response was that Ericsson had been using it industrially since the 90s, and that in fact Erlang was actually less academic than Python or Go. The recruiter handwaved this as "well, it's an academic language".

You totally dodged a bullet.

Even if the company despises Erlang for whatever reasons, it's still very valuable for them to examine and be educated about it. Erlang makes tradeoffs for X optimizing for Y, we'll choose a different tradeoff since we're optimizing for Z.

Once I interviewed at a company with many competitors. I continually asked "how will this company succeed while the competitors have a ten year head start? What choices do we make that the others didn't?". I got blank stares. Literally nobody was interested in examining the competitive landscape.

Oh, I've had that, too. I've interviewed with a few companies that create products that are literally years of research behind their (sometimes free) competitors. And don't realize, typically because they don't have the skill to even comprehend the difference.

And for fun, all these companies interviewed me on cloud development, rather than on their core offering, despite the fact that I actually happen to know a thing or two about said branch (i.e. I have both a PhD and commercial experience in the domain).

One of the things that makes Erlang so practical is that it is not an academic language.

I’m guessing it’s probably the prolog-like syntax that gets it thrown in to that category by some. I’ve never heard someone consider Elixir “academic”.

Well, it tells you those things about that specific interviewer.

I would just stress to folks that red flags go both ways. If the work environment seems toxic from your experience as a candidate, chances are it will only get worse once you join.

That's not both ways. That's exactly what a red flag in interviewing means.

Employers look for red flags in candidates, candidates should do the same. My apologies for confusing you.

1) "The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer."

This sort of person intends to sleep in the bed that they make, so best to leave them to it.

On the other hand...

2) I'm an Elixir guy looking for work for a few months now. Should I be concerned that this is the perception out there? IS this the perception out there?

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.

What company. Worth avoiding.

> Anyway, I did take a non-eng role there, and it was easily the worst and most abusive (like verbally abusive, psychological abusive, generally fucked up) places I've ever worked.

Sorry this happened, but it’s a good lesson for everyone: If interviewers do anything resembling “negging” in an interview, they’re trying to push your limits and see how submissive you’ll be.

The founder may not have cared about Erlang. He just wanted something to attack you with.

Some people think that lightly insulting people is a way to get them to work hard to prove their worth. It does work on people for a while, until they realize they’re being used and abused.

Is there something about Erlang itself that makes it an attractive FP language for you, or is it the environment (Beam, OTP)? As a web dev, I find the performance of the system and concept of the actor model appealing and interesting, although admittedly I lack an in-depth understanding. I found the language to be too high a barrier though. This includes Elixir. http://efene.org/ looked promising, but when I tried to install it, I had some issue with something being outdated. Gleam is the next thing to try, although the more I read about it the less I understand, lol.

I've done some toy Elixir things and I really like it; not enough to get hired but enough to like the shiny packaging. (It might be that shiny all the way down, I just don't have the experience to say.)

Gleam though... that looks more to my liking _syntax_ wise. Familiarity more than anything, but might try some toy stuff on it soon.

BEAM interests me immensely from a user standpoint; I'm just wondering how much time it has in the world vs. containerization and orchestration.

Haven't heard of efene yet; thanks for that. Now my Sunday's ruined =D

> The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer.

Man, that would have left me with such a bad impression that I would have ended it right there, no matter the role.

That said, I've taken jobs where I had to in order to eat, and at least one of them ended up being shit, so I empathise.

Yeah I almost cried partly because it was so unexpected, and partly because I was so desperate dealing with lots of housing instability, and this was one of the first companies that even reached out to me for an interview. I wish I had more of a spine back then because that ended up being hardly the worst of it

In a way I'm glad to have gone through it -- I think it's helped me to be a lot more compassionate in situations when I have any kind of leverage over another person, and it taught me precisely all the wrong ways to treat people in general. Probably most significantly, it showed me that there are major costs in committing to fucked up people, costs that might not be obvious at first. Like you can think you're aware what you're getting yourself into, you can tell yourself it's just for a paycheck, but if they get inside your head at all, you might be dealing with that shit for years. And you can be sure that predators like that are all about getting inside your head