Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir for Ruby developers: the three most important differences

phoenixonrails.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Elixir for Ruby developers: the three most important differences

#41

Post by arrowsmith »

enraged_camel wrote: post #38
manmal wrote: post #26

Earlier quoted context omitted.

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.

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.

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 differences

#42

Post by biql »

pavel_lishin wrote: post #23
ollysb wrote: post #7

Earlier quoted context omitted.

Elixir doesn't currently have a type system built into the compiler. There is a separate package Dialyzer which does type checking but it would be fair to characterise it as a bolt-on rather than part of the core tooling. Work is now underway[1] to create a type system based on "set-theoretic types" though this is still considered experimental and may never be added to Elixir. [1] https://elixir-lang.org/blog/2022/10…

My experience with Dialyzer wasn't great a few years ago. The error messages are often counter-intuitive, to the point where hating dialyzer became a meme at work.

Trying Gleam that also runs on Erlang VM but has static types, a fast compiler with Rust-style elaborate error messages made me hopeful about how much nicer this experience can be when static types are added to Elixir too.

Re: Elixir for Ruby developers: the three most important differences

#43

Post by cpursley »

arrowsmith wrote: post #36
pmontra wrote: post #33

Earlier quoted context omitted.

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.

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.

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 differences

#44

Post by ricketycricket »

davidw wrote: post #2

What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?

Just wrapped up a live translation feature that watches an HLS live stream, live transcribes with whisper and then translates into 18 languages. Heavy use of OTP: supervision trees for each stream, ports for managing ffmpeg and receiving audio, async tasks for concurrently submitting chunks to translation API, etc. Transcription and translations provided in real-time via LiveView to about 4,000 viewers.

Little over 3 weeks from `mix new` to the live event. Not sure how I could have done it so easily without OTP and LiveView.

Re: Elixir for Ruby developers: the three most important differences

#45

Post by manmal »

enraged_camel wrote: post #38
manmal wrote: post #26

Earlier quoted context omitted.

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.

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.

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 differences

#46

Post by davydog187 »

davidw wrote: post #2

What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?

I’m building a product in the media world. Elixir powers our webserver, that’s connected to NVIDIA Jetson devices, all using elixir for coordination and talking over UART to serial components. We also plan to do vision and ML workloads in the applications in the near future

Re: Elixir for Ruby developers: the three most important differences

#47

Post by sbuttgereit »

pmontra wrote: post #33
mrcwinn wrote: post #5

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.

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.

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 differences

#48

Post by pschuegr »

jph wrote: post #12
davidw wrote: post #2

What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?

We built a social network for social justice work, with posts, likes, shares, and the like. Elixir and Phoenix are a really good fit for the problem domain i.e. lots of concurrent users, high scalability via built-in balancing and queuing, the "let it crash" concept for lots of backend APIs such as image processors that sometimes fail. And LiveView is superb for fast interactivity.

Got a link?

Re: Elixir for Ruby developers: the three most important differences

#49

Post by dopidopHN »

el_nahual wrote: post #18
mrcwinn wrote: post #5

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.

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 genui…

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 differences

#50

Post by manicennui »

ljm wrote: post #28

I would give seasoned Ruby engineers a lot more credit than this article expects. A lot of its examples are just…functions? A lot of the things that are ‘elixir’ are what I learned when I was writing PHP and modding forums.

A lot of Rails developers don't actually know Ruby.
Post reply on HN