> Why, then, do MCP interfaces have to "dumb it down"? Writing code and calling tools are almost the same thing, but it seems like LLMs can do one much better than the other?
> The answer is simple: LLMs have seen a lot of code. They have not seen a lot of "tool calls". In fact, the tool calls they have seen are probably limited to a contrived training set constructed by the LLM's own developers, in order to try to train it. Whereas they have seen real-world code from millions of open source projects.
I am curious: Is this a generally agreed upon fact or an assumption/conjecture?
> In his blog post, André says, “For the last ten years or so of working on Bundler, I’ve had a wish rattling around: I want a better dependency manager. It doesn’t just manage your gems, it manages your ruby versions, too. It doesn’t just manage your ruby versions, it installs pre-compiled rubies so you don’t have to wait for ruby to compile from source every time. And more than all of that, it makes it completely trivial to run any script or tool written in ruby, even if that script or tool needs a different ruby than your application does.”
> Bluesky threads reveal that Rafael França (Shopify / Rails Core) saw this tool as a threat, saying “some of the “admins” even announced publicly many days ago they were launching a competitor tool [rv] and were funding raising for it. I’d not trust the system to such “admin”.”
So a dev was innovating to make better tool to meet their needs (which is what most open source maintainers are generally doing all day), and then some guys immediately jumped to the possibility that they would then actively sabotage RubyGems? Whoa, that is insane.
Trying to kill innovation and a start-up out of fear doesn't sound like Shopify's branding in the media.
You left out the really gross quote from Rafael França: "I’m not so sure I trust them to not sabotage rubygems or bundler." I'm not eager to work with a community with leaders who say things like that in it. Imagine spending years volunteering work that helps a company like Shopify only to have someone malign your work like that.
I didn't understand why anyone would think that way. Python has new package management/build tools all the time and to my knowledge there's no drama about it, other then the normal dev arguments over which tools are best.
I'm reconsidering my opinion of Rafael considering the trajectory of DHH's rhetoric, and that Rafael has stayed in support of DHH throughout this time while many others have publicly called him out. Concerning.
At some point the majority will learn that no matter the public messaging most large companies will do what benefits their incumbency over what is best for the industry or customers.
It’s worth noting the weren’t the only ones signaled out. At least one maintainer who had worked closely with them, but not been involved in RV also got tarred with the “too involved with André or too politically similar”
It’s also worth nothing that DHH has moved against André before, via organizing a letter to his Board. In addition to any personal dispute and radically different politics (André is about as left as DHH is right in labor issues) there is how that’s played out in funding open source. André founded RubyTogether as a trade guild and DHH seemed to disapprove of rubygems/bundler maintainers getting paid directly by community support like that. I do not know if a black trans woman getting paid was part of what DHH was against or if she was collateral damage in his move.
André annd another maintainer worked (and a designer), together through my company on rubygems stuff for RC, at a great discount. Mostly we tried to structure it so they kept getting paid enough for to cover health insurance for their families, etc, while mostly rolling our company down.
It’s hard not to read it as “people who worked closely with André, whether or not they were going to work on RV, were targeted”. I think the fact that I am also a trans woman is bores coincidental, even given DHH’s politics. I don’t think he even remembers who I am and I don’t we mostly a tangential factor in any of this.
That is explained in the "On 9 September, HSBT ..." paragraph, which describes how an existing RubyGems maintainer did - and then undid (most) - changes. A new user remained as an owner of the RubyGems GitHub organization - which allowed Ruby Central to do things later.
It's effectively seed funding for early stage startups:
> Geplant ist die Finanzierung von 50 Startups über Wandeldarlehen zwischen 100.000 und 300.000 Euro mit einer Laufzeit von ein bis zwei Jahren, die dann in eine offene Beteiligung gewandelt werden
And with 100k you can even have a single developer working full time for a year! That will surely lead to groundbreaking new solutions, rivaling US tech giants.
I know that what the company has higher cost that the gross salary, but e.g. the EXIST founder's stipend will pay you 2500€/month if you have a university degree (30k/year), the rates at privately funded companies aren't much higher.
Quick note that Prisma (and most of the other modern tools) never "drops everything" for normal migrations. A database reset is a solution suggested when your migration history and the actual database are not in sync, which makes it impossible for Prisma to "calculate" the migration SQL to get the database in the desired state (which is defined in Prisma schema).
The commands that suggest a reset are explicitly designed for use with development databases, not with production. The "deploy migrations to production database" command on the other hand only applies already existing migration files (that you have reviewed before) and does not suggest a reset, ever.
reply