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

Russ Cox is stepping down as the Go tech lead

groups.google.com

Post reply on HN
Print view View original

151–160 of 396 posts

Re: Russ Cox is stepping down as the Go tech lead

#151

Post by jeffrallen »

hankman86 wrote: post #147

Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.

A goal of Go was to put working on complex distributed systems within the reach of the junior people Google had access to in the quantity they were hiring. To whit, the kind of people who would have been able to work on a big Python system with 3 months ramp up or on a big C++ system with a year of ramp up.

It is pretty clear that with respect to that goal, Go is a success. It has attracted Python programmers who need type safety and performance. Someone with no Go experience could land a useful new feature in a big Go program in 3 months.

Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go. Which means to me that if Rust had been aiming at this same adoption goal (it wasn't) it would not have succeeded where Go did.

Re: Russ Cox is stepping down as the Go tech lead

#152

Post by weinzierl »

hankman86 wrote: post #147

Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.

This is an interesting question, but I doubt you will get a satisfactory answer here and probably anywhere. There is probably not even a uniform opinion about this within Google.

What I am more curious about is how much actual use Go has within companies and especially Google. What is the percentage of Go within their monorepo? How much of Google search is powered by Go?

Re: Russ Cox is stepping down as the Go tech lead

#153

Post by the_duke »

klartd wrote: post #67

Thanks for all the Go contributions! I disagree on one point that has nothing to do with Go. Python has not benefitted from GvR stepping down. The new "leadership" is non-technical, tyrannical and has driven almost all true open source contributors away. Development has stalled except for the few corporate contributions of doubtful quality. The atmosphere is repressive and all that matters is whether you have a posit…

> Development has stalled except for the few corporate contributions of doubtful quality.

Do you have some data to back that up?

The stats on Github seem to show healthy activity. 700+ merged PRs from 120+ contributors in the last month [1].

There seems to have been a big influx of new contributors in the last few years. [2]

[1] https://github.com/python/cpython/pulse/monthly

[2] https://github.com/python/cpython/graphs/contributors

Re: Russ Cox is stepping down as the Go tech lead

#154

Post by hellojesus »

TheDong wrote: post #137
hdesh wrote: post #135

Earlier quoted context omitted.

> Basically, the Go team is a bunch of old white dudes, which already means the project is poorly managed from the start This seems like a broad generalization. Can you please elaborate?

[flagged]

> Special attention like having diverse people in positions of power.

You realize that selecting people based on "diverse" qualities is the very act of racism/sexism/whatever-ism, right? You propagate what you claim to oppose.

Re: Russ Cox is stepping down as the Go tech lead

#155

Post by cookiengineer »

pansa2 wrote: post #124
lolinder wrote: post #96

Earlier quoted context omitted.

Yes. And? Programming languages more than almost any other type of project end up swamped with thousands of competing requests to implement mutually incompatible features. Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption.

> Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption. Unfortunately that’s not at all true - Go is a real outlier here. If it were true, we’d all be writing C instead of C++, Lua instead of Python and ES5 instead of TypeScript.

The choice is yours. Don't blame your choices on other people's opinion that you don't agree with. Everything in life is a tradeoff.

If you don't agree with the available languages, make it better. That's the power of open source :)

Re: Russ Cox is stepping down as the Go tech lead

#156

Post by cocok »

amiga386 wrote: post #94

thanksStr := "thank you rsc" ret, err := sayThanks(thanksStr) if err != nil { return nil, err } return ret, nil

Can anyone familiar with Go explain why not

  return sayThanks(thanksStr)
I've seen this "if err != nil" pattern before, but I can't help thinking that it's not necessary.

"return ret, nil" ignores err's value, which is nil anyway.

"return nil, err" ignores ret's value, but why? If the caller checks for err before doing anything with ret, it doesn't hurt having ret always passed up.

4 extra lines only to lose the value of ret in case of error.

Re: Russ Cox is stepping down as the Go tech lead

#157

Post by randomdata »

hankman86 wrote: post #147

Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.

Go was never intended to be a C/C++ successor, it was intended to solve a class of problems that Pike and gang experienced in the software they worked on. Which is to say network servers. What you are probably remembering is that they assumed from their unique Google lens that it was C++ developers who had those same problems and would see it as an alternative to C++ when faced with those problems, but it turned out that in the "real" world people were writing network servers in Python and Ruby, not C++.

Which isn't surprising to the rest of us. If you remember the days before Go, every second thread on HN was about how "company X", including the company now known as X, saw their Ruby network servers completely falling down under load, forcing a rewrite in whatever the language du-jour was that day. But Googlers tend to live in a completely different bubble with respect to the way software is written.

Re: Russ Cox is stepping down as the Go tech lead

#158

Post by cookiengineer »

hoten wrote: post #19
tomcam wrote: post #5

IMHO Go has been one of the best-managed open source projects ever. Hats off to Google for supporting it.

What are some things that make it well managed?

The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language.

If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly.

Unified codestyle, unified paradigms, unified toolchain.

It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion upstream is better than no opinion downstream.

That's why go's toolchain isn't as messed up as npm, yarn, grunt, gulp, webpack, parcel, babel and other parts of the ecosystem that have no conventions and are therefore as a result very expensive to maintain.

Re: Russ Cox is stepping down as the Go tech lead

#159

Post by tptacek »

cocok wrote: post #156
amiga386 wrote: post #94

thanksStr := "thank you rsc" ret, err := sayThanks(thanksStr) if err != nil { return nil, err } return ret, nil

Can anyone familiar with Go explain why not return sayThanks(thanksStr) I've seen this "if err != nil" pattern before, but I can't help thinking that it's not necessary. "return ret, nil" ignores err's value, which is nil anyway. "return nil, err" ignores ret's value, but why? If the caller checks for err before doing anything with ret, it doesn't hurt having ret always passed up. 4 extra lines only to lose the value…

You can golf it down to

    return sayThanks("thank you rsc")
without losing anything, but then it could just as easily be JS.

Re: Russ Cox is stepping down as the Go tech lead

#160

Post by denysvitali »

cocok wrote: post #156
amiga386 wrote: post #94

thanksStr := "thank you rsc" ret, err := sayThanks(thanksStr) if err != nil { return nil, err } return ret, nil

Can anyone familiar with Go explain why not return sayThanks(thanksStr) I've seen this "if err != nil" pattern before, but I can't help thinking that it's not necessary. "return ret, nil" ignores err's value, which is nil anyway. "return nil, err" ignores ret's value, but why? If the caller checks for err before doing anything with ret, it doesn't hurt having ret always passed up. 4 extra lines only to lose the value…

In this case, the if err != nil is completely useless.

Usually the pattern is used to perform better error handling (wrapping errors) or in case you call multiple functions that might return an error.

In this case, your suggestion is actually what I would expect to see

Post reply on HN