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

41–50 of 61 posts

Re: Why Go Rocks for Building a Lua Interpreter

#41

Post by osigurdson »

jekwoooooe wrote: post #40
osigurdson wrote: post #29

Earlier quoted context omitted.

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.

Go 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

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

Re: Why Go Rocks for Building a Lua Interpreter

#42

Post by skybrian »

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

Re: Why Go Rocks for Building a Lua Interpreter

#43

Post by foldr »

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?

Looks like he was laid off, not fired. But so what? Layoffs have their own weird logic. It doesn’t tell us anything about how the project is perceived internally to Microsoft.

Re: Why Go Rocks for Building a Lua Interpreter

#44

Post by pjmlp »

skybrian wrote: post #42

Performance 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…

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

Re: Why Go Rocks for Building a Lua Interpreter

#46

Post by foldr »

skybrian wrote: post #42

Performance 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…

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

Re: Why Go Rocks for Building a Lua Interpreter

#47

Post by skybrian »

foldr wrote: post #46
skybrian wrote: post #42

Performance 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…

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

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

Re: Why Go Rocks for Building a Lua Interpreter

#48

Post by skybrian »

pjmlp wrote: post #44
skybrian wrote: post #42

Performance 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…

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

It’s different because Go is garbage collected. See my other reply.

Re: Why Go Rocks for Building a Lua Interpreter

#49

Post by pjmlp »

skybrian wrote: post #48
pjmlp wrote: post #44

Earlier quoted context omitted.

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

It’s different because Go is garbage collected. See my other reply.

No it is not, that is the anti-GC folks agenda since Xerox PARC days, placing all GC languages into one big basket, not learning what actually makes one specially tick, the language features available for low level coding in each programming language and such.

Just sticking to the old ways is why we don't get progress in some industry corners.

Re: Why Go Rocks for Building a Lua Interpreter

#50

Post by Jyaif »

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 mainly write code in languages without GCs so this article was very interesting to me, and the title was very fitting.
Post reply on HN