Can somebody explain to me what is so great about this package? It just seems to be making API calls. I am not critical, I am just genuinely curious since I don't understand the landscape.
RubyLLM: A delightful Ruby way to work with AI
161–170 of 182 posts
Re: RubyLLM: A delightful Ruby way to work with AI
#162Earlier quoted context omitted.
“Almost” is key there. I respect your position, but it’s an always/never take, and the longer I am in this industry, the more I find myself leaning into “it depends.” Here’s a take that articulates this being done well on a large codebase better than I can in a short comment: https://dev.37signals.com/globals-callbacks-and-other-sacril...
> it’s an always/never take No, it isn't—I'm the one who inserted the word "almost" into that sentence! Where did you get the idea that I meant always/never? Like I said, you can point to exceptions but that doesn't change the rule. It's better to teach the rule and break it when you really know what you're doing—when you understand that you're breaking a rule and can articulate why you need to and why it's okay this…
Respectfully, your response further qualifies what I meant by your take being an always/never. I’m aware you’re the one who put “almost” in there, and I didn’t meant to imply you were being stubborn with that take, that’s why I said (and genuinely meant) that I respect it.
But I’m also aware that you’re comparing using global state to amputating a human limb. I don’t think it’s nearly that extreme. I certainly wouldn’t say global state “almost always leads to bad architecture,” as evidenced by my aligning with a framework which has a whole construct for globals baked into it (Rails’ Current singleton) that I happen to enjoy using.
Sure, global state is a sharp knife, which I already said. It can inflict pain, but it’s also a very useful tool in certain scenarios (more than would equate to “almost [never]” IMO).
So your response aligns with how I took your original post, and what I inferred “almost” really meant: basically never. My point is that I don’t agree with your take being a “rule.” While I understand your perspective, instead of saying basically never, I would say, “it depends.”
Re: RubyLLM: A delightful Ruby way to work with AI
#163Earlier quoted context omitted.
What do you mean by 'assignment or creating a new object'? It assigns chat to ... whatever RubyLLM.chat returns. Do you mean the function could have a clearer name?
It's unclear whether `chat` is a field/property/member of `RubyLLM` or a method being called.
Perhaps to you, but anyone that’s ever worked with Ruby knows that there’s no such thing as fields/properties/members in Ruby. There are only methods. Parentheses are optional for method calls.
Re: RubyLLM: A delightful Ruby way to work with AI
#164The 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...
Unfortunately, 5 years after the release you linked, almost none of this has made it to Rails or even to relatively new libraries this post is about. The reason (imho) are unfortunate design choices in how the language incorporates concurrency - it’s just not well done.
Re: RubyLLM: A delightful Ruby way to work with AI
#165The 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.
Well instead of looking at the two first hits of Google I spent several years on a platform team of a multi billion dollar company using mostly Rails and worked on solving real world problems caused by Ruby/Rails’ design choices which lead me to believe that Ruby concurrency as of today is hot garbage.
They need fundamental breaking changes to the language to fix this, which means people won’t be able to use their beloved pile of 438 gems that haven’t seen a commit in 7 years. If I had to bet, I’d say the language is dead. It might still be a nice niche language for easy prototyping, but the world has moved on to async/await (js/python/Rust/C++) or stackful coroutines (Go).
Re: RubyLLM: A delightful Ruby way to work with AI
#166Earlier quoted context omitted.
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?
Rails is a hot ball of global mutable state. Good luck with threads.
Re: RubyLLM: A delightful Ruby way to work with AI
#167Wow the syntax is beautiful!
You're confusing beautiful with simple. There's a lot of complexity and magic that's hidden behind the curtains of that "beautiful" syntax. Great for scripts and small programs, and an absolute nightmare on large projects. It's too simple.
As a general rule of thumb, don’t yuck someone else’s yum. Plenty of people like the trade offs Ruby makes. And plenty of absolutely huge businesses use it quite successfully (e.g., Shopify, GitHub, GitLab, Airbnb, Stripe).
If you don’t like it, don’t use it.
Re: RubyLLM: A delightful Ruby way to work with AI
#168>delightful
>ruby
Pick one
Re: RubyLLM: A delightful Ruby way to work with AI
#169Re: RubyLLM: A delightful Ruby way to work with AI
#170Earlier quoted context omitted.
You're confusing beautiful with simple. There's a lot of complexity and magic that's hidden behind the curtains of that "beautiful" syntax. Great for scripts and small programs, and an absolute nightmare on large projects. It's too simple.
As a general rule of thumb, don’t yuck someone else’s yum. Plenty of people like the trade offs Ruby makes. And plenty of absolutely huge businesses use it quite successfully (e.g., Shopify, GitHub, GitLab, Airbnb, Stripe). If you don’t like it, don’t use it.
I'll yuck whatever yum I please. I'm not here for your approval. I did 10 years of Ruby. I have some authority on the matter.