News for hackers. Stuff that matters.
Re:Elixir for Ruby developers: the three most important diff... by mrcwinn on Sunday July 23, 2023 @12:35PM (#36836947)
I love Elixir, Phoenix and LiveView. A drawback is the size of the community, and as a function of that, availability of libraries for various things. It is not bad. It is also not great. That said, the community itself deserves high marks for their willingness to help and do so in a friendly manner.
Re:Elixir for Ruby developers: the three most important diff... by el_nahual on Sunday July 23, 2023 @01:10PM (#36837357)
The community is small, but that means that a reasonable question on elixirforums (not a stateless discord/slack, pun intended) has a good chance of:

1. receiving an answer from a core contributor (valim, McCord, etc)

2. Having the answer become part of the documentation for the language or library

As an aside, the elixir community has a different didactic approach to many others: the documentation in elixir is genuinely instructive (vs a descriptive reference).

As an example, I've been able to download the elixir, Phoenix, and ecto docs and work on an app entirely offline, on an airplane ride, and never felt like I needed to Google anything.

A common elixir answer to "where are all the blog posts" is "read the docs. No, seriously."

Re:Elixir for Ruby developers: the three most important diff... by sodapopcan on Sunday July 23, 2023 @01:14PM (#36837402)
> A common elixir answer to "where are all the blog posts" is "read the docs. No, seriously."

This is indeed very common the forums, ha. Also common is for people to actually then go read the docs and be like, "Oh crazy, I'm not used to this!" Not to over-sell the quality of the docs, of course they aren't perfect but they really are particularly good.

Re:Elixir for Ruby developers: the three most important diff... by manmal on Sunday July 23, 2023 @02:06PM (#36837964)
As a convenient side effect, GPT-4 is actually quite good at coding in Elixir. I tasked it once to find a bug in an Ecto query and it even improved the query‘s structure. I‘d been worried that, as a small-ish language, Elixir would suffer from bad LLM support, but that’s not the case.
Re:Elixir for Ruby developers: the three most important diff... by enraged_camel on Sunday July 23, 2023 @04:12PM (#36839322)
My experience has been the total opposite. It can give simple answers but makes up total nonsense for anything non-trivial.

That said, with Ecto I just ask it to give me the SQL query. From there it’s pretty easy to manually write the Ecto equivalent.

Re:Elixir for Ruby developers: the three most important diff... by arrowsmith on Sunday July 23, 2023 @04:39PM (#36839584)
Are you using GPT-4 (the paid version) or GPT 3.5?

3.5 is as you describe. 4 isn't perfect but it's good enough, in my experience.

Re:Elixir for Ruby developers: the three most important diff... by manmal on Sunday July 23, 2023 @05:56PM (#36840273)
That was right after the release of GPT-4, when it was slow but good. Haven’t gotten around to much Elixir coding since, it could be that they crippled GPT-4 too much to be of use in the meantime.

Oh and the chat is better for me than the API. API sometimes gives me the complete opposite of what the chat (correctly) gives me.

Re:Elixir for Ruby developers: the three most important diff... by dopidopHN on Sunday July 23, 2023 @08:46PM (#36841653)
Thanks to pointing that out ( about the doc )

I will take your word for it and try.

Re:Elixir for Ruby developers: the three most important diff... by el_nahual on Sunday July 23, 2023 @10:11PM (#36842284)
Too late to edit this comment, but as evidence: at time of writing this, the top comment has a very thoughtful reply by...Jose Valim (creator of the language).
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.

Re:Elixir for Ruby developers: the three most important diff... by tagamma on Monday July 24, 2023 @02:06AM (#36843644)
It's indeed relatively small, but what it may lack in numbers, it makes up for in quality. It's one of the most dedicated, helpful, and friendly communities I've come across.

I've personally been surprised by a pro of having a more intimate community: in my experience, this leads to a higher signal-to-noise ratio in discussions and resources. It feels like what I need to get online is more "condensed".