Is Elixir / Phoenix ready for production?

@dokuzbir You’re right. I knew I’m going the hard way, because this web app would have been easy to implement using something like rails. The problem is that, in rails every thing is hidden you have to follow conventions without knowing what happens behind the scenes.

I’m basically a chemical engineer working in nuclear energy but I tried programming using Elixir and I fall in love with it. Wonderful syntax, clear methodology because you’re using functions that are easy to debugg etc.

I know that making efforts to learn web using Elixir and Phoenix will help me become a better programmer :slight_smile: and this is what made me choose it. The second thing is that my background as engineer makes thinking in a functional way easier since I did a lot of math. I tried OO and I hate it, i hope that I won’t need to use too much of OO in front-end with JavaScript.

2 Likes

So you know already that it will be easy too in Phoenix, because when you know Elixir Phoenix is just quite like Ruby on Rails.

1 Like

I don’t hear about many people taking the path from Elixir to Erlang. How’s that going for you? (seriously. would be interested in your impressions)

I wanted to try Erlang out long before Elixir, Elixir’s streamlined experience helped me to get some real work done quickly (yes it’s totally production ready) and added to my interest in Erlang/OTP.

I went through the e-book version of http://learnyousomeerlang.com/ which helps to learn Erlang as well as better unterstand Elixir under the hood. So the path from Elixir to Erlang seems natural to me, unless it’s about abandoning Elixir for Erlang.

3 Likes

@crabonature Actually, no there is a difference in complexity to build an app :

  • using Elixir : U need to learn Elixir, Phoenix, Erlang, OTP.
  • using Ruby : U need to learn Ruby and Rails only.

Of course, if your project goes mainstream, the efforts (money and knowledge) required to scale your web app using Elixir will be small compared to when using Ruby.

You can do fine with only learning Elixir and Phoenix. You might want to learn Erlang and OTP but it’s not strictly required to be able to build stuff with Phoenix.

1 Like

It’s just not true, to be fair you should write it that way:

  • using Elixir : U need to learn Elixir, Phoenix, Erlang, C, OTP etc.
  • using Ruby : U need to learn Ruby, Ruby on Rails, C, Linux processes/POSIX threads etc.

Why?

With Phoenix you will not write any line of Erlang code, just like in Rails C code. (but sometimes you have to in both technologies).

Just like in Rails you don’t have to use processes/pthreads, the same goes for Phoenix about some OTP stuff.

1 Like

@younes-alouani i mean hard way because there are less libraries and tutorials. Phoenix is easy and productive as other mature framewoks.
Most of elixir programmers already know more than one programing language. They call themself newbie or noob but they are really experienced programmers. I am the only programmer noob in here :grinning:
Elixir is not pure functional programing. We got some power from OOP desings. Never limit yourself. Because there alot informations written for OOP for improve your skills.I started learning programing with ruby. Ruby opened me to elixir doors. Elixir will open rust door. Rust is currently big bicycle for me i still need some magics. Yo u dont need write to OOP but learn to understand OOP codes.

1 Like

Actually this guy is describing what happened to me hahahah :slight_smile: !

1 Like

Unfortunately it’s not ready for production. When we migrated our entire platform from Meteor to Phoenix, our server costs went down 3000%. Definitely not ready! :laughing:

Our 600 tests run in 9 seconds. Ugh I can barely have enough time to get my coffee!

Our pattern matched functions mean less code being written daily, which is bad for productivity.

19 Likes

My comment is not about right tool. Even i was learning ruby i couldnt find documentation for some of my needs. I read PHP documents. I cant code PHP but i understand. That is what i mean, OOP is like a english for web.

I think you can write a crappy Phoenix-based project without knowing anything about OTP and certainly without knowing any Erlang. We just happen to be conscious, as a community, of the fact that you won’t know what you’re doing and you’re just going to be writing Ruby (on Rails) in Elixir if you do that…

Yes, languages of a certain paradigm are alike. That’s why they’re grouped together. People become enlightened about Haskell every day from using Elm, etc., I’m not sure that’s a point against or for one language or technology as much as it is a fact of how programming has evolved.

2 Likes

Oo… as a person who is begginer in Elixir/OTP I don’t understand what these words mean?

That every simple small scale Phoenix/Ecto based project without need to use some OTP related stuff and Erlang language is a crap?

And what is wrong to write something with similar architecture as in Rails or the same way as there just in Elixir?, is that a crap too?

I don’t think Ruby, Python, PHP, Java, C or any other language based projects are crap, because in every language/technology stack you can write wonderful things at large scale. No matter is it functional, object oriented, declarative or imperative.

3 Likes

I write Rails and Django apps daily for living, but let’s focus on rails architecture… Yes it is crap. Grouping whole application code by the similarity of purpose (models, controllers, etc) instead of grouping it by the similarity of domain (ie. warehousing, sales, or notifications) is crap. Writing whole app as a tightly coupled monolith, without clear boundaries between business logic, and UI layers is crap. Not having well defined internally APIs is crap. Try to write cli, or desktop frontend to rails app… If rails architecture wasn’t crap, things like trailblazer wouldn’t emerge and get traction.

And just a reminder, it’s just my opinion, no one has to agree. And it’s opinion about architecture, nothing personal. I for example really value DHH as a person, especially his opinions about not strictly coding related topics.

3 Likes

I think that I will read only two books and start my project :
Programming Elixir and Programming Phoenix.
Phoenix has OTP included, so i will just use and discover what it behind the scenes later if needed.
Focusing too much on theory will delay the start of my project.

2 Likes

If the scope truly is that small, no. If the scope is actually bigger and someone is trying to fill the gaps without actually knowing what they’re doing they’ll write it like they imagine they’d do in a OOP project, but they’ll use OTP to do it, which is obviously a very bad fit. The result will be crap, because they’re trying to fill a real-time need without understanding how real-time is done on the platform.

I’m firmly of the belief that it can be done, though. OTP isn’t necessarily complicated: You can copy-paste your way to something that works from only the publicly available Elixir tutorials. But you’ll probably not understand what makes a good marker for isolating certain processes, etc., and the inevitable result of that is something that doesn’t fit on the platform.

Edit:

Just to add to this, there’s also the very common idea of “This is a web app, obviously this web portion is my whole app” kind of thinking that leads to massive monoliths without any regard for separation of concerns. I don’t personally think that reading about OTP actually teaches this, but the greater community and the Phoenix team is doing a great job of repeating “Phoenix is not your application”.

1 Like

You write about some framework architecture as they do by default. But no one forced you to architect your system this way. For start you got some defaults and you can do with them what you like. It depends only on you how you architect the system and how you will store your business logic etc… Because you are an architect, not a framework you are using.

Maybe with this traiblazer you are guided better and you know precisely where to put what kind of stuff, but you loose some simplicity of concept (from 3 simple concepts (m-v-c) to many more). Maybe for really simple web app without any business logic it’s not needed at all?
Maybe for them simplicity matter.

When I programmed in Ruby in some years in past, before my 2 years break with computer, in some projects we used to use FormObjects, Presenters, ServiceObjects, other abstractions, microservices etc.
Rails not forced us to not use it in Rails, you can do with it anything you want, because it was just Ruby with some abstractions, even modify code of the framework on your own if you got some special needs. So I don’t think it’s a crap.

1 Like

So begginer question: yyy Erlang is real-time?, or maybe firm real-time? or just soft real-time? :slight_smile:

1 Like

“Soft real-time”, i.e. it doesn’t give any guarantees that something will happen within a certain amount of milliseconds.

2 Likes

Of course, because that’s really what matters. If you start to change the defaults, you can If you want to, end up with something that does not even need given framework at all.

You don’t choose given framework to change how half of it does work, because at this point it actually might have been easier to start from scratch or just use some other tool/framework.

The problem I have with Rails is that it has it’s conventions, and does very much magic to make those conventions work. Most of things are very implicit, and if you really want to change those defaults, framework works against you and not for you.

That’s true. But the more complex business logic gets the harder is to write something sane in rails.

And when it comes to FormObjects, Presenters, ServiceObjects i have a problem with them… but the problem is with glorification of those “patterns”, I think it should be rather clear that when you separate concerns you have specialized objects (classes?) that represent specialized needs. After all you don’t want a model that’s responsible for keeping data in memory, and it’s transformation taking care of the data validation, and about how to persist the data between sessions. Right? But that’s what Rails, and most of Rails tutorials teach you, to bloat you classes so they’re responsible for way too many things. Well I could go on an on… **

But What I really want to say is that Rails are tailored to very specific needs of Basecamp, and they are really easy to write something in it, as long as you follow all conventions. But when the app starts to get complex Rails does not try to help you in any way, and often stays in your way. And because Rails are so popular, and they are not trying to teach about concepts like separation of concerns, as a young developer who learned Rails you may have hard time accepting the fact that the Rails Bloated Classes Way is not the only way, and certainly not the best way.

And sorry for ranting, I just dislike Rails very much, I think because it’s magic and being very implicit.

And answering question in topic. Is Elixir / Phoenix ready for production? Lately I started prototyping new functionalities for a Dajngo app in Elixir and then converting it to Django. And to be honest it’s much easier to write fully working prototype in Elixir/Phoenix than write similar functionality in Python/Django, even tho I’ve been working with Python for almost 10 years already.
__
** It’s also nothing personal, when I started coding I didn’t know that separation of concerns, and clear internal APIs are need to keep applications sane. But so far in my career Phoenix is the first “framework” that takes teaching it from start to any level, beside maybe Django and it’s “applications”.

5 Likes

Separation of concerns/concepts is nothing more than just modularity, software must be decomposed into separated chunks with single responsibility and high cohesion that are not overlapping in functionality or just as little as possible. Terms used by Dijkstra, Parnas and DeMarco at '70 which is almost from ages in computer science, they teach about it probably at every university.

1 Like