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 :).
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.
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.
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.
> 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.
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.
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.
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.
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.
Yeah, I agree with that. I had a significant feature included in the Python stdlib (os.scandir and related changes) and after it was included in 3.5, the core developers have made significant improvements to it (added "with statement" and "close" support, and so on), and I don't think I was contacted at all. I wouldn't have minded being contacted, but I'm actually quite happy I could write the initial proposal and feature and don't have to maintain it after that. :-)
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.
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.
So, if the correct behavior was known, why did you not write a test asserting the correct behavior? I understand that it can get complicated, just legitimately curious if the behavior could or could not be easily captured by the test suite.
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.
> 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.
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.
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.
I'm a maintainer of some smaller open source projects -- you have to consider it from the project owner's point of view. To say they "shoot down ideas" is a negative way of saying it, but from their point of view they're carefully selecting and designing features and code that fit the design philosophy of the language. If the Go developers included every idea that users submitted (and there are many! -- I read the mailing lists), the language and standard libraries would be a sprawling and incoherent pile.
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.
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.
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.
Fair. It was the "otherwise they would have devised a better system already" bit.
I'm saying that people who are not capable of writing a bestseller (solving a complex problem) are still capable of editing a bestseller (their judgement would improve the overall system).
> 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)
>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.
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.
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.
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.
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#.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
> 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
I can imagine it works for larger features that need a more thorough, formal review. I'm personally only familiar with code reviews on smaller changes (from trivial fixes to whole features, but often limited to <1000 LOC). The danger of only reviewing small parts of a larger whole is that you miss things in the larger whole.
But for that, you can do both; small code reviews from a 'task' branch into a 'feature' branch, then a big code review before merging into the main branch. The smaller reviews should catch the more trival or obvious issues.
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."
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.
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?
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.
i always review stuff within 24 hours. usually much sooner. pisses me right off when people don't return the favor. i want me shit in prod just as much as you, don't waste my time and I won't waste yours.
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.
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.
> 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.
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...
I interpreted the requirement that they needed to be google employees as a legal requirement of some sort rather than anything related to qualifications.
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.
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.
> 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!)
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.
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.
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!)
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.)
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.
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.
You're comparing a fully fledged framework to a language, so not apples to apples comparison. At an employer that heavily used golang, they had to reinvent frameworks (dependency injection, web app, RPC, etc.) to standardize how work was being done, and guess what, you ended up having huge stack traces anyway that some people mock ASP.NET or Spring for, not to mention very slow build times. Modifying small parts of code and rebuilding to re run unit tests was so time consuming it's not even funny. I had a faster experience with Scala and SBT, so that's saying something.
> you can write the code with nothing but a text editor and a compiler
Nothing is stopping you from doing the same in other languages. At some point, the benefits of what IDEs offer (refactoring, inspections, integrated debugging, profiling, etc.) almost become necessary when working on large programs.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
> 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.
4. Type hints make python readable, but with as with most scripts people avoid type hints. This makes python actually less readable then go. Additionally python syntax allows for some very convoluted patterns. This is less the case for go. Go syntax forces explicit procedural steps while python you can throw 20 steps into a single 1 line list comprehension.
3. Go compiles so fast it's not that far off from an interpreted language.
2. It's not as big of a scripting language but it's close enough such that I can see justification for it's usage.
1. Yeah but go can be installed pretty quickly from package managers on every linux distro out there.
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.
What you've shown is that Go takes 5 times as many lines of code, but this is a trivial example based on boilerplate. Once you scale your codebase up beyond a handful of lines the percentage which is actual boilerplate becomes negligible and this example ceases to be valid.
As an aside, I can't deny that on a per-line or even per-scope basis Python is often more readable. But at the meta level where you're dealing with an entire codebase, which to me is more relevant, the structural aspects come into play and that's where it devolves into pure opinion.
In other words, comparing for readability across a handful of lines is not valuable unless you're only dealing with codebases which are also only a handful of lines.
Of course the main driver of this thread is script files, and for readability Python probably does win as they tend to be short. But I'd argue that as long as something is readable enough (which Go is) then other factors like performance may need to come into the decision.
Suffering is a function of familiarity with the language and the intelligence of the user. Go is good enough such that if you had familiarity with both python and go, usage of either is justifiable in terms of expressiveness and ease of use.
Your lack of knowledge about this fact, however, is a symptom of intelligence.
I've worked on large golang projects. Linking takes a very long amount of time. Languages like Java or C# have a much faster compile then run unit test cycle. Even full compilation, it's hard to prove that golang is faster in any significant manner, and could very well be slower.
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.
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.
On my enterprise space, .NET has indeed not much traction outside Windows. even with .NET Core as many key products are yet to be UNIX friendly.
However when we go for UNIX solutions, Java is the alternative, Go is not even part of the picture unless we are talking about devops tooling (which nowadays is becoming trendy to rewrite in Rust anyway).
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.
> 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.
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.
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.
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.
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.
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.
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.
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 :).