lackoftactics

Not only buggier, but less usable overall. We can not blame everything on AI. For example events discovery platforms and ticket platforms were way better decade ago, you could search by popularity, friends going to the same event and there wasn’t as much fragmentation. That part you could blame on Cambridge Analytica scandal and late capitalism love of algorithmic feeds

also the conseqeunces of implementing it badly from scratch don't make sense if you can use battle-tested solution

It's one of those things you shouldn't trust LLMs to such an extent; that part should be very solid because the consequences of bad practices are getting to front page of hacker news :)

There was a recent interview with Dax Raad on the Pragmatic Programmer podcast, and they talked briefly about it. We would like a future where we do just a bit more work and are happier with legacy codebases or work on getting rid of tech debt, but that definitely won't be something our employers are interested in.

other thing could be also true, if you are great developer who spent decade honing their craft (vim, working on hobby projects, grinding when your friends party) you would hold cognitive bias against it as it flips the script. I don't think our profession is going away, but the shift is happening and it's not very comfortable one.

definitely hard to beat Bun at the moment, the live reload is crazy good

they introduced static typing (Sorbet) to avoid problems, it's completely different app and looks nowhere close to what you experience in standard Rails app

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 readability while gaining safer refactoring, better tooling, and earlier feedback.

That doesn’t mean dynamic languages can’t produce high-quality software. They obviously can. But I don’t think appreciating modern static typing is just evangelism.

And yes, I understand what this library is about, it's for "beautiful" easy to use interface to AI providers for Ruby apps. It's the popular play nowadays with litellm, bifrost, gomodel and vercel gateway. We have at least couple AI gateways, libraries like that every week on HN.

Even as rails dev, I am seeing that you might be right. It’s really hard to find specific pros nowadays that Ruby brings to the table. All that talk about conventions over configurations and vast presence of Rails in weights is fun, but if writing speed isn’t an issue anymore, then Ruby on Rails has serious problems with larger codebases

there are only limited number of patterns for ui,ux, CTA. It sucks to be stolen from, but we build on top of each other most of the time

Two questions.

How do you handle the competition like https://github.com/ENTERPILOT/GOModel and Bifrost? They already moved to more performant languages like Go.

What is the moat of litellm currently and why such a radical move?

And the effort to produce valid benchmarks is tremendous. You are probably right and that’s very annoying. We already had flame wars over frameworks and this is way worse, your vibes vs. my vibes. Who would thought non-deterministic outputs would lead us here?

Thanks for the link! I thought I know every obscure law and I was so wrong.

Looked at your repo, even starred. On the surface, I like your approach a bit better. It looks like your idea sits at the space between semantic search and compressing tokens. I was into semantic search before, but mostly trying to vectorize codebase instead of tree sitter and couldn’t make the semantic search work for me. Thanks for sharing!

1. Are you sure no one is fooled? It’s the main thing managers are praising rtk for and using as an argument for it’s validity. If this is gamed, then it paints a very different picture. 2. No, I didn’t vet all the reports. But they paint quite convincing picture of the problems present in the library, which has a very ambitious goals of handling every popular command and making it less verbose. 3. You know this is not a valid point. Engineers tanking performance and choosing based on hype is nothing new. Github stars and usage is not a valid argument, when the tool is not very transparent and could quietly fail. If it’s only couple percents less accuracy, most wouldn’t easily recognize it with the whole stack of skills, mcps and agents.md 4. Is it something more than a feature? If the benefit is $3 on $900 as other commenter pointed out using maybe better and well researched article than mine from codepointer, why would I risk that for all the possible bugs and worse accuracy. 5. Hard to address this one. Tough problem domain to handle with endless cli commands to capture and process properly.

Congratulations on your accepted PR. I didn’t want to make you grumpy today. If you feel I am wrong, it’s very possible. I am just a guy who wrote my point of view, it doesn’t automatically make it valid. Once again sorry for making you grumpy.

As an author of the text, I can say you are „absolutely” not correct. I might be already spending too much time with llms and they start to shape my texts, so I am not proud of that either. But thanks for bringing very valuable insight to otherwise interesting discussion.

Tbh I could buy into what you are proposing more than rtk. It feels sane in comparison

Nice, I am not good enough engineer to be in the weights

What is your approach for reducing token usage and is it different than rtk?

That’s the fair point. The rtk promotional posts point to 60-90% tokens savings and there is no mention how they perform accuracy wise. The commenter below did great job pointing to resource showing caveman, rtk saving just couple bucks on $926 bill. Thanks, Llyoyd Christmas for linking to useful substack

I have to say I made a similiar mistake with trusting semantic search is the next big thing. My opinion shifted, but it made sense for me for too long

Nope, I am doing my master thesis on finetuning llms at 36, so I am into this stuff, but it’s been very weird lately. I’ve been self-taught dev and I definitely was missing computer science concepts so excited to fill the gaps, although the timing wasn’t perfect.

Good conversation! Great pushback against my arguments. That’s what I signed on with hacker news and missing that spirit recently

oh, I appreciate this list even more than the one posted. It has so many less known websites that no llm gonna suggest

appreciate the engineering effort and skin in the game. I might try on macos today as the author of issue.

Hey, author here, I am skeptical of implementation starting from Rust Token Killer and looking to monetize on Rust love by other developers.

Concept is fine to me and I believe we should optimize, but a repo that will handle all tools sounds like Sisyphus rolling a rock up the hill.

ok, this one is all mine. So that's even more hurtful as this is 100% me

no, it doesn't upset me. I am open for discussion, there might be things I miss and don't understand. I am just trying to get why it's been pushed so hard lately and if the benefits are really there. Sorry, if I sounded upset to you, but I am trying to be really civil and just genereally curious

I was wondering if that impacts the accuracy, obviously the rtk output wasn't in the training dataset, but maybe it doesn't matter at the end

Author of the text here. I will be honest with why I wrote it, the rtk ai looks very odd to me as software engineer, the number of stars, no mention of accuracy and how management is pushing that stuff to optimize costs. Now people are wrapping every possible command in rtk and trying to handle all major possible commands and decide which output you should get.

I was looking through the issues as investigation. Some issues that caught my attention are looking quite bad https://github.com/rtk-ai/rtk/issues/2494 https://github.com/rtk-ai/rtk/issues/2462 https://github.com/rtk-ai/rtk/issues/2395