This works with anything that one might call "named tuples".
So, you can also define a struct like so and it'll work:
struct Baz(i32);
On the other hand, if you define an enum variant with the normal struct syntax, it does not work:
enum Foo {
...
Qux { something: i32 } //cannot omit braces
}
Well, you would determine the TypeId of SomeOtherType, then search for that as the key in your HashMap and get back a None, because no entry exists and then you'd hand that back to the user.
I guess, my little usage example should've included handling of an Option value...
So, it's only a runtime error, if you decide to .unwrap() or similar.
A cool thing you can do, is to store values of all kinds of types in a big HashMap, basically by storing their TypeId and casting them to Box<dyn Any> (see std::any).
Then you can later retrieve those values by specifying the type (and optionally another ID for storing multiple values of the same type).
So, you can create an API which is used like this:
let value = MyType::new();
storage.insert(value);
let retrieved = storage.get::<MyType>();
assert_eq!(retrieved, value);
There's various ECS storage libraries which also implement such an API. Depending on what you're doing, you might prefer to use those rather than implementing it yourself, but it's not too difficult to implement yourself.
I believe, this entire post is fiction...
Cooking with rice. I was never big on rice, so never had particular ambitions for experimenting with it.
Then I found a rice variety in the shops, which actually tastes nice on its own, and also you're allowed to just dump it into a pot of water, then drain the remaining water, which I much prefer for experimenting.
And yeah, that has led to me catching up with experimenting very quickly. Last week I made basically a risotto using:
...and last, but definitely not least, orange slices.
And it tasted fucking rad. That's my favorite feature of rice. You can throw in the wildest ingredients and it magically makes them work together.
It does have a decently-sized modding scene, though? Like, it cannot compete with the popularity of Minecraft and therefore doesn't have as many modders.
But it has a modding API, which makes it a lot easier to mod and means that the mods don't break with every new version, so the effective output of those modders is actually pretty good.
Or well, just look at it: https://content.minetest.net
I believe, they increased it a little while ago, so it's actually -64 to +320 now.
But yeah, I don't think anyone's actually happy about the limited world height. It's so limited, because of the way Minecraft works on a technical level. It loads the map in chunks, which are just massive pillars, reaching from the bottom of the world all the way to the sky, across the whole 384 blocks.
As a result, if they increase the world height, they increase how many blocks have to be loaded at once, which increases the lag.
Luanti doesn't have this problem, because it uses cubic chunks instead.
Man, I saw them initiating discussions around the name like a year ago. I did not expect anything to actually come from that after all this time. But yeah, glad that it did.
Now we just need a better default font. ๐
I find the increased world height much more important. Luanti can generate actual mountains, and caves where you'll want to bring ladders for your descent.
It was the first time, I felt like it made sense to build minecarts and intermediate mining bases, because the ores reach far deeper.
Oh, I didn't mean to say that balenaEtcher actually had gone unmaintained before. I just meant that it's likely to do so in the future, like pretty much all software.
dd is kind of in a unique position, in that it's so simple, that it'll hardly need maintenance, and it's useful enough that it presumably gets this maintenance.
With balenaEtcher, it's developed by a company. If that company folds or changes strategy, then they'll stop maintaining balenaEtcher.
It's also implemented with Electron, i.e. browser technologies. If it goes unmaintained for a few months, you'll quickly have security vulnerabilities in there.
You might also not find anyone willing to maintain such a comparatively thick tech stack...
Yeah, I do miss those, too, although I've noticed that I'm becoming ever more consistent with just naming my variables like the type is called and that works out nicely in Rust, because then you can also leave out the field name when filling in a struct with named fields. I'll often have named my function parameters the same name that I ultimately need to pass into structs fields.
At this point, I'm secretly wondering, if a programming language could be designed where you don't normally fill in variable names, but rather just use the type name to reference each value.
For the few cases where you actually do have multiple variables of the same type, then you could introduce a local (type) alias, much like it's currently optional to add type annotations.
Someone should build this, so I don't have to take on another side project. ๐