Nice! Go 1.11, especially modules, is a great step forward.
Cloud Functions: Go 1.11 is now a supported language
41–50 of 107 posts
Re: Cloud Functions: Go 1.11 is now a supported language
#42We've used GCF for some production tasks and it's worked pretty well for us. Would like to see some more runtimes/languages. I'm hoping AWS' recent layers implementation has made this more of a focus at Google. I'm curious how the implementation of Go has affected the ease of integrating other languages.
Given what we've seen with AppEngine they've been moving away from custom language toolchains and to a more containerized deployment approach.
Re: Cloud Functions: Go 1.11 is now a supported language
#43Meta comment: why did the HN title change to "Go 1.11 is now a supported language"? This post is specifically about Google Cloud Functions, not Go 1.11 in general (which is over 6 months old). edit: thanks, mods!
Re: Cloud Functions: Go 1.11 is now a supported language
#44Earlier quoted context omitted.
It's definitely something that we've discussed. Would you consider running a container that could be run like Cloud Functions? This container could run the binary that you create. It's not something that we support today but I'm curious whether this would meet your needs.
> running a container that could be run like Cloud Functions Does this mean we actually run the container ourselves on our GKE cluster or in a VM? Or do you mean a "container" runtime for Cloud Functions? Both would be interesting, but we'd prefer the latter since there would be less to manage. I'd be interested to see the performance of it.
Re: Cloud Functions: Go 1.11 is now a supported language
#45Re: Cloud Functions: Go 1.11 is now a supported language
#46> func F(w http.ResponseWriter, r *http.Request) And me thinking the days of C compilers with 10 character limit for identifiers on the symbol table was long gone.
https://github.com/golang/go/wiki/CodeReviewComments#variabl...
Disclaimer: I work at Google, but not on GCF or Go.
Re: Cloud Functions: Go 1.11 is now a supported language
#47Earlier quoted context omitted.
That is a lame excuse for a blog with examples that are just bad engineering practices. You surely don't have such examples with the other programming languages supported on the Google Cloud.
Thank you for the feedback. We do have similar examples for the other programming languages because that’s what the community uses most frequently. You’re still free to name the entry function whatever you prefer to match the styles and engineering practices of your organization :)
https://cloud.google.com/blog/products/gcp/cloud-functions-s...
https://cloud.google.com/blog/products/application-developme...
https://cloud.google.com/blog/products/gcp/calling-java-deve...
Re: Cloud Functions: Go 1.11 is now a supported language
#48> func F(w http.ResponseWriter, r *http.Request) And me thinking the days of C compilers with 10 character limit for identifiers on the symbol table was long gone.
For better or worse, it's convention to use really short (as in, single character when possible) variable names in Go. https://github.com/golang/go/wiki/CodeReviewComments#variabl... Disclaimer: I work at Google, but not on GCF or Go.
Thanks for the heads up.
Re: Cloud Functions: Go 1.11 is now a supported language
#49Earlier quoted context omitted.
For better or worse, it's convention to use really short (as in, single character when possible) variable names in Go. https://github.com/golang/go/wiki/CodeReviewComments#variabl... Disclaimer: I work at Google, but not on GCF or Go.
I guess I forgot about those "best practices". Thanks for the heads up.
The second paragraph there is more in line with best practice...
"The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names."
In the case of a Cloud Function, a short name like "F" is probably fine. While it needs to be exported to get deployed properly, it isn't a library function, is very unlikely to be imported by other packages, so it's really more like "func main" than anything.
Most people will have a single Cloud Function in a package, and I don't think you'd reasonably have f/f.go with a function named "F".
Re: Cloud Functions: Go 1.11 is now a supported language
#50Meta comment: why did the HN title change to "Go 1.11 is now a supported language"? This post is specifically about Google Cloud Functions, not Go 1.11 in general (which is over 6 months old). edit: thanks, mods!