deklerk

Others have answered this better than I, but I'll tell you what I've seen:

- grpc-go and gopls had great "Contributors welcome" issues set up. For both of them, I had to email/chat various people for help getting used to the code, but everyone was extremely pleasant and helpful (and happy to help). - Drive treated it like an internship, where a TL curated a set of low-priority issues and I just went and chatted with folks when I had questions. Again, everyone was very helpful. - Other Go tools I've worked on have had really intuitive codebases, or were quite small, and have been easy to dive right in. That's helpful too, though I do end up chatting with people a lot.

If I had to make a general statement I guess I would say: don't allow 20%ers if you don't have the time for an intern. Treat the 20% like an internship: free labour with a little bit of extra onboarding. It's ok to not have that time, but I think most people are usually happy and excited to provide that help! =)

Oh, actual tip: having a myproject-users@ / myproject-devs@ mailing list, or a #myproject-devs chat channel, goes a long way. Then, chatting and asking questions can be informal and ad-hoc.

I imagine it's not appropriate for startups, since they're burning money fast and mental health appppears to be less of a priority? I've not worked at one, so hard to say.

Besides startups, I think it's fair play at companies of all sizes. Employees are the most important thing to companies, and the overhead of losing trained, context-carrying talent tends to be heavy. So, why not let them fulfill that scratch and keep them at your company.

I've seen some companies allow 20% on any team within the company (rather than any project whatsoever): that could be a nice middleground for a company that is unsure about the whole thing.

I've been at Google for 3 years and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc).

I think it's fantastic. The whole 120% thing is up to the individual: there have been times I've made it a 120%, and there are times when it's been just "take a friday off to work on other stuff". You end up getting less of your "job" done but my managers have always been supportive.

It's been great for sanity: some weeks/months feel just, like, meetings and chore work. It's great having that one day a week to work on a rockstar feature request in some fun project. It's also cool to work on your dream projects without the luck/physical move/whatever to get on the actual team. (you can effectively work on anything since no project is going to say no to free headcount)

It's also nice because it spreads your professional network in the directions you choose to spread it, rather than the more organic spread that your normal job entails (assuming luck and available are big drivers of where and which projects you "end up" working, rather than 100% your choice). So, maybe I don't work on project X today, but I can 20% on it and build up those connections, and later in my career I have a much better shot getting on the project. That agency is a nice feeling.

So, as far as the employee happiness goes, I think it's fantastic.

Denver voter here: wer'e very excited about this! Our neighbours in Longmonth and Fort Collins both have similar situations, and we're jealous over here. Excited for some competition to ISPs, and excited for our government to be, ya know, building things that help its peoples. =)

Package-Side Problems I also find it problematic because it breaks (in my mind) one of the most useful things about module names – they reflect the file path.

Sorry, this is incorrect: https://golang.org/ref/mod#module-path. A module path describes where to find it, starting with its _repository root_ (github.com, golang.org, etc) and then the subdirectory in the repository that the module is defined in (if not the root).

So, if a module lives in golang.org/username/reponame/go.mod, its module path is likely golang.org/username/reponame. If a module lives in golang.org/username/reponame/dirname/go.mod, its module path is likely golang.org/username/reponame/dirname. (and so on with a /v2 folder, etc)

I mention this because it appears that OP's major gripe in "package side problems" is that the /v2 dir "breaks" the (mis)conception that a module path describes _only_ the repo root.

(see also: multi module repositories)

In other words, we should only increment major versions when making breaking changes

No, you can increment major versions whenever you want (though it's painful to your users). But, you _should_ increment a major version when you make a breaking change.

I think a simple console warning would have been a better solution than forcing a cumbersome updating strategy on the community.

Could you elaborate on how a console warning solves the problem of users becoming broken when module authors make incompatible changes within a major version?

Another problem on the client-side is that we don’t only need to update go.mod, but we actually need to grep through our codebase and change each import statement to point to the new major version:

What if you need to use v2 and v4 of golang.org/foo/bar? How would you import them both without one having a /v2 suffix and a /v4 suffix? Are you proposing that users should only be able to use one major version of a library at a time?

(I assume you are talking about a user upgrading to a new major, not the package author bumping to a new major. If the latter, a grep and replace is quite approachable and is shown in the blog you linked :) )

Go makes updating major versions so cumbersome that in the majority of cases, we have opted to just increment minor versions when we should increment major versions.

I'm reminded of when the "unused imports not allowed" rule was lambasted, and then goimports was released and the conversation was snuffed out. This situation feels analagous.

You praise the toolchain and the good decisions in modules, but then hinge your thesis against it on "it's cumbersome". That's a valid concern, but it's likely that a tool that makes major version upgrades easier will resolve your issue. A wholly different design certainly is not needed .

Check out https://godoc.org/golang.org/x/exp/cmd/gorelease for one tool that's under development aimed at helping version bumps. It sounds like you also need something that will create the v2 branch/directory, change all the self-referencing import paths in that branch/directory, and change the go.mod path. That sounds like an easy tool to write - I expect something like that should come out quite quickly if it doesn't already exist.

-------------------

Side note: In my opinion, dependency management is a rat's nest of choices that seem good at the outset and end up with terrible consequences later on. Go modules make super well thought out decisions, and is a very very simple design, built to last for a long time without regrets. Sometimes the right answer is to work around a small problem with some tooling or documentation rather than go a totally different direction that will have large, sad consequences later.

That is: all choices have downsides, but it's good to choose the best choice whose downsides can largely be tackled with easy solutions like tools and docs. Decisions like "we should build a SAT solver" have sad, sad, sad consequences that can't be tool'd and doc'd away, for example.

Semver is very clear on what a minor vs a major change means.

the majority of software in use today uses version numbers - they are most often used to denote new features, which may or may not have breaking changes large or small, and small breaking changes are tolerated all the time, often in minor versions

We're getting into opinion here. Let's be clear: semver very strictly, objectively disagrees with this approach. In general, this approach of "what's a few breaking changes in a minor release amongst friends" leads to terrible user experiences.

Go modules takes the cost of churn, which in some languages gets externalized to all users, and places it on the module author instead. That is far more scalable and results in much happier users, even though module authors sometimes have to be more careful or do more work.

Thanks, this is good feedback. In general, I reckon having a variety of documentation is great, so also would like more of "how" documentation.

I believe the tutorials that are in the work take more of the "short and sweet" approach, which should help with this.

Hiyo,

I'm one of the co-authors of https://blog.golang.org/v2-go-modules.

One of the takeaways from this article was, "there needs to be more documentation", and I think I can speak to that:

First, thanks for the feedback. We also want there to be a loooot more documentation, of all kinds.

To that end, several folks on the Go team and many community members have been working on Go module documentation. We have published several blog posts, rewritten "How to write Go code" https://golang.org/doc/code.html, have been writing loads of reference material (follow in https://github.com/golang/go/issues/33637), have several tutorials on the way, are thinking and talking about a "cheatsheet", are building more tooling, and more.

If you have ideas for how to improve modules, module documentation, or just want to chat about modules, please feel free to post ideas at github.com/golang/go/issues or come chat at gophers.slack.com#modules.

What in the world. This is incredible. Could we have a blog post about how this is achieved? Is there webassembly involved?

Thanks for these great links! This is very informative.

Where are you getting 90% from? AFAICT it's closer to 50% or 60% [1] [2].

And, note, that deal was only a 4 year deal from 2017-2021 [1]. It's not like a decades-old source of revenue that's dried up.

And even though the deal is expiring, they've had deals before (yahoo etc), and will certainly have more in the future.

1: https://www.computerworld.com/article/3240008/mozillas-recor...

2: https://www.cnet.com/news/google-firefox-search-deal-gives-m...

Let's please not upvote this. It is _not_ a "standard" go project - it doesn't even have a go.mod. Furthermore, it is in an org called "golang standards", when in reality it and its projects are not standards - they're just some opinions of some programmers.

Let's please not make getting started with golang more confusing to beginners by falsely claiming standards.

Also, see numerous similar complaints in this project's issue tracker: [ex1 https://github.com/golang-standards/project-layout/issues/38) [ex2 https://github.com/golang-standards/project-layout/issues/38].

You're thinking of chubby. :) https://ai.google/research/pubs/pub27897

Those are also, as the OP has repeatedly addressed: first order effects.

I used "fairness" because it appears in most definitions of the anti trust regulation. A "level playing field" is 100% not the point of antitrust laws. Sidenote: I don't believe any "playing field" in business is "level".

I think something for folks to keep in mind is that much of the US antitrust laws were made back in the early 1900s to combat _literal_ monopolies, objective collusion between companies to harm consumers, and so on. We're talking price fixing here.

Anti-trust laws can be seen as pro-market laws that try to prevent long periods of monopolized markets without waiting for a naturally occurring disruption, instead providing a mandated disruption.

This sentence is dangerous: it is very close to saying that any long-term, successful company should be "disrupted". Interpreted differently it could be read that startups should have some inherent right to evenly compete with large companies (by fining or splitting up large companies to be "beatable" by startups).

Again, that is not all the point of anti trust laws. I won't argue whether there should be laws like that (as you can tell, I think not), but the anti trust regulation in the USA is definitely squarely aimed at _actual_ monopolies and collusion.

The point of antitrust regulations is to stop the anti-innovation practices

Is that true? That doesn't match the definition of any antitrust regulation I'm aware of. AFAIK antitrust regulation is intended to enforce _fairness_, not _innovation_. Often the two go hand in hand, of course, but I think it's worth not conflating the two.

s/Rib/Rob :)

I'm not a twitch streamer/viewer, but I believe a lot of folks are in it for the community aspect. Following your favourite streamers and being a participant in the group chat - especially if your streamer chats with the group - is a way for folks to feel like they're hanging with friends.

In contrast, watching TV by yourself can be quite lonely.

There are a lot of other differences between TV and twitch; I'm not sure how much worth there is in comparing them. They seem (to me) to mostly be different categories of products that happen to both include a video component.

I generally just stick to net/http. In both small projects and large enterprise-y projects it's served well. I think most Go devs are roughly of similar opinion at this point.

YES. Absolutely yes. I _hated_ this aspect of working with AWS. Also, documentation always came off as "generic" and "wordy" without being "useful" - a huge, huge article that might have the tiny sliver you need in it, or perhaps one of its dozens of sister articles would have the answer, who knows.

Author here - happy to answer any questions.

For example Los Angeles County, twice as large as Finland.

Uhh. You're off by two orders of magnitude. Los Angeles county is 4751 sq mi [1]. Finland is 130,666 sq mi [2].

1: https://en.m.wikipedia.org/wiki/Los_Angeles_County,_Californ...

2: https://en.m.wikipedia.org/wiki/Finland

Was it necessary to change the title of this post a half dozen times?

This is good satire about overly-aggressive folks / jerks heh.

I guess the one nit I have is about the predilection to rag on weightlifters. It's just a hobby for many people. I don't do it myself, but I have met loads of the friendliest people that do. Working out, having protein shakes, and eating hard-boiled eggs do not make someone a jerk. /shrug

Very very cool. One of the most neatest use of javascript/browsers I've seen, but then again I'm a huge sucker for sci-fi space stuff. :)

[citation needed]

the difference is between Docker and Google App Engine

Neither the question nor the answer in your link compare Docker and App Engine.

Docker is a containerization platform, whereas App Engine is a PaaS (platform as a service). Their functions are wholly different.

Very, very loosely; Docker is about building and running an individual package of some software. Basically, bundling software and running bundles. PaaS are platforms for developing, running, and managing (often pre-bundled) software.

App Engine is a PaaS (platform as a service), as is PCF. Docker is a containerization platform, though, which is entirely something else. e.g. a PaaS might use Docker (many do).

Yep, not what happened. Google didn't make one; they acquired one. Google sunset that reader (I'll agree that in retrospect it was the wrong move, but regardless), but at no point did RSS readers stop existing. Two notes:

- RSS readers are _dead simple_ to build. If you're an average programmer you could make an MVP within 2 days.

- Many of the RSS readers are/were free. I don't think Google having Reader caused any great migrations, but even if it did I doubt it would have caused other readers to implode or anything like that.

I _believe_ what happened is that Reader had a small but vocal user group who were (understandably) upset at the sunsetting, and caused a big hubbub about it. I _suspect_ many of today's Reader complainers have never actually used Reader, and are just piggy-backing off some low-hanging Google bashing fruit.

Again, I'll happily nod at the badness of Google killing off Reader, but I intensely dislike the amount of hyperbole in the statement that Google "killed RSS". It's a thing that never took off. That's all that happened. It's still accessible, there are many clients you could use, and so on - it just so happens that most sites don't bother creating an RSS feed.

but capturing RSS and then shutting it off

... what? Ultra, ultra hyperbole much? I get it, shutting down reader sucked, but seriously you can literally use any RSS reader to read feeds. Google didn't "kill RSS".

Seriously, voicing opinions is one thing but fear mongering and hyperbole is another and this article leans far too heavily towards the latter.