Like it or not, Google is probably paying around a million $$ a year to keep senior full-time developers around that want to work on the language. That could be used as a benchmark to calculate how much of an investment is required to have a healthy development cycle.
If a community-maintained fork is created, it would need time and monetary investment similar to what google is doing just to maintain and develop non-controversial features. Question is: Is this assessment sensible and if so, is the community able or willing to make this kind of investment?
(Source: public git logs for all core Go repos in past year, look for google.com or golang.org emails, multiply by typical Google salaries, which you can find on various sites.)
I'd be surprised if Ian Lance Taylor, Russ Cox and Rob Pike are making less than a million dollars a year each. They're all L8+, and even by that standard they're notably famous/distinguished/respected.
Another one to add is the cost of evangelism. Even if someone isn't evangelizing a language directly, they're helping further it so long as they demonstrate how to do stuff with it.
I read somewhere on mailing list that there are about ~30 people inside Google working full time on Go. And that is different from engineers working on products built using Go.
With infrastructure cost added it would be easily $10 million a year.
So these Linkedin/Twitter style thought leaders demanding some kinda OpenGo foundation need to ask if they have capacity to raise this amount consistently over years to start and run this foundation.
A foundation doesn't need to replace all the corporate money. At minimum, it's a guarantee that the language will be maintained if/when the corporate entity loses interest. Maintaining a language is not nearly as cumbersome as improving it.
At best, a foundation is also going to provide more neutral governance, as well as a nexus for multiple corporations to work on the language together. Other companies are more likely to adopt Go if they see it as not just a Google project.
I personally don't care whether my favorite languages have a foundation, as long as they're used for large projects by large companies. That alone is a good guarantee that they'll stick around.
I think, to a degree, the growth in popularity in the language — coupled with the perceived value of whichever changes the current Go team won't make — will determine the viability of a fork.
If the popularity of the language grows enough, there will inevitably be new companies and ecosystems reliant on it and those interests may eventually band together to create forks they think bring value to their businesses.
Outside of that formula, forks will almost always remain niche and without significant investment.
A very well written piece by Ian Lance Taylor. If you don't want to read it all, he summarizes it here:
> 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 believe that every successful language must have a
coherent vision that is shared by a relatively small group of people.
He points out that there are over 100 committers, nearly half of which are non-Google; it's only the small group of people in charge of the language spec that are at Google.
It may be true that Google the company don't drive Go the language. However, simply working in the same company tends to make you take on the perspective and values of that company.
In the Xen Project, for instance, Citrix is the largest single contributor. Citrix management have basically left the engineers working in the Xen to our own devices; but nonetheless we've made a conscious effort to diversify the organizational membership of the core decision-makers in the project: partly to make sure that we're not drifting into a Citrix-centric groupthink, and partly to avoid the appearance of Xen being a Citrix-only project.
If I were them, I would be looking for an opportunity to arrange to have at least one non-Googler on the core Go team, for the same reasons.
I don't think he defined his terms very precisely in his document; but as my comment says, yes, there are two levels. There are people who can approve changes to the implementation of Go, and people who can make changes to the specification of Go.
There are 100+ people who can approve changes to the implementation; but there only a handful of people who can make changes to the language specification, and all of those people are at Google.
> the implementation of Go, and people who can make changes to the specification of Go
Should that be "the reference implementation of Go" ?
The specification mentions "implementation restriction" many times, so the Go spec writers seem to be encouraging other implementations. Besides gc, google also provide gccgo. If you download the gc source, change it a little so it still conforms to the spec, and publish, then that would be another implementation of Go. I believe there's an incomplete JS-based version of Go around as well, so if that's ever finished, that would be another implementation of Go.
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.
which is essentially the "benevolent dictatorship" principle; it's hard to swallow because developers tend to imagine open source projects as "owned by the people".
I believe too that projects "owned by the people" end like The Homer™, and I'm actually curious, as the author, about:
I would be interested to hear of a counter-example
works pretty well. Maybe C++ is a good example of this, and maybe that is a good way to build a language like C++, but it might be a bad way to make a language like Go.
Well, interestingly, "design by comittee" is a pejorative, so it raises the question whether C++ is, in a (specific, not universal) sense, a success or not.
C++'s design by committee is well-suited to achieve one of the key goals in the (ongoing) design on the language, which is maintaining extreme backwards compatibility and extensive mulling of potential changes by numerous independent interested parties so that changes that do make it in are nearly-consensual.
You could argue whether those are the goals a language should pursue, but it's pretty obvious a central designer with free reign would not have achieved those goals.
There's a lot more nuance in the original post, outlining that Go is fully open source & it can be forked. That the author believes any good open source project should have a coherent vision and a set of decision makers. That the actual committers to Go are majority Googlers but not overwhelmingly so (59 Googlers to 51 others).
There is more to Go than Google, there is a community and it is as free as can be. But the final decision makers are at Google. It's all very well said, every open source project has a set of final decision makers and that project is theirs. Unless you work hard to become one of those decision makers the project is not yours. And perhaps it is not notable to write the blog post "this open source project ACTUALLY belongs to so-and-so."
I was not really convinced by that line of argumentation either.
For me, the more convincing argument is that Go would have probably happened in a parallel universe as well. Imagine that Griesemer, Pike, and Thompson had worked another company that gives the freedom to work on personal projects, it is very likely that they had come up with the same language. They have argued in talks that Go was created as an answer to problems that they identified in the development of infrastructure at Google. That may have been a trigger, but Go is firmly rooted in the tradition of C, UNIX, Plan 9, and Limbo and a logical next step in that tradition.
Hence, to me, Go is really Griesemer, Pike, Thompson, and Cox' language and not Google's language.
Of course, the title of the original article that Taylor is reacting to was a bit sensational. But I think the original point was that Go is not a language that is developed by the community, but a small set of people. Whether they are employed by Google, Facebook, Uber, or Zalando is somewhat irrelevant to this debate.
I agree that it's worded confusingly, but I think I can see the point they're making. Solutioning usually looks vastly different when driven by a core team than when it's driven by higher-ups or "The Business". The Go Core team is likely more vested in the overall success of the language than the rest of Google.
I'm not certain, because - like I said - it's worded confusingly, but that was my impression.
Not at all. Google Chrome and Android are produced by Google too. And yet, the user tracking or advertising sections of Google have their interests met through Chrome and Android. If the Chrome and Android teams had only their users' interests in mind, ad blocking and tracker blocking would have been built into these products.
I think it's more like saying that there's no meaningful sense in which your body, apart from your pancreas, makes decisions about how much insulin your pancreas secretes. It is technically true, just... only technically.
My takeaway from this is that there is no active attempt to influence the direction of Go to fit Google's agenda and that's a good thing. However, active influence isn't necessary to shape Go's direction and functionality. Probably the best example of this are the twin canker sores of GOPATH and dep. Anyone who has wanted to develop multiple projects in isolation has run into issues with these two and the way that they work-but-don't-really. For Google, this doesn't and will never matter because use of blaze / bazel is assumed and any problems relating to GOPATH or dependency management were likely addressed eons ago.
So is this good that the team is crafting the language for their own needs? Perhaps they will keep the language small and keep scope creep to a minimum?
This apparent, but that's because there does not seem to be any obvious conflicts of interest - further diminished by the fact that they're all paid by Google, work for Google, and inherently serve Google's interest.
If push came to shove, and we saw a war between G and say ... Oracle, over a kind of 'programming language' ... you can be darn sure the claws will come out and it will be apparent 'who owns what' etc..
In the end it may not matter: Go is what it is, it's not set up for licensing or battle, so this all may be moot.
That's like saying "the politicians all made up their own minds being in favor of the new pro-corporations law" - the fact that 99% of their donations came from the corporations that benefit from the law is "irrelevant."
Nonsense. You don't even realize there is an underlying bias when you get paid by someone to do something.
Googler here, but these are my own opinions formed from less than a year at the company.
My observation of Google's culture is that it can be very difficult to see the ways in which they dominate projects they participate in because it's very difficult to keep perspective on how even small investments by Google tend to overwhelm the volume of other contributers project. Google has a lot of great, productive engineers and when they turn those folks fulltime to open source projects the results are very impressive. I feel this too with the open source work I'm adjacent to.
Go's situation is further exacerbated by the somewhat normal expectation at Google that programming systems often feel very top-down mandated to new employees (even if I think reality is that there is just a lot of cultural and tooling inertia there; in reality you can use whatever you want if you can make a case for it). The recent "fix Python's broken batteries" thing comes to mind as a conflict long overdue but suppressed by that culture of top-down mandates. Indeed, even without insider knowledge, rumors speak in hushed tones about how top-down GVR's leadership of Python was during his time working with Google. It seems like after he left, that notion has softened.
So even if folks on the Go project don't mean for it to feel like "google's language", it's still entirely possible that it does feel like Google exercises a lot of control over Go. This is a really significant and old challenge for big companies interacting with open source, but it's one that language teams have only recently started to really face at scale (see also: Rich Hickey's conflict with the Clojure community over overly biasing Clojure towards Datomic's interest and not helping to prioritize or yield resources or his oversight mechanisms to other people's needs).
The Go team was (and has been) also been slow to address the community's obvious and vocal need for some sort of templating solution. While it's fair to appreciate the difficulty of these discussions and designs, it's also the case that the Go project communicated their reservations rather poorly and created a lot of ill will that the language still suffers from today.
As languages are starting to open up and become more community driven (again, it used to be a lot more like this with small scripting language communities), the difference between a carefully guided language like Go and a language where anyone an contribute all the way down to the compiler and have a fair expectation of getting it included (like Haskell's GHC project) start to really contrast.
There are many of us in the Go community who like Go the way it is. The last thing we want is another Java ecosystem, which feels like something designed by archonaut committee more than anything coherent. Better to not have generics than to have generics that are bodged into the language like they were in Java.
> The last thing we want is another Java ecosystem,
Which practically contains almost everything one can think of? Yeah, like that's not a good thing. Where's the golang equivalent of Hadoop, Spark, Vertx, Netty, Akka, etc.? Not to mention the Java standard library with it's new time package, and java.util.concurrent, and many more.
> Better to not have generics than to have generics that are bodged into the language like they were in Java.
Strawman fallacy. Not to mention that generics in Java are not botched, they made a tradeoff and it paid off quite well, just look at the number of existing JVM languages. That beings said, there is work being done to improve generics in Java even more.
The Java time package has been a disaster for 20 years until Java 8, before that everyone was using Joda. As for generics have a look at what C# does for "proper" generics.
I'm aware of what C# does, that's why I said it was a tradeoff. Compare the number of languages on the JVM to those on the CLR to see why they made this tradeoff. The JVM folks are working on improving generics even further in upcoming releases.
I know about Joda time, that even another point in how mature the Java ecosystem is. There's no similar offering in golang.
> Compare the number of languages on the JVM to those on the CLR to see why they made this tradeoff
IMO the main reason why people aren't creating more CLR language is unrelated to generics. You can compile many languages to CLR bytecode and never emit these ldelem/stelem/unbox.any instructions. The main reason is C# is good language, and it evolves fast enough.
I don't believe Java developers deliberately crippled Java to incentivize third parties to develop more JVM languages.
Java Time is a renamed Joda Time with some improvements, from the same guy who did Joda Time. It's a pretty great example of Java being defined by its community actually.
You think it's a good thing. The parent doesn't. So isn't it better that both Go and Java exist, rather than Go be Java-ised, so you both get what you want?
> Strawman fallacy.
It's only a straw man to those who like the tradeoff. Tradeoffs are always a matter of judgement. The parent (and many others) make a different judgement to you. So isn't it better that both the Java and Go approaches exist, to satisfy different tastes?
This is my biggest worry about the future of Go, that it will gain enough adoption at enterprise shops that we'll end up with another Java-esque ecosystem. So far it has seemed to have avoided that trap, but it is still a young language.
I am ... Quite surprised to see folks arguing that Java has "too many" features. For a log time the problem was we couldn't get ANY new language features through committee and so we were resorting to outrageous hacks.
The only people in my experience that complain about the Java ecosystem have limited experience with Java 7 or before and haven't done any real modern Java development in many years.
I've been using Java since it was released, and (at the same time) Go for several years now.
The amount of cognitive overhead in dealing with all the history that's baked into Java is really annoying. Things like the dated concurrency model, the overachieving in logging (and other) libraries (when one to use?), the poorly thought out I/O libraries, the crazy build tools and slow builds, ... It's always a relief to get back the the smoothness of Go.
There is a notion here that the community is unified and all the core team needs to do is listen to the community and do what they say. In reality the community is too large to get a grip on and has conflicting ideas. You can run polls and read online arguments but in the end this won't result in a design.
There is a good point about fulltime, and nothing specific to either go or google.
Lots of opensource projects get by largely on the evenings-and-weekends contributions of a (often small) number of contributors. Sometimes managing to find resources for a full time person or two at the core.
There are a ton of great, productive engineers out there. Some of them contribute across a number of projects in their "spare" time. It's easy to understate the impact even a small, mostly full time (or at least solidly part-time) team can make on a project.
Any company willing to put it's money where its proverbial mouth is like this can easily start to significantly affect the direction of all but the largest OS projects. You don't have to be google sized, you just have to effectively vote with hours (e.g. $) spent. The governance model of the project may help or hinder this to some degree, but in the end results speak (or a fork is likely).
Go is not the only such project. For how long did linux hw decoding patch for chromium wait for being merge?
And it's still not merged because of the "maintenance burden" (needless to say big linux distros maintain this patch and apply it to their chromium packages just fine).
Android hw support is merged, no problems. Oh, and Chromium OS has hw decoding as well, while having 0.0001% market share. Because it's a google's product.
For google open source is nothing but a way to obtain free labor and make more money. These are their products, meant to make money for them. Others are mere free contributors.
> Rich Hickey's conflict with the Clojure community over overly biasing Clojure towards Datomic's interest
I’m not sure I would describe it that way. I don’t know of anything in Clojure language that is biased towards Datomic’s interest (or Cognitec’s). The conflict was about Rich not having enough time to consider/review/accept changes to the language core and declining to relax acceptance of such changes without his sign off. It’s a problem and it doesn’t sit well with some people in the community, but it really is very different from your accusation.
Having been a part of that conversation and mad enough about it that I've effectively abandoned the use of Clojure: I am quite certain I'd describe it that way.
My experience with this conversation is that there is nothing I could say that would make you ever acknowledge my experience or feelings. Even the act of stating my opinion on a subjective matter is getting downvoted, because folks are so eager to NOT talk about this except under the lens of Hickey making shirt jokes.
And it drives home the actual point I wanted to make about how some languages are in theory forkable, but in practice are very much run by a central figure who exercises powerful social control via the inertia of prior involvement and the social power of the community eager to defend them.
> 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.
I'm continually surprised that more of the greater, vocal community does not grok this.
I don’t think the issue is a small group of people holding a vision. For me, the issue is that a company changes the vision based on some unknown goals that the company has that are not known to the community.
I think it’s disingenuous to paint this as a tyranny of the masses type situation as no one is calling for democracy. And even if they did, Apache and Python are showing successes in that area.
If google wanted an OSS language, they would have non-google committers. It’s perfectly cool to have company run languages. I think people just need to be aware and not confused that Go is anything other than Google’s language that we all get to use for free.
For me, with almost all things google, the risk is when Google grows bored with this and makes all the employees work on other stuff.
> And even if they did, Apache and Python are showing successes in that area.
I find both of these communities to be huge turn offs. I think Apache projects and Python demonstrate varied quality; design by committee.
Conversely I find Go releases to be pretty high quality. When they are marginally suspect, I tend to find the strongest critics are members of the Go core team (e.g. future of http, sql packages).
> If google wanted an OSS language, they would have non-google committers.
I don't buy this line of reasoning. Go has been extremely welcoming to contributors. You don't need to be a committee to contribute. Are the thousands of projects open sourced by corporations under their corporate GitHub account not _true_ OSS to you?
> For me, with almost all things google, the risk is when Google grows bored with this and makes all the employees work on other stuff.
I understand this, but it's FUD. We've heard nothing but positive feedback from Googlers (no "they won't let us do X"), and if this _did_ happen, I would expect the existing committers to rebel sufficiently (i.e. quit) that this problem solves itself. Until then, I see no cause to warrant a change in management.
More to the point, they correctly perceive that that specific small group of people are acting on behalf of a evil corporation, rather than based on a coherent vision of what a successful language should look like.
Fred Brooks said it well in the Mythical Man Month:
"the sheer number of minds to be coordinated affects the cost of the effort, for a major part of the cost is communication and correcting the ill effects of miscommunication (system debugging). This, too, suggests that one wants the system to be built by as few minds as possible."
Whether I grok this or not doesn't really influence the behaviour. Option 1: to change the language I need to say what I want. Option 2: to change the language I need to influence the small group of people enough... by saying what I want.
Option 3: you write a coherent proposal of a quality comparable to those written by the committers and work with them to implement it, possibly becoming a committer yourself and getting hired by google in the process.
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.
And again
Many people will provide input to this decision,
but no successful language--indeed, no successful free software
project of any sort--is a democracy.
The fact that Golang has no generic is a huge thing. I've read countless amount of code that abused generics (unfortunarely developers think they have to use generics all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it generics could only be used when necessary, yes, but there are no technical way to enforce this.
Gofmt is the second blessing. All codebases look the same because it is not customizable. This makes reading Golang code and understanding it fast as hell.
The GOPATH is also a huge win. You always know where everything is and it is really fast to figure out about dependencies or structure of the project.
What I'm saying is that in my years of security consulting, Golang codebases have always been the clearest ones to read and have always been the most secure ones.
I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Golang.
> The GOPATH is also a huge win. You always know where everything is and it is really fast to figure out about dependencies or structure of the project.
Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't. It's not enough to have a cool idea for a language, even if your cool idea is not to put any new cool ideas in the language. You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real and will be supported for many years to come, and will have a healthy ecosystem. If I had made Go, no one would be using it right now. Network effects matter in languages. People want all the upsides of the network effects (i.e. the ecosystem and adoption), but none of the downsides (it's propped up by a big company with massive network effects).
History doesn't really support that. PHP, Python, Ruby, Tcl, OCaml, Lua. Successful programming languages seem to come in equal measures from both large corporate backers and not.
There is certainly the need for network effects which large corporations often can provide more consistently, but we have seen plenty of examples within the space where individuals or smaller companies have been successful in providing these same network effects.
Many of those languages came out in the 1990's when the big corporates were busy pushing visual 4GL's to replace programming languages. But programmers prefered to write a Perl ten-liner rather than fire up a visual environment, click on some toolbars to place some widgets on a form, link in the data files using the right-click form, wait while the OS thrashes the hard drive as it paints the screen for the first test, and on and on. When those corps realized they'd dropped the ball, they soon built their own.
I worked as a programmer in the 1990s, when I got paid to write things in C, C++, Perl, Khoros (I guess that's a "visual 4GL"?), IDL (the array language), VB, SQL, INFORMIX's horrible forms thing (which was not especially "visual"), sh, csh (not my fault), and occasionally Tcl. It's true that PHP, Ruby, Tcl, OCaml, and Lua came out in the 1990s (Python is from 1990, so arguably the 1980s), but they became widely used in the 2000s. In fact, even Perl was considered kind of déclassé until these "lightweight languages" took over the world, and then Perl became déclassé again after being eclipsed by Python, Ruby, and most surprisingly, JS.
(OCaml is not a "lightweight language" and is not like the others, and consequently never became popular.)
I don't recognize your description as corresponding to any events I remember. Sun was pushing Java. Microsoft was pushing C++, then Java, and then when Sun sued them, C#. Apple wasn't pushing much of anything until they bought NeXT, and then they started pushing Objective-C. As far as I know Oracle was pushing PL/SQL and cisco was pushing bletcherous IOS commands. Microsoft was pushing VB, which sort of resembles what you're saying, but VB wasn't a 4GL (the language was just 1960s Basic minus line numbers and plus subroutine arguments) and was actually spectacularly successful at what it did; it just wasn't good at making web sites. Borland was pushing Delphi. I guess in a way Microsoft was pushing Access? Are you thinking of Microsoft Access?
Maybe you were thinking of PowerBuilder? It was spectacularly successful at what it did, too (again, not building websites), and it was a visual 4GL, but it was being pushed by Powersoft, not a big corporate, until (Wikipedia tells me) Sybase bought it for 0.9 Instagrams in 1995. I never saw anybody use PowerBuilder but I didn't use Microsoft Windows a lot.
When you say, "they soon built their own", do you mean VBA and PowerShell, or what?
> Microsoft was pushing VB, which sort of resembles what you're saying, but VB wasn't a 4GL
Every marketing department was calling their company's new software development product/language/whatever a "Fourth Generation Language" back then. There's no actual definition for what it really means. Perl, Python, Ruby, and PHP represent a trend that peaked the 1990's, some came before and some after, so there's no need to read "1990's" literally.
My total memory (i.e. work, study, and hobby) of that extended decade (1985-ish to 2005-ish) was VB, VBA (Access, Excel), Java on Windows, Quattro Pro, dBASE 3+, Perl, Cobol on IBM (and ICL), and a myriad other obscure mainframe languages and mini-languages that probably still get used in banks and insurance companies.
> I don't recognize your description as corresponding to any events I remember
My previous description of that time was quite typical for many of us. For example, I remember in 2001 developing a five-line Word macro for an accounting department on a leftover 386 sitting in the corner running Windows 95 that read in a file couriered in daily from some other company's Unix system that stripped out some incompatible data from each line. After I deployed it into production, the user every morning started Word, opened a Word document that contained a button on a form, clicked on the button, selected the day's file from the floppy, then waited (at the water cooler) while the macro ran. They then renamed the output file so the date was in the name, and copied it from the LAN to the mainframe using some proprietary program, so it could be input (with the funny Unix bytes removed) to the overnight processing run. Perhaps you worked in the other company sending that Unix-based file to us every day, and didn't see the ongoing after-effects of your C++ program that produced the file.
Python came out of CWI in the Netherlands, where Guido van Rossum worked and had previously developed the language ABC. OCaml came out of INRIA in Paris. So both had institutional backing and financing.
While it's certainly a form of institutional backing it's very dissimilar to Google as CWI and INRIA are both research institutes. They would have their own network effects within research and academia, but that doesn't necessarily translate to wider scale adoption.
That's sort of why I threw in OCaml; largely it is still only successful within academia. Python on the other hand had similar beginnings, but has been wildly successful both in academia and in common use.
in the early 90s the languages had to provide fewer features to be considered adoptable. Once people adopted that language they had to expand it.
Nowadays if you want to create a new language there is a minimum set of features everybody expects that raises the complexity quite high. You could just create a bare language but who would adopt that?
Isn't that kind of what Elixir and Clojure did? Neither language is festooned with bells and whistles and both leveraged the Erlang VM and JVM respectively to assist in bootstrapping their ecosystems.
I assume OP meant that Elixir is a purposefully small language. It taps into a lot of functionality in Erlang without necessarily re-implementing it. There isn't even a wrapper around the Erlang :sleep function.
Well to be honest there's a lot of functionality in erlang you should probably forget about (like the :http and :tftp modules).
Not to hate too much on erlang, but I would say that beyond being small, as a pushback to characterizing it as "bells and whistles", Elixir brings to the table "21st century" understanding/opinions on what makes for readable and maintainable code (build packaging, first-class documentation, module organization, file types, strings, map-focused vs struct-focused, sane function parameter ordering). As a result, I can confidently onboard a junior into Elixir (especially if they were in a RoR bootcamp) and have them be productive. I probably wouldn't for erlang.
is that actually true or is that true of a vocal minority? I've been using Go since 2011 and I'm perfectly happy that it's Google's language; I'm happy to mooch off of their investments. In my seven-plus years of using Go I have never encountered a Go programmer in real life that is actually mad about this.
I think the "everyone" in that statement refers to those who are upset. It probably could have been more accurately phrased as "People are upset that Go is Google's language..."
As to your not encountering a Go programmer who's mad about this, I think that's because you're considering people who are already programming in Go. I suspect people who care never actually start using Go because of their thoughts on Google's involvement. (For the record, I too am fine with it, especially after reading Ian Lance Taylor's response.)
> I think that's because you're considering people who are already programming in Go
um I talk to a lot of programmers that don't use Go. Most that don't use it decide not to use it because of either the type system ("it's not safe/expressive enough") or the garbage collector. I've never talked to someone that said "Go is technically good and I think it would be a good tool but I won't use it because of Google".
That's fair. I only made that assumption because you specifically said "I have never encountered a Go programmer in real life that is actually mad about this"
ah yeah makes sense. Honestly "I have never encountered someone that doesn't use Go because of this, or a Go programmer that's mad about it" is probably a more complete sentiment.
If I had made Go, no one would be using it right now.
It would be really frustrating for you, because assuming people found out about your language in the first place, it would be shot down for not having generics (or something else), and there wouldn’t be any Google fanboys to come defend it. So much of what’s popular is determined by which company is backing it, whether people want to admit that or not. Pure bandwagoning.
I know of more than one organization that have decided against Angular in recent years primarily because of Google's backing of the project. Skepticism of the big three (four?) tech giants is growing, especially if you've had some of your market carved out by them.
Yehuda Katz said something a while ago that stuck with me. He likened Ember’s community model to Postgres. That is, relatively small levels of support from lots of different organizations. I think there’s a lot of wisdom is such an approach.
Pleasing all pleases noone. Successful products and projects come from a vision that is executed with discipline. Design by committee never works if the committee reaches a certain size. Instead of whining and trying to sabotage Go, why don't you fork it and apply your misguided product management ideas to the soon-to-be-forgotten fork instead? Applause to the Go core team, inside Google or outside it, for creating a great language. Please keep it up!
> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.
Brand recognition is not that important for programming languages. It does skew decisions a bit, but people still have to make too many of them when moving to another programming language, so the effect is not that significant. Go just happened to hit all the right spots for many programmers at the time and a bit of marketing turned that into some adoption.
> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.
I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".
As of 2011, Matsumoto is the Chief Architect of Ruby at Heroku, an online cloud platform-as-a-service in San Francisco. He is a fellow of Rakuten Institute of Technology, a research and development organisation in Rakuten Inc. He was appointed to the role of technical advisor for VASILY, Inc. starting in June 2014. - From https://en.wikipedia.org/wiki/Yukihiro_Matsumoto
Japan. With roots in Japan, Ruby was very popular throughout Asia in the earlier days of the language, before Rails.
Granted, this support was perhaps more cultural than corporate. There's something to be said for a community that grows in your own backyard, has significant documentation in your native language(s), etc.
JavaScript is an interesting case, in that it was the only way to write code that would run in Netscape Navigator at the time. In a sense it had Netscape behind it, and then it had Microsoft behind it once they reverse-engineered an implementation for IE3.
I'm not very familiar with the history of Python, though it seems it was funded in its early years by various research institutes that employed Guido van Rossum, rather than a giant corporation.
It certainly is in the last decade or so. Python is a language from the early nineties and took decades to achieve it's current level of popularity.
Javascript was backed by Netscape, and later by Microsoft/IE. It would never have succeeded without corporate backing and being on of the 2.5 usable languages on the web (Java was the other one, I'm counting ActiveX/VBScript as half)
Python was picked up by companies like Red Hat at the end of the nineties (e.g. in the Anaconda installer). So in Linux circles Python had already gained quite a bit of popularity.
Is there really much practical difference between that and Go? From the Ian Lance Taylor response:
> 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
Google employed the primary maintainer of Python and paid him to work on it. You asked "did they have a giant corp behind them", the subtext there being that you could complete the sentence "as Go does". I'm merely pointing out that your example of Python is strikingly similar to Guido Van Rossum working at Google while he was BDFL of Python
Of course it matters. That's the whole reason the Go Is Google's Language post exists. And the whole reason the response exists, and this very comment thread, too.
> 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
That is a ver very strong assumption. Just because Google did not explicitly have a ‘GO’ team does not mean they did not support it. I assume Google became aware of it the moment their employees started using it for something useful. People have bosses who have bosses. At whoch point they decided to let their employees continue working on it.
> ...but no one would have adopted it if it weren't.
It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can work effectively with parallel/concurrent code. In many ways it's Java done right, or a more intuitive (and from certain POVs, preferable) alternative to Haskell and Ocaml. That would seem to be enough to drive adoption.
Go shot past similar languages because Google's backing got lots of instant attention from people who would never even hear of something like Nim or Clay.
Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1].
Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off.
I'd argue that readability is better in Java due to things like non-clutter due to error handling, and the existence of generics.
Deployment has been solved for a while now with building shadow jars[1].
Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.
So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here.
And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.
Object pools are really easy.
Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself.
Yes this is better than relying on the end user/admin to tune things. It is more predictable.
I don’t understand the comparison to Haskell or Ocaml; those languages are not C like and have a much different philosophy on the responsibilities of the language and type system.
Haskell is not C like? You can write Haskell with curly brackets and semicolons, just like Go! I rest my case.
No, but seriously, you didn't get what I was saying there. The whole reason Go might be of interest is that it is loosely C-like in a way that Haskell and Ocaml are not.
That true, and I still don’t get what you are saying here. In my mind, they are different languages which appeal to different developers and fit with different requirements. I don’t see it as an alternative to Haskell any more than any Turing-complete language is technically an alternative.
For a long time D wasn't open source, didn't work very well on Windows, had a very limited standard library, and had poor IDE support. There's also a large divide in the community around garbage collection vs manual memory management.
I don't necessarily agree with the parent's point but D managed to fumble early on and never managed to catch up ever since. Around the time it got released (in the early 2000's) I was a C++ coder and I remember being very interested, only to immediately dismiss it as soon as I learned that it wasn't fully open source. I'm sure other devs didn't mind as much as I did but it definitely stunted growth early on. By the time they fixed this "issue" there was a lot of competition in that space and I never bothered looking back.
“It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It” —- Google employee’s defenses of Go
Even if it is theoretically true that Go is open source, by employing the majority of the Core Go team, Google exercises extensive soft power over Go. All of the defenses of Go seem to gloss over this.
While in general, I agree with that quote, I don't think that we have a problem with the Go core team in that respect. I think they do understand the problem but don't really have a solution.
I mean, the community has (so far) just a few cases were decisions of the core team were 'not so good'. Sometimes because we didn't like the process and sometimes because of the outcome. But I guess, in general, the majority of Go users likes what the core team does.
The problem is more about that many of us have a problem with Google (for a myriad of reasons) and seeing that the core team is tied so deeply into that company makes us worry about future decisions of the core team (as you said). But what could/should the core team do about it?
This is partly why, from the perspective of another person at a company working on a language used by people, it's important to:
1. Embed yourself in the community rather than shy away from it. It's impossible to escape the criticism of "acting on behalf of the company", but being a member of the community can certainly help perception problems
2. Act more slowly on accepting things so that as many voices as possible can have a say
3. Scope what you do to what you're capable of doing _well_
Even if a given feature for a given release isn't what the majority want, people will use it if it solves a problem and is designed and implemented thoroughly.
Agreed. It was interesting to see self contradicting things in the post of how management doesn't control anything and yet people somehow get hired into the core team. And it's not just soft power. Google can actually hire people that serve its interests well and fire those that don't. This is pretty much as much power as possible to have over a project.
Exactly this. And this mailing list post exemplifies that even Googlers don't realize the soft power they have.
How many of us get to be lunch or drinking buddies with Russ Cox or Rob Pike? Googlers have much easier access to both than the external community and those are really the only two that matter.
This situation feels similar to the need of politicians to divest any potential conflicts of interest. I would not accept “just trust me” as a response. As long as there’s a possible conflict of interest, there will be ethical concerns.
Yes, but they are both still conflicts of interest. Also as the other poster mentions, as Go accrues popularity, it is not always as easy as picking another language.
It's not easy picking another language no matter its popularity, but switching languages and stacks is not uncommon in our industry. In this case it's also entirely on you and your team to achieve success with that switch. This is not at all analogous to a government system.
News Rooms and Editorial boards all swear that management never asks for any changes (and they'd all quit if they did!)
I think it would be productive to try and list areas where Go would be different if it wasn't at Google. Some examples: C integration, loading plugins, desktop GUIs.
I'm both surprised and unsurprised that this quote is so far down the page. The little twists and turns in the OP are the typical detail-oriented rationalizations of a very smart individual, who has given himself to the group and doesn't want to admit it.
>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.
No, but like with the community developed dependency solution, Google can arbitrarily chose not to include it in Go, even if itself proves successful.
So it's more like saying "you can have your own niche ports, just don't expect them to become part of the main language".
But this is the same with any open source project - you can write as much code as you want, but if those with the commit bits decide they don't like it, it's not getting upstreamed.
If you were really keen to push some functionality into the Linux kernel, but Linus decided he didn't like it, you'd be in exactly the same position. The fact that in Go's case quite a lot of the maintainers work at Google doesn't really change much.
>But this is the same with any open source project - you can write as much code as you want, but if those with the commit bits decide they don't like it, it's not getting upstreamed.
Yes, but seldom those with the commit bits will so blatantly disregard the community as with the case of the community developed dependency solution (and other cases).
Especially in projects where those with the commit bits are voted, there would be riots...
It also does since those calling the shots are not just some community members among others that just happened to start the project, but people with job security working on the language, with the money of the biggest sponsor of the language behind them, hosting the infrastructure, doing conferences, and so on.
So it's not a level playing field with another contributor.
> No, but like with the community developed dependency solution,
Unless you are deliberately trying to obscure the facts. Sam Boyer et al are no unanimously elected community leaders whose solutions somehow must be included with main distribution.
> So it's more like saying "you can have your own niche ports, just don't expect them to become part of the main language".
This is exactly same for all open source languages, if core maintainers do not like the your change either fork it and implement or use any other language which gives you feature you wanted.
>Unless you are deliberately trying to obscure the facts. Sam Boyer et al are no unanimously elected community leaders whose solutions somehow must be included with main distribution.
Unless you are deliberately trying to obscure the facts, this is irrelevant.
Their project seemingly had the blessing of the core team, it was touted as a community effort, it was adopted and tested by the community at large, it was presented and critiqued in public discussions, and so on.
And then it was shot down, unilaterally, and replaced with no discussion by a never before seen implementation from a core team member.
>This is exactly same for all open source languages, if core maintainers do not like the your change either fork it and implement or use any other language which gives you feature you wanted.
Not really, many open source projects give the community a chance to vote on such things, have core team members that are voted into place, and go out of their way to adopt popular community extensions (as opposed to implement their own core-team only versions).
It wasn't arbitrary. The community dependency solution was half-baked: it couldn't support the case of dependencies relying on multiple major versions of the same module. Even Rust is very careful to allow this, and nobody would describe Rust as being anything other than community-led. That this was the issue was made very clear by tye folks who criticized that solution, btw.
I feel like some people/groups are obsessed with community owned/open source languages/infrastructure. At the end of the day, most of these are controlled by a small group of individuals and we put different wrappers around them/labels...
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.
That's a great little story. As an IC, I always felt that VP's, Staff, etc would know everything about what was going on in their organization. This story lets me know that even at that level, they don't know everything.
Honestly, I'm very confused by all this. Don't like it, fork it no? Isn't that the whole point of open source? Any project needs to have a certain set of people in charge of making actual decisions and working on those. You'll never have every single user be a part of that decision making. It wouldn't scale.
What language is not driven by a handful of decision maker? Even what could be argued to be committee driven languages, like say Java, are very much controlled by a handful of committee members.
It's hard to trust a bunch of people employed by a megacorp to make all the decisions about the project you rely on. But easier to trust independent people, closer to the users, maybe even voted in by the users, like democracies do, not like top down only ruler's interests matter dictatorships.
No. Forking a language is very difficult from forking an application (which is itself a Herculean task if the app is big). And few end-users of a piece of software will switch to a fork with much less backing because of soft-power influence or governance model.
Is there any incident where a patch that was antithetical to Google’s business interests that was specifically blocked by the Go core team? If not, then I’d say there’s nothing to see here.
> 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
Power and control aren't about whether you've attempted to change something, they're about whether you can change something.
If Google ever had a conflict between the core Go team vs the people who make money for the company, you can be sure who will win out in that debate. Saying that it's never happened before or that it's unlikely to happen doesn't change the fundamental power dynamics that people are upset about.
Those conflicts have existed for years (since go was created in fact) and despite your claim about who is "sure" to win, it turns out you were wrong and continue to be wrong about who wins.
I always wonder why HN is full of people who are so sure of the outcomes instead of asking for data about what actually happened.
Its definitely easier to just assert things than ask for perspectives and data that might conflict with your own experience, but you are rarely going to learn anything interesting that way.
>> 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.
Or, what would happen if non-google employees on the core Go team were to take Go in a direction that Google's leadership didn't want to?
I definitely feel that Google owns Go and it is a language designed for Google's purposes, but that didn't dissuade me from using it. It only makes me not want to contribute to the core language, just as Google's control over Chrome makes me not want to contribute to chromium.
Keep reading; further down the thread, Rob "Commander" Pike found it "a surprise" that Google trademarked Go. Maybe Pike feels that Go isn't Google's language, but it certainly seems that Google does indeed have a modicum of control over Go, and that that control is above and beyond the Go authors' perception.
Of course not, it's not Google's language, it's Rob Pike's language. The logo was designed by his wife, and most of the questionable design choices in Go are there because of his opinions, such as the dubious dependency management and lack of generics.
A lot of the power of go comes from it being opinionated, but that same opinionated approach is a real pain for some (it turns out common) use cases. With all that said, Go is my language of choice, and I'm happy that Rob seems to be less involved with Go 2.0, and that the core Go team is incorporating user feedback rather than just dismissing complaints as Pike seemed so inclined to do.
> Many people will provide input to this decision, but no successful language--indeed, no successful free software project of any sort--is a democracy. [..]
> As I said, that is my opinion, but I think it's true. I would be interested to hear of a counter-example.
Debian is 1000+ developers with a constitution and voting system.
So if it isn't Google's language, does it mean i can go and make my own compiler for it, call it -say- "Crinus Go" (to differentiate it from Google's Go but still point out that it is an implementation of Go) and not worry about Google coming after me?
The open source license allows me to fork the implementation of Go, but not use a derivative of the Go name for my derivative of the Go implementation (to ensure/show, among others, that people know that my work is about Go and not some other language or something i came up with).
The original toplevel comment was about making a new compiler, not a derivative of an existing one, the comment you reply to is a continuation of that discussion not a standalone comment. The implication here is that the open source license is about a specific implementation and only covers that implementation but it doesn't cover its name, as you rightfully point out. Munificent wrote that the open source license protects you if you decide to create your own Go compiler and name using a derivative of the Go name, but this is wrong since the open source license does not cover the name.
If it's an actual, standards adherent implementation of Go, nobody should a shit what you call it. If it actually changes the language spec, then you would have to rename it for legal reason, but you should also want to rename it - unless it's a backwards compatible superset of the language, you wouldn't want people to think it's YAGC and just feed it their vanilla Go code and be surprised when it doesn't work.
How does the adherence to Go's spec of a compiler affects its legality with regards to the compiler's name? And why is that an exception if it is a backwards compatible superset when a new version of the "real" Go could come out with new features that are incompatible with the extensions (thus rendering the previously compatible superset now incompatible and presumable illegal)?
And these articles are about Go being Google's language, which is empirically and legally true.
Different from C. I can write a C compiler with extensions and release it, call it C or "Something-C" and no IP problems. I can even call it Standard C and even if it's not no one can do anything. I maybe can't call it ANSI C if it's not standard compliant, but that's because ANSI is a protected term, not C. And unlike Go.
Now let's assume it's not true.
In that case Go is not Google's language and there are no ip issues. I can make and release a compiler, call it a Go compiler, and I'm fine.
Which is it? Unsure. I find no information suggesting Go is trademarked. But there are people like in your post claiming that it is. If so that should be easy to cite. I really don't know which it is. So many people claiming the word Go is protected. Perhaps they have better references than I could find and we can figure out what sort of language Go really is.
I'm not sure what you're arguing. You certainly have the right to fork GO and release your fork. There may be restrictions on what you call that fork (as in, you may not be allowed to use the name 'Go' anywhere in the name) - but that's a separate issue.
> The name Go is not trademarked by Google, at least as a programming language trademark. There are other things Google makes called Go (an interesting signal on its own) and they might be trademarked, but Go the language is not a trademark.
I'm not confident I'm correct only because it seems unlikely Google would have a page listing trademarks it doesn't actually own. That being said, I'm pretty sure there's no other place to search for trademarks.
I also don't think there is actually a trademark on the term "Go" based on this USPTO search: http://tmsearch.uspto.gov/bin/showfield?f=toc&state=4809%3Ax.... But admittedly I've only looked through five or six pages; using the option to search for an exact term doesn't seem to cut down the search results at all.
> it seems unlikely Google would have a page listing trademarks it doesn't actually own
Putting a ™ symbol after a name is only a claim on that name to be one's own property for use as a mark on some product or service when trading, and big corporates do this all the time. So I think it's likely Google would have such a page.
> I also don't think there is actually a trademark on the term "Go" based on this USPTO search
There's a distinction between a trademark and a registered trademark. Registering the name in some jurisdiction's database just means the corp has begun its defense of that claim before it sees a perceived infringement.
I would imagine everyday words like "Go" (or "Groovy") wouldn't be accepted by the US trademark office anyway, so perhaps Google tried but failed to register it there. They might get "Golang" accepted but the Go team have said the name of the language is "Go" not "Golang".
Goods and Services IC 009. US 021 023 026 036 038.
G & S: Computer programs and downloadable computer programs that implement a computer programming language for use in developing, building and managing other software.
FIRST USE: 20091110.
FIRST USE IN COMMERCE: 20091110
Standard Characters Claimed
Mark Drawing Code (4) STANDARD CHARACTER MARK
Serial Number 88100955
Filing Date August 31, 2018
Current Basis 1A
Original Filing Basis 1A
Owner (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600 Amphitheatre Parkway Mountain View CALIFORNIA 94043
That is splitting hairs, the name is part of the language - it is how you refer to it, you cannot remove it. If i name my implementation Glag it wont be Go, it will be Glag which just happens to be compatible with Go. Someone using my compiler wouldn't be using Go, they'd be using Glag.
As such, since the Go name is "protected" then the language itself is "protected" even if the protections allow you to contribute your time to Google's language.
> If i name my implementation Glag it wont be Go, it will be Glag which just happens to be compatible with Go. Someone using my compiler wouldn't be using Go, they'd be using Glag.
You can fork Go, call it Glag, and you will have a language that is interoperable with Go. In fact, it is Go - you just changed the name. And this is perfectly OK to do.
If I take Spanish, rename it Bogolog, and start speaking Bogolog around Madrid, people will understand me. Why? Because it's the same language they're speaking, I just changed the name.
I'm not so sure. Technically the name isn't Go, since that was already a protected name in use by someone else. So it's "Golang." And if "Golang" is acceptably different from "Go," I don't see why "Cnus-Go" shouldn't be different enough, too. It seems like at the very least you'd have to call it "Cnus-Golang" in order to start infringing on their IP.
Go is a Thompson/Pike language and neither suffer fools gladly. I've had only the briefest, AUUG and related unix conference type interaction with either and claim no special privilege or insight but I do know people who worked with them in a deeper sense, and I spoke to them in times past about both people (and Ritche)
If they decide on their own formidable intellect they want something they do it, and if they can be convinced by others intellect they may do it, but simply wanting it is not enough to get over their bar.
Pike is more curt. But I think both of them stand by a principle: Don't waste our time.
"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. "
I kind of read the original argument that Go is dominated by a "Google point of view", and there really isn't a significant alternative view that's as coherent. And that may be a risk.
It's not obvious to figure out how Go "plays with others". And it's unclear if that's much of a risk or not. As an outsider, you read of the funky module system duality and you wonder... "What if I don't want to 'work like Google'? Will this work in the future?" It's actually not that clear.
It's weird, because I don't get this sense, for example, with Kotlin projects in Android. You can write Kotlin in Android Studio. Or, in IntelliJ for backend code with Spring. And the tooling seems to be oriented in the same way. For most devs I've met, you can just swap Kotlin for Java, and everything else just works the same, and they don't get lost. You never have this sense of "well... _Google_ does it _this_ way..." when it comes to the tooling.
It _might_ be an institutional risk for people, who are evaluating tooling, to just decide that they don't see other major companies getting involved, see a bunch of gripes about the module system switcheroo, and decide "nah".
You really get a sense of "this is Google's approach" with the go toolchain, because it's pretty unique. One of the first documents, "How to Write Go Code", sets up a workspace that doesn't clearly integrate in with any other toolchain I'm aware of.
So, just by reading about the ecosystem, it's not clear who is really investing in it, and, you have a single, unique approach to tooling apparently dominating.
I just wonder if these arguments would be mitigated if Go ever got the investment in "developer relations" that other Google projects get, with some better onboarding documentation.
That seems like a special case. Kotlin swaps in easily because it was designed to be compatible with Java, and you've bought into the Java ecosystem already.
For someone coming from a different ecosystem, it would be a big jump.
It's just interesting because Android seems to be much more "externally focused", as opposed to Go, which seems much more of "here's an internal tool you can use".
Kotlin and the community version of IntelliJ came along _way after_ the Android toolchain was already available, and Google basically shifted gears and adopted it. Android Studio switched from Eclipse to IntelliJ, and Kotlin is now a default language.
I just don't see that kind of change ever happening with Go. There's no "other voice". It feels like it's "Google with a few enthusiasts".
A lot of technology development happens at Google and FB and AirBnb these days because that is where the money is, so that is where the smart people go. In the previous generation they would have been at Xerox or Bell Labs. The work they do is often generic and of general interest. We should resist the idea that because the creators are sojourning in the bosom of some corporation, that corp "owns" the work. This is a key benefit of open source: we can take the freedom granted by being useful to monopoly capitalism and use it to liberate work for the public good, thus diffusing that monopoly power.
In practical terms, however, this means governance has to eventually flee the bounds of its corporate origin.
EDIT: Whenever I make this claim here it gets downvotes, but I've never heard anyone explain why - anyone care to explain?
The work you do at a corporation is owned by them by default. You need to arrange for releasing it as open source. (I agree that some places are generous about this, and that's great!)
Also, there were some serious intellectual property disputes in the early history of Unix, which you're ignoring. Things are better now, but it's not something to be taken for granted.
That's a pretty good perspective; lemons to lemonade type of reasoning. If you have a centralization of talent and money, it easily leads to monopolization and stagnation, but if you manage to sail against the wind, so to speak, and you coerce that gigantic cluster of capital into outputting open-source, interop-friendly tech, you've hijacked the monopoly machine for the common good. However, it _is_ sailing against the wind: if Google wasn't good at preserving the monopoly and we weren't bad at enforcing fair competition and regulation, we wouldn't be in this situation.
By the way, what did you mean by "the corporate origin of governance"?
Edit: I second the call for more discussion on this. I think parent is making a valid point that doesn't merit an off-hand rejection by downvote.
However, as Google has learned recently to their dismay, its workers have power; they can wrest things from corporate power through their collective (or individual) action, and there may be little that they can do to resist. Sailing against the wind is annoying, but we've been doing it for thousands of years: https://en.wikipedia.org/wiki/Tacking_(sailing)
> This is a key benefit of open source: we can take the freedom granted by being useful to monopoly capitalism and use it to liberate work for the public good, thus diffusing that monopoly power.
In theory. In practice, a fork on that scale rarely happens because it would require a large part of the community to adapt, lots of supporting services to switch etc, which is unlikely to happen unless it's a major issue like "oh btw we're shutting everything down next month". Convenience keeps developers with how it's currently working, and developers are the community.
Why does it have to fork that hard? C is used everywhere; there are ISO standards for it. UNIX also escaped the bounds of AT&T a while back as POSIX. The same could happen elsewhere also.
Because most will (sooner or later) become incompatible as goals diverge. You're right that it could happen, but I don't see it as likely, be that a programming language or a tool.
Slightly unrelated, but has anyone heard of and used Fantom https://fantom.org/ before. If not, and you like Go, I recommend you check it out. It's a great language which I wish was a lot more popular. Similar to Go, it only has Generics for core data-structures. They have similar reasoning as well, that beyond those use cases, they're almost never practically needed for the amount of complexity they add to the compiler. It has first class Actor support for concurrency, as opposed to Go'suse of CSP. And its standard library is awesome. It's a very small community, but worth a look.
I’m a bit upset by the assumption that a Democracy (in this case in software) would lead to chaos, therefore leadership should be limited to a closed elite.
So what about the scientific method? What about custodian oversight?
> 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.
Wait, why not? The majority of people in control of what Go is work at Google. Seems like a pretty clear definition to me.
If a community-maintained fork is created, it would need time and monetary investment similar to what google is doing just to maintain and develop non-controversial features. Question is: Is this assessment sensible and if so, is the community able or willing to make this kind of investment?