Live data from Hacker News

RubyLLM: A Ruby framework for all major AI providers

rubyllm.com

71–80 of 91 posts

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

#71
post #62

We've used RubyLLM for ~6+ months and it's been mostly OK. The API/Dev UX is good but we have seen little success with engaging the maintainer on PRs, and have noticed a lot of vibe coded PRs being merged (including some rewrites of PRs we submitted) - I suspect an minimal API compatible gem with similar heuristics would do well.

I checked whether you or anyone from Wistia, your company, opened PRs.

I found one: #813, opened June 16, 2026. Last week.

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

#73
post #69
post #62

We've used RubyLLM for ~6+ months and it's been mostly OK. The API/Dev UX is good but we have seen little success with engaging the maintainer on PRs, and have noticed a lot of vibe coded PRs being merged (including some rewrites of PRs we submitted) - I suspect an minimal API compatible gem with similar heuristics would do well.

Similar experience. I tried using this library about a year ago, but the Rails integration was really rough at the time, and things like persisting the conversation to the database required essentially bespoke code. Also, tool use, schemas, etc. for Gemini required a lot of work, observability was limited, and IIRC, it did stuff like overwriting records in specific situations. I don't know if that is improved, but it…

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 per request/job, where the record is reloaded each time. Also, it did not overwrite records; it duplicated messages in the in-memory request context.

Gemini tool calling shipped in 1.0, schema support landed in 1.4, and observability landed in 1.16.

As for "the most trivial of applications": check the docs. RubyLLM goes well beyond that, and several multi-million-dollar companies use it in production every day.

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

#75
post #73
post #69

Earlier quoted context omitted.

Similar experience. I tried using this library about a year ago, but the Rails integration was really rough at the time, and things like persisting the conversation to the database required essentially bespoke code. Also, tool use, schemas, etc. for Gemini required a lot of work, observability was limited, and IIRC, it did stuff like overwriting records in specific situations. I don't know if that is improved, but it…

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…

I don't remember every interaction I had with you folks, but that wasn't the only one. Also, the same PR was reverted a bit later, IIRC -- I think I made a mistake in my PR or it wasn't compatible with some other use case, so that's fine, but the overall theme of the interactions (again, in my recollection) was that I was personally moving much faster than you, and using your library was hurting more than helping. So I stopped.

> 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.

That happens all the time. Without it, you can't pass things around to functions that add to the chat, for example.

> The usual flow is one turn per request/job, where the record is reloaded each time.

This may be your usual flow, but it doesn't have to be everybody's usual flow. No offense, but you're currently reminding me of what I interpreted as "chilly reactions" at the time.

> Gemini tool calling shipped in 1.0, schema support landed in 1.4, and observability landed in 1.16.

Great! I did them myself in less time. It's entirely possible that your library, today, is the tool I needed then.

> As for "the most trivial of applications": check the docs. RubyLLM goes well beyond that, and several multi-million-dollar companies use it in production every day.

OK. Cool. If they want to use the software, I'm sure nothing I say will convince them otherwise.

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

#76
post #75
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…

I don't remember every interaction I had with you folks, but that wasn't the only one. Also, the same PR was reverted a bit later, IIRC -- I think I made a mistake in my PR or it wasn't compatible with some other use case, so that's fine, but the overall theme of the interactions (again, in my recollection) was that I was personally moving much faster than you, and using your library was hurting more than helping. So…

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!

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

#77
post #76
post #75

Earlier quoted context omitted.

I don't remember every interaction I had with you folks, but that wasn't the only one. Also, the same PR was reverted a bit later, IIRC -- I think I made a mistake in my PR or it wasn't compatible with some other use case, so that's fine, but the overall theme of the interactions (again, in my recollection) was that I was personally moving much faster than you, and using your library was hurting more than helping. So…

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 did it and don't fault you for doing it), the fact remains that there were lots of missing features that I needed, and working with you was slower than doing it myself.

Maybe that has changed, but I have to be honest: being defensive and prickly is not making me want to do it. You're actually pretty much illustrating the primary reason why I stopped.

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

#78
post #74

Does 2.0 expose explicit capability negotiation, or does it infer capabilities from the selected model?

We have an extensive model registry with cost and capability tracking: https://rubyllm.com/available-models/

thx

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

#79
post #73
post #69

Earlier quoted context omitted.

Similar experience. I tried using this library about a year ago, but the Rails integration was really rough at the time, and things like persisting the conversation to the database required essentially bespoke code. Also, tool use, schemas, etc. for Gemini required a lot of work, observability was limited, and IIRC, it did stuff like overwriting records in specific situations. I don't know if that is improved, but it…

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.

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

#80
post #79
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.

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?

Post reply on HN