[HN Gopher] Why Go Rocks for Building a Lua Interpreter
___________________________________________________________________
Why Go Rocks for Building a Lua Interpreter
Author : Bogdanp
Score : 57 points
Date : 2025-06-26 05:28 UTC (3 days ago)
(HTM) web link (www.zombiezen.com)
(TXT) w3m dump (www.zombiezen.com)
| ufo wrote:
| I know the author starts the post by saying he won't explain the
| reasons why he had to write a new Lua interpreter from scratch,
| but I'm still curious about that. Does anyone know? I dug through
| some of the links in the post and couldn't find the answer.
| Lyngbakr wrote:
| This is exactly the part I got hung up on, too.
| The exact reasons aren't important for this blog post, but
| neither the reference implementation [...] nor the other open
| source Go Lua intepreters I could find were a good fit for my
| needs.
|
| I'm intrigued because presumably the shortcomings of the
| _other_ implementations are important to how they chose to
| implement Lua here.
| Scaevolus wrote:
| It's for zb, a Bazel-inspired build system that uses Lua
| instead of Starlark (stripped down python).
| mdaniel wrote:
| _Zb: An Early-Stage Build System_ -
| https://news.ycombinator.com/item?id=41595310 - Sep, 2024
| (125 comments)
|
| and the beta announcement was also recently submitted, but
| without commentary
| https://news.ycombinator.com/item?id=44290692
| shhsshs wrote:
| From the article: My Lua data types have a
| notable difference from C Lua: an ability to be "frozen".
| wavemode wrote:
| Given this is going to be used as a scripting language for a
| build system, it's possible they are trying to implement a
| restricted subset of Lua rather than than the full language.
| zombiezen wrote:
| Yup, as others have mentioned, it's for zb. I originally
| outlined some background on design goals for this blog post,
| but the outline for that section was as big as the outline for
| the rest of the post, so I cut it. I'll probably write that one
| up as another blog post in the near future. :)
|
| (Also, my pronouns are she/her.)
| jekwoooooe wrote:
| Go rocks for pretty much everything
| williamdclt wrote:
| Well done, writing interpreters is fun!
|
| I'm not really sold on why Go would be a particularly good fit
| for the task, compared to other languages. Seems to be mostly
| "interfaces are useful for interpreters, and GC means I don't
| have to care about memory management" - both of which are true
| but hardly specific to Go. There's some form of interface in
| almost every mainstream language, I think the implementation
| would be pretty much the same in any GCd language
| lopatin wrote:
| I never thought that Go would be a technology of choise for PL
| stuff. I always considered it more of a Java-lite for Web
| systems and also for CLI stuff, but here we are! TypeScript
| rewrote their compiler to Go. Being a compiler, they had no use
| of piggy backing on the GC, looks like they just liked the
| language.
| 3836293648 wrote:
| Typescript chose Go specicfically because they didn't rewrite
| it. Go has close enough semantics to TypeScript that they
| could write a Go backend for tsc and do a machine port to Go
| and continue working from that
| azemetre wrote:
| Didn't MSFT also fire the lead engineer for this project
| shortly after?
| pjmlp wrote:
| They did.
|
| Also the way the port was sold is a bit misleading,
| because as described on BUILD 2025 session, they had
| anyway to redo the whole datastructures due to the more
| basic Go's type system.
|
| Meanwhile Azure is rewriting C++ into Rust with AI
| tooling, see Microsoft talks at Rust Nation UK 2025.
| osigurdson wrote:
| Yeah. They said that there were lots of nested structures
| with cycles and so on so it would be hard to do with Rust.
| Link below.
|
| https://youtu.be/10qowKUW82U?t=762
| shadowgovt wrote:
| I used Go awhile ago for a Blockly interpreter. It's
| remarkably friendly; if memory serves, the ability to attach
| metadata to structs was pretty useful.
|
| One hack I'm not super proud of is I implemented return and
| break with panic / recover. Were I to do it all over, I'd
| probably use continuations to model that instead.
|
| (Side-note on Lua specifically: among the reasons I like Lua
| is that it's very simple and its reference interpreter
| implementation is some very understandable code. I did some
| truly horrible things to it back in the day for a game
| engine, and it was very amenable to getting beat up like
| that).
| 9rx wrote:
| _> I'm not really sold on why Go would be a particularly good
| fit for the task, compared to other languages._
|
| Can't _every_ language rock for building a Lua interpreter? It
| isn 't a competition.
| williamdclt wrote:
| I think that's re-interpretation, making the subject of the
| article about "why go rocks" shows the author thinks Go has
| something over other languages. Otherwise it's like saying
| "why orange cats are fluffy" then saying stuff that applies
| to all cats without orangeness specificity
| wavemode wrote:
| I'm surprised there was no mention of implementing Lua's
| coroutines via Go's goroutines.
| shadowgovt wrote:
| That feels not quite correct. Lua coroutines aren't separate
| threads and trying to farm them out to goroutines (which are
| separate threads) risks violating expectations you can assume
| with non-concurrent execution. With coroutines, you can fairly
| believe that your state isn't going to change when you're
| running until you yield.
| andrewmcwatters wrote:
| Not that it's terribly important, but in the Lua circles, the
| reference implementation is usually referred to as PUC-Rio Lua.
| anaempromptu wrote:
| tfw you learn lua so you can build robots on minecraft
| jhbadger wrote:
| Lua has a long history with gaming since the late 1990s. The
| LucasArts adventure game "Grim Fandango" (1998) used Lua
| internally, and more recently it seems to have become the
| standard language for "fantasy console" game development such
| as in PICO-8 and TIC-80.
| photochemsyn wrote:
| Is it just me or is Go/Rust proseltyzing on HN kind of getting
| ridiculous?
___________________________________________________________________
(page generated 2025-06-29 23:00 UTC)