5 ms·

> Rails is going to be a better pick in some circumstances because of the huge number of libraries. This isn't really as big a problem as many people think. I

> Rails is going to be a better pick in some circumstances because of the huge number of libraries. This isn't really as big a problem as many people think. I've been out of Rails for a while now but haven't really felt the pain of missing anything with Phoenix. I've noticed there aren't often Elixir wrappers around third party APIs, but those are really not a big deal to create a small version on your own with only what you need. I always used to wrap the wrappers anyway! As far as UI stuff goes, there are actually a lot of really nice vanilla JS libs out there which play really nicely with LiveView's JS hooks. I would be interested to hear what people have been sorely missing, though. EDIT: Said "are" when I meant "aren't"

arrowsmith 3y ago
Your experience matches mine. And ChatGPT has been a game-changer - if there isn't an Elixir library for some third-party API, GPT is very good at generating some wrapper functions in Elixir using the API docs.
davidw 3y ago
Oh, I don't think the library thing and ecosystem is really an obstacle for using Elixir so much as it makes Rails a 'safe bet'. If I'm putting on my business hat, I need a reason to use Elixir instead of Rails and that probably has something to do with a better concurrency story, but I'm always curious to hear what other people are getting out of it. My previous experience with BEAM was using Erlang in a semi-embedded environment and it was fantastic for that. Solid, dependable, deterministic, great response times... all of that. But while we did have a web interface to the system, it wasn't a web site.
- bcrosby95 3y ago
  For us its the simplified production environment. We use BEAM's clustering capability to forgo things like redis and/or a message queue. It probably doesn't matter for every company, but it helps for us where we have zero full time ops people.
  - davidw 3y ago
    That's a pretty good reason. Some people might react "well, you're going to need those things broken out anyway as you scale" or something to that effect, but it can be really nice to just not need them until you have scaled further. There are plenty of smaller applications where you just don't want or need all the extras and the longer you can keep it simpler, the better off you are.
    - sodapopcan 3y ago
      Ya, this is one big bonus in my eyes. I have certainly hear the argument several times that "installing redis is really easy" and it is! But it's another moving part that often isn't necessary with BEAM. In a current project I'm also able to use OTP to create a single microservice for my monolith that runs on its own node and the two can communicate with run-of-the-mill message passing without the need for an HTTP API.
    - toast0 3y ago
      > Some people might react "well, you're going to need those things broken out anyway as you scale" or something to that effect, but it can be really nice to just not need them until you have scaled further. Dist messaging and mnesia scale pretty far. Although it must be noted that they were original built around rock solid networking (two nodes in one chasis), so if your networking is flakey, you have to handle that; my recommendation is to make your network not flakey, but that's easier to say than it is to do.
      - davidw 3y ago
        I would pair BEAM with Postgres, not Mnesia as that's going to limit you in a lot of ways. Unless you reaaaaaally know what you're doing.
        toast0 3y ago
        Well, I like to think I know what I'm doing. And I've participated in some big Mnesia operations. That said, redis is in memory key-value, and Mnesia does in memory key-value too. If you're using Postgres's relational stuff or data bigger than memory, that's a different thing. Mnesia has some relational facilities, but I dunno if anybody uses them much; mnesia can use disc_only_copies, but that's not a good time. Of course, memory only gets you pretty big tables these days; I ran some mnesia nodes with 768GB, but a couple TB isn't too hard to put together these days.
- arrowsmith 3y ago
  My reason to use Phoenix instead of Rails: development speed. I'm just so blazingly productive in Phoenix that nothing else compares, including Rails. Every time I'm forced to develop in another framework I now get agonisingly frustrated by how long it takes to get anything done.

arrowsmith 3y ago

Your experience matches mine. And ChatGPT has been a game-changer - if there isn't an Elixir library for some third-party API, GPT is very good at generating some wrapper functions in Elixir using the API docs.

davidw 3y ago

Oh, I don't think the library thing and ecosystem is really an obstacle for using Elixir so much as it makes Rails a 'safe bet'. If I'm putting on my business hat, I need a reason to use Elixir instead of Rails and that probably has something to do with a better concurrency story, but I'm always curious to hear what other people are getting out of it. My previous experience with BEAM was using Erlang in a semi-embedded environment and it was fantastic for that. Solid, dependable, deterministic, great response times... all of that. But while we did have a web interface to the system, it wasn't a web site.

bcrosby95 3y ago
For us its the simplified production environment. We use BEAM's clustering capability to forgo things like redis and/or a message queue. It probably doesn't matter for every company, but it helps for us where we have zero full time ops people.
- davidw 3y ago
  That's a pretty good reason. Some people might react "well, you're going to need those things broken out anyway as you scale" or something to that effect, but it can be really nice to just not need them until you have scaled further. There are plenty of smaller applications where you just don't want or need all the extras and the longer you can keep it simpler, the better off you are.
  - sodapopcan 3y ago
    Ya, this is one big bonus in my eyes. I have certainly hear the argument several times that "installing redis is really easy" and it is! But it's another moving part that often isn't necessary with BEAM. In a current project I'm also able to use OTP to create a single microservice for my monolith that runs on its own node and the two can communicate with run-of-the-mill message passing without the need for an HTTP API.
  - toast0 3y ago
    > Some people might react "well, you're going to need those things broken out anyway as you scale" or something to that effect, but it can be really nice to just not need them until you have scaled further. Dist messaging and mnesia scale pretty far. Although it must be noted that they were original built around rock solid networking (two nodes in one chasis), so if your networking is flakey, you have to handle that; my recommendation is to make your network not flakey, but that's easier to say than it is to do.
    - davidw 3y ago
      I would pair BEAM with Postgres, not Mnesia as that's going to limit you in a lot of ways. Unless you reaaaaaally know what you're doing.
      - toast0 3y ago
        Well, I like to think I know what I'm doing. And I've participated in some big Mnesia operations. That said, redis is in memory key-value, and Mnesia does in memory key-value too. If you're using Postgres's relational stuff or data bigger than memory, that's a different thing. Mnesia has some relational facilities, but I dunno if anybody uses them much; mnesia can use disc_only_copies, but that's not a good time. Of course, memory only gets you pretty big tables these days; I ran some mnesia nodes with 768GB, but a couple TB isn't too hard to put together these days.
arrowsmith 3y ago
My reason to use Phoenix instead of Rails: development speed. I'm just so blazingly productive in Phoenix that nothing else compares, including Rails. Every time I'm forced to develop in another framework I now get agonisingly frustrated by how long it takes to get anything done.