You might be able to even compile Go as a static library and embed it in your binary instead of carrying a .so file around. Regardless, Go's FFI story (especially in that direction) is hobbled and you can't do things like share structs easily (for obvious reasons, but still annoying). But yes, as soon as you get to C-level, you can mix and match anything and write about it. Running Go in Rust, or Rust in Go, or Go in JS, or whatever.<p>What would really be neat is to leverage Graal's polyglot iface a bit higher. I am not sure the status of llgo these days, but compile Go to LLVM bitcode and then leverage that from Java and compile to a single binary. Or even expose Go's awesome stdlib to JVM developers that way. But the practicality of doing some of these things becomes a bit lost beyond toy use.
the other alternative is to just implement the go-aws-lambda protocol. it is basically a bunch of go RPC calls that AWS makes to a port that you listen on. if you do it correctly it should be safe to run because AWS can't change the protocol in a way that is not backwards compatible with existing go projects. any language that can compile statically and be run on linux can run on AWS lambda because static-go binaries can be deployed to AWS lambda.<p>but this is probably a little less riskier because i'm sure if AWS made a change to the go protocol they would test it against their existing go libraries they have published but they can't test it against your <insert language> implementation.
So, clearly you can't use the real Java runtime because it expects to load an endpoint from a jar, but I wonder what the equivalent Python runtime version would look like. Prior to explicit Go support, people used the Python runtime as a shim to start a Go binary.<p>Is there anything about the way the Go runtime works that makes it fundamentally better than the Python runtime's semantics? Is the entirety of it that you really don't need to do a lot of work but Go is going to be marginally faster at doing that tiny bit of work (dlopen and ferry bytes across)? I think the underlying serialization format in Python is JSON. I have no idea how fast Gob is.<p>Any idea how much you lose on the FFI bridge? (My understanding is you need to copy the Go struct you get out before you can pass it to FFI. I'm very familiar with FFI in general and especially on the JVM, but only superficially with Go's in particular.)
FYI There is a blog post for interested, a reverse engine of AWS Lambda for Python, which does not use RPC/network at all, instead uses shared memory to communicate, which could be more of a challenge.<p><a href="https://www.denialof.services/lambda/" rel="nofollow">https://www.denialof.services/lambda/</a>
Sweet... I feel like someone should do this for a Jython program as a joke.<p>Then you'd have Python code executed by an interpreter written in Java compiled by Graal to produce a native binary which will be registered on AWS as a Go executable and will communicate via Go's net/rpc.<p>... as opposed to switching the runtime to Python ;-)
Is there any advantage to this over using Lambda's python runtime to run a binary? That seems to be what this project is doing to run a natively-compiled Clojure project: <a href="https://github.com/uwcpdx/clombda" rel="nofollow">https://github.com/uwcpdx/clombda</a>
> This title might seem like generated by a Markov Chain on Hacker News submissions, but it is real.<p>I smiled. But a more plausible Markov-chain headline might be "Using GraalVM to Run Native Java with Rust, Machine Learning, and the Gut Microbiome".
Okay, I can see what you're doing. I'm a little confused why. This seems like a potential rube goldberg machine that may exhibit some strange and unpredictable behaviour.<p>Maybe I'm crazy, but I much prefer to keep things as simple as possible. Pick a technology stack and use just it. Don't play mix and match games.<p>If java is just not working for you in lambda, due to the startup cost, is it time to consider that Java might not be the right technology at all for you to be using there?<p>If you're determined to stick with lambda, maybe it's time to bite-the-bullet and use Go (or something else with fast startup times).<p>If you're determined to stick with Java, maybe it's time to consider that maybe Lambda isn't the right solution for you? How much benefit are you really seeing vs the engineering cost and complications?