9 ms·

Umka: A statically typed embeddable scripting language

68 points by mr_ms 4y ago

latchkey 4y ago
This is great as a research project, but if I needed something like this to be embedded in an existing project, I'd just go with Yaegi [1] instead of going with something that is similar to golang, but not. Having all the golang ecosystem and tooling is a huge advantage as well. [1] https://github.com/traefik/yaegi https://github.com/traefik/yaegi
- rad_gruchalski 4y ago
  Yaegi needs to be embedded in another golang program. It’s a golang module to evaluate golang. Which is cool, but different from what Umka seems to be. Umka is a scripting language with syntax inspired by golang. A language with its own vm that you can embed anywhere, exsmple: https://github.com/vtereshkov/umka-lang/blob/master/examples/3dcam/3dcam.c https://github.com/vtereshkov/umka-lang/blob/master/examples.... Yaegi and Umka are two different things. Edit: of course you can have a golang program that uses yaegi to execute your arbitrary script, and call into it this msin program from C. But how effective is it?
  - eatonphil 4y ago
    > Yaegi and Umka are two different things. From the looks of it not really. They're language implementations designed for embedded use. The only difference in design is that Umka is in C and Yaegi is in Go. But yes it's true that it's easier to call into C libraries than it is to call into Go libraries. But you can call into Go libraries from other languages.
    - rad_gruchalski 4y ago
      > But you can call into Go libraries from other languages. Yes. But it’s far from “embedded”. You can compile golang to a shared library. But that’s still far from “embedded”. Hence my question: how practical is it, really.
  - latchkey 4y ago
    Yaegi has a cli and repl [1]. [1] https://github.com/traefik/yaegi#as-a-command-line-interpreter https://github.com/traefik/yaegi#as-a-command-line-interpret...
    - rad_gruchalski 4y ago
      Yes. And? It’s not like you’d embed that in a C program. Yaegi was built with a very narrow use case: golang plugins for Traefik proxy. It’s a golang library for evaluating golang code. That’s it. You can go through the hoops of calling from C into a golang program that then evals some other golang code via Yaegi but that’s probably not going to be the most efficient way of doing it and it’s far from embedded. So yeah, if you have an existing golang program and needs scripts with everything what golang offers, go for Yaegi. Umka solves a different problem.
      - latchkey 4y ago
        > Umka solves a different problem. And my point is that I don't get what problem a golang-like language that can be called from c solves exactly. Why not just write the code in c? If you aren't going to write in c, then you might as well write in golang or rust or some other higher level language that has a whole suite of tooling, supporting libraries, documentation, community and ide support. If the end benefit is just some scripting language... heck... what's wrong with a system() call to bash? Like I said, neat research project, but if I came into a company to work on a project and this was tossed in my lap, I'd probably walk away.
        mr_ms 4y ago
        Tophat[1] is a game engine using umka for scripting. This means all the performance critical parts are written in c, but game scripts are made in umka for simplicity and less crashes. A lot of game engines do that (godot, löve). Embedded programming languages can also be used for user made scripts. Either in games as a form of modding or in other software (see blender and its use of python). [1] https://th.mrms.cz https://th.mrms.cz
        4y ago
- mr_ms 4y ago
  > Having all the golang ecosystem and tooling is a huge advantage as well. I can see that as currently the umka tooling is pretty lacking.
- socialdemocrat 4y ago
  Thanks for mentioning this. This does in fact look a lot more interesting to me. As a huge fan of REPL environments, I have been looking for a way to do this in Go, so I can more easily explore and try out things.
0des 4y ago
Wow this is pretty cool :) I like how many screenshots and samples are included in the Readme. I can't wait to try this out.
mike_hock 4y ago
Is it easily sandboxable, i.e. can you block or virtualize any file system and other non-memory resource access?
- vtereshkov 4y ago
  Umka has a limited support for sandboxing, i.e., you can block the file system and disable executing native code from external libraries.
credit_guy 4y ago
The performance benchmark is extremely underwhelming. Multiplication of 2 400x400 matrices takes about 25 seconds, compared to more than 50 seconds for Python. But in Python everybody uses numpy to multiply matrices, and at this size the runtime is less than 1 millisecond on any recent CPU.
- IshKebab 4y ago
  Sure but using numpy is not really Python anymore - at that point you'd be comparing to C, not Python. Anyway I think the benchmark is underwhelming for a different reason - Python is extremely slow so beating it surely isn't that Impressive? I guess on the other hand... one guy has made a faster language than one made by an entire army of Python developers.
  - agoose77 4y ago
    Eh, but Python isn't designed to be fast. In fact, you might say Python is designed to be slow (it's not, but that's a fun way to look at it) because it does so much. If you don't want to have the kind of runtime flexibility that Python has, then arguably you should have better performance to show for it - Python is planning on finding ~40% speed ups in the coming year. That said, I don't know what the goals of this language are, and bluntly, perf isn't everything ;)
    - vtereshkov 4y ago
      > 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.
  - vtereshkov 4y ago
    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.

68 points by mr_ms 4y ago

This is great as a research project, but if I needed something like this to be embedded in an existing project, I'd just go with Yaegi [1] instead of going with something that is similar to golang, but not. Having all the golang ecosystem and tooling is a huge advantage as well. [1] https://github.com/traefik/yaegi https://github.com/traefik/yaegi

rad_gruchalski 4y ago
Yaegi needs to be embedded in another golang program. It’s a golang module to evaluate golang. Which is cool, but different from what Umka seems to be. Umka is a scripting language with syntax inspired by golang. A language with its own vm that you can embed anywhere, exsmple: https://github.com/vtereshkov/umka-lang/blob/master/examples/3dcam/3dcam.c https://github.com/vtereshkov/umka-lang/blob/master/examples.... Yaegi and Umka are two different things. Edit: of course you can have a golang program that uses yaegi to execute your arbitrary script, and call into it this msin program from C. But how effective is it?
- eatonphil 4y ago
  > Yaegi and Umka are two different things. From the looks of it not really. They're language implementations designed for embedded use. The only difference in design is that Umka is in C and Yaegi is in Go. But yes it's true that it's easier to call into C libraries than it is to call into Go libraries. But you can call into Go libraries from other languages.
  - rad_gruchalski 4y ago
    > But you can call into Go libraries from other languages. Yes. But it’s far from “embedded”. You can compile golang to a shared library. But that’s still far from “embedded”. Hence my question: how practical is it, really.
- latchkey 4y ago
  Yaegi has a cli and repl [1]. [1] https://github.com/traefik/yaegi#as-a-command-line-interpreter https://github.com/traefik/yaegi#as-a-command-line-interpret...
  - rad_gruchalski 4y ago
    Yes. And? It’s not like you’d embed that in a C program. Yaegi was built with a very narrow use case: golang plugins for Traefik proxy. It’s a golang library for evaluating golang code. That’s it. You can go through the hoops of calling from C into a golang program that then evals some other golang code via Yaegi but that’s probably not going to be the most efficient way of doing it and it’s far from embedded. So yeah, if you have an existing golang program and needs scripts with everything what golang offers, go for Yaegi. Umka solves a different problem.
    - latchkey 4y ago
      > Umka solves a different problem. And my point is that I don't get what problem a golang-like language that can be called from c solves exactly. Why not just write the code in c? If you aren't going to write in c, then you might as well write in golang or rust or some other higher level language that has a whole suite of tooling, supporting libraries, documentation, community and ide support. If the end benefit is just some scripting language... heck... what's wrong with a system() call to bash? Like I said, neat research project, but if I came into a company to work on a project and this was tossed in my lap, I'd probably walk away.
      - mr_ms 4y ago
        Tophat[1] is a game engine using umka for scripting. This means all the performance critical parts are written in c, but game scripts are made in umka for simplicity and less crashes. A lot of game engines do that (godot, löve). Embedded programming languages can also be used for user made scripts. Either in games as a form of modding or in other software (see blender and its use of python). [1] https://th.mrms.cz https://th.mrms.cz
      - 4y ago
mr_ms 4y ago
> Having all the golang ecosystem and tooling is a huge advantage as well. I can see that as currently the umka tooling is pretty lacking.
socialdemocrat 4y ago
Thanks for mentioning this. This does in fact look a lot more interesting to me. As a huge fan of REPL environments, I have been looking for a way to do this in Go, so I can more easily explore and try out things.

0des 4y ago

Wow this is pretty cool :) I like how many screenshots and samples are included in the Readme. I can't wait to try this out.

mike_hock 4y ago

Is it easily sandboxable, i.e. can you block or virtualize any file system and other non-memory resource access?

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

credit_guy 4y ago

The performance benchmark is extremely underwhelming. Multiplication of 2 400x400 matrices takes about 25 seconds, compared to more than 50 seconds for Python. But in Python everybody uses numpy to multiply matrices, and at this size the runtime is less than 1 millisecond on any recent CPU.

IshKebab 4y ago
Sure but using numpy is not really Python anymore - at that point you'd be comparing to C, not Python. Anyway I think the benchmark is underwhelming for a different reason - Python is extremely slow so beating it surely isn't that Impressive? I guess on the other hand... one guy has made a faster language than one made by an entire army of Python developers.
- agoose77 4y ago
  Eh, but Python isn't designed to be fast. In fact, you might say Python is designed to be slow (it's not, but that's a fun way to look at it) because it does so much. If you don't want to have the kind of runtime flexibility that Python has, then arguably you should have better performance to show for it - Python is planning on finding ~40% speed ups in the coming year. That said, I don't know what the goals of this language are, and bluntly, perf isn't everything ;)
  - vtereshkov 4y ago
    > 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.
- vtereshkov 4y ago
  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.