Wow the syntax is beautiful!
I support software in many languages and ruby has to be the most syntactically stimulating.
RubyLLM: A delightful Ruby way to work with AI
111–120 of 182 posts
Re: RubyLLM: A delightful Ruby way to work with AI
#112I understand it's a Ruby thing, `chat = RubyLLM.chat` looks odd. How do I know whether it's a function call returning an object or just an assignment? Why not just use `RubyLLM.chat()` and eliminate the ambiguity?
Re: RubyLLM: A delightful Ruby way to work with AI
#113Earlier quoted context omitted.
Is it really Ruby or they just made a nice interface? I don't see why a hypothetical TypeScript example would be all that different. // Just ask questions const chat: Chat = LLM.chat; chat.ask("What's the best way to learn TypeScript?"); // Analyze images chat.ask("What's in this image?", { image: "ts_conf.jpg" }); // Generate images LLM.paint("a sunset over mountains in watercolor style"); // Create vector embedding…
It's the extra parens, semi-colons, keywords and type annotations. Ruby makes the tradeoff for legibility above all else. Yes, you can obviously read the TypeScript, but there's an argument to be made that it takes more effort to scan the syntax as well as to write the code. Also: const chat: Chat = LLM.chat; ...is not instantiating a class, where Ruby is doing so behind the scenes. You'd need yet another pair of par…
chat = RubyLLM.chat
Re: RubyLLM: A delightful Ruby way to work with AI
#114Earlier quoted context omitted.
I'm not sure what your point is. I care about Ruby and want it to die because I have worked on the Gitlab codebase, which is written in Ruby. It's a bad language and it stopped me being able to understand behaviours and fix bugs. In contrast I have also worked on VSCode which is similarly huge but written in Typescript. Faaaar easier to work with, enough that I've been able to contribute a couple of medium sized feat…
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.
Re: RubyLLM: A delightful Ruby way to work with AI
#115[flagged]
Re: RubyLLM: A delightful Ruby way to work with AI
#116I understand it's a Ruby thing, `chat = RubyLLM.chat` looks odd. How do I know whether it's a function call returning an object or just an assignment? Why not just use `RubyLLM.chat()` and eliminate the ambiguity?
In Ruby, chat = RubyLLM.chat is a method call since Ruby doesn't have properties, only methods. Dropping parentheses is standard Ruby style, familiar to Ruby developers. While adding parentheses is allowed, it doesn't match Ruby's readability. The library aims for a clean style consistent with Ruby conventions.
Re: RubyLLM: A delightful Ruby way to work with AI
#117[flagged]
[deleted]
Re: RubyLLM: A delightful Ruby way to work with AI
#118I run engineering for a venture backed AI-first startup and we use Ruby/Rails. For us, it made sense to leverage one of the best domain modeling and ORM frameworks out there. Most of our inference is http calls to foundational models, but we can still fine tune and host models on GPUs using Python. Inference matters, but part of building an effective user platform are the same old SaaS problems we’ve had before, and…
[deleted]
Re: RubyLLM: A delightful Ruby way to work with AI
#119Earlier quoted context omitted.
Global state is a tool that will almost always lead to bad architecture in an app where architecture matters. I'm sure you can point to a counterexample or two where a set of devs managed to keep disciplined indefinitely, but that doesn't change the fact that allowing people to reach into a mutable variable from anywhere in the system enables trivially accessible spooky action at a distance, and spooky action at a di…
“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 time—than it is to spread the idea that globals are really just fine and you need to weigh the trade-offs. The odds are strongly against you being the exception, and you should act accordingly, not treat globals as just another tool.
Sometimes amputation is the right move to save someone's life, but you certainly should not default to that for every papercut. It's a tool that comes out in extreme circumstances only when a surgeon can thoroughly justify it.
Re: RubyLLM: A delightful Ruby way to work with AI
#120This interface needs to have a better relationship with streaming, there is always a lag in response and a lot of people are going to want to stream the response in non blocking threads instead of hanging the process waiting for the response. Its possible this is just a documentation issue, but either way streaming is a first class citizen on anything that takes more than a couple seconds to finish and uses IO. Aside…
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