I wrote a script (now an app basically haha) to migrate data from EMR #1 to EMR #2 and I chose Nim because it feels like Python but it's fast as hell. Claude Code did a fine job understanding and writing Nim especially when I gave it more explicit instructions in the system prompt.
I thought about this but what would it have that is missing? Hardware decoding for newer codec like AV1 is one thing, but what else?
I have two of these one in my living room and one in my bedroom. They are the best devices for playing pirate Emby servers 4k Remuxes with dolby vision and dolby audio support direct play.
They're missing support for newer codecs and current WiFi standards, can't decode Dolby Vision FEL, and, unless something had changed recently, they don't keep up on security updates (even if they are pushing out other updates).
I suspect the last point would be true even if they launched new hardware, though.
Also the current hardware has lots of overheating problems that hugely affect performance (you have to re-paste the heat sink to the CPU after only 2 years), and thier Bluetooth antenna is so awful it makes Bluetooth controllers for gaming completely unusable due to lag from lost/dropped packets (and the remote constantly disconnect and reconnect randomly).
In addition to hardware support for more modern codecs, USB C seems to be an easy upgrade, it would also benefit from being able to detect frame rate to auto-switch for the HDMI (this likely needs hardware support).
Is there another car out there in the US that has a way to type in an address, tap a button, and it drives you there? All other car manufacturers software is terrible.
Python dudes are in for a treat, Oban is one of the most beautiful elegant parts of working with Elixir/Phoenix. They have saved me so much heartache and tears over the years working with them.
Generally speaking the boomer generation has a different set of ideals from gen-x/millennials, and they are on the way out of shot calling. I don't think things repeat.
It's not. The guy behind Moltbot dislikes crypto bros as much as you seem to. He's repeatedly publicly refused to take fees for the coin some unconnected scumbags made to ride the hype wave, and now they're attacking him for that and because he had to change the name. The Discord and Peter's X are swamped by crypto scumbags insulting him and begging him to give his blessing to the coin. Perhaps you should do a bit of research before mouthing off.
i'd say the crypto angle is only one factor. as is usual in the real world, effects are multifactorial.
clawdbot also rode the wave of claude-code being popular (perhaps due to underlying models getting better making agents more useful). a lot of "personal agents" were made in 2024 and early 2025 which seem to be before the underlying models/ecosystems were as mature.
no doubt we're still very early in this wave. i'm sure google and apple will release their offerings. they are the 800lb gorillas in all this.
I highly suggest you expose functionality through Graphql. It lets users send out an agent with a goal like: "Figure out how to do X" and because graphql has introspection, it can find stuff pretty reliably! It's really lovely as an end user. Best of luck!
A proper REST API would also work without all the extra overhead of GraphQL.
People may dislike XML, but it is easy to make a REST API with and it works well as an interface between computer systems where a human doesn't have to see the syntax.
Depends mostly on efficiency: GraphQL (or Odata as a REST compliant alternative that has more or less the same functionality) provide the client with more controls out of the box to tune the response it needs. It can control the depth of the associated objects it needs, filter what it doesn't need, etc. This can make a lot of difference for the performance of a client. I actually like Odata more than GraphQL for this purpose, as it is REST compliant, and has standardized more of the protocol.
Not one of the downvoters, but I'd guess it's because this is only true with HATEOAS which is the part that 99% of teams ignore when implementing "REST" APIs. The downvoters may not have even known that's what you were talking about. When people say REST they almost never mean HATEOAS even though they were explicitly intended to go together. Today "REST" just means "we'll occasionally use a verb other than GET and POST, and sometimes we'll put an argument in the path instead of the query string" and sometimes not even that much. If you're really doing RPC and calling it REST, then you need something to document all the endpoints because the endpoints are no longer self-documenting.
But that is roughly the point here. If we still used REST we wouldn't need swagger, openapi, graphql (for documentation at least, it has other benefits), etc.
We solved the problem of discovery and documentation between machines decades ago. LLMs can and should be using that today instead of us reinventing bandaids yet again.
I didn't downvote, but I'm thinking that you need endpoint discovery, bucket types, etc. Sure you could write a 1 page document describing the buckets at the root level, the relationships of the objects, etc., but why not let swagger do that for you at compile time?
I'm talking about actual REST here though, not RPC. Endpoint discover and typed schemas are core pieces of REST, we don't need Swagger or similar to fill in those gaps.
I tried this recently and found the token overhead makes it prohibitive for any non-trivial schema. Dumping the full introspection result into the context window gets expensive fast and seems to increase hallucination rates compared to just providing specific, narrow tool definitions.
reply