It also seems to be one of the biggest points of controversy for Go 2, with calls from "everything should have a context" to "context should go away".
The libraries that support it have now all their function signature way longer, and it is not well understood if it is a "Request for cancellation" or something else
Given that all of a Go program sooner or later will need contexts somewhere, it would be much cleaner to let goroutines have this stuff implicitly. I don't know enough about the intervals to say whether this is feasible with the current runtime, though.
> Then anyone can code implementations to that interface for whatever cloud they like in separate repos, similar to the way `database/sql` is structured
Of course they can, but you're working on a Google-centric version first right? Otherwise why would it be at Google Cloud Next?
That makes all other cloud providers second tier, and I don't think you should call yourselves "platform neutral". If you were, you would code up multiple platforms from the beginning, like is normally done for support on different operating systems for example
Please see the comment from our PM regarding Azure: https://news.ycombinator.com/item?id=17604358
Seems pretty weird to include support for an Oracle offering from the get-go, especially given the bad blood between Google and Oracle.
Yet, Azure support is listed as unplanned.
The language could mean that this is not going to be planned. The fact that y'all have not worked with Azure Go folks to get this moving is something to ponder.
A reminder that Go is a Google language and isn't vendor neutral?
"Unplanned" on the issue tracker just means we haven't assigned it to a sprint milestone for the team yet.
Azure and more clouds are very much in the works. As an open project, there are many approaches and we're open to all of them.
One other point: since Go interfaces are implicitly fulfilled, anyone can write and share implementations of Go Cloud for new providers or custom services without asking anyone for permission. If you take a look at the implementations we've provided, you'll find it's actually rather easy.
More to come.
My my question is, what if developers want access to innovations in specific cloud providers, such as reduced redundancy storage on S3? Wire up or own provider? Will there be some sort of community-provided provider registry or will we be grepping awesome lists on GH? Are providers extendable in any way?
Thanks and have a sunny day.
The main goal of Go Cloud is that the abstraction is not leaky and that you don't get access to specific features in the way you are describing in the application itself.
Now if the specificity of the thing you want happens at provisioning time but the API is the same (e.g. choosing to use Aurora on AWS vs standard RDS), then there's no problem. Go Cloud doesn't need to know about that.
If the API changes too, then that's a much different thing, and gets back to the leaky abstraction which we want to avoid. If you can't simply wire new providers to your application code and have it Just Work, then we've done our job wrong.
But remember that it's all Just Normal Go, there's no magic here. It's just standard Go. If you want to write an app that ties itself to something specific on some cloud you can; just write the code you'd write now. But that necessarily means you're tied to that product.
In the minute you implement something provider specific, you just lost the whole point of this library and you did not needed it in the first place.
The majority of the team is in SF for Google Cloud Next to present this. I'm about to hop into the car to head up myself to watch, so I can do a little AMA throughout the day. Reply to this to make sure I see your question!
Here's a question I've already seen:
> Is this a Google project or a Go project?
It is a project led by the Go team, and we are very aware of our responsibility to be cloud provider neutral. At the same time, while the project is so new and evolving so rapidly, we need to have working examples that we can change atomically in a single repository (atomic changes necessary for rollbacks and such). We don't want to have cloud provider-specific code in the Go project, so the code is currently sitting under the Google GitHub org. When the interfaces to different products stabilize, the intention is to graduate them up to the Go GitHub org. Then anyone can code implementations to that interface for whatever cloud they like in separate repos, similar to the way `database/sql` is structured. The cloud provider-specific code will always live outside the Go project.
But things are very new, so change is possible.