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.
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.
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.
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.
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.
> 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)
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.
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?
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.
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.
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.
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.
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.
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 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.
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.
> 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.
[+] [-] silisili|3 years ago|reply
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 :).
[+] [-] guynamedloren|3 years ago|reply
[+] [-] ajgrover|3 years ago|reply
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.
[+] [-] infogulch|3 years ago|reply
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.
[+] [-] dcormier|3 years ago|reply
[+] [-] afandian|3 years ago|reply
[+] [-] perrygeo|3 years ago|reply
[+] [-] endorphine|3 years ago|reply
[+] [-] nateb2022|3 years ago|reply
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.
[+] [-] chrsig|3 years ago|reply
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.
[+] [-] namaria|3 years ago|reply
[+] [-] donio|3 years ago|reply
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)
[+] [-] kodah|3 years ago|reply
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|3 years ago|reply
Compare that with C# or Objective C.
[+] [-] davidw|3 years ago|reply
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?
[+] [-] zdw|3 years ago|reply
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|3 years ago|reply
[+] [-] remus|3 years ago|reply
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
[+] [-] schmichael|3 years ago|reply
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|3 years ago|reply
[1] perhaps Erlang, but that seems dated as a ref to its origin versus contributions and expanded field of endeavor.
[+] [-] dom96|3 years ago|reply
Hope the above saves you a click.
[+] [-] skybrian|3 years ago|reply
[+] [-] dbrgn|3 years ago|reply
[+] [-] yalue|3 years ago|reply
[+] [-] kardianos|3 years ago|reply
[+] [-] endorphine|3 years ago|reply
[+] [-] pipe_connector|3 years ago|reply
[+] [-] icholy|3 years ago|reply
[+] [-] SmileyKeith|3 years ago|reply
[+] [-] deathanatos|3 years ago|reply
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|3 years ago|reply
.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?
[+] [-] sergiotapia|3 years ago|reply
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!
[+] [-] cheriot|3 years ago|reply
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.
[+] [-] oppositelock|3 years ago|reply
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.
[+] [-] karolist|3 years ago|reply
[+] [-] jonahx|3 years ago|reply
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.
[+] [-] throw_m239339|3 years ago|reply
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.
[+] [-] debug-desperado|3 years ago|reply
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.
[+] [-] rs_rs_rs_rs_rs|3 years ago|reply
[+] [-] lacasito25|3 years ago|reply
Enforcing no exceptions is a pretty big win for me.
[+] [-] erik_seaberg|3 years ago|reply
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.
[+] [-] mfcl|3 years ago|reply
[+] [-] asoliveira|3 years ago|reply
[+] [-] orblivion|3 years ago|reply
[+] [-] tialaramex|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] dqpb|3 years ago|reply
[+] [-] 0xbadcafebee|3 years ago|reply
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.
[+] [-] sosodev|3 years ago|reply
[+] [-] platz|3 years ago|reply