Ian Lance Taylor's Response to “Go Is Google's Language” | Hacker News Reader

Ian Lance Taylor's Response to “Go Is Google's Language”

groups.google.com

342 pointsra7327 comments

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?

$10M per year would be closer, actually.

(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.)

10MM might be on the low side.

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.

Would it be viable to setup some sort of trust at the beginning so that it wasn't necessary to raise that money repeatedly?

Sure, but that means raising 10x+ since you'd really want the trust to be untouched and just have the foundation run off the interest.

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.

> There is no meaningful sense in which Google, apart from the core Go team, makes decisions about the language.

That's like saying that there's no meaningful sense in which I, apart from my brain and nervous system, make decisions about what my body does.

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 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.

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.

> The Go Core team is likely more vested in the overall success of the language than the rest of Google.

I think you could say that about most teams at most companies. That doesn't mean that they have any autonomy whatsoever from their company, though.

But isn't that what the article is stating? That the core team is making the final decisions?

Go can live on if Google collapses, the same cannot be said for most teams at most companies.

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 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.

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?

I think it's also worth highlighting this:

  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

Debian. They are one of the largest free software projects and are very democratic.

Isn't C++ committee-driven, which could be considered a type of democratic process? Or would that not be considered an open-source project?

On that note, I also seem to remember that LLVM/Clang are pretty democratic, but I haven't dug deeply and may be completely wrong.

The analogy

   Go : C++ :: Go's governance : C++'s governance

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.

Large parts of Java are handled via the Java Community Process.

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.

Actually, I think the other key argument is here:

> 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.

> 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.

That's how I read the 50 or so out of 100 approvers as being Google. That means 50 (or so, can't remember the exact number..) are not Google.

When I read "Approvers", I match that in my head to "Core Team". Is there a "rank" above approvers that defines the core team?

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.

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.

I have news for you: ‘dep’ was abruptly demolished by ‘go mod’ about a year ago.

That's still years after it was pointed out as a problem; and it still hasn't permeated to many Go projects.

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.

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.

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.

> 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.

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 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.

Well I'm glad you're happy with things the way they are! But this doesn't necessarily mean we should ignore the folks who are not.

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.

I said nothing about Java features. I was strictly referring to their Ecosystem, which I found to be terrible (though it's been a couple years).

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.

> 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.

> Yeah, like that's not a good thing

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?

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).

Yeap, that's google.

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.

> 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.

They do grok it, they just don't trust that specific small group of people.

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.

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.

> If google wanted an OSS language, they would have non-google committers

Ian claims "59 Googlers on the committers list and 51 non-Googlers." I was surprised by that too.

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.

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."

The whole paragraph is worth reading

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.

On point.

Security consultant here.

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.

I can feel you there, Generics can become unwieldy especially when you're nesting several different generic types.

Can you tell me if you have found any kind of security issue relating to interfaces and reflect(ion) ?

Never, but it's probably because abstractions hid all the bugs.

> 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.

I ... have some bad news.

You probably don't. You can still use gopath and choose to use gopath for another project that doesn't.

> You always know where everything is

do you always work on projects in which you made every decision?

sorry, what I meant is that if you're working on a project not using GOPATH, you can still choose to place it in GOPATH while you audit the code.

What's the bad news?

"you always know where everything is" is no longer true.

https://github.com/golang/go/wiki/Modules

Modules can still use GOPATH. If you have GOPATH defined when working with modules, they will be installed into the GOPATH in the pkg/mod/ directory.

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).

Is that really true though? What abiut python and javascript for example? Did they have a giant corp behind them?

... Python was led by a Google employee for seven years.

One of the first languages supported on App Engine was Python, IIRC.

Does it matter where the person worked? Python definitely was not Google’s or any other corp’s.

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.

Absolutely not. It is one thing to create a language and maontain it and another to hire someone who created a language some years ago.

from the post:

> 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.

Go exists because Rob Pike, Ken Thompson and others are allowed the latitude to make it.

You can be sure that whatever they do gets a high profile without it in any way being "supported" or "official"

It would be more correct to say Google hired the leader of Python and he worked there for 7 years

Is there really much practical difference between that and Go? From the Ian Lance Taylor response:

Wasn't it Google that heavily used Python that popularized it a lot?

And JS was born and evolved with the browser.

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.

Javascript was Netscape, and adopted by various other megacorps (such ad Microsoft and ... Google) over the years in various guises.

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)

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.

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.

It’s open development vs open source.

What about Ruby?

Basecamp.

Basecamp supports Rails. Ruby is mostly developed by a community of Japanese developers.

That supports OP's theory: Ruby wasn't mainstream before Rails.

While this might have been true, it was that screencast and the rise of Rails that put Ruby on the map in the west.

Basecamp is minuscule next to Google.

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.

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

Heroku was acquired by Salesforce.com in 2010.

> ...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.

Then why did D never take off?

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.

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.

> In many ways it's Java done right

Not quite:

* no generics

* error prone error handling

* non tunable GC

* null pointers

* golang interfaces are messy and can't be used to tag structures

* golang time package is garbage

and lots more

Java today is superior to golang in almost every front.

Memory usage, compile time, simplicity, readability and deployment story are notable fronts in which go is several miles ahead.

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].

[1] Not to mention offerings like: https://quarkus.io/

You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.

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.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

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.

Managing allocations is way more than just object pooling. The following code in golang allocates "n" on the heap:

    func main() {
        n := 1
        fmt.Println(n)
    }

Object pooling won't help here.

The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.

You can pool n if it's on your hot path, can't you?

Escape analysis was just rewritten, and the objective is to handle this case more gracefully.

Just like the inventor of the other language Go. They even filed am early bug asking G to change the name.

Folk were using that Go, but they would use the Google Go.

> You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real

Counter-examples: Clojure, Elm.

Sorry, but those languages don't really have adoption outside of small echo chambers.

I've heard about those before. What are they?

clojure is lisp on the jvm. not sure about elm.

I think they were being sarcastic.

oh, duh.

Elm is a JS framework for rendering views. It has a type system and guarantees no runtime errors while being fast. The language compiles into JS.

https://elm-lang.org/

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.

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.

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.

Actually, Elixir did add the bells and whistles to Erlang, sort of. That is pretty much the whole point of Elixir.

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.

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.

Different times, different stakes.

Lua was the consequence of trade embargoes in Brazil. It was created with substantial institutional support.

As well as targeting a use case that didn't have much competition (at that time).

> PHP, Python, Ruby, Tcl, OCaml, Lua

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.

My memory of that time is pretty different.

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.

> they soon built their own

C#, Go, Swift, etc.

I see! Thanks for explaining your experience in more detail. That does sound a lot more familiar.

I don't think so. The better the core team in programming languages, the better the future of the language.

> If I had made Go, no one would be using it right now.

This made me think of this (thank you for reminding me about it, by the way):

https://vlang.io/

Really looking forward to see where Alex will take this project.

This is vaporware.

How is it "vaporware" when it's been available for the public for more than a month now? :)

Show me a link to the source, and a way to run it myself. I certainly can't find it.

> Everyone's upset that Go is Google's language

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.

> 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".

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.

“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.

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.

> This situation feels similar to the need of politicians to divest any potential conflicts of interest.

With the key difference being that you can use a different language and achieve the same results you want. You can't just pick a different government.

Except not really because not all of us are greenfield developers 100% of the time.

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.

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?

Suggestions?

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.

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.

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.

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".

That's true for literally any project.

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.

> The fact that in Go's case quite a lot of the maintainers work at Google doesn't really change much.

It does if those calling the shots aren’t the committers but their bosses.

I’m not saying that’s how it is, but if it is, it changes things a great deal.

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.

>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...

This reminds me of the mono project and Microsoft’s .NET languages. It’s doable.

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.

> 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).

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.

> The logo was designed by his wife

They changed it. https://blog.golang.org/go-brand

"Changed" is a bit of a strong word here. The go home page still includes no instances of the new logo, and several of the Gopher - https://golang.org

> Of course not, it's not Google's language ...

Well, from a legal perspective Google sure seems to own it:

> https://groups.google.com/d/msg/golang-nuts/6dKNSN0M_kg/axCq...

Hopefully they won't implement generics.

> 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 language is not the name.

The name is protected.

> The name is protected.

Let's assume first that is true.

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.

Both Go and the Go logo are trademarked, see the responses in the linked post (use private mode if Google asks for login).

Thanks. I read further along in the linked post and found this comment by Rob Pike, one of Go's chief developers:

https://groups.google.com/d/msg/golang-nuts/6dKNSN0M_kg/dMCQ...

> 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.

> -rob

But, here is Google's official trademark list:

https://www.google.com/permissions/trademark/trademark-list/

> Golang™ programming language

> Go™ programming language

Golang and Go are trademarked by Google as programming languages and Rob Pike is not aware of this. That is interesting. Rob should be made aware.

And so the debate is now settled: Go is in fact Google's programming language, as an empirical legal fact.

I'm not certain, but I think that page is wrong. I searched the USPTO database of trademarks for "Golang" and nothing was picked up: http://tmsearch.uspto.gov/bin/showfield?f=toc&state=4809%3Ax...

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".

https://trademarks.justia.com/881/00/go-88100955.html

Word Mark GO

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

Type of Mark TRADEMARK

Live/Dead Indicator LIVE

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.

Exactly. You're making my point for me.

I'm not sure what point you are trying to make here.

The name is not the language.

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.

The language is not 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.

This page lists "Go™ programming language" as owned by Google: https://www.google.com/permissions/trademark/trademark-list/

(Also there is discussion of this point in comments to TFA)

You can though you may have to remove 'Go' from the name as trademark is either owned by Google or owned by the 'Go' project.

Yes, you have always been able to do that. The open source license it uses enables that.

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).

Since when has being able to use a derivative of the name ever been a requirement (or important) for free software?

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.

llvmgo and gccgo would indicate, yes you can.

It's worth noting that Ian Lance Taylor (author of this post) is the maintainer of gccgo.

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)?

The point I'm trying to make is there's a difference between re-implementing the language and forking it, is there not?

Yes, please do so, and implement some Generics too!

Setting aside the topic entirely; that is some clear, direct, and courteous writing.

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. "

Oh, the irony

Yeah big irony. Millions of users still remain confused between original 'Go!' and Google's hijacked version 'Go' language.

Not sure if sarcasm...?

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.

> And that may be a risk.

How is it a risk? Is Rust at risk because of Mozilla? What about Java given all its corporate sponsors?

People need to stop with this predictive FUD crap, it's tiring.

It's mesmerizing to observe the lengths that people can go when trying to smear an open-source tool.

I can't even fathom the amount of relentless bullshit that teams of big projects have to endure.

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.

Rust isn't really a fair comparison, not anymore anyway, it's very much a community led project.

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?

> 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.

> Why does it have to fork that hard?

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.

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)

Note that Go is trademarked. C wasn't. IANAL but there probably, legally, cannot be a Go++ or Go#.

That just means you need to pick a different name.

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.

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?

No need to be upset. Maybe you can set an example for Go project on how it is done in right way.

> 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.

It's a threat to have Google totally control the source code behind Go. If they were so inclined, at the direction of certain agencies, they can just maintain known vulnerabilities or bugs in the code that let those agencies wreak havoc.

There is a difference between open source and open governance. Go is open source but the governance is controlled by Google. For example, the committee that accepts proposals is all Google employees and a subset of the core team, if I read it right. From what I can tell, they definition of consensus is that of this group rather than the community at large.

This has business decision implications. Those who have had issues with Oracle and Java may want to take note because this is a similar setup. To use Go means you need to trust Google.

I'm not disagreeing with Ian and I'm happy he posted that. There is just more to this than technical considerations.

I for one will be curious to see if the breaking changes currently sitting on master (there are issues for them) end up in a release. The governance can play into the stability of the language which is a pretty hard dependency.

This reads like FUD. Go isn't to Google what Java is to Oracle.

Also, by that logic we shouldn't use Linux since a single man gets to pick what goes into the kernel. Same for most relevant tools which are mantained by a few individuals.

Which breaking changes do you mean? Got an issue link?

Anyone care to copy-paste so I don't have to log in?

Ian Lance Taylor wrote:

> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo...

Thanks for the link. There is clearly a real sense in which Go is Google's language. But I think I would like to emphasize some points that don't necessarily contradict the blog post but may add some nuance.

I'm a member of the Go team and I'm employed by Google. I'm speaking exclusively for myself here, not for Google nor for the Go team.

I've worked on free software for my entire career, before I joined Google and indeed before Google existed. I think it's fair to say that Go is an open source language. All the source code, including the source code for all the infrastructure support, is freely available and may be reused and changed by anyone. For software the most fundamental freedom is freedom to fork: freedom to take an existing 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.

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

The response requires logging in to Google's systems. So, essentially, there is no public response.

Why not petition Google to donate the Go project to the Cloud Native Computing Foundation, since many of the core technologies (including Kubernetes, Prometheus) that make up the cloud native space are written in Go?

And why exactly would they do this?

Go is perceived as Google's language because they named it "Go".

Yeah, that and because of the tight control and the opinionated, "our way or the highway", core team.

I'm sure they would've been "My way or the highway" if they hadn't been part of Google too.

And I'm sure being paid to work on Go and being part of Google gives them much more power over the community, and much more personal power to insist on their way.

Is Java is or is Java ain't Oracle's baby?

The TLDR to me is:

OK, yes, it is Google's language. But it's OK because someone has to control it after all, and Google is doing it well. And anyone could fork it if they wanted to.

(I don't mean to suggest I agree or don't agree, just trying to understand and state the main points.)

Not saying anything about Go necessarily, but Google being behind a technology doesn’t exactly give me a warm and fuzzy that it will be “supported for years to come”.

What does it even mean for it to be "supported for years to come"? It's not a web service.

Money spent to support the maintenance of the language and standard library evolution over time.

Bugs exist in software that are not web services.

It's a good thing it's an open source project and not a web service, then.

Lots of popular open source projects, including those that are not web services, sputter and die after the primary author stops working on it. When push comes to shove, when teams see that a part of their stack has been abandoned upstream, most will try to replace that part rather than take on the responsibilities of ownership.

Source code is of limited use if a company decides it is no longer interested and never allowed external developers into the processes that would have, over time, given them the necessary context to run with the project. At that point the only real hope the project has is that some nucleus of people quit the former sponsoring company to keep it going.

Almost every major significant OSS project has a corporate sponsor (usually in the form of paid employees doing the bulk of contributions). Don't see the problem with that.

And it's usually problems people are solving are work that instigate most of these contributions, so it's a damn good thing Go has a company like Google to act as steward, regardless of all the useless FUD people like to pretend "may" happen because they can think it up.

You're comments are getting quite circular. Your original post in this thread was implying that since the project is open source, corporate sponsorship was less important.

At least that is how it reads.

OP complains that Google is behind Go. Someone mentions that it's open source. But oh no, open source projects need a strong core! Guess what, those strong cores usually come from corporations. See how it all comes together?

So you don't get to be angry that the things open source projects need - strong cores - usually come in the way of companies paying for them.

Go having Google is a good thing, regardless of all the pointless stupid FUD people like to spread because it makes them feel better to point out something that could be scary.

> Almost every major significant OSS project has a corporate sponsor (usually in the form of paid employees doing the bulk of contributions). Don't see the problem with that.

Your arguments are deeply cargo cult-ish: they lack any rational train of thought and boil down to an empty belief on how a greater power will eventuall deliver good things to those who have faith in it.

> Your arguments are deeply cargo cult-ish

What does that even mean? It's such a ridiculous statement, don't even know where to begin.

> they lack any rational train

Care to back this up with facts rather than slinging mud?

That it'll still be useful in 20 or 30 years.

I think in this context, supported doesn't mean "will provide regular updates and tech support" but rather "will continue throwing enormous amounts of developer resources and put its institutional influence and weight towards the improvement of".

It makes sense if you think about it: how many companies adopted Go because they saw that it had Google's name on it?

Look at how Microsoft supports legacy code. You can still run VB programs on any Windows machine. "Supported for years to come" means that your code should be running in machines for at least the next 15 years regardless of how technology evolves. If you can't guarantee that then you'll gain no traction with enterprise sales and without them your language will always be a hobbyist's tool.

Keep the language working on newer devices, update the compiler, expose new features of the hardware etc...

Even if you don't mind if the language itself stops evolving you still need somebody to maintain it. I'm fine coding in C99 without the features of newer standards but if I can't find a C compiler that can efficiently target modern architectures I have a problem.

And volunteers can't do that for Go like they do for other languages why?

I never implied otherwise, I merely answered the parent's question. It's worth noting however that Go's maintenance burden is higher than many other languages which are often a layer atop existing infrastructure (Clojure with Java, Rust with LLVM for instance). AFAIK Go devs write maintain the entire toolchain, including a custom linker for instance.

Who takes this kind of argument seriously? The Go community can't support Go without Google because only a company like Google can maintain a linker? You're reaching.

I don't read the comment like that. The original comment invalidates the premise "Go will be maintained in the future, because it is backed by Google". Given how fragile Google's support for non-core projects is, I wouldn't bet on very long term support by Google.

That being said, Go is mainstream enough that, if Google EOLs it, the community will pick up the torch. Simias says its harder for Go than, say, Rust. It probably is.

> What does it even mean for it to be "supported for years to come"? It's not a web service.

I'm pretty sure those writing and building software today would like it to build and run 6 months from now.

How exactly is it that you think a compiler works? When Google withdraws their support for the project, what do you think happens to your Go install? The Go Playground is a playground, not where you actually build and run Go code for real.

Is this really a comment on Google or is it a comment on the velocity of platforms in general? I think Go has reached a sufficient momentum that it will be supported for years to come, regardless of its parentage. Not everything Google does is Orkut. Not everything other people do is LLVM.

I think Go is self sustainable. What would be nice is if they finally made "The Go foundation" idek if thats a thing yet but every language even D and Python have a foundation. Then ownership of domain etc can go to that Foundation.

Also Go will be fine. For example the Windows version of Go was all implemented by the Go community. The core devs were only focused on Unix and Mac at the time. I think Go will be fine.

People love the language and its being used by many in industry. Just look at Docker and other utils coded in Go. If you download Chrome or Android SDK / images from Google you are using a Go server to download those files.

Why? This isn't some closed-source web service like Reader that needs to be reimplemented from scratch. The code is there, and due to demand, maintenance will be provided.

Well, I do have to log in with my google account to read it...

It loads okay in an incognito window for me. Are you sure logging in was mandatory? It should only be needed if you want to post to the mailing list.

I also had to login with my google account to read it.

Logging in to Google Groups has been mandatory forever if you had logged in to a Google account before in that browser. If there are no traces of past login sessions (such as when using Incognito mode) then it opens just fine for unauthenticated users.

One of the annoying things about Google is that if it detects that at some point in the past you were logged in as a user it will not let you see Google Groups content without logging in (or going incognito).

There is no "just let me see the content, I can't be bothered to type my password right now" option, there is no "forget that I'm that user" option, the only option is to log in or to go incognito.

Deleting cookies should help?

https://www.pastery.net/ycqfug/

Golang Nuts is a public mailing list, sadly there are not a lot of mailing list archives these days.

https://www.mail-archive.com/golang-nuts@googlegroups.com/ms...

Not if you had signed up for the mailing list, which is how mailing lists are supposed to work.

It's how mailing lists were supposed to work circa 1992. But web archives for mailing lists are more than 20 years old. [1] And honestly, I'm not sure "supposed to work" is correct. It's how they did work, sure, but thinking back to the mailing lists I set up pre-web, the goal was to create a forum many people could use. That a mailing list was used to do that was a function of the available tech and how people connected.

And I'll note that from what I can tell, forum software predates mailing list software. LISTSERV only goes back to 1986. [2] Forum software goes back to the mid-1970s [3], and the WELL was started in 1985 [4]. So I think it's reasonable to argue that online forums are the "real" experience, and mailing lists were more an implementation constraint for the decade or so that email popularity outstripped the richer interfaces of the terminal era and the web era.

[1] http://www.lsoft.com/corporate/history-listserv.asp

[2] https://en.wikipedia.org/wiki/LISTSERV

[3] https://en.wikipedia.org/wiki/CONFER_(software)

[4] https://en.wikipedia.org/wiki/The_WELL

The Well isn't a great example here. You can't read anything on the Well (other than a couple of public forums) without signing up for a paid account and disclosing your real name.

For early BBS's it was routine to create an account before doing much of anything, though they often didn't verify anything. I think some had a limited anonymous account you could use?

Was there anything before gopher that let you seamlessly jump from machine to machine?

Me too. Which perhaps undermines the point of the denial?

On groups.google.com nonetheless

Go == Simplicity

It's obvious that Golang is Google's language. The most obvious part is they require a CLA that gives them and only them special rights. It's a sham.

Care to explain what a CLA is? Assuming a legal term...?

https://en.wikipedia.org/wiki/Contributor_License_Agreement

Contributor License Agreement - basically that you agree they can use your code, modify it and distribute it.

https://en.m.wikipedia.org/wiki/Contributor_License_Agreemen...

Basically signing over rights of what you contribute to the company running the project.

Thanks all. So basically you can’t build a close source app with GO?

That has nothing to do with the ability to build a closed source application. You can absolutely build one in Go.

I don't know of any large open source project that doesn't require a CLA. As the post suggests, perhaps one day there'll be a Golang Foundation, which would otherwise have ownership of whatever code you contribute. See that Python has a CLA that gives the PSF ownership of your code: https://www.python.org/psf/contrib/contrib-form/

Even the linux kernel has a CLA, they just call it by another name (Developer Certificate of Origin)

Ruby, Ruby on Rails, and Rust are three large open source projects that do not require a CLA. That said, I do think you're correct that these days, it's in the minority.

Node had a CLA, but it was removed in 2014. It does have a "Certificate of Origin", which you claim is the same as a CLA, but I beg to differ. The issue here is that CLAs generally require you to reassign copyright; the Certificate of Origin does not. That's the part of CLAs that the OP is taking issue with.

There is a world of difference between a CLA that gives your code to a for profit entity and one that gives it to a foundation that (at least in theory) only cares about the health of the language/community.

> Even the linux kernel has a CLA, they just call it by another name (Developer Certificate of Origin)

Who is the single beneficiary of special rights granted under the DCO? CLAs provide a single party with rights nobody else has.

Google’s takeover of deja news and its formation into groups.google.com was always a mess, but it seems to have got even worse. Now it’s at the point I can’t access the article on iOS safari.

First it forced me to log on. Ok I did that. After which the redirects lost the deep link, so I reached a generic landing page. I tried going back but there were more redirects which made that difficult. I finally came back to HN and clicked the link again. Then a spinner came up but didn’t load. A few reloads later and I got a few characters but nothing useful.

What a mess.

I had the same experience, but never actually got the groups page to load.

Hey googlers remember a cool little thing called the URI? Can we make that just work again without all this session/auth nonsense wrapped around everything? I am not interested in your accounts.

Same here... I feel like I am in some sort of nostalgic jQuery mobile museum.

You have a problem with the browser.

It should display correctly on the 10-year old webkit engine.

https://groups.google.com/forum/m/#!topic/golang-nuts/6dKNSN...

This works fine without javascript.

https://groups.google.com/forum/?_escaped_fragment_=topic/go...

https://golang.org/LICENSE

Not GPL. Therefore it doesn't matter. Some corporate overlord has the power to kill/modify at whim.

GPL(2.0) for comparison: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

Huh? Even if it were GPL, how would that prevent "some corporate overlord" from changing the license later?

You can still fork the code up until the point of the license change and freely modify it going forward.

Right, and that's true with the current license too.

And you can't with a BSD-style license?

Whoever owns the copyright on the code can change between licenses at will, they are not constrained by the GPL's restrictions on re-licensing (because they aren't licensing the code to themselves, they own it)

That's the 3-Clause BSD license [0], which is arguably more open than the GPL (On varying definitions of "openness" at least. It's very lax, although it doesn't prevent patent treachery)

[0] https://opensource.org/licenses/BSD-3-Clause

The license is pretty much AS-IS license that tells nothing of copyright or potential patents behind this, and simply covers google of any claims against them. It doesn't grant anything to licensee, for open or commercial use, nor clarifies any sticky points.

Compare that to Apache 2.0's 2nd and 3rd clauses:

"2. Grant of Copyright License.

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License.

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."

Reply on news.ycombinator.com