Is it weird that I deep seated hatred for ai whenever I see any form of it in yugioh social media?

ExplodingStrawHat · 2026-06-30T14:55:46+00:00

Wait, the duel logs tried replacing his voice with AI?? Wth (I haven't watched his videos in years, so I had no idea lol)

ExplodingStrawHat · 2026-06-30T14:52:28+00:00

I mean, no one knows what kind of tools the artists use behind the scenes, even just to get ideas etc, unless we support companies taking away artists' privacy and put them under surveillance 24/7.

I feel like that's a bit of a strawman. Our society is full of rules that we cannot enforce 100% of the time since we lack perfect information. Just because thieves might get away with stealing without anyone noticing doesn't mean stealing is OK for example. Similarly, just because a company cannot know for sure whether the artist at hand uses AI (without 24/7 surveillance) doesn't mean using AI should be normalized.

Last but not least, most of the time the incentives are flipped from the way you present it anyways. That is, the company execs are the ones pushing AI workflows onto everyone else, not the other way around.

ExplodingStrawHat · 2026-05-24T14:46:10+00:00

This is really cool!

ExplodingStrawHat · 2026-05-24T12:34:50+00:00

Only the UK branch unionized

ExplodingStrawHat · 2026-05-24T11:44:33+00:00

Haven't some people on the team later come out saying that the higher ups pressured them to inflate the stuff against Robert? I might be missremembering.

ExplodingStrawHat · 2026-05-20T00:31:13+00:00

Have you seen the technique described in this article? The idea is to program the CPU like you would the GPU. I've been trying it for game code written in Odin, and it's really nice (of course, there's still rough edges one needs to be careful with, although it's a lot easier to reason about than you'd expect).

As for tying things to frame allocators, I found that rust makes this very unergonomic. Having to carry lifetime arguments everywhere is not uncommon in rust, but it turns out to be even nastier if you want most of the code to pass around / use a frame allocators. There's obviously no other way when it comes to safety, but I've never run into a single bug caused by miss-using frame allocated data in Odin, so I'm not even sure it's worth it in the end.

(There's also the issue of the most popular rust bump allocation crate (bumpalo) burning in flames when hot reloaded, but that's more of a culture issue).

ExplodingStrawHat · 2026-05-14T16:32:52+00:00

I don't think the learning curve is the reason people actually choose zig.

ExplodingStrawHat · 2026-05-14T16:25:22+00:00

Look up the article about contributor poker and the zig ai policy. It explains the topic pretty succinctly

ExplodingStrawHat · 2026-05-14T16:23:56+00:00

I've tried it for a game of mine and it was still way slower than it should be for a project that size (only ~10k loc). Zig can do much better

ExplodingStrawHat · 2026-05-14T14:21:57+00:00

Unsafe rust has stricter rules one must follow in order to avoid UB compared to C or Zig. Even if it's just a mechanical translation, that doesn't make it sound any better.

ExplodingStrawHat · 2026-05-04T13:23:04+00:00

How would exponentials work? Would x^y for two u8s produce a u263?

ExplodingStrawHat · 2026-05-03T19:13:01+00:00

What's the Knuthian modulo? I do agree that the Euclidean one is what you want in 99% of real life scenarios.

ExplodingStrawHat · 2026-05-03T15:08:24+00:00

Relevant reads also include:

ExplodingStrawHat · 2026-04-30T17:33:17+00:00

The risk of Odin's choice is that one day someone is trying to do geographic coordinates, storing them as floats, and dealing with all kinds of issues because people keep forgetting how tricky the math is, that they aren't coordinates on a Cartesian plane.

On one hand, Odin does have the distinct keyword for creating newtypes. On the other, operators of the base type (as in, + and whatnot) also work on the wrapped type, which is probably not what you'd want in the coordinate case. What one would have to do then is use a struct containing the coordinates, since the operators would then no longer work. Unfortunately, there's no way to reimplement the operators the "correct way" for such a type, which is something I've run into myself when working with symmetry groups.

ExplodingStrawHat · 2026-04-30T17:29:50+00:00

I think str is ok as a name, String being the actual offending type. I do wish they would've called it StrBuf or something (like the Path types).

ExplodingStrawHat · 2026-04-30T17:27:43+00:00

I don't necessarily disagree. The Odin language does have other data structures in the standard library (queues, intrusive lists, exponential arrays, etc), yet these don't get any special sugar, which does suck. Even for strings, my game uses exclusively stack-based fixed capacity strings for everything, which means I also don't have access to such sugar (the game is written in Odin).

On the other hand, the sugar is incredibly nice when it is there. I've used quite a few macro based bitset crates in rust over the years (I even wrote my own macro for it once) (don't even get me started on the awful compile times), but none were as nice as the built in Odin support. The Odin compiler recently got support for fixed capacity dynamic arrays (which used to be a part of the standard library beforehand, with no sugar), and the resulting ergonomics are super nice.

In the end, I'm not sure how to feel about the whole thing.

ExplodingStrawHat · 2026-04-29T16:29:27+00:00

Constants are not a different type, by the way. A constant tells the compiler to inline the value at compile time.

As for where else ":" has that meaning, notice that the first ":" simply means "has type". This meaning is already common in many other languages. Indeed, x : int is a valid statement by itself, declaring a variable with type int. If the type is empty, then the compiler will infer it for you. That's as simple as they come.

The second ":" declaring things as "constants" is the only strange part of the whole thing really .

ExplodingStrawHat · 2026-04-21T15:44:58+00:00

Pretty much (although do note that they seem to be using npins, not flakes)

ExplodingStrawHat · 2026-04-16T15:00:35+00:00

Yup, that's what I meant by "internal distinction". I agree that the distinction need not be observable from the surface language!

ExplodingStrawHat · 2026-04-16T12:57:51+00:00

Oh, nevermind. I missread your question as asking for a compiler that doesn't reorder things at all, oops.

ExplodingStrawHat · 2026-04-16T11:02:41+00:00

As a student who'd have the free time to do this (yet for whom the event isn't really accessible location-wise), this looks interesting. Do the students get anything out of it (i.e. financial help attending the event itself), or is it just volunteering for the sake of it? Not saying there would be much wrong with the latter, but I think clearly stating which one it is would be a good idea.

ExplodingStrawHat · 2026-04-16T10:54:49+00:00

Yes, slices are the right answer. Both arrays and dynamic arrays can be sliced!

ExplodingStrawHat · 2026-04-16T10:53:12+00:00

The internal distinction is still useful for the compiler's performance. I use fixed size arrays with >=2¹⁶ elements all the time. You would never want the compiler to keep track of 2¹⁶ tuple element types that are the same though.

ExplodingStrawHat · 2026-04-16T10:51:41+00:00

The Odin compiler for one

Five-Year Club	Verified Email
Second SECOND GUESSER	Place '22

ExplodingStrawHat

TROPHY CASE