So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)

With unsafe, you’re telling the compiler “I’ve taken extra care to make sure that what I’m doing is safe and doesn’t break your rules” and the compiler can go ahead and assume that you don’t, in fact, break the rules, and therefore can verify everything else as if the rules never got broken.

In less safe languages, the entire program is “trust me, it’s safe”, while in rust only the parts flagged as unsafe are.

The point is that you should only use unsafe when 1. It’s absolutely necessary for functionality or performance and 2. You have verified and are very certain that the code is correct.

That’s a very useful property to have.

Your vendors plans to grow fast and break things shouldn’t affect your ability to provide your service to your customers.

Anthropic has not been a reliable vendor. Previously, when they were compute starved, the quality of their models degraded in the weeks before new releases, without warning to their customers. You just suddenly got a worse service. I wrote a little more a few months ago: https://news.ycombinator.com/item?id=47375818 And then there’s the transparent downgrading they did with Fable.

If your running a business, that’s not what you want to be relying on.

It works quite well for me, a lot better than when the LLM makes these decisions.

This is the problem.

I would love to have a product sheet showing what each models strengths an weaknesses are, so that I can have a clear decision tree of "if this kind of work, use model X", or "model Y should be used in ways Z". But they all look the same from the outside and the only way to figure out which might be marginally better at what is to do extensive, time consuming, and perhaps expensive testing.

Hasn’t the Bullet physics engine been used for robotics for over a decade?

I don’t understand this “first game engine for robotics” messaging.

As an aside, this website crashes for me on safari on iOS.

That’s not at all what I’m saying.

I’m saying that in my experience across multiple models, the follow up prompts don’t fix prior underlying issues. They usually patch on top instead, unless you give them significant and time consuming guidance.

I want them to be more useful outside of one-shot uses, but I find that they currently miss the mark.