Developer presence in Northwest (US/Canada)

Million-dollar question: why do you need people on site? What’s wrong with remote? Unless you have a very small budget for a minimally viable product and want it done in a month (which implies a constant back-and-forth communication in an office space), there’s really no reason to require people be physically present.

Why limit yourself like that?

Elixir being young is misleading. Erlang, the original language of the BEAM VM (in which Elixir also lives and runs its code) has been around for 30 years. Countless telecom equipment and internet backbone tech run Erlang around the world. Elixir itself might be young but the tech behind it is as mature as you can get.

If you are gonna write proposals and will advocate for Elixir (not sure if I understood that part of your post correctly) then you absolutely want to include Erlang and its mature background. If you want to advocate, here’s a link to a huge thread I made not long ago: Please help me persuade a Java CTO that Elixir is the right choice. If you wanna read, you can find a few gems in there, shared by several people.

In Scotland Elixir is not having too much adoption for now, thus developers from any level that want to work full time with the awesome Elixir will have a very hard time making their dreams become true, because of the cultural resistance of companies in recruiting remote developers and/or cross training them into Elixir, not to mention that a lot of them already want they come with a lot of experience in Elixir.

I would like to see this trend to change and see companies to not have afraid of:

• hire more remote developers.
• cross training developers from other languages into Elixir.
• giving opportunity to entry level developers looking for their first professional job.
• dismiss the academic background in favour of a self learner and passionate developer.

Ironically, the reason you list to do so is the one that I would never consider for not going remote. For me a constant meetings and interruptions practice is never of value. For 1 of the 3 serious projects I’m looking into I would be fine purely with remote. For the others there is testing of rugged hardware in fired out/flooded buildings + training, factory based closed system integration in Canada involving robots and support contracts. Not to mention if I get my favorite Canadian whiskey and like to sit down to discuss ideas who will I drink it with? It’s not really a question of why limit myself. The question for me was remote is easiest but why limit myself to that if I don’t have to?

For the rest of what you mention, I should clarify for Elixir being young, a more accurate statement is more about it being niche causing the search for developers to be a smaller pool but a more focused search. Erlang does make it into my proposals but I don’t expect that to be game changing even though for ME choosing the tech, it is. I thank you for the reminder though. And good pointing out that thread btw, I had read it before and think there will be some useful info there.

I hear ya. Had one dev I work with say they wouldn’t want to learn it due to job market data. From my perspective it seems silly but I guess some folks don’t know what they are missing. The training argument is funny because I see so much training to do with languages that don’t offer any new paradigm etc.. so the time and money exist.. nobody takes a risk that the big guys aren’t taking.

Looking for consiencousness and learning is definintely more solid than algorthim/whiteboarding nonsense generally person by person, but hey.. valley culture is still winning atm. Let’s turn it around

Perfectly valid, thanks for clarifying.

I need a co-worker or a boss like you.

I’d additionally challenge the claim that Erlang and Elixir are niche. Here are the things they are NOT good at:

1. A lot of number-crunching.
2. Working with a lot of short-lived data that needs to be mutated in-place, like big graphs or trees (DB index comes to mind).

…And that’s pretty much it. Erlang/Elixir aren’t made to be uber-performant and they really want their immutability. If those are in the way then the project should not be written with them.

I heard people argue that if your code is only single-core then you shouldn’t use Elixir because it’s waste of potential or something; but they do miss the fact that your code is still gonna be much more concise than, say, Java, C++, Go or Rust (I like Rust but it is quite verbosive sadly). And easier to evolve.

In another thread a guy shared they were doing 60 FPS streaming with Erlang monitoring and managing C++ workers which were doing the tough legwork while Erlang basically took care of everything else, including coordinating those workers.

There are numerous advantages to Erlang / Elixir and there are actually not many things they are bad at.

The businessmen are triggered by certain keywords and ideas so what won my case in front of a CTO was mentioning the tech has been battle-hardened by 30 years of development, being one example.

(All that being said, I’d be interested in working with you on one out of these three projects you spoke of.)

Oh I hear you believe me. It isn’t niche in capabilities but the community is seen that way and I have to live with that reality I feel like. Compare it to Java and you have to admit you’re suddenly talking about a decision you have to explain more right? I’m speaking toward the culture more than what the language is capable of. I love everything about it that you do.

Way back I was an adept in Prolog so for me, it was absolutely a given early on that elixir would be more efficient to program in day to day than the others. It’s not just an academic argument in my opinion but it seems to be viewed that way by many. Sounds like we’re in the same boat and trying to rock the waters a little.

Used rust/rustler with erlang to solve a problem recently btw.. love it too but agree on verbosity. It does offer a new paradigm which is nice, more so than Go it seems to me and it was FAST as advertised.

Anyway awesome to hear your interest, keep in touch! Things are looking great so far and I really do hope to get a chance to work with people from the community here.

Elixir + Whiskey sounds good! Always interested in both

I have been running a product development agency for a dozen years. We have two kinds of customers, those who come to us with a tech stack, and those who trust us to make the decision. Sometimes the customer has a legacy application, and we need to work with it and improve it. Sometimes its a new application.

There are some applications where Elixir is such a great match that using anything else would be silly. I think that’s true for chat, e,g, WhatsApp, XMPP (ejabberd/MongooseIM), Discord, and custom web/mobile chat things. It’s good for high performance, concurrent network services in general. I think it’s a good match for things that need to be very reliable, and Nerves is a great way to make embedded systems in a post-scarcity world. These are all the things that make people excited about Elixir, and we don’t have to make any excuses.

A similar story can be told for health care and financial services applications, though there are other popular platforms, e.g. Java. There are other apps where it doesn’t make as much difference, e.g. CRUD apps. Elixir/Phoenix does perfectly fine at building these things. It doesn’t have as many libraries as platforms like Rails, but in four years of using Elixir/Phoenix, it hasn’t caused me significant problems. You need to have enough budget to do some new things, but it can be managed.

I talk about my thought process when determining if Elixir was ready in this post:

As a professional, I am not going to recommend technology to a customer that is not right for them. But I don’t think that simply choosing a relatively niche language is a big problem. There are plenty of web frameworks that get abandoned. The half-life of JavaScript frameworks is about a year. That’s probably a worse problem.

We are the long term partners for our customers, and that’s the most important thing for them. We are still supporting PHP, Rails and Python applications from 10 years ago, and we will do the same for Elixir. I think that Elixir is going to be around for a long time, just like Erlang.

Addressing your questions more directly, I think that good developers don’t have a problem with Elixir and Phoenix. It generally helps us with recruiting. We have been able to transition projects to customers staff and train/mentor them on Elixir. If you open up to remote, then finding developers is not a problem. We work remote from our customers, and we hire remote developers. And we are happy to work with agencies that want to ensure that they can deliver with Elixir.

I’ve been in “enterprise Java” for anywhere 5 to 8 years (depending on if you count EJB 1.0 and 2.0 as “enterprise”) and truthfully, most financial systems I encountered were nothing more than very thick wrappers around carefully crafted and very fast PL/SQL stored procedures. It’s quite silly and I could never understand why such systems are advertised as Java systems at all… Just sharing a tidbit here.

Any upfront development time invested in Elixir is very quickly alleviated by all Elixir apps needing a lot of load to even start lagging noticeably… whereas a Rails apps gets brought down to its knees much, much earlier. But I believe you already arrived at the same conclusion.

This cannot be said enough. Many people bash lesser known tech for the numbers but they never give the lesser known tech a chance; goes to show you most are only followers but that’s another topic.

Esp. in JS as you mentioned it’s a huge problem; knowledge there amortizes and gets replaced very quickly.

In my eyes and practice Elixir brings many benefits to the business for free. It only asks for a small culture shock and a small leap of faith and it repays them handsomely. Alas, even those small upfront costs are too big for many.

I think the key question is trust. The most important thing is that the customer trusts that you can solve their problem at a price they can afford, and you will be there to support them. Then you need to address practical questions like working with their existing systems and infrastructure, and the ability of their team to deal with the technology, and their ability to hire or train developers.

In “enterprise”, conservatism over the practical things mean that you end up with a lot of generic Java and don’t address the more fundamental problems. Nothing ever changes.

Here is an example of how Elixir can help solve fundamental access control and security issues in financial services and health care apps: Secure web applications with GraphQL and Elixir