go-cloud

project in a new direction. People have that freedom with the Go language. They don't necessarily have the freedom to call that forked language "Go" (I'm not sure), but I think that limitation is OK; it serves nobody to call different projects by the same name. The blog post starts by quoting @kapoorsunny asking why there can't be something like OpenGo, with a community implementation of generics. I hope that it is clear that the answer is that there could be. Nothing prevents that from happening. In particular, Google doesn't prevent that from happening. So when someone says that Go is Google's language, they must mean something else. For any free software project, there is a set of people who can commit changes to the project. For the Go project, that is the set of people who are on the approvers list, who can click the +2 button in Gerrit. I don't think this list is publicly visible for anybody is not an approver, but I just took a look. Since some people who work at Google use their personal e-mail addresses I could have made a mistake, but I count 59 Googlers on the committers list and 51 non-Googlers. So while Google is the majority, it's not an overwhelming one. Again, this can't be what it means to say that Go is Google's language. A programming language is a type of shared software infrastructure. It's most useful when everybody is using the same language, so code written by person A can be reused by person B. That means that programming languages are most useful when we all agree on exactly what the language is. All successful languages have either a single specification or a single primary implementation. (Go and C++ are examples of language based on a specification; Perl, at least before Perl 6, is an example of a language based on an implementation). These serve as the definition of what the language is: whatever the specification says or whatever the implementation does. I think most people would agree to all of the above. Now some opinion, where people may disagree. If a language is to change over time, this specification or implementation must change. Somebody has to decide how changes will be made. All successful languages have a small set of people who make the final decisions. Many people will provide input to this decision, but no successful language--indeed, no successful free software project of any sort--is a democracy. Successful languages pay attention to what people want, but to change the language according to what most people want is, I believe, a recipe for chaos and incoherence. I believe that every successful language must have a coherent vision that is shared by a relatively small group of people. As I said, that is my opinion, but I think it's true. I would be interested to hear of a counter-example. Since Go is a successful language, and hopes to remain successful, it too must be open to community input but must have a small number of people who make final decisions about how the language will change over time. So, I think that when the blog post says that Go is Google's language, what they mean is that Google makes those final decisions. Now a bit of personal history. The Go project was started, by Rob, Robert, and Ken, as a bottom-up project. I joined the project some 9 months later, on my own initiative, against my manager's preference. There was no mandate or suggestion from Google management or executives that Google should develop a programming language. For many years, including well after the open source release, I doubt any Google executives had more than a vague awareness of the existence of Go (I recall a time when Google's SVP of Engineering saw some of us in the cafeteria and congratulated us on a release; this was surprising since we hadn't released anything recently, and it soon came up that he thought we were working on the Dart language, not the Go language.) Since Go was developed by people who worked at Google, it is inevitable that the people who initially developed Go, who became the core Go team, were Google employees. And it happens that of that core Go team, while not all are actively working on Go, none have left Google for another company in the years since. I do think that due to Go's success there are now Google executives who know about Go. Google as a company is doing more work with Go at a higher level, supporting efforts like the Go Cloud Development Kit (https://github.com/google/go-cloud). And, of course, Go is a significant supporting element for major Google Cloud projects like Kubernetes. But (and here you'll just have to trust me) those executives, and upper management in general, have never made any attempt to affect how the Go language and tools and standard library are developed. Of course, there's no reason for them to. Go is doing fine, so why should they interfere? And what could they gain if they did interfere? So they leave us alone. In effect, then, the current state is what the blog post suggests at the very end: final decisions about the Go language are made by the core Go team, and the core Go team all work at Google, but there is no meaningful sense in which Google, apart from the core Go team, makes decisions about the language. I do think that it will be interesting to see what happens if someone on the core Go team decides to leave Google and but wants to continue working on Go. And it will be interesting to see what the core Go team, including me, decides to do about succession planning as time goes on. Being a core Go team member is a full time job, and many people who want to work on Go full time wind up being hired by Google, so it would not be particularly surprising if the core Go team continues to be primarily or exclusively Google employees. But even then it's not clear that Go will be Google's language in any deep sense. It's also possible that someday it will become appropriate to create some sort of separate Go Foundation to manage the language. I don't know. We'll have to see. As I said initially, none of this necessarily contradicts anything in the blog post, but perhaps it gives a slightly different perspective. In this note I've specifically focused on whether Go is Google's language. I have some thoughts on other aspects of the blog post, about its discussion of the interaction between the core Go team and the rest of the Go community, but this note is already too long. Perhaps I will tackle those later. Or perhaps not, no promises. Ian

s://github.com/google/go-cloud You could easily have a "blockchain" API with any number of runtime backends. I understand what the proposer was suggesting: a single semantic meaning for "print" across all programming languages that will map onto blockchain. I just don't agree that it is a good idea.

has been my experience with tens of providers that the time loss occurs when the requests have been handed off to a providers API but not so much in Terraform. Agree. So this is sort of the point. I don't need to actually bring up machines in a typical DAG fashion - so some of the work is parallelizable. But other parts aren't. If I need 20 machines, I know I need 20 machines. If the AMI's are loaded on the cloud provider, there is absolutely no reason to have them loaded sequentially (such as a "post-config" might require) i.e. incurring large wait times. Once you start using "terraform" variables (off of resources), that is what you get. So I prefer a different variable resolution mechanism (i.e. lazy/evented). Particularly now that you can ghetto-leverage the cloud providers tag systems, in order to do "proto" service discovery (tag machines for eventual service discovery/config i.e. similar to ansible roles). I'm twisting the hell out of terraform (for things it is not intended to do). but that is because I want to avoid adding yet another tool to the toolchain. More declarative DSL's = more issues to diagnose. > As for Terraform itself, my biggest issue is that it has turned around the view of resources and providers. not so much a problem for me (not multi-cloud). I like knowing (at a glance) what provider-specific features I can expect to be supported. The problem with trying to abstract out cloud provider, is you go with the lowest common denominator (in terms of declarative syntax). > It should have been going in the direction of https://github.com/google/go-cloud Never used it. Also I've never written a terraform module. So its entirely plausible, this is where my issues would be resolved (custom provider) and an "enhanced" dsl.