
Cloud Functions: Go 1.11 is now a supported language - yannikyeo
https://cloud.google.com/blog/products/application-development/cloud-functions-go-1-11-is-now-a-supported-language
======
st3fan
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 a Linux x86_64
binary.

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

~~~
DSingularity
That would be my guess. Since this is all event driven code, why wouldn’t they
bundle them for improved system utilization?

~~~
sudhirj
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).

------
sethvargo
Hey all - Seth from Google here. We're really excited to bring Go to Google
Cloud Functions (GCF). Please try it out, give us feedback, and let us know if
you have any questions!

~~~
w8rbt
I think AWS Lambda supports Go 1.x. Does GCF plan to stick to Go 1.11.x or
broaden support to other Go versions in the future? What will happen to 1.11.x
support when 1.12 comes out?

~~~
chrisbroadfoot
We use unpatched langauge toolchains/runtimes for GCF and second-generation
GAE. That means a drastically reduced time to release for new language
versions. (Maintaining patched runtimes was a significant burden to making new
versions of Go available on GAE.)

For long-term support of various languages, see the GCP deprecation policy:
[https://cloud.google.com/terms/deprecation](https://cloud.google.com/terms/deprecation)

Especially this sentence: "excluding [...] support for a programming language
version that is no longer publicly supported by, or receiving security updates
from, the organization maintaining that programming language"

So, that means we're committed to supporting the two most recent major version
releases of Go, as per the Go release policy:
[https://github.com/golang/go/wiki/Go-Release-
Cycle#release-m...](https://github.com/golang/go/wiki/Go-Release-
Cycle#release-maintenance)

Disclaimer: I work on GCP and used to work on Go language releases.

------
jay_kyburz
As an aside, and since there are some googlers here, the heading animation on
the blog has some issues in Firefox. They are super annoying. Would be nice if
google supported all browsers.

[https://photos.app.goo.gl/MgsfH8GZndCdyBjeA](https://photos.app.goo.gl/MgsfH8GZndCdyBjeA)

~~~
sethvargo
I’ll raise it with the team thanks!

~~~
jay_kyburz
I deleted the album because somebody kindly pointed out it might have revealed
more that it should. Feel free to email me if you need any help reproducing
the issue.

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

~~~
stewart27
> I'm curious how the implementation of Go has affected the ease of
> integrating other languages.

In some ways, it helps. You start to see similar issues arise and know what to
look out for when you're launching a new runtime. In other ways, every
language has its peculiarities and its own set of design considerations.

Launching/polishing a completely new language still takes a decent amount of
work. Launching a new version of an existing language tends to be much
quicker.

~~~
sladey
Although I've never used Lambda Layers. Do you think a similar approach is
something that could be implemented?

Maybe even just something for compiled languages like Go, Crystal, etc that
will just run the binary?

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

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

~~~
stewart27
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

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

~~~
tschellenbach
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](https://github.com/golang/go/issues/24661)

~~~
cygned
I noticed that, too. The only actual third-party tooling we use is realize [1]
which currently doesn’t work outside of GOPATH. Luckily, we work with Docker
anyway so our code is mounted inside GOPATH and we can use modules commands on
the host.

1: [https://github.com/oxequa/realize](https://github.com/oxequa/realize)

------
manigandham
Isn't this all about to be replaced by serverless containers? With FaaS
deployments just taking docker containers or building your code into one when
you upload?

Why the continued work on a one-off runtime and http response spec instead?

~~~
chris_st
It's simpler to just write code, rather than have to try to set up a
container.

~~~
manigandham
>> building your code into one when you upload

There's already a publish step, so it can be automatic.

------
dolftax
Single functionality HTTP handlers in Go, can now be served on HA. Nice.

------
thetechlead
Trying to make sense of it from a business point of view. Could be useful for
IoT applications. Event-driven, lightweight, scalable.

------
lukeaf
Worth the wait!

------
wiradikusuma
Since it's compiled (compared to Python or JS), is this faster/lighter?

~~~
chrisbroadfoot
Any performance difference will be similar to if you were running on any other
platform.

So, if for your particular application, Go has a faster startup/cold start
time than Python or Node, then yes, it'll be faster, overall.

Very difficult to speak about performance in general terms, though.

I will say that there is no kind of wrapper library or wrapper runtime like
some other serverless platforms might depend on.

------
vira28
Better late than never.

~~~
stewart27
You're not wrong. Cloud Functions Product Manager here. We've been running a
private early access preview since we first showed this at GopherCon in
August. I'm really happy to see this first step but we have a lot of work
ahead of us.

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

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

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

~~~
sethvargo
You can name the function anything you’d like. When you deploy the function,
you specify the entry point function name. Many of our alpha testers used “F”
for function because it’s quick and easy, but that’s not a requirement :)

