Live data from Hacker News

Cloud Functions: Go 1.11 is now a supported language

cloud.google.com

91–100 of 107 posts

Re: Cloud Functions: Go 1.11 is now a supported language

#91
post #55

One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…

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…

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

#93
post #55

One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…

One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. I've been thinking of using this approach for a golang MMO game…

Like Screeps? Even more niche? :)

Re: Cloud Functions: Go 1.11 is now a supported language

#94
post #55

One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…

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…

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

#95
post #88
post #55

One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…

Curious, wouldn’t you want the source code to compile on the final platform? (If not using docker) I’m not familiar with binary or lower level workings but I figured there would be certain benefits of compiling the same code on Linux vs Mac or Windows for example.

The Go compiler produces the same binary regardless of which host OS it is ran on. i.e., the OS you compile a Go program on doesn't matter (assuming pure Go code, not including C etc).

Re: Cloud Functions: Go 1.11 is now a supported language

#96

Earlier quoted context omitted.

This is a much better solution, I think. Uploading your source code is often easier than uploading your binaries. If, for example, you have a new contributor you don't yet trust creating a cloud function in Go and you know enough Go to review the code, but it's not convenient for you to compile it yourself, you can just upload the code yourself. You can't easily review the binary.

The fact that it's easier to do things this way just shows how immature the toolchain surrounding serverless development is. It shouldn't be difficult to simulate the serverless environment on a workstation, and yet somehow that's a huge gap, even for Lambda.

the Cloud Functions emulator works well, and helps https://cloud.google.com/functions/docs/emulator

Re: Cloud Functions: Go 1.11 is now a supported language

#97

Earlier quoted context omitted.

Cloud Functions PM here. I can give some insight: * We've been running a private early access preview/alpha since last August. * This was our first compiled language on Cloud Functions, which came with its own set of challenges. * It took us a while to find the right approach for supporting dependencies (both Go Modules and vendoring are supported). Unlike other providers, when you deploy your source code, Cloud Func…

Is there a reason dependency management happens like this? We currently deploy Go Lambda functions in AWS with the help of the Serverless Framework and it just uploads the cross compiled Binary and not the whole project. Why wouldn't the binary be the deployed unit in this case?

While it's a lot more work for them, and some may already have the infrastructure setup for deploying their own binary, I think having GCP handle the end-to-end there is more user friendly in general. I can quickly write a Cloud Function from any computer, without having to deal with setting up the tool chains. If you want to just run binaries, sounds like Cloud Functions isn't what you're looking for.

Re: Cloud Functions: Go 1.11 is now a supported language

#98
post #95
post #88

Earlier quoted context omitted.

Curious, wouldn’t you want the source code to compile on the final platform? (If not using docker) I’m not familiar with binary or lower level workings but I figured there would be certain benefits of compiling the same code on Linux vs Mac or Windows for example.

The Go compiler produces the same binary regardless of which host OS it is ran on. i.e., the OS you compile a Go program on doesn't matter (assuming pure Go code, not including C etc).

Thx for the info, I don’t use Go typically.

Re: Cloud Functions: Go 1.11 is now a supported language

#99
post #95
post #88

Earlier quoted context omitted.

Curious, wouldn’t you want the source code to compile on the final platform? (If not using docker) I’m not familiar with binary or lower level workings but I figured there would be certain benefits of compiling the same code on Linux vs Mac or Windows for example.

The Go compiler produces the same binary regardless of which host OS it is ran on. i.e., the OS you compile a Go program on doesn't matter (assuming pure Go code, not including C etc).

I think he was talking more about the machine architecture than the OS.

Re: Cloud Functions: Go 1.11 is now a supported language

#100
post #95

Earlier quoted context omitted.

The Go compiler produces the same binary regardless of which host OS it is ran on. i.e., the OS you compile a Go program on doesn't matter (assuming pure Go code, not including C etc).

I think he was talking more about the machine architecture than the OS.

As of Go 1.5 the compiler works for any supported target architecture.
Post reply on HN