Elixir Adoption ♥️

Hi Guys,

We are making a case for elixir for all of our future projects as well as company-wide adoption.
We are already happy with what we have achieved with it so far.
But we need community’s help as we are facing few blockers with Elixir’s adoption.
So far we have decided to use either nodejs or elixir.

Please help me with the blockers that we are facing with elixir’s adoption.

1. Installation on windows

  • Most of the machines in our company have Windows-10 as operating system.
  • We have a firewall which prevents many of the sites.
  • Should I open a github issue to find out all the site that elixir-exe installer is connectiong to, so that we can whitelist all those sites and can install elixir via exe-installer.
  • What are your suggestions/tips/tricks to make developement tooling and process smoother on windows machine with elixir ?

2. Package Management

  • Our company use Nexus for package-management. It doesn’s support hex.pm yet.
  • Can we host hexpm like package manager internally ?
  • There is MiniRepo for that. Can we use that ?

3. Overall Advantages of Elixir (Specially compared to nodejs)

  • Concurrency
  • Good Tooling
  • Good Deployment story with docker and containers
  • Ecto, Mix, Phoenix, Db-Libs all are being developed actively and are supported by Elixir/Phoenix Core team
  • Less Fragmentation & Less libraries to install compared to nodejs
  • Built in ETS, Formatter

What else can I add here?

Thanks a lot.

I hope I can create a strong case for elixir provided we can resolve first 2 blockers.

6 Likes

Use *nix, or at least WSL.

Yes

If you want. I have written something similar, and I need to ask my (previous) employer if I can publish it. Then you can check this one as well. In general the required API is quite small and possible to implement rather quickly.

Distributed computing.

3 Likes

Interesting thread, and for me interesting timing! I’ve been a bit of an Elixir fan/lurker for the last couple of years, but I only recently started a work-related Elixir project for the first time in the last few weeks.

I come from a mostly PHP background, and my current employer is very much a Python shop. All that said, my CTO is pretty open minded, and recently gave his blessing to try Elixir in this aforementioned project. To be a bit more specific about it, it’s a Phoenix app, using LiveView, for a demo product that needed to be built quickly for a client — the hope is that it’ll evolve into a big part of the company’s offering. I had some technical arguments for nominating this approach.

I probably don’t have a lot to add to this conversation, but one thing that struck me when working on this project was the experience of writing Elixir in an actual project, when trying to get things done in a hurry.

Like any tooling there’s a ramp-up where you get into the flow of things, how you want to organise your code, and get to grips with using various libraries (like Ecto) in ways you hadn’t considered before.

Moreover, LiveView has been a big paradigm shift, with some challenges (like enforcing auth etc.) and organising that code in a way that’s well organised and understandable. Especially, coming from a place where I’ve written a lot of Vue (which I love and with which I feel very productive) — I feel like I am bringing some preconceived notions to writing LiveView that don’t necessarily map.

That said, I found articles like Steven Nuñez’s Presentation Models article very helpful, and overall the payoff of using LiveView has been great.

But, I think the biggest insight for me, since working on this project is — once you’re into the flow — how easy it is to write code, then move it around, rename/refactor etc. This is a little bit apples to oranges in some respects (legacy code vs greenfield project) but I was also writing integration code on the Python side, and I noticed that the difference in velocity and general WTF factor between the two codebases was HUGE. This was an unexpected and very pleasant discovery for me.

One thing I’d add is, my CTO did point out the “bus factor” of this project and invited anyone else on the team to volunteer to be a mentee on the project. So I guess this is a (well discussed) concern to address — the risk of using one new thing for everyone to learn, which always begs “what’s the benefit?”. I guess this is the reason you’ve created this thread!

Anyway, one guy enthusiastically volunteered immediately, the others showed no interest. I guess that’s how I am going to approach Elixir adoption from now on — one dev at a time! :smiley:

5 Likes

Do you mean NixOS via WSL on windows ?

Thanks a lot :blush:
Can you please ask your previous employer about it.
It would be great if we can leverage it.

It’s more like nix in Unix :slight_smile:

1 Like

Oh…Okay. Thanks a lot @kokolegorille😊
We are using nix then.
But most of the people have windows machine in our company.
So it’s hard requirement to make elixir run smoothly on windows.

Elixir’s installer is failing us.
However I believe we can build it on our machine by following the guidelines given in its readme file.
It’s not ideal but I think that’s the best we can do.

We will try for WSL2 but seems like it’s not gonna pass through security team.

I’m just a Elixir hobbyist but I didn’t see any problems running on Windows 10 while developing. Are you even sure it’s wise to develop in this kind very strict environment? It should be possible to use VS Code and remote machines to do your development https://code.visualstudio.com/docs/remote/remote-overview

1 Like

The windows experience is, in my experience, pretty awful. I tried to set one up at home and eventually just gave up. I’ve been working on Elixir projects for 3 years now… so I can’t imagine what a pain it is for people just trying it out. It’s definitely the roughest edge of the platform for me.

1 Like

I’ve been using windows with elixir for a couple years now, it works just fine only if you don’t have to compile nif dependencies (unless is a rust nif which most of the time works just fine), any c/c++ is annoying to do and requires extra steps and normally breaks things like elixirls because while you can compile with vs dev tools you can’t from vs code itself

So if you don’t have any native compilation honestly windows does not any problem what so ever, othewise just use wsl2 or linux itself (personally I use wsl2 because I just hate using linux for desktop, but that’s personal preference)

2 Likes

Apparently I was not able to compile elixir on Windows 10 by following their guideline.
I’ve raised an issue on github.

Update: Jose helped to close this issue within 30 minutes. RESPECT :raised_hands:t3: :heart::raised_hands:t3:

2 Likes

Installation on windows

For consistency, I’d lean towards using Docker in dev. This will ensure you are running the same Erlang / Elixir versions in dev as you are in production. That said, I have people on my team using a mix of Docker, Linux desktop, Windows, Mac.

Overall Advantages of Elixir (Specially compared to nodejs)

I wrote an article a few years back that compares Node to Elixir called “Choosing Elixir”, and I speak a bit about it on this Elixir Mix podcast.

Concurrency is a huge topic, but there are some very practical benefits I can highlight. For example, Elixir scales vertically by default. So whereas Node is a bit of a chore to utilize all cores and have them talk to each other, Elixir does that by default – and with far smarter scheduling. Scaling across many nodes in a cluster (eg Kubernetes) is surprisingly easy (eg. headless service cluster). For instance, a shared socket channel across multiple servers is essentially turn-key once you’ve chosen your topology strategy (eg. libcluster / k8s DNS). For a more advanced scenario, to ensure 100% uptime and smooth deployments, we listen for a k8s SIGTERM, and quiesce longer running processes. We can “delay” the server termination until everything is cleaned up, including handing off processes to another node in the cluster. That stuff is just very difficult to do in Nodejs because it lacks the process / supervision tree / OTP logic of Elixir.

All that nerdy stuff said, the BIGGEST advantage still comes down to syntax. Functional programming is cleaner to read and maintain. Fundamentally, it comes down to the lack of modifying variables outside of the function scope, and the intuitiveness of modules and functions. This then makes Elixir very testable. A lot of the best practices to write testable code are essentially baked into how Elixir modules / functions work. Writing tests become less of a chore.

Additionally, pattern matching is a HUGE benefit. It’s hard to over-state the impact that pattern matching has on the cleanliness of code.

One final (bonus?) point I would make is how useful ETS tables are (and by extension, the Cachex library). We effectively use ETS as a co-located Redis. You can cache your expensive DB queries in their raw form (no serialization), GraphQL context, etc… It’s pretty amazing.

Hope that helps. If you want, I’d even be happy to chat with your team and go over the real-world pros and cons.

Good luck!

6 Likes

I’ve come off of converting an old legacy shopping system (about 10 years running) I developed in PHP. I knew PHP wasn’t the way forward for us. We do quite a high volume, and we were running into scaling issues left and right. Even if we stuck with PHP, a complete rewrite was in the works.

I decided to try something else. It came down to nodejs or Elixir. Frankly, the Elixir paradigm scared me off. I had already done a few projects in node, and I knew it would be easier to find a dev to help me out if I stuck with JS, so I started what turned out to be a two year process converting everything over to node.

If I had a time machine…

Never again. If you care about predictability in your code, testability, integrity of your data, Elixir is the way to go. The number of hours I’ve spent chasing down silent errors would have paid for a third developer. Silent type conversions sneak into the database. The number of side effects dealing with node has been maddening. And all of these complaints have solutions, but they all also require learning another paradigm, and another, and another. Don’t use mongo without mongoose. Typescript is its own thing as well. All of a sudden, you find yourself relying on an ever-expanding chain of dependencies and linguistic sugar, and the simplicity of the nodejs promise – JS everywhere – becomes moot.

For my small shop, node is fine for relatively straightforward projects. Simple API applications. A small front end for a newsletter. Whatever. It’s fast enough. It scales pretty well. Javascript certainly has a great deal of support out there. But I’m not going to use it to develop anything central to the core business ever again.

It’s been a tough road for me, personally, to get into the functional paradigm. But the amount of time Elixir saves in testing and predictability alone is worth the investment. The rest of my small team is on board. It’s working out pretty well, and I should have done this two years ago.

12 Likes

:dart::dart:

:raised_hands:t3: :raised_hands:t3: I share the same feeling.

I’ve been using Elixir professionally for about 5 years now. During this time, I have converted four NodeJS applications to Elixir. In my experience, NodeJS doesn’t scale well compared to Elixir, Elixir code is faster to write and easier to maintain, Elixir runs faster than NodeJS and has an infinitely better concurrency model.

4 Likes