[HN Gopher] The Problem with Go
___________________________________________________________________
The Problem with Go
Author : nnnand
Score : 148 points
Date : 2022-11-02 16:56 UTC (6 hours ago)
(HTM) web link (vanitynotes.com)
(TXT) w3m dump (vanitynotes.com)
| dom96 wrote:
| This seems a rather long article to basically say "It's too
| difficult to contribute to Go".
|
| Hope the above saves you a click.
| schmichael wrote:
| As a "maintainer" of an open source project with a corporate
| backer/owner, I sympathize with Google. Changing anything, even
| an "obvious" bug fix, is a lot of work: are there tests? Do
| existing tests need fixing? How will this affect all existing
| users who may now rely on the buggy behavior? Are docs updated?
| Are there any legal/provenance/attribution concerns? Does this
| effect any internal issues or goals? Were there plans to approach
| the problem a different way? Is this bug worth my limited time to
| answer all of these questions or could I have a higher impact
| delivering something else?
|
| None of this is insurmountable, but I do think it explains the
| effort it takes to merge even a one line bug fix.
|
| At the end of the day Go is the most stable language I've worked
| with in my entire career. It's far from perfect, but it's
| unbelievable how stable it is. In 6 years of working on nomad I
| can count the times an upgrade caused a regression in nomad on
| one hand, and nomad uses a lot of Go. Coming from Java and Python
| (and the MS ecosystem before that) this is _unreal._ We just
| _never_ updated Java at a previous job. Python upgrades were
| _significant_ time investments and never were completed without
| regressions.
|
| While it would be nice to have this level of stability without
| googles heavy hand bureaucracy, I can't think of an example of
| that happening.
|
| I think a lot of folks at Google who work on Go are trying to
| improve this situation, but it's harder than any technical
| problem.
| kapilvt wrote:
| corporate backer/owner on oss project is a bit different from a
| language as far as scope of users. and to wit minus java
| (arisen from its oak roots at a time where c/c++ were the
| primary alternatives), and golang, most languages don't have a
| corporate oss backer imo [1], at least not one in pole position
| over the language vs other contributors.
|
| [1] perhaps Erlang, but that seems dated as a ref to its origin
| versus contributions and expanded field of endeavor.
| schmichael wrote:
| > most languages don't have a corporate oss backer imo
|
| Oh that's an interesting observation! Made me peek at the
| TIOBE index top 10:
|
| 1. Python - has a Foundation and is as "pure" OSS as I think
| something can be.
|
| 2. C - slow moving standards body
|
| 3. Java - there's a few players here but a fairly small
| number of corporations have outsized impact (Oracle being the
| most)
|
| 4. C++ - slow moving standards body
|
| 5. C# - Microsoft
|
| 6. Visual Basic - Microsoft
|
| 7. JavaScript - standards body but mostly controlled by a
| small number of megacorps and Mozilla
|
| 8. ASM - I guess corp owned? Hard to reason about this one.
|
| 9. PHP - Foundation (I think? I've been out of that world for
| decades and Zend defacto controlled it when I was in it that
| world)
|
| 10. SQL - slow moving standard with tons of vendor specific
| variation
|
| So by rough count I think we have about 30% of the top 10
| controlled by either 1 or a very small number of corporate
| backers. 30% controlled by standards bodies, 30% by
| Foundations, and ...what you count ASM as.
|
| So I think it's fair to say governance by corporate backers
| is as popular a route for languages to take as any.
|
| (To be clear I don't mean "slow" to be a pejorative when it
| comes to standards bodies. If it isn't clear from my OP, I'm
| a big fan of slow moving languages!)
| dqpb wrote:
| My main problem with Go is the error handling.
| zdw wrote:
| Most likely your problem is with the Gerrit "Reviewers by Blame"
| plugin, which contextually uses the last editor of the code to
| determine who to ping to review the code. Makes total sense if
| the developers are still there, but that's obviously your problem
| - they're not there.
| https://gerrit.googlesource.com/plugins/reviewers-by-blame
|
| The plugin also will determine if the user is "Active" - maybe
| what needs to happen is that the Go Devs need to make a sweep and
| mark everyone on their Gerrit who hasn't committed in say 6
| months as not Active:
| https://gerrit.googlesource.com/plugins/reviewers-by-blame/+...
|
| That said even after the cleanup of active users this is
| fundamentally a human problem with a part of the codebase that
| isn't being actively maintained.
|
| As an aside - I really like Gerrit. It's leaps and bounds better
| than GitHub if your goal is putting code review front and center
| as the important task to accomplish, as opposed to search and
| making a fancy webpage. But YMMV.
| hanwenn wrote:
| I am the manager for the Gerrit team at Google. I can assure
| you that the 'reviewers-by-blame' plugin is not currently used
| on any Google Gerrit instance.
| zdw wrote:
| First, thanks for working on Gerrit - it's an excellent
| product that I really love working with!
|
| Second, is it public how the contextual assignment of
| reviewers works on the Go project?
| remus wrote:
| > Most likely your problem is with the Gerrit "Reviewers by
| Blame" plugin...
|
| I suspect it will also be related to a recent change where
| every CL needs to be signed off by two google employees.
| Reducing the number of people who can +1 CLs is going to make
| it harder to get +1s on your CLs.
|
| Reading between the lines I suspect some on the go team at
| google find it a frustrating situation where they have to
| rubber stamp contributions from trusted and capable
| contributors.
|
| https://groups.google.com/g/golang-dev/c/K7oGURi0wTM
| Kon-Peki wrote:
| If someone is qualified to review code when they are employed
| by Google, then that qualification doesn't go away when they
| leave Google. Unless, perhaps, this requirement is
| arbitrary...
| chrsig wrote:
| I interpreted the requirement that they needed to be google
| employees as a legal requirement of some sort rather than
| anything related to qualifications.
| chasil wrote:
| Why is it that the ISO does not control the Go language standard,
| and compiler implementation projects can be as open or closed as
| they see fit?
|
| I will use Go if and when this comes to pass.
| the_gipsy wrote:
| It's google's project, and they "make" it and most things
| around it. Just like Apple's swift or Microsoft's C#.
| deathanatos wrote:
| > _Hint: It's not error handling.1_
|
| Me: "sure it is." So I follow the footnote reference. That links
| to r/haskell. That post, in turn, is nothing but a link to
| r/golang. That post _again_ is nothing but a link to Innoq, which
| is finally the article. Why make a reader jump through so many
| hoops?
|
| All for a second article that ... doesn't support the claim the
| footnote needs to support! (The article concludes that ... error
| handling is _indeed_ problematic, and Pike 's advice
| insufficient.)
| leetharris wrote:
| The problem with Go is that it offers nothing substantial above
| the existing ecosystems.
|
| .NET and Java, both garbage collected, are just as fast or faster
| with a much larger ecosystem. The only real differences are mild
| (composition vs inheritance, simpler multithreading, better TDD
| support, etc).
|
| Rust owns the low level space for modern composition based
| development and manual memory management. C/C++ exists as well.
|
| Typescript and Python completely dominate the dynamic space.
|
| So... why does Go exist?
| erik_seaberg wrote:
| Go is popular for the same reason Scala is not. You're
| encouraged to crank out a lot of ugly repetitive code because
| the language is so minimal you aren't expected to learn a
| cleaner built-in solution (because there isn't one).
|
| Go's memory footprint is also quite a bit better than Java, at
| least until value types land. .NET doesn't seem to have a lot
| of traction; I've been meaning to reevaluate its improved Linux
| story but haven't yet.
| kcartlidge wrote:
| > _.NET doesn't seem to have a lot of traction_
|
| I feel like I'm shilling for C# in this thread (a handful of
| replies so far) so apologies, but I'm genuinely not being
| partisan here as I'm a dev using both Go and C# daily.
|
| However if you think .NET doesn't have traction I can only
| assume you are excluding virtually the entire enterprise in
| favour of start-ups and pure-tech firms. For the second group
| you may be right. For the first group Go is (relatively
| speaking) absolutely nowhere in comparison to .NET, which has
| for years had the enterprise virtually sewn up alongside
| Java.
|
| Outside of enterprise I agree you're probably right, which is
| a shame as it is approximately the equal of Go in most areas,
| worse in some and better in others.
| st3fan wrote:
| You can build wonderful abstractions in Go. Now even more so
| with generics being part of the language. I don't know where
| this is 'encouraged' but the language itself cannot do that -
| only engineering teams or leaders can.
| cheriot wrote:
| It's the runtime and tooling.
|
| Personally, I've largely stopped using the JVM ecosystem and it
| has nothing to do with the languages. Start up delays killed
| applets and have always limited command line tools. Now the
| same startup limitation is afflicting cloud functions. Memory
| management has always made running JVM processes in a multi-
| tenant environment complex (from desktop apps to kubernetes
| pods). The JVM is great in so many ways, but gets extremely
| complex if you want to do anything the runtime authors haven't
| prioritized. Maybe GraalVM will change this? After literally
| decades of waiting, I'm skeptical. /rant
|
| Typescript is still javascript and single threaded. Python
| kinda has types, but most libraries I used don't.
|
| Go's popularity is an indictment of every other language
| ecosystem. It's not better, just less bad.
| sergiotapia wrote:
| .NET and Java are hardly competition.
|
| If you're the suit'n'tie engineer that is Corpo through and
| through you might not notice the baggage but from the outside
| looking in, both of those stacks have this sheen about them
| that is just too much architecture. Too many factories of
| factories of generators of memoized factories. Hell I even
| tried Kotlin, and got pretty far but it didn't take long to get
| smeared with some Java stuff.
|
| Compare that to Go thats lean and you can write the code with
| nothing but a text editor and a compiler -- it's very
| compelling for non-Corpo engineers.
|
| It's why I use Elixir and Nim - I can use both stacks with a
| simple text editor and terminal. They are built with that
| perspective. I don't have to fiddle around with
| MavenASPNetResource.xml digging into 14 different nested
| folders.
|
| With all due respect to the thousands of man hours that went
| into these technological marvels, I just don't have it in me to
| dive into this kind of stuff again:
| https://learn.microsoft.com/en-us/aspnet/core/fundamentals/c...
|
| Look at it! And weep!
| kcartlidge wrote:
| You're right. Go is simpler, cleaner, and lower level.
|
| But as with anything, when you have the experience even the
| linked-to code is second nature and not an issue - it's
| boilerplate, yes, but it is simple stuff that is both obvious
| and clear to those within the ecosystem and simply represents
| a different approach.
|
| Personally whilst I use Go daily I think Linq in C# is far
| superior to anything in Go, but it doesn't stop me using Go
| as well as C# because each has its own approach and each is a
| better fit for specific needs.
| tracker1 wrote:
| Funny, I use the fluent extensions from System.Linq a lot,
| but almost never use actual LINQ syntax.
| tracker1 wrote:
| You can write pretty light C# code... I find that it's C#
| shops I tend not to care much for, not really the
| language/tools so much.
| mfcl wrote:
| Are you asking why alternatives exist in this world?
| lacasito25 wrote:
| Funny how all the languages you mentioned compile slower than
| go (C maybe faster).
|
| Enforcing no exceptions is a pretty big win for me.
| bornfreddy wrote:
| You mean renaming exceptions to panics? Or reinventing them
| through wrapping? (which, admittedly, does have a benefit of
| possibly clearer stack trace)
|
| Go didn't get rid of exceptions, it just made them more
| awkward.
| debug-desperado wrote:
| I think at the end of the day it was about forcing CSP-style
| concurrency on the majority of Google services. You can make a
| pretty good argument that CS programs don't do a great job at
| teaching multithreaded programming (even though it's pretty
| dang straightforward on the JVM and CLR). Race conditions are
| often painful to track down. Exceptions are also tough to get
| right, and many services require several hardening updates
| because of missing catch blocks or overly thoughtless "catch
| and log" behavior. Multi-return, despite the verbosity, may be
| a win on the operations side here.
|
| Like you, I wish Google was more ambitious with their language
| design though. Honestly I'd rather stick to the JVM, especially
| with Virtual Threads now in preview.
| zozbot234 wrote:
| Go does _not_ force CSP-style concurrency. There 's a lot of
| Go code that uses shared memory with concurrent tasks, even
| leading to possibe data races and violations of memory
| safety. (In fact, purely sequential Go is memory safe.)
| throw_m239339 wrote:
| > So... why does Go exist?
|
| Because it does offer an alternative to C/C++ for some projects
| that need to be fast while learning the language requires very
| little investment. And I say that as someone that has been
| criticizing Go for a decade. Go has its place.
|
| It's absolutely faster than both Python and Node.js as a HTTP
| Server,produces faster tooling for linux/PC , it's easy to
| distribute programs written in Go...
|
| It is not serious alternative to Enterprise Java development,
| but neither are Python nor Typescript.
|
| However, I don't think Go's opensource ecosystem is
| comprehensive compared to Python's or Node.js and it is
| ironically due to how rigid the language used to be which
| impaired code generalization since it made polymorphism
| difficult before Generics. It also didn't have an actual
| package system for years. The Go team has had hard time
| understanding that in the past.
| rs_rs_rs_rs_rs wrote:
| Go is a great language to replace sysadmin scripts written in
| python or shellscript. I used to imediately jump to python when
| a shell script would get a little complicated, now I always
| pick Go.
| booleandilemma wrote:
| Why would you do scripting with something that isn't a
| scripting language?
|
| Especially with a language that prides itself on being like a
| modern version of C, of all things.
| hitpointdrew wrote:
| I would hard disagree with this. When bash won't cut it
| Python is the goto.
|
| 1. Python is installed by default of pretty much every linux
| out distro out there.
|
| 2. Go is a bit overkill for something that realistically
| doesn't need any of the speed/performance benefits you would
| get in Go
|
| 3. No need to compile Python
|
| 4. Go is way less readable than Python IMO
|
| Go and Rust are fine languages for a lot of things, but
| sysadmin scripts is not a good use case for either of them.
| kcartlidge wrote:
| You're right with half of these, though 4 is as you say
| purely opinion and 2 depends on the circumstance. It is
| worth noting however that with `go run main.go` (or
| similar) you can execute Go without needing to build a
| binary first so it can behave exactly like a scripting
| language.
|
| And Go builds virtually instantly, meaning for any non-
| trivial script (and if you prefer Go of course) it's a
| virtual certainty that given the negligible build time and
| far better performance a Go 'script' done this way will
| massively out-perform a Python script.
|
| In other words if you don't accept 4 (and I like Python so
| not a dig) and you have a need for 2 then 3 can become
| irrelevant and Go is a good choice.
| tracker1 wrote:
| just realized you can use shebang with a go file...
| sweet.
| morelisp wrote:
| > 1. Python is installed by default of pretty much every
| linux out distro out there.
|
| If you can install a Python script you can install a
| binary, and you won't have missing modules or version
| compatibility issues.
|
| > 3. No need to compile Python
|
| Anything on a server better be coming out of your
| orchestration tools anyway...
| matwood wrote:
| > Python is installed by default of pretty much every linux
| out distro out there.
|
| Which Python? Do I need to install pyenv or venv? What
| about deps? Python is an absolutely disaster every time I
| try to use it. Golang easily cross compiles (fast enough it
| doesn't seem like a compilation is happening) to various
| platforms, I drop the executable there, and it runs.
| jonahx wrote:
| > composition vs inheritance
|
| This is not a mild a difference in practice.
|
| > .NET and Java, both garbage collected, are just as fast or
| faster with a much larger ecosystem.
|
| Go executables don't require a runtime.
| WkndTriathlete wrote:
| > Go executables don't require a runtime.
|
| Sure they do, it just happens to be built into every single
| executable. _Something_ has to manage the GC and coroutines
| for the application.
| kcartlidge wrote:
| > _Go executables don 't require a runtime._
|
| Neither do .NET executables. Cross-platform single-file
| dependency-free.
|
| (I really like Go, just clarifying because I really like C#
| too.)
| oppositelock wrote:
| Alternatives are always good, as is competition. Go applies
| competitive pressure to others, just as they do to Go.
|
| I really enjoy using Go as my main server backend programming
| language. It's verbose, but simple, and that simplicity makes
| it easy to maintain. The CSP model of concurrency/parallelism
| works really well at making multi-threaded applications.
|
| In Go, I can pull from a work queue, fan out for parallel
| processing via multiple threads, fan into a smaller pool for
| some post-processing, really easily. In the HTTP engine, I can
| service each request with its own goroutine, which lets me
| write simple, synchronous, linear code, versus using promises
| or futures or callbacks in other languages, breaking up the
| flow.
|
| To me, subjectively, it's the best backend language when I'm
| writing something from scratch and don't need to tie into a
| pre-existing ecosystem. Go exists because there are lots of
| people like me.
| hazyc wrote:
| I'm one of those people. I've programmed in a lot of
| languages, but it wasn't until I was introduced to Go that
| programming actually become _fun_ rather than more or less a
| job. Everything about the language just immediately clicked
| for me, and suddenly I wasn 't thinking about the language,
| but rather what could I build (and I felt like I could build
| almost anything at that point).
|
| Go is about efficient compilation, efficient execution, and
| ease of programming.
| karolist wrote:
| Go was created as a simple to pickup language to write fast to
| run and compile (!), memorysafe and typesafe, easily
| paralelized code with formatter enforcing consistent style from
| the get go, free from outside idioms which would possibly need
| to be unlearned when writing software at Google. They have
| achieved all of this.
| tracker1 wrote:
| I think the inherent parallelization as probably it's biggest
| feature... not that you can't use similar patterns in other
| languages, just that it's in the box and scales really,
| really well.
| asoliveira wrote:
| The best comment here. I wonder the same.
| kodah wrote:
| There's always been a lot of disfunction with the way the Go team
| does stuff. These same points about Gerrit were made more broadly
| years ago. Gerrit was viewed as an arbitrary barrier to getting
| changes in. They vowed to make it better and as far as I'm aware,
| not much has changed.
|
| The same human processes broke down when Google acquired GoDoc
| and rewrote it using proprietary Google tech. I watched employees
| argue down people concerned with the effects of taking something
| fundamentally open and making it fundamentally closed, and
| subsequently making it dependent on GCP infrastructure.
|
| This just skims the surface of what's gone on over the years.
| Generally, if you're frustrated by the way Go does stuff, I'd say
| you need to realize that their internal priorities trump external
| ones and that cannot be shifted.
| klabb3 wrote:
| I don't disagree, but you're, imo, cherry picking. Go started
| out as a language with many flaws for people outside of Google.
| The absolute awful GOPATH based dep management was made for
| monorepos, for instance. As time went by, they added
| unglamorous tooling and fixes that just makes Go a pleasure to
| work outside of Google, in more domains than originally
| intended.
|
| Compare that with C# or Objective C.
| kcartlidge wrote:
| > _Compare that with C# or Objective C._
|
| As a dev using both Go and C# I'm not entirely sure what you
| mean?
|
| C# is great to work with outside Microsoft, it has lots of
| non-MS code in it, has masses of unglamorous tooling and
| fixes, and is used across a load of domains. I don't know
| about Objective C (that's not my bag) but I'm really missing
| the point re C#.
| klooney wrote:
| As a Python person, GOPATH always made a lot of sense to me.
| It's just a one variable virtualenv.
| marcosdumay wrote:
| Virtualenvs do make some sense for interpreted languages,
| but are far from the best solution to the problem.
|
| Other compiled languages resolve their dependencies without
| any special configuration. Or, if you want to use non-
| shared dependencies, with project-wide configuration, not
| system-wide.
| sosodev wrote:
| If the author is here, could you link the single line change?
| skybrian wrote:
| Other open source projects at Google have struggled with similar
| issues, with respect to balancing reviewing contributions with
| their own goals. It may be a one-line change, but the overhead is
| often similar to something more substantial due to the need to
| make sure it doesn't break Google's proprietary code.
| dbrgn wrote:
| Looking at you, WebRTC.
| vt85 wrote:
| [deleted]
| silisili wrote:
| My experience with contributing there is that they are too
| 'Google'-ized. I guess they pay for the language, so that's their
| right.
|
| Myself and another non-Googler wrote and worked on a portion of
| the code. We'd of course have to get it blessed and merged by G,
| which wasn't that bad.
|
| My problem became when a Googler started messing around in that
| portion of the code, changed it, got it approved, without it
| notifying the two of us who wrote it. Not that we'd need to be
| approvers or anything, just would have been nice to have gotten
| some heads up so we could see how it was changing. I only know as
| it ended up having bad behavior, went to see what changed, and
| wrote a rant on the mailing list about it :).
| infogulch wrote:
| This is an interesting problem for any kind of significant
| contribution made to a big project. To summarize, you seem to
| have some expectation that you would at least be notified when
| your past contribution is undergoing changes, with the
| intention to provide feedback at your discretion. Personally I
| find this expectation relatable and reasonable, but I'm not
| exactly sure why.
|
| To counterpoint, it's pretty easy to explain why you might not
| have been pinged; if every engineer was pinged every time any
| of the code they wrote changed I expect they'd be buried in
| notifications. Also, whose responsibility is it to send the
| notifications? the org's? the engineer making the changes? This
| seems like a lot of organizational and/or social complexity
| that has no chance of actually being implemented.
|
| Maybe the solution is that it's the engineer's responsibility
| to watch the code they care about. This model is better aligned
| with everyone's goals, but it highlights the lack of tooling to
| watch for proposed changes and manage your desired
| notifications.
| afandian wrote:
| Did you have test cases provided an intended contract for the
| code? Did they break? And did they provide a justification for
| the change of contract?
| ajgrover wrote:
| is your expectation that if you contribute to an open source
| project that you would get notified if your code is later
| modified?
|
| if I was in your shoes, I would assume that once the feature is
| merged, the maintainers have final say and can modify or remove
| your code as they wish. An RFC for a breaking change would
| surely be nice but I wouldn't expect any kind of notification
| if the change was some kind of minor update or enhancement.
| flir wrote:
| Would be a nice feature though, wouldn't it... sort of git-
| blame-by-email.
|
| "Hi, this PR is modifying a line of code that you submitted.
| You don't have to do anything, we're just notifying you in
| case you want to weigh in on the PR".
|
| You could extend it into a general purpose "subscribe"
| mechanism - if someone raises a PR against this bock of code,
| please email me.
| tracker1 wrote:
| For that matter, simply attaching a @notify to the pull
| request (assuming it's a public repo) then the repository
| manager can notify you with the PR.
|
| There are automation tools that do this already.
| bborud wrote:
| Yeah, I think this is something that has to be solved by
| the tooling. It isn't reasonable to expect people to do a
| git blame and remember to email everyone whose code you
| want to change.
|
| That being said: I don't even expect people to notify me
| when changing code I have written at work. In fact, if
| people bothered me about code someone else should be
| perfectly capable of reviewing without me, I'd be a bit
| annoyed. I really don't need MORE interruptions.
|
| The fact that a breaking change was introduced is really an
| orthogonal issue. It isn't a given that the original
| authors would catch the problem. Maybe in this case they
| would, but I don't think this is a given.
|
| I have certainly experienced reviewing pull requests
| against code I have written only to let breaks slip by me.
| :-)
|
| To me this sounds more like the code didn't have sufficient
| tests to catch the breakage. If I had written the code I
| would probably have looked at improving the tests after
| helping fix the breakage so at least it doesn't happen
| again. _But of course, that 's just speculation since I
| don't know what was broken and how_.
| kevincox wrote:
| Sounds like a great way to help share knowledge about a
| particular bit of code.
|
| I can even imagine something like take the top 3 authors of
| code changed or removed by the PR and if they aren't
| already the author or reviewer CC them. That way you can
| pull in some people with context.
| guynamedloren wrote:
| Without any additional context (which may be critical to
| understanding fully!) this sounds like an unreasonable
| expectation on your part. Imagine the sheer number of
| contributors to a large open source project (that number is
| nearly 2000 for golang), and then managing the web of
| contributions and subsequently triaging notifications whenever
| a change is made. Sounds like a nightmare. Granted I've never
| contributed to a project of this scale personally, my but
| experience (as a developer working with other developers for
| many years) is that the existing processes and tooling are
| sufficient enough to stay in the loop on things as a
| contributor.
| eberkund wrote:
| Doesn't sound like that much of a nightmare to me. Maybe I am
| missing something but when making a change, you could just
| use `git blame` and you would see the previous author of the
| portion of code and add them as a reviewer.
| marcosdumay wrote:
| > Imagine the sheer number of contributors to a large open
| source project (that number is nearly 2000 for golang), and
| then managing the web of contributions and subsequently
| triaging notifications whenever a change is made.
|
| Imagining the Linux repository (because I have no idea how
| the golang one looks), creating this doesn't look like a big
| deal.
|
| I don't think it's reasonable to expect to be contacted,
| because most projects don't do it. But it's also not
| unreasonable to contact everybody that touched the code
| either.
| kevincox wrote:
| If GP wrote a significant part of the code that is being
| modified it seems like it would be a good idea to involve
| them in the review. It is a chance to share their expertise
| and catch bugs early. I don't think it shuold be required or
| blocking but automatically CCing a few people who have
| recently changed the code seems like a smart idea.
|
| I don't think "managing the web of contributions" seems too
| impractical. If for example you CC the top 3 contributors who
| authored the lines that were changed or modified (excluding
| large automate or "tree-wide" changes) then for any line you
| write you are getting notified at most once. In practice it
| will be much less than that since multiple lines will be
| changed at a time and you won't always be in the top 2 or 3.
| Plus consider that many of these people are qualified to
| review the code and would need to be in that discussion
| anyways. What I'm trying to say is that the data is there and
| available automatically and the cost of reviewing follow-ups
| is bounded.
| peyton wrote:
| It's pretty normal to give a heads up in a project of this
| size.
| endorphine wrote:
| Care to share the link to that particular discussion?
| silisili wrote:
| In the name of what anonymity I've tried to keep here, I'm
| going to refrain, sorry.
| dcormier wrote:
| Sounds like the tests around what you were trying to achieve
| with your changes weren't complete enough, possibly?
| silisili wrote:
| IIRC, it was an overhaul and improvement some months later. I
| didn't mean to at all imply that our code was better or that
| we knew better - the overhaul was much needed, only that the
| review process seemed broken. This was 8-9 years ago, so not
| exactly fresh in my brain.
| [deleted]
| [deleted]
| tromp wrote:
| For more Go problems, see https://www.goproblems.com/ (sorry;
| couldn't resist:-)
| tialaramex wrote:
| > Every change needs approval from at least two Google employees.
| Their code review platform, Gerrit, is meant to automate this.
| But it will happily assign your pull request to ex-employees who
| haven't logged in for years.
|
| This seems like something which can be fixed, technically, and
| which can also be short-circuited (perhaps after verifying that
| the technical fix worked). Rust PRs also require a human review,
| but AFAIK they ensure the list of reviewers tracks people who are
| currently engaged, and also you can explicitly say "I want my PR
| reviewed by person A" and the robot checks that person is a
| reviewer and assigns your PR.
| pipe_connector wrote:
| It would appear that the changeset the OP was having trouble
| getting through review is here: https://go-
| review.googlesource.com/c/text/+/421914
| bumblebritches5 wrote:
| [deleted]
| SmileyKeith wrote:
| I've had similar problems contributing to bazel (Google's open
| source build tool) for the past few years. I've found
| contributing only goes smoothly if there is a single Googler
| working in your area who cares about open source. Otherwise
| everything is very Google centric and the open source community
| is definitely a secondary concern (which is of course their
| right!)
| 0xbadcafebee wrote:
| Don't support open source led by a corporation. There is no
| primary motivation behind the project. Everyone working on it is
| subject to the whims of ephemeral leadership and a headless
| monster moving towards indeterminate goals. The 'community' holds
| no sway, because it's not built by and for a community; it's
| built by a capitalist enterprise for a capitalist enterprise.
| Much more cathedral than bazaar. They may feign to accept your
| contributions, but only when it's extremely convenient.
|
| Look at nearly any open source project that's corporate-led, and
| then - if you can find a FOSS alternative, because most of them
| die if there is an incumbent well-funded project - look there
| too. The FOSS one works the way you want it to. It has features
| built-in that the corporate-led one locks up as a "paid feature",
| and refuses to accept an open-source alternative contribution.
|
| Our entire Open Source community only works when it really _is_ a
| community. People contributing their works and getting it merged
| just because it 's what we all want. Corporations aren't part of
| the community, because they don't do anything without profit.
| Imagine a FOSS project lead who wouldn't merge a PR unless she
| could make money off it.
| kardianos wrote:
| robertlagrant wrote:
| The article wasn't about the bar being too high. It was about
| the PR review system automatically assigning PRs to ex-
| employees, and how there aren't enough maintainers.
| bsder wrote:
| > The bar to contribute should be high.
|
| The issue is things lingering in limbo.
|
| It's okay to have a high bar. It's not okay to let things
| remain unreviewed and open.
|
| If your project staff can't handle the volume of changes, then
| don't pretend you're open. Admit that you have a closed set of
| developers and stop accepting changes from outside. _THERE IS
| NOTHING WRONG WITH THAT_.
| bluenose69 wrote:
| I always thought that a contribution that lingers in limbo (a
| great phrase!) has effectively been rejected.
|
| I agree that active projects that habitually ignore _useful_
| contributions for unreasonable time intervals risk losing
| favour in the open-source community. But whether Go falls
| into this category is beyond my ken.
| endorphine wrote:
| That was a 1-line bugfix though.
| kardianos wrote:
| In my experience, 1-line "bugfixes" are usually so trivial
| they don't matter, or possibly complex in subject matter and
| are often drive-by. Often, but not always", I consider 1-line
| "bugfixes" to be CL smell.
| nateb2022 wrote:
| I think the Maintainers are doing a good job, all things
| considered.
|
| People are certainly free to fork Go, or any open-source project,
| and take on the roles and responsibilities of Maintainers, but I
| believe fragmenting the community has almost always led to the
| overall downfall of a language. Communities are stronger united.
|
| With that in mind, generally Maintainers have the prerogative to
| decide the specific areas of a project that need improvement, and
| to focus their time and energy there. Contributors are welcome to
| contribute code to areas highlighted by Maintainers, and
| generally Maintainers are responsive and happy to work with
| those.
|
| Certainly with the volume of PR's (100+) and Issues (5k+), the
| current Maintainers have their hands full. Decisions will have to
| be made, and priorities established. While an argument may be
| made that we need more Maintainers, this is not an overnight
| solution. A Maintainer needs to really "own" the project, and has
| to have substantial knowledge of the code inside-out.
|
| Developing a great product like Go takes a lot of time and
| effort. I believe that slow(er) development is a fine tradeoff
| for the polished, focused language that Go has become. I would
| gladly take that any day over a fast-and-furious project where
| development happens at light-speed but the overall quality
| decreases with every commit.
| unethical_ban wrote:
| >but I believe fragmenting the community has almost always led
| to the overall downfall of a language
|
| Warning, I am not a professional developer, only a mere
| scripter.
|
| Aren't forks and transpiled languages sometimes a driving
| force? Typescript/coffeescript pushed changes in Javascript.
| Scala on the VM pushed changes in Java. jQuery as a DSL of
| javascript even pushed changes in the language.
|
| And in all of these cases, the branch language/framework
| eventually becomes less relevant, but that does not take away
| the utility and influence they provided in their time.
|
| So if someone imagines running a Golang fork and successfully
| develops the fork with new features and/or better processes and
| faster iteration, it may be useful even if they end up dying
| once and if Golang itself incorporates the changes.
| amdolan wrote:
| With Typescript/coffeescript, there were core language
| improvements to the language that led to popularity in the
| JavaScript community. Things like types and arrow functions
| were welcome additions and gained adoption.
|
| I think that a Go fork would be more like, for example, Go
| with text internationalisation fixed. It wouldn't be very
| interesting to a large part of the Go community who is using
| the language just fine.
| chrsig wrote:
| > Certainly with the volume of PR's (100+) and Issues (5k+),
| the current Maintainers have their hands full. Decisions will
| have to be made, and priorities established. While an argument
| may be made that we need more Maintainers, this is not an
| overnight solution. A Maintainer needs to really "own" the
| project, and has to have substantial knowledge of the code
| inside-out.
|
| I think one of the big problems is that decisions _aren 't_
| being made. Issues, proposals, PRs, etc. get ignored. Ignoring
| is not a decision, it's the absence of a decision.
|
| It's fine if they don't want to accept/fix/invest/etc in
| whatever issue a contributor is raising, but by not providing a
| rationale, the community just gets left in the dark without any
| idea how to proceed.
| bsg75 wrote:
| Is this scenario better managed in other language projects?
| jackosdev wrote:
| I've made contributions to Rust repos and it was a great
| experience, they helped me along and were very quick with
| responses. I never even considered it for Go because the
| community shot down every idea I had.
| chrsig wrote:
| I imagine it varies wildly based on the project. How any
| other project behaves doesn't change the experience of
| working with the go project.
|
| Comparing go to itself, I _feel_ like they 've lost some
| steam and are coping with the ecosystem steadily growing. I
| can't say for sure if that's the case, and I can have a lot
| of empathy for anyone just feeling exhausted all the time
| these days. That doesn't change the experience on the
| trying-to-contribute side of the interaction though.
| philosopher1234 wrote:
| FYI there is a weekly review of a subset of open proposals
| here: https://github.com/golang/go/issues/33502
| chrsig wrote:
| I'm aware. There's no timeline for when a proposal may
| actually be considered. It certainly isn't submission
| order. So proposals sit around for an indefinite amount of
| time before entering into the process to give them a
| definitive decision.
| donio wrote:
| > but I believe fragmenting the community has almost always led
| to the overall downfall of a language
|
| I'd argue the opposite. Most programming languages that truly
| thrive have multiple independent implementations. Go always
| (1.0+) had multiple implementations and for some of us this was
| a factor in accepting it as a serious contender.
|
| Fragmentation is not a concern as long as the language and
| standard library remain well defined. The more the merrier.
|
| (I'm not arguing for trying to wrestle control from the current
| team, I think they are doing a fine job. Only meant to address
| the fragmentation thing)
| namaria wrote:
| Complex systems tend to attract this class of opinions where
| individuals believe their judgement would improve the overall
| system. They are nearly always wrong, otherwise they would have
| devised a better system already.
| flir wrote:
| I don't know. Authors that get big enough to ignore their
| editors can produce some pretty awful work. The role of
| editor has value.
| cbron wrote:
| It's not about ignoring editors, it's about taking
| constructive feedback, and the ratio of constructive
| feedback to noise is very low in complex projects. In those
| projects, people that aren't heavily invested typically
| don't know enough about the wider project to make valuable
| contributions.
| namaria wrote:
| I don't follow how you got from 'complex problems don't
| have simple solutions' to 'editors don't add value'
| bborud wrote:
| Except that implementing ideas usually takes a non-zero
| amount of time.
| groestl wrote:
| Hint: it _is_ error handling (as well). Forces me to be half-
| human, half-compiler and reinvents the convenience of Java's
| checked exceptions, but without stack traces. It might sound
| bitter, which I don't intent to be, I just cannot fathom why a
| significant fraction of users seem to be blind to this, or become
| blind after a while. Must be some kind of Helsinki syndrome.
|
| I use Go for the deployment story, but I think (and I know that
| I'm not alone in this) that error handling in Go desparately
| needs a runtime-exception-kind-of awakening.
| [deleted]
| vincnetas wrote:
| * Stockholm syndrome
|
| https://en.wikipedia.org/wiki/Stockholm_syndrome
| groestl wrote:
| True, thanks!
| yalue wrote:
| If accurate, it's unfortunate to hear the situation has worsened
| here. About 7 years ago, I sent what was essentially a single-
| line bugfix to Go, and it was reviewed and merged within 3 days.
| kardianos wrote:
| That is often still the case. It really depends on the CL being
| proposed (which is not linked).
| endorphine wrote:
| Same here, though it was a 3 line change to x/sys
| platz wrote:
| so - the thesis is that go needs funding?
| davidw wrote:
| Code review seems to be a small but annoying problem in a lot of
| places, beyond the problem in the article of people who are no
| longer active being assigned.
|
| When you've finished doing something, you want to get that review
| right away so you can fully move on to the next thing. OTOH, if
| you're a reviewer, you don't want to lose focus by jumping on
| random things at random times.
|
| It creates frustration all around. Not sure what the answer is.
| What works well for your team?
| bcrosby95 wrote:
| I check anytime I'm normally interrupted. So at the start of
| the day, before/after lunch, at the end of the day, after any
| meetings or phone calls, etc.
|
| If I don't have time to do it I'll update the person on when I
| plan to do it. So if I'm heading to lunch and see a review,
| I'll ping them that I'll do it after lunch.
|
| And if it's the very end of the day, I let them know I'll take
| a look first thing in the morning.
|
| If that doesn't pan out for some reason, I let them know and
| give them an update on when I expect to be able to do it.
| sosodev wrote:
| In my opinion reviewing code should be a higher priority than
| other work. Getting existing changes reviewed, polished, and
| merged is better for everybody involved than creating more
| changes that will also need to be reviewed and potentially
| rebased.
| kibwen wrote:
| The problem is that developers don't get promoted for
| reviewing code. If you want good code review in a corporate
| environment, you _cannot_ leave it to developers, you need to
| have a dedicated QA team. OSS contributions are more
| complicated (in theory people care a bit more about the
| quality of the resulting software rather than being
| recognized), but even then reviewing will never be as fun as
| developing for the vast majority of contributors, burning out
| those who are willing to.
| bornfreddy wrote:
| Does the QA team do _code_ reviews where you work, or do
| they just test the behavior of the app? In all the places I
| know QA only does black box testing.
| sahila wrote:
| Dedicated qa doesn't absolve the responsibility of code
| reviewers which devs absolutely need to be involved with.
| Code review is as much about functionality as it is about
| code design and extensibility.
| clappski wrote:
| By sharing the load, we have a #reviews channel that anyone can
| put something in to get peer review. If there's something that
| needs attention from a specific person then arranging a call to
| walk through is a good approach where both reviewee and
| reviewer can negotiate a time to review.
| plorkyeran wrote:
| I'm far from perfect at this, but my general idea is that you
| should never _start_ something other than code reviews if you
| have review requests pending. Interrupting something to review
| is awful, but as soon as you are interrupted you should
| prioritize unblocking people.
| cpeterso wrote:
| That's a hard perspective for many developers to adopt
| because people understandably prioritize their own tasks and
| deadlines. I think it needs manager support and even
| encouragement because it's a global optimization for your
| team's productivity. Reviewing and merging pending PRs will
| deliver value to your product sooner than procrastinating on
| pending PRs so you can write new code that will then need to
| wait for some other developer to review it. It can be a
| vicious cycle.
| salamanderman wrote:
| Additionally, at least in small-medium sized teams, I've
| seen teams become over reliant on the small number of
| people who prioritize and respond quickly to code review
| requests. A benefit of _not_ prioritizing code review as an
| individual is that it can naturally spread the review
| responsibility, and understanding of the code, more
| broadly.
| skybrian wrote:
| Within a team, I wonder if a ping-pong reviewing scheme would
| work? Instead of suggesting changes, make the changes yourself,
| test them, and send the revised patch back to them for review.
| It's done when someone says "good enough."
| kqr wrote:
| For me a very common review comment is asking the author to
| clarify their intention in a comment. I can't do that myself
| becaus I don't know!
| skybrian wrote:
| That might be a place to put a "TODO: explain" comment when
| sending it back.
| AtNightWeCode wrote:
| Code reviews must have a higher priority than new development.
| In a team it should complete within hours. The process also
| needs to be opinion free. There should be a checklist to go
| through. A code review is not the place to talk about other
| potential solutions. Also, absolutely no testing during
| reviews.
| agentwiggles wrote:
| > Also, absolutely no testing during reviews.
|
| Really? I consider it part of the due diligence of a good
| review to pull down the branch and at least make sure the
| tests pass, maybe even try the functionality out if it's
| something easy to do. Maybe you mean something different in
| this context though?
| AtNightWeCode wrote:
| No. Devs should not test other coders code. Much better to
| hand it over to dedicated testers or the quality assurance
| team.
| teeray wrote:
| Many teams don't count code reviews as "work". They may pay lip
| service to it, say that it's A Good Thing and a Requirement.
| However, when it comes down to periodic reviews of work
| completed, the issue tracker highlights the assignee and that's
| who gets all the glory. On these teams, code reviews will
| languish unless you somehow score Agile funpoints for doing
| them.
| robertlagrant wrote:
| That sounds like such a broken system.
| napo wrote:
| Asking for code to be reviewed within one day worked well in
| the teams I worked with. Some pple likes to do it in the
| morning before starting the rest of their day. And if someone
| has something urgent or small they can always ping the team.
|
| I can understand than for changes in a language it's a bit more
| involved than that though.
|
| Also, I'm really curious about teams that do reviews after
| merge. I heard some places do it but I never really got a good
| understanding of the pros&cons
| orblivion wrote:
| Could maybe edit the word "Real" into the submission title to
| match the article.
___________________________________________________________________
(page generated 2022-11-02 23:02 UTC)