Re:Cloud Functions: Go 1.11 is now a supported language
by skywhopper on Wednesday January 16, 2019 @09:43PM
(#18927847)
I was wondering about this, given the examples. AWS's Golang support for Lambda involves including their library and passing your function to a Lambda initializer function. Which I'm sure is all that's happening with this, but it's weird to hand off the Go source to Google. I wonder if they are multiplexing multiple functions in single binaries or using special Go toolchains. Or just don't want to lock into specific backends yet.
[ Parent
| on HN ]
Re:Cloud Functions: Go 1.11 is now a supported language
by chrisbroadfoot on Thursday January 17, 2019 @02:25AM
(#18929024)
No, there's no real magic. Each function runs in its own process (which is inside a gVisor sandbox).
The toolchain is completely unmodified.
Disclaimer: I work at GCP and worked on this product.
Re:Cloud Functions: Go 1.11 is now a supported language
by zaphirplane on Thursday January 17, 2019 @02:00AM
(#18928921)
Unlikely Golang’s init block will get executed in all the multiplexed serverless functions that are bundled in the one binary. Which adds a side effect
Re:Cloud Functions: Go 1.11 is now a supported language
by justasitsounds on Wednesday January 16, 2019 @09:57PM
(#18927941)
> AWS's Golang support for Lambda involves including their library and passing your function to a Lambda initializer function
AWS announced 'native' Golang support last year - since then there hasn't been a need to use a Python or node 'shim' to bootstrap the golang executable like this. You just upload your compiled binary to S3 and provide the path to AWS lambda
Re:Cloud Functions: Go 1.11 is now a supported language
by DSingularity on Wednesday January 16, 2019 @11:38PM
(#18928423)
That would be my guess. Since this is all event driven code, why wouldn’t they bundle them for improved system utilization?
Re:Cloud Functions: Go 1.11 is now a supported language
by sudhirj on Thursday January 17, 2019 @01:57AM
(#18928909)
Because Go's namespacing / packaging model doesn't have the kinds of isolation required to prevent you from accessing the code and variables of the other packages you've been bundled with, compared to NodeJS, which does (VM feature).