Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

Post reply on HN
Print view View original

81–90 of 679 posts

Re: Go is Google's language, not ours

#81

Post by pbowyer »

rococode wrote: post #66
fetbaffe wrote: post #54

Earlier quoted context omitted.

For community driven programming languages I would say PHP, large user base, mature & very active.

I'd use this as an argument that if PHP is the gold standard for a community-driven programming language, I'd rather every popular language be backed by a large corp haha. Actually, even ignoring PHP, I'm vaguely convinced it's generally better for a language to be backed by a company. I personally feel more secure knowing that there are people whose full-time job is to take care of the language, and I trust communit…

Having observed the decision-making process for 6 months and thought about PHP's direction, I'd agree.

Either a foundation is needed, which sets a vision and sticks to it, or a company, or a BDFL. But with none of them, you get each language faction pulling in its own direction, bits of each added/retained, and no coherence.

Re: Go is Google's language, not ours

#82

Post by silvester23 »

jmtulloss wrote: post #23

The article uses "Google" instead of individuals names to make the actions taken seem like sinister actions of a faceless corporation. My interpretation is that Google employs a tight-knit group of people that work on Go and collectively are the BDFLs of the language. This isn't that much different from most large OSS projects, although it does seem likely that this core team weights the opinions of those that they i…

The last two paragraphs of the article address exactly that issue - that it's hard to tell whether the direction of Go development is decided solely by the Go core team or by Google as a corporation.

Re: Go is Google's language, not ours

#83

Post by nickm12 »

> Python has always been Guido van Rossum's language regardless of who he worked for at the time.

(from the article) I think the high-level point that Python has not been tied to a company is true, but it's not been true that Python is "Guido's language" for decades. Python has a very effective community process. Guido has certainly served as a tie-breaker and of course as BDFL (no longer!), but I see the language being largely steered by the community and community leadership.

Re: Go is Google's language, not ours

#84

Post by Illniyar »

Google are bad at building developer communities (or at the very least they don't care about it much). They build things for themselves and their way is the Ivory Tower way of running a community. The overlords decide and their word is set in stone, the plebs should just accept the fact that their concerns and use cases are just too trivial and they should listen to the smart people at google and do it their way, which is the only way.

This isn't the first time google open sources internal tools, trying to build a community but really ignoring them completely. GWT, Closure compiler and of course Angular comes to mind.

Angular built a great momentum and community, and the angular team at google basically ignored most ongoing concerns to work on their next big project that'll fix everything (first it was Object.observe, then dart then angular 2).

Contrast google's handling of Angular to Facebook's handling of React (and react-native) - The routinely incorporate community influencers into the core team, they include other major corporations in their decisions and community, actively engage in developer relations to get feedback, explain controversial choices and build a community.

Sun's model with Java is even more different - incorporating major stakehodlers in the language into the actual decision process via the JCP.

Of course Google isn't the only ones who are bad at building developer communities around their open source. Apple and Amazon barely even try.

If google is Ivory tower, Microsoft is the Herbalife way of building a developer community - actively supporting influencers, providing official seals of approval and using a top down hierarchy of advocates. They do listen to community input a lot more, but Microsoft is still the overlords of all their projects.

Re: Go is Google's language, not ours

#85

Post by xyproto »

crimsonalucard wrote: post #52
theshrike79 wrote: post #37

Earlier quoted context omitted.

In my opinion the way they are handling adding Generics to Go is proof of this model working. They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.

Parametric polymorphism is a tool to solve real world issues with.

It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.

Re: Go is Google's language, not ours

#87

Post by tamrix »

Golang solves a specific domain problem google has.

They extended plan9s c compiler with some syntax Sugar for co routines and fixed some whacky c stuff then threw in some gc.

There's new and innovated about golang.

They just had to open source golang because they used the plan 9 c compiler which was open source.

Re: Go is Google's language, not ours

#88

Post by PetitPrince »

ncmncm wrote: post #67
dtrailin wrote: post #44

Earlier quoted context omitted.

Each of the languages you mentioned is wildly popular, well run, and not going anywhere. If you chose not to learn Java a decade ago because you "knew better" you aren't any better off than you were before, given that this language is the core foundation many companies and open source projects, maintaining relevance for 20 years. Not learning Swift now means you won't be able to do effective IOS development. Not lear…

You can fork them and become (or remain) irrelevant. Ios development is a walled garden. C# is barely used except to target Windos. Go? Too early to say. If it did fade away, who would miss it, really ? Its express design purpose was to be not powerful enough to make big mistakes in. Has it transcended that? If so, what is its purpose now? Java has shown staying power, despite its shortcomings, although its connectio…

>C# is barely used except to target Windos

The Unity game engine use C# for scripting; I wouldn't call that "barely used".

Re: Go is Google's language, not ours

#89

Post by ncmncm »

pushpop wrote: post #49
ncmncm wrote: post #6

This. But Go is one in a long line of proprietary languages that those of us who have been around the block know to stay away from. Recently: Java was Sun's, C# is Microsoft's, Swift is Apple's, Go is Google's. With any luck, all will be footnotes in ten years. Those of us who knew better than to get invested in them will be fine. Everyone else gets a chance to learn something.

I’m guessing you don’t use C or C++ either then because they were proprietary Bell Labs languages. You should probably rule out assembly too because they will have proprietary instructions for proprietary CPUs. Which means if you really want to be freed from the shackles of using proprietary tools when programming you’re now building your own hardware too, processors and all. Good job ASCII isn’t proprietary otherwis…

Guess away, but both C and C++ broke out of Bell control very, very quickly by language standards.

Now they are driven by ISO Standards bodies, with many, many participants -- ATT not among them anymore, to my knowledge. Even in 1995 ATT had nothing approaching veto power.

My remarks lumping Java in with C# and Swift are transparent wishful thinking.

Re: Go is Google's language, not ours

#90

Post by _ph_ »

crimsonalucard wrote: post #52
theshrike79 wrote: post #37

Earlier quoted context omitted.

In my opinion the way they are handling adding Generics to Go is proof of this model working. They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.

But that is exactly the point - you would have added the best proposal available to the language vs. waiting till all issues are worked out with generics. Go 1.0 has been released 7 years ago, in that time a ton of happy Go users were able to use Go as it is. All the discussions on generics clearly show, that the Go team is interested adding them, but that all proposals so far had distinct shortcomings.

Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.

Post reply on HN