
Golua – A Lua 5.3 engine implemented in Go - grey-area
https://github.com/Azure/golua
======
azinman2
Amazing. Microsoft releases an open source implementation of a Lua VM written
in Go. I feel like I’m in the twilight zone!

~~~
pjmlp
Microsoft is also responsible for Go's support on VSCode.

And they just released an Azure Go SDK earlier this year.

~~~
delusional
Both of which make sense, as they're integrations to other Microsoft owned and
operated platforms.

How go and lua fit into their product line I'm less sure of.

------
drej
In case you are wondering why this exists, there is a discussion here:
[https://github.com/Azure/golua/issues/36](https://github.com/Azure/golua/issues/36)

~~~
wahern
> The VM is designed differently (I'm encouraging Brian to write a blog post
> about this), but in a nutshell it is designed for better error handling and
> for adding a debugger

Looking at the VM, they implement function calls by recursively re-entering
the VM in Go. The VM implements neither tail calls nor coroutines, and I don't
see how they could implement the latter without some serious refactoring.

Perhaps by adding a debugger they mean they implemented the VM such that they
could repurpose existing Go debuggers, which is why there's a 1:1 mapping
between the Lua call chain and the Go runtime call chain.

~~~
mfer
This was open sourced very early. It is being built with the intent of
supporting Helm v3 and by open sourcing it early it enables other Helm
maintainers to get involved and to import it into Helm v3 early.

I expect more docs, details, and improvements will be coming

~~~
wereHamster
You mean this helm: [https://helm.sh](https://helm.sh)?

------
skybrian
Based on my experience porting Wren's interpreter to Go, I would expect this
to be about 3x slower than a C interpreter (without JIT). But someday I hope
to be pleasantly surprised.

I don't believe Go has been optimized for compiling an interpreter, so perhaps
there is low-hanging fruit, should the Go team decide that it's a priority.

~~~
sephware
Go was originally intended as a systems level language, suitable for writing
extremely efficient servers, dealing directly with raw bytes where needed,
therefore enabling writing code at both high and low levels. VMs typically
take advantage of the lowest level of code that their language supports to be
as efficient as possible. There's no reason Go code can't be as fast as C++
code with enough time for optimizations, and there's no reason a VM written in
Go has to be slower than any other low-level program written in Go.

~~~
stcredzero
Go's native GC is specifically targeted for Go. To be performant, one would
want GC targeted towards the language to be implemented.

~~~
sephware
Only if you're using Go's native GC as the Lua VM's GC, which isn't the only
option.

~~~
stcredzero
I have to confess, I've been thinking of implementing Smalltalk in Go, using
its native GC as a very unoptimized GC.

------
Rapzid
I wonder what sort of VM monitoring will be available. Something that was
interesting with HekaD's lua integration was the ability to monitor CPU usage
and evict bad actors. Can it see and perhaps even limit?

This was something I was wondering about with Cloudflares isolate
implementation as well. I read that in node/v8 you can inspect an isolates CPU
usage, but no way to limit it apparently? If you start out with 1/2 of a CPU
but your program gets squeezed down to 1/1000 as more isolates are added or
existing isolates use more time you could be in for a big surprise as your
program no longer performs adequately, perhaps to the point of not functioning
properly at all.

~~~
mrkurt
Isolates are limited to a single thread. There's no built in way to throttle
an isolate's CPU usage, but you _can_ manage the thread it belongs to. Which
means isolates aren't inherently worse for CPU contention than processes would
be, you just need to roll your own throttling instead of using something like
cgroups.

------
swah
Funny that luac is called:

[https://github.com/Azure/golua/blob/24b0595f74412f2f249fbdb3...](https://github.com/Azure/golua/blob/24b0595f74412f2f249fbdb38bb5efa2c349a07e/lua/state.go#L332)

Isn't this a pure Go implementation?

~~~
sdfpoi8g98sd
You should read the source you are linking to instead of being needlessly
snarky.

The function you call emits IR, and it's doc block says:

    
    
        // EmitIR compiles the Lua script similarly to Compile but instead
        // uses the long listing options to capture the compiled IR dump.
        // EmitIR returns the Lua bytecode encoded as a string or any error.

------
mitchtbaum
Rust has good bindings for PUC Lua, but this looks like it could have several
advantages over Rio's runtime. I did a quick search for any Rust bindings to
Go libraries but haven't found any yet. I opened an issue in rlua to discuss
bindings to golua, even though that would definitely be a separate project,
but we have discussed there before other Lua runtimes. If anyone else is
interested in using this library in Rust, here are those issues:

[https://github.com/kyren/rlua/issues/100](https://github.com/kyren/rlua/issues/100)

[https://github.com/kyren/rlua/issues/39](https://github.com/kyren/rlua/issues/39)

Edits.. Resources found so far:

[https://users.rust-lang.org/t/can-rust-interface-with-go-
lib...](https://users.rust-lang.org/t/can-rust-interface-with-go-
libraries/4292/3)

[https://medium.com/learning-the-go-programming-
language/call...](https://medium.com/learning-the-go-programming-
language/calling-go-functions-from-other-languages-4c7d8bcc69bf)

[https://github.com/softprops/shiplift](https://github.com/softprops/shiplift)
(okay, here's a Rust interface to Go)

~~~
mitchtbaum
shiplift uses an API. Looks like calling Go from Rust is never done. I would
guess because of the huge performance hit at 3 orders of magnitude worse than
C (according to the users.rust-lang link above). Will still be interesting to
see how Golua impacts the wider Lua ecosystem.

------
mysti
May I point at my own implementation:
[https://github.com/arnodel/golua](https://github.com/arnodel/golua)

------
firdak
Would this allow Lua code to directly use Goroutines, and take advantage of
Go's features for concurrency and parallelism?

I'd love to see a high-level language like Lua (or Python, Ruby etc.) with
good threading support. Building a language runtime in Go might be a good way
to get that support more easily?

While I'm wishing for things, could I have good single-threaded performance
too? This would likely need a JIT, which unfortunately doesn't seem possible
in Go at the moment [0].

Maybe I should give up on my desire for a high-level language and just use Go
itself, where concurrency, parallelism and good performance are all available
today...

[0]
[https://github.com/golang/go/issues/20123](https://github.com/golang/go/issues/20123)

~~~
bjoli
You have various lisps at your disposal, with my favourite Guile offering a
full working Concurrent ML implementation instead of the almost-CML offered by
Go.

------
rcarmo
This is great, since I've been meaning to do some stuff in Lua instead of
JavaScript (mostly Functions-like stuff that require simple scripting). Having
more options is always nice.

~~~
swah
There are a couple other Lua implementations in Go that exist for a few years
though...

------
ksec
It is interesting to think of Go as a C replacement, and both CLua and CRuby
gets an implementation in go. [1]

Are we going to see GoPython and GoJS?

[1] [https://github.com/goby-lang/goby](https://github.com/goby-lang/goby)

~~~
jimsmart
There is also already a Python-implemented-in-Go[1] and a Python-to-Go
transpiler[2] — albeit both somewhat limited.

[1] [https://github.com/go-python/gpython](https://github.com/go-
python/gpython)

[2] [https://github.com/google/grumpy](https://github.com/google/grumpy)

------
charlieAutomata
Does anyone know of any example code anywhere? I can't seem to find any public
examples of someone embedding/using this.

Edit: seems there is an open issues for adding some of this
[https://github.com/Azure/golua/issues/15](https://github.com/Azure/golua/issues/15)

~~~
mfer
It was quietly open sourced earlier this week at an early state so we could
start looking at importing it into something else
([https://helm.sh](https://helm.sh) v3). You likely will not find any
examples, yet. It's not release quality quite yet so there will likely be
changes as it becomes production quality.

I'm amazed people found this already. The team over there who owns this is
excellent. I expect it to work nicely once they have had a little time to get
everything together.

------
crawdog
Heres an old project I wrote with some sample code for the C binding library.
I tried the go versions and always found the c binding faster.

[https://github.com/rickcrawford/go-lua-
test](https://github.com/rickcrawford/go-lua-test)

------
znpy
I see that contribution is guarded by CLA agreement. I often wonder: if I
don't want to sign a CLA, couldn't I just fork the whole repository and keep
going on my own?

~~~
colonelxc
Yes you can. The restriction is on what can be put into this "upstream"
version.

------
bhengaij
I don't want to be "that guy" but I think its a valid question to ask- why
didn't they write this in ... ... .... Rust?

I think go and rust serve two somewhat different use cases- go being for
distributed computing in a nutshell, and rust for fast running programs. And I
think Rust would have been a better choice

Edit: looks like everybody and their dog has a Lua engine now- maybe I'll
create one in rust

~~~
zzzcpan
I think you got it backwards. Go is good for toy-interpreters, compilers,
programming languages in general. Pretty bad for distributed computing though,
Rust is definitely better for that use case if your only choices are Rust and
Go.

~~~
monocasa
Rust's type system is derived from the ML variants, and as such is fantastic
for writing compilers and interpreters. ML stands for "meta language", ie.
it's named after how good it is at writing compilers in.

~~~
pjmlp
Kind of, I prefer the productivity I get from the GC in ML language variants.

Having done some compiler related work back when we had Caml Light, OCaml was
still called Objective Caml and Mirada was being turned into Haskell, I don't
see what I would gain from having to deal with the borrow checker.

~~~
monocasa
You don't really gain anything from the borrow checker in this case, but you
don't really lose anything either if you're used to it.

It's the ADTs that are killer compared to Go.

~~~
pjmlp
Yeah, but then why Rust and not another ML variant?

~~~
monocasa
The discussion here is between Rust & Go. My point is swaping the GC for the
borrow checker in order to get ADTs is a net win to me.

If we're veering off into hypotheticals that don't have anything to do with
the question at hand, I personally write compilers and interpreters in Rust
rarher than another ML because my use cases tend to be worst case latency
sensitive enough that a GC is a non starter.

~~~
pjmlp
Fair enough, thanks for replying.

