In short: Goja is an ES5 interpreter written in pure Go and seamlessly integrating with it. You pass a struct, the JS side receives an object, you update it, and the Go side seamlessly gets an updated struct. No cgo overhead.
Calling a C function with Cgo has a certain overhead if you compare it to calling a Go function. But cgo overheads are completely negligible as soon as the function does any kind of real work. (A bigger reason to avoid cgo would be if you want easier cross-compilation.)
cgo execution overhead is a nothingburger, but the programmer overhead to convert between Go types and C->Javascript types, and vice versa, as required by the use of a third-party engine (v8, etc.) is still significant as compared to what Goja offers. That is what the parent is talking about.
It's definitely cool, and and accomplishment. I think it's a bit strange to compare it to "no cgo overhead" though
I say that because it's an interpreter rather than a jit, and doesn't have nearly as many person hours put into it as v8.
I can see the argument that if you just need to evaluate a quick expression or maybe some user supplied script or something, it could be very handy, but I have a hard time believing that the cgo overhead is a factor when using cgo to invoke v8 compared to the parse/jit overhead that v8 will do.
This is all armchair speculation of course. I use go regularly, but have no taste for javascript, so I have no dogs in that race. Definitely cool that there's an interpreter focused on correctness though.
Comments
In short: Goja is an ES5 interpreter written in pure Go and seamlessly integrating with it. You pass a struct, the JS side receives an object, you update it, and the Go side seamlessly gets an updated struct. No cgo overhead.
Calling a C function with Cgo has a certain overhead if you compare it to calling a Go function. But cgo overheads are completely negligible as soon as the function does any kind of real work. (A bigger reason to avoid cgo would be if you want easier cross-compilation.)
cgo execution overhead is a nothingburger, but the programmer overhead to convert between Go types and C->Javascript types, and vice versa, as required by the use of a third-party engine (v8, etc.) is still significant as compared to what Goja offers. That is what the parent is talking about.
It's definitely cool, and and accomplishment. I think it's a bit strange to compare it to "no cgo overhead" though
I say that because it's an interpreter rather than a jit, and doesn't have nearly as many person hours put into it as v8.
I can see the argument that if you just need to evaluate a quick expression or maybe some user supplied script or something, it could be very handy, but I have a hard time believing that the cgo overhead is a factor when using cgo to invoke v8 compared to the parse/jit overhead that v8 will do.
This is all armchair speculation of course. I use go regularly, but have no taste for javascript, so I have no dogs in that race. Definitely cool that there's an interpreter focused on correctness though.