Live data from Hacker News

Cloud Functions: Go 1.11 is now a supported language

cloud.google.com

41–50 of 107 posts

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

#41
post #22

Nice! Go 1.11, especially modules, is a great step forward.

Actually tried to use it in production these last few months. The core of the experience is awesome, didn't run into any issues at all. The problem is that all the tooling like errcheck doesn't support go modules yet. So we ended up going back to the dep package manager. Will try again in a couple of months. Here's a ticket about the issue: https://github.com/golang/go/issues/24661

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

#42
post #19
post #13

We'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.

You're right. If you look around in the logs for the deployment output, you'll see that both Cloud Functions and App Engine go through a container build step via Cloud Build.

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

#43

Meta 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!

Yeah- mods, the Cloud Functions context was useful. Can you change it back.

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

#44
post #26

Earlier 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.

If you're interested in something along the lines of the latter, you can sign up for an early access preview here: g.co/serverlesscontainers

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

#46
post #27

> 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.

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

#47
post #32

Earlier 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 :)

I don't see any such single letter identifiers on previous announcements.

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
post #27

> 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.

I guess I forgot about those "best practices".

Thanks for the heads up.

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

#49
post #48

Earlier 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.

I don't think "Variable names in Go should be short rather than long" is an accurate description of best practice. The wiki should probably be changed.

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

#50

Meta 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!

I assumed as much, but the title could definitely be better.
Post reply on HN