umka-lang VS yaegi

I'm a fan or Umka. It is inspired by Go and can be embedded into C programs.

https://github.com/vtereshkov/umka-lang

My scripting language Umka now supports closures. This is not merely a matter of fashion, but the requirement of the Tophat game engine that heavily relies on callbacks, particularly for inter-module communication via signals.

After three years of development, I released Umka 1.0, a statically typed scripting language designed for embedding into C/C++ host applications. Its syntax and some key features were inspired by Go. However, Umka doesn't rely on the Go ecosystem and only needs the C standard library to run.

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....

Yaegi and Umka are two different things.

UmPlot 0.1 has been released. It is an easy-to-use cross-platform plotting library for the Umka language. It is based on raylib and distributed as an Umka Module Implementation (UMI) file, i. e. a language extension shared library with an Umka interface.

Some people who tried to use the Umka scripting language were frustrated by the absence of closures. This feature is under development and not yet released. However, you can easily simulate closures with the good old structures, methods and interfaces. This simple truth sometimes comes as a surprise to the users.

I have been developing the statically typed scripting language Umka for more than a year. Now it is stable enough to serve as the basis for various projects: a 2D game engine, a VDrift-based framework for exercising with the car autopilot logic, and a proprietary tractor dynamics simulator.

Yes. There are long standing feature requests for (e.g.) the reflect package that simply don't get done because they'd break this assumption and/or force further indirection in hot paths to support "no code generation at runtime, ever".

Packages like Yaegi (that offers an interpreted Go REPL) have "know limitations, won't be addressed" also because of these assumptions.

https://github.com/golang/go/issues/4146

https://github.com/golang/go/issues/16522

https://github.com/traefik/yaegi?tab=readme-ov-file#limitati...

There is always https://github.com/traefik/yaegi - a Go interpreter written to make it easy to write plugins.

I think https://github.com/traefik/yaegi comes as close as using the python interpreter in you CLI, but for Go

There's a go interpreter: https://github.com/traefik/yaegi It could run programs without compiling them, but there're some limitations.

I'd recommend looking into a different approach for plugins such as hashicorp/go-plugin (which uses multiple process PIDs and RPC communication between them) or traefik/yaegi (which implements a Go-compatible scripting language that can be interpreted at runtime and which still supports most Go modules).

Why do we need a language like Rust when we have Rust. Why not just create a Rust interpreter. (There's such an interpreter for Go, BTW, https://github.com/traefik/yaegi )

A cool solution I saw was Traefik's yaegi module. They basically created an interpreted scripting language with Go compatible syntax (turning Go into an interpreted, not compiled, language). I haven't tried this but it sounds like it brings the better parts of dynamic languages like Python's plugin support to Go - plugin writers can still write "Go" code, which can load dynamically.