Phoenix and Elixir, if you understand the choices made, is also a wonderful choice. The whole contexts thing allows you to design your system as micro services before you even add in network partitions, and Ecto, not being an ORM (it’s a DSL for writing SQL in elixir) is incredible, better than it’s possible to be in active record. Then there’s channels, presence, performance etc.

> Phoenix and Elixir, if you understand the choices made, is also a wonderful choice

Until you want to integrate Stripe, BrainTree, PayPal or Paddle and then you can't find an official library for Elixir. Even common things like pagination isn't fully solved with well maintained libraries in Elixir. Then there's things like wanting to create notifications (showing unread icons, sending email / sns notifications, etc.) where Rails has this solved with well supported gems but there's nothing like this in Elixir. There's dozens of other things too, and all of this adds up to you having to be an expert in Elixir and have to write all of this functionality from scratch.

If you're in it for the long haul and are investing years into the project with a big team that's fine, but if you're a solo developer building an app and want to focus on writing your app's features, in my opinion Phoenix can't really be compared to Rails. Especially with Hotwire Turbo being recently announced, now you can get all of those awesome real time features into a Rails app quite easily (IMO even easier than Live View).

I started a SAAS app with Phoenix a while back and ultimately backed out of it because all of the above. It just felt like I was in a perpetual state of having to write libraries instead of my application. It was one of those things where I got super excited initially but after 2 years of trying, waiting for certain features to come, etc. it ended up not being for me.

I have no regrets tho because I learned a really big lesson from that, which is if you want to build something now, use whatever tech stack you know right now and if you're very much inclined to deviate from that and learn something new then pick something based on what exists today in that tech stack. Not what's "on the horizon" or "coming soon". You could set yourself up for waiting forever, or if that feature you wanted in the future does come out it could be way different than what was originally claimed and now it feels like you've delayed what you wanted to do for so long for nothing.

In other words, nothing is ever going to be perfect. Just pick something and build it. Also trust what folks do, not what they say.

I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it. What specifically are you struggling to paginate, I’ve never found that difficult to implement even with quite clever options. Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them. Elixir+Phoenix I agree is definitely lower level but there are things it does much better than Ruby on Rails. I’d rather not have to rely on gems and write the simplest implementation specifically for my use case. It’s a trade off, but one I’m much happier with.

> I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it.

It's way more involved than inserting an auth token header into an HTTP request and calling some API endpoint.

For example, what about verifying webhooks? The official libraries for Stripe (Python, Ruby, Node, PHP, Go, JS, etc.) deal with this for you.

But with Elixir, you're on your own. This is very low level code to have to deal with and it's extremely important you get it right.

You're left having to parse Stripe's specification on this and then implement the code yourself in Elixir. It's so tricky and involved that the Dashbit company (the creator of Elixir and members of the core team work there) wrote a blog post on it at https://dashbit.co/blog/how-we-verify-webhooks.

But before a few months ago that blog post didn't exist. Also this isn't the only thing you'll have to do yourself when it comes to interacting with Stripe using Elixir.

Then you'll have to do similar things for other payment providers all which are different in a lot of ways, but with Rails you have the combination of having official Ruby clients from those payment providers and even the Pay gem which lets you support payments from multiple providers. That could easily be a few months of dev time just for that abstraction alone if you had to go about that from scratch and your implementation wouldn't have any track record until you start using it and ironing out the bugs from real world experience.

> Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them

Don't take this the wrong way but this seems to be the mindset of almost everyone I chatted with when it comes to Elixir. When someone asks how to do something, the answer is it's trivial or easy to implement but there's rarely any examples posted on how to do it and almost never in a production ready way.

In my mind trivial or easy means I can sit down in maybe a few hours or a day and write a production ready solution, complete with tests and have it work exactly how I want without running into any major roadblocks.

I'd be curious to see how you would implement https://github.com/excid3/noticed or https://github.com/pay-rails/pay in Elixir / Phoenix. Based on your responses of saying these things are easy I'm guessing you've written large apps with Phoenix where you've developed features like this in a production app? It would be fantastic if you could post some code examples or a blog post on how you went about this. Not just to answer my specific question but I'm sure the community would appreciate having concrete examples of how it's done. This way maybe more folks would use the framework.

Here's some links by way of an answer for you...

Stripe, including webhooks support, actively developed: https://github.com/code-corps/stripity_stripe

Global pay solution that supports everything: they are all a bit crap you're right, the best I've found is https://github.com/aviabird/gringotts and ex_money really is amazing that integrates with it (I would suggest it's better than the equivalent ruby gem). To be fair I'm not sure I'd want to use the pay gem with anything complex as you need to be able to use the specific quirks of each API properly (for example it can't pause subscriptions on stripe right now even though stripe supports this: https://github.com/pay-rails/pay/blob/master/lib/pay/stripe/...).

You're also right about noticed, after looking into it more it would be worth building for elixir for sure. Ravenx represents a start but it's unmaintained and doesn't have a huge number of strategies. It depends on how much I needed to do notifications like this. For the apps that I've built we've just needed database and grouped emails sent once per day, no need for texts or slack etc. There's no reason these couldn't be added fairly simply but I agree noticed is very neat. It's definitely a few weeks work to roll your own from scratch so to be honest I'd probably just integrate with Twilio and just pay for someone else to handle this for me.

Thanks.

> Stripe, including webhooks support, actively developed

I've looked into Stripity Stripe. For some time it was unmaintained and ended up getting taken over by another maintainer. It's also not as comprehensive as the official Stripe libraries. There's also a very big difference in using an official Stripe library and hoping for the best with a random one someone developed. Just skimming the code base it looks like the Checkout module is missing features that exist in the official Stripe library in every other supported language.

According to the README file for Stripity Stripe it's also using Stripe's API version from 2019. There have been multiple major API updates since then, and there's been an open issue since November 2020 to add support for newer API versions with no replies. Personally I would be using one of those major features too.

And this really is the point I'm trying to drive home. With Ruby, Python, Go, PHP, Node, Java and .NET these are problems you don't even need to think about. You just pick the payment provider's official SDK and start coding immediately, often times there's also an abundance of resources to implement the billing code itself into your app too through blog posts, official docs, YouTube videos, and even paid products like https://spark.laravel.com/. Stuff that makes integrating billing into your app (through Stripe, BrainTree and Paddle) being something you get done in 1 day instead of 3 months.

With Elixir it becomes weeks of comprehensive research, evaluating questionable libraries, opening PRs, and becoming a full time library developer just to get to the point where you could even maybe begin to start accepting payments with just Stripe. Then you have to repeat the whole process for PayPal, BrainTree and / or Paddle. These are all super popular payment providers.

> the best I've found is https://github.com/aviabird/gringotts

I asked the Gringotts developers if they would be supporting PayPal about 5 hours after they announced the project ~3 years ago. He said it was coming and to stay tuned. It's now ~3 years later and PayPal support isn't there. Neither is BrainTree or Paddle. Here's the open issue for PayPal support from 2018 (not by me, I asked on another site) https://github.com/aviabird/gringotts/issues/114. The Stripe integration is also missing a ton and hasn't been touched since 2018.

By the way, the Pay gem is really good. It's a smart abstraction and supports a ton of different subscription / 1 off payment use cases. Even complex ones like the type of app I was building.

> It's definitely a few weeks work to roll your own from scratch so to be honest I'd probably just integrate with Twilio and just pay for someone else to handle this for me.

Twilio ends up being 1 potential delivery method, it's not really someone you pay to solve the problem for you.

There's wanting to show notification in the app over websockets, saving them into a database, emailing them out only if they are unread, maybe sending a text through Twilio, Slack and other providers.

The noticed gem handles all of this for you (and supports Twilio too).

Notifications in general is another example where other frameworks have this solved in very good ways, but it becomes another example where you have to stop developing your app and start developing a notification library with Elixir.

At this point we've only talked about payments and notifications too. There's lots of other examples and these are all things to think about if your goal is to build an application.

Now don't get me wrong, it still takes a lot of custom code and effort to build an app with Rails but the time spent isn't on low level generic problems. It's letting you focus on your custom application's business logic.

And with less opinionated frameworks like Flask you can lean on Python being extremely well supported by almost every service that offers an SDK and also being able to find solutions to nearly every web dev problem online in some form or another (blog posts, youtube, stack overflow, etc.). That goes a long ways because at least you're not starting from scratch.

What I love with Phoenix/Elixir is that there's plenty of features I wouldn't bother with in a more traditional language. You want a PubSub? It's just there, you can use it in one line. You want a Redis? Registry is there, also in one line. It's like a whole tech stack in one language.

I saw a presentation about Phoenix/Elixir that described this once and it really impressed me. It's been 4 or so years that I've been meaning to pick up Phoenix for a project but still haven't.

Was it a publicly available online presentation? If, please share title or link if you can.

It was a slide from a conference I believe but I wouldn't know how to find it - some elixir people in the thread might know. It was something illustrating all the external tools you'd normally reach for and how Erlang/Elixir just had all of this built into the language and VM.

That sounds like one of Saša Jurić's talks:

GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić

https://www.youtube.com/watch?v=JvBT4XBdoUE

https://elixirforum.com/uploads/default/original/2X/a/a2524c... (also from Saša Jurić's book)

Thats it! Thank you!

Thanks.

You can watch this small twitter demo: https://www.youtube.com/watch?v=MZvmYaFkNJI. It's what sold me on the technology.

Thank you.

I want to use this, but every time I try to switch it is not there yet.

Sure it has the core stuff, but things like ActionMailer and the built in S3 support in ActiveStorage, Devise, keep me going back. Too many of those things are not there... yet ... with Phoenix

Also nothing beats active record after they added Arel which turns your query into an AST and optimizes it before sending it out - Ecto is not really there yet and doesn't look like it will get there

I think most packages are just as good if not better than their Ruby equivalents these days (and really we can do all of the things you mentioned in elixir), the active record pattern is obviously easier to understand than Ecto, but if you know how to write well optimised SQL you never want to go back to an ORM (even if it tries to rewrite your queries for you with magic).

ActiveRecord and the scenic gem for database views is a very powerful combination. For the vast majority of queries, you don't need to write optimized SQL by hand.

When you do, you can push that work to a version controlled database view, and wrap it in a ActiveRecord class interface and still get all of the ORM niceties.

The difference here is between two different philosophies:

1) I want the thing to just work, it doesn't matter about underlying complexity, give me the magic and the version controlled database view and the ORM niceties.

2) I don't trust magic as it has bitten me in the arse before, let me make and be able to fix things myself as I'm working at a (slightly) lower level.

I'm not saying either is correct but in Phoenix/Elixir magic stuff tends to be kept to a minimum. One man's "for the vast majority of queries" is another persons "will work fine until you need to do something complex".

It's all trade offs and I choose mine carefully as I'm sure you do.

This is interesting - I'm evaluating what to use for the backend of a side project right now after having focussed more on front-end/apps for the last few years, so I'm catching up on the latest progress in this area. Interesting to see that Rails is still often considered the best option, seems like they must be doing something right.

Ideally in my mind, I'd like to use JS (well, TS), because it's the language I work in most of the time these days... but I can pick up different languages as needed, that's not a major issue and I've done some Ruby way back when - more important to me is making the development of the backend as simple and as quick as possible (the less code the better!), and that it will run reliably. A good selection of well-tested off-the-shelf modules to integrate other services is always a good thing. It seems like Rails is well ahead of any JS-based solution in these regards, from what I can see.

I had been evaluating PostGraphile, which appeals because of the "low-code" approach, but I guess I'm a little concerned about doing most of the logic in database functions, because I've worked on a system like that years ago and found things like testing and debugging pretty painful. If anyone has evaulated PostGraphile (or Hasura etc) vs. Rails, I'd love to hear your thoughts (or equally, any other solutions to check out!).

Replace Rails with any framework and you'll have the same amount of success. I've done the exact same thing across Ruby, PHP, Golang and tons of other frameworks/languages and never had problems if following those steps.

Problems usually come from when teams start with point 3 and 2 when in reality they should stay lean in the beginning.

This argument has been made for years and I’ve yet to see it really be true.

You can make anything with anything, but Rails is the closest thing to an Aspect Oriented Programming environment that I’ve seen in the wild. It’s not easy to replicate that type of ecosystem with any other framework. I’ve spent ample time on teams using Go, Python, PHP, Java and C#.

There’s just no comparison vs what a small Ruby team can accomplish.

I really agree with this statement. I've never seen anything like Rails in Java/JavaScript land. In Java there's SpringBoot but its nowhere near a cohesive package with a strong online community behind it like Rails. It's more of a collection of libs put together with a good enough attitude.

I have seen multiple PHP projects at multiple companies go totally pear-shaped. I refuse to work at companies that use PHP anymore.

Same experience. I've seen nice PHP projects on the internet, but not yet in RL. I know its possible, i guess its just that the language does not reward you for corecctness.

PHP used to actually have a performance penalty for splitting things up into modules and using object oriented design, because it meant loading and parsing more files on each request.

I was trying to do that on my first big PHP project, and got called out. The architect said "your code is too good, PHP is for writing crap". If you are going to write good code, you should do it in another language.

Symfony framework is a great example of a PHP framework written by Java programmers. All the same verbosity as Java, but without the benefits of Java.

Ok? I've seen projects go pear-shaped in probably 20 different programming languages at this point, and I guess after a certain point of experience, you start to realize that failures seldom have to do with the programming languages themselves, and more about the people actually writing and managing the code (and everything else around development).

When the 3 biggest disaster projects I've ever had to touch were all in PHP, I choose to believe that is a trend.

Yes, you can write bad code in any language.

PHP makes it hard NOT to. The footguns are all sitting out in the open, loaded, and the safeties are off.

Well, if you're not interested in factual discussions and you simply "choose to believe trends", all bets are off since you're pulling in your feelings about a programming language into your arguments. Hope all goes well for you anyway!

As a counter-point, the biggest disasters I've seen has been involving either C++ or C#, but in the end I think the reason they were disasters were because of the programmers (and their ego) rather than the programming languages they worked with. C++ is plenty open and without safeties, but that doesn't mean you have to use it like that.

Constant factors vary framework to framework. I can't say I've ever seen anyone move as fast on Symfony as on Rails.

Symfony might be the odd one of the bunch.

Jokes aside, Laravel is probably a more likely contender to provide a Rails experience for PHP.

And it's easy to get clouded by anecdotal data, I'm sure I'm biased as well. But after some time in the industry, it matters more who the person is that is using the framework, than the framework itself. If you put an equally skilled developer with the same amount of experience in either Symfony or Rails, I'm sure they can be as productive as the other. But then skilled developers tend to gravitate towards Rails more than Symfony, so hard to judge in the real world.

What Rails-equivalent framework does Golang have?

I myself usually opt for the "small set of composable libraries" way of development nowadays, but I've worked with teams using Buffalo and Beego which kind of provides a "batteries included" approach that Rails follows too.

I found Revel to be quite similar.

I would say it is as productive as rails too.

There is no ActiveRecord and way way less magic which slows (initial) development speed but it pays off in less bugs to fix.

So overall development speed is roughly the same. But with Go you gain co routines and nice performance which can make life a lot easier.

Gos type system, while somewhat poor, still helps too.

The worst part of the whole thing is actually the weird Go std lib templating.

Same question but for Node.

NodeJS has even more "batteries included" frameworks than Golang. Sails, Hapi, NestJS and Adonis are probably the most popular right now, at least from my viewpoint (traditional SaaS web development)

I don't know, I just keep using Java and .NET, alongside their top of the line JIT/AOT compilers and GC implementations.

I've thought about learning Ruby (and Rails), being a Python guy myself. Not sure if it is worth the effort.

Give it a try. The languages are actually very similar, on roughly the same level of "high-low-level-ness", they both come batteries included, both are very mature and refined.

Some things you may find nice are: the elegance and ease of use of blocks instead of explicitly declared lambdas, the standard library full of nicely named methods with aliases for the most used ones (e.g. array.map / array.collect do the same thing, some people hate this), the {do,if,case,loop}-end syntax that doesn't fuck your code up when you just quickly comment these parts out without reindenting the rest, and if you're into OOP (as in OOP, not explosion-in-the-factory-factory), then of course the hardcore OOP-ness.

Depends on your use-cases - Rails is unparalleled in my opinion for getting a web app up and running, testing startup ideas, and building quickly in response to customer feedback.

I've been using Python recently as I've done more ML work, and I do prefer Ruby (though the syntaxes are similar and you won't have any difficulty).

If you learn for Rails, start with 5.2.3, webpacker and the other black magic in Rails 6 will frustrate you and currently eliminates a lot of the ease of getting started and building relatively sophisticated web apps quickly.

"If you learn for Rails, start with 5.2.3, webpacker and the other black magic in Rails 6 will frustrate you and currently eliminates a lot of the ease of getting started and building relatively sophisticated web apps quickly."

Anyone else agree with this?

Nope.

Webpacker is here to stay and takes about 5 minutes to understand. Might as well take advantage of it so you can quickly add complex front end components via React or whatever flavor of FE you prefer.

I agree, webpacker makes learning Rails harder. It's a shame. But learning on a non current version is a short term solution. A good tutorial, like Michael Hartl's, will get you over that hump.

I'm learning rails 6 right now for a work project, and webpacker is just broken so I can't even get hello world to work.

I'd go with something that has static/strong types when picking a new tool. Not saying I dont love Ruby, but when the codebase/team becomes large i've always regretted not having strong type safety. Today I'd go with Kotlin.

Try rails you won't look back

I tried (am trying at current company) and still don't like it. I completely see the appeal for getting an idea up and running quickly, it absolutely delivers on that.

However, I joined a rails company about a year ago and the codebase is just a mess at this scale. I find it annoying that in order to know where dependencies are coming from, I can't just go to the top of the file and see what's imported. I have to know how rails injects it and then track it down from there.

Don't get me wrong, there are issues with django, Go, etc.. but for the most part I can jump in and track down what's happening much easier.

Now, Ruby itself isn't bad at all.

Yeah, that's gotta be one of my biggest complaints after years of working with Rails. Eventually you sort-of memorize the conventions and can relatively accurately guess where a file lives, until someone decides to get clever and put things in a weird place.

It also implicitly discourages you from asking yourself if you should be accessing the thing you are. IMO a lot of the tight coupling in Rails codebases begins with being able to grab literally anything and use it with no one the wiser unless the read that specific line of code.

I love Ruby. Have used it for 15 years, but I can't stand Rails. It's just massive overkill for most things.

I prefer to start with Sinatra + Sequel for web projects. Sometimes Padrino + Sequel. As your project grows, sure, you'll pull in many things similar to Rails, and probably pull in some projects that started out with Rails too, but it allows you to be much explicit about which dependencies you pull in, why, and to limited where it gets pulled in.

I have not tried Sinatra, only heard good things about it I will check it out. Thanks!

Sinatra is great - it's small enough to read the whole thing and understand it. But it's also very minimalist, so you might also want to look at Padrino, which layers neatly on top of Sinatra, yet is still small and ORM agnostic.

It's also fairly painless to start with Sinatra, and layer in components from Padrino if/when you need them. E.g. you can simply register Padrino's helpers, mailer, routing, rendering or cache components in a Sinatra app if/when you need them. They're just straightforward Sinatra plugins.

The single most important part of rails is the orm. That, honestly, seems to be the "thing" that people are actually getting excited about when they gush over rails. A close second would be rspec. Finally, in production, it can be very helpful to be able to inspect the state of the db using the rails console (as long as the developer is wise enough to sandbox their actions).

I find the tooling (I use vim with solargraph) to be not only underwhelming but frustrating. No I am not willing to use a different editor. Rails code is not at all discoverable because I cannot follow method calls/objects half of the time. In order to alleviate this, I suppose, rails tries very hard to standardize things. Ok. Fine.

The ease of creating model relationships can also produce a nasty set of relationships between tables if you are not careful. One project I worked on used the fast_jsonapi where one table had relationships spanning most of the system. Dealing with that was borderline ridiculous.