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

351–360 of 679 posts

Re: Go is Google's language, not ours

#351

Post by nudq »

repolfx wrote: post #228
tremon wrote: post #192

Earlier quoted context omitted.

That's not really a problem for computer science students, I think. Their area of focus tends to be on the algebraic, theoretical side of the spectrum. It's much more of a problem for computer (software) engineers.

Be careful. Rob Pike asserted Googlers can't handle an "advanced language" or whatever his exact words were, but he provided no evidence this was true, or that others at Google agreed with him, or that this was even the reason Go was created to begin with. The most obvious evidence he's wrong is that Google's codebase is all C++ and Java, both languages that have generics and other more advanced features than Go. So…

Occam's Razor: Did he really make up a strange claim that reflects negatively on his employer, or was something very much like what he said actually part of his brief?

I believe it was the latter, the twist being that it was forward looking, not reflecting then-current reality. It was likely someone else's prediction that the quality of talent available to Google will go down, going forward.

Re: Go is Google's language, not ours

#352

Post by divan »

brown9-2 wrote: post #255
divan wrote: post #151

It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations. Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team)) There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2] The way how…

In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-15075...

It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community".

So we have

a) Google having problems with lack of monotonic clock in Go

b) Go team reluctant to break API and break promise of compatibility without really serious reason

c) community feedback in form of well written experience report, explaining how serious the issue is for the community

d) immediate reaction and efforts to find a solution (without breaking API)

Even though team was dismissive of the idea, feedback from the community made them to change their minds.

Re: Go is Google's language, not ours

#353

Post by TheCondor »

mieseratte wrote: post #301
akerro wrote: post #186

Earlier quoted context omitted.

>everyone's pet feature Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.

> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.

That this very thread exists suggests a certain “C++ ification” that happens to languages.

I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.

Re: Go is Google's language, not ours

#354

Post by 72deluxe »

0815test wrote: post #307
logimame wrote: post #295

Earlier quoted context omitted.

From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. (I “kinda” get it, but am not confident about it). It seemed more and more convoluted every time I tried to study about it. The complexity created by implicit and explicit copy/move constructors is just insanity for me...

> From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. ... The complexity created by implicit and explicit copy/move constructors is just insanity for me... This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit…

So what if I have an object that has a pointer to another object? memcpy is not what I want in that instance.

Re: Go is Google's language, not ours

#355

Post by bunderbunder »

dullgiulio wrote: post #197
EtienneK wrote: post #191

Earlier quoted context omitted.

"Java has been ruined by the push to include everyone's pet feature." Care to expand on this? Java is very careful to release new features.

It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writ…

> streams and related functional features

Streams are inspired by some idioms of functional programming. But they are not functional, and they cannot be made to be functional, because it is impossible to evaluate one without causing a rather glaring side effect.

Re: Go is Google's language, not ours

#356

Post by slykar »

cryptos wrote: 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…

> I wonder why so many companies are happily paying Oracle [...] instead of sponsoring an open source project like PostgreSQL.

Corporate world is ruled by liability. When you are working on a multi-million dollar project and the database breaks, you want to be able to put as much responsibility on the 3-rd party as much as possible.

Open Source projects come with no guarantee. If someone hacks into a system because of a flaw in the Open Source project you are screwed. If it's a software delivered by Oracle, then Oracle is responsible and needs to pay your million dollar fine.

Of course I'm simplifying, because there's probably still a lot of legal process behind it depending on the country, but it's essentially that.

Re: Go is Google's language, not ours

#357

Post by 72deluxe »

logimame wrote: post #295
72deluxe wrote: post #179

Earlier quoted context omitted.

Not sure - I thought it got significantly better with C++11/14? Admittedly it also became rather more complicated, but the changes were generally for the best I thought?

From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. (I “kinda” get it, but am not confident about it). It seemed more and more convoluted every time I tried to study about it. The complexity created by implicit and explicit copy/move constructors is just insanity for me...

Read "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14" by Scott Meyers.

That'll clear it up for you. It's a very good book. rvalue references are a bit muddy but move semantics should be clear.

Do you have Stroustrup's blue book?

Re: Go is Google's language, not ours

#358

Post by lllr_finger »

pjmlp wrote: post #149

I pity the recent CS graduates that weren't able to attend a decent CS degree and need Go to fit their mental model.

I look at it as a collection of any guarantees that you can leverage to ensure a (relatively) high degree of correctness, performance, and maintainability. I can't fault Google for valuing these things over agency to play with languages that feel more fun/interesting.

Re: Go is Google's language, not ours

#359

Post by nudq »

jolfdb wrote: post #328
foldr wrote: post #261

Earlier quoted context omitted.

I sort of agree with that, but features often have externalities. For example, let's say I choose to use lambda case because it makes some of my code a little bit more concise. From my narrow point of view, that seems like a win. But then it's one more piece of syntax that external tools have to deal with, one more barrier to anyone trying to develop an alternative to GHC, one little piece of additional complexity to…

Do you need an alternative to GHC?

What's GHC's bus factor? (Actual question.)

Re: Go is Google's language, not ours

#360

Post by nudq »

jbergens wrote: post #346
willtim wrote: 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.

Wasn't Haskell created by a university? That would be more tax dollars than community-driven.

I think Haskell was largely derived from Miranda, a commercial product.
Post reply on HN