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
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.
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
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.
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).
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
> 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?
"Rocks" is most commonly used in the context of (rock) music. A statement like "<insert band> rocks!" usually indicates that someone enjoys said band. But what makes you think it also means that they see other bands as now being inferior in some way?
As far as I can tell, most people who find a band that "rocks" also enjoy other bands as well, often even more, and are not looking for some kind of a battle of the bands to find the one true band that they will only ever listen to again. It is quite possible, and typical, for (rock) music fans to enjoy many bands.
You are right that words mean only what the speaker/author intends for them to mean, but in common usage there is nothing to suggest that "rocks" implies something is better than something else. It only suggests something in the vein of "I enjoy this". Besides, we know what the author meant as he has told us.
Even we were to agree that the title is poorly written, we know from other context that there isn't a programming language competition. This single title wouldn't suddenly make us think that there is one. So where has the idea that there is one coming from?
>> "Rocks" is most commonly used in the context of (rock) music
False.
>> we know from other context that there isn't a programming language competition.
I would have expected at least one comparison to another programming language. Like "COBOL" was a real pain for this, but "Go rocks".
>> ... other stuff ...
Yeah, I don't really care one way or the other. If people want say that everything in space and time are completely undifferentiated and therefore "rock" equally, I don't really care. Rock on.
Nobody does. Why would they? It isn't like there is a competition or something.
> If people want say that everything in space and time are completely undifferentiated and therefore "rock" equally, I don't really care.
Many things having the potential to "rock" does not imply that everything "rocks" equally, or at all. I strongly suspect his attempt to write a Lua interpreter in Brainfuck would not "rock".
Let's see if we can break HN nesting algo with this thread.
>> Many things having the potential to "rock" does not imply that everything "rocks" equally, or at all
That isn't what I am suggesting. I am saying that I do not care if people use the word "rocks" to describe an impossibly spherical marble rolling on an impossibly flat surface - equal across all space and time. Or, to describe, something that is uniquely better than all others. Use the term as you see fit. Use it to describe the value 4.532341 +/- 0.00001345 if you like.
As the author of the article, I'll say that my intent was to share the good time I had writing a Lua interpreter in Go. Other folks in the thread are right: more than one thing in this world can rock. :)
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.
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. :)
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.
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.
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.
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.
Go 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.
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
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.
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
Didn't MSFT also fire the lead engineer for this project shortly after?
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.
Sorry, who got fired?
He means probably Ron Buckton: https://xcancel.com/rbuckton/status/1922364558426911039
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
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).
> 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.
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
> 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?
Usually when something "rocks" it is better than other things in some way. I guess it can mean anything though.
"Rocks" is most commonly used in the context of (rock) music. A statement like "<insert band> rocks!" usually indicates that someone enjoys said band. But what makes you think it also means that they see other bands as now being inferior in some way?
As far as I can tell, most people who find a band that "rocks" also enjoy other bands as well, often even more, and are not looking for some kind of a battle of the bands to find the one true band that they will only ever listen to again. It is quite possible, and typical, for (rock) music fans to enjoy many bands.
You are right that words mean only what the speaker/author intends for them to mean, but in common usage there is nothing to suggest that "rocks" implies something is better than something else. It only suggests something in the vein of "I enjoy this". Besides, we know what the author meant as he has told us.
Even we were to agree that the title is poorly written, we know from other context that there isn't a programming language competition. This single title wouldn't suddenly make us think that there is one. So where has the idea that there is one coming from?
>> "Rocks" is most commonly used in the context of (rock) music
False.
>> we know from other context that there isn't a programming language competition.
I would have expected at least one comparison to another programming language. Like "COBOL" was a real pain for this, but "Go rocks".
>> ... other stuff ...
Yeah, I don't really care one way or the other. If people want say that everything in space and time are completely undifferentiated and therefore "rock" equally, I don't really care. Rock on.
> I don't really care one way or the other.
Nobody does. Why would they? It isn't like there is a competition or something.
> If people want say that everything in space and time are completely undifferentiated and therefore "rock" equally, I don't really care.
Many things having the potential to "rock" does not imply that everything "rocks" equally, or at all. I strongly suspect his attempt to write a Lua interpreter in Brainfuck would not "rock".
Let's see if we can break HN nesting algo with this thread.
>> Many things having the potential to "rock" does not imply that everything "rocks" equally, or at all
That isn't what I am suggesting. I am saying that I do not care if people use the word "rocks" to describe an impossibly spherical marble rolling on an impossibly flat surface - equal across all space and time. Or, to describe, something that is uniquely better than all others. Use the term as you see fit. Use it to describe the value 4.532341 +/- 0.00001345 if you like.
> Use the term as you see fit.
Obviously. But you already suggested that in your first comment. For someone who claims to not care...
As the author of the article, I'll say that my intent was to share the good time I had writing a Lua interpreter in Go. Other folks in the thread are right: more than one thing in this world can rock. :)
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.
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.)
This is exactly the part I got hung up on, too.
I'm intrigued because presumably the shortcomings of the other implementations are important to how they chose to implement Lua here.It's for zb, a Bazel-inspired build system that uses Lua instead of Starlark (stripped down python).
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
From the article:
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.
I'm surprised there was no mention of implementing Lua's coroutines via Go's goroutines.
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.
tfw you learn lua so you can build robots on minecraft
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.
Not that it's terribly important, but in the Lua circles, the reference implementation is usually referred to as PUC-Rio Lua.
Thanks for letting me know! I've updated the blog post to reflect that terminology.
Oh, you’re welcome! I didn’t think the author would read this comment. Cool software!
It was mostly funded by Petrobras in Brazil.
Go rocks for pretty much everything
Go 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.
Is it just me or is Go/Rust proseltyzing on HN kind of getting ridiculous?