I've been using it for my personal project and it's still too expensive and very slow when thinking. I think we need one more generation from mistral and with maybe 50% of this already "slashed" price for this to be competitive (I use Opus 5.5 at work and it's still much better than this).

And while this is done partially in jest, it's a jest similar to https://malus.sh/ which started it.

Comments URL: https://news.ycombinator.com/item?id=47520073

Points: 2

# Comments: 1

Middleware/library writers that touch on anything that could be async (db, SPI, network etc.) will now have to write two versions of their API and duplicate most code.

I wanted to avoid people just taking this out of the javascript source so it's using some hash tricks to prevent that. Maybe I over engineered that a bit though.

Puzzle out what prompted stable diffusion to create the image. New puzzle each day.

Comments URL: https://news.ycombinator.com/item?id=33089008

Points: 2

# Comments: 4

It's much worse when a beekeeper takes the swarm tho. Speaking from experience, you can see "lost" scouts going to and from the temporary cluster from their destinations for days after you moved the cluster into a new hive. The reason is because there's noone going from cluster to new hive since no scout found that destination. It's a bit heartbreaking.

I collected the "leftover" mini-clusters 4 times in a row coz I felt responsible...

Then you also get into architecture specifics etc.

dodobirdlord described the two major advantages Rust has on the language level very well so I won't repeat them, but the gist I'm making is that Rust simply allows more optimizations purely on the language level. Specifics of backend implementations are of course another topic completely (and is one of the reasons why I'm excited for the possibility of a GNU Rustc)

The original goal was an ASCII game but since I needed to create the resources for it it morphed into Texel. I think the use of ECS here wasn't a bad decision but Specs proved to be just too cumbersome and overoptimizing.

As others have mentioned ECS is a bit "loosly defined" and each implementation seems to go over the line to add more specializing one way or the other. I want to switch to something more simple and elegant like DCES (https://crates.io/crates/dces) for my next refactor.

I think for "runtime resource management" ECS is fine if you need a fairly large, distinct pool of entities to handle. One of my main usage problems was the re-use of same components in the same entity.

E.g. imagine having an entity with a global world position, but also an internal position for something like "last cursor position". It's not possible to just "add another Position component" to the same entity, for good internal reasons, but still. It's pretty important people take these kind of limitations into account before planning out their entity/component maps.