6 ms·
Why Go Rocks for Building a Lua Interpreter
- anaempromptu 1y agotfw you learn lua so you can build robots on minecraft
- jhbadger 1y agoLua 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.
- ufo 1y agoI 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 1y agoThis 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 1y agoIt's for zb, a Bazel-inspired build system that uses Lua instead of Starlark (stripped down python).
- mdaniel 1y agoZb: An Early-Stage Build System - https://news.ycombinator.com/item?id=41595310 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 https://news.ycombinator.com/item?id=44290692
- shhsshs 1y agoFrom the article: My Lua data types have a notable difference from C Lua: an ability to be “frozen”.
- wavemode 1y agoGiven 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 1y agoYup, 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 1y agoGo rocks for pretty much everything
- osigurdson 1y agoGo routines are very nice. Way better than async await nonsense in other languages. if err != nil {return .., err} gets pretty tedious however. Everything tends to be very mutable / nullable as well which could be better. Also not really any faster than Java/C# - just another GCed language.
- jekwoooooe 1y agoGo can be way faster than those. Garbage collection is not an issue at all if you write efficient code And the error handling is way better than catching stuff because it’s so explicit
- osigurdson 1y agoAgree that values are better than exceptions for error handling. It seems that it could be better though. I don't think Go is faster than C# or Java for the most part.
- pjmlp 1y agoExcept for having a modern type system.
- jekwoooooe 1y agoWhat’s missing? It has generics and robust typing. Man this website must be full of old geezers with all the go hate I see
- pjmlp 1y agoMaybe some Pascal like enumerations, something like this from 1976: type weekdays = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); DailyActivity = array weekdays of string; Instead of the ridiculous iota/const workaround. You mention generics, but actually they still are quite constrained on capabilities. Robust typing misses out on the famous gotcha with nil interfaces. The error boilerplate, but granted that isn't a typesystem issue, rather grammar and semantics. Package names tied to SCM domains, with a workaround using HTML Meta redirections when they change, and behind our back file rewrites remapping imports.
- williamdclt 1y agoWell 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
- 9rx 1y ago> 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 1y agoI 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
- 9rx 1y ago> shows the author thinks Go has something over other languages. How so? It is clearly just a story of someone's experience, not a technical evaluation of various languages. The only other language (aside from Lua) mentioned is C, and the C implementation was considered so good that it was to be the direct model for the implementation in the story, so we can assume that writing a Lua interpreter in C also rocks. > Otherwise it’s like saying “why orange cats are fluffy” Sure. That seems like a reasonably fair title for a story about your fluffy orange cat, even if other cats (and other animals, not to mention other things that aren't animals) are also fluffy. You could call it "Fluffy" instead, I suppose, but then someone would complain about the lack of details. You can never please everyone. But, regardless of how you want to interpret the title, it remains that there isn't a competition. There never has been, never will be. A poorly written title wouldn't magically create a competition. Where does the bizarre idea that there is one stemming from?
- wavemode 1y agoI'm surprised there was no mention of implementing Lua's coroutines via Go's goroutines.
- shadowgovt 1y agoThat 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 1y agoNot that it's terribly important, but in the Lua circles, the reference implementation is usually referred to as PUC-Rio Lua.
- osigurdson 1y agoIt was mostly funded by Petrobras in Brazil.
- zombiezen 1y agoThanks for letting me know! I've updated the blog post to reflect that terminology.
- andrewmcwatters 1y agoOh, you’re welcome! I didn’t think the author would read this comment. Cool software!
- photochemsyn 1y agoIs it just me or is Go/Rust proseltyzing on HN kind of getting ridiculous?
- skybrian 1y agoPerformance is scarcely mentioned. It probably doesn’t matter that much for a build system. But for projects where it does matter, you won’t get performance in the same ballpark as a Lua interpreter written in C if you use Go. In particular, because Go is memory-safe, you don’t have the control over memory layout you need to do tricks like NaN-boxing. Anything that requires a union with a pointer (which will be every value in a dynamically typed language) must be represented as a value of interface type, and interface values are quite fat - 16 bytes on a 64-bit machine. Interpreters are atypical programs to optimize. Few other programs use unions so much in their inner loop.
- foldr 1y agoYou can do raw memory access via the ‘unsafe’ package, so I don’t think it would be impossible to do NaN boxing in Go. It would be somewhat less convenient than in C.
- skybrian 1y agoUnlike C, Go is garbage collected. Hiding pointers from the garbage collector so it can’t trace them without breaking something seems tricky. There would need to be pointers to that memory somewhere else to prevent it from being collected. And then since you’ve disabled the system GC, you need to write your own GC that understands NaN boxing to find out when memory can really be freed. I see it as so awkward that it’s not worth doing.
- shadowgovt 1y agoThere are some advantages to constraining our runaway pointers to the part of the language written under the `unsafe` package, as opposed to doing the whole thing in C where we get the advantages of no language preconceptions of garbage collection getting in the way but the disadvantages of forever having to wonder whether we have vulnerabilities in the bog-standard steps like "reading from the input file."
- pjmlp 1y agoOr do it like C in the age of K&R C, and compilers ramping up for C89 compliance, with a little bit of Assembly. Most stuff people use in C for writing interpreters with optimal performance, isn't ISO C, rather C compiler specific extensions, or inline Assembly. All things being equal, same rules apply.