It’s not that the author picked Rust for scripting. All Rust game engines (e.g. Bevy) use Rust as the scripting language.

Compare this with Godot, which is implemented in C++, but supports GDScript and many other languages for scripting.

Also, only supporting Rust is not considered a limitation, but a feature here. Bevy’s ECS is tied up with Rust’s trait system, therefore it’s impossible to use a different language.

So if Rust as a system programming language should not be used for game scripting, then projects like Bevy are fundamentally flawed. The author is willing to go there, but I don’t know if many people would go that far.

There could be a Godot-like engine written in Rust that supports easier scripting languages, but I think that space is not explored due to the fact that Godot already exists.

In general, given a Turing machine which outputs the result of a procedure to its memory tape, you can equivalently construct a recognizer of valid input/output pairs. Say P is the procedure, then the recognizer R is let (i, o) = input in P(i) = o

The reverse is also possible. Give a recognizer R, you can construct a procedure P that given part of the input (can be empty), computes the rest of the input that makes R accept the whole. It can be defined as for o in all-strings, if R(i, o) then output o and halt, else continue.

It might feel contrived at first, but both views can be useful depending on the situation. You’ll get used to it soon with some exercises.

For all possible input, only recognize the one input that’s (under certain encoding scheme) equal to the sum of the given list. That’s for a given list.

Another more general approach is that, only recognize the input if (under certain encoding), it’s a pair of a list and a number, where the number is the sum of the list.

Look, there’s a thing called safety-catch and that’s why my son can play with semi-auto rifles.

People who know monad: ???

People who don’t know monad: ???

Thank you for raising the question. I think it’s an important one to think about. I constantly hear about good things about the REPL experience of LISP family languages. You can set up a code fragment (the test in your example) to run constantly in the background as you edit. Then you can jump to the REPL anytime and interact with the state.

I myself am more on the ML-family side of FP, where you’d encode the expected behavior with an expressive type system and work with the type checker (the smart compiler) to implement that behavior.

One important thing to note is that the type checking process is also a fast feedback loop. The difference is that it’s often on the abstract level and you’re more concerned about the expected behavior instead of the actual behavior.

It’s harder to write, but the advantage is that you’ll have more confidence once it type checks.

Of course, the two styles are not mutual exclusive, just that the tooling ecosystem will often reflect the culture of that language family. And it’s easier to add a simple watch make task, but harder to go the other way around.

Take Rust as an example, composition implemented in modern languages is really a mix of both paradigms.

In the Advantages of Inheritance section, we can emulate the inheritance way by adding a IndefinitelyDoStuff type class (or interface). The type’s capability is extent by type class hierarchy and code duplication is mitigated by default implementation.

Inheritance provides a safer experience due to compile time guarantees […] the code simply doesn’t compile until you’ve updated all child classes

Similarly, adding that to the type class declaration will enforce implementation for each instance to be added at compile time.