> That said, I don't know what the goals of this language are, and bluntly, perf isn't everything ;)

Since the most popular scripting language is Lua, I can name three big disadvantages of Lua that Umka is trying to fix:

- Verbose and unfamiliar syntax

- Type error detection at run time instead of compile time (a direct consequence of dynamic typing)

- Data structures not compatible with C (which is particularly odd, as Lua is specifically designed to interact with C)

So yes, Umka's main goals are not related to performance.

Of course, any program can be written completely in C. This, however, does not mean that it's always the best way to write programs.

Suppose you have a piece of code that you have to modify frequently until you find an acceptable solution to your problem. For example, it may be a game character behavior, or automatic vehicle control equations, or something else. If you write this piece of code in C, you have to recompile this module and link the whole project each time you modify the source. With a scripting language, you can write 90% of your code in C, and remaining 10% in this scripting language, so that you compile your C project only once. You can even hand over writing the remaining 10% to the people who are not familiar with low-level programming in C but perfectly understand the problem domain (like engineers or game designers).

Another scenario is when you want your application to be customizable by its users, but only in a controlled way and without exposing the sources.

Certainly, Python is slow. But I would say it's incorrect to compare Umka to C in terms of performance. Interpreted languages are always slower than compiled ones. The only way to close the gap is to use a JIT compiler, like LuaJIT for Lua. But such a compiler can never be portable.

Umka has a limited support for sandboxing, i.e., you can block the file system and disable executing native code from external libraries.