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

RubyLLM: A delightful Ruby way to work with AI

github.com

Post reply on HN
Print view View original

91–100 of 182 posts

Re: RubyLLM: A delightful Ruby way to work with AI

#91

Post by deedubaya »

xcskier56 wrote: post #84
deedubaya wrote: post #80

Looks useful. Allowing ai to eval() code or execute any sql statement would scare the crap outta me personally.

From searching the codebase, I can only find eval() used in the markdown and the specs. You’re totally right that eval()’ing unknown code is terrible but it doesn’t look like the gem itself is doing that. The usage of eval() is in a user written tool in the docs. Definitely a bd example and should probably be changed

Yes, that’s exactly what I was referring to. Folks (or llms!) never copy/paste doc examples, right?

Re: RubyLLM: A delightful Ruby way to work with AI

#92

Post by [deleted] »

tasuki wrote: post #73
bmacho wrote: post #57

Earlier quoted context omitted.

> Ruby does not require you to put the opening and closing parenthesis on a function to run that function, and it's not always put there when you have zero or 1 parameter mind = blown I always liked how functionName denotes the function and functionName() calls the function, and then it denotes the result e.g. in JavaScript or in math. But just saying functionName to call a function makes the code read more like Engl…

You'd like the ML-family languages, which don't use parentheses to call functions.

[deleted]

Re: RubyLLM: A delightful Ruby way to work with AI

#93

Post by simpaticoder »

continuational wrote: post #34
toasterlovin wrote: post #26

Earlier quoted context omitted.

I don’t really mean this to be derogatory toward people who enjoy other things, but Ruby is a language and ecosystem by and for people who have taste.

Certainly a taste for global state, it seems.

Global state is wonderful when the world is small. Rubyfolk then keep the world small, which has many other benefits.

Re: RubyLLM: A delightful Ruby way to work with AI

#94

Post by lolinder »

simpaticoder wrote: post #93
continuational wrote: post #34

Earlier quoted context omitted.

Certainly a taste for global state, it seems.

Global state is wonderful when the world is small. Rubyfolk then keep the world small, which has many other benefits.

Sorry, I like Ruby, but this is nonsense. Rails apps get enormous very quickly, like apps written in every other framework. In most work you can't just declare that your world will be small, your world is as big as your problem is.

Re: RubyLLM: A delightful Ruby way to work with AI

#95

Post by lolinder »

bmacho wrote: post #55
zelphirkalt wrote: post #53

Earlier quoted context omitted.

Usually though it just creates long term issues, putting off important work to later.

Sometimes later never comes, so it's a net win compared to languages where you are forced do this important work now.

But when later does come, it can take dev-years to fully disentangle the global state and allow code reuse. Did you gain dev-years in productivity by using it in the first place? Probably not.

If you have good reason to believe that an app will stick around for more than a year, be maintained by more than 3 people, or grow to more than 500k lines of code (sub in whatever metrics make sense to you), don't put off removing global state for later. You will regret it eventually, and it doesn't cost much to do it right the first time.

(Also, no mainstream language I'm aware of forces you to not use global state. Even Java, famed for its rigidity, has global state readily available if you really do need it.)

Re: RubyLLM: A delightful Ruby way to work with AI

#96

Post by lolinder »

jatins wrote: post #37
rochak wrote: post #35

Earlier quoted context omitted.

Umm, doesn’t Go do so as well? Personally, I’ve had a better experience working with Go tooling.

Go ecosystem is generally good. However, given that Go as a language doesn't have any "fancy" (for the lack of a better word) syntactical features you can't create DSL's like this though Ruby's expressiveness comes at a cost and I'd personally stick with Go in a team but use something like RubyLLM for personal projects

I'm wary of equating "ability to create dsls like this" with "prioritizing developer experience".

Ruby and go each prioritize different parts of the developer experience. Ruby prioritizes the experience of the author of the initial code at the expense of the experience of the maintainer who comes later. Go prioritizes the experience of a maintainer over the experience of the initial author. Both prioritize a developer, both de-prioritize a different developer, and which one makes more sense really depends on the ratio of time spent on writing greenfield code versus maintaining something another human wrote years ago who's long gone.

Re: RubyLLM: A delightful Ruby way to work with AI

#97

Post by techscruggs »

continuational wrote: post #34
toasterlovin wrote: post #26

Earlier quoted context omitted.

I don’t really mean this to be derogatory toward people who enjoy other things, but Ruby is a language and ecosystem by and for people who have taste.

Certainly a taste for global state, it seems.

Well, taste for a Global Interpreter Lock, at least.

Re: RubyLLM: A delightful Ruby way to work with AI

#98

Post by kyledrake »

This 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 that the DSL is quite excellent.

Re: RubyLLM: A delightful Ruby way to work with AI

#99

Post by kaiuhl »

viraptor wrote: post #62
bmacho wrote: post #57

Earlier quoted context omitted.

> Ruby does not require you to put the opening and closing parenthesis on a function to run that function, and it's not always put there when you have zero or 1 parameter mind = blown I always liked how functionName denotes the function and functionName() calls the function, and then it denotes the result e.g. in JavaScript or in math. But just saying functionName to call a function makes the code read more like Engl…

It comes with the downside that if you want to pass the function itself around, you need to do f=something.method(:the_function), and then f.call(args). It's not a huge deal, but... meh.

But in general, ruby code only passes anonymous functions and, in those cases, the syntax is beautiful.

Re: RubyLLM: A delightful Ruby way to work with AI

#100

Post by trevorhinesley »

lolinder wrote: post #95
bmacho wrote: post #55

Earlier quoted context omitted.

Sometimes later never comes, so it's a net win compared to languages where you are forced do this important work now.

But when later does come, it can take dev-years to fully disentangle the global state and allow code reuse. Did you gain dev-years in productivity by using it in the first place? Probably not. If you have good reason to believe that an app will stick around for more than a year, be maintained by more than 3 people, or grow to more than 500k lines of code (sub in whatever metrics make sense to you), don't put off remo…

You’re describing the pain of poor architecture rather than the pain of global state. The tool itself is neutral. Sharp knives and all that.
Post reply on HN