3 ms·

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

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
    - rad_gruchalski 4y ago
      > 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? It says in the readme. It provides scripting capabilities using a strongly-typed go-inspired language in compiled languages. You don't write the scripting code in C because C isn't a scripting language. > ... what's wrong with a system() call to bash? Okay. Because you need to fork, because you need to have permissions to fork the process you want to fork, because fork is time consuming and requires resources you might not have a lot of, because maybe there is no bash. Or on one machine there is bash, on another there isn't. Because depending on what you are going to call, you may need a whole shebang of dependencies, which may or may not exist. Because maybe you compile to tinygo and you can't use Yaegi, but then maybe wasm is a better choice. There are tons of reasons why not. > 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. It doesn't seem to solve a problem you are facing but it doesn't mean it's useless. You said multiple times that you don't understand what problem does it solve. It provides an embedded, type-safe, cross-platform, go-inspired syntax, performant scripting language. You know, Yaegi was some time ago also someone's "neat research project", albeit for a totally different use case.

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
  - rad_gruchalski 4y ago
    > 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? It says in the readme. It provides scripting capabilities using a strongly-typed go-inspired language in compiled languages. You don't write the scripting code in C because C isn't a scripting language. > ... what's wrong with a system() call to bash? Okay. Because you need to fork, because you need to have permissions to fork the process you want to fork, because fork is time consuming and requires resources you might not have a lot of, because maybe there is no bash. Or on one machine there is bash, on another there isn't. Because depending on what you are going to call, you may need a whole shebang of dependencies, which may or may not exist. Because maybe you compile to tinygo and you can't use Yaegi, but then maybe wasm is a better choice. There are tons of reasons why not. > 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. It doesn't seem to solve a problem you are facing but it doesn't mean it's useless. You said multiple times that you don't understand what problem does it solve. It provides an embedded, type-safe, cross-platform, go-inspired syntax, performant scripting language. You know, Yaegi was some time ago also someone's "neat research project", albeit for a totally different use case.