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

RubyLLM: A Ruby framework for all major AI providers

rubyllm.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: RubyLLM: A Ruby framework for all major AI providers

#81

Post by qup »

timr wrote: post #77
earcar wrote: post #76

Earlier quoted context omitted.

Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago. > Also, the same PR was reverted a bit later, IIRC No. Your #151 was merged. The regressions it introduced were patched the next day in #157/#159. Cheers!

> Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago. Erm, OK. I don't think that's even close to what I did, but I guess people can read for themselves. Again, this was not the only interaction I had with you folks, and even if you accepted my patch instantly and didn't roll it back or anything else at all (Also, once again: completely fine ; I understand why you d…

You called them out for being slow; turns out they weren't. You called them out for un-merging your work; turns out they didn't.

Now you keep saying you had other bad interactions, but you haven't even said what they were. I have a feeling that if you named them, shortly later I'd read a comment about how it wasn't true. Again.

If the library didn't match your needs, that's fine. Who cares? That's happened to all of us many times, right?

Re: RubyLLM: A Ruby framework for all major AI providers

#82

Post by hartator »

strzibny wrote: post #70

Congrats Carmine on being featured! I am using RubyLLM for quite some time and I am in love with the API design. If someone wants to see how this looks in a real project including custom tools, you can have a look at the SerpTrail project on GitHub. The Chat model still is just: class Chat More: https://github.com/serpapi/serptrail I am quite excited for RubyLLM 2.0 and beyond.

‘acts_as_chat’ feels super cute indeed.

Re: RubyLLM: A Ruby framework for all major AI providers

#83

Post by spider-mario »

nougati wrote: post #79
earcar wrote: post #73

Earlier quoted context omitted.

Your PR #151 was opened May 4, 2025 and merged 2 days later. The repeated `chat.to_llm` message bug was reported Apr 30 2025, and fixed May 6, 2025, about 27 minutes after your comment. It only showed up when reusing the same Rails chat object for multiple turns in the same Ruby object lifetime, e.g. `chat.ask("first"); chat.ask("second")` inside one controller action or one background job. The usual flow is one turn…

The decision to audit (frankly, aggressively) this guy out the gate with this comment on a discussion thread is not a good look. It's a very unnecessary way to tarnish the reputation of the devs by picking fights with someone sharing their experience. If you can't see how you did that, perhaps you should ask an LLM to help.

Why should the parent comment be immune from factual challenges? Reports of personal experience are not sacred.

Re: RubyLLM: A Ruby framework for all major AI providers

#84

Post by miki123211 »

As a non-rubyist who nevertheless understands Ruby, and has a keen interest in cross-provider LLM frameworks / abstractions, chat.rb is the most beautiful implementation of the agentic tool-calling loop I've ever seen.

People point at pi-agent (Typescript) as a good one, but I find the Ruby version far more elegant, far more concise, and generally easier to read.

I think it could be simplified further at the cost of making the API a bit uglier — and perhaps an educational fork should be — but it's still really good.

Re: RubyLLM: A Ruby framework for all major AI providers

#85

Post by timr »

qup wrote: post #81
timr wrote: post #77

Earlier quoted context omitted.

> Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago. Erm, OK. I don't think that's even close to what I did, but I guess people can read for themselves. Again, this was not the only interaction I had with you folks, and even if you accepted my patch instantly and didn't roll it back or anything else at all (Also, once again: completely fine ; I understand why you d…

You called them out for being slow; turns out they weren't. You called them out for un-merging your work; turns out they didn't. Now you keep saying you had other bad interactions, but you haven't even said what they were. I have a feeling that if you named them, shortly later I'd read a comment about how it wasn't true. Again. If the library didn't match your needs, that's fine. Who cares? That's happened to all of…

> You called them out for being slow; turns out they weren't. You called them out for un-merging your work; turns out they didn't.

I said they were slower than me. I didn't "call anyone out" for un-merging my PR -- I explicitly did the opposite. I could care less.

More than anything, I said I recalled that the reception was chilly. This thread has reminded me of why I had that opinion.

> If the library didn't match your needs, that's fine. Who cares? That's happened to all of us many times, right?

Sure. And we're allowed to talk about it.

Re: RubyLLM: A Ruby framework for all major AI providers

#86

Post by nougati »

spider-mario wrote: post #83
nougati wrote: post #79

Earlier quoted context omitted.

The decision to audit (frankly, aggressively) this guy out the gate with this comment on a discussion thread is not a good look. It's a very unnecessary way to tarnish the reputation of the devs by picking fights with someone sharing their experience. If you can't see how you did that, perhaps you should ask an LLM to help.

Why should the parent comment be immune from factual challenges? Reports of personal experience are not sacred.

Learn to pick your fights? People can check the history of the git issues if they want to see. The dev clearly had a bone to pick

Re: RubyLLM: A Ruby framework for all major AI providers

#87

Post by nougati »

qup wrote: post #80
nougati wrote: post #79

Earlier quoted context omitted.

The decision to audit (frankly, aggressively) this guy out the gate with this comment on a discussion thread is not a good look. It's a very unnecessary way to tarnish the reputation of the devs by picking fights with someone sharing their experience. If you can't see how you did that, perhaps you should ask an LLM to help.

I think it's really neutral in tone and I appreciate the record being corrected. 2 days is a great turnaround time for PRs isn't it?

With how the record is so correct now, can you clarify for me who was right?

It's the wrong question; the first person was sharing their experience, and the reply jumped to collecting evidence that only vindicated the characterisation of a 'chilly response'. It's a human social skills thing. This place is not github issues. People who actually care will see. People who 'clarify' it here were never maintainers

Re: RubyLLM: A Ruby framework for all major AI providers

#88

Post by mosselman »

jaredsohn wrote: post #66
katzgrau wrote: post #64

Earlier quoted context omitted.

The issue is that it’s relatively low effort to make false and unverified claims. Defending and refuting it is a much higher effort task for the person doing the work to everyone else’s benefit. RubyLLM dev literally had to take time to provide code samples and doc links. No issue with listing legit limitations, but be a bro and fact check claims before wasting a volunteer’s time - and potentially leading other devel…

I completely agree that unverified claims create a heavy burden for maintainers. My only point was about the language used: 'disparaging' to me implies a bad-faith attack or a dismissive attitude, whereas this was just an honest technical mix-up that the poster immediately corrected. I think part of the confusion with that word comes from things like corporate non-disparagement clauses. In those contracts, lawyers wr…

Thanks for the discourse. I never meant it to be disparagement nor do I think it really was.

I checked and it turns out I remembered correctly that setting effort and some of its settings are not portable between providers.

There are some different settings that each provider uses and in order for it to be portable, you have to force some defaults on provider A when using a setting that is almost only supported in provider B.

In our implementation we decided to drop a certain setting when using OpenAI in one case and we decided we can just force some other setting when using Anthropic. But this 'solution', might not be what others expect.

When you build an open-source library you can go this opinionated route and force these settings, or you might go the config route and force people to explicitly handle per-provider differences. I will have a look at what I am able to do in terms of a contribution and then in the PR Carmine can decide what they like.

Re: RubyLLM: A Ruby framework for all major AI providers

#89

Post by mosselman »

mosselman wrote: post #17
earcar wrote: post #4

Earlier quoted context omitted.

RubyLLM author here. I'm not sure where you got that. `chat.with_temperature(0.2)` https://rubyllm.com/chat/#controlling-response-behavior `chat.with_thinking(effort: :high, budget: 8000)` https://rubyllm.com/thinking/#controlling-extended-thinking Max tokens is the only one of your list that require provider specific params: https://rubyllm.com/chat/#provider-specific-parameters I'm one guy doing it for free. Happy…

Hi! Valid challenge, I am probably misremembering. We were playing with various 'one-interface to all providers' solutions and I might have mixed up RubyLLM there. Sorry for that. I will have a deep dive into which things I felt we needed to adapt per provider. I didn't mean to imply that you have to solve all of our wants of course. One thing we did do was monkey-patch the spot where tool_calls are performed by Ruby…

Update since the side thread blew up.

There is some difference in how OpenAI and Anthropic handle 'max_tokens'. The OpenAI way raises errors in Anthropic for example.

I will look at confirming this a bit more in depth once we've taken our RubyLLM based adapter in production and see if I can make some contribution.

Thanks for all the work! It is incredibly impressive and I never meant any disrespect.

Re: RubyLLM: A Ruby framework for all major AI providers

#90

Post by shevy-java »

lackoftactics wrote: post #44
MitziMoto wrote: post #35

Earlier quoted context omitted.

You static typed evangelists have lost your damn minds. You seem to have completely misunderstood what this library even is because you have some primal urge to boast static typing at every chance. You can build high quality software with dynamically typed languages, and Ruby is an absolute dream to read and write.

Why do you think that follows? I was on team dynamic typing for about 12 years, and Ruby was a big part of that. I still think dynamic languages can be wonderful to read and write. But after using modern statically typed languages with good inference, I changed my mind. Many of my old objections were really objections to verbose type systems, not static typing itself. With inference, you can keep a lot of the readabi…

Because it is simply incorrect. I have been using ruby since 2005 or so. Static types were never relevant or needed in the slightest here. The various claims by the type afficionados camps could easily be disproven and rejected, but that never stopped them from trying to ruin other languages.

> But I don’t think appreciating modern static typing is just evangelism.

But it is evangelism, because the type-addicted devs want to slap on types on ruby. That is evangelism. They try to change an existing language to their world view and narrative. And you can not talk to them because their brain is deadlocked here. This is why the person you replied to, is correct here.

Post reply on HN