22 ms·

Cloud Functions: Go 1.11 is now a supported language

252 points by yannikyeo 8y ago

sethvargo 8y ago
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!
- vira28 8y ago
  As we all know, it took Google so long to get this. Can you overview on what are some of the technical challenges faced? Just curious. Thanks.
  - stewart27 8y ago
    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 Functions will automatically install dependencies listed in your go.mod file. * Our testers gave us a ton of feedback that helped us polish the developer experience -- we identified and fixed many rough edges related to error messages during deployment/build and errors at runtime. Serverless products can be a bit opaque (since you can't just ssh into a machine), so getting this right is important. I'd like to say that there was one big, interesting challenge that we had to tackle. But the reality is that we worked through many small details that only became apparent during testing. We wanted to address these so that we could offer a high quality experience for our public beta launch. We owe our alpha testers major credit for helping us find and solve issues. Speaking of testers -- if you have feedback on the runtime, we'd love to hear from you in our Cloud Functions Beta Tester group [1]. [1] https://cloud.google.com/functions/docs/getting-support#beta_tester_group https://cloud.google.com/functions/docs/getting-support#beta...
    - vira28 8y ago
      Thanks for the response. Would like to see more granular triggers (event types). Especially with Firebase. Also, would like to see more examples with firestore.
      - stewart27 8y ago
        Which ones would you like to see? We're always looking for new use cases to support.
        vira28 8y ago
        These are not specific to Go. firebase authentication -> user account from disabled to enabled. firebase authentication -> when a new phone number is associated. Firestore -> field level triggers. Right now we have only document level trigger.
        elithrar 8y ago
        > Firestore -> field level triggers. Right now we have only document level trigger. For what it's worth, if you have an onUpdate trigger on a Firestore database, the event you receive has the before & after state of the change, which would include field-level changes: https://firebase.google.com/docs/functions/firestore-events#handle_event_data https://firebase.google.com/docs/functions/firestore-events#... Is there a specific use-case that this doesn't handle for you? Note: Work at GCP, not on Functions.
        vira28 8y ago
        well, if I have onUpdate trigger, which means my function is going to be triggered for every update on the document (even for the fields that I don't care) You can say that triggering functions shouldn't cost you much, but thats not the way to do right. Correct me if I am wrong. My use-case is simple. Want to get my CF triggered if the value of a particular field in a doc changes. Thanks.
    - 8y ago
- dstaley 8y ago
  IIRC only the Node.js runtime has the ability to be emulated locally. Is this still the case? If I wanted to test my function locally, how would I go about doing that?
  - chrisbroadfoot 8y ago
    Use regular "go test" for unit testing. If you're using metadata inside your function (e.g., to extract an event ID) you can use metadata.NewContext to pass into your function while testing: https://godoc.org/cloud.google.com/go/functions/metadata#NewContext https://godoc.org/cloud.google.com/go/functions/metadata#New... If you just want to execute your function, create another package main and start an HTTP server, as you'd normally do. There are some examples on this page: https://cloud.google.com/functions/docs/bestpractices/testing#functions-prepare-environment-go https://cloud.google.com/functions/docs/bestpractices/testin... We're thinking about ways to improve the local development/testing story, and are keen to hear any ideas/feedback. Disclaimer: I work at Google, and worked on this product.
    - gobuildship 8y ago
      Just do what Azure does with functions. Have used their VS Code local debug and "just worked" out of the box
- wasd 8y ago
  What's next on the roadmap for cloud functions? Some things I'm curious about is work related to cold starts and future run times (specifically Ruby) but happy to hear about anything.
  - stewart27 8y ago
    While I can't share details publicly, I can confirm that we're actively working on new runtimes and performance improvements.
- w8rbt 8y ago
  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?
  - sethvargo 8y ago
    We will include support for more runtimes and language versions in the future.
  - chrisbroadfoot 8y ago
    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-maintenance https://github.com/golang/go/wiki/Go-Release-Cycle#release-m... Disclaimer: I work on GCP and used to work on Go language releases.
- bdibs 8y ago
  Hey Seth, I was wondering if you guys ever discussed the previous AWS vs GCP performance post that was on here a while back.
  - sethvargo 8y ago
    We worked with the original authors and they updated their original benchmarks. We are still compiling data and running our own benchmarks in other areas. Things were on pause for a bit as many Googlers took time off for the holidays to spend time with friends and family. I’ll check in on the team though. Thanks for the reminder!
  - sofaofthedamned 8y ago
    Do you have a link to this please?
    - bdibs 8y ago
      https://news.ycombinator.com/item?id=18673541 https://news.ycombinator.com/item?id=18673541
      - sofaofthedamned 8y ago
        Awesome,thank you.
- MrSaints 8y ago
  This might be a very specific question, but any plans to include packages in the Go runtime for headless Chrome? I know it is already available in Node.js.
  - tbpalsulich 8y ago
    The base set of system packages should be the same between the two runtimes. I work at GCP and on this project.
vira28 8y ago
Better late than never.
- stewart27 8y ago
  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.
lukeaf 8y ago
Worth the wait!
SkeptinenSpede5 8y ago
How fast you could get banned ? Or shadowed ?
sladey 8y ago
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 8y ago
  > 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 8y ago
    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 8y ago
      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 8y ago
        > 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.
cygned 8y ago
Nice! Go 1.11, especially modules, is a great step forward.
- tschellenbach 8y ago
  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 8y ago
    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
pjmlp 8y ago
> 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 8y ago
  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 :)
  - pjmlp 8y ago
    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.
    - sethvargo 8y ago
      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 :)
      - pjmlp 8y ago
        I don't see any such single letter identifiers on previous announcements. https://cloud.google.com/blog/products/gcp/cloud-functions-serverless-platform-is-generally-available https://cloud.google.com/blog/products/gcp/cloud-functions-s... https://cloud.google.com/blog/products/application-development/introducing-php-7-2-runtime-on-the-app-engine-standard-environment https://cloud.google.com/blog/products/application-developme... https://cloud.google.com/blog/products/gcp/calling-java-developers-spring-cloud-gcp-1-0-is-now-generally-available https://cloud.google.com/blog/products/gcp/calling-java-deve...
- 8y ago
jay_kyburz 8y ago
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 8y ago
  I’ll raise it with the team thanks!
  - jay_kyburz 8y ago
    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.
chrisbroadfoot 8y ago
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 8y ago
  Yeah- mods, the Cloud Functions context was useful. Can you change it back.
- nijaru 8y ago
  I assumed as much, but the title could definitely be better.
dolftax 8y ago
Single functionality HTTP handlers in Go, can now be served on HA. Nice.
st3fan 8y ago
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.
- stewart27 8y ago
  Indeed. If you want to compile the binary yourself/don't want to upload source code, we have a serverless containers product currently available as an early preview (sign up at g.co/serverlesscontainers). This would allow you to compile your binary locally, write a simple Dockerfile and then build/deploy the resulting container.
  - sjroot 8y ago
    This is great. It sounds like what people were hoping would come from Zeit Now, though in their latest major release they moved away from serverless docker deployments. Their community was quite upset at that decision I think. I will have to check this out!
- benatkin 8y ago
  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.
  - vira28 8y ago
    If i understand correctly the binary is created from the source code right. Am i missing anything?
    - 8y ago
manigandham 8y ago
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 8y ago
  It's simpler to just write code, rather than have to try to set up a container.
  - manigandham 8y ago
    >> building your code into one when you upload There's already a publish step, so it can be automatic.
- jacques_chester 8y ago
  > Isn't this all about to be replaced by serverless containers? Maybe soon, maybe later, maybe never. But it makes sense for a company of Google's size to keep working on the current things they have. Otherwise you wind up with an Osborne Effect and/or frustrated customers.
- com2kid 8y ago
  If you need to setup some stand alone functions, this is a great way to do it. I run quite a few utility functions like this, they are simple to write and deploy. If all I want is an HTTP endpoint somewhere, I'm actually not sure why I'd want a serverless container when a stand alone .js file does the trick.
wiradikusuma 8y ago
Since it's compiled (compared to Python or JS), is this faster/lighter?
- chrisbroadfoot 8y ago
  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.
thetechlead 8y ago
Trying to make sense of it from a business point of view. Could be useful for IoT applications. Event-driven, lightweight, scalable.

252 points by yannikyeo 8y ago

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!

vira28 8y ago
As we all know, it took Google so long to get this. Can you overview on what are some of the technical challenges faced? Just curious. Thanks.
- stewart27 8y ago
  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 Functions will automatically install dependencies listed in your go.mod file. * Our testers gave us a ton of feedback that helped us polish the developer experience -- we identified and fixed many rough edges related to error messages during deployment/build and errors at runtime. Serverless products can be a bit opaque (since you can't just ssh into a machine), so getting this right is important. I'd like to say that there was one big, interesting challenge that we had to tackle. But the reality is that we worked through many small details that only became apparent during testing. We wanted to address these so that we could offer a high quality experience for our public beta launch. We owe our alpha testers major credit for helping us find and solve issues. Speaking of testers -- if you have feedback on the runtime, we'd love to hear from you in our Cloud Functions Beta Tester group [1]. [1] https://cloud.google.com/functions/docs/getting-support#beta_tester_group https://cloud.google.com/functions/docs/getting-support#beta...
  - vira28 8y ago
    Thanks for the response. Would like to see more granular triggers (event types). Especially with Firebase. Also, would like to see more examples with firestore.
    - stewart27 8y ago
      Which ones would you like to see? We're always looking for new use cases to support.
      - vira28 8y ago
        These are not specific to Go. firebase authentication -> user account from disabled to enabled. firebase authentication -> when a new phone number is associated. Firestore -> field level triggers. Right now we have only document level trigger.
        elithrar 8y ago
        > Firestore -> field level triggers. Right now we have only document level trigger. For what it's worth, if you have an onUpdate trigger on a Firestore database, the event you receive has the before & after state of the change, which would include field-level changes: https://firebase.google.com/docs/functions/firestore-events#handle_event_data https://firebase.google.com/docs/functions/firestore-events#... Is there a specific use-case that this doesn't handle for you? Note: Work at GCP, not on Functions.
        vira28 8y ago
        well, if I have onUpdate trigger, which means my function is going to be triggered for every update on the document (even for the fields that I don't care) You can say that triggering functions shouldn't cost you much, but thats not the way to do right. Correct me if I am wrong. My use-case is simple. Want to get my CF triggered if the value of a particular field in a doc changes. Thanks.
  - 8y ago
dstaley 8y ago
IIRC only the Node.js runtime has the ability to be emulated locally. Is this still the case? If I wanted to test my function locally, how would I go about doing that?
- chrisbroadfoot 8y ago
  Use regular "go test" for unit testing. If you're using metadata inside your function (e.g., to extract an event ID) you can use metadata.NewContext to pass into your function while testing: https://godoc.org/cloud.google.com/go/functions/metadata#NewContext https://godoc.org/cloud.google.com/go/functions/metadata#New... If you just want to execute your function, create another package main and start an HTTP server, as you'd normally do. There are some examples on this page: https://cloud.google.com/functions/docs/bestpractices/testing#functions-prepare-environment-go https://cloud.google.com/functions/docs/bestpractices/testin... We're thinking about ways to improve the local development/testing story, and are keen to hear any ideas/feedback. Disclaimer: I work at Google, and worked on this product.
  - gobuildship 8y ago
    Just do what Azure does with functions. Have used their VS Code local debug and "just worked" out of the box
wasd 8y ago
What's next on the roadmap for cloud functions? Some things I'm curious about is work related to cold starts and future run times (specifically Ruby) but happy to hear about anything.
- stewart27 8y ago
  While I can't share details publicly, I can confirm that we're actively working on new runtimes and performance improvements.
w8rbt 8y ago
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?
- sethvargo 8y ago
  We will include support for more runtimes and language versions in the future.
- chrisbroadfoot 8y ago
  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-maintenance https://github.com/golang/go/wiki/Go-Release-Cycle#release-m... Disclaimer: I work on GCP and used to work on Go language releases.
bdibs 8y ago
Hey Seth, I was wondering if you guys ever discussed the previous AWS vs GCP performance post that was on here a while back.
- sethvargo 8y ago
  We worked with the original authors and they updated their original benchmarks. We are still compiling data and running our own benchmarks in other areas. Things were on pause for a bit as many Googlers took time off for the holidays to spend time with friends and family. I’ll check in on the team though. Thanks for the reminder!
- sofaofthedamned 8y ago
  Do you have a link to this please?
  - bdibs 8y ago
    https://news.ycombinator.com/item?id=18673541 https://news.ycombinator.com/item?id=18673541
    - sofaofthedamned 8y ago
      Awesome,thank you.
MrSaints 8y ago
This might be a very specific question, but any plans to include packages in the Go runtime for headless Chrome? I know it is already available in Node.js.
- tbpalsulich 8y ago
  The base set of system packages should be the same between the two runtimes. I work at GCP and on this project.

vira28 8y ago

Better late than never.

stewart27 8y ago
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.

lukeaf 8y ago

Worth the wait!

SkeptinenSpede5 8y ago

How fast you could get banned ? Or shadowed ?

sladey 8y ago

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 8y ago
> 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 8y ago
  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 8y ago
    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 8y ago
      > 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.

cygned 8y ago

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

tschellenbach 8y ago
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 8y ago
  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

pjmlp 8y ago

> 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 8y ago
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 :)
- pjmlp 8y ago
  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.
  - sethvargo 8y ago
    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 :)
    - pjmlp 8y ago
      I don't see any such single letter identifiers on previous announcements. https://cloud.google.com/blog/products/gcp/cloud-functions-serverless-platform-is-generally-available https://cloud.google.com/blog/products/gcp/cloud-functions-s... https://cloud.google.com/blog/products/application-development/introducing-php-7-2-runtime-on-the-app-engine-standard-environment https://cloud.google.com/blog/products/application-developme... https://cloud.google.com/blog/products/gcp/calling-java-developers-spring-cloud-gcp-1-0-is-now-generally-available https://cloud.google.com/blog/products/gcp/calling-java-deve...
8y ago

jay_kyburz 8y ago

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 8y ago
I’ll raise it with the team thanks!
- jay_kyburz 8y ago
  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.

chrisbroadfoot 8y ago

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 8y ago
Yeah- mods, the Cloud Functions context was useful. Can you change it back.
nijaru 8y ago
I assumed as much, but the title could definitely be better.

dolftax 8y ago

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

st3fan 8y ago

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.

stewart27 8y ago
Indeed. If you want to compile the binary yourself/don't want to upload source code, we have a serverless containers product currently available as an early preview (sign up at g.co/serverlesscontainers). This would allow you to compile your binary locally, write a simple Dockerfile and then build/deploy the resulting container.
- sjroot 8y ago
  This is great. It sounds like what people were hoping would come from Zeit Now, though in their latest major release they moved away from serverless docker deployments. Their community was quite upset at that decision I think. I will have to check this out!
benatkin 8y ago
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.
- vira28 8y ago
  If i understand correctly the binary is created from the source code right. Am i missing anything?
  - 8y ago

manigandham 8y ago

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 8y ago
It's simpler to just write code, rather than have to try to set up a container.
- manigandham 8y ago
  >> building your code into one when you upload There's already a publish step, so it can be automatic.
jacques_chester 8y ago
> Isn't this all about to be replaced by serverless containers? Maybe soon, maybe later, maybe never. But it makes sense for a company of Google's size to keep working on the current things they have. Otherwise you wind up with an Osborne Effect and/or frustrated customers.
com2kid 8y ago
If you need to setup some stand alone functions, this is a great way to do it. I run quite a few utility functions like this, they are simple to write and deploy. If all I want is an HTTP endpoint somewhere, I'm actually not sure why I'd want a serverless container when a stand alone .js file does the trick.

wiradikusuma 8y ago

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

chrisbroadfoot 8y ago
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.

thetechlead 8y ago

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