TehPers

Zig's features don't map 1:1 to Rust's features, so translating line-by-line (or file-by-file) doesn't even make much sense. What are you supposed to do with a crazy comptime function full of reflection when translating that? What about custom pointer types (which Bun had to create for Rust), lifetimes, differences in ecosystem library APIs, etc?

The author actually mentions the challenges they ran into due to breaking the code up across multiple crates. They needed to break cyclic dependencies for it all to compile.

I agree. 1 year is an underestimate.

As little sympathy as I have for these kinds of people, what Davide is accused of doing is still unacceptable. Still, thanks for the additional context. Makes it easy to decide not to touch OpenMandriva in the future.

The memory leaks section just feels like an introduction to smart pointers as though they're some complex concept. Also, the page is showing its age by mentioning the now-removed auto_ptr instead of something like unique_ptr.

Anyway, scrolling down a little more:

Why can't I assign a vector<Apple*> to a vector<Fruit*>?

This actually comes up in C# with arrays. Copying their example here:

object[] array = new String[10];
// The following statement produces a run-time exception.
// array[0] = 10;

It may have been a design mistake not to make C#'s arrays invariant, though I don't know the state of that debate today.

By which I mean maybe the author enjoys different parts of coding than you do.

It seems to me like the part of coding the author enjoys least is coding.

Trying to wrangle AI into writing something decent is generally an exercise in frustration for me.

This is my issue with it. The output of these tools, unchecked, evolves into something abysmal over time. I find it quicker to just rewrite the output than to try to prompt it over and over again to produce something good.

Rust would be more efficient. Hand written assembly would be more efficient. Using butterflies to manually flip bits in the memory would be more efficient.

OP wanted to use Python. It's not a very large program. It really doesn't matter.

The high-level directory structure looks reasonable, but every language and build tool has its own recommended structure that people should use instead. For example, by default, cargo looks for a src/main.rs or src/lib.rs as an entrypoint. uv expects one of a couple different project structures before you need to touch the pyproject.toml. C# will create namespaces for each of these nested subdirectories if you don't carefully configure it in your .csproj file. And so on.

It's best to just use whatever's recommended for your environment by your tools. Maybe this directory structure works well for Guile Scheme, but I wouldn't touch it at all if I were writing Rust.

I agree, this makes the most sense. I was under the assumption they wanted to keep it as a String, but your suggestion is a better way to approach the problem if they're able to do that.

I was able to turn the string into a char iterator, but I could not figure out how to change elements of said iterator (this can be seen at line 55).

You have a few options here, but the easiest is to collect into a Vec<char>, replace the character there, then do a String::from_iter(chars) to get it back as a string.

You can also manipulate the original chars iterator directly through takes, skips, and so on and collect it into a string, but that's more complicated.

Also, "character" is such a complicated concept because unicode is not simple. If you can work directly with bytes though, you can convert the string to a Vec<u8> (which is the underlying type for String), manipulate that directly, then do String::from_utf8 (or the same method for str) to convert it back to a string.

What happens when you import an library written in another language, and one of the functions is a reserved keyword in your language?

This is already possible in Rust. You can import libraries written with different editions, and there are different reserved keywords across editions.

The compiler just looks at what language the library was written in and switches internally based on that.

In my C and C++ example, you'd pass different flags for that library during build time, although I'm not sure how this would work for header-only libraries.

Edit: I see your reserved keywords example is an issue, and I raise you raw identifiers (r#if in Rust, @if in C#, etc)

How would collaboration between people with different native languages work?

Same way it currently does? It's not like everyone who writes code knows English, but somehow they can all write it despite the keywords being in English.

Who makes sure all language variant have equally good educational resources?

The community around that programming language would be responsible for this, would it not? This is already a thing people do, though it's impossible to translate all educational resources that exist into all languages. Fortunately we have services that can translate things for us though.

There's a reason why lingua francas change over time but always exist, and forgetting that will do more harm than good.

It would do no harm here. People already write code in many languages. In most popular programming languages, you can already name things in Korean, French, Russian, and so on. Documentation for the languages exist already in all those languages. There is literally only one thing that would change: the keywords. It's really not that complicated.

This might seem like an obvious question, but wouldn't it be more effective for the README to be in Korean? Not that having it in English too is a bad thing, but people interested in a language with Korean keywords probably can read Korean more comfortably than English (if they can read English at all).

Anyway, I don't really see why PLs that support UTF-8 idents can't just reserve multiple aliases in different languages for their keywords. Rust is mentioned here, so I'll use that as an example, but Rust could just add a language field to Cargo.toml next to edition that defaults to English (which is what Rust currently uses), and that wouldn't even need a new edition as far as I'm aware. C# could do a field in the csproj file, C and C++ can use compiler flags, and so on.

Fatal Push at home, and probably still good enough to play in some formats.

They wanted to be extra sure you'd never use Ajani's last ability.

Hopefully. I think normally people use paper to track stuff like this though, and it's always a bit annoying if you don't have a notepad with you.

As far as I can tell, if you counter these champions, the exiled card never returns. That seems pretty rough to me.

Not super easy, actually. It gives your other creatures that ward as well, so losing 10% of your life every time you target something against a red deck adds up.

Nowhere to run is legal though, so hopefully that can counter it if it becomes a problem.

I really don't get what WOTC is doing with front side's first loyalty ability. To be clear, I don't dislike what it does. What I dislike is that there's no built-in tool to track the effect on that creature.

By comparison, Kaya the Inexorable's first loyalty ability is

+1: Put a ghostform counter on up to one target nontoken creature. It gains “When this creature dies or is put into exile, return it to its owner’s hand and create a 1/1 white Spirit creature token with flying.”

Notably, with this ability, the ghostform counter does nothing mechanically. Whether the creature gets the counter at all or gets multiple doesn't matter. It's only used to track that the creature also gains that additional ability.

They could have easily done something like this with Oko. For "until end of turn" abilities, it doesn't matter that much since you don't need to track it anymore after cleanup, but for permanent abilities, it can be easy to forget in a few turns which creatures you've used the ability on.

One other card that works like this mechanically is Chance for Glory, but this is what that card says:

Creatures you control gain indestructible. Take an extra turn after this one. At the beginning of that turn’s end step, you lose the game.

Despite that the creatures permanently become indestructible, the game is intended to end on your next turn, so you shouldn't need to track it for long. (Yes there are always exceptions but the intended use of the card means you don't have to track it for long.)

Great reprint! I wonder how much it'll do in standard.

TLDR: data is something you collect over time from users, so you shouldn't let the contracts for it mindlessly drift, or you might render old data unusable. Keeping those contracts in one place helps keep them organized.

But that explanation sucks if you're actually five, so I asked ChatGPT to do that explanation for you since that would be hard for me to do:

Here’s a super-simple, “explain it like I’m 5” version of what that idea is trying to say:

🧠 Imagine your toys

You have a bunch of toys in your room — cars, blocks, stuffed animals.

Now imagine this:

• You put some cars in the toybox.

• You leave other cars on the floor in another place.

• You keep some blocks in a bucket… and some blocks on the shelf.

• And every time you want a toy, you have to run to a different spot to find its matching pieces.

That would be really confusing and hard to play with, right? Because things are spread out in too many places for no good reason.

🚧 What the blog is really warning about

In software (computer programs), “state” is like where toys are stored — it’s important information the program keeps track of. For example, it could be “what level I’m on in a game” or “what’s in my cart when I shop online.”

The article says the biggest mistake in software architecture is:

Moving that important stuff around too much or putting it in too many places when you don’t need to.

That makes the program really hard to understand and work with, just like your toys would be if they were scattered all over the place. (programming.dev)

🎯 Why that matters

If the important stuff is all over the place:

• People get confused.

• It’s harder to fix mistakes.

• The program gets slower and more complicated for no reason.

So the lesson is:

👉 Keep the important information in simple, predictable places, and don’t spread it around unless you really need to. (programming.dev)

The never type comes more from type theory and isn't common in other languages (though TS has never). Similar to 0 or the null set, it exists as a "base case" for types. For example, where you have unions of T1 | T2 | ..., the "empty union" is the never type. Similarly, for set theory, a union of no sets is the null set, and in algebra, the summation of no numbers is 0.

In practice, because it can't be constructed, it can be used in unique ways. These properties happen to be super useful in niche places.

Because if it never returns, then it has no return value.

Then how would you annotate having no return value?