|
|
|
|
|
by latchkey
1470 days 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. |
|
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.