How do you feel about the distinction between Google and Go? It sometimes feels like they're joined at the hip, something which historically had made people queasy (Java and Oracle, .NET and Microsoft, etc). Though Go is a project which came from Google, I personally feel that it better serves the interests of the Go community to treat them separately. Google receives special treatment from Go - the announcement that AWS Lambda would support Go did not receive similar fanfare on golang.org.

Side note: there is some activity on the Go blog which is more mutual cooperation and less Google hivemind:

https://blog.golang.org/go-cloud

But I still wonder why this stuff belongs here.

Hey thanks a lot for your efforts! Your direct communication about the Go runtime progress has been a breath of fresh air compared to the years preceding you. I wonder though, how many developers are there on the App Engine Standard Go team?

>[7] Access Not Configured. Cloud Build has not been used in project <project> before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/cloudbuild.go... then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

So go111 cannot be used without Cloud Build, for which I have to activate billing?

I have an old app deployed to App Engine. The app itself is rock solid and chugging along fine (I touch it once a year or so), but I dreaded having to deploy it due to the lack of vendoring support and other... peculiarities of the Go runtime. Glad to see this is no longer an issue!

It looks like memcache is moving to a third-party service now instead of a built-in api. Is performance different? Does anyone have experience with this?

Yup!

> It looks like memcache is moving to a third-party service now instead of a built-in api. Is performance different? Does anyone have experience with this?

I'm not sure about the performance impact. But I can tell you that we're working with the Cloud Memorystore team to have a better memcache story for the App Engine second generation runtimes

> the cloud datastore package will default to writing your nested structs as entity values, while the appengine datastore packages will only write your nested structs as flattened sets of attributes.

Other than that, there are no differences.

(GCP Gopher)

You are right that the devil is in the details, and there might be some slight serialization differences. I cannot find an exact list.

Feel free to post here if you need more help.

Though...I wouldn't necessarily call Python slow! Python keeps getting faster, and we now support Python 3.7 on our second gen runtimes: https://cloud.google.com/blog/products/gcp/introducing-app-e...

Python might be perfectly acceptable of course.

You can go to the filter, turn off all languages but Go and Python, and get a general idea.

There's also the old Computer Benchmark Game, which should be taken with a whole barrel of salt: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Which program? URL?

It’s fifty percent faster than the competing java program.

That Go pi-digits program is only 4% faster than a PHP program that uses the GMP library.

It's not enough to "point out that most languages have C FFIs" when for this arbitrary precision arithmetic task GMP is allowed and others step-up and contribute those programs.

That's true of every comparison -- basic due diligence.

And read how the measurements were made --

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And read some background --

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And, of course, look for a task that might be appropriate --

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The benchmarks game website shows what it says it shows --

"Which programs are faster? Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!"

GOMAXPROCS is not 1 for this new runtime. As far as I know, it's an entirely vanilla Go runtime.

These new runtimes seem amazing (and fix a lot of problems), but we also lose a ton of functionality that made app engine so desirable (easy users auth, images api, built in email sending, search, cron, and others).

It kind of feels like we've thrown the baby out with the bathwater.

We are working on Google Cloud standalone products to replace most missing features (e.g. Cloud Scheduler for cron jobs). Not all of them are ready yet.

App Engine APIs were great when there was no alternative (when GCP did not exist, or when App Engine could not use arbitrary packages), but at the same time, contributed to the "lock-in" of App Engine, which was one of the main criticism. We believe it is in the long term benefit of our users to use standalone Google Cloud or third party services, instead of replying on APIs only accessible in App Engine.

Would be great if that was solved.

See https://cloud.google.com/appengine/docs/standard/go111/using... and scroll way down to the sample code.

either you whitelisted your ips or you used the proxy (which go appengine could already use).

so with go you just needed to use https://github.com/GoogleCloudPlatform/cloudsql-proxy which means you just need to change the query string.

however a new feature is emerging where you can have a private ip that is connected to your internal services, however it is still a beta feature.

Source: myself, but not a googler, just a regular user

(GCP Gopher)

You definitely don't want to check secrets into the repo for the same reason you don't set them as environment variables: It's not secure. The solution is to use Cloud Key Management Service. More info here: https://cloud.google.com/kms/ We use that to either store secrets directly, or to decrypt encrypted entities in a DB (e.g. Datastore).

You can see how we use it here (our project is open source): https://github.com/google/nomulus/tree/master/java/google/re...

Shows how to encrypt env vars with Cloud KMS then decrypt them in memory.

The reason being that these secrets are absolutely essential for many tasks that our registry needs to perform, and the past six years of experience have shown us that Datastore has better availability than GCS. We haven't seen Datastore ever go down unless all of Cloud is down too, whereas we have seen outages isolated to just GCS. Datastore also has lower latency (since it's a DB, not bulk file storage).

One caveat is that the maximum size of a single entity in Datastore is 1 MB -- if you're encrypting stuff larger than that then you'll need to shard (ugly) or just use GCS. Since none of our secrets are anything close to that large, it works just fine.

P.s typo on your link

Cloud Endpoints currently runs on GAE Standard Gen 1 and GAE Flex. We're investigating a solution for GAE Standard Gen 2 (which go 1.11 is, along with python 3.7, node 8, etc.) and GCF.

Any ETA for Gen 2 or alpha signup?

Flex uses ESP (https://github.com/cloudendpoints/esp), which is deployed as a sidecar, and works with any runtime.

As for EAP: unfortunately not. Personally, I'd like to see a managed version as opposed to the current framework or sidecar approach, as it'll be easier to implement across products, but that means it'll likely take a little longer.

Note: you need to have go1.11, and by default you need to be in a directory NOT in your $GOPATH for modules to work in go1.11

Copy paste error I guess.

Does anyone have any elucidation?

However, there's still an environment needed to run that binary. For Go on App Engine, this includes the sandbox (backed by gVisor) and the operating system (Ubuntu).

We also tend to call everything in the toolchain the "runtime" - this includes the CLI for uploading and staging your app, and the builder used to compile your program. Not the strictest definition :)

(GCP Gopher)

For App Engine flexible, you can skip that build step and provide your own container, but that isn't possible for App Engine standard. (If you're interested in something like that, see https://g.co/serverlesscontainers)

Yes, you don't need to use the appengine context for anything (except to access the services at google.golang.org/appengine/...)

You can use the standard net/http package to make HTTP requests, for example.