Valid points, Python will offer you a lot more choice with regards to libaries and plugins for Flask/Django, no question. It’s used by a lot more companies, and is a much more popular language, which inevitably leads to more choice when it comes to libraries etc. But choice can be a double edged sword, when you need to lookup, for example, which testing library is best to use out of the many available, or which authentication library best suits your need. Of course, official libraries for integrations do make the choice more obvious.
As Sasa Juric mentions in his book about some of the drawbacks of Elixir:
The ecosystem built around Erlang isn’t small, but it definitely isn’t as big as that of
some other languages. At the time of writing, a quick search on GitHub reveals about
20,000 Erlang-based repositories and about 36,000 Elixir repositories. In contrast,
there are almost 1,500,000 Ruby repositories and more than 5,000,000 for JavaScript.
You should be aware that the choice of libraries won’t be as abundant as you may
be used to, and in turn you may end up spending extra time on something that would
take minutes in other languages. If that happens, keep in mind all the benefits you
get from Erlang.
Yep but it hasn’t been touched since 2014 and most API resource implementations are an unfinished TODO and is wildly out of date vs Stripe’s current API. That library isn’t the official Stripe library from the Stripe team. Stripe officially has clients for Python, Ruby, PHP, Go, Java, Node and .NET but not Elixir.
There’s too many things that you need to implement yourself when it comes to implementing Stripe with Elixir. At least it was for me. I didn’t want to spend a ton of time developing a Stripe library. I wanted to build my app.
There’s other Stripe Elixir libs out there but they are all in the same type of state where they are very out dated (using multiple year old Stripe API versions) and are missing lots of common Stripe functionality.
Even doing something as basic as verifying webhook responses requires writing a lot of complex code, which was documented by Dashbit a few months ago How we verify webhooks - Dashbit Blog. That is the type of stuff I don’t want to have to be coding.
The app I was building in Phoenix needed to support Stripe, Paypal and I also wanted to bring in Paddle support too as a backup plan. It got to the point where I didn’t want to dedicate months of hardcore library writing. It was easier (for me at least) to use the existing official Python libraries and rewrite my app in Python.
Payments weren’t the only struggle I had too.
Numbers are good but it’s about which libraries exist too. Like with Rails the payment situation is so polished that you can integrate with Stripe, PayPal, BrainTree and Paddle in a day if you’re an experienced Rails developer. There’s even gems like GitHub - pay-rails/pay: Payments for Ruby on Rails apps which is an abstraction over multiple providers.
Likewise, there’s very polished gems around notification delivery systems (websocket in app notifications for connected users, email, text, slack, etc.). These types of things don’t exist in Elixir and could easily take over a month’s time of dedicated development to get a production ready implementation going.
These are pretty common things in a lot of SAAS apps. Of course your mileage may vary and it’s super dependent on what you’re building but I haven’t found it to be faster to develop apps in Phoenix due to more Elixir libraries existing vs writing the same app in Rails. There’s also loads of things in Rails that come baked into the framework that don’t need a gem but with Phoenix it requires you to write that code yourself.
retrieving customers (all or paginated), events, and invoice items
Also did you try contacting the Stripe team and ask if they had any plans for an Elixir or Erlang official library? Perhaps be offering to help maybe? They don’t have an official Rust library either, and I’m guessing they have one for Go because they use Go themselves.
Another thing you could have done is post a thread to ask if anyone was interested in helping you update the Elixir or Erlang package? That would have been neat
FWIW I generally prefer to implement my own integration with a vendor’s API using the quest pattern (GitHub - gvaughn/quest: Pattern for building API clients in Elixir). Sometimes even a vendor’s own official library can get bugs and it is nice to be able to debug raw API calls instead of digging through someone else’s code when things go wrong. As such, I don’t consider Python “vendor” libs to be an a feature (for me).
I find these observations valuable because its easy, in any ecosystem, to defend the current situation rather than be open to areas where there are gaps or deficiencies or just alternative points of view.
Payments gets mentioned regularly. While I don’t have the relevant experience to judge, if enough people comment that the payments libraries aren’t up-to-scratch then they need improving. Whether its code, documentation, tutorials or marketing.
I for one would be interested in the community view of what are considered fundamental/standard gaps in the Elixir library ecosystem that are considered settled matters in other language communities. Because these are also opportunities for people that like to build things.
It’s another one that’s really out of date based on what Stripe currently offers in their API. This also isn’t a case of claiming it’s out of date because it hasn’t had a commit in 4 years because it doesn’t need it. That library will not function using any semi-recent API version of Stripe.
Yep, a couple of times. Once about 3 years ago and again about a year ago. In both cases they told me that the demand isn’t there with Elixir. They add official clients based on programming language usage popularity not what’s used internally at the company.
I guess it’s a big undertaking because there’s thousands of lines of code that need to be written, maintained and then have very high test coverage. It’s also the company’s official offering so it needs a level of polish that’s above and beyond most projects.
That’s why it’s so handy to have official support for payment gateways. You just know when you use it you’re getting an extremely well tested library that thousands or even tens of thousands of projects are using successfully.
In a perfect world with no time constraints on life expectancy maybe, but doing the above would have meant stopping all development on my app and becoming a full time library developer and then after Stripe, repeat the process for paypal and paddle. For someone like me (not a core Elixir developer) this would have been honestly 3-6 months of full time work and then continuous maintenance afterwards.
I contribute a lot to open source but at some point you need to know when to pick your battles. Attempting to create multiple payment gateway libraries was out of scope of anything I could pull off, even with help.
Plus I’ve seen other libraries like the most popular Elixir AWS package stop being maintained and then post an open request for someone to take over the project. It took around 4 months to get 1 response, which is great that someone decided to take it over but that is a long time to wait for help.
I also haven’t seen too many payment related questions on the forums so it kind of left the impression that not too many people are creating apps that use payments in elixir. Maybe there’s some super high traffic sites processing millions of dollars of payments in some “success stories”, but they haven’t open sourced their work or spoken about how they do it.
This has the same issue as the others. It’s outdated. It’s coded against an API version of Stripe from 2019. There’s been a few major API updates since then. It’s also missing entire resource end points (major features of Stripe).
Yeah but you also run the risk of getting labeled as someone who is anti-Elixir and get ostracized by the community as you get labeled as “that one person who only posts negative things”.
I can’t even post on Reddit anymore. I mentioned a shortcoming in the docs around multi-tenancy a while back and got like 40 downvotes in 5 hours. I don’t care about karma points or anything, but it’s not exactly a motivating factor to continue investing time in a community like that.
It wouldn’t hurt to start a thread on that IMO. I’d be curious to see what others say too and definitely have a laundry list of things that I wish existed because they are solved problems with a number of other tech stacks.
I know there is value to keeping things simple in terms of minimizing the number of different technologies in the stack, but is it necessary to have payments handled in Elixir code? If there are better tools for the job in other languages, maybe use those tools for the payment process even if Elixir provides a better framework for other aspects of the app. For instance using the Python libraries via :erlport and :python might be a solution similar to the tutorials:
Nick, after reading about your experiences here and in HN, I started to be sympathetic to the arguments, and because I’m feeling so happy when I’m working with Elixir I’m just figuring out how to contribute, copying what makes Rails and Django so good regarding application’s development.
Ash framework is heading on this direction, but we also need other things, as the Phoenix equivalents of ActiveMail, ActiveStorage and even ActiveJobs.
Payments is also essential, at least a well maintained suite of SDKs to the biggest players
Hey, that’s really nice to hear. I’m looking forward to reviewing and contributing back to some of those things if I can. I know in a lot of cases it’s not fair to compare Phoenix to Rails / Django because they’re not necessarily trying to solve the same problems. Also there’s 15 years of history in those projects.
In some of the recent HN comments maybe I was too critical of Phoenix and LV. It’s easy to write a brutally honest unfiltered response about something when you like the thing so much but run into a few roadblocks that prevent you from being able to use it for the apps you’re trying to build.
Someone recommended that we all reach out to Stripe’s support to ask for an Elixir client because client libraries are added based on popularity, maybe that idea would work and then it could also be sent to Braintree and Paddle too.
I’m up for writing an initial email template and figuring out the contact addresses for these companies. Might be worth starting a new thread for this specifically? Then once we all agree it’s worded well, we’ll send it out.
And surprisingly Braintree uses Elixir itself internally in some projects.
I think that we can start a thread to ask and monitor the support of the payments SDKs, it’ll be very useful.
EDIT: What about write an application, sort of Are Elixir Payment’s SDKs Ready Yet, so that we can track the status and ask the vendors for official support?
