News for hackers. Stuff that matters.
Re:Elixir for Ruby developers: the three most important diff... by pmontra on Sunday July 23, 2023 @03:15PM (#36838663)
I worked on a Phoenix project for a few years. We had to write our own libraries to access some services from Google and Stripe which have libraries for other languages but it was not difficult. We have to implement only the few HTTP calls we need and we can choose the functions that suit our application instead of learning somebody's else tool.
Re:Elixir for Ruby developers: the three most important diff... by arrowsmith on Sunday July 23, 2023 @03:40PM (#36838956)
GPT-4 is excellent at this - give it code from an existing SDK in Ruby (or whatever) and tell it to rewrite the functions you need in Elixir and it'll get you at least 90% of the way there.

The other day I used this to create an Elixir wrapper around, appropriately enough, the OpenAI API.

Re:Elixir for Ruby developers: the three most important diff... by cpursley on Sunday July 23, 2023 @05:29PM (#36840036)
It's also great at "here are the so and so docs, write an adapter for Elixir"
Re:Elixir for Ruby developers: the three most important diff... by sbuttgereit on Sunday July 23, 2023 @06:00PM (#36840313)
I am writing a lot of the code that might be found in libraries for my project; I'm doing it mostly because: third party, open source libraries really need to be treated as hostile code until they're vetted... and then will continue to need vetting with every update. For a fair number of uses cases, writing the library is less than or as labor intensive as a good audit and writing them in Elixir tends to be pretty simple. For the larger more complex and essential libraries, there are solid, fairly well endorsed packages out there (they still need vetting though).

Of course, there's the option of taking an appropriately licensed open source license and making an internal fork... not expecting to really receive updates from upstream after the point of departure.