I don't use Go much to have an actual opinion on this. I actually like Go because I built my data science blog on top of it (learned a bit of CSS and html along the way).
But I think the final paragraph of this post only serves to highlight an issue brought up in the original post by Mr. Siebenmann.
The rebuttal says:
"There are certainly senses in which Go is Google's language: it was created at Google, Google continues to fund most of the development, and a few people at Google are the final deciders about the language itself."
I understand that the language can be owned by Google and the community, but the original take was:
"You could ask if Go is Google's language or the Go core team's language, since Go's direction is set and controlled by that small core team. However, at the moment I believe that most or all of the active Go core team is employed by Google, making the distinction impossibly to determine in practice (at least from outside Google). In practice we'll only get a chance to find out who Go really belongs to if Go core team members start leaving Google and try to remain active in determining Go's direction."
Seems like the rebuttal's concluding statement doesn't really address the biggest concerns.
The rebuttal continues to say that the development team tries to work with the community when possible. The original discussion here on HackerNews brought up examples where that is not always the case. I don't think a BDFL or a team acting as BDFL is a bad thing inherently, but I don't think this rebuttal really talks to the issues.
I once wanted to build a bunch of ML tools for Golang. Like coding up UMAP or other dimensionality reduction techniques, introducing some variational techniques, etc. But the package manager situation at the time (I thought of doing this 2 years ago) scared me off!
edit: I thought about this and did form a slight opinion on this article only. If we were to change the opening and concluding paragraph only (and retain the rest of the contents), it should have been titled "Go is Google's Language, and that is ok!" And then added a paragraph on how Google possibly abandoning the project wouldn't cripple it.
He does not need to rebut anyway go is language created by googlers for a need they had and they open sourced it. If it does not meets anyones development requirements they can use another language or fork it and do the changes themselves. There are so many community driven open source projects one of the most used is Kodi and if you have spent any time on it's repo you can see that the maintainers set a hardline on what their vision is and what code they are willing to accept. Funnily enough an argument is going on at the moment where Kodi maintainers want to remove all hardware specific hacks in future versions and some dev opposed to it. What do you think will happen?
"..I've noticed that people often use the term “the Go community” without being particularly clear about what they mean. To me, the Go community is all Go users, which is at least a million people at this point. As such, it's at the very least imprecise to say things like “the Go community wants (or did) X.”
I think this is important because some outspoken members seems to have tendency to claim that they represent whole community and they must be heard and responded to even at the cost of quiet community members.
No reason to be skeptical, that analysis is pure shit and dismissible on its face.
The minor issue is the quantifying of developers. The methodology for the 15-20 million figure isn’t clear, but it at least passes some basic sniff test.
What’s completely bullshit is using stackoverflow surveys. There is no reason to believe the respondents of that survey are an unbiased cross section of the 20 million and many reasons to believe they aren’t.
I would totally expect the stackoverflow social 2.0 tech hipster webshit crowd that would fill out that dumb survey to be more likely to use Go. The same with oreilly surveys. Old grizzled grey beards aren’t as likely to fill out publisher surveys on old stable tech.
Also, answering that you have “used” go is not the same as being a regular developer (as noted by one of the commenters there... assembly is more “popular” than Go).
Well, as a "stackoverflow social 2.0 tech hipster webshit" (I answered the survey), I fully agree with you that the methodology is beyond suspect, you just can't take those numbers and apply some fudge factor from the top of your head and pretend the result has any credibility.
OTOH, regarding
> answering that you have “used” go is not the same as being a regular developer
The question they ask in the survey is: "Which of the following programming, scripting, and markup languages
have you done extensive development work in over the past year, and
which do you want to work in over the next year?", so it's more than just having "used" it.
Is that all one question? Then it’s even worse, because then “use” also includes purely aspirational users. Nice.
Also I don’t think anyone that participates on this website has any moral superiority over tech hipster webshit. But it’s good to realize this is a skewed demographic.
Not sure what to make of this. All of the points the author makes are obvious; of course a project originated at Google would have a majority-Google membership. Of course anyone is free to fork Go. Of course the code can be considered FOSS. Of course execs at Google couldn't care less about spec details. None of those things disprove the point that Go is not a community-driven project.
I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply. The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone.
The difference between an OpenJDK and an OpenGo project, in practice, would be that the two would be completely unrelated. Go core would go on ignoring community progress and, at best, Google would sue for the project to change the name and force a hard fork.
"I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution:"
Can you explain why it makes sense to generalize a company of 50k developers, which has released 4000+ open source projects, on the basis of precisely 1 of them?
Why doesn't it make sense that it will end up with a variety of projects with a variety of models?
Especially given that is true of the world writ large?
I simply do not understand this fixation with trying to rigidly pigeonhole Google on open source.
I think the point rmrfrmrf is making is that Guava is a typical example of Google's attitudes towards the two-way relationship of open source. Google developers (and many other big software companies) are more than happy to open their code and promote it as something that the community should adopt, but seem rigidly dismissive of any code contributions to the project from outside. That may not be the case for every Google project but it does feel like it's a common one to me.
What Google projects would make good counterpoints by demonstrate a welcoming attitude to external contributions?
Kubernetes is a reaction to that state of closeness, and was explicitely designed to bring Google’s philosophy (Borg) to the world. Its strong focus on getting outside people involved is the core reason of its existence, so it’s a bit of a special case IMO.
An issue is copyright ownership. Even if a contributor assigns copyright, it is ineffective if they didn't hold copyright. This opens the project to legal peril.
That sounds reasonable except Google could write some boilerplate for maintainers to include in a project's README.md, contributing.md or license file that explicitly states they won't accept community contributions because copyright would be an issue, and they don't appear to have done anything like that.
> I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply.
This claim is belied by the fact that half of the people who have committers in Go are non-Googlers, isn't it?
It's probably less than half due to people using person email addresses instead of @google.com. The author didn't verify that people who had non-google addresses didn't actually work for Google.
One thing I'd be curious to know is how many of the committers didn't ever work for Google. I suspect some of the non-Googlers on the committer list maybe former Googlers...
In the context of this discussions why would it matter if someone never worked at Google vs someone who used to work at Google. They're not acting on behalf of Google when they make the contribution.
But it might be an indication of how “open” Google is to complete outsiders as opposed to people who were insiders but now just happen to not work for Google. Whether or not that matters is another question entirely.
But like I said, I don’t think it matters in the context of how much control Google has over the language. Many successful languages are either driven by an individual benevolent dictator or a company. As far as I can tell, languages controlled by community/committees tend to evolve more slowly. That’s okay at some point in a project. But there is something to be said for a person/company having the ability to rapidly push through changes.
You need to sign a CLA to work on Go, like most Google projects. You can't accidentally use your personal email address, and setting up the CLA signing stuff is somewhat involved.
Ok that's curious, cus I've spent the last two years working on a project at Google that's half open source, and the guidance we got was to use an existing non-google github account for contributions if you had one and wanted to.
But this is also like a developed-in-open-source project, not a built-internally-and-copied-outside, so maybe the guidance differs there?
> and the guidance we got was to use an existing non-google github account for contributions if you had one and wanted to.
This is correct. Use an existing github account, but your contributions should be under your @google email address. There's nothing that ties your github account to a git email. I've committed through github from like 4 different email addresses (@google, @gmail, @uni.edu, and a shared organizational one for a project from a shared machine).
Ah gotcha, yes we're agreed then. The underlying commits are supposed to be tied to your @google account (though a not insignificant number slip through)
The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone.
NIH syndrome was widely cited as one of the major flaws of the Smalltalk community back in the day. In any human endeavor, one has to fight the tendency of a group turning something which isn't a club, into a club.
That said, golang isn't a field. It isn't a genre. It's a computer language, a collection of libraries, and a number of online communities. In large part, it's a collection of tools with support around it, people interested in using it, and a company behind it. There are lots of things like this. Leica cameras. Rigol oscilloscopes. Chevy LS3 crate engines. Harley Davidson Motorcycles. These things live and die by continuing to garner the goodwill of the market and staying honest with themselves.
On the flip side, many of those things also live or die through good design, and good design also needs gatekeepers and visionaries. It's a balancing act. Golang in particular needs to watch its step. Since it has a syntax on the minimalist side with few surprises and easy access to its AST, it's going to be one of the easier languages to port off of.
indeed but there are so many more clear examples :)
rsc@'s clear disdain that anyone outside of google would run go is crystal clear in many of his various writings on issues like clock skew, packaging, etc
It's lucky bradfitz is, apparently, able to remember that a world outside of google exists.
> the tedium of dealing with the unwashed masses -- typical NIH syndrome
If you've managed a large OSS project with a wide userbase before, you know how annoying it can be to deal with large numbers of repetitive requests from folks who don't have the full context of what's going on in the project. It's time consuming at best, and at worse some small minority of those folks take up a toxic attitude that sucks the happiness out of your work. There's no need to accuse maintainers of arrogance or NIH syndrome. This stuff is hard, and we all try to do the best we can.
> ...repetitive requests from folks who don't have the full context of what's going on in the project
Write some FAQ's, so that people are made aware of that context. An openly-developed project can actually be very successful at dealing with this, because pointing folks to the centralized discussion in which the pros and cons of commonly-requested feature X are dealt with becomes second nature after a while. We saw an example of this very recently with the surprisingly-mild brouhaha about Rust's choice of a postfix .await syntax.
From my experience as oss developer on several different projects (small to medium ones),a lot of people don't bother to read FAQ's.
There are some people that hit the problem, start googling, and trying to find information, and some that just fire off email or stack overflow question (often so badly, you need several back and forth)
Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large and accommodating room)? I read almost all proposals for Generics, and, perhaps to my inexperienced eyes, the problem seems hard. The ramifications on the language design are not trivial, and the benefits, again, from my quite limited world view, are not so easy to quantify, otherwise how can one justify the extreme productivity spawned by the language? In the cloud business no less.
I have almost no stake in this, I don't even use the language professionally, but I find the supposed criticism a bit over the top. I'd wager that an example implementation of Generics that fits nicely with the language and works for a big and healthy code base would absolutely not go unnoticed by Russ and the other core members, but we have to accept that it is not easy.
There's a proverb in these here parts that goes like "He who doesn't want to kneed dough, keeps sifting flour".
Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor".
That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...
Most of these "analyses" especially from Ian has backing code changes.
This for example, is my experiment with trying to give Go a backing calculus that supports generics https://asciinema.org/a/166748
The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too - essentially a different language
>The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too
Well, isn't it a major typesystem change? Makes sense for it to apply to a big part of the runtime and semantics.
You mean the usual documents that get thrown into generics discussions, where he keeps talking about C++ and Java, while ignoring all other programming languages designed since CLU and ML in the 70's?
"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
I don't know, that they actually implement them, instead of doing proposal after proposal?!?
Even the ideas that eventually die on the Web, C++, Java and .NET happen to have preview implementations available to try out at one point, instead of dead paper.
Except that they admitted that they didn't really look beyond C++ and Java implementations. Their aversions to modern language design and type theory are pretty obvious.
Also, lots of code can be written in a bad language. And a language can be practical without being good from a language design perspective, the difference is in the richness of the ecosystem, the stdlib, and 'meeting programmers where they are'.
Guava was always made available as Google's Java core utilities. I think it was always a misunderstanding to expect external contributions, like Apache Commons, as that was not its original intent. Rather it was to reduce internal duplication and ad hoc code with a shared standard. It then became useful for open-sourced Google projects (like API clients) and recruiting (new hires would be familiar with Google's libraries). Many suggestions are best spun off into new libraries, rather than donated to Google to maintain.
Java's many flaws have been papered over by a large ecosystem of libraries. As a non-gopher, I'm not sure if that same spirit exists. Perhaps that is due to the dependency debates, whereas Maven Central was quickly adopted when managing jars (via Ant) became too burdensome. Perhaps modules will help, as the language doesn't have to be batteries included.
Any OSS project can be relatively closed to outside contributors based on how opinionated the core owners of the repo are, it isn't just corporate open source.
You think the Guava team has a low opinion of patches? Does that mean Linux isn't a community project because Linus wields an iron fist when it comes to accepting patches?
Yet Linux is full if half-assed undocumented cruft despite Linus' vigilance. It's just gigantic. He doesn't care much about how great your new LSM, IO scheduler, FS is, if it's relatively sane, and you don't do crazy things elsewhere in the code, he'll pull it. (Nowadays it's not directly him.)
A counter-example I've seen is Bazel; the Bazel core team seems very receptive to outside contributions and feedback from my experience (I've contributed PRs to Bazel).
(I don't use Go, so I don't have much insight into the overarching discussion. Just wanted to add my 2c).
The set of people that make decisions about Guava is mutually exclusive from the set of people that make decisions about Go, and the two projects have markedly different goals.
It's also worth noting that Guava lives in a very different world from Go - the way we distribute Guava is (unfortunately) not designed for non-Google contributors and Guava needs to support multiple Java ecosystems/platforms (Android and servers, at least).
A shout out for Firefox multi-account containers here. Set up google-specific containers for any google properties you do want to log into, leaving your main container uncontaminated with google cookies.
I dont even click groups.google.com links anymore because I know I'll be prompted to login to view the contents of the page. It irks me to no end that the contents will be indexed for search and then hidden behind a login.
I didn't have to login. Firefox on Android, never logged into a Google account in that browser. (But I'm not entirely sure if Google recognizes the account used by Android somehow.)
> You hereby grant to Google and to recipients of software distributed by Google 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 Your Contributions and such derivative works.
It seems the bulk of the rebuttal is a reposting of Russ' blog post from 2015 "Go, Open Source, Community" found here: https://blog.golang.org/open-source
I was hoping that this would address the package management fiasco, but it did not.
I don't use Go, I think rsc's module system is significantly better than the community version (although bad in its own way), and I find your broad dismissal... unappealing.
I am interested in programming languages (and especially module systems), and Go is a neat case. Plus, I've been following the antics of the ex-Bell Labs team for years.
In that case you possibly agree with my sentiment that Go 1.0 is 'World according to Pike' (with associated +/-).
And note that I wasn't being snippy at you. Some of us have invested literally a decade in this at times infuriating language and are loathe to see it 'normalized' due to social pressure.
So it's just sour grapes for not having your favourite feature implemented?
Okay, fair enough ... but Go was always designed to be a small language with a limited set of features. Many reasonable requests may very well be reasonable on their own, but don't fit with the design aesthetics. It's like trying to add Common Lisp features to Scheme: that might be considered reasonable by some, but it doesn't really fit with Scheme's design. They kind of tried with R6RS and it was massively controversial, and many Scheme implementations stuck with R5RS.
This is the part that so many people don't seem to understand. They confuse "trying to maintain Go's minimalist design aesthetics" with "not open" and "unwilling to listen". Those are not the same things!
Some of the most frequently quoted examples all include things that have either been implemented, or at least seriously considered: monotonic clock, package management, generics (not implemented but Go Core team proposals go back to at least 2010). Arguably, some things took rather long, but again, Go is a small language and changes are discussed and considered for longer than most others. Many consider this good, as it provides a stable working environment to "get stuff done", which is the entire point of Go.
It's also not clear to me that exactly "community-driven" means? The entire community voting on all proposals? Accepting a proposal as long as a subgroup is loud enough? Very few projects – if any – operate like that. There is always a comparatively small group of core developers who, in the end, get to decide.
I don't think they refuse features because of design aesthetics. Go has many warts already anyway.¹
The design goal for Go seems to be to make a language where there is only one way to express a given algorithm.
They are trying to create a language where it is impossible to be clever.
This is not bad thing in itself, except when it starts to remove features that allow you to write clearer code.
For example I have a Java application that connects to a database. I _like_ that I can just let the transaction die for any uncaught exception that bubbles up from the DB layer.
I like that better than the idea of having to 'handle' a thousand possible errors from down there that I don't even understand. In some cases exceptions make for clearer code.
And don't even get me started about the lack of generics. That is a glaring omission that shows lack of understanding of the human factor in language design.
That they didn't anticipate this obvious feature makes me question the purity of the aesthetics.
This is all fine, and they are of course free to leave out whatever features they want: this is what makes it Google's language, after all.
1: Just one from today, inconsistent arithmetic with Durations.
Go leaves a bad taste in my mouth too, partly because it thrusts someone’s stubborn opinions on me but mostly because I don’t think it is all that great of a language. In particular, I don’t know why you would use public memory to store processes, I don’t know why you would use cooperative scheduling in a language designed for concurrency, and I can’t imagine why you’d release or use a language with virtually non-existent dependency management (better nowadays, but still not great). With so many better-thought-out languages available, I just don’t see a reason to use Go.
I 100% believe everything Russ Cox says here and don't think it will make a whit of difference on HN and Reddit.
Keeping as constant Go's opinionated (for better/worse) management philosophy, I don't think there's anything the Go team can say to put this criticism to bed. It's simple: Rails can be "omakase" because Basecamp is a tiny company, and Go can't be (without gripes) because Google is a big company. Hell, it wasn't even clear a few weeks ago whether Clojure was allowed to gripe-free "omakase" status, and hardly anyone on HN has even heard of Rich Hickey's company.
Since, short of drastically changing how the project is managed --- something I don't think many Go users have an appetite for --- there's nothing they can do rhetorically to shut the argument down, I think it's best ignored.
If you don't want to use a project affiliated with Google, don't code in Go. Similarly, if you want to have large solo impact on core features of a language platform, like package management, set your sites somewhere other than Go, where fairly intensive gatekeeping to that kind of stuff is widely considered a feature, not a bug.
> impact on core features of a language platform, like package management
In this specific case (which is important to the discussion) there effectively was nothing you could call "management" in what the core tooling provided for resolving and fetching dependencies. I think the reason it wasn't there, was because that wasn't very important to Google which famously operates a company-wide mono repo. Dependency management wasn't a problem Google had, so an official solution was a very long time coming, and left the interim solution providers feeling quite raw.
"There effectively was nothing you could call 'management'" is hyperbole. I know what you mean: you don't like the way they managed it. Ok. But this is a pretty good illustration of how there's no winning for the Go core team in responding to this stuff.
I honestly don't think its hyperbole. What we had with go get, would install different versions of dependencies each time you checked out your repository and built it. That isn't managed. Managed is what they recommended you to do, which is vendor all the dependencies, but that isn't something provided by the go tooling.
That's a lovely sentiment, but it doesn't help much when you've got no consistency between checkouts and builds are failing because of upstream changes that the code you're trying to work with doesn't even know it's using, and to try to fix an issue first requires you to spend days dealing with bitrot.
Here are some principles: 1. only the team working on a component should be able to break the build of that component. 2. Components should not break outside of commits.
The truth is, that your 'API' ends up being every part of your behavior that is relied on by your dependents and their dependents, ad infinitum, and it's almost impossible to make improvements without breaking such an API. Sometimes bugs are part of your de facto API.
It's one thing to say 'people shouldn't depend on these features, look it even says so in the doc', but should and shouldn't are moral judgements, what is and what is not are the distinctions that drive whether your development and release process are fit for purpose.
> I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
Well, there can be debate on the volume of problems on either side, but some other ecosystems attack this with tooling that can automate the process of getting notified that there's an upstream change, rebuilding with the new version, running the automated tests, and making it super easy to accept a commit updating the dependencies if the tests all work.
> I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
Semver addresses this. You stick with a specific major version (or minor version for a 0.x release, where "minor" version changes can in fact introduce major breaks), and your dependency tool enforces this. However, it does still warn you if a newer version is available, so that you can start depending on it. (Of course, switching to a newer release is easier said than done if other modules might still depend on the previous one, and your build tool doesn't support the concurrent use of both in the same build!) This is essentially a solved problem.
I think it's disingenouous to call this a solved problem. Regardless of their appearance, very few projects actually follow this consistently, because it's a lot of work and almost impossible to be sure.
I'm with @jeremyjh on this one. There was no management. There was a "fuck it. works for me." kind-of half-assed implementation that was frankly terrible when compared to ANY of its contemporaries. It spawned a ton of competing "package managers" that attempted to do a better job but none of them "won" (probably because none were officially sanctioned) so you ended up dealing with like six of them in order to manage the dependencies of whatever random project you tried to work with.
No-one "managed" the problem. They just sat and watch the community flail around for years.
That what's happen if the community has no say in what package manager is used or how it works and the community is not forced to use the official one and the community is not organized properly.
I would say it's what happens when a community is explicitly not allowed to solve a problem.
PHP, for all its warts, is 1) very community driven and 2) solved their package management problems via the community (with Composer). Go was not allowed to do that, because everyone knew that any solution had to be blessed by Google.
I believe everything that Russ Cox says here and don't think it will make a whit of different either. But thats because he does not refute the assertion in the original document.
Go _is_ Google's project. They may let other people contribute but if Google's interests are not maintained, and further if the small core group who run it inside of Google disagree, you should not assume there is any way to override that. That's literally the point of what the original document was saying.
Lots and lots of us can live with that, but it would be much better if the golang contribution process was more explicit about that.
I guess I just don't see the practical difference between "if Google's interests are not maintained" and "if the small core group who run it disagree". The latter describes lots of things! Very much Clojure, too! The former sounds ominous, but really means the same thing.
And with that lack of difference in mind: when the Go team says "Google's interests have little to do with how we're running Go", I'm strongly inclined to believe them, because what difference does it make? Why would they just make it up?
But really my point here is just: there's no point in the Go team engaging on this, because I literally can't think of a single thing Russ Cox could say to defuse this drama.
Perhaps, he could be honest and say, yeah, it's true. We don't think it's a problem because ... but it's something you'll have to live with if you are to use Go.
There's precedence, for instance, C# is Microsoft's turf.
Seems to me to be a basic human thing - if people are worried, downplaying their worries backfires.
He could simply agree. There is nothing wrong with the model they are cultivating.
But by not acknowledging it’s what they are doing they leave space for drama. Worse is if they think they are doing something else, because they are missing their intentions by a wide mark.
> But really my point here is just: there's no point in the Go team engaging on this, because I literally can't think of a single thing Russ Cox could say to defuse this drama.
As others, I think the easiest thing Cox could say in response to these posts is: "Yeah, you're right. Go is open source but it's not community driven. There's a small, insular core team, we have full control over the language, we have a clear vision, we're going to follow that vision, and we think the results so far have justified this approach. We hope you choose to continue to use and, where appropriate, contribute to the project and the larger ecosystem."
Go is a very impressive project, and the core team does have very tight control over it, and (very plausibly) that tight control is responsible for the quality of the language. I don't think it necessarily needs to change; certainly not any time soon. Why not embrace it?
And I think, if he did that, it would end the drama in a heartbeat, because what's left to discuss?
The words you put after "Yeah, you're right" don't actually square with the accusation being leveled at them. You're right, I think, that there's a small insular core team with full control and a clear vision. That doesn't make it "Google's project". Put differently: if Russ Cox resigned from Google, I imagine he'd probably remain involved with Go and have the same amount of influence.
My impression is that most criticism (certainly the criticism I've found valid and troubling) has been focused on whether Go is community driven, or controlled by a small team of core developers who just happen to currently work for Google.
Certainly there is some criticism than seems to focus on the idea that Go is controlled by Google, but I feel like that's, at most, a vocal minority. Then again, perhaps I just discount it because I find it pretty silly!
> Put differently: if Russ Cox resigned from Google, I imagine he'd probably remain involved with Go and have the same amount of influence.
I agree 100%.
(Of course, if your concern is how Russ Cox is managing Go, that probably doesn't make you feel better. If your concern is how Sundar Pichai is managing Go...well, I think we can both agree that's not a real issue.)
Is this not how it works for pretty much more – if not all – projects? Good luck trying to land a patch in Python if the small group of core developers don't agree. Or PHP. Or Ruby. Or Firefox. Or Linux. Or anything else really.
Quite a few of the core Go devs aren't hired by Google out of the general programming pool, they were already contributing to Go and then Google asked "hey, cool stuff; why not come work on Go for us?" Again, this is pretty much how you join any core group of developers: make good contributions, get asked. Except here you actually get paid.
as mentioned in another comment, a number of people have been hired by Google "from the community" (including e.g. spf13/Steve Francia, the Go product manager). I don't have access to their HR accounts, so I can't tell you how many exactly. But if you do good work, there's a non-zero chance you'll get hired.
I think voting and whatnot are implementation details. That PEP says only core team members can vote who can join the core team, so core team choosing vs. core team voting is not all that different in practice.
Yes, and hence a higher chance that they are not a hardened paid-for core team, but a looser team where people can come and go, and where an outsider can get influence.
people should be paid to work to a product under some direction, if you want some professional outcome
teams where people come and go rarely have built solid products
Take for example the Linux kernel, Alan Cox has been working on it non-stop from 1991 to 2009, and even after resigning as TTY maintainer, he was still heavily involved up to 2014
From 1999 to 2009 he was employed by RedHat and after That by Intel until 2013
I can't honestly say he did RedHat or Intel interests more than he did Linux community as a whole interests
He's a big advocate and activist for free software, but he also said "Yearn for the good old days when you knew every contributor by name and the source code fitted on a single floppy disc ?"
In a way or another, a small group of "directors" is always better for the good of both the product and the users
Google doesn't "own" the project in any meaningful sense. That was Russ' entire point of this post. Could Google assert control if they wanted to? I guess. But that's no unique to just Go. Remember the XFree86 drama, for example? Probably a number of other examples to be found.
The issue here seems to be primarily one of trust. I can relate to that, as I don't like Google either, and actually mostly avoided Go for exactly that reason until I got hired as a Go developer a few years ago. I found that the Go project in particular is developed and managed in a fairly reasonable way; certainly much better than some other popular Google projects such as Android (the open parts of it anyway) or Chromium.
In other words, I think you should give them a chance, rather than immediately go "corporate Google overlords".
> If you don't want to use a project affiliated with Google, don't code in Go.
For what it's worth (and I say this is an outside observer who's never written any Go, so, grain of salt, etc.), I don't think the original post this responds to disagrees with your point. To wit, from that post:
> Or in short, Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.
and
> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it.
I don't think he's saying "Go is bad" or even "the management of Go is bad," but rather something more like "people should be honest about the nature of the management of Go, and choose how to engage with the community and the process accordingly."
I'd wager that nobody would complain if Google donated Go to an open organization such as CNCF [1]. The CNCF is a good fit because it already hosts the world's most prominent Go projects, including Kubernetes and Prometheus.
While Google is certainly a big bish in that pond, there are plenty of other big fish to balance them out, including Cisco, Red Hat/CoreOS, Github, IBM, Intel and Docker.
Or invent a new organization. Call it "the Go Foundation". Make sure it's independent and has the bylaws and administrative structure to prove it. It's worked out pretty well for Python [2].
I kind of get what you (and the articles) are driving at. Who will be the people that run it under that umbrella? You need some community buy in and corporate buy in.
Who will run it? Activists ? You want the top talent working in/on go to be the people that run it.
Now if GvR (python) or equivalent was contributing to go and he is hey I’m an awesome developer and an awesome language designer what gives with side lining me.
That would be a point. But now most top go talent that are working on the language are at google
Just like with k8s google may create a foundation for it or donate to one of the existing one when there is diversity in top contributors. I assume hope. Perhaps this activism is early
If go wasn't a strongly opiniated language curated by the core team, I fear it wouldn't be the same go.
Example: I don't like all the things gofmt does, but if I accept what gofmt gives me, I can learn to live with it, and eventually be super happy :)
If go isn't opinionated, then what's the point? Whether owned by Google or a foundation, if the core team isn't small and opiniated, then aren't we just reinventing C++, hehe :)
Disclaimer: I work for Google, this is my personal opinion.
(I actually haven't used golang since joining Google, but that's a different story)
There are two kinds of control: control via stewardship and control via contribution. Stewardship is the process of making final decisions. That could be done by some foundation, but if it's the same people, the decisions would be the same. But even when the stewards make the final decisions about what goes in, someone has to contribute the work. For large/complex open source projects, much of the contribution comes from people who are paid to work full-time on the project, and someone has to pay their salary; that someone is often a corporation. Even if a corporation does not have direct control via stewardship, they can still decide what kind of contributions they're willing to pay their full-time engineers to work on. For example, Linux stewardship is done by a foundation, but most of the contribution is done by corporations.
We see something similar in the Java world. Even though the Java stewards are mostly Oracle employees, Oracle does not exert direct control over stewardship; the OpenJDK lead is elected by the OpenJDK board (whose chairmanship is reserved for Oracle, but has non-Oracle members). However, Oracle also funds 90% of the OpenJDK contributors, and the company can decide they want to fund work in certain areas but not in others. E.g. Oracle has reduced investment on client-side Java; some of that work is now contributed by another corporation (Gluon), but the total resources for client work are still reduced.
Because Google has many people working on OpenJDK (I think about the same number as those working on Go), it also has a lot of influence, as it can contribute large features (like the thread sanitizer they're now contributing).
Here is an explanation of Java's governance by Mark Reinhold, who is the OpenJDK lead and also Chief Architect of the Java Platform Group at Oracle: https://youtu.be/HpbchS5kmio
Just to add to the explanation, "omakase" is Japanese for "I'll leave it to you". It's relatively common in sushi restaurants to have 2 ways to order - a la carte (or in japanese "tampin") where you choose exactly what you want, or "omakase" where you essentially say, "Give me what you recommend". One of the reasons for this is that there are definite seasons for fish. You can often get certain fish at most times of the year, but in winter it will have more fat, etc, etc. Similarly, the chef knows the quality of the fish that has been bought for the day and knows what's best. If you want the best, then usually you go for omakase, because you, as the customer, don't have a good way of judging the quality of the fish for the day. In some restaurants you even just say how much money you want to spend and the chef will try to fill you up with the best possible fish for the price.
The parallel, of course is that you can choose a language or framework that provides you with a lot of choice, but where you need to have have a corresponding amount of expertise in order to make good choices. Or you can choose a language or framework that is designed to more or less work out of the box without you needing to understand all of the details.
Where I think it breaks down is that in a sushi restaurant, ordering "omakase" every time you go will result in a completely different experience each time -- all tuned to give the absolutely best possible experience from an objective perspective. "Omakase" in a framework gives you a homogenised experience which will bring you up to a particular baseline, but which is almost certainly not tuned for your situation.
I don't think it really 'breaks down', it's just a mildly wanky analogy and he explains what the design philosophy of Rails is without relying on the reader's familiarity with sushi ordering. I'm also generally sympathetic to Rail's desire to avoid crufty enterprise-y terminology. Their unchecked enthusiasm for it, though, makes reading anything Rails-related feel like dumbly leafing through a picture-less IKEA catalogue of an MLM company for personal growth and wellness products. But that's just me - being told to be happy by a web framework gets me like, right here, in the resentful Slavic soul.
Google does with all corporate sponsored projects. Most non-Google commiters just submitted simple bug fixes, most or all core maintainers are Google employees.
It's this way with every Google OSS project I know of. Guava, Angular, AMP, Chrome, Android, Tensorflow, gRPC. Sometimes they even de-facto take over existing projects, like Square's Dagger DI.
Google has no open source governance model unlike Apache, the chaos that is Linux or rust, or even Java's JCP. Since a fork is so expensive to maintain over time, many of these projects are open source only in name. Google invests enough money to keep anyone from forking. Pennies for them compared to the huge marketshare they get for having massive "safe" OSS projects that companies won't worry about adopting.
I don't know what "a community driven project" means because it doesn't use technical terms. The established technical concepts are stakeholders, consensus, and standardization. Go has clearly delineated stakeholders. These are few relative to Go's broader user base. Not being stakeholders, the broader user base is excluded from Go's consensus process. Go's stakeholders do not appear to value standardization of the language.
Sorry for not being clear. I used "standardization" in its established technical sense.
In general technical use, standards and specifications are different. Standards are technical documents published by an independent standards organization. For example ISO in the case of the C programming language and ECMA in the case of ECMAscript (i.e. Javascript). Standards (in conventional use) have formal processes for establishing stakeholders, submitting proposed changes, acting on proposed changes, and publishing changes to the standard.
Formal processes are not an inherent property of specifications. The Go specification could change in surprising ways tonight. Though it probably won't. The process for changing the Go specification can also change. Specifications are short lived. Standards are 'forever'. Fortran 77 is still Fortran 77 because of X3.9-1978.
It is common for specifications to incorporate standards by reference. For example a specification might include "the program should generate valid XHTML 1.1." The standards body W3C provides a process for determining conformance with the standard https://validator.w3.org/. T
His comments are fine, but don't engage with any of the criticism or concrete points others have made. The "Go Is Not a Community Driven Project" post really dug into detail how, in a specific case, Go did not behave as a community driven project, and it was made very clear that Go was Google's language, not the communities.
Responding with, in essence, "but we love the community!" is great, and probably true, but...unless it's followed up by "...and that's why we feel so badly about the previous events, and have made these specific changes" (or at the minimum a rebuttal of the specific criticisms), it doesn't really....mean anything?
Keep in mind, the closest we've got to introspection from Cox about the modules issue was a "I'm sorry everyone else is upset, I must have not explained things well enough" non-apology. Which is fine! The Go team doesn't need to apologise for running their language development process however they see fit...but it does underscore the issue.
Fundamentally, a decent chunk of the Go community thinks that the modules process was fundamentally broken, and the Go team thinks the modules process was fundamentally fine. I would interpret the subtext of Cox's post as "we really wish the community would be fine with the process". No doubt.
Finally, there's something a bit patronising about this:
> I spent a while trying to work out what I want to say about the general theme of Go and open source, but in the end I realized that my talk at Gophercon 2015 is a better articulation of what open source means for Go, and what Google's role is, than any email I can write in a few hours today. You can read the blog post version, “Go, Open Source, Community,” at https://blog.golang.org/open-source, and I am including a copy below. I reread it this morning, and I still believe everything I said then.
The current discussion is about events after 2015, by people who are well aware of that talk. If people are questioning how the Go team is interacting with the community even after that talk, then maybe it isn't sufficient, and you need to do more than just tell everyone to read it again?
It seems to me, as an outside observer, that golang is OSS. In that "hey, here's the code, you're welcome to tinker with it and all," but we're not accepting community contributions (or community contributions come under such heavy internal to Google scrutiny, they're unlikely to be accepted upstream, which discourages anyone from attempting).
Again, outside observer as a non golang user, but this is my impression. Any non-Google's contributing care to share experiences.
This perceived (on my part) hostility to the non Google user community definitely keeps me from even taking a look at it. I use C++, C# and Python professionally. I'd potentially give Rust a go if I had time to learn it (my job currently wouldn't allow it, as we're mainly a C# shop, only now branching into Python - few of the main reasons I was hired was business domain knowledge and +15 years experience in both C# and Python).
My 3 main languages all have active engagement with their user community and 2 of the 3 aren't controlled by a single corporation. C# is definitely driven by MS, bit they are actively engaged with their development community and listen to feedback and accept PRs for .Net Core.
I asked for people to contrafute my perception, not just a downvote.
I posted my perception as a nonuser, non member of the golang community, but with my perception of my perceived hostility against non googler memebers of the community...and I get met with no comments and downvotes, which reinforces my perception (deservedly or not) of hostility towards non-googler involvement in golang development. So, yeah, thanks. Golang is something I will now not likely something I will ever pursue.
> It seems to me, as an outside observer, that golang is OSS.
That seems fair, yes. Although while some people are unhappy because they're just not fans of that model, I think more of the unrest is because the Go team keeps saying they want it to be more community driven, and then there being a (perceived) disconnect between intentions and reality.
If your language has a BDFL, and they make arbitrary decisions, well, what did you expect? And lots of people are fine with that, and if you're lucky then, like Python, you can eventually transition to a more community driven model.
Sometimes it seems to me that the only people who think Go isn't being run exclusively by the Go team are the Go team themselves. :)
I think you've succinctly put the issue(s) I have with Go. Most languages either have a BFDL, a committee or a corporate DFL, which is the case with golang and Google, and I think to a far lesser extent with C# and MS. MS in the last few years seems far more accepting of community contributions to their "core" language, whether its ideas or actual PRs.
Admittedly, not all MS OSS projects are equal, there are a number of "here's the code", but it's going to be driven internally, versus a more traditionally driven mix of a primary corporate driver and OSS community contributions.
One of the things I'd love to see is a bespoke cross platform DB API. I'm currently using zillow's cTDS lib, which has been great, except it can't support table valued parameters, because FreeTDS doesn't. Yet pytds supports SVTPs, but seems to only support bulk copy via a file.
I wish that MS would provide a bespoke lib that provided all of this functionality (TVPs and BCP without an intermediate file).
> in a specific case, Go did not behave as a community driven project
Why are people saying this? What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? Rust does the right thing there, this is a fact.
Depends what you mean by "big", but between Docker, Influx, Cockroach, etcd, all the hashicorp projects (consul, nomad, terraform), caddy, grafana, bolt, etc., there's a fair number of pretty big golang project around.
> dep absolutely met the needs of most/all large projects and advanced users.
...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper, and dep critics were right to highlight it. That these critics might be mostly Googlers in this specific case would seem to be a red herring.
> ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper
No, it isn't. Most other dependency management tools don't allow this condition.
> Most other dependency management tools don't allow this condition.
Ah, but how many of these dependency-management tools are in fact "corporate" vs. genuinely community-led projects? Surely this too is relevant to the controversy.
> What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies?
There are many who would dispute your assertion very vigorously. I mean...the core issue was being able to have semantic import versioning, which is a feature most languages used in very large projects do not have. (And the most widely used language to try and solve the underlying issue is node, which is not well known for its suitability for large, complex projects, so...) And Cox tried and failed to explain why he thought semantic import versioning was important to a committee that included many people who had worked on large projects written in Go and other languages, so...must be a bit of a subtle issue. :)
But sure. Fine. Let's just accept your entire claim as fact for the sake of argument, because even so, the real concerns here have nothing do with whether or not dep was fit for purpose, it has to do with the Go team's unwillingness to work with the community over what it would mean for a modules tool to be fit for purpose.
If you piece together the different accounts, we can say with some confidence what happened, and it's pretty clear that the core issue is the dep team wanted to work with the Go team on a solution that met the needs of everyone, and the Go team did not, so they didn't.
Which is fine, of course. Cox had every right to refuse to talk to the dep team, throw their work away, and re-implement it from scratch. I'm sure he enjoyed developing vgo, and perhaps it even saved him time compared to having to explain his ideas to the plebians on the dep committee...but even if so, that's not how you have a successful community driven project.
> Rust does the right thing there, this is a fact.
Ironic then, that dep was a straight up effort to copy Cargo, and most critic's of the Go teams management of the language have looked to Rust as an inspiration.
> the core issue was being able to have semantic import versioning,
Well, the actual core issue was merely being able to use differing major releases as part of the same build, something that dep doesn't itself allow. SIV is a further tweak that's only really needed to address a common wart, namely re-exporting elements of the versioned API from one's imports without semantically-versioning them accurately in the process. What you really need is good semantic re-export versioning, which is a rather minimal subset of SIV!
I think one interesting aspect is to think what would happen if Ken Thompson and Rob Pike and the other original creators and active maintainers left Google?
And say, they still wanted to lead the project? Even though they no longer work? Could they? Or would Google appoint new people, and maybe Go would lose its magic?
I guess that's the difference between run by one or a few BDFLs and run by Google?
I am pretty sure (but not completely positive) that Ken and Rob don't really do much with Go these days. They have since moved on to other projects for the most part.
After all the drama surrounding the bureaucratic paralysis and legal encumberment of Java, I wouldn't touch another corporate language with a ten foot pole. Let Go Die.
As an aside, since the discussion mentions trademarking, whatever happened to the new branding announced [1] a year ago? The logo (which they did trademark, along with the name "Go") is also still not in use. The design wasn't received so well by the community, so did Google perhaps change their minds?
Go is just like many Google projects and Google "community" programs. They are basically a way to get free labor while benefiting Google first and foremost. That is a philosophy that goes right up to the top. Yes others benefit from the free software, and by fixing something you might be scratching your own itch, but if you invest any unpaid time towards developing for it you need to understand the Google controls everything (unless you fork it).
If you get on the wrong side of the Google activists, they will use the COC to invent a reason to kick you out of the main project. Some of Google's "community" programs are not as subtle about things. IE: The Google Developer Expert program in these "community" technologies such as Angular, Android etc. require the unpaid developer experts to sign non-disparagement agreements with Google while in exchange only getting a little bit of notoriety and a few comped trips and tickets to events...and of course Google is the gate keeper for it. The GDG program is even more flagrant. Each chapter is "independent" and has to raise their own money for things, but then Google tips the scales by throwing money towards programs that shill certain Google products. Google also has guidelines on how you market etc. things and is able to be a gate keeper on who is and isn't and organizer etc..
Many of the Google "community" "open source" packages are first only released to people under NDA's. I've seen this happen a few times with the some of the Android libraries etc..
Does that mean that Go is bad? No, in the same way that proprietary technologies are not bad. The key is understanding the truth from the propaganda.
Yes, Google effectively has final say over what goes into golang; that's never going to change. But then again, the same could be said of the cadres of people managing other languages. At the end of the day, SOMEONE has to be in charge, and that someone probably isn't you.
I personally like to have strong leadership behind such fundamental things as languages. I may not agree with all of their decisions, but at least I can count on the stability, which we all need in order to collaborate successfully. With strong leadership, I know I we won't have another Python2 vs Python3 mess.
And the ability to fork is very handy. I've forked my own golang compiler to allow warnings for unused imports, variables, etc [1] because I don't like fighting the compiler during debug or exploratory coding sessions.
> Google effectively has final say over what goes into golang
I'm wondering who has more say, Google or the individuals on the core Go team. My guess is that said people's personal opinion matters a lot more, or rather, almost exclusively.
How exactly would "Google" decide what goes into golang? They pay the Go team to do that, and I have a gut feeling that the Go team will do what the Go team wants to do, and not something else.
I would also be surprised if enough of them didn't have a sufficient amount of "fuck you money" to be able to effectively do what they want even if Google somehow managed to find someone who feels like they have any authority to tell the Go team which way to go (pun not intended).
Yes, I wasn't fully clear: It's the authors who wield the most power. Google as a whole doesn't really care so long as it works for the things they do (and it already does, so they really don't care anymore).
This isn't a case of an evil empire seeking to enslave our minds via a programming language; it's a company open sourcing their internally designed language, and engaging the community to make it more useful outside of Google (and to increase the number of people who use the language, which is always good because it means a greater pool of developers who could possibly work for them).
>There are certainly senses in which Go is Google's language: it was created at Google, Google continues to fund most of the development, and a few people at Google are the final deciders about the language itself. But I disagree with the “not ours:” I think Go is also the Go community's language.
Well, not if people in the Go community can't be promoted to be among "the final deciders about the language itself" without also being hired by Google.
Sure, the community is 1 million people. Nobody expects 1 million people to vote for Go's design and features.
But each language community develops prominent members, which for Go can be outside of Google too. E.g. like JS had Resig and Askenash, or Java had the various Java Apache project leads, Yoda time, etc people, or like Python has Kenneth Reitz, Armin Ronacher, the Twisted/Tornado guys and co. And some major projects, modules, etc, eventually emerge.
If those people can't get their (widely adopted by many in the community) proposals and changes into the language, and don't get the chance to be core team, them it's not a community language.
188 comments
[ 3.4 ms ] story [ 233 ms ] threadBut I think the final paragraph of this post only serves to highlight an issue brought up in the original post by Mr. Siebenmann.
The rebuttal says:
"There are certainly senses in which Go is Google's language: it was created at Google, Google continues to fund most of the development, and a few people at Google are the final deciders about the language itself."
I understand that the language can be owned by Google and the community, but the original take was:
"You could ask if Go is Google's language or the Go core team's language, since Go's direction is set and controlled by that small core team. However, at the moment I believe that most or all of the active Go core team is employed by Google, making the distinction impossibly to determine in practice (at least from outside Google). In practice we'll only get a chance to find out who Go really belongs to if Go core team members start leaving Google and try to remain active in determining Go's direction."
Seems like the rebuttal's concluding statement doesn't really address the biggest concerns.
The rebuttal continues to say that the development team tries to work with the community when possible. The original discussion here on HackerNews brought up examples where that is not always the case. I don't think a BDFL or a team acting as BDFL is a bad thing inherently, but I don't think this rebuttal really talks to the issues.
I once wanted to build a bunch of ML tools for Golang. Like coding up UMAP or other dimensionality reduction techniques, introducing some variational techniques, etc. But the package manager situation at the time (I thought of doing this 2 years ago) scared me off!
edit: I thought about this and did form a slight opinion on this article only. If we were to change the opening and concluding paragraph only (and retain the rest of the contents), it should have been titled "Go is Google's Language, and that is ok!" And then added a paragraph on how Google possibly abandoning the project wouldn't cripple it.
"..I've noticed that people often use the term “the Go community” without being particularly clear about what they mean. To me, the Go community is all Go users, which is at least a million people at this point. As such, it's at the very least imprecise to say things like “the Go community wants (or did) X.”
I think this is important because some outspoken members seems to have tendency to claim that they represent whole community and they must be heard and responded to even at the cost of quiet community members.
This seems a little implausible to me, can this really be the case?
Edit: Oh, I see the reference in the post https://research.swtch.com/gophercount (I'm still skeptical!)
The minor issue is the quantifying of developers. The methodology for the 15-20 million figure isn’t clear, but it at least passes some basic sniff test.
What’s completely bullshit is using stackoverflow surveys. There is no reason to believe the respondents of that survey are an unbiased cross section of the 20 million and many reasons to believe they aren’t.
I would totally expect the stackoverflow social 2.0 tech hipster webshit crowd that would fill out that dumb survey to be more likely to use Go. The same with oreilly surveys. Old grizzled grey beards aren’t as likely to fill out publisher surveys on old stable tech.
Also, answering that you have “used” go is not the same as being a regular developer (as noted by one of the commenters there... assembly is more “popular” than Go).
OTOH, regarding
> answering that you have “used” go is not the same as being a regular developer
The question they ask in the survey is: "Which of the following programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?", so it's more than just having "used" it.
Also I don’t think anyone that participates on this website has any moral superiority over tech hipster webshit. But it’s good to realize this is a skewed demographic.
Activist: "Over two million Americans signed our petition. You must do something!"
Politician: "So that means over 320 million didn't sign it. The majority clearly likes how things are!"
I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply. The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone.
The difference between an OpenJDK and an OpenGo project, in practice, would be that the two would be completely unrelated. Go core would go on ignoring community progress and, at best, Google would sue for the project to change the name and force a hard fork.
Can you explain why it makes sense to generalize a company of 50k developers, which has released 4000+ open source projects, on the basis of precisely 1 of them?
Why doesn't it make sense that it will end up with a variety of projects with a variety of models? Especially given that is true of the world writ large?
I simply do not understand this fixation with trying to rigidly pigeonhole Google on open source.
What Google projects would make good counterpoints by demonstrate a welcoming attitude to external contributions?
https://github.com/kubernetes/community/tree/master/contribu...
Please stop trying to attribute singular motivations behind a company with thousands of projects and many thousands more developers, it's so silly.
AOSP for another example.
Of those, only Gradle is external but the Android plugin is in house and it shows.
Kotlin its ran by an essentially two party Kotlin Foundation of Google and JetBrains.
This claim is belied by the fact that half of the people who have committers in Go are non-Googlers, isn't it?
One thing I'd be curious to know is how many of the committers didn't ever work for Google. I suspect some of the non-Googlers on the committer list maybe former Googlers...
But it might be an indication of how “open” Google is to complete outsiders as opposed to people who were insiders but now just happen to not work for Google. Whether or not that matters is another question entirely.
But like I said, I don’t think it matters in the context of how much control Google has over the language. Many successful languages are either driven by an individual benevolent dictator or a company. As far as I can tell, languages controlled by community/committees tend to evolve more slowly. That’s okay at some point in a project. But there is something to be said for a person/company having the ability to rapidly push through changes.
But this is also like a developed-in-open-source project, not a built-internally-and-copied-outside, so maybe the guidance differs there?
Or is that a go team specific thing?
This is correct. Use an existing github account, but your contributions should be under your @google email address. There's nothing that ties your github account to a git email. I've committed through github from like 4 different email addresses (@google, @gmail, @uni.edu, and a shared organizational one for a project from a shared machine).
Open source =/= community driven.
NIH syndrome was widely cited as one of the major flaws of the Smalltalk community back in the day. In any human endeavor, one has to fight the tendency of a group turning something which isn't a club, into a club.
That said, golang isn't a field. It isn't a genre. It's a computer language, a collection of libraries, and a number of online communities. In large part, it's a collection of tools with support around it, people interested in using it, and a company behind it. There are lots of things like this. Leica cameras. Rigol oscilloscopes. Chevy LS3 crate engines. Harley Davidson Motorcycles. These things live and die by continuing to garner the goodwill of the market and staying honest with themselves.
On the flip side, many of those things also live or die through good design, and good design also needs gatekeepers and visionaries. It's a balancing act. Golang in particular needs to watch its step. Since it has a syntax on the minimalist side with few surprises and easy access to its AST, it's going to be one of the easier languages to port off of.
rsc@'s clear disdain that anyone outside of google would run go is crystal clear in many of his various writings on issues like clock skew, packaging, etc
It's lucky bradfitz is, apparently, able to remember that a world outside of google exists.
If you've managed a large OSS project with a wide userbase before, you know how annoying it can be to deal with large numbers of repetitive requests from folks who don't have the full context of what's going on in the project. It's time consuming at best, and at worse some small minority of those folks take up a toxic attitude that sucks the happiness out of your work. There's no need to accuse maintainers of arrogance or NIH syndrome. This stuff is hard, and we all try to do the best we can.
Write some FAQ's, so that people are made aware of that context. An openly-developed project can actually be very successful at dealing with this, because pointing folks to the centralized discussion in which the pros and cons of commonly-requested feature X are dealt with becomes second nature after a while. We saw an example of this very recently with the surprisingly-mild brouhaha about Rust's choice of a postfix .await syntax.
For generics specifically, there's a "Summary of Go Generics Discussions", which is quite comprehensive: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
There are some people that hit the problem, start googling, and trying to find information, and some that just fire off email or stack overflow question (often so badly, you need several back and forth)
Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large and accommodating room)? I read almost all proposals for Generics, and, perhaps to my inexperienced eyes, the problem seems hard. The ramifications on the language design are not trivial, and the benefits, again, from my quite limited world view, are not so easy to quantify, otherwise how can one justify the extreme productivity spawned by the language? In the cloud business no less.
I have almost no stake in this, I don't even use the language professionally, but I find the supposed criticism a bit over the top. I'd wager that an example implementation of Generics that fits nicely with the language and works for a big and healthy code base would absolutely not go unnoticed by Russ and the other core members, but we have to accept that it is not easy.
Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/...
More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho...
The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.
Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor".
That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...
This for example, is my experiment with trying to give Go a backing calculus that supports generics https://asciinema.org/a/166748
The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too - essentially a different language
Well, isn't it a major typesystem change? Makes sense for it to apply to a big part of the runtime and semantics.
"measure twice, think twice, cut once"
(or even "think twice, cut once" if you want to generalise it to other spheres)
"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
https://go.googlesource.com/proposal/+/master/design/go2draf...
Even the ideas that eventually die on the Web, C++, Java and .NET happen to have preview implementations available to try out at one point, instead of dead paper.
People who need generics will use code generation until the issue is addressed, I don't really see the need to rush.
Attention to details is something I like about go.
The big reason for me to use GO is it's simplicity. I can pick any programmer, give him a few days to a week, and he will be productive.
Python used to be somewhat simple (never really that simple) with goal of having 1 "obvious" way of doing anything.
I think GO is better at that, than python ever was, and I think that is one of the bigger reasons for it's success.
Also, lots of code can be written in a bad language. And a language can be practical without being good from a language design perspective, the difference is in the richness of the ecosystem, the stdlib, and 'meeting programmers where they are'.
That's actually the problem. Bad languages require reading and writing too much repetitive code, just to replace missing abstractions.
Guava was always made available as Google's Java core utilities. I think it was always a misunderstanding to expect external contributions, like Apache Commons, as that was not its original intent. Rather it was to reduce internal duplication and ad hoc code with a shared standard. It then became useful for open-sourced Google projects (like API clients) and recruiting (new hires would be familiar with Google's libraries). Many suggestions are best spun off into new libraries, rather than donated to Google to maintain.
Java's many flaws have been papered over by a large ecosystem of libraries. As a non-gopher, I'm not sure if that same spirit exists. Perhaps that is due to the dependency debates, whereas Maven Central was quickly adopted when managing jars (via Ant) became too burdensome. Perhaps modules will help, as the language doesn't have to be batteries included.
You think the Guava team has a low opinion of patches? Does that mean Linux isn't a community project because Linus wields an iron fist when it comes to accepting patches?
(I don't use Go, so I don't have much insight into the overarching discussion. Just wanted to add my 2c).
It's also worth noting that Guava lives in a very different world from Go - the way we distribute Guava is (unfortunately) not designed for non-Google contributors and Guava needs to support multiple Java ecosystems/platforms (Android and servers, at least).
(Googler that works on neither Guava nor Golang.)
> You hereby grant to Google and to recipients of software distributed by Google 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 Your Contributions and such derivative works.
I was hoping that this would address the package management fiasco, but it did not.
Can we keep the discussion substantive?
I think OP has a point that perhaps could have been expressed more gracefully.
And note that I wasn't being snippy at you. Some of us have invested literally a decade in this at times infuriating language and are loathe to see it 'normalized' due to social pressure.
It seems like we will never hear the end of the apologias about how open Go is.
To me that betrays that it’s exactly the opposite.
I use Go, it’s useful, but i do so with a bad taste in my mouth: like someone’s stubborn opinions are being forced upon me.
Okay, fair enough ... but Go was always designed to be a small language with a limited set of features. Many reasonable requests may very well be reasonable on their own, but don't fit with the design aesthetics. It's like trying to add Common Lisp features to Scheme: that might be considered reasonable by some, but it doesn't really fit with Scheme's design. They kind of tried with R6RS and it was massively controversial, and many Scheme implementations stuck with R5RS.
This is the part that so many people don't seem to understand. They confuse "trying to maintain Go's minimalist design aesthetics" with "not open" and "unwilling to listen". Those are not the same things!
Some of the most frequently quoted examples all include things that have either been implemented, or at least seriously considered: monotonic clock, package management, generics (not implemented but Go Core team proposals go back to at least 2010). Arguably, some things took rather long, but again, Go is a small language and changes are discussed and considered for longer than most others. Many consider this good, as it provides a stable working environment to "get stuff done", which is the entire point of Go.
It's also not clear to me that exactly "community-driven" means? The entire community voting on all proposals? Accepting a proposal as long as a subgroup is loud enough? Very few projects – if any – operate like that. There is always a comparatively small group of core developers who, in the end, get to decide.
The design goal for Go seems to be to make a language where there is only one way to express a given algorithm.
They are trying to create a language where it is impossible to be clever.
This is not bad thing in itself, except when it starts to remove features that allow you to write clearer code.
For example I have a Java application that connects to a database. I _like_ that I can just let the transaction die for any uncaught exception that bubbles up from the DB layer.
I like that better than the idea of having to 'handle' a thousand possible errors from down there that I don't even understand. In some cases exceptions make for clearer code.
And don't even get me started about the lack of generics. That is a glaring omission that shows lack of understanding of the human factor in language design.
That they didn't anticipate this obvious feature makes me question the purity of the aesthetics.
This is all fine, and they are of course free to leave out whatever features they want: this is what makes it Google's language, after all.
1: Just one from today, inconsistent arithmetic with Durations.
* nil interfaces.
* duration arithmetic (easy to avoid once you understand it).
* multiple ways of instantiating things (var vs new vs literals)
Then why use it? Is there really nothing better?
For me it's good enough for some small tasks. I could find something better, but it's not worth it in some cases.
Keeping as constant Go's opinionated (for better/worse) management philosophy, I don't think there's anything the Go team can say to put this criticism to bed. It's simple: Rails can be "omakase" because Basecamp is a tiny company, and Go can't be (without gripes) because Google is a big company. Hell, it wasn't even clear a few weeks ago whether Clojure was allowed to gripe-free "omakase" status, and hardly anyone on HN has even heard of Rich Hickey's company.
Since, short of drastically changing how the project is managed --- something I don't think many Go users have an appetite for --- there's nothing they can do rhetorically to shut the argument down, I think it's best ignored.
If you don't want to use a project affiliated with Google, don't code in Go. Similarly, if you want to have large solo impact on core features of a language platform, like package management, set your sites somewhere other than Go, where fairly intensive gatekeeping to that kind of stuff is widely considered a feature, not a bug.
In this specific case (which is important to the discussion) there effectively was nothing you could call "management" in what the core tooling provided for resolving and fetching dependencies. I think the reason it wasn't there, was because that wasn't very important to Google which famously operates a company-wide mono repo. Dependency management wasn't a problem Google had, so an official solution was a very long time coming, and left the interim solution providers feeling quite raw.
If the code is guaranteed to work with the current version of the dependency and packages were built to not break their API, there would be no problem
I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
That's a lovely sentiment, but it doesn't help much when you've got no consistency between checkouts and builds are failing because of upstream changes that the code you're trying to work with doesn't even know it's using, and to try to fix an issue first requires you to spend days dealing with bitrot.
Here are some principles: 1. only the team working on a component should be able to break the build of that component. 2. Components should not break outside of commits.
The truth is, that your 'API' ends up being every part of your behavior that is relied on by your dependents and their dependents, ad infinitum, and it's almost impossible to make improvements without breaking such an API. Sometimes bugs are part of your de facto API.
It's one thing to say 'people shouldn't depend on these features, look it even says so in the doc', but should and shouldn't are moral judgements, what is and what is not are the distinctions that drive whether your development and release process are fit for purpose.
> I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
Well, there can be debate on the volume of problems on either side, but some other ecosystems attack this with tooling that can automate the process of getting notified that there's an upstream change, rebuilding with the new version, running the automated tests, and making it super easy to accept a commit updating the dependencies if the tests all work.
Semver addresses this. You stick with a specific major version (or minor version for a 0.x release, where "minor" version changes can in fact introduce major breaks), and your dependency tool enforces this. However, it does still warn you if a newer version is available, so that you can start depending on it. (Of course, switching to a newer release is easier said than done if other modules might still depend on the previous one, and your build tool doesn't support the concurrent use of both in the same build!) This is essentially a solved problem.
No-one "managed" the problem. They just sat and watch the community flail around for years.
If the community cannot agree on a simple thing like the package manager, imagine what'll happen if it was in charge of evolving the language
PHP, for all its warts, is 1) very community driven and 2) solved their package management problems via the community (with Composer). Go was not allowed to do that, because everyone knew that any solution had to be blessed by Google.
Go _is_ Google's project. They may let other people contribute but if Google's interests are not maintained, and further if the small core group who run it inside of Google disagree, you should not assume there is any way to override that. That's literally the point of what the original document was saying.
Lots and lots of us can live with that, but it would be much better if the golang contribution process was more explicit about that.
And with that lack of difference in mind: when the Go team says "Google's interests have little to do with how we're running Go", I'm strongly inclined to believe them, because what difference does it make? Why would they just make it up?
But really my point here is just: there's no point in the Go team engaging on this, because I literally can't think of a single thing Russ Cox could say to defuse this drama.
There's precedence, for instance, C# is Microsoft's turf.
Seems to me to be a basic human thing - if people are worried, downplaying their worries backfires.
But by not acknowledging it’s what they are doing they leave space for drama. Worse is if they think they are doing something else, because they are missing their intentions by a wide mark.
As others, I think the easiest thing Cox could say in response to these posts is: "Yeah, you're right. Go is open source but it's not community driven. There's a small, insular core team, we have full control over the language, we have a clear vision, we're going to follow that vision, and we think the results so far have justified this approach. We hope you choose to continue to use and, where appropriate, contribute to the project and the larger ecosystem."
Go is a very impressive project, and the core team does have very tight control over it, and (very plausibly) that tight control is responsible for the quality of the language. I don't think it necessarily needs to change; certainly not any time soon. Why not embrace it?
And I think, if he did that, it would end the drama in a heartbeat, because what's left to discuss?
Certainly there is some criticism than seems to focus on the idea that Go is controlled by Google, but I feel like that's, at most, a vocal minority. Then again, perhaps I just discount it because I find it pretty silly!
> Put differently: if Russ Cox resigned from Google, I imagine he'd probably remain involved with Go and have the same amount of influence.
I agree 100%.
(Of course, if your concern is how Russ Cox is managing Go, that probably doesn't make you feel better. If your concern is how Sundar Pichai is managing Go...well, I think we can both agree that's not a real issue.)
Quite a few of the core Go devs aren't hired by Google out of the general programming pool, they were already contributing to Go and then Google asked "hey, cool stuff; why not come work on Go for us?" Again, this is pretty much how you join any core group of developers: make good contributions, get asked. Except here you actually get paid.
Well, Python has this: https://www.python.org/dev/peps/pep-8016/#electing-the-counc... and you can also get to be a core team member (and many have). What about Go?
I think voting and whatnot are implementation details. That PEP says only core team members can vote who can join the core team, so core team choosing vs. core team voting is not all that different in practice.
https://www.youtube.com/watch?v=Pw9gaEiQAxY
people should be paid to work to a product under some direction, if you want some professional outcome
teams where people come and go rarely have built solid products
Take for example the Linux kernel, Alan Cox has been working on it non-stop from 1991 to 2009, and even after resigning as TTY maintainer, he was still heavily involved up to 2014
From 1999 to 2009 he was employed by RedHat and after That by Intel until 2013
I can't honestly say he did RedHat or Intel interests more than he did Linux community as a whole interests
He's a big advocate and activist for free software, but he also said "Yearn for the good old days when you knew every contributor by name and the source code fitted on a single floppy disc ?"
In a way or another, a small group of "directors" is always better for the good of both the product and the users
The issue here seems to be primarily one of trust. I can relate to that, as I don't like Google either, and actually mostly avoided Go for exactly that reason until I got hired as a Go developer a few years ago. I found that the Go project in particular is developed and managed in a fairly reasonable way; certainly much better than some other popular Google projects such as Android (the open parts of it anyway) or Chromium.
In other words, I think you should give them a chance, rather than immediately go "corporate Google overlords".
For what it's worth (and I say this is an outside observer who's never written any Go, so, grain of salt, etc.), I don't think the original post this responds to disagrees with your point. To wit, from that post:
> Or in short, Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.
and
> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it.
I don't think he's saying "Go is bad" or even "the management of Go is bad," but rather something more like "people should be honest about the nature of the management of Go, and choose how to engage with the community and the process accordingly."
While Google is certainly a big bish in that pond, there are plenty of other big fish to balance them out, including Cisco, Red Hat/CoreOS, Github, IBM, Intel and Docker.
Or invent a new organization. Call it "the Go Foundation". Make sure it's independent and has the bylaws and administrative structure to prove it. It's worked out pretty well for Python [2].
[1] https://www.cncf.io/
[2] https://www.python.org/psf-landing/
Who will run it? Activists ? You want the top talent working in/on go to be the people that run it. Now if GvR (python) or equivalent was contributing to go and he is hey I’m an awesome developer and an awesome language designer what gives with side lining me.
That would be a point. But now most top go talent that are working on the language are at google
Just like with k8s google may create a foundation for it or donate to one of the existing one when there is diversity in top contributors. I assume hope. Perhaps this activism is early
Example: I don't like all the things gofmt does, but if I accept what gofmt gives me, I can learn to live with it, and eventually be super happy :)
If go isn't opinionated, then what's the point? Whether owned by Google or a foundation, if the core team isn't small and opiniated, then aren't we just reinventing C++, hehe :)
Disclaimer: I work for Google, this is my personal opinion. (I actually haven't used golang since joining Google, but that's a different story)
We see something similar in the Java world. Even though the Java stewards are mostly Oracle employees, Oracle does not exert direct control over stewardship; the OpenJDK lead is elected by the OpenJDK board (whose chairmanship is reserved for Oracle, but has non-Oracle members). However, Oracle also funds 90% of the OpenJDK contributors, and the company can decide they want to fund work in certain areas but not in others. E.g. Oracle has reduced investment on client-side Java; some of that work is now contributed by another corporation (Gluon), but the total resources for client work are still reduced.
Because Google has many people working on OpenJDK (I think about the same number as those working on Go), it also has a lot of influence, as it can contribute large features (like the thread sanitizer they're now contributing).
Here is an explanation of Java's governance by Mark Reinhold, who is the OpenJDK lead and also Chief Architect of the Java Platform Group at Oracle: https://youtu.be/HpbchS5kmio
https://dhh.dk/2012/rails-is-omakase.html
The parallel, of course is that you can choose a language or framework that provides you with a lot of choice, but where you need to have have a corresponding amount of expertise in order to make good choices. Or you can choose a language or framework that is designed to more or less work out of the box without you needing to understand all of the details.
Where I think it breaks down is that in a sushi restaurant, ordering "omakase" every time you go will result in a completely different experience each time -- all tuned to give the absolutely best possible experience from an objective perspective. "Omakase" in a framework gives you a homogenised experience which will bring you up to a particular baseline, but which is almost certainly not tuned for your situation.
It's this way with every Google OSS project I know of. Guava, Angular, AMP, Chrome, Android, Tensorflow, gRPC. Sometimes they even de-facto take over existing projects, like Square's Dagger DI.
Google has no open source governance model unlike Apache, the chaos that is Linux or rust, or even Java's JCP. Since a fork is so expensive to maintain over time, many of these projects are open source only in name. Google invests enough money to keep anyone from forking. Pennies for them compared to the huge marketshare they get for having massive "safe" OSS projects that companies won't worry about adopting.
None of this is inherently bad or good.
This seems rather misinformed. Go has a spec https://golang.org/ref/spec and at least 2 alternative compilers in the form of gccgo and GopherJS.
I'd love to hear where do you base the notion that Go's stakeholders do not appear to value standardization of the language.
In general technical use, standards and specifications are different. Standards are technical documents published by an independent standards organization. For example ISO in the case of the C programming language and ECMA in the case of ECMAscript (i.e. Javascript). Standards (in conventional use) have formal processes for establishing stakeholders, submitting proposed changes, acting on proposed changes, and publishing changes to the standard.
Formal processes are not an inherent property of specifications. The Go specification could change in surprising ways tonight. Though it probably won't. The process for changing the Go specification can also change. Specifications are short lived. Standards are 'forever'. Fortran 77 is still Fortran 77 because of X3.9-1978.
It is common for specifications to incorporate standards by reference. For example a specification might include "the program should generate valid XHTML 1.1." The standards body W3C provides a process for determining conformance with the standard https://validator.w3.org/. T
Responding with, in essence, "but we love the community!" is great, and probably true, but...unless it's followed up by "...and that's why we feel so badly about the previous events, and have made these specific changes" (or at the minimum a rebuttal of the specific criticisms), it doesn't really....mean anything?
Keep in mind, the closest we've got to introspection from Cox about the modules issue was a "I'm sorry everyone else is upset, I must have not explained things well enough" non-apology. Which is fine! The Go team doesn't need to apologise for running their language development process however they see fit...but it does underscore the issue.
Fundamentally, a decent chunk of the Go community thinks that the modules process was fundamentally broken, and the Go team thinks the modules process was fundamentally fine. I would interpret the subtext of Cox's post as "we really wish the community would be fine with the process". No doubt.
Finally, there's something a bit patronising about this:
> I spent a while trying to work out what I want to say about the general theme of Go and open source, but in the end I realized that my talk at Gophercon 2015 is a better articulation of what open source means for Go, and what Google's role is, than any email I can write in a few hours today. You can read the blog post version, “Go, Open Source, Community,” at https://blog.golang.org/open-source, and I am including a copy below. I reread it this morning, and I still believe everything I said then.
The current discussion is about events after 2015, by people who are well aware of that talk. If people are questioning how the Go team is interacting with the community even after that talk, then maybe it isn't sufficient, and you need to do more than just tell everyone to read it again?
Again, outside observer as a non golang user, but this is my impression. Any non-Google's contributing care to share experiences.
This perceived (on my part) hostility to the non Google user community definitely keeps me from even taking a look at it. I use C++, C# and Python professionally. I'd potentially give Rust a go if I had time to learn it (my job currently wouldn't allow it, as we're mainly a C# shop, only now branching into Python - few of the main reasons I was hired was business domain knowledge and +15 years experience in both C# and Python).
My 3 main languages all have active engagement with their user community and 2 of the 3 aren't controlled by a single corporation. C# is definitely driven by MS, bit they are actively engaged with their development community and listen to feedback and accept PRs for .Net Core.
I posted my perception as a nonuser, non member of the golang community, but with my perception of my perceived hostility against non googler memebers of the community...and I get met with no comments and downvotes, which reinforces my perception (deservedly or not) of hostility towards non-googler involvement in golang development. So, yeah, thanks. Golang is something I will now not likely something I will ever pursue.
That seems fair, yes. Although while some people are unhappy because they're just not fans of that model, I think more of the unrest is because the Go team keeps saying they want it to be more community driven, and then there being a (perceived) disconnect between intentions and reality.
If your language has a BDFL, and they make arbitrary decisions, well, what did you expect? And lots of people are fine with that, and if you're lucky then, like Python, you can eventually transition to a more community driven model.
Sometimes it seems to me that the only people who think Go isn't being run exclusively by the Go team are the Go team themselves. :)
Admittedly, not all MS OSS projects are equal, there are a number of "here's the code", but it's going to be driven internally, versus a more traditionally driven mix of a primary corporate driver and OSS community contributions.
One of the things I'd love to see is a bespoke cross platform DB API. I'm currently using zillow's cTDS lib, which has been great, except it can't support table valued parameters, because FreeTDS doesn't. Yet pytds supports SVTPs, but seems to only support bulk copy via a file.
I wish that MS would provide a bespoke lib that provided all of this functionality (TVPs and BCP without an intermediate file).
Why are people saying this? What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? Rust does the right thing there, this is a fact.
And most of them seemed pretty happy with dep...
...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper, and dep critics were right to highlight it. That these critics might be mostly Googlers in this specific case would seem to be a red herring.
No, it isn't. Most other dependency management tools don't allow this condition.
Ah, but how many of these dependency-management tools are in fact "corporate" vs. genuinely community-led projects? Surely this too is relevant to the controversy.
There are many who would dispute your assertion very vigorously. I mean...the core issue was being able to have semantic import versioning, which is a feature most languages used in very large projects do not have. (And the most widely used language to try and solve the underlying issue is node, which is not well known for its suitability for large, complex projects, so...) And Cox tried and failed to explain why he thought semantic import versioning was important to a committee that included many people who had worked on large projects written in Go and other languages, so...must be a bit of a subtle issue. :)
But sure. Fine. Let's just accept your entire claim as fact for the sake of argument, because even so, the real concerns here have nothing do with whether or not dep was fit for purpose, it has to do with the Go team's unwillingness to work with the community over what it would mean for a modules tool to be fit for purpose.
If you piece together the different accounts, we can say with some confidence what happened, and it's pretty clear that the core issue is the dep team wanted to work with the Go team on a solution that met the needs of everyone, and the Go team did not, so they didn't.
Which is fine, of course. Cox had every right to refuse to talk to the dep team, throw their work away, and re-implement it from scratch. I'm sure he enjoyed developing vgo, and perhaps it even saved him time compared to having to explain his ideas to the plebians on the dep committee...but even if so, that's not how you have a successful community driven project.
> Rust does the right thing there, this is a fact.
Ironic then, that dep was a straight up effort to copy Cargo, and most critic's of the Go teams management of the language have looked to Rust as an inspiration.
Well, the actual core issue was merely being able to use differing major releases as part of the same build, something that dep doesn't itself allow. SIV is a further tweak that's only really needed to address a common wart, namely re-exporting elements of the versioned API from one's imports without semantically-versioning them accurately in the process. What you really need is good semantic re-export versioning, which is a rather minimal subset of SIV!
Senator: "Mr. Mayer works for you, does he not?"
Mr. Hughes: "He does."
Senator: "And what is his official title?"
Mr. Hughes: "Well I don't exactly know, Senator. A lot of people work for me."
Senator: "Explain why your press agent would pay out $170,000 to representatives of the United States Air Force."
Mr. Hughes: "Well I don't know, I suppose you'd have to ask him, Senator."
Senator: "Well would you produce him?"
Mr. Hughes: "Produce him?"
Senator: "Will you cause him to appear?"
Mr. Hughes: "Senator, you had John Mayer on the stand for three days last week."
Senator: "Well be that as it may, we would like him to reappear. Would you ask him to return?"
Mr. Hughes: (long pause) "No, I don't think I will."
Senator: "Will you try to have him appear?"
Mr. Hughes: "No, I don't think I'll try."
Senator: "You don't think you'll try..."
Mr. Hughes: "No... I don't think so."
In other words, go fork yourself, Senator.
And say, they still wanted to lead the project? Even though they no longer work? Could they? Or would Google appoint new people, and maybe Go would lose its magic?
I guess that's the difference between run by one or a few BDFLs and run by Google?
[1] https://blog.golang.org/go-brand
Go is just like many Google projects and Google "community" programs. They are basically a way to get free labor while benefiting Google first and foremost. That is a philosophy that goes right up to the top. Yes others benefit from the free software, and by fixing something you might be scratching your own itch, but if you invest any unpaid time towards developing for it you need to understand the Google controls everything (unless you fork it).
If you get on the wrong side of the Google activists, they will use the COC to invent a reason to kick you out of the main project. Some of Google's "community" programs are not as subtle about things. IE: The Google Developer Expert program in these "community" technologies such as Angular, Android etc. require the unpaid developer experts to sign non-disparagement agreements with Google while in exchange only getting a little bit of notoriety and a few comped trips and tickets to events...and of course Google is the gate keeper for it. The GDG program is even more flagrant. Each chapter is "independent" and has to raise their own money for things, but then Google tips the scales by throwing money towards programs that shill certain Google products. Google also has guidelines on how you market etc. things and is able to be a gate keeper on who is and isn't and organizer etc..
Many of the Google "community" "open source" packages are first only released to people under NDA's. I've seen this happen a few times with the some of the Android libraries etc..
Does that mean that Go is bad? No, in the same way that proprietary technologies are not bad. The key is understanding the truth from the propaganda.
I haven't heard of this. What's the rationale?
I personally like to have strong leadership behind such fundamental things as languages. I may not agree with all of their decisions, but at least I can count on the stability, which we all need in order to collaborate successfully. With strong leadership, I know I we won't have another Python2 vs Python3 mess.
And the ability to fork is very handy. I've forked my own golang compiler to allow warnings for unused imports, variables, etc [1] because I don't like fighting the compiler during debug or exploratory coding sessions.
[1] https://github.com/kstenerud/go
I'm wondering who has more say, Google or the individuals on the core Go team. My guess is that said people's personal opinion matters a lot more, or rather, almost exclusively.
How exactly would "Google" decide what goes into golang? They pay the Go team to do that, and I have a gut feeling that the Go team will do what the Go team wants to do, and not something else.
I would also be surprised if enough of them didn't have a sufficient amount of "fuck you money" to be able to effectively do what they want even if Google somehow managed to find someone who feels like they have any authority to tell the Go team which way to go (pun not intended).
This isn't a case of an evil empire seeking to enslave our minds via a programming language; it's a company open sourcing their internally designed language, and engaging the community to make it more useful outside of Google (and to increase the number of people who use the language, which is always good because it means a greater pool of developers who could possibly work for them).
Well, not if people in the Go community can't be promoted to be among "the final deciders about the language itself" without also being hired by Google.
Sure, the community is 1 million people. Nobody expects 1 million people to vote for Go's design and features.
But each language community develops prominent members, which for Go can be outside of Google too. E.g. like JS had Resig and Askenash, or Java had the various Java Apache project leads, Yoda time, etc people, or like Python has Kenneth Reitz, Armin Ronacher, the Twisted/Tornado guys and co. And some major projects, modules, etc, eventually emerge.
If those people can't get their (widely adopted by many in the community) proposals and changes into the language, and don't get the chance to be core team, them it's not a community language.