Getting things done with Elixir - tips?

I always look at new languages in terms of existing apps I’ve done. FP is just such a mind shift.

Since this post, I wrote a tiny utility in functional Scala. It took a ridiculous amount of time. I guess for existing apps I need to think of the smallest possible app, rather than a “real” app.

I would also say the benefits shine(at least for me) when supporting an app wrote in functional style. It is so much easier to debug/add existing features when everything is a pipeline of function compared to some of the messes I have seen in imperative code. So while it may be taking you more time to write your application with FP(although I suspect that will change once you use it more, I can write code in elixir way faster then any other languages due to familiarity) I am willing to bet you will see some nice pluses down the road when used.

1 Like

I don’t know Scala at all (actually no FP language besides Elixir), so perhaps it’s more contrived in there, but my experience has been exactly the opposite. Doing changes in function based pipelines/actions is a breeze compared to other things, even with ruby/rails where you can do quite neat magical tricks.

I’ve been developing a game, , which basically uses resources to play “spells”, I had 6 different resources all exactly the same type (think of it as “energy” that is in a pool), then decided a cool resource to also use would be the total life-points you have, which is a total different type. The change in the rules engine in the back-end, in elixir, took me 5 min, the change in the front-end to allow that interaction took me an afternoon (and probably because it’s written with vuejs, otherwise…). The rules engine is currently at 3.4k lines. Ofc this isn’t always applicable, but I guess it would probably be a completely different case if it wasn’t a functional pipeline.

To be fair, @Justin seems to be talking primarily about taking a project you already have a mental model for (presumably an imperative model) and translating it into FP from the start. Making changes in a primarily data based system that focuses on transformations is potentially something that he agrees completely with. I think you’re talking about two different scenarios.

On top of that everyone has a different level of familiarity with FP and this obviously will impact how well you find analogs to things you’ve already done before.

1 Like

Fair, but in this particular case this game was started in Rails with Jquery, it was getting so out of hand and complex that I decided to learn elixir (mostly because of phoenix & websockets at that point) and a front-end framework at the same time (vuejs), so it’s effectively my first project in elixir (and vue) and I still say that making changes to the back-end is fairly trivial compared to what I had before, and translating what I had from rails (I literally started with that as my “template”), although not totally painless was still very manageable. I don’t want this to sound like “you’re not getting how it’s done”/“you’re dumb”/patronising, rather share that I don’t agree with this, from my experience.

Now that I re-read it, perhaps I misunderstood, and it means “doing a small part of each large app independently and not trying to translate the whole app immediately” and if so, I would agree.

1 Like

Scala is definitely not for small apps like that, but rather it has a higher initial overhead, but it has much better maintainability later, like most good statically strongly typed languages, though I’d prefer OCaml personally. ^.^

Scala’s pretty good though, yeah is has some line-noisy stuff, but that’s because it is mixing HM+Extensions with Java’s ecosystem, I used Scala for a few years a long while ago (2.11 was brand new at about the time I stopped using it).

To learn a new language I like to make a new language in it as making a compiler tests so much stuff about language design that I find it a good way to learn. :slight_smile:

The Scala app was from scratch and the code probably fit in a single screen. I did Scala because JVM is compatible and supported, while BEAM is neither.

For perspective, one of the apps I’m working on now at my day job facilitates loading various packages into different containers. It’s modular, imperative, procedural code, about 7.8k lines of code total.

BEAM is not compatible and not supported… by what or who? :107:


AIX and IBMi.

Well that’s a case by case thing. If your project has to live in that environment then obviously you will optimize for that.

I think it’s fairly safe to say that the BEAM runs on a lot of hardware and operating systems. It might be safe to say that your case is pretty niche but I am not informed well enough to claim that; it might easily be a semi-hidden market with a lot of money in it as well.