Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Rocks for Building a Lua Interpreter

zombiezen.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Why Go Rocks for Building a Lua Interpreter

#11

Post by lopatin »

williamdclt wrote: post #8

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…

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.

Re: Why Go Rocks for Building a Lua Interpreter

#12

Post by 3836293648 »

lopatin wrote: post #11
williamdclt wrote: post #8

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…

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

Re: Why Go Rocks for Building a Lua Interpreter

#13

Post by [deleted] »

williamdclt wrote: post #8

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…

[deleted]

Re: Why Go Rocks for Building a Lua Interpreter

#14

Post by 9rx »

williamdclt wrote: post #8

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…

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

Re: Why Go Rocks for Building a Lua Interpreter

#15

Post by zombiezen »

ufo wrote: post #2

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

Re: Why Go Rocks for Building a Lua Interpreter

#18

Post by azemetre »

3836293648 wrote: post #12
lopatin wrote: post #11

Earlier quoted context omitted.

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?

Re: Why Go Rocks for Building a Lua Interpreter

#19

Post by pjmlp »

azemetre wrote: post #18
3836293648 wrote: post #12

Earlier quoted context omitted.

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.

Re: Why Go Rocks for Building a Lua Interpreter

#20

Post by osigurdson »

3836293648 wrote: post #12
lopatin wrote: post #11

Earlier quoted context omitted.

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

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

Post reply on HN