This is what Rust game engines need.
Some sort of sensible scripting language to do the game logic in.
Some sort of sensible scripting language to do the game logic in.
It's also a tiny codebase which is easy to vendor and ship.
Python is also a decent glue language but creating a Python interpreter is a bunch more work and the API is a bit harder to work with.
The language is _tiny_ (and kept that way on purpose)
Aside from stuff like metatables(which may require you to play around for a bit to understand their value), you can pick it up in a couple of hours. I'm not even kidding. So much so that you see people modifying code without even looking at documentation.
and yes; i know that's a ridiculous example that's not really comparable for anything significant.
Impossible. Most developers outside the games industry don't even know it exists.
... and if they knew about it, they would use it much more.
The first problem is "Which Lua?" Lua, by itself, is almost completely useless. You first need to compile/install a bunch of things in order to make Lua useful. This has the Perl problem that everybody uses a different dialect of Lua.
The second part is that the Lua constructs for programming in the large are very weak. I believe that Adobe had a postmortem about this (Lightroom, I think?)
And then there is the language, itself. For me, the 1-based indexing is death in this day and age. Sorry. Zero-based is the dominant ecosystem and not fitting into that is simply not acceptable.
How is this any different from pretty much any language out there? From a quick eyeball of RustPython's Cargo.toml[1], there are about 70 different dependencies which all need to be compiled. I haven't worked too much with Autoconf, but I am pretty sure CPython has quite a few dependencies.
[1]: https://github.com/RustPython/RustPython/blob/main/Cargo.tom...
> The second part is that the Lua constructs for programming in the large are very weak.
This is deliberate because it forces you to use the tools you are given instead of reimplementing features that can already be implemented by using other primitives in Lua.
> I believe that Adobe had a postmortem about this (Lightroom, I think?)
I can't find this article. Has anyone else had any luck?
Yeah we have mypy, but its not official and not integrated. And subsets that do have a performance benefit (like TorchScript) are niche and/or not sustainably supported.
Now all your imports, on the other hand...
Python was not the bottleneck, just the scapegoat for badly written code.
(1): e.g. awesome, blender
Furthermore tooling to work in such contexts (as a API consumer) often is very limited or does not exists, but the API producer seldomly has the time/money to produce such tooling either.
Lastly there is the remaining problem of Python by itself being really slow, for it's main use-cases this often doesn't matter as e.g. the scientific computations are run by native extensions python delegates the work, too. But this would mean that you have to also support native extensions support or hope that no extension needs to be really fast (not needing to be really fast is surprisingly often the case) or similar solutions. In turn choosing something which has a good JIT, AOT or similar compilation has benefits.
Not only did old examples often just not work, there was no serious code completion to facilitate creating anything from scratch.