[flagged]
RubyLLM: A Ruby framework for all major AI providers
61–70 of 91 posts
Re: RubyLLM: A Ruby framework for all major AI providers
#62We'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.
Re: RubyLLM: A Ruby framework for all major AI providers
#63[dead]
Re: RubyLLM: A Ruby framework for all major AI providers
#64Earlier quoted context omitted.
Well put!!! You work your arse off for free and the guy who made the disparaging comment didn't even bother to research to see if he had the details right. Hat's off to you Carmine for all your work. Many people really do appreciate it.
FWIW, I don't think the GP post is disparaging (at least as I read it right now.) I think it is fair to list limitations from using a library that provides an abstraction; it can suggest why a tool isn't right for a person's use cases. But it also sounds like this API handles those pretty well.
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 developers on a public board astray.
Re: RubyLLM: A Ruby framework for all major AI providers
#65[dead]
Re: RubyLLM: A Ruby framework for all major AI providers
#66Earlier quoted context omitted.
FWIW, I don't think the GP post is disparaging (at least as I read it right now.) I think it is fair to list limitations from using a library that provides an abstraction; it can suggest why a tool isn't right for a person's use cases. But it also sounds like this API handles those pretty well.
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 write the terms so broad that "disparagement" means saying anything negative, regardless of malice or intent.
Re: RubyLLM: A Ruby framework for all major AI providers
#67Meanwhile Ruby is dropping like crazy on TIOBE. TIOBE has tons of issues, I get it, but the underlying message is that Ruby is struggling immensely, for many reasons (and has been for a while). The language is still great as-is, but if there is no solution to lack of new developers, ruby will just follow perl's path to extinction. AI is not going to save ruby here; quite the opposite. More AI will mean less quality overall. The AI generated documentation is useless gibberish. It's not even an improvement over lacking documentation in the first place, which many ruby projects also have as an issue.
Re: RubyLLM: A Ruby framework for all major AI providers
#68We'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.
> engaging the maintainer on PRs
Well, do real people want to "interact" with bots, including AI? I noticed this problem recently on prawn. Someone wants to merge about 1000 lines of code, 95% of what was auto-written by some AI model. Then he complained that the solo-maintainer does not want to review those ~1000 lines of code. What can I say ... I understand the issues by real humans more than by "vibe" coders here.
Re: RubyLLM: A Ruby framework for all major AI providers
#69We'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 was essentially a no-go for me at the time.
I tried submitting some PRs, but got a chilly reception. It was taking so long to make any forward progress on the parts I needed that I gave up, and wrote my own layer to do the parts of this that mattered to me. It didn't take long, and ultimately, I've customized it so much over time that I'm glad I didn't make this a dependency.
While the parts of this gem abstracting the various LLMs are nice and well designed, I think this kind of thing is a liability for anything but the most trivial applications. LLMs are moving too quickly to have the core connection infrastructure be gated on the release cycle of a third-party library. You can see this in the various comments down-thread where people are talking about the library lacking the Responses API -- it's great that the library is about to fix that problem, but if you just write your own adapter, you'd have been done months ago.
One of the biggest implications of LLMs in software, in my opinion, is that entire classes of third-party dependencies can be eliminated. It's interesting to look at which ones those are (and which ones continue to get interest) because it tells you a bit about where the post-LLM value of software will reside.
Re: RubyLLM: A Ruby framework for all major AI providers
#70Congrats 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 I am quite excited for RubyLLM 2.0 and beyond.