My reading of the "Developing Grumpy" section of the README [0] is that Grumpy is primarily a transpiler, and that's what `grumpc` is. It says right there it takes your Python, compiles it to Go, and then you run `go build` to build a Go executable.
The "runtime" comes in at this point. It sounds like `grumpc` compiles Python objects down to stubbed-out Go objects, which depend on the functionality implemented in grumpy for the implementation of those stubs. "The Go code generated by grumpc performs operations on data structures that represent Python objects in running Grumpy programs."
To me, this mostly sounds like a Python->Go transpiler with special hooks to more easily facilitate Pythonic access in Go. If anything, it seems to support my original point that transpilers are custom-built even more; from my high-level and probably wrong reading, it looks like instead of a full-scale Python-to-Go transpiler, Grumpy's developer realized it would just be easier to implement if he made the programs dependent on his "runtime", which he could freely do because he was running his own project on it and he can execute that project through `grumpy` just as easily as he could through anything else. Such options would probably not be available to someone who was tasked with writing a generic Python-to-Go transpiler that was expected to work anywhere that Go works.
I also could be misreading this, because again, I've never used it, and maybe by "runtime" the author really does just mean "library", and it all compiles down to a standard Go application. That'd be cool.
The "runtime" comes in at this point. It sounds like `grumpc` compiles Python objects down to stubbed-out Go objects, which depend on the functionality implemented in grumpy for the implementation of those stubs. "The Go code generated by grumpc performs operations on data structures that represent Python objects in running Grumpy programs."
To me, this mostly sounds like a Python->Go transpiler with special hooks to more easily facilitate Pythonic access in Go. If anything, it seems to support my original point that transpilers are custom-built even more; from my high-level and probably wrong reading, it looks like instead of a full-scale Python-to-Go transpiler, Grumpy's developer realized it would just be easier to implement if he made the programs dependent on his "runtime", which he could freely do because he was running his own project on it and he can execute that project through `grumpy` just as easily as he could through anything else. Such options would probably not be available to someone who was tasked with writing a generic Python-to-Go transpiler that was expected to work anywhere that Go works.
I also could be misreading this, because again, I've never used it, and maybe by "runtime" the author really does just mean "library", and it all compiles down to a standard Go application. That'd be cool.
[0] https://github.com/google/grumpy/tree/aa58aa68717f6ac2ebf40f...