I really do not understand game engine designers insistence on inventing a new language for their scripting needs. There are dozens of well built languages that can be used for simple scripting. Just pick one of those.
For example if a game engine keeps track of asset references, scripts could be themselves assets like any textures, levels, materials, etc and have asset references as literals in the code that the script compiler understands, allowing automatic and precise extraction of asset dependencies the scripts (and the assets that refer to those scripts) can have. This is, e.g. what Blueprint does (BP is just a visual scripting language that uses a graph with a visual editor instead of parsing text to generate an AST but the same idea applies).
- Fast to compile
- Fast to run
- Memory management that doesn't destroy frame times
- Easy to embed, ideally with a small runtime
- Can target whatever ISAs and OS's that the game runs on, like consoles.
There are not dozens of languages that fit these criteria, particularly memory management, embedding, and toolchain support for consoles when you're using a proper JIT compiler and not a bytecode interpreter.
I think UE is a situation where writing a new language specifically for scripting it is absolutely the correct choice. The user base will be large enough to support it properly, and there are a lot of things that are a lot more ergonomic when the language will be built to support them after the base system is already built, instead of the other way around.
I don't know much about Verse but looking at the preview I already see a type called a type called `<latent>` (async Promise?) and a `race` keyword (seems like a built-in `await Promise.all`?). I bet building these directly into the language fixes much impedance mismatch.
I strongly agree this is a superior approach to a custom language. Even better if the games industry standardized a single purpose fit scripting language
[1]: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp