Introducing the AiGPL, the AGPLs more up to date cousin.
Protect your free software by refusing it to be used for any Ai/LLM related purposes whatsoever with the AiGPL.
And while this is done partially in jest, it's a jest similar to https://malus.sh/ which started it.
I am so glad someone said this. This also shows nicely how async is wrong, not just that it's viral, but it's bad design because it forces code duplication.
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.
This is not correct. The api that was disabled was deprecated for over a decade when disabled. It was an api that wasn't meant to be used. Zol folks kept using it out of tree and when Linus finally removed/hidden them people went apeshit thinking it was some sort of attack. It wasnt, it was 12 years late...
Really cool. For some reason when I opened the webpage I was like "this seems like it's written in Rust" and it is! I'm using Rust as my main language for the past 6 months now so it makes me happy :D
This happens regularly, the bee cluster doesn't wait for late comers. There are some scouts that keep going there and back but there are also scouts that do that with the "Correct" destination, so they "lead" the stray ones to their new home eventually. In the end most bees end up where they're supposed to.
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...
I'm not disputing that. In theory Rust should outperform even today but of course reality is a different beast and implementation details are important.
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)
Rust will outperform C consistently soon. It already does in some cases. It will also do so with safe idiomatic code in most cases. The reason behind my statement is simply more opportunity for the optimizer. Rusts rules allow for a more aggressive optimization. The reasons why it's not outperforming C yet are LLVM bugs and some missing Rust language features and fixes. LLVM in particular is driven by C needs so they rarely fix bugs present only Rustc generated IR.
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.
No, I asked on the IRC channel and forums as well as a friend who does embedded. The answer was basically "because clippy doesn't know the target arch it has to be a conservative-guess" which I agree with.
My friend also explained how it's a REALLY tricky question to answer properly especially given specific embedded architectures and setups where the answer is very hard.
I've had a smaller but similar dive recently while working on embedded machine (32 bit) with Rust. Clippy was pushing me to use move/copy instead of reference for passing a [u8; 8].
I thought this strange on a 32bit machine so I dived in and it turned out the "rule" is supposed to be "up to 2 register sized" variables are supposed to be copied, anything bigger is supposed to be referenced.
The trick here is that due to compatibility and no knowlege of target platform and setup clippy assumes 32bit register size. So on 64 bit platforms you'll only get this warning up to 8 bytes as well for example.
I never went in to actually see if it makes any sense on that particular 32bit platform, so good to see someone taking a dive on the actual compiled code side.
And while this is done partially in jest, it's a jest similar to https://malus.sh/ which started it.