Live data from Hacker News

RubyLLM: A delightful Ruby way to work with AI

github.com

141–150 of 182 posts

Re: RubyLLM: A delightful Ruby way to work with AI

#141
post #42
post #5

Earlier quoted context omitted.

Matz said he designed Ruby to optimize for developer happiness, it’s just a core principle of the language since it was created

Happiness of a developer writing code can be a misery of a one having to read / debug it. I worked in ruby for a couple years around 2009 and having to deal with a code that implemented most of its logic via method missing is still one of the strongest negative memories I have about coding.

Yep yep, that's the whole "sharp knives" thing.

What I advise (and aim for) is only pulling out the sharp knives for "library" code, but application code should stay "simple" (and this much more easily navigable). Otherwise you can absolutely make a bloody mess!

Re: RubyLLM: A delightful Ruby way to work with AI

#142
post #132

The API looks nice on the surface, but this will be expensive to operate due to Ruby and Rails’ lack of support for concurrency. Everything is blocking, which is not a great match for the async nature of interacting with these models.

Ruby isn't dead and like all alive things, it grows and changes; your expectation is out of date.

https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-rele...

Re: RubyLLM: A delightful Ruby way to work with AI

#143
post #125

Earlier quoted context omitted.

From https://rubyllm.com/#have-great-conversations # Stream responses in real-time chat.ask "Tell me a story about a Ruby programmer" do |chunk| print chunk.content end

This will synchronously block until ‘chat.ask’ returns though. Be prepared to be paying for the memory of your whole app tens/low hundreds of MB of memory being held alive doing nothing (other than handling new chunks) until whatever streaming API this is using under the hood is finished streaming.

Threads?

Re: RubyLLM: A delightful Ruby way to work with AI

#145
Feels more useful for something like cli where you want to run one-off commands to test something instead of running it in production given how non-deterministic the behavior can be for example for something like

  chat.ask "What's being said?", with: { audio: "meeting.wav" }
definitely don't want users to get a valid response only 75% of the times, maybe?

Re: RubyLLM: A delightful Ruby way to work with AI

#148
post #132

The API looks nice on the surface, but this will be expensive to operate due to Ruby and Rails’ lack of support for concurrency. Everything is blocking, which is not a great match for the async nature of interacting with these models.

https://ruby-concurrency.github.io/concurrent-ruby/1.1.5/Con...

https://thoughtbot.com/blog/my-adventure-with-async-ruby

First two hits on Google.

Re: RubyLLM: A delightful Ruby way to work with AI

#149
post #74

Earlier quoted context omitted.

IIRC Github was originally written in Ruby as well. Now that they use something "far easier to work with", the UX gets to suffer accordingly. I've never been in a situation where making the customer happy was synonymous with applying best practices to the tech stack or otherwise making it so everyone and their dog can contribute.

Github is still rails, but they have layered in some react to the UIs, like the file explorer. It all seems pretty negative value to me though it’s terribly slow.

Yeah Codeberg is significantly faster than GitHub, presumably in part because it's Go and not Ruby.

Re: RubyLLM: A delightful Ruby way to work with AI

#150

Be careful with the examples though: https://github.com/crmne/ruby_llm/issues/25

Thanks for flagging this. The eval was only in the docs and meant only as an example, but we definitely don't want to promote dangerous patterns in the docs. I updated them.
Post reply on HN