Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

121–130 of 679 posts

Re: Go is Google's language, not ours

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

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…

Whether Kubernetes is important for you, and whether Go matters as a language for implementing it is very much the question. Kubernetes was started in Java, and Kubernetes developers themselves describe it as incoherent mess of dozens of daemon programs in various stages of completion in the process of refactoring Java idioms into Go while introducing redundancies due to Go's limited code organization facilities.

Re: Go is Google's language, not ours

#122
post #56

Earlier quoted context omitted.

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 real world issue. ...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.

> ...what in the world makes you thing that?

Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.

Re: Go is Google's language, not ours

#123

>> But Google is the gatekeeper for these community contributions; it alone decides what is and isn't accepted into Go. So ... much like Linux where Linus is the gatekeeper, and he decides what goes in and what doesn't, and also abuses people while at it?

But he's trying to be nicer, so cut him some slack :)

Re: Go is Google's language, not ours

#124
post #45

Earlier quoted context omitted.

Ten years is a very short time for a programming language. Python is decades old and hasn't hit its peak popularity yet. I don't know of a single mainstream language that has died, except for perhaps ColdFusion or ActionScript.

Depends on how you define death. There's ALGOL, SNOGOL, LOGO, Pascal, Visicalc, APL... They were all mainstream at a point, and they all still exist, but the userbase has become tiny.

OK, but it is "SNOBOL".

Re: Go is Google's language, not ours

#125
post #92
post #75

Haskell is an excellent example of a community-driven language. It's more mature and advanced than most commercial offerings too, offering a superior type system, fast and efficient executables, lightweight fiber concurrency, software transactional memory, higher-kinded parametric polymorphism and many more features.

Haven’t most of the top Haskell devs been on the Microsoft payroll for years and years?

SPJ and a fe wothers work at microsoft, but they are few compared to the community. Likewise, several high profile haskellers were at Standard Chartered, but I don't believe this was significant.

I would say the main drivers of Haskell these days are academics, PhDs and consultancies.

Re: Go is Google's language, not ours

#126
post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

Debian is 1000 developers with mostly decentralised decision making with some voting for project-wide issues using Condorcet.

Re: Go is Google's language, not ours

#127
post #106
post #38

Earlier quoted context omitted.

you shouldn’t let an article decide what language you learn.

How many do you consider enough?

none. articles on the web are made for clicks. judge a language on its own merits, not via what someone on the web said.

Re: Go is Google's language, not ours

#128
post #14

"... can't we have something like OpenGo ..." > " ... this won't happen ... " I'm confused as to what's stopping someone from forking it, calling it OpenGo, and building a community around that.

Running project like this is a full-time job. It can't be done in a spare time.

Re: Go is Google's language, not ours

#129

Earlier quoted context omitted.

Depends on how you define death. There's ALGOL, SNOGOL, LOGO, Pascal, Visicalc, APL... They were all mainstream at a point, and they all still exist, but the userbase has become tiny.

OK, but it is "SNOBOL".

That too. :-)

Re: Go is Google's language, not ours

#130
post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

Apache and Linux have always been the two big examples of community-driven open source projects. And Apache still hosts many community-driven open source projects, but they don't seem to be as visible as they were 10-15 years ago.
Post reply on HN