Or is the point of it to be able to use existing JS scripts within a Go application?
---
Let’s set up the scenario. You have a program that a user can manage via a config file. That tune knobs and dials, and everything works. They then ask you one day, “I’d like to add some custom logic for they have.”
Do you add another option to the configuration file to support their one use case? Or provide a mechanism for them actually to write some code?
If it’s the latter, do you want them to have to recompile your program to be able to run that custom code? Or do you have a runtime in your application for that custom code?
The latter is what a browser does. You can write JavaScript for a website without recompiling the browser just for the website. The user doesn’t have to worry about your event loops, SDKs, APIs, wiring code in rust/C, etc. This feature allows others to add custom logic to your application's runtime.
This is the purpose of embedding JavaScript into an application. It’s not the whole program, but it allows someone to provide code in your program event loop to do something custom. Not every program needs this. Sometimes, a config file of YAML or command line arguments works, too.
[1] https://www.reddit.com/r/golang/comments/1d78d3j/what_script...
Thanks for opening me up to it all - it will definitely solve a problem that I'm about to start working on!
JS, or in Replicator's case, TypeScript (shout-out to esbuild), is sufficiently well-known that any dev group will have some experience with it. On the whole, I've been very impressed with how straightforward it's been to have user-scripts integrated into the processing pipeline.
And, I suppose my initial hunch is probably correct - for the dev/application to be able to use existing JS libraries (be it part of your broader application/system or external) within a Go app.
Check out my other comment [1] in this post for a newer, better version/fork of Goja - from the grafana/k6 team.
a) non-technical users describe, in plain English, what they would like from the data; b) an LLM with lots and lots of prompt-engineering massaging translates the English into JS, c) the JS gets executed in a sandbox, d) the results get returned to the user
They can be configured to mutate the data with some basic DSL syntax, but if you have more advanced needs, you can break out to JavaScript and transform the JSON any way you want.
This is very useful because now any transformation becomes possible. And because this is the user of your product who writes that JavaScript more as configuration than code. And since there's no build step, it is just part if the configuration loaded at startup.
[1] https://www.elastic.co/guide/en/beats/metricbeat/current/pro...
[0] https://github.com/robertkrimen/otto [1] https://github.com/daptin/daptin [2] https://daptin.github.io/docs/actions/actions/
I used it for game scripting. Lots of stuff is just easier to write in a high level language. I was able to use inheritance to compose behaviors for entities, and I could restart entities with new code without having to restart the server.
So, Sobek seems to be the way forward...
[1] https://github.com/grafana/sobek/
Since you're doing ETL, did you consider something like Conduit, which is written in Golang and also allows for JS processing in the pipeline? Or is that overkill for what youre doing?
https://conduit.io/docs/processors/builtin/custom.javascript
I've used Wazero myself on C++ -> WASM code but I'm sure you could use Emscripten or something to compile JavaScript to WASM.
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.
Pocketbase is the framework that makes me want to switch to golang. It just makes a lot of sense.
One thing that concerned me, though. How do I debug goja? It doesn't seem like I can set breakpoints as usual.
However, one of the strengths of pocketbase, I think, is that the creator chose to add bindings for a very well known scripting language (js) to allow projects to be rapidly developed. It feels like django rethought.
Using go for the base of your project and then gluing things together via scripting seems like a good idea. It's quite a big feature of the framework.
If you're interested in some production code with Goja, this is our code for calling RoughJS ([1]) from Go in order to produce the hand-drawn diagram look: [2]
[0] https://github.com/terrastruct/d2
[2] https://github.com/terrastruct/d2/blob/master/d2renderers/d2...
CC="zig cc -target aarch64-linux"The article makes no comparisons seemingly? I don't think there's even a never. I find that pretty odd.
I'm curious if there'd be any reason to switch.
I guess it's the Lisp Curse or something, I dunno.